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