ANÁLISEDE REQUISITOS. Profa. Reane Franco Goulart

Transcrição

1 1 ANÁLISEDE REQUISITOS Profa. Reane Franco Goulart

2 Requisitos 2 Apartemaisárduanaconstruçãodeumsistemade 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.

3 O quesão requisitos? 3 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;

4 O quesão requisitos? 4 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.

5 5 Níveis de abstração dos requisitos?

6 RequisitosFuncionais 6 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 quando sua requisição estiver disponível para retirada.

7 RequisitosFuncionais 7 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.

8 Requisitosnãofuncionais 8 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( , VoIP, Browser); usabilidade e portabilidade (a aplicação deve rodar em vários tipos de aplicativos: móveis, desktop, notebook).

9 Requisitosnãofuncionais 9 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.

10 10 Exemplo: Validação de um requisito não funcional Um requisito não funcional qualquer estabelece que o softwaretemqueterumbomtempoderesposta. Para quantificar esse requisito, pergunte ao usuário o que ele considera umbom 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.

11 Documentaçãodos requisitos 11 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?

12 Documentarum requisito 12 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?

13 Documentarum requisito 13 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?

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

15 Que artefatos usar para documentar um requisito? 15 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. EmUMLgeralmentechama-sede casodeuso.

16 16 levantamento-de-requisitos-parte-1/