Análise de Requisitos

Já houve um tempo em que os usuários não entendiam a magia que acontecia por trás dos sistemas de software. Eles podiam não entender como se dava o desenvolvimento do software, não conseguem especificar muito bem o que desejam do software e era muito dificil desenvolver algo sem saber exatamente o que deveria ser feito.

Então muitas técnicas surgiram e atualmente as principais técnicas de análise de requisitos consistem em fazer entrevistas com os stakeholders para se melhorar todos os requisitos, procurando remover contradições, priorizar os requisitos, permitir que eles façam a escolha também do que pode ser feito com relação aos custos.

Em alguns casos, se for julgado necessário, é possível se fazer uma reunião com todos os interessados para se definir o escopo/custo geral, principalmente quando cada uma das partes deseja algo diferente e precisam entrar em um acordo.

A forma comum de se documentar isso é por meio de contrato. E mais do que a lista de funcionalidades que pode ser muito longa, se propõe uma lista de objetivos mensuráveis que deve ser alcançada com protótipos o quanto antes, para que estes objetivos maiores possam ser atingidos.

Outras duas técnicas muito conhecidas para ajudar a exemplificar e facilitar a visualisação deste software final são a prototipação e os casos de uso para ajudar na especificação dos requisitos.

O problema é que a prototipação acabava gerando uma certa ansiedade e sensação de que o software seria mais fácil de implementar do que seria de verdade e acabava gerando bastante desgaste. Também acabavasse recorrendo ao uso do protótipo como produto final, o que poderia implicar em diversos outros riscos e também poderiam passar muito tempo apenas desenvolvendo um protótipo que poderia ser descartado.

Quanto aos casos de uso, é uma técnica que acaba simplificando muito o software para mostrar um cenário de como seria as interações do usuário com o sistema. Mas como também não diz nada sobre a lógica que deve andar por trás do software, pode ser mal interpretado nas estimativas de prazos e esforço.

Agora que o sistema está melhor especificado, acabou-se, certo? Não, claro que não. É importante também se poder acompanhar com os stakeholders se o projeto está indo na direção correta, mais um ponto para metodologias ágeis de desenvolvimento, que acabam gerando mais versões que podem voltar a ser discutidas e revisadas...