Curso de Requisitos
Módulo 03: Requisitos de Software
Requisitos de Software, Técnicas de
Levantamento, Identificação dos Problemas,
Necessidades e Principais Artefatos
Introdução à Gerencia de Requisitos: Visão Geral
Problem
Problema
Domínio do
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
–A condição ou capacidade que o sistema
deve possuir.
• 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.
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
Uma expressão independente de solução de um estado desejado pelo
stakeholder da solução ou sujeito ao domínio.
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
Um requisito que especifica, de uma perspectiva caixa-preta, como
uma solução que interage com o mundo externo.
Requisito não funcional
Um requisito que expressa, de uma perspectiva caixa-preta, os
atributos de qualidade da solução.
Restrição
Uma limitação no design do sistema ou nos processos usados para
construir o sistema.
Exemplo de um Sistema de Registro em Curso
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 de visualizar a grade de aulas, por semestre
e por turma.
Requisito de Software
Funcional
O caso de uso começa quando o estudante seleciona o comando
“register for course”. 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 porque…
• Requisitos:
–Nem sempre são óbvios.
–Vem de várias fontes.
–Nem sempre é fácil de expressar claramente em
palavras.
–São interelacionados e relacionados a outras
entregas do processo de desenvolvimento de
software.
–Tem propriedades únicas ou valores de
propriedade.
–Mudam.
–São difíceis de controlar quando em grande
número.
Gerenciamento Requer Estratégia
RM Plan
RUCS10:
RM Plan
Gerenciamento de Requisitos efetivo
• 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
As 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
Frequência/severidade da falha,
recuperabilidade, previsibilidade,
acurária, MTBF
P erformance
Velocidade, uso de recrusos, throughput,
tempo de resposta
S upportability
Testabilidade
Extensível
Adaptabilidade Manutenível
Compatibilidade Configurável
Disponibilidade Instalável
Localizável
Robustez
On Time and On Budget
Quanto de
trabalho nós
podemos fazer?
Recursos
Escopo
Scope
Scope
Scope
Orçamento
Tempo
Atendendo as 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 6: O sistema deve
Característica 7: 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 um acordo entre os
envolvidos
O Objetivo
Cliente
Grupo de Usuários
Sistema a ser
construído
Verificação
Requisitos
Objetivos de
sistema
Requisitos
Adapted from Al Davis
Quais fatores contribuem para o
sucesso do Projeto?
Os Dez Motivos
1. Suporte da Gerência
Fatores de Sucesso
Executiva
2. Envolvimento do Usuário
 28% dos projetos são completados
3. Gerente experiente
no orçamento e prazo.
4. Objetivos Negociais claros
 49% dos projetos ultrapassam
5. Escopo controlado
as estimativas iniciais.
6. Infra de Software
padronizada
- Tempo estoura em média 63%.
- Custo ultrapassa em média 45%. 7. Requisitos básicos firmes
8. Uso de métodos formais
 23% dos projetos são cancelados
