|
Identifique os Stakeholders
Identifique os tomadores de decisão, clientes, potenciais usuários, parceiros, peritos do domínio, analistas da indústria e outras partes interessadas (veja Role: Stakeholder). Desenvolva perfis dos potenciais (ou atuais) usuários do sistema que correspondem aos papéis dos atores humanos do sistema que você está desenvolvendo. Documente a informação inicial sobre os principais usuários e seu ambiente na Visão. |
Adquira consenso sobre o problema a ser resolvido
Evite se apressar na definição da solução. Primeiro obtenha um consenso na definição do problema perguntando aos Stakeholders o que eles enxergam como problema. Então busque as causas primárias, ou o "problema atrás do problema". Utilize técnicas como as descritas na Guideline: Técnicas Para Obtenção de Requisitos. Formule a declaração do problema, e preencha então a seção correspondente do Template: Visão. Sua finalidade é ajudar a distinguir as soluções e respostas dos problemas e questões.
|
Capture um vocabulário comum
| Cada projeto tem sua própria terminologia especializada que todos na equipe devem compreender bem para se comunicar eficazmente com os Stakeholders. Trabalhe com os Stakeholders para criar um glossário que defina acrônimos, abreviaturas e termos técnicos e de negócio relevantes. Trabalhe com os Stakeholders para expandir e refinar continuamente o glossário durante todo o ciclo de vida do projeto. |
Obtenha as solicitações dos Stakeholders
Utilize o método mais apropriado para recolher informações, tais como os que estão na Guideline: Técnicas Para Obtenção de Requisitos. Cada um é aplicável a uma situação particular ou para um tipo específico de Stakeholder.
Se você puder se encontrar pessoalmente com os Stakeholders, então você poderá conduzir uma entrevista ou uma sessão de brainstorming. Esta colaboração face-a-face é extremamente valiosa e reduz as possibilidades da equipe de projeto não entender as necessidades dos Stakeholders.
Alguns requisitos podem já ter sido documentados em uma Lista de Itens de Trabalho existente. Isto pode normalmente ser usado como um sólido ponto de partida do qual um conjunto completo de requisitos possa ser criado.
Qualquer requisito obtido durante esta etapa deve ser capturado na Lista de Itens de Trabalho.
Para mais informações, veja Task: Encontrar e Descrever os Requisitos. |
Defina os limites do sistema
Encontre e defina a linha que divide a solução e o mundo real que a cerca. Identifique as interfaces, bem como as informações de entrada e saída trocadas com os usuários, máquinas ou sistemas.
Colabore com o Gerente de Projeto e o Arquiteto visto que as decisões relativas aos limites do sistema terão um grande impacto no custo, no cronograma e na arquitetura do sistema.
Um Modelo de Caso de Uso é uma técnica que pode ser útil na definição dos limites do sistema. Para mais informações, veja Task: Encontrar e Descrever os Requisitos. |
Identifique as restrições no sistema
Considere as várias fontes de restrições que podem afetar o design ou o próprio projeto:
- Políticas
- Econômicas (orçamento, licenciamento)
- Ambientais (restrições regulamentárias, legais, padrões)
- Técnicas (plataformas, tecnologias)
- Viabilidade (cronograma, alocação de recursos, terceirização)
- Sistemas (compatibilidade das soluções, suporte do sistema operacional e ambientes).
Colabore com o Gerente de Projeto e o Arquiteto visto que as decisões relativas às restrições no sistema terão um grande impacto no custo, no cronograma e na arquitetura do sistema. |
Defina as características do sistema
Trabalhe com os Stakeholders para capturar uma lista das características que eles querem no sistema, descrevendo-as resumidamente e registrando os atributos para ajudar a definir suas prioridades e status gerais no projeto.
Atualize a Visão para capturar as características identificadas e seus atributos. |
Obtenha consenso
| Conduza uma revisão da Visão do projeto com os Stakeholders mais relevantes e a com a equipe de desenvolvimento para assegurar o consenso, avaliar a qualidade e identificar as mudanças necessárias. Veja Guideline: Revisão Eficaz de Requisitos para mais informações. |
|
