A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Requisitos Eveline Alonso Veloso PUC-Minas.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Requisitos Eveline Alonso Veloso PUC-Minas."— Transcrição da apresentação:

1 Engenharia de Requisitos Eveline Alonso Veloso PUC-Minas

2 Bibliografia PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed., Rio de Janeiro: LTC - Livros Técnicos e Científicos, 2003, capítulos 1 e 5. PRESSMAN, Roger S. Engenharia de Software. 5ª ed., Rio de Janeiro: McGraw Hill, 2002, capítulo 10. IEEE. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004, capítulo 2. Transparências da professora Maria Augusta Vieira Nelson – PUC-Minas.

3 Engenharia de Requisitos Concentra-se em problemas e objetivos do mundo real; para estabelecer as funções que o cliente e usuários requerem de um sistema de software; e definir as restrições sob as quais ele opera e/ou é desenvolvido.

4 Engenharia de Requisitos Requisitos: são as descrições das funções e restrições do sistema de software; geradas durante o processo de Engenharia de Requisitos. são documentados em um documento denominado: Especificação dos Requisitos do Software.

5 Engenharia de Requisitos Uma boa engenharia de requisitos é um passo essencial; para o desenvolvimento de um bom produto. Requisitos bem entendidos e gerenciados; reduzem riscos na construção de um sistema de software.

6 Terminologia da Engenharia de Requisitos propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

7 Onde pode dar Errado? propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina No computador (muito raro) Causas: falha na energia falha nos dispositivos de hardware falha no sistema operacional falha na rede

8 Onde pode dar Errado? propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina No programa (não tão raro) Causas: erros de programação especificação mal entendida ausência de controle de mudanças Detecção: testes do programa em relação à especificação inspeções, walkthroughs

9 Onde pode dar Errado? propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina Na especificação (comum) Causas: requisitos mal entendidos escolha inadequada da linguagem de especificação especificação ambígua, inconsistente ou incompleta Detecção: inspeções, verificação formal

10 Onde pode dar Errado? propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina Nos requisitos (comum) Causas: comunicação insuficiente com o cliente/usuários ausência de análise falha ao lidar com as mudanças Detecção: inspeções, revisões feitas pelo cliente, modelagem, validação formal, prototipagem

11 Onde pode dar Errado? propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina Nas propriedades do domínio (muito comum) Causas: ausência de especialistas no domínio premissas que não foram questionadas análise do domínio insuficiente Detecção: comunicação com os especialistas que detêm a informação

12 Princípios da Engenharia de Requisitos Boas especificações de requisitos são indispensáveis. Não representam custos supérfluos; mas investimentos necessários. A participação dos usuários é fundamental; para que suas verdadeiras necessidades sejam atendidas. Uma boa especificação de requisitos; custa tempo e dinheiro. A ausência de uma boa especificação de requisitos; custa muito mais tempo e dinheiro.

13 Receitas para Reduzir Custos Fazer uma boa especificação de requisitos: para não ter que mudá-la durante o desenvolvimento; nada é mais caro do que resolver os problemas errados. Desenvolver adequadamente os requisitos do produto de software; ajuda a obter os requisitos corretos em um estágio anterior ao desenvolvimento; o custo de correção de defeitos cresce muito ao longo do tempo. minimiza a necessidade de alterações posteriores nos requisitos do produto; mas não a elimina. Se for preciso modificar requisitos: controlar as mudanças; por meio da gerência dos requisitos.

14 Engenharia de Requisitos Os processos utilizados durante a Engenharia dos Requisitos variam amplamente dependendo: do domínio da aplicação; das pessoas envolvidas; da organização que desenvolve os requisitos. Contudo, existem atividades genéricas comuns a todos os processos.

15 Engenharia de Requisitos Desenvolvimento de RequisitosGerência de Requisitos LevantamentoAnáliseDocumentaçãoValidação

16 Desenvolvimento de Requisitos Levantamento: coletar os requisitos do software. Análise: modelar o comportamento desejado. Documentação: documentar o comportamento do sistema de software proposto. Validação: verificar se a especificação atende aos requisitos do cliente e dos usuários.

17 Gerência de Requisitos Concentra-se nos processos envolvidos nas mudanças de requisitos do produto de software, já que, à medida que o projeto de desenvolvimento evolui: novos requisitos aparecem; requisitos existentes são alterados ou desaparecem. Procura manter sob controle os requisitos de um produto; mesmo diante dessas alterações.

18 Instabilidade dos Requisitos Ocorre quando clientes e usuários trazem novos requisitos, ou alterações em requisitos já especificados anteriormente; quando o desenvolvimento do software já está em fase adiantada. Acarreta: perda de tempo e dinheiro.

19 Instabilidade dos Requisitos Os requisitos podem alterar-se ao longo do projeto de desenvolvimento: descoberta de defeitos e inadequações nos requisitos originais; falta de detalhes suficientes nos requisitos originais; alterações incontornáveis no contexto do projeto; como mudanças na legislação.

20 Gerência de Requisitos – Principais Interesses Gerenciar mudanças nos requisitos aprovados. Manter a informação de rastreabilidade dos requisitos atualizada; auxilia a descobrir o impacto de uma mudança nos requisitos do produto.

21 Gerência de Requisitos – Diretrizes Delimitar o escopo do sistema. Definir as regras para o gerenciamento dos requisitos. Definir as regras de rastreabilidade. Definir as regras para a gerência de mudanças.

22 Rastreabilidade Um requisito é rastreável se: é possível identificar quais são as partes do produto que existem por causa dele; rastreabilidade para frente. para qualquer parte do produto; é possível identificar o requisito que causou sua existência; rastreabilidade para trás.

23 Rastreabilidade Através da rastreabilidade é possível identificar: os relacionamentos entre os requisitos; suas fontes; os artefatos criados durante o ciclo de vida do sistema; que são derivados do requisito.

24 Matriz de Rastreabilidade Projeto RequisitoR1R2R3R4 R1** R2* R3* R4 Relações entre os requisitos: R1 depende de R2; R1 especifica R2; acrescenta detalhes. R1 requer R2; requer o resultado de R2. R1 restringe R2.

25 Matriz de Rastreabilidade Projeto RequisitoCaso de Uso de Análise 1 Caso de Uso de Análise 2 Compo- nente 1 Caso de Teste 1 R1** R2** R3 R4*

26 Por quê Rastrear? Auxiliar a gerência do projeto; acompanhando a evolução dos requisitos; registrando sua situação. Auxiliar a gerência de mudanças; acompanhando como a alteração nos requisitos; pode impactar em mudanças nos diversos artefatos do projeto. Garantir a qualidade.

27 Regras para a Gerência de Mudanças Devem definir: o processo de requisição de mudanças; a informação necessária para processar cada requisição de mudanças; o processo usado para analisar o impacto e os custos da mudança e da informação associada com a mudança; o responsável por analisar a requisição de mudanças; ferramentas para registrar a situação da requisição de mudanças.


Carregar ppt "Engenharia de Requisitos Eveline Alonso Veloso PUC-Minas."

Apresentações semelhantes


Anúncios Google