Web viewperspectiva do Cliente (foco no foco do cliente). Neste documento está descrito...

Logotipo ou nome da empresa cliente

Projeto:

Project Charter

Verso X.X

Ms, Ano

NDICE

Colocar um ndice aqui.

Histrico de Reviso

Data

Verso

Descrio

Autor

1. Introduo

1.1. Propsito

O propsito do documento de Project Charter coletar, analisar e definir as necessidades do Cliente e as caractersticas (requisitos) do Projeto de Software, descritas em alto nvel focando o negcio sob a perspectiva do Cliente (foco no foco do cliente). Neste documento est descrito o qu ele necessita, incluindo a descrio do problema a ser resolvido e uma proposta de soluo tecnolgica. Em nenhum momento este documento descrever como estas necessidades sero atendidas. Os detalhes de implementao da soluo tecnolgica proposta estaro descritos nos documentos de requerimentos de software.

1.2. Extenso

Identificar informaes externas para consulta, como manuais, referncias em leis, documentos da organizao, etc.

1.3. Definies, Acrnimos e Abreviaes

Este tpico prov a definio de todos os termos, acrnimos e abreviaes utilizados no contedo deste documento, objetivando melhorar a compreenso do mesmo. Estas informaes so referenciadas a partir do documento de Glossrio do Projeto, consulte-o para obter maiores detalhes e a lista completa dos termos documentados para este projeto.

Exemplos:

Deliverable: Todo Produto de Trabalho (Work Product) previamente acordado para ser entregue ao Cliente. A sada de um Processo pode ser considerado um Deliverable, desde que tenha um significado, valor, para o Cliente que o solicita.

Stakeholder: Pessoas, Grupos ou Unidades Organizacionais que atuem como colaboradores ou patrocinadores, com interesses financeiros ou no, no sistema a ser desenvolvido.

Work Product: Todo artefato produzido como resultado de determinada atividade, tambm denominado Produto de Trabalho.

SLA Server Level Agreement.

1.4. Referncias

Descrever as referncias externas para o projeto.

2. Posicionamento da Oportunidade de Negcio

2.1. Oportunidade de Negcio

Descrever a Oportunidade de Negcio para o projeto.

2.2. Declarao do Problema

Descreva de maneira breve, fornecendo as informaes solicitadas na tabela a seguir, o problema que seu Cliente atualmente enfrenta, que este projeto visa resolver. Verifique se o exemplo proposto adequado ao contexto deste projeto e, utilize-o fazendo as adequaes necessrias. Lembre que um projeto visa resolver um problema e que este quadro um resumo, portanto apenas um quadro suficiente.

O problema

.

afeta

o impacto disto

uma soluo proposta seria

3. Identificao dos Stakeholders, Usurios e suas Necessidades

3.1. Stakeholders

Identificao do Stakeholder

Descrio

Critrios de Sucesso

Deliverables

Restries No-Tcnicas

[Ttulo do Stakeholder]

[Nome do Stakeholder]

[Papel (Qualificador): Executivo, Sponsor, Usurio, rea Interessada.]

[Nvel de Competncia Delegada: Alto; Mdio; Baixo]

Responda: Como o stakeholder define o sucesso do projeto? Como o stakeholder ser recompensado ou reconhecido com o sucesso do projeto?]

Responda: H algum produto previsto ou no na metodologia a ser desenvolvido (Work Product) e entregue (Deliverable), no qual o stakeholder possua especial interesse?]

Responda: H algum marco (milestone) ou data de entrega (parcial ou total) de algum Produto de Software (deliverable, componente ou programa de software) a ser desenvolvido, os quais o stakeholder considere-os importantes sob a perspectiva de negcio.

No especifique restries oramentrias ou termos contratuais.]

3.2. Usurios

Identificao do Usurio

Descrio

Critrios de Sucesso

Deliverables

Restries No-Tcnicas

[Ttulo do Usurio]

[Nome do Usurio(s)]

Quando forem muitas as pessoas envolvidas opte por documentar os papis exercidos por elas.

