Utilize o método mais apropriado para recolher informações, tais como os que estão na 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 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, mas você deve se preparar para que essas reuniões sejam produtivas.

Alguns requisitos podem já ter sido documentados na demanda, em reuniões anteriores ou em outro contato com o cliente. 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 inserido no Documento de Visão do Projeto.

Esteja preparado para revisar as informações relacionadas ao domínio do problema, a definição do problema, ao ambiente empresarial e aos principais Stakeholders.

Requisitos podem ser classificados como funcionais ou não-funcionais. Os funcionais especificam o que o sistema deve fazer (cerne do sistema). Os não-funcionais especificam restrições na solução, tais como facilidade de uso, confiança, desempenho, facilidade de suporte, interfaces com sistemas legados, etc (fronteira dos sistema).

Colabore com os Stakeholders para identificar os tipos de requisitos relevantes ao sistema. Isto lhe ajudará a avaliar a completude do conjunto de requisitos.

Na concepção devem ser levantados requisitos de negócio. Ou seja, aqueles que definem "o que" deve ser feito.

Na fase de elaboração devem ser levantados requisitos do sistema. Ou seja, aqueles que definem "como" deve ser feito.

Todos os requisitos levatandos para o projeto devem ser validados segundo Critérios de Entendimento, Validação e Aceitação dos Requisitos. Esta é uma medida que visa garantir a qualidade do projeto, uma vez que um requisito mal declarado ou entendido pode gerar inúmeros problemas no decorrer do empreendimento.

A validação SEMPRE deve ser realizada por um Analista de Negócio que NÃO tenha participado da composição do documento de visão. Isso elimina vícios de leitura e permite que alguém com conhecimento técnico adequado revise o trabalho de levantamento e questione possíveis incongruências.

Para cada requisito listado no Documento de Visão, o revisor deve repassas o checklist com os critérios apresentados e confirmar se o requisito atende a todos eles. Caso exista alguma inconsistência, o revisor deve conversar com o Analista responsável pelo levantamento e corrigir os problemas detectados imediatamente.

Dialogue com o cliente se é desejo dele possuir o código-fonte do sistema. Muitas vezes, se o cliente for leigo em informática, ele pode nem entender do que se trata, neste caso, realize uma explicação sobre este conceito.

Defina junto ao cliente a quem pertencerá o código-fonte do sistema, se à empresa desenvolvedora ou ao cliente. Na maioria das vezes o cliente irá indicar que ele deseja obter os códigos-fontes, no entanto, argumente se ele irá utilizar este código posteriormente, uma vez que não é algo trivial realizar manutenções no código (provavelmente ele terá que contratar uma empresa) e devido ao custo deste ao projeto, se dentro do escopo, será a maior parte do investimento.

A instalação do produto normalmente já é entendida para o cliente que faz parte do projeto. No entanto, defina junto a ele se realmente será realizada pela equipe de desenvolvimento e além disto: em qual servidor(res) será realizada, qual a configuração do servidor, se é remoto ou não, se existem outros sistemas já configurados, se ele possui uma equipe técnica capacitada para auxiliar na instalação, se os softwares necessários ao servidores serão comprados pela empresa, etc.