Análise e Validação dos Requisitos

Apresentação em tema: "Análise e Validação dos Requisitos"— Transcrição da apresentação:

1 Análise e Validação dos Requisitos
Alexandre Monteiro

2 Análise de Requisitos Definição e especificação de requisitos
Documento de requisitos 7 8 Validação dos requisitos Entendimento do domínio 6 Atrib. Prioridade Entrada do processo 1 5 2 4 Coleta de requisitos Resolução de conflito 3 Classificação

3 Entendimento do Domínio
Desenvolver sistemas envolve domínios além de software e hardware Podemos ter que entender sobre Contabilidade Saúde Supermercados Etc.

4 Coleta de Requisitos Como vimos anteriormente, a coleta de requisitos é feita através de técnicas Nesta etapa, os requisitos são simplesmente documentados à medida que são coletados Resulta em documento preliminar (draft)

5 Classificação dos Requisitos
Esta etapa consiste basicamente em agrupar os diversos requisitos coletados em categorias (clusters) bem-definidos Por exemplo Deve ser possível consultar o preço de uma mercadoria A consulta deve retornar uma resposta em no máximo 5s

6 Problema da Análise de Requisitos
Stakeholders em geral não sabem o que querem Stakeholders expressam requisitos em sua terminologia Stakeholders diferentes podem gerar requisitos conflitantes

7 Problema da Análise de Requisitos
Fatores políticos e organizacionais podem influenciar os requisitos do sistema Requisitos mudam durante o processo de análise. Stakeholders novos podem surgir e o ambiente de trabalho muda

8 Resolução de Conflitos
É normal que ocorram requisitos conflitantes Por exemplo R-23: O sistema deve ... R-45: O sistema não deve ... Cliente/usuário deve ser consultado para resolver conflitos (ambigüidades)

9 Atribuição de Prioridade
Alguns requisitos são mais urgentes que outros É essencial determinar a prioridade dos requisitos junto ao cliente Requisitos de maior prioridade são considerados em primeiro lugar

10 Prioridade Requisitos podem ser vistos em três classes distintas
Essenciais Importantes Desejáveis Em princípio, sistema deve resolver todos os requisitos de essenciais para desejáveis

11 Exemplo de Prioridade [RF001] Consulta X ao B.D. deve retornar dados A, B, C Prioridade: Essencial [RNF001] Consulta X ao B.D. deve visualizar dados segundo padrão Y Prioridade: Importante [RNF010] Consulta X ao B.D. deve usar cores azuis nos resultados Prioridade: Desejável

12 Validação dos Requisitos
Será que realmente entendi o que o cliente deseja? Devo me certificar de que não houve falha em nossa interação (comunicação) Há diversas técnicas de validação

13 Validação de Requisitos
Demonstrar que os requisitos definem o sistema que o cliente realmente deseja Custos com erros de requisitos são altos Consertar um erro de requisitos após entrega do sistema pode custar mais de 100 vezes o custo de um erro de implementação

14 Técnicas de Validação de Requisitos
Revisões de Requisitos Análise manual sistemática dos requisitos Prototipação Uso de modelo executável do sistema para avaliar requisitos Geração de Casos de Teste Desenvolver testes específicos para os requisitos para avaliá-los Análise de Consistência Automática Avaliar uma especificação dos requisitos

15 Gerenciamento de Requisitos
Gerenciamento de requisitos é o processo de controlar as mudanças dos requisitos durante O processo da engenharia de requisitos E desenvolvimento do sistema

16 Gerenciamento de Requisitos
Requisitos são inevitavelmente incompletos e inconsistentes Requisitos novos surgem durante o processo de acordo com mudanças nas necessidades do negócio e um entendimento melhor do sistema é desenvolvido Diferentes pontos de vista têm diferentes requisitos e esses geralmente são contraditórios

17 Rastreamento Responsável por dependências entre requisitos, suas origens e projeto do sistema Rastreamento de Origem Associação entre requisitos e stakeholders que propuseram tais requisitos

18 Rastreamento Rastreamento de Requisitos Rastreamento de Projeto
Associação entre requisitos dependentes Rastreamento de Projeto Associação dos requisitos com o projeto Usar hipertexto ou referência cruzada Ou matriz de rastreamento

