Profa. Reane Franco Goulart Análise de requisitos Profa. Reane Franco Goulart

Requisitos “A parte mais árdua na construção de um sistema de software é decidir o que construir. Nenhuma outra parte do trabalho compromete mais o sistema se for feito de forma imprópria. Nenhuma outra parte é mais difícil de corrigir a posteriori”. Frederick P. Brooks Jr, “No Silver Bullet: Essence and Accidents in Software Engineering”, IEEE Computer, abril 1987.

O que são requisitos? Requisitos são as necessidades do cliente para um sistema de software. Requisitos são descritos em diferentes níveis de abstração: Requisitos de usuário: especificam em linguagem natural as funções que o sistema deve prover ao usuário final;

O que são requisitos? Requisitos de sistema: especificam em linguagem natural (mais estruturada) as funções e restrições (especificação funcional) para que o sistema de software seja capaz de atender os requisitos de usuário.

Níveis de abstração dos requisitos?

Requisitos Funcionais Descrevem as funcionalidades ou serviços que se espera do sistema. Estes requisitos tem uma característica importante, pois são eles que agregam valor ao software ou facilitam a vida do usuário. Exemplo: “o sistema deve notificar ao requisitante por e-mail quando sua requisição estiver disponível para retirada”.

Requisitos Funcionais Eles expressam o comportamento de um software. As informações de entrada, o processamento e a saída emitida por uma funcionalidade são informações necessárias para especificar o requisito do referido grupo.

Requisitos não funcionais Mapeiam os aspectos qualitativos de um software, por exemplo: performance (tempo de resposta); segurança (restrições de acesso, privilégios); perspectiva do usuário (padrão das cores, disposição dos objetivos na tela); comunicabilidade (e-mail, VoIP, Browser); usabilidade e portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis, desktop, notebook).

Requisitos não funcionais Este grupo é de suma importância e não deve ser desprezado durante o processo de produção de software. Como qualquer outro tipo de requisito, ele deve ser levantado, analisado, especificado e validado.

Validação de um requisito não funcional Exemplo: Um requisito não funcional qualquer estabelece que o software tem que ter um bom tempo de resposta. Para quantificar esse requisito, pergunte ao usuário o que ele considera um bom tempo de resposta. Uma variação ente 0,5 e 2 segundos é aceitável? Enfim, os requisitos não funcionais são de suma importância e podem delimitar o sucesso ou o fracasso de um projeto de software.

Documentação dos requisitos Documentar requisitos custa caro. Você pode chegar numa documentação de 500 páginas de um único requisito com diagramas, protótipos, documentação descritiva e no final das contas produzir um artefato que ninguém vai ler ou seguir, ou ainda, escrever uma documentação de meia-página que não ilustra o problema real. Então como chegar no nível certo de documentação?

Documentar um requisito O cliente entende o documento? Ele entende que o documento é uma poderosa ferramenta para garantir que todas as suas solicitações serão contempladas no sistema?

Documentar um requisito O desenvolvedor entende o documento? Ele entende que esse é sua única garantia de que está atendendo todas as solicitações do usuário e qualquer solicitação fora disso poderá ser considerado como modificação e ele terá tempo extra para fazê-las?

Documentar um requisito O responsável pela implantação consegue entender como o sistema funciona baseado nesse documento?

Que artefatos usar para documentar um requisito? Para cada metodologia, usa-se um nome diferente para um documento de requisito ou artefato diferente para realizar a documentação: Em análise estruturada (voltando aos anos 70-80), usava-se o DFD, e muita documentação descritiva. Em UML geralmente chama-se de “caso de uso”.

http://rodrigodotnet. wordpress http://rodrigodotnet.wordpress.com/2010/09/01/ levantamento-de-requisitos-parte-1/ http://eduardo- prola.blogspot.com.br/2011/10/pessoal- excelentes-dicas-para-o.html http://codipse.tigris.org/planatividades.htm