Inicialmente, faça a identificação dos requisitos de modo a compreender o domínio no qual o projeto se insere, as partes interessadas envolvidas, a captura dos requisitos pretendidos para o sistema, além das restrições que podem influenciar o desenvolvimento do sistema.

Algumas dificuldades podem ser encontradas nessa etapa:

• Os stakeholders podem não saber exatamento o que querem;
• Cada stakeholder pode expressar os mesmos requisitos de maneiras distintas;
• Os requisitos podem ser conflitantes.

Existem algumas técnicas de levantamento de requisitos que podem ser utilizadas:

• Entrevistas e questionários;
• Workshop de requisitos;
• Uso de cenários;
• Prototipagem;
• Estudo etnográfico.

Após a identificação dos requisitos, analise-os com o objetivo de entender melhor o que foi solicitado e resolver possíveis conflitos identificados. Nessa análise, organize ou classifique os requisitos em "módulos", por exemplo, para se ter uma visão global do sistema. Depois, priorize-os para posterior validação com as partes interessadas.

A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.

Descreva os requisitos de usuário em consenso com os Analistas de Negócios. É importante que os requisitos descrevam uma característica do produto, que corresponde à solução de um ou mais problemas descritos na Visão. Além disso, a definição desses requisitos deve estar alinhada com as definições dos termos de negócio, regras de negócio e suas restrições relacionados em Lista de Regras de Negócio. A descrição dessas características deve constar na seção de requisitos funcionais na Lista de Requisitos.

Identifique os requisitos não-funcionais, como facilidade de uso, confiança, desempenho, interoperabilidade, facilidade de teste, facilidade de manutenção, etc. Esses requisitos não-funcionais devem estar definidos no artefato Lista de Requisitos.

Colabore com os Analista de Negócios para ter certeza que os termos ambíguos ou específicos ao domínio sejam claramente definidos no Glossário e que esses termos sejam utilizados de forma consistente.

Colabore com os Analistas de Negócios para identificar e capturar os Ator(es) e os Caso de Uso no Modelo de Caso de Uso . Veja Guideline: Encontrar e Descrever Atores e Casos de Uso para mais informações.

Posteriormente, crie/atualize o Modelo de Caso de Uso adicionando, removendo e atualizando os Atores e os Caso de Uso conforme necessário. Para mais informações sobre a criação e a estruturação do modelo de caso de uso veja Guideline: Modelo de Caso de Uso.

Caso já tenha identificado os casos de uso e definido os requisitos, detalhe os Caso de Uso para validar a compreensão do requisito e permitir o início do desenvolvimento do software. Isto não implica que todos os casos de uso e cenários serão detalhados antes do início da implementação. Colabore com os Analistas de Negócio para detalhar somente aqueles que foram priorizados para implementação na próxima iteração ou na subseqüente, ou aqueles que foram definidos como arquiteturalmente significantes (veja Concept: Requisitos Arquiteturalmente Significantes.)

Importante ressaltar que o nível de detalhe capturado irá variar dependendo das necessidades do projeto e da complexidade do caso de uso.

É importante assegurar que a lista de Requisitos funcionais e não-funcionais identificados na Lista de Requisitos possam ser relacionados aos Caso de Uso propostos para o sistema. É importante definir um projeto claro, portanto, se a alteração é proposta enquanto o sistema está em desenvolvimento, o impacto da alteração envolve verificar como a alteração afeta os requisitos, o projeto do sistema e sua implementação.

A Matriz de Rastreabilidade oferece como grande facilitador a visualização global dos Requisitos x Casos de Uso do sistema em uma tabela de forma gráfica, dando suporte para tomada de decisões e descoberta de problemas e sua solução de forma mais rápida.

Execute e analise os seguintes Checklists: 

• Checklist - Lista de Requisitos (DOC) para a Lista de Requisitos. Esse checklist deve ser executado, preferencialmente, pelo Analista de Métricas, que poderá auxiliar na identificação de possíveis discrepâncias entre requisitos funcionais e não funcionais.
• Checklist - Modelo de Caso de Uso (DOC) para o Modelo de Caso de Uso.

Caso tenha especificado Caso de Uso na iteração, utilize também o Checklist - Caso de Uso (DOC).

Os checklists de Caso de Uso e Modelo de Caso de Uso devem ser executados, preferencialmente, pelo Analista de Testes, que posteriormente usará esses artefatos como subsídio na elaboração dos Caso de Teste.

Adicionalmente, o Desenvolvedor de Software pode ser consultado para avaliar a viabilidade técnica da solução propondo alternativas.