Engenharia de Requisitos Definição de Engenharia de Resquisitos Motivação Perspectivas...

Preview:

Citation preview

Engenharia de RequisitosEngenharia de RequisitosDefinição de Engenharia de

ResquisitosMotivaçãoPerspectivasDefinição e Tipos de RequisitosProcesso de ERModelagem de RequisitosEspecificação de Requisitos

1

DefiniçãoDefiniçãoTambém conhecida como:

◦Análise de requisitos;Análise de sistemas.

É a área responsável pela descoberta:◦Das reais necessidades dos clientes.

◦Do comportamento externo de uma solução que atenda a estas necessidades.

Domínio do Problema

Domínio da Solução

2

3

MotivaçãoMotivaçãoSegundo Brooks*, a ER é a parte mais difícil da construção de um software.

Nenhuma outra parte do desenvolvimento causa tantos danos se feita de forma errada.

Nenhuma outra parte é tão difícil de ser corrigida.

*F. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Computer, vol 20(4):10-19, april,1987.

Determina o sucesso…Determina o sucesso…

4

Ou o fracasso…Ou o fracasso…

5

Copyright 2006-2007 Prof. Edison A. M. Morais 6

PerspectivasPerspectivas

◦Perspectiva de domínio◦Perspectiva tecnológica◦Perspectiva temporal

Copyright 2006-2007 Prof. Edison A. M. Morais 7

Perspectiva de DomínioPerspectiva de DomínioDomínio do problema

◦Exploração detalhada de um problema particular para determinar as necessidades de automação do usuário.

Domínio da solução◦Especificação do comportamento externo de um sistema.

Copyright 2006-2007 Prof. Edison A. M. Morais 8

Perspectiva TecnológicaPerspectiva TecnológicaExistem vários mecanismos de especificação:◦Linguagem natural;◦UML;◦Prototipação;◦Métodos formais, etc.

Copyright 2006-2007 Prof. Edison A. M. Morais 9

Perspectiva TemporalPerspectiva Temporal◦É uma das atividades iniciais da engenharia de software.

◦Resulta no criação de um documento de Especificação de Requisitos de Software (ERS). Este documento deve ser atualizado

constantemente para obtenção de mais conhecimento sobre o problema.

Copyright 2006-2007 Prof. Edison A. M. Morais 10

Perspectiva TemporalPerspectiva Temporal

10

Engenharia de Software

Processo de Desenvolvimento de Software

Implemen-tação

TesteImplan-tação

Atividades- Garantia de qualidade;- Gerência de Configuração;- Gerência de Riscos;- Métricas;

- Estimativas;- Revisões Técnicas Formais.

Outros Processos

Contidos no Processo Principal

Análise de

Requisitos

Projeto

RequisitoRequisito

O que é um REQUISITO?◦Em software: “É a CARACTERIZAÇÃO do que o sistema deverá fazer.”

Existem vários tipos de requisitos que devem ser analisados…

11

Tipos de RequisitosTipos de Requisitos

12

Copyright 2006-2007 Prof. Edison A. M. Morais 13

Processo de ERProcesso de ER

Como deve ser este documento?

Como Conduzí-lo?

Copyright 2006-2007 Prof. Edison A. M. Morais 14

Dificuldades do ProcessoDificuldades do ProcessoVolatilidade dos requisitos;Clientes dispersos, numerosos;

Clientes com objetivos conflitantes, perspectivas e formações distintas;

Clientes com dificuldades para esclarecer seus objetivos.

Copyright 2006-2007 Prof. Edison A. M. Morais 15

Características desejáveis Características desejáveis para o ERSpara o ERSDocumento ERS completo;Documento ERS não ambíguo;

Documento ERS passível de ser testado.

Processo de ERProcesso de ER

16

Atividades do Processo de Atividades do Processo de ERER

17

Modelagem de RequisitosModelagem de Requisitos

18

Modelagem de RequisitosModelagem de RequisitosBoas PráticasBoas PráticasAnálise Orientada a Objetos;ER executada em várias rodadas;

Revisões constantes com os usuários;

Protótipos;Alocação de 15% a 30% do esforço total do processo.

19

Específicação de Específicação de RequisitosRequisitosModelagem GERA especificação.

Especificação: Documento ERS.

É um conjunto de documentos.

Ex.:

20

Documento Visão

Especificação

Suplementar

Modelo de

Domínio

Casos de Uso

+ + +

Documento VisãoDocumento Visão

Objetivo◦Descrever as necessidades e características de alto nível do sistema.

◦Exs.: Visão geral do sistema. Descrição dos usuários. Requisito funcionais.

21

Especificação Especificação SuplementarSuplementarObjetivo

◦Descrever os requisitos não funcionais do sistema

◦Exs.: Usabilidade Confiabilidade Performance

22

Modelo de DomínioModelo de Domínio

É o resultado da Análise Orientada a Objetos (AOO);

Objetivo:◦Auxiliar na compreensão e análise do problema.

Artefato◦Diagrama de Classe de Domínio

(UML)23

Diagrama de Classe de Diagrama de Classe de DomínioDomínioExemplo

24

Casos de UsoCasos de Uso

Representam interações entre usuário e sistema.

25

Caso de Uso A

Ator

Caso de Uso B

UC1. Caso de Uso 1

Descrição: .........

Fluxo Básico:1. O usuário

solicita....2. O sistema

disponibiliza...

UC1. Caso de Uso 1

Descrição: .........

Fluxo Básico:1. O usuário

solicita....2. O sistema

disponibiliza...

Descrição de Caso de Uso

Diagrama de Caso de Uso

Casos de UsoCasos de Uso

Exemplo

26

É recomendável associar um diagrama de atividades

Diagrama de AtividadesDiagrama de Atividades

Exemplo

27

Referências BibliográficasReferências BibliográficasEngenharia de Software, Pressman, Roger

– 6ª Edição.

Lucena, F. N. Requisitos de Software: Eliciar, Registrar e Ser bem-sucedido. Disponível em http://www.inf.ufg.br/~fabio

28

Recommended