Análise e Gerenciamento de Requisitos com Casos de Uso

Apresentação em tema: "Análise e Gerenciamento de Requisitos com Casos de Uso"— Transcrição da apresentação:

1 Análise e Gerenciamento de Requisitos com Casos de Uso
Módulo 2 Introdução ao Gerenciamento de Requisitos com Caso de Uso

2 Objetivos Definir os conceitos-chave da gerência de requisitos.
Identificar os fatores que contribuem para o sucesso ou falha do projeto. Descrever como o Gerenciamento de Requisitos aumenta as chances de sucesso do projeto. Definir as qualidades de um conjunto de requisitos. verificável, rastreável, não ambíguo. Conhecer o Workflow de gerência de requisitos com UP, papéis, e artefatos.

3 Algumas situações familiares…
Nós construímos tudo o que vc pediu! Certo, mas não é o que eu quero Por que vc não nos disse que queria aquela funcionalidade? Você não perguntou! Hummm... Eu acho que ele faz desse jeito! Eu tive uma idéia para uma função nova, você deixa a gente colocá-la no sistema? Sem problema!

4 Requisitos de Software Procedimentos de Teste
Visão Geral Problem Problema Domínio do Problema Necessidades Características Sistema a ser construído Domínio da Solução Requisitos de Software Rastreabilidade Procedimentos de Teste Design Docs do usuário

5 Definições Requisitos Gerenciamento de Requisitos
Uma necessidade do processo de negócio que o sistema deverá sanar. Gerenciamento de Requisitos Uma abordagem sistemática para: Detalhar, organizar, e documentar requisitos. Estabelecer e manter acordos entre cliente / usuário e equipe de projeto nas requisições de mudanças. Controlar e registrar a evolução do atendimento aos requisitos.

6 O que Requisitos de Software especificam?
Entradas Sistema Saídas Restrições de Design Funções Requisitos não funcionais (Ex.: Performance)‏ (Ex.: Ambientes)‏

7 Definições Requisições do Stakeholder Característica
Expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do steakholder. Característica Um serviço externamente observável, diretamente no sistema, que atende a um ou mais requisições do stakeholder. Requisitos de Software Requisito Funcional Descrição das funções que os steakholders precisam que o software faça. Definem a funcionalidade desejada do software. Requisito não funcional Qualidades técnicas globais de um software, como manutenibilidade, usabilidade, desempenho e várias outras. Normalmente são descritos de maneira informal, controversa, e são difíceis de validar. Restrição Uma limitação no design do sistema ou nos processos usados para construir o sistema.

8 Exemplo: Sistema de Matrícula
Requisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas. Característica Uma árvore de navegação para visualizar a grade de aulas, por semestre e por turma. Requisito de Software Funcional O caso de uso começa quando o estudante seleciona a opção de menu “Matricular”. O sistema apresenta uma lista de cursos disponíveis… Não-Funcional Disponibilidade de 99% dos 24/7(3.65 dias off-line por ano) Restrição Opera no Main Frame DEC VAX da Universidade.

9 Caracterização das Definições
Tipos de Requisitos Características Requisições do Stakeholder Requisitos de Software Restrições de Design Requisitos Funcionais Requisitos não funcionais Based on Leffingwell & Widrig, 1999

10 Requisitos existem em vários níveis
Necessidades do Stakeholder O que Como Características do Produto ou Sistema O que Como Requisitos de Software O que Como Especificação de Design Procedimentos de Teste Planos de Documentação

11 Gerência de Requisitos Não é Fácil
Nem sempre são óbvios. Vêm de várias fontes. Nem sempre é fácil de expressar claramente em palavras. São inter-relacionados e relacionados a outras entregas do processo de desenvolvimento de software. Tem propriedades únicas. Mudam. São difíceis de controlar quando em grande número.

12 Gerenciamento Requer Estratégia
RM Plan Handout

13 Gerenciamento Efetivo de Requisitos
Manter um claro estabelecimento dos requisitos requer: Boa qualidade dos requisitos Atributos aplicáveis para cada tipo de requisito Rastreamento para outros requisitos e outros artefatos do projeto O OBJETIVO é entregar produtos de qualidade, no tempo e no orçamento, que atendam às reais necessidades do usuário.

14 O que é um “Produto com Qualidade” ?
Qualidade: Velhos Conceitos Satisfaz os documentos de requisitos. Passa nos testes de sistema. Adere ao processo de desenvolvimento. Qualidade: Conceitos Modernos Entende todas as necessidades do usuário. Continuamente revisa todos os artefatos para garantir que atendem às necessidades.  Paradigma baseado em atividades  Paradigma baseado em Resultados

15 Dimensões de Qualidade
Componentes do FURPS+ F unctionality Conjunto de características, segurança, e requisitos em geral U sability Fatores humanos, estéticos, consistência, documentação R eliability (Confiabilidade) Frequência / severidade da falha, recuperabilidade, previsibilidade, MTBF (Mean Time Between Failures ) P erformance Velocidade, uso de recursos, processamento, tempo de resposta S upportability Testabilidade Extensível Adaptabilidade Manutenível Compatibilidade Configurável Disponibilidade Instalável Localizável Robustez

16 Quanto de trabalho nós podemos fazer?
“No Prazo e No Custo” Tempo Quanto de trabalho nós podemos fazer? Recursos $ Orçamento Scope Escopo

