​Existe bastante diferença entre a forma como os requisitos são tratados nas diferentes metodologias de desenvolvimento existentes. Um conceito bastante antigo, mas que algumas vezes ainda é utilizado pelas empresas de uma forma incorreta, é que a análise de requisitos é apenas uma etapa do desenvolvimento de software e que acontece sempre no começo do desenvolvimento. Então na etapa inicial, onde é feita a primeira reunião com o cliente, são identificados os requisitos funcionais e não funcionais. Depois disso, o sistema começa a ser desenvolvido e não há uma revisão dos requisitos e raramente eles são alterados. Isso porque, como tudo é modelado no início, se houver algum tipo de alteração no meio do caminho, pode interferir no prazo e no custo do projeto. A etapa de análise de requisitos gera uma documentação bem extensa e muito bem delineada de diagramas, gráficos e especificações de todas as necessidades que devem ser atendidas.

O ciclo de vida do desenvolvimento, portanto, seguia a estrutura:

1-Análise de Requisitos;

2- Planejamento;

3-Desenvolvimento;

4-Entrega.

Quando utilizamos metodologias ágeis de desenvolvimento, o pensamento é diferente. As etapas que seguimos não são tão diferentes, mas elas são tratadas de forma diferente. Nesse contexto, os princípios são: colaboração e comunicação entre os envolvidos no projeto (equipe e cliente). A ideia é responder de forma rápida e eficiente a possíveis mudanças para aumentar o valor e qualidade do produto final. Então na primeira etapa, não necessariamente teremos todos os requisitos definidos em documentações extensas, mas teremos uma visão geral e definição do máximo de requisitos possíveis, mas não acaba por aí. Como as metodologias ágeis preveem que haja entregas menores com validação do cliente, é possível que nessas pequenas entregas os requisitos estejam mais claros ou sejam alterados para atender melhor as necessidades.

No contexto de desenvolvimento ágil, temos um recurso que se chama “User Stories” ou Histórias do Usuário, que também representa os requisitos do sistema, mas de uma forma diferente. Elas são explicações curtas, informais e mais gerais sobre um recurso de software, escrito a partir da perspectiva do usuário final ou do cliente, por exemplo: “Como cliente, gostaria de realizar meu cadastro na plataforma, onde eu possa comprar os produtos da loja”. Veja que ela possui uma estrutura, apesar de simples, precisa conter: O tipo de usuário, o que ele quer e para que. Essa estrutura não é obrigatória, mas ajuda muito. Cada equipe pode ter sua estrutura própria.