Análise e Gerenciamento de
Requisitos com Casos de Uso
Módulo 2
Introduçã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
Hummm...
Eu acho que
ele faz desse
jeito!
Por que vc não
nos disse que
queria aquela
funcionalidade?
Você não
perguntou!
Eu tive uma idéia para uma
função nova, você deixa a
gente colocá-la no sistema?
Sem problema!
Visão Geral
Domínio do
Problema
Problem
Problema
Necessidades
Características
Requisitos de
Software
Procedimentos de
Teste
Sistema a
ser
construído
Domínio da
Solução
Rastreabilidade
Design
Docs do
usuário
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
Sistema
Saídas
Restrições de Design
Funções
Requisitos não
funcionais
(Ex.: Performance)
(Ex.: Ambientes)
Definições
Requisições do Stakeholder
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.
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.
Caracterização das Definições
Tipos de
Requisitos
Requisitos de
Software
Características
Requisições
do Stakeholder
Restrições de
Design
Requisitos
Funcionais
Requisitos não
funcionais
Based on Leffingwell &
Widrig, 1999
Requisitos existem em vários níveis
O que
Como
O que
Como
Necessidades do
Stakeholder
Características do Produto ou
Sistema
Requisitos de Software
O que
Como
Especificação de Design
Procedimentos de Teste
Planos de Documentação
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.
 Paradigma baseado em atividades
• 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
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
“No Prazo e No Custo”
Quanto de
trabalho nós
podemos fazer?
Recursos
Escopo
Scope
Scope
Scope
Orçamento
Tempo
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
Possibilitar acordo entre os envolvidos
O Objetivo
Cliente
Grupo de Usuários
Sistema a ser
construído
Verificação
Requisitos
Objetivos de
sistema
Requisitos
Quais fatores contribuem para o sucesso do Projeto?
Os Dez Motivos
1. Suporte da Gerência
Executiva
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.
2. Envolvimento do Usuário
3. Gerente experiente
4. Objetivos Negociais claros
5. Escopo controlado
6. Infra de Software
padronizada
7. Requisitos básicos firmes
8. Uso de métodos formais
9. Estimativas confiáveis
10. Outros aspectos
Standish Group, ‘99 (www.standishgroup.com)
Tamanho é importante
Sucesso pelo Tamanho do Projeto
60
50
Taxa de
Sucesso
(%)
Menos de $750K
$750K a $1.5M
$1.5M a $3M
$3M a $6M
$6M a $10M
Mais de $10M
40
30
20
10
0
Tamanho do Projeto ($)
Standish Group, ‘99 (www.standishgroup.com)
O alto custo dos Requisitos Errados
A regra do 1-10-100
Em tempo de Requisitos
“Os resultados
Design
mostram como
2.5
corrigir erros
Codificação
5
encontrados nos
Teste Unitário
10
requisitos custa até
200 vezes menos do
Teste de Aceitação
25
que em estágios mais
Manutenção
100
avançados do ciclo de
vida”
Custo relativo para reparar erros:
.5 - 1
Quando Introduzidos X Quando reparados.
Boehm 1988
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
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 830-1993, § 4.3.2, 1994
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 830-1993, §
4.3.2, 1994
Qualidades de um requisito:
Rastreável
Requisições do Stakeholder
Características
Casos de Uso
Suplementar
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”
“A deve ir de B para C”
“A deve ir de B para C”
ref - IEEE 830
O que NÃO é um Requisito?
Design
Verificação
Dados de
Projeto
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.
Adapted from Alan Davis
Artefatos Usados para Gerenciar Requisitos
Onde o problema é definido?
Visão
Onde os stakeholders e usuários são listados?
Onde os ambientes e plataformas são identificadas?
Onde os requisitos não funcionais
estão localizados?
Onde os casos de uso são mantidos?
Especificação
Suplementar
Especificações de
Caso de uso
Onde o vocabulário comum está descrito?
Onde as Necessidades e Requisições
dos stakeholders são capturadas?
Glossário
Requisições do
Stakeholder
Revisão: Introdução ao RMUC
1.
2.
3.
4.
5.
6.
7.
8.
9.
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 1-10-100?
Quais são algumas das qualidades dos requisitos?
Quais são alguns dos tipos de requisitos nãofuncionais?
Por que usar UML?
Por que usar um processo de desenvolvimento?