Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de...
Transcript of Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 2 Introdução ao Gerenciamento de...
Análise e Gerenciamento de Requisitos com Casos de Uso
Módulo 2Introdução ao Gerenciamento de
Requisitos com Caso de Uso
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.
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!
Visão Geral
Sistema a ser
construído
Necessidades
Requisitos de Software
DesignProcedimentos de Teste
Docs do usuário
Características Domínio da Solução
Domínio do Problema
Rastreabilidade
ProblemProblema
Definições
• 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.
O que Requisitos de Software especificam?
Entradas Saídas
Funções
Requisitos nãofuncionais(Ex.: Performance)
Restrições de Design
(Ex.: Ambientes)
Sistema
DefiniçõesRequisições do StakeholderExpressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do steakholder.
Requisitos de SoftwareRequisito FuncionalDescrição das funções que os steakholders precisam que o software faça. Definem a funcionalidade desejada do software.Requisito não funcionalQualidades 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çãoUma limitação no design do sistema ou nos processos usados para construir o sistema.
CaracterísticaUm serviço externamente observável, diretamente no sistema, que atende a um ou mais requisições do stakeholder.
Exemplo: Sistema de MatrículaRequisição do Stakeholder Precisa de menor despesa geral no registro. Professores precisam de acesso imediato a grade de aulas.
RestriçãoOpera no Main Frame DEC VAX da Universidade.
Requisito de SoftwareFuncionalO 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-FuncionalDisponibilidade de 99% dos 24/7(3.65 dias off-line por ano)
CaracterísticaUma árvore de navegação para visualizar a grade de aulas, por semestre e por turma.
Caracterização das Definições
Based on Leffingwell & Widrig, 1999
Requisitos de Software
Restrições de Design
Requisitos Funcionais
Requisitos não funcionais
Tipos de Requisitos
Requisições do Stakeholder
Características
O queComo
Necessidades do Stakeholder
Características do Produto ou Sistema
Requisitos de Software
Especificação de Design Procedimentos de Teste Planos de Documentação
Requisitos existem em vários níveis
O queComo
O queComo
Gerência de Requisitos Não é Fácil• Requisitos:
– 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.
Gerenciamento Requer Estratégia
RM Plan
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.
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 Resultados Paradigma baseado em Resultados
Paradigma baseado em atividades Paradigma baseado em atividades
Dimensões de Qualidade
Componentes do FURPS+
FFunctionality Conjunto de características, segurança, e requisitos em geral
UU sability Fatores humanos, estéticos, consistência, documentação
RR eliability(Confiabilidade) Frequência / severidade
da falha, recuperabilidade, previsibilidade, MTBF (Mean Time Between Failures )
PPerformance Velocidade, uso de recursos, processamento, tempo de resposta
SS upportability
Testabilidade Extensível Adaptabilidade ManutenívelCompatibilidade Configurável
Disponibilidade InstalávelLocalizável Robustez
“No Prazo e No Custo”
Tempo
Quanto de trabalho nós
podemos fazer?
Recursos
Orçamento
ScopeScopeScopeEscopo
Atendendo às reais necessidades do cliente
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?
Como sabemos quais são as necessidades?
TempoData de Início
do ProjetoData-Alvo do Lançamento
Possibilitar acordo entre os envolvidos
Objetivos de sistema
VerificaçãoRequisitos
ClienteGrupo de Usuários
Sistema a ser construído
Requisitos
O Objetivo
Quais fatores contribuem para o sucesso do Projeto?
10. Outros aspectos9. Estimativas confiáveis8. Uso de métodos formais7. Requisitos básicos firmes
6. Infra de Software padronizada
5. Escopo controlado4. Objetivos Negociais claros
3. Gerente experiente2. Envolvimento do Usuário
1. Suporte da Gerência Executiva
Os Dez Motivos
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.
Fatores de Sucesso
Standish Group, ‘99 (www.standishgroup.com)
Tamanho é importante
Taxa deSucesso
(%)
Standish Group, ‘99 (www.standishgroup.com)
Sucesso pelo Tamanho do Projeto
0
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
O alto custo dos Requisitos Errados
Custo relativo para reparar erros: Quando Introduzidos X Quando reparados.
100
2.5
5
10
25
.5 - 1Em tempo de Requisitos
Design
Codificação
Teste Unitário
Teste de Aceitação
Manutenção
“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”
Boehm 1988
A regra do 1-10-100
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.
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 830-1993, § 4.3.2, 1994
• 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 830-1993, § 4.3.2, 1994
Qualidades do Conjunto de requisitos de software
IEEE 830-1993, § 4.3.2, 1994
- 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...
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.
Estes requisitos são verificáveis?Se não, qual o melhor modo de definí-los?
Qualidades de um requisito: Rastreável
Requisições do Stakeholder
Características
SuplementarCasos de Uso
ref - IEEE 830
“A deve ir de B para C”
“A deve ir de B para C”
“A deve ir de B para C”
Qualidades de um Requisito: Não ambíguo
• O requisito é não ambíguo se tiver apenas uma interpretação.
Requisito A
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.
Design
Adapted from Alan Davis
O que NÃO é um Requisito?
Verificação
Dados deProjeto
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?
Onde os casos de uso são mantidos?
Onde o vocabulário comum está descrito?
Visão
Especificações de Caso de uso
Glossário
Especificação Suplementar
Onde os requisitos não funcionais estão localizados?
Onde as Necessidades e Requisições dos stakeholders são capturadas?
Requisições do Stakeholder
Revisão: Introdução ao RMUC1. O que é um Requisito?2. O que é Gerenciamento de Requisitos?3. Que fatores contribuem para o sucesso do projeto?4. Quais membros da equipe são envolvidos na
Gerência de Requisitos e como?5. Saberia explicar a regra de 1-10-100?6. Quais são algumas das qualidades dos requisitos?7. Quais são alguns dos tipos de requisitos não-
funcionais?8. Por que usar UML?9. Por que usar um processo de desenvolvimento?