17 Atendendo às reais necessidades do cliente
Como sabemos quais são as necessidades? Característica 1: O sistema deve... Característica 2: O sistema deve Característica 3: O sistema deve Característica 4: O sistema deve Característica 5: O sistema deve Característica n: O sistema deve… Como determinar prioridade? O que é um baseline? Tempo Data de Início do Projeto Data-Alvo do Lançamento

18 Possibilitar acordo entre os envolvidos
O Objetivo Cliente Grupo de Usuários Sistema a ser construído Verificação Requisitos Objetivos de sistema Requisitos

19 Quais fatores contribuem para o sucesso do Projeto?
10. Outros aspectos 9. Estimativas confiáveis 8. Uso de métodos formais 7. Requisitos básicos firmes 6. Infra de Software padronizada 5. Escopo controlado 4. Objetivos Negociais claros 3. Gerente experiente 2. Envolvimento do Usuário 1. Suporte da Gerência Executiva Os Dez Motivos Fatores de Sucesso 28% dos projetos completados no prazo e custos. 49% dos projetos ultrapassam as estimativas iniciais. - Tempo estoura em média 63%. - Custo ultrapassa em média 45%. 23% dos projetos são cancelados antes de sua conclusão. Standish Group, ‘99 (

20 Tamanho é importante Sucesso pelo Tamanho do Projeto Taxa de Sucesso
10 20 30 40 50 60 Tamanho do Projeto ($) Menos de $750K $750K a $1.5M $1.5M a $3M $3M a $6M $6M a $10M Mais de $10M Taxa de Sucesso (%) Standish Group, ‘99 (

21 O alto custo dos Requisitos Errados
A regra do Em tempo de Requisitos .5 - 1 “Os resultados mostram como corrigir erros encontrados nos requisitos custa até 200 vezes menos do que em estágios mais avançados do ciclo de vida” Design 2.5 Codificação 5 10 Teste Unitário 25 Teste de Aceitação 100 Manutenção Custo relativo para reparar erros: Quando Introduzidos X Quando reparados. Boehm 1988

22 Ajuda para Projetos serem bem sucedidos
Análise dos Problemas Entender o Problema. Obter o entendimento com os stakeholders. Estabelecimento claro dos objetivos de negócio. Elicitação de Requisitos Identificar quem utilizará o sistema (atores). Elicitar como o sistema será usado (casos de uso). Gerenciamento de Requisitos Especificar os requisitos de forma completa. Gerenciar expectativas, mudanças, e erros. Controlar quebra de escopo. Listar todos os membros da equipe.

23 Qualidades do Conjunto de requisitos de software
Correto É a descrição correta sobre o que o sistema deve fazer. Completo Descreve todos os requisitos significantes para o contexto do negócio e do usuário. Consistente Não está em conflito com outros requisitos. Não ambíguo Está sujeito a apenas UM entendimento. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994

24 Qualidades do Conjunto de requisitos de software
Verificável Pode ser testado sem grandes custos. Classificável por importância e estabilidade Pode ser classificado por importância para o cliente e estabilidade do requisito em si. Modificável Mudanças não afetam a estrutura do todo. Rastreável A origem de cada requisito pode ser apontada. Claro Compreendido por usuários e desenvolvedores. Leffingwell & Widrig (1999). IEEE , § 4.3.2, 1994

25 Qualidades de um Requisito: Verificável
Um requisito é verificável se: É algo finito, em que uma pessoa ou máquina (com custo viável) pode checar se o produto atende ao requisito definido junto ao usuário. - O sistema suporta acima de 1000 usuários simultâneos. - O sistema deve responder a qualquer consulta em 500ms. - A cor deve ser um agradável verde sombreado. - O sistema deve estar disponível em 24 x 7. O sistema deve exportar visões dos dados em formato texto, separado por vírgula de acordo com o leiaute... Estes requisitos são verificáveis? Se não, qual o melhor modo de definí-los? IEEE , § 4.3.2, 1994

26 Qualidades de um requisito: Rastreável
Requisições do Stakeholder Características Casos de Uso Suplementar

27 Qualidades de um Requisito: Não ambíguo
O requisito é não ambíguo se tiver apenas uma interpretação. “A deve ir de B para C” Requisito A “A deve ir de B para C” “A deve ir de B para C” ref - IEEE 830

28 O que NÃO é um Requisito? Como realizar os requisitos.
Design Como realizar os requisitos. O Modelo de Design especifica componentes de um sistema ou suas interfaces com outros sub-componentes. Como saber se os requisitos estão sendo atendidos. Um caso de teste especifica uma forma de testar um cenário de caso de uso. Quando os requisitos atendem. O Plano de desenvolvimento de software especifica cronograma, planos de verificação e validação, e planos de gerenciamento de configuração. Verificação Dados de Projeto Adapted from Alan Davis

29 Artefatos Usados para Gerenciar Requisitos
Onde o problema é definido? Onde os stakeholders e usuários são listados? Onde os ambientes e plataformas são identificadas? Visão Onde os requisitos não funcionais estão localizados? Especificação Suplementar Onde os casos de uso são mantidos? Especificações de Caso de uso Onde o vocabulário comum está descrito? Glossário Onde as Necessidades e Requisições dos stakeholders são capturadas? Requisições do Stakeholder

30 Revisão: Introdução ao RMUC
O que é um Requisito? O que é Gerenciamento de Requisitos? Que fatores contribuem para o sucesso do projeto? Quais membros da equipe são envolvidos na Gerência de Requisitos e como? Saberia explicar a regra de ? Quais são algumas das qualidades dos requisitos? Quais são alguns dos tipos de requisitos não- funcionais? Por que usar UML? Por que usar um processo de desenvolvimento?