[Representa o Stakeholder: xxxx]

[Papel (Qualificador): Tcnico de Negcio e/ou Usurio da rea de Negcio e/ou Usurio-Final do Sistema.]

Responda: Como o stakeholder define o sucesso do projeto? Como o stakeholder ser recompensado ou reconhecido com o sucesso do projeto?]

Responda: H algum produto previsto ou no na metodologia a ser desenvolvido (Work Product) e entregue (Deliverable), no qual o stakeholder possua especial interesse?]

Responda: H algum marco (milestone) ou data de entrega (parcial ou total) de algum Produto de Software (deliverable, componente ou programa de software) a ser desenvolvido, os quais o stakeholder considere-os importantes sob a perspectiva de negcio.

No especifique restries oramentrias ou termos contratuais.]

[Obs.: todos os demais usurios do sistema j esto identificados e representados pelos respectivos stakeholders, sendo desnecessrio repetir as informaes.]

3.3. Necessidades dos Principais Stakeholder e Usurios

Stakeholder / Usurio

Necessidade

Prioridade

Preocupaes

Soluo Atual

Solues Propostas

[NOTA: Identifique o stakeholder ou usurio.]

[NOTA: Liste as principais necessidades do stakeholder ou usurio. Tambm pode-se verificar quais so os ou problemas enfrentados por eles e, suas razes.]

[NOTA: Informe a prioridade, importncia, da soluo para cada problema sob a perspectiva de cada stakeholder ou usurio.]

[Alta, Mdia ou Baixa]

[NOTA: Descreva as preocupaes do stakeholder ou usurio quanto a sua necessidade e/ou a soluo atual. Busque informar as razes destas preocupaes.]

[NOTA: Descreva a soluo atualmente em uso para atender a necessidade.]

[NOTA: Descreva a soluo tecnolgica proposta para atender a necessidade.]

3.3.1. Detalhamento das Necessidades

Informaes adicionais para as necessidades acima relacionadas.

4. Caractersticas do Projeto de Software

Liste e descreva resumidamente as caractersticas do projeto de software baseados numa viso de alto nvel. As caractersticas de um sistema podem ser consideradas como as capacidades que precisam estar disponveis para trazer benefcios aos seus usurios, atendendo as suas solicitaes.

Cada caracterstica uma solicitao de servio externo ao sistema, que tipicamente requer uma srie de entradas para o resultado desejado.

O nvel de detalhamento destas informaes dever ser de alto nvel, geral o bastante para que todos tipos de stakeholders / usurios possam compreend-las de maneira adequada.

Para gerenciar a complexidade do software a ser construdo, recomendvel que entre 25 a 100 caractersticas do sistema sejam descritas, sendo que cada caracterstica ser detalhada como um requerimento funcional ou no-funcional. Estas caractersticas devero ser reconhecidas pelos usurios, stakeholders e/ou outros sistemas externos que compartilhem informaes. Ao descrev-las, especifique o qu dever ser feito, mas no detalhe o como fazer. Verifique os exemplos, edite-os ou apague-os se conveniente.]

4.1. Caracterstica 1.

[NOTA: O detalhamento deste tpico no Work Product obrigatrio! Descrever o detalhamento da caracterstica, sua prioridade (na viso do cliente) e qualquer premissa que seja aplicvel a sua efetiva implementao no projeto.]

.

4.2. Caracterstica 2


.



.

4.4. Caracterstica 4


.



5. Caractersticas de Qualidade do Projeto


.

6. Caractersticas de Restries do Projeto


.

7. Outras Caractersticas do Projeto

7.1. Padres Aplicveis


.

7.2. Caractersticas de Ambiente


.

7.3. Caractersticas de Desempenho

[NOTA: O detalhamento deste tpico no Work Product obrigatrio! Descrever o detalhamento da caracterstica, sua prioridade (na viso do cliente) e qualquer

Web viewperspectiva do Cliente (foco no foco do cliente). Neste documento está descrito...

Documents

Transcript of Web viewperspectiva do Cliente (foco no foco do cliente). Neste documento está descrito...