análise de requisitos

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

Upload: perry

Post on 16-Jan-2016

49 views

Category:

Documents


0 download

DESCRIPTION

Análise de requisitos. Profa . Reane Franco Goulart. Requisitos. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Análise  de  requisitos

1

ANÁLISE DE REQUISITOS

Profa. Reane Franco Goulart

Page 2: Análise  de  requisitos

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

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

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

5

Níveis de abstração dos requisitos?

Page 6: Análise  de  requisitos

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

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

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

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

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

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

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

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

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

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