19 Detalhados (Casos de Uso)
Rastreamento 1.Rastrear requisitos do usuário nos do sistema 2.Rastrear requisitos no projeto 3.Rastrear requisitos nos procedimentos de teste 4.Rastrear requisitos do usuário no plano Requisitos Produto (Caracter.) Req A 1 Requisitos Detalhados (Casos de Uso) Req B Based on this structure, we then need to set up traceability links between all associated requirements or other project elements. 2 3 4 Projeto Teste Doc. Usuário Modelos Suítes Teste Plano

20 Rastreamento: Análise de Impacto
RequisitePro provides what are called “suspect links”, which notify that an associated requirement has changed. All directly related requirements should be reviewed to assess whether they are impacted. Why is the link from Req B to Req C not marked as suspect? Because it will only go suspect if B actually changes. The only way to resolve these are manually (by actually looking at the changes and the affected requirements). You can probably make a *lot* of money if you could figure out a way to do this automatically (joke). Req A antes “if return value > $5” Req B Req C “if return value > $2” Req A depois RequisitePro provides what are called “suspect links”, which can notify that an associated requirement has changed. All directly related requirements should be reviewed to assess whether they are affected. Why is the link from Req B to Req C not marked as suspect? The only way to resolve suspect links are manually (by actually looking at the changes and the affected requirements). Links dos requisitos devem ser marcados como “revisar” Links “revisar” devem ser analisados

21 Estrutura de um Documento de Requisitos
1. Introdução 2. Definição dos Requisitos do Usuário 3. Especificação dos Requisitos do Sistema 4. Arquitetura do Sistema 5. Modelos do Sistema 6. Evolução do Sistema 7. Apêndices 8. Índice

22 Documento de Requisitos
Fonte: IEEE/ANSI ( ) 1. Introdução 1.1 Propósito do documento 1.2 Escopo do sistema 1.3 Glossário, acrônimos e abreviaturas 1.4 Referências 1.5 Descrição do resto do documento

23 Documento de Requisitos
Fonte: IEEE/ANSI ( ) 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 Assertivas e dependências

24 Documento de Requisitos
Fonte: IEEE/ANSI ( ) 3. Requisitos específicos requisitos funcionais, não-funcionais, GUI com o usuário: funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, caract. qualidade, ...

25 Documento de Requisitos
4. Arquitetura do Sistema 5. Modelos do Sistema Diagrama de Atores Modelo de Caso de Uso Modelo de Análise Modelo de Projeto Diagrama de Pacotes 6. Evolução do Sistema (Futuro) 7. Apêndices 8. Índice

26 Abreviações e Glossário
Abreviação Significado Explicação / Condição ou situação no sistema A Administrador Usuário com maiores privilégios no sistema AT Auto-treinamento Um dos três perfis de avaliação. O operador/treinando solicita ao sistema uma avaliação que lhe é montada de modo randômico a partir de alguns parâmetros CT Certificação Técnica Um dos três perfis de avaliação. Os supervisores (RL/RS) agendam com antecedência dia e hora da avaliação. É o teste que certifica o treinando/operador. O Operador Usuário. Treinando que realiza as avaliações. RL Responsável Local Usuário. Responsável, na unidade da empresa, por um grupo de operadores. Propõe, elimina e valida questões e avaliações. RS Responsável Setorial Usuário. Responsável por um setor da empresa. Coordena um ou mais RL. Propõe, elimina e valida questões e avaliações. TO Treinamento Orientado Um dos três perfis de avaliação. Serve para os RS/RL diagnosticarem o estágio da aprendizagem dos operadores. V Validador Usuário. Checa e valida as questões propostas pelos RS/RL. M Módulo Refere-se aos módulos do sistema. Backup Refere-se à cópia de dados de um dispositivo para o outro com o objetivo de posteriormente os recuperar (os dados), caso haja algum problema. Logon É a ação necessária para acessar um sistema computacional restrito inserindo uma identificação, podendo esta ser ou não única para cada usuário, e a senha relacionada a ela. Uma vez logado, o usuário passa a ser identificado no sistema, sendo restringido ou permitido a acessar recursos do sistema.