ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

16
ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1

Transcript of ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

Page 1: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

1

ANÁLISE DE REQUISITOS

Profa. Reane Franco Goulart

Page 2: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

2

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.

Page 3: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

3

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;

Page 4: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

4

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.

Page 5: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

5

Níveis de abstração dos requisitos?

Page 6: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

6

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

Page 7: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

7

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.

Page 8: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

8

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

Page 9: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

9

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.

Page 10: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

10

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.

Page 11: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

11

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?

Page 12: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

12

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?

Page 13: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

13

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?

Page 14: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

14

Documentar um requisito

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

Page 15: ANÁLISE DE REQUISITOS Profa. Reane Franco Goulart 1.

15

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