Engenharia de Requisitos

Apresentação em tema: "Engenharia de Requisitos"— 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
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 Propriedades do domínio da aplicação são todos os fatos que são verdadeiros a respeito do negócio do cliente, independentemente de construírmos o sistema proposto. Requisitos expressam os fatos que nós queremos que sejam verdade quando o sistema proposto for instalado no domínio do cliente. Os requisitos servem para validar todos os outros artefatos do sistema que vão ser construídos ao longo do seu desenvolvimento. A especificação do sistema é uma descrição do comportamento que o programa deve ter, para satisfazer os requisitos. A especificação é a ponte que liga o mundo do cliente ao mundo da máquina. É a descrição em mais alto nível do sistema proposto. É através de refinamentos na especificação que se chega ao programa. Dois critérios que verificam se o programa está correto: - O programa sendo executado em um determinado computador satisfaz a especificação. A especificação dentro do contexto das propriedades do domínio da aplicação do cliente satifaz os requisitos. Por exemplo: Requisito: O histórico escolar deve conter todas as notas de apenas um aluno. Propriedades do domínio: Cada aluno é identificado por um número de matrícula único ou dois alunos não possuem o mesmo número de matrícula. Especificação: O sistema deve ler um número de matrícula de aluno e imprimir todas as notas associadas a este número de matrícula.

7 Onde pode dar Errado? 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 propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

8 Onde pode dar Errado? 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 propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

9 Onde pode dar Errado? 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 propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

10 Onde pode dar Errado? 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 propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

11 Onde pode dar Errado? 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 propriedades do domínio requisitos do cliente computador programa especificação domínio da aplicação domínio da máquina

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 Requisitos Gerência de Requisitos Levantamento Análise Documentação Validaçã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
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. Matriz de Rastreabilidade Projeto <nome do projeto> Requisito R1 R2 R3 R4 *

25 Matriz de Rastreabilidade
Projeto <nome do projeto> Requisito Caso 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.