Agora você já sabe tudo o que acontece antes de um novo software chegar até você. Mas, como descobrir as necessidades de quem vai utilizar esse software?

Continuando a série A saga do herói… Ou melhor, do software!, hoje vamos falar sobre levantamento de requisitos, a primeira atividade do desenvolvimento de software. Como falei no último texto, esse é o momento em que os analistas de sistemas interagem com os usuários para identificar as necessidades deles (a.k.a. requisitos). Ou seja, é o momento de compreender o “problema” que precisa ser resolvido, detalhando assim o que o software deve fazer em vez de como isso será feito.

Dada a importância do tema, existe uma área da Computação dedicada somente a isso: a Engenharia de Requisitos. Essa área está interessada em todas as atividades que contribuem para a produção de um documento que detalha todos os requisitos contemplados no software a ser desenvolvido, além da manutenção desse documento ao longo do tempo.

A primeira das atividades da Engenharia de Requisitos é o estudo de viabilidade. Nesse momento, os analistas avaliam a viabilidade do projeto, considerando restrições tecnológicas, econômicas, políticas, ambientais, recursos disponíveis etc., e produzem um relatório que recomenda ou não a continuidade do projeto.

Caso o projeto seja viável, pode-se iniciar a identificação dos requisitos. Além de entender o que o software precisa fazer, também é necessário avaliar o domínio que o software será utilizado e identificar pessoas interessadas no software e fontes de informação relevantes. Essa é uma etapa bem crítica porque os interessados no software podem não saber exatamente o que desejam, desejarem coisas não realistas, expressarem as mesmas necessidades de formas diferentes. Para ajudar, algumas técnicas de levantamento podem ser aplicadas, como: demonstração de tarefa; Etnografia; Estudo de documentos; Storyboarding; Questionários; Brainstroming/Brainwriting; Workshops; Entrevistas; etc.

Após a identificação, é necessário realizar uma análise e negociação. Nessa atividade, os requisitos identificados passam primeiramente por uma classificação. Com isso, é possível identificar e solucionar conflitos entre os requisitos; priorizar esses requisitos de forma que os mais críticos sejam tratados primeiramente; além de confirmar com os interessados a completude e validade dos requisitos identificados.

Conhecendo os requisitos, passa-se para a atividade de especificação e documentação. É nessa etapa que o documento de requisitos é produzido. Esse documento apresentará todos os requisitos, funcionais (descrevem as funcionalidades que o sistema disponibilizará) e não-funcionais (descrevem restrições nas quais o software deve operar), do software.

O documento de requisitos também passa por uma validação. Essa atividade tem por objetivo mostrar que o documento gerado corresponde ao software que os interessados precisam. Através de um conjunto de técnicas, o documento é verificado e problemas identificados e corrigidos.

Por fim, tem-se a gestão dos requisitos. Os requisitos estão em constante evolução, seja para adaptar o software a novas necessidades ou desenvolver melhorias. Assim, é necessário definir como ocorrerá a identificação de problemas e/ou novos requisitos; avaliar o custo/impacto que as alterações terão; pensar em como as mudanças serão realizadas; definir que ferramentas serão utilizadas etc.