9. Estimativas confiáveis
antes de sua conclusão.
10. Outros aspectos
Standish Group, ‘01 (www.standishgroup.com)
Tamanho é importante
Sucesso pelo Tamanho do Projeto
60
50
Taxa de
Sucesso
(%)
less than $750K
$750K to $1.5M
$1.5M to $3M
$3M to $6M
$6M to $10M
Over $10M
40
30
20
10
0
Standish Group, ‘99 (www.standishgroup.com)
Project Size ($)
O alto custo dos Requisitos Errados
A regra do 1-10-100
.5 - 1
2.5
5
10
25
100
Em tempo de Requisitos
Design
Codificação
Teste Unitário
Teste de Aceitação
Manutenção
Custo relativo para reparar erros:
Quando Introduzidos X Quando reparados.
“All together, the
results show as
much as a 200:1
cost ratio between
finding errors in the
requirements and
maintenance stages
of the software
lifecycle.”
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.
Envolvendo toda a Equipe com
os Requisitos
• Desenvolvedores, Testadores, e Autores
–Ajuda a desenvolveder as práticas de
gerenciamento de requisitos.
–Monitora a aderência às boas práticas.
–Verifica o processo de elicitação.
–Documenta requisitos.
–Participa das revisões sobre os requisitos.
–Participa como membro do Comitê de Controle
de Mudanças (CCM).
–Revisa as matrizes de rastreabilidade.
–Verifica qualidade, testabilidade, e completude.
O resultado é pior quando a
qualidade é baixa
?
?
?
?
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.
Qualidades do Conjunto de
Requisitos (cont.)
• 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 IEEE.
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?
Como realizar os requisitos.
Design
O Modelo de Design espefica componentes de um
sistema ou suas interfaces com outros subcomponentes.
Como saber se os requisitos
estão sendo atendidos.
Verificação
Um Test Suite contém um conjunto de scripts de teste e
logs de teste.
Quando os requisitos atendem.
Dados de
Projeto
O Plano de desenvolvimento de software especifica
cronograma, planos de verificação e validação, e planos
de gerenciamento de configuração.
RUP: Um Framework para
Gerência de Requisitos
Disciplina de Requisitos:
Detalhes do Workflow
Papéis e Artefatos
Quais artefatos são usados
Onde o problema é definido?
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?
Onde o vocabulário comum está descrito?
Onde as Necessidades e Requisições
dos stakeholders são capturadas?
Visão
Especificação
Suplementar
Especificações de
Caso de uso
Glossário
Requisições
do
Stakeholder
Onde estamos na disciplina de Requisitos?
Análise do Problema: Atividades e Artefatos
Análise do Problema
• É o processo de entender os problemas
do mundo real, e como eles se relacionam
com as necessidades dos stakeholders, e
propor soluções para atender a estas
necessidades.
• Qual o objetivo da Análise de Problemas?
–Ter um melhor entendimento antes de
começar o desenvolvimento.
–Identificar as causas-raiz.
–Ajudar na identificação da solução.
• Evitar o: “Sim, mas…”
–Minimizar o trabalho extra.
Qual o problema
real?
Definição do Problema
Um problema pode ser definido como uma
diferença entre as coisas como são percebidas e
como são desejadas.
(Problema)
Percebido
Desejado
Passos para a Análise do Problema
• Identificar os stakeholders.
• Entender as causas-raiz.
• Chegar a um entendimento sobre os
problemas.
• Identificar as restrições do sistema e do
projeto.
• Identificar e validar a solução em relação as
causas-raiz.
• Definir a fronteira (escopo) do sistema.
Roadmap da Análise de Problemas
Problema
de
Negócio
Identifique stakeholders para o
problema.
Análise da Causa-Raiz.
Problema de Negócio
Definido
Idéia de
Solução ou
Oportunidade
Problema Atual
identificado e definido
Entendimento dos
Problemas no
Contexto dos
Objetivos de Negócio.
Problema validado/ajustado
Escolher as melhores
soluções para alcançar os
objetivos.
Reavaliar qual é a melhor
idéia de solução.
Melhor solução
identificada
Expandir a lista de
soluções do
stakeholder.
Elicitar
Requisitos
Stakeholders: Definições
• Stakeholder
–Um indivíduo que é materialmente afetados
por uma saída do sistema ou do projeto que
está produzindo o sistema.
• Representante do Stakeholder
–Um stakeholder representa um ou mais
stakeholders. Eles estão diretamente
envolvidos na direção, concepção, e no
escopo do projeto.
Identificar os Stakeholders
• Cada grupo de stakeholders precisa de um
representante.
• Nem todos os grupos de stakeholders
precisam ser consultados.
–Vários irão fornecer os requisitos.
• Clientes, usuários, administradores do sistema
–Vários podem não fornecer requisitos.
• Acionistas da empresa
Quem destes são stakeholders nos seus projetos?
Descrever Stakeholders no
Documento de Visão
Stakeholder
Representante
Descrição
Tipo
Responsabilidades
Critério de
Sucesso
Envolvimento
Entregas
Comentários/
Preocupações
Digitador
Kelly Hansen
Usuário
O digitador é tipicamente um técnico com conhecimentos
em informática. O digitador é treinado e experiente no uso
do atual sistema batch de registro.
O digitador é responsável por administrar o cadastro de
cursos para cada período letivo. Isto inclui a supervisão
administrativa e de permissão de acesso aos dados.
Conseguir manter o banco de dados de estudantes e
professores, e abrir/fechar cursos para matrícula.
A responsabilidade primária dos digitadores será manter o
banco de dados de estudantes e professores, e
abrir/fechar cursos para matrícula.
Também será requerido da área de matrículas….
Gestor de Revisão – especialmente nas funcionalidades
requisitadas pela área de Matrículas.
Nenhum
Quais problemas estão por trás
dos problemas?
Técnicas do Diagrama de Espinha de Peixe
Problema de
negócio que foi
percebido.
Clientes
insatisfeitos
com nossos
serviços.
Liste as causas que contribuem para o problema detectado.
Continue perguntando “Por que?” (expanda cada raia).
Análise do Problema – Validando a solução
Técnicas do Diagrama de Espinha de Peixe
Solução
percebida para
os problemas.
Mais Máquinas
de Auto
Atendimento.
Liste as razões que justificam a solução.
Continue perguntando “Por que?” (expanda cada raia).
Foco nos que mais contribuem – Lei de
Pareto
20% do esforço
originam em 80%
de benefício.
Benefício
80%
20%
Esforço
Classifique por ordem. Use a regra do 80-20 para focar nas principais
causas responsáveis pelas grandes porções de problema.
Compreender o contexto maior
do problema
• A falta de entendimento do negócio e seus
objetivos aumenta o risco.
• O problema está em algum componente
do processo/empresa?
• A equipe entende qual o domínio do
problema?
• A solução do problema cria oportunidades
de melhoria do processo?
Disciplinas de Modelagem de
Negócio e Requisitos
Modelagem de Negócio
Requisitos
Modelos de Negócio
• Modelo de Organização estrutural e
dinâmico.
–Processos de Negócio
–Estrutura Organizacional
–Papéis e responsabilidades
•
•
•
•
 Produtos
 Entregas
 Eventos
Visualize a organização e seus negócios.
Ajude a entender os problemas atuais.
Identifique potenciais melhorias.
Derive e valide os requisitos de sistema
necessários à Organização.
Descrever o problema no Documento de Visão
Definição do
Problema
Requisições
do
Stakeholder
Documento de
Visão
Modelo de
Caso de Uso
Especificações de
Design
Especificação
Suplementar
Especificações de
Manual do Usuário
Documento de Visão
• As mesmas informações para gerência,
marketing, e equipe de projeto.
• Fornece o feedback inicial do cliente.
• Promove uma compreensão única do
produto.
• Define escopo e prioridade em alto-nível
das requisições do stakeholder e suas
características.
• Um documento em nível de sistema que
descreve o “que” e “porquê” do produto.
Visão
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Estrutura do Documento de
Visão
Introdução
Posicionamento
Descrições do Stakeholder e Usuário
Visão Geral do Produto
Características do Produto
Restrições
Faixas de Qualidade
Precedência e Prioridade
Outros Requisitos do Produto
Requisitos de Documentação
Anexo 1 – Atributos das Características
Obtendo o Entendimento do Problema
Descrição do Problema
O problema de
(descreva o problema)
afeta
(os stakeholders afetados pelo
problema)
O impacto disto é (qual o impacto do problema)
que
Uma solução de (listar vários benefícios-chave de
sucesso seria
negócio para uma solução de sucesso)
Visão
Identificar as Restrições
De ambiente
Econômicas
Políticas
Técnicas
Viabilidade
Sistêmicas
Identificar as melhores soluções
de negócio
• Identificar as várias soluções para os
problemas principais.
–Técnico, não-técnico, ou ambos.
• Escolher a que:
–Melhor resolve as causas-raiz.
–Suporta os objetivos de negócio.
• Obter os requisitos que permitem
implementar a solução.
Definir a fronteira da solução de
Outros
sistema
sistemas
Usuários
Novo Sistema
Manutenção
Comunicações
Sistemas
Legados
Relatórios
Atores ajudam a definir a fronteira do sistema
Fronteira do sistema?
PC
PC
Servidor
Servidor
PC
PC
PC
Usuário
Quem é o ator? Os módulos do
sistema ou o usuário?
Capturando o Vocabulário comum do sistema
• Definir os termos usados no projeto.
• Ajudar a previnir mal-entendidos.
Capturar o Vocabulário Comum
• Começar o mais cedo possível.
• Continua durante todo o projeto.
Glossário
Visualize o Glossário como um
modelo de Domínio
Cliente
1..2
1..* Acao Cliente. 1
Transacao geral
*
Limite Credito
Transacao
Transferencia
Entender Necessidades: Atividades e
Artefatos
Quais são as fontes de Requisitos?
Especif. de Requisitos
Modelo de Negócio
Planos de Negócio
Objetivos Pessoais
Parceiros
Cliente
Usuários
Requisições Iniciais
Relatórios de Erro
Mudanças de Requisito
Analista
Domínio do
Problema
Visitas ao Site
Experts no Negócio
Analistas de Mercado
Infos Competitivas
Como é o Processo?
Requisitos Ad-hoc vindos de um cliente
Cliente
Especificação de Requisitos
Rejeitado pelo cliente
Especificação corrigida
Rejeitada Novamente
Especificação corrigida
Aprovado pelo Cliente
Membro
do Projeto
Quais problemas podem ser encontrados?
• Stakeholders
– Tem uma idéia pré-concebida da solução.
– Não sabem exatamente o que querem.
– Não conseguem articular o que querem.
– Pensam que sabem o que querem, mas não
reconhecem o que sugeriram quando da entrega.
• Analistas
– Eles acham que entendem mais
sobre os problemas do usuário
do que o próprio usuário.
??
• Todo mundo
– Todo mundo vê as coisas sob
seu ponto de vista.
– Todo mundo é
politicamente motivado.
Stakeholder
Analista
Expressando as Requisições do Stakeholder
STRQ
STRQ
O Artefato de Requisição do Stakeholder
• Vem dos stakeholders.
• Tem todas as requisições do
stakeholders.
• É consolidado de várias fontes.
Requisições do
Stakeholder
– E-mail, especificação de requisitos do
cliente, guardanapos, quadro branco,
planilhas, e etc.
• Usados pelos membros do projeto
para criar requisitos e
funcionalidades do sistema.
• Pode conter referências para
qualquer tipo de fonte externa.
Documento
de Visão
Modelo de
Caso de Uso
Espec.
Design
Esp.
Supl.
Docs do
Usuário
Técnicas para Elicitar Requisições do
Stakeholder
• Revisar especificações de requisitos do
cliente
• Workshop de Requisitos
•
•
•
•
•
–Workshops de Casos de Uso
–Brainstorming e redução de idéias
Entrevistas
Questionários
Role playing
Protótipos
Storyboards
Revisar as Especificações do
Cliente
• Identificar Requisitos.
–Reconhecer e rotular:
• Comportamentos da Aplicação
• Atributos comportamentais
• Questões e Suposições
• Perguntar ao cliente.
Revisão dos Requisitos
Brainstorming
• Produza o maior número de idéias
possíveis.
Regras do Brainstorming
 Esclareça o objetivo da sessão.
 Gere o maior número de idéias
possíveis.
 Deixe a imaginação voar.
 Não permita críticas ou debates.
 Mescle idéias.
Brainstorming: Vantagens e
Desvantagens
• Vantagens
–Usado a qualquer tempo, em qualquer lugar.
–Bom para grupos.
–Bom para coisas de alto-nível e
pressuposições.
–Bom para algum nível de automação.
• Desvantagens
–Se aplica mais a processos em grupo.
–Não sistemática na forma “clássica”.
Redução de Idéias: Podar e
organizar
Afine Diagramas
Redução de Idéias: Priorize Idéias
• Priorize idéias restantes.
–Vote
• Votos cumulativos
– Compre idéias
• Voto único
–Aplique avaliações
– Critério
• Não ponderado
• Ponderado
Rational University “bucks”
Definição do Sistema: Atividades e Artefatos
Posicionamento do Produto
• Comunica a intenção e importância.
Para
(cliente alvo)
Que
O (nome do
produto)
(declare oportunidade e necessidade)
Que
(estabeleça os benefícios, que levaria a
investir no produto)
É um (tipo de produto)
Diferentemente (concorrente)
Nosso
(diferença para o concorrente)
produto
Dica: Use declaração do problema como ponto de partida.
Capture os Requisitos de Software
Requições do
Stakeholder
Requisições de
Stakeholders
Requisições Chave
do Stakeholder
e Características
Documento de
Visão
Requisitos
de Software
Modelo de CSU
Especificação de
Projeto
Especificação
Suplementar
Especificações de
Documentação do
Usuário
Passos para criar o Modelo de Casos de Uso
1. Identifique atores e casos de uso.
- Descrição Breve.
2. Rabisque cada caso de uso.
- Fluxo básico de Eventos.
- Fluxos alternativos.
3. Detalhe cada caso de uso.
- Detalhe os fluxos de eventos.
- Estruture cada fluxo do CSU.
- Adicione Detalhes.
Condições Pré e Pós, requisitos especiais, relacionamentos,
diagramas de caso de uso, e etc.
Exemplo de Diagrama
Efetuar
Negociação
Conta
Gerenciar
Portfolio
Rede
Financeira
Sistema de
Cotações
Obter
Cotação
Executar
Negociação
Cliente de
Negociação
Sistema de Negociação
na Bolsa
Distribuir
Notícias
Sistema de Notícias
Operador
Rever Conta
Agendador
Esboço de cada caso de uso
Nome do Caso de Uso
Numerar
os passos
Descrição Breve
Fluxo Básico
1. Primeiro Passo
2. Segundo Passo
3. Terceiro Passo
A1 Fluxo Alternativo 1
A2 Fluxo Alternativo 2
A3 Fluxo Alternativo 3
Estruturar
o fluxo em
passos
Porque esboçar casos de uso?
Esboço
Tamanho do Caso de Uso
Muito Peq.? Muito Grande?
É mais de um
caso de uso?
?
?
Caso de Uso
?
Esboçar ajuda a identificar
fluxos alternativos
Fluxo de Eventos (Básico e
Alternativo)
• Um fluxo básico
–Cenário do Caminho Feliz
–Cenário de sucesso do início ao fim.
• Vários fluxos alternativos
–Variantes regulares
–Casos ímpares
–Fluxos excepcionais (erros)
Fluxo: um conjunto de passos seqüenciais.
Representando fluxos básicos e
alternativos
Passo 1
A5
A2
Pas. 2
A1
A3
A4
Passo 3
Passo 4
<Nome do Caso de Uso>
1. Descrição Breve
2. Fluxo de Eventos
2.1 Fluxo Básico
Passo 1
Passo 2
Passo 3
Passo 4
2.2 Fluxos Alternativos
2.2.1 A1 …
2.2.2 A2 …
2.2.3 A3 …
2.2.4 A4 …
2.2.5 A5 …
O que é um cenário?
Fluxo
Cenário
Fluxo: um conjunto de passos sequenciais.
Caso de Uso: Um repositório com a descrição de todos os fluxos.
Cenário: Um conjunto ordenado de fluxos que vem do início do caso de uso
até seus pontos finais.
Capturando os cenários do Caso de Uso
• Capture os cenários na especificação de
caso de uso em sua própria seção.
• Dê um nome a cada cenário.
• Liste o nome de cada fluxo em cada
cenário.
–Coloque os fluxos em seqüência.
Exemplo do Cenário de Caso de Uso
Obter Cotação
Cenário “Conexão do servidor caiu.”
Fluxos: “Fluxo Básico,” “Sistema de Cotações Indisponível.”
Esboçe o fluxo de eventos
• Fluxo Básico
– Quais eventos iniciam o caso de uso?
– Como o caso de uso termina?
– Como o caso de uso repete um comportamento?
• Fluxos Alternativos
– Há situações não obrigatórias que ocorrem?
– O que pode acontecer de estranho?
– Quais variantes podem acontecer?
– O que pode estar errado?
– O que não pode acontecer?
– Que tipos de recurso podem ser bloqueados?
Desenho passo-a-passo: Obter Cotação
Fluxo Básico
1. O cliente se autentica.
2. O cliente requisita a obtenção de uma cotação.
3. O cliente seleciona o botão de negociação de ações.
4. O cliente obtêm a cotação desejada.
5. O sistema apresenta a cotação.
6. O cliente obtêm outras cotações.
7. O cliente sai do sistema.
Fluxos Alternativos
A1. Cliente de Ações não identificado.
A2. Sistema de Cotações indisponível.
A3. Sair.
Existem outras
alternativas?
Packages (Pacote): Organize o Modelo de CSU
Package
Raiz
Use-Case
Packages
Atores
Use Cases
Use-Case
Packages
Refinar a definição do sistema: Atividades
e Artefatos
O que são restrições de
projeto?
• Um requisito que se refere ao projeto e/ou
arquitetura do sistema é uma restrição de projeto.
– Distinguir de outros requisitos.
– Colocá-la em uma seção especial do Documento de
Requisitos.
– Identificar a fonte de cada uma.
– Documentar a razão de cada uma.
• Exemplos.
– Um algoritmo de uso obrigatório.
– O uso de um determinado produto de banco de dados.
– A linguagem de programação que deve ser usada.
O Dilema do O Que-Versus-Como
Questão: Como especificar um requisito de projeto?
Resposta: Depende de seu ponto de vista.
O homem
de cima
Éo
Homem do
outro
andar.”
Davis, 1993
O que
Como
O que
Como
O que
Como
Necessidades
Características
Casos de Uso
Espec. Técnica
Procedimentos Teste
Planos Documentação
Características levam a Requisitos de
Períodos de negocição Software
podem ser digitadas em
dias, semanas e meses.
Caract 63 – o sistema de
acompanhamento de defeitos
irá fornecer informações de
tendências para ajudar o
gerente de projeto a ter
conhecimento do andamento
Informações de tendências
serão apresentadas em um
gráfico de linhas
apresentando tempo em x, e
nº de defeitos em y.
Imprimir Relatório
de Status Gerente de
Operador
Projeto
Como especificar requisitos funcionais?
• Use os casos de uso e setenças declarativas.
– Ambos são necessários para entender um sistema de
complexidade relevante.
• Dê preferência a casos de uso, onde
apropriados.
+
Casos de Uso
O sistema pode …
O sistema deve …
O sistema deve ...
Sentenças Declarativas
Qual escolher?
E sobre requisitos que não
estão em Casos de Uso?
• Escreva uma sentença declarativa que não
esteja em caso de uso.
– Use uma palavra-chave que para ajudar na
identificação, por exemplo “deve.”
– Numere e dê um título a cada requisito.
– Agrupe requisitos relacionados.
• Use language the team easily understands.
– Use uma estrutura de setença simples.
• Adjetivo + Substantivo.
– Seja conciso e claro.
• Descreva o requisito em 1 a 3 sentenças.
• Torne o requisito completo.
– Use termos do glossário.
Requisitos Funcionais em
Sentenças Declarativas
• Alguns requisitos são mais fáceis de
entender em sentenças declarativas.
– Exemplo do sistema RU e-st
1. Localização:
SUPL120: O sistema RU e-st deve suportar a
apresentação de todas as mensagens e menus no
idioma escolhido pelo usuário a qualquer hora. Os
idiomas suportados devem ser Inglês, Espanhol,
Francês, Alemão, e Sueco.
Onde as sentenças declarativas
são especificadas?
• Se o requisito se aplicar ao caso de uso:
–Especifique no caso de uso
–Na seção “Requisitos especiais”
• O requisito se aplica a uma parte do
sistema:
–Especifique na Especificação Suplementar
Variações nos Requisitos Funcionais
O sistema com um
pequeno comportamento
externo observável.
O sistema com muito
comportamento externo
observável.
Por que detalhar casos de uso?
• Para especificar os requisitos de software.
–Criar a especificação que deve ser
implementada.
• Esclarecer detalhes importantes do fluxo de
eventos.
–O que um ator faz.
–Como o sistema deve responder ao ator.
–Quais informações são trocadas.
• Descrição de informação adicional.
–Pré-Condições
–Pós-Condições
Detalhe um caso de uso
1. Procure atores e casos de uso.
2. Detalhes do caso de uso.
Esboço
<Nome Caso de Uso>
1. Descrição Breve
2. Fluxo de Eventos
Fluxo Básico de Eventos
Fluxos Alternativos
3. Requisitos Especiais
4. Pré-Condições
5. Pós-Condições
6. Pontos de Extensão
7. Relacionamentos
8. Diagramas de Caso de Uso
9. Outros diagramas e itens
Adicione Detalhes
Detalhe o fluxo básico de eventos
Obter Cotação
1.1 Fluxo Básico
1. Cliente se autentica
O caso de uso se inicia quando o cliente se autentica.
O sistema valida login e senha do cliente.
O sistema apresenta uma lista de funcionalidades.
2. O cliente seleciona a função “Obter Cotação”
O cliente escolhe obter uma cotação.
O sistema apresenta uma lista de símbolos de cotação e nomes
de seguros.
3. O Cliente seleciona o seguro
O cliente seleciona de uma lista de seguros ou informa o
símbolo de seguro para a cotação.
4. O sistema obtêm a cotação do sistema de cotações
O sistema envia o símbolo de cotação para o Sistema de
Cotações, e recebe uma resposta do sistema de cotações.
O sistema apresenta a tela correspondente da cotação (veja em
campos apresentados na Especificação Suplementar) ao cliente.
Estruture o fluxo
em passos
Numere e dê
títulos a cada passo
Torne cada
passo um
conjunto de
eventos
Descreva passos
(completamente
e claramente)
Gerenciar Detalhes
Caixa preta
Caixa Branca
• Saber quem vai ler.
• Escreva para a caixa preta.
• Algum texto de caixa branca pode melhorar
o entendimento porque torna o caso de uso
mais concreto.
Estruturar os fluxos de caso de uso
• Organização interna do caso de uso.
–Melhora legibilidade.
–Torna os requisitos mais fáceis de entender.
• Documente os estilos aceitáveis nos
Guias de Modelagem de Casos de Uso.
Numeração e Referência Cruzada
Estilo do RUP
1. Customer Logs On
In Step 1, Customer Logs On, in
Estilo de Tag
{Trading Customer Logs on}
In {Trading Customer logs on},
Detalhe fluxos alternativos
Alternative
Flows
Fluxos
alternativos
Request Additional
A3 Requisitar
cotaçõesQuotes
adicionais
In Step
3, Customer
Gets Quote,
in the
if the
No
passo
3, Cliente obtêm
cotação,
no Basic
Fluxo Flow,
básico,
se o
customer
wantscotações
additional
quotes.
cliente
desejar
adicionais.
The
usede
case
at Step
3. 3.
O
caso
usocontinues
continua no
passo
Quit
A4 Sair
If at
any time
the Trading
Customer
decides to
quit.sair do
A
qualquer
tempo
o Cliente
de Negociações
pode
The use case ends.
sistema.
O caso de uso termina.
A5 Unknown Trading Symbol
Step 3, Customer
Gets Quote,
in the Basic Flow, if the
A5InSímbolo
de negociação
desconhecido
system
cannot
recognize
trading symbol,
the Básico,
system
No
passo
3, Cliente
obtêmthe
negociação,
no Fluxo
notifies
the Trading
Customerothat
the trading
symbol iso
se
o sistema
não reconhecer
símbolo
de negociação,
not recognizable.
sistema
notifica o ator que o símbolo não existe.
The
usede
case
at the
beginning
of 3.
Step 3.
O
caso
usocontinues
continua do
início
do passo
Descreva o que
Acontece
Localização
Condição
Ações
Resuma a
Localização
Evite Comportamento Condicional em série
• Torna os cenários difíceis de entender.
• Mais difícil de implementar e testar.
Prefira fluxos
alternativos.
Evite comportamento repetitivo em série
• Torna os cenários mais difíceis de identificar.
• Mais difícil de testar e implementar.
Prefira fluxos
alternativos.
Fluxos alternativos X Comportamento
Condicional em série
• Fluxos alternativos
– Prós
• Pode ser usado em qualquer lugar onde haja comportamento
condicional.
– REPITA-ATÈ, SE-ENTÃO-SENÃO-FIM-SE
• Torna os cenários fáceis de identificar.
– Isto ajuda a implementação e ao teste
– Contras
• Aumenta a complexidade de manter referências.
• Comportamento condicional em série
– Prós
• Mais de fácil de lidar nos fluxos com pequenas variações.
– Contras
• Difícil de identificar cenários, testar e implementar.
Visualizar comportamento
alternativo
Cliente
Sistema
Sis. Cotação
Sub-fluxos
• Melhora a clareza.
• Permite reuso intermo dos requisitos.
• Diferente dos fluxos alternativos, são
chamados explicitamente.
• Sempre retorna para a linha de onde foi
chamado.
Fluxos
Alternativos
Subfluxos
Exemplo de Subfluxo
Mantenha a interface do usuário
fora do caso de uso
• Texto não é bom para descrever tela.
• Casos de uso desconhecem tela.
• Descreva tela durante Análise com
protótipos:
–Modele a iteração com tela via protótipo
Palavra a EVITAR
Clique Arrastar
Abrir
Fechar
Botão Campo
Pop-up Rolar
Registro Janela
Form
Combo
Drop-down
Navegar
Palavras para usar
Pergunta
Inicia
Submete
Começa
Apresenta
Escolhe
Especifica
Seleciona
Informa
Use o glossário efetivamente
Caso de uso
Entrar com informações do
cliente
O sistema requisita ao cliente que
informe seus detalhes cadastrais.
O cliente informa seus detalhes
cadastrais.
O cliente cria uma conta.
Glossário
Detalhes Cadastrais: informações
que identificam unicamente e fornecem
informações de contato para um
cliente localizado nos EUA. A
informação consiste de: Nome, 2
linhas de endereço, cidade, estado,
cep, e telefone para contato.
Implementação
Pré-condições
• Descreve em qual estado o sistema deve
se encontrar para o início do caso de uso.
– Não é o evento que inicia o caso de uso.
• Reduz a quantidade de validação
necessária.
• Opcional: Use somente se necessário para
melhorar o entendimento.
Obter Cotação
Pré-condição
O sistema RU e-st deve se estar
conectado com o Sistema de Cotação
antes do início do caso de uso.
Pós-Condições
• Descreve em qual estado deve estar o sistema
ao fim da execução do caso de uso.
– Estado garantido de quando terminar o caso de uso.
– Pode conter variações.
• Opcional: descreva somente se necessário para
melhorar o entendimento.
Executar Previsão
Pós-condição
Ao fim do caso de uso todas as contas
devem estar atualizadas para refletir
as transações que ocorreram.
Seqüência do caso de uso com
pré e pós Condições
Casos de uso não interagem.
Outras propriedades dos casos
de uso
• Requisitos especiais
– Relacionado a este casos de uso, não coberto pelos
fluxos.
– Geralmente não funcionais, dados, regras de negócio.
• Pontos de Extensão
– Nomeia com conjunto de locais nos fluxos onde há
comportamento de extensão a ser executado.
• Relacionamentos (Use-Case-Model)
– Associações com atores e casos de uso.
• Diagramas de Casos de Uso
– Modelo visual de todos os relacionamentos
envolvendo o caso de uso.
• Outros diagramas e encapsulamentos
– Interação, atividade, ou outros diagramas.
Dicas para casos de uso
• Descreva apenas eventos visíveis ao ator:
– O que o ator faz.
– O que o sistema responde ao ator.
• O que o caso de uso fornece de valor ao ator.
• Casos de uso podem ter diferentes níveis de
detalhe.
– Detalhe até que cada stakeholder tenha um
entendimento comum dos requisitos de sua
perspectiva, e então pare.
• Use termos e vocabulário comum a todos.
• Use linguagem precisa.
Checkpoints para casos de uso
• As iterações e trocas com os atores estão
claramente descritas?
• A seqüência de comunicação entre atores
e casos de uso estão em conformidade
com as expectativas do cliente?
• Está claro como e onde os fluxos de caso
de uso começam e terminam?
• Subfluxos estão modelados com

precisão?
E sobre os requisitos não funcionais?
• O “URPS” do FURPS
– Usabilidade
– Robustez (Confiança)
– Performance
– Suportabilidade
• Conformidade com as Leis
e Regulamentos
– IMMETRO
– ANVISA
– BC
– ISO
• Restrições de Projeto
– Sistema Operacional
– Ambientes
– Compatibilidade
– Padrões de Aplicação
Functionality
Feature set
Capabilities
Generality
Security
Usability
Human factors
Aesthetics
Consistency
Documentation
Reliability
Performance
Supportability
Frequency/Severity
of failure
Recoverability
Predictability
Accuracy
MTBF
Speed
Efficiency
Resource usage
Throughput
Response time
Testability
Extensibility
Adaptability
Maintainability
Compatibility
Configurability
Serviceability
Installability
Localizability
Robustness
Exemplo: Requisitos não
funcionais
• O sistema RU e-st
–O sistema deve fornecer cotações de preço
com um atraso máximo de 15 minutos.
• E quanto aos outros?
• Onde cada um deles devem ser
especificados?
Especifique Requisitos de Usuabilidade
• Usabilidade é a facilidade com que o software pode
ser aprendido e operado por um usuário.
• Requisitos de Usabilidade incluem:
– Requisitos de tempo de treinamento, tempos de tarefas
mensuráveis.
– Habilidades do usuário (iniciante/avançado).
– Comparação com outros sistemas conhecidos pelo usuário.
– Help on-line, dicas, necessidades de documentação.
– Conformidade com padrões.
• Exemplos: Windows, guias de estilo, Padrões de Tela
Toda a documentação do usuário deve estar em
conformidade com o Manual de Estilo para Documentos
Técnicos da Microsoft® .
Especifique requisitos de Confiabilidade
• Confiabilidade é a capacidade que um
software tem de se comportar
consistentemente da maneira aceitável pelo
usuário.
• Requisitos de Confiabilidade incluem:
–Disponibilidade (xx.xx%)
–Acurácia
–MTBF (xx hrs)
–Max. bugs per/KLOC (0-x)
O relatório de velocidade da cápsula não tripulada de Marte
deve ser em unidade de metros por segundo e estar entre 1
até 1e6.
Especifique Requisitos de
Performance
• Performance é a medida de velocidade ou
eficiência de um sistema em execução.
• Requisitos de performance incluem:
- Memória
–Capacidade
- Modo de degradação
–Throughput
–Tempo de resposta - Use de recursos limitados
- Processador, memória, disco,
banda de rede
Não há mais do que 4 protocolos de troca, tamanhos não
menores do que 512k bytes cada, entre cliente e servidor
para a troca de dados.
Especifique requisitos de Suportabilidade
• Suportabilidade é a capacidade do software em
ser facilmente modificável para acomodar
melhorias e reparos.
• Requisitos de suportabilidade incluem:
– Linguagens, SGDB, ferramentas, e etc.
– Padrões de programação.
– Manipulação de erros e padrões de relatório.
• Difícil de especificar
– Se não mensurável ou observável, assim não é
requisito.
– É uma restrição de projeto?
– É uma intenção ou um objetivo?
Como descrever protocolos de
comunicação
• Especifique um protocolo de comunicação
se o ator é um sistema externo ou um
outro hardware.
–A descrição do caso de uso pode estabelecer
se um determinado protocolo é usado.
–Se o protocolo é novo, ele será totalmente
descrito no desenvolvimento orientado a
objetos.
Estruturar Modelos de Casos de
Uso
• Como estruturar modelos?
– Transformar partes de casos
de uso em novos casos de uso.
• Por que estruturar o modelo
de casos de uso?
– Simplificar os casos de uso
originais.
• Tornar mais fácil de entender.
• Tornar mais fácil de manter.
– Reuso de Requisitos.
• Compartilhar pelos diversos casos
de uso.
Relacionamentos entre CSUs
• Include
• Extend
• Generalização
«include»
«extend»
O que é um relacionamento de
Include?
• O relacionamento entre um caso de uso
origem com um caso de uso incluído.
• O comportamento do caso de uso incluído é
explicitamente incluído dentro do caso de
uso de origem.
Inclusão
«include»
Origem
Relacionamento de Inclusão
Obter Cotação
Executar
Negociação
«include»
«include»
Trading
Customer
Outro caso de uso
Caso de Uso de Obter Cotação
1. Inclui “Identificar Cliente”
para verificar a identidade do
cliente
2. Mostrar Opções. O Cliente
seleciona “Obter Cotação”
3. ...
Identificar Cliente
«include»
Caso de Uso de Identificar Cliente
1. Autenticar
2. Validar autenticação
3. Entrar com senha
4. Validar senha
A1: Autenticação inválida
A2: Senha errada
A3: ...
Execução de um relacionamento de inclusão
• Totalmente executado quando o ponto de
inclusão é alcançado.
Caso de Uso
Base
Instância de
Caso de Uso
Caso de Uso
Incluído
Por que utilizar um
relacionamento de inclusão?
inclusão
«include»
Base
– Cortar comportamento comum
entre 2 ou mais casos de uso.
• Evitar descrever o mesmo
comportamento duas vezes.
• Assegurar comportamento igual em
vários outros pontos.
– Cortar e encapsular
comportamento comum.
• Simplificar fluxos de eventos
complexos.
• Cortar partes não primárias do
comportamento.
O que é um relacionamento de
Extend?
• Conecta um ponto de extensão de um
caso de uso a um ponto do caso de uso
base.
–Insere um ponto de comportamento extensível
para um caso de uso base.
–Insere apenas se uma condição for
Base
verdadeira.
–Insere no caso de uso base
«extend»
um ponto de extensão
Extension
nomeado.
Relacionamento de Extensão:
Exemplo RU e-st
Cliente de
Negociações
Obter
Cotação
«extend»
Obter
Notícias
«extend»
Obter
Previsões
Sistema especialista
em cotações
Sistema novo
Relacionamento de Extensão
Caso de Uso Obter Cotação
Fluxo Básico:
1. Incluir “Identificar Cliente”
para verificar identidade do
cliente.
2. Apresentar Opções.
3. Cliente seleciona “Obter
Cotação.”
4. Cliente obtêm cotação.
5. Cliente obtêm outras
cotações.
6. Cliente faz logs off.
A1. Sistema de cotação fora
…
Pontos de Extensão:
O ponto de extensão “Serviços
Opcionais” ocorre no passo 3
do Fluxo Básico e passo A1.7
no fluxo alternativo Sistema de
cotação fora.
Caso de Uso Obtêm Notícias
Este caso de uso extende o caso de
Obter cotações, no ponto de
extensão “Serviços Opcionais.”
Fluxo Básico:
1. Se o cliente selecionar “Obter
notícias,” o sistema pergunta ao
cliente o intervalo de tempo e a
quantidade de itens de notícia.
2. O cliente informa os dados. O sistema
envia o símbolo de cotação de
ações ao sistema de Notícias,
recebe a resposta, e apresenta as
notícias ao cliente.
3. O caso de uso Obter cotações
continua.
A1: Sistema indisponível
A2: Sem notícias para a cotação da ação
…
Execução de um Extend
• Executado quando o ponto de extensão é
alcançado e a condição de extensão
válida.
Instância de
Caso de Uso
Caso de
Uso Base
Ponto de Extensão
Caso de Uso
Extendido
Por que usar um
relacionamento de Extend?
Base
«extend»
Extensão
• Recortar comportamento
excepcional ou alternativo.
– Executado somente sob certas
circunstâncias.
– Recortar simplifica o fluxo de
eventos no caso de uso base.
– Exemplo: Disparar Alarmes.
• Adicionar Comportamento de
Extensão.
– Comportamento desenvolvido
separadamente, possivelmente
em versão posterior.
Caso de Uso Concreto versus
Abstrato
Um caso de uso
pode ser concreto
ou abstrato.
Caosos de Uso Abstratos (A & D):
• Não tem de ser completos.
• Existem somente em conjunto
com outros casos de uso.
«include»
• Não possuem sua própria
instância.
Dica:
C
B
Mesmo retirando
todos os casos
de uso abstratos
«extend»
você ainda é
Concrete use cases (B & C):
capaz de
D
• Tem que ser completos e
entender o
claros.
sistema
• Possuem suas próprias
instâncias.
A
Por que não estruturar o
Modelo de Casos de Uso?
Inclusão
«include»
Base
«extend»
Extensão
Filho
- A solução é mais difícil de ver
quando o casos de uso é
fragmentado.
- Decomposição de Caso de Uso.
- Diminui entendimento.
- Aumenta complexidade.
- Aumenta esforço de revisores,
testadores e desenvolvedores.
- Nem todos os stakeholders estão
confortáveis com o formato.
- O Modelo de caso de uso se
parece com o design.
O que é Generalização de Ator?
• Atores podem ter características comuns.
• Múltiplos atores podem ter papéis ou propósitos
comuns ao interagir com os casos de uso.
Pai
Filho 1
Filho 2
Generalização de Atores
• Pai: Medical Worker
Agendar
Operação
• Filhos: Doutor,
Enfermeira, Auxiliar
Doutor
Enfermeira
Auxiliar
– Servidor Hospitalar pode
ler prontuário
– Doutor, Enfermeira, e
Auxiliar podem ler
prontuário
Servidor
Hospitalar
Ler Prontuário
Por que generalizar atores?
Pai
Filho 1
Filho 2
• Simplifica o
relacionamento entre
vários atores e casos de
uso.
• Mostra que o
comportamento do pai é
herdado pelos filhos.
• Representa diferentes
níveis de segurança.
Atores concretos versus abstratos
• Um ator abstrato contém a
parte comum dos papéis.
Funcionário
de Medicina
– Não podem ser instanciados.
– Exemplo:
• Ninguém terá o cargo: servidor
médico.
• Um ator concreto pode ser
instanciado.
Doutor Enfermeira
– Exemplo:
• Lauren é Doutora.
• Daniel é enfermeiro.
Guias para a modelagem de
casos de uso
• Notações para usar e não usar.
–Por exemplo, quando usar relacionamento de
generalização.
• Papéis, recomendações, estilos, e como
descrever um caso de uso.
• Recomendações de quando começar a
estruturar os casos de uso(não tão cedo).