apostila_psp_requisitos_v1.2

Prévia do material em texto

Processo de Software da PBH/Prodabel 
PSP 
 
 
 
Requisitos de Software e 
Casos de uso 
 
 
 
 
 
 
 
 
 
 
 
Gerência de Engenharia de Software (GESS-PB) 
Superintendência de Arquitetura de Sistemas (SAS-PB) 
Diretoria de Sistemas e Informação (DS-PB) 
Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A) 
 
 
Versão 1.2 
Sumário 
 
1. Requisitos de software 
2. Engenharia de requisitos 
3. Técnicas de levantamento (elicitação) de requisitos 
4. Casos de uso 
5. Modelagem de casos de uso 
6. Exercícios 
Processo de software PBH/Prodabel
C1-Introdução 1
Processo de Software da PBH/Prodabel – PSP
Gerência de Engenharia de Software (GESS-PB)
Superintendência de Arquitetura de Sistemas (SAS-PB)
Diretoria de Sistemas e Informação (DS-PB)
Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A)
Versão 1.2
Requisitos de software
Requisitos Processo de software da PBH/Prodabel 2
Objetivos
• Entender o que é um requisito
• Apresentar as classificações dos requisitos
Processo de software PBH/Prodabel
C1-Introdução 2
Requisitos Processo de software da PBH/Prodabel 3
Roteiro
• Problemas de desenvolvimento de software
• Definição de requisitos
• Classificação dos requisitos
− Visibilidade
− Natureza
• Regras de negócio
• Requisitos e processos
• Interessados nos requisitos
• Engenharia de requisitos
− Desenvolvimento de requisitos
− Gerenciamento de requisitos
Requisitos Processo de software da PBH/Prodabel 4
Problemas do desenvolvimento de software
• “A parte mais difícil de construir um software é decidir
precisamente o que deve ser feito.
• Nenhuma outra parte do trabalho conceitual é tão difícil do 
que estabelecer os requisitos detalhados, incluindo todas
as interfaces com pessoas, equipamentos e outros
sistemas.
• Nenhuma parte do trabalho influencia tanto o sistema
resultante se feita incorretamente.
• Nenhuma parte é mais difícil de retificar posteriormente.”
(Frederick Brooks)
Processo de software PBH/Prodabel
C1-Introdução 3
Requisitos Processo de software da PBH/Prodabel 5
Problemas clássicos do desenvolvimento de software
Requisitos Processo de software da PBH/Prodabel 6
Problemas com requisitos
• Envolvimento insuficiente dos usuários.
• Crescimento dos requisitos de usuário.
• Requisitos ambíguos.
• Gold plating (bala de prata).
• Especificações minimalistas.
• Excesso de classes de usuário.
• Planejamento inacurado.
• Outros:
• __________________________________________
Processo de software PBH/Prodabel
C1-Introdução 4
Requisitos Processo de software da PBH/Prodabel 7
Processo de requisitos efetivo
• Redução de defeitos nos requisitos.
• Redução do retrabalho de desenvolvimento.
• Redução de características desnecessárias.
• Redução de custos para evoluções.
• Desenvolvimento agilizado.
• Redução dos problemas de comunicação.
• Redução do crescimento do escopo.
• Redução do caos no projeto.
• Estimativas mais acuradas.
• Aumento da satisfação dos envolvidos.
Requisitos Processo de software da PBH/Prodabel 8
Requisitos
• O termo requisito nem sempre é utilizado pela
indústria de software de modo consistente.
• Em alguns casos, um requisito é visto como uma
declaração abstrata, de alto nível, de uma função
que o sistema deve fornecer ou de uma restrição do 
sistema.
• No outro extremo, ele pode ser uma definição
detalhada, matematicamente formal, de uma função
do sistema.
• Que definição adotar?
• __________________________________________
Processo de software PBH/Prodabel
C1-Introdução 5
Requisitos Processo de software da PBH/Prodabel 9
“Documento de requisitos”
• Se uma empresa deseja estabelecer um contrato para o 
desenvolvimento de um projeto de software, suas necessidades
têm que ser definidas de forma suficientemente abstrata para que
uma solução “a priori” não seja definida.
• No caso de contratação externa os requisitos devem ser redigidos
de modo que os diversos fornecedores possam apresentar
propostas.
• Uma vez estabelecido o contrato, o fornecedor escolhido precisa
preparar uma definição de sistema para o cliente contendo mais
detalhes, de modo que o cliente possa compreender e validar o 
que o software fará.
• Em ambos os casos, tem-se um “documento de requisitos”.
• Essas afirmações mostram que a definição de requisitos deve ser 
feita por meio de refinamentos sucessivos, indo do “conceitual” em
direção ao “físico”.
Requisitos Processo de software da PBH/Prodabel 10
Definição de requisitos
1. Condição ou capacidade necessária a um usuário
para resolver um problema ou atingir um objetivo.
2. Condição ou capacidade que deve ser alcançada ou
possuída por um sistema ou componente de sistema
para satisfazer um contrato, padrão, especificação
ou outro documento formalmente imposto.
3. Uma representação documentada de uma condição
ou capacidade como nos itens 1 e 2 acima. 
Fonte: [IEEE Standard Glossary of Software Engineering 
Terminology, 1990]
Processo de software PBH/Prodabel
C1-Introdução 6
Requisitos Processo de software da PBH/Prodabel 11
Definição de requisitos II
“Requsitos são uma especificação do que deve
ser implementado. Eles constituem descrições
de como o sistema deve se comportar, ou uma
propriedade ou atributo do sistema. Podem
caracterizar uma restrição no processo de 
desenvolvimento do sistema.”
Fonte: Sommervile e Sawyer, Requirements 
Engineering, 1997].
Requisitos Processo de software da PBH/Prodabel 12
O que requisito não é
• Especificação de requisitos não incluem:
−Detalhes de desenho;
− Implementação;
− Informações de teste;
−Requisitos de projeto;
− Limites de recursos e tempo;
− necessidade de um tutorial para os usuários;
− Etc…
Processo de software PBH/Prodabel
C1-Introdução 7
Requisitos Processo de software da PBH/Prodabel 13
Classificação dos requisitos
• Quanto a visibilidade
– Requisitos de usuário;
– Requisitos de sistema;
– Requisitos de desenho.
• Quanto a natureza
– Funcionais;
– Não funcionais.
Requisitos Processo de software da PBH/Prodabel 14
Classificação dos requisitos
Necessidades
Requisitos de usuário
Domínio da
solução
=> Sistema
Requisitos de sistemas
Requisitos de desenho
Domínio do 
problema
=> Negócio
Produto a ser 
construído
+ Conceitual
+ Físico
Problema a ser 
resolvido
Processo de software PBH/Prodabel
C1-Introdução 8
Requisitos Processo de software da PBH/Prodabel 15
Separação entre domínios
• A separação em domínios indica que os
requisitos de software tratam da solução para um 
problema.
• O formato da pirâmide reflete o volume relativo
do problema: poucas necessidades podem exigir
vários requisitos.
• Rastreabilidade deve ser mantida entre todos os
níveis.
Requisitos Processo de software da PBH/Prodabel 16
Necessidades
• Também conhecidas como requisitos de negócio, representam
objetivos de alto nível da organização ou cliente que requisitou o 
sistema. Tipicamente são originadas do patrocinador do projeto, 
o adquirente. Por ex: o gerente dos usuários ou o setor de 
marketing.
• Descrevem porque a organização está implementando o sistema
– os objetivos que espera-se atingir. Normalmente são
contemplados num documento de visão ou proposta do projeto.
• Ex: “Reduzir os custos operacionais [em y%]”; “Aumentar
participação no mercado [em x%]”; “Implantar nova linha de 
produtos e serviços”.
• Dê um exemplo na sua área de trabalho:
• ____________________________________________________
Processo de software PBH/Prodabel
C1-Introdução 9
Requisitos Processo de software da PBH/Prodabel 17
Requisitos quanto à visibilidade
• Requisitos de usuário: Declarações em linguagem natural e 
também em diagramas sobre as funções que o sistema deve
fornecer e as restrições sob as quais deve operar.
• Requisitos de sistema: Estabelecem detalhadamente as funções
e restrições de sistema. O documento de requisitos de sistema, 
também chamado Especificação Funcional ou de Requisitos, 
deve ser preciso. Ele pode servir como um contrato entre 
compradore desenvolvedor.
• Requisitos de desenho: Uma descrição abstrata que é base para
detalhes de implementação. Essa especificação acrescenta mais
detalhes à Especificação de Requisitos do Sistema. É um 
documento orientado à implementação.
Requisitos Processo de software da PBH/Prodabel 18
Público-alvo dos documentos
Requisitos de 
usuário
•Gerentes de clientes
•Usuários finais
•Técnicos do cliente
•Gerentes do fornecedor
•Arquitetos de sistemas
•Usuários finais de sistemas
•Técnicos do cliente
•Arquitetos de sistemas
•Desenvolvedores de software 
(eventual)
•Técnicos do cliente
(eventualmente)
•Arquitetos de sistemas
•Desenvolvedores de software
Requisitos de 
sistema
Requisitos de 
desenho
Processo de software PBH/Prodabel
C1-Introdução 10
Requisitos Processo de software da PBH/Prodabel 19
Exemplo de requisitos de usuário e sistema
• Requisitos de usuário: 
– “O sistema deve oferecer um meio de representar e acessar
arquivos externos criados por outras ferramentas.”
• Especificação de requisitos de sistema: 
– “O usuário deve dispor de recursos par definir o tipo dos 
arquivos externos.
– Cada tipo de arquivo pode ser representado como um ícone
específico na tela do usuário.
– Quando um usuário seleciona um ícone de um arquivo
externo, o efeito é aplicar a ferramenta associada com o tipo
de arquivo representado, permitindo executa-lo.”
Que software poderia ser este?
______________________________________________
Requisitos Processo de software da PBH/Prodabel 20
Requisitos funcionais
• Declarações de funções que o sistema deve fornecer, 
como o sistema deve reagir a entradas específicas e 
como deve se comportar em dadas situações.
• Descrevem as funcionalidades ou serviços que um 
sistema oferece.
• Dependem do tipo de software, usuários esperados e 
do tipo de sistema onde o software será utilizado.
• Enquanto requisitos funcionais de usuário podem ser 
declarações de alto nível do que o sistema deve fazer, 
requisitos funcionais de sistema devem descrever os
serviços do sistema em detalhes.
Processo de software PBH/Prodabel
C1-Introdução 11
Requisitos Processo de software da PBH/Prodabel 21
Requisitos funcionais
• Especificam funcionalidades de software que
os desenvolvedores devem construir para
possibilitar aos usuários executar suas tarefas, 
satisfazendo aos requisitos de negócio.
• Esse tipo de requisitos é descrito
tradicionalmente pela sentença 'deve‘.
• Ex: “O sistema deve enviar uma mensagem
com a confirmação de reserva para o usuário”.
Requisitos Processo de software da PBH/Prodabel 22
Exemplos de requisitos funcionais
• Sistema de biblioteca:
– “O usuário deverá ser capaz de buscar todo o 
conjunto inicial de banco de dados ou selecionar
um subconjunto a partir dele.
– O sistema deve prover telas apropriadas para o 
usuário ler documentos no repositório de 
documentos. 
– Cada pedido será alocado a um único identificador
(ID_Pedido), que o usuário poderá copiar para a 
área de armazenagem permanente da conta.”
Processo de software PBH/Prodabel
C1-Introdução 12
Requisitos Processo de software da PBH/Prodabel 23
Requisitos não funcionais
• Restrições sobre as funções oferecidos pelo sistema. Destacam-
se aqui as restrições de tempo, processo e padrão.
• Ex.: tempo de resposta, requisitos de armazenamento, 
confiabilidade, capacidade dos dispositivos de I/O, etc...
• Também podem ser especificados uma determinada ferramenta
CASE, linguagem de programação ou processo de 
desenvolvimento.
• Podem ser mais críticos que os requisitos funcionais. 
Ex: ________________________________________________
• Caso não sejam atendidos, o sistema pode tornar-se inutilizável. 
Ex: ________________________________________________
Requisitos Processo de software da PBH/Prodabel 24
Classificação dos requisitos não funcionais
Facilidade de uso
Desempenho
Espaço
Eficiência
Confiabilidade
Portabilidade
Requisitos de produto
Entrega
Implementação
Padrões
Requisitos organizacionais
Interoperabilidade
Éticos
Privacidade
Segurança
Legais
Requisitos externos
Requisitos não funcionais
Processo de software PBH/Prodabel
C1-Introdução 13
Requisitos Processo de software da PBH/Prodabel 25
Classificação dos requisitos não funcionais
• Requisitos de produto: Especificam o comportamento do 
produto.
• Requisitos organizacionais: Decorrem de políticas e 
procedimentos nas organizações do cliente e/ou do 
desenvolvedor.
• Requisitos externos: Abrangem todos os requisitos
procedentes de fatores externos ao sistema e ao seu
processo de desenvolvimento. 
Requisitos Processo de software da PBH/Prodabel 26
Exemplos de requisitos não funcionais
• Requisitos de produto: 
– “Deve ser possível que toda a comunicação necessária
entre o software e o usuário seja expressa no conjunto
padrão de caracteres ASCII”.
• Requisitos de organização:
– “O processo de desenvolvimento e os documentos
entregues deverão estar de acordo com o processo e os
produtos definidos em XYZCo-SP-STAN-95”.
• Requisitos externos:
– “O sistema não deverá revelar aos operadores nenhuma
informação pessoal sobre os clientes além de seus nomes
e código”.
Processo de software PBH/Prodabel
C1-Introdução 14
Requisitos Processo de software da PBH/Prodabel 27
Metas e requisitos
• Requisitos não funcionais podem ser difíceis de 
estabelecer e requisitos imprecisos são difíceis para
verificar. 
• Metas são úteis a medida que elas esclarecem as 
intenções dos usuários do sistema
• Meta:
– Uma intenção do usuário, como “fácil de usar”, “rápido”.
• Requisito não funcional verificável:
– Uma sentença que use alguma métrica que possa ser 
objetivamente testada.
Requisitos Processo de software da PBH/Prodabel 28
Exemplos
• Uma meta do sistema
– “O sistema deve ser fácil de ser usado por
controladores experientes e organizado de tal forma 
que os erros possam ser minimizados.”
• Requisito não funcional verificável
– “Controladores experientes devem estar aptos a 
usar todas as funções do sistema após um 
treinamento de duas horas
– Após o treinamento, o número médio de erros
cometidos pelos usuários experientes não pode
exceder o total de dois por dia.”
Processo de software PBH/Prodabel
C1-Introdução 15
Requisitos Processo de software da PBH/Prodabel 29
Métricas para requisitos
Porcentagem de declarações dependentes de sistema alvo
Número de sistemas alvo
Portabilidade
Tempo de reinício após falha
Porcentagem de eventos que causam falhas
Probabilidade de corrupção de dados
Robustez
Tempo médio para falhar
Taxa de ocorrência de falhas
Disponibilidade
Confiabilidade
Tempo de treinamento
Número de frames de ajuda
Facilidade de uso
K Bytes
Número de chips de RAM
Tamanho
Transações processadas por segundo
Tempo de resposta ao usuário/evento
Tempo de refresh de tela
Velocidade
MétricaPropriedades
Requisitos Processo de software da PBH/Prodabel 30
Atributos de qualidade
• Visão do cliente:
• Disponibilidade
• Eficiência
• Flexibilidade
• Integridade
• Interoperabilidade
• Confiabilidade
• Robustez
• Usabilidade
• Visão do 
desenvolvedor:
• Manutenibilidade
• Portabilidade
• Reusabilidade
• Testabilidade
• Os requisitos não funcionais também são conhecidos
como atributos de qualidade (norma ISO 9126):
Processo de software PBH/Prodabel
C1-Introdução 16
Requisitos Processo de software da PBH/Prodabel 31
Exemplos de atributos de qualidade
• Disponibilidade: “O sistema deve estar 99,5 % do tempo 
disponível nos dias de semana de 6h às 18h”.
• Eficiência: “O sistema deverá estar reservar pelo menos 25% 
da capacidade do processador em condições de pico”.
• Integridade: “Somente usuários que tem acesso como Auditor 
devem ser habilitados a visualizar dados de transações de 
clientes”.
• Interoperabilidade: “O sistema deve ser capaz de importar
qualquer registro válido de funcionário, provido pelo sistema
Pessoal”.
• Confiabilidade: “No máximo cinco em cada 1.000 transações
podem falhar”.
Requisitos Processo de software da PBH/Prodabel32
Regras de negócio
• Não são exatamente requisitos, pois existem fora dos 
limites de qualquer sistema específico.
• Geralmente restringem quem pode desempenhar
determinadas tarefas ou diz que o sistema deve conter
certas funcionalidades.
• Normalmente inclui políticas da corporação, 
regulações governamentais, padrões da indústria, 
práticas contábeis e algoritmos computacionais.
Processo de software PBH/Prodabel
C1-Introdução 17
Requisitos Processo de software da PBH/Prodabel 33
Regras de negócio
• Uma regra de negócio é uma sentença que define ou
restringe algum aspecto do negócio. Tem por
objetivo atender a estrutura, controlar ou influenciar o 
comportamento do negócio.
• Classificação das regras de negócio:
- Fato
- Restrição
- Habilitador
- Cálculo
- Inferência
Requisitos Processo de software da PBH/Prodabel 34
Fato
• Sentenças simples verdadeiras sobre o negócio. 
Tipicamente descrevem associações ou relações entre 
termos de negócio relevantes. São também chamadas
de invariantes. 
• Exemplos:
− “Cada contêiner deve ter um único código de barra
identificador”.
− “Todo pedido deve ter uma carga de entrega”.
− “Taxas de vendas não são computadas nas cargas de envio”.
Processo de software PBH/Prodabel
C1-Introdução 18
Requisitos Processo de software da PBH/Prodabel 35
Restrições
• Restringem as ações que o sistema ou usuários podem
executar. Algumas palavras e frases sugerem
restrições como ‘deve’ e ‘não deve’. 
• Exemplos:
− “Tripulação deve gozar de pelo menos 8 horas de descanso a 
cada 24 horas”.
− “Um cliente com menos de 18 anos deve ser associado a um 
responsável”.
Requisitos Processo de software da PBH/Prodabel 36
Habilitador
• Regra que dispara alguma atividade sob uma condição
específica. 
• Exemplos:
− “Se a data de expiração de um produto tiver sido atingida, o 
responsável deve ser notificado por email”.
− “No último dia da quinzena, gerar os relatórios gerenciais e 
disponibilizar aos gestores”.
Processo de software PBH/Prodabel
C1-Introdução 19
Requisitos Processo de software da PBH/Prodabel 37
Cálculo
• Cálculos realizados usando fórmulas matemáticas específicas ou
algoritmos. Vários cálculos seguem regras externas as 
organizações. 
• Exemplos:
− “O preço total de um pedido é determinado pela soma dos preços de cada
item, deduzido de qualquer desconto de volume, mais taxas de vendas
estaduais e federais, mais taxa de embarque e seguro”
− Tabela de desconto:
20mais de 10Desc3
106 a 10Desc2
01 a 5Desc1
Desconto (%)Itens vendidosId
Requisitos Processo de software da PBH/Prodabel 38
Inferência
• Regra que estabelece algum novo conhecimento
baseado na verdade de certas condições. Uma
inferência cria um novo fato de outros fatos ou de 
cálculos. São geralmente escritos no formato “se …
então”. 
• Exemplos:
− “Se o pagamento não for recebido em 30 dias corridos, o título
será protestado”.
− “Produtos com taxa de toxidade maiores que 5 mg/kg são
considerados perigosos”.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 1
Processo de Software da PBH/Prodabel – PSP
Gerência de Engenharia de Software (GESS-PB)
Superintendência de Arquitetura de Sistemas (SAS-PB)
Diretoria de Sistemas e Informação (DS-PB)
Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A)
Versão 1.2
Engenharia de requisitos de software
Requisitos Processo de software da PBH/Prodabel 2
Objetivos
• Apresentar o conceito de Engenharia de 
requisitos
• Apresentar a disciplina Requisitos do PSP
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 2
Requisitos Processo de software da PBH/Prodabel 3
Roteiro
• Engenharia de requisitos
• Processo de Software da PBH / Prodabel (PSP)
• MPS.BR
• RUP
• Desenvolvimento de requisitos
• Gerência de requisitos
Requisitos Processo de software da PBH/Prodabel 4
Engenharia de requisitos
• Processo de estabelecer os serviços que um cliente
requer de um sistema e as restrições em que o 
mesmo é desenvolvido e será operado.
• Os requisitos são a descrição dos serviços de 
sistema e restrições que são gerados durante o 
processo de engenharia de requisitos.
• Os processos usados dependem do domínio da
aplicação, pessoas envolvidas e organização.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 3
Requisitos Processo de software da PBH/Prodabel 5
Atividades da engenharia de requisitos
• Desenvolvimento de requisitos
− Levantamento (Elicitação)
− Análise
− Especificação
− Verificação e validação
• Gerenciamento de requisitos
− Controle de versões
− Controle de mudanças
Requisitos Processo de software da PBH/Prodabel 6
Limites entre desenvolvimento e 
gerenciamento de requisitos
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 4
Requisitos Processo de software da PBH/Prodabel 7
Requisitos e outras disciplinas
Requisitos Processo de software da PBH/Prodabel 8
Interessados nos requisitos
• Indivíduo ou organização que recebe direta ou
indiretamente algum benefício do produto.
• Incluem os envolvidos no projeto que recebem
pagam, selecionan, especificam, usam ou
recebem os resultados gerados por um 
produto de software.
• Alguns exemplos de interessados são
analistas, desenvolvedores, testadores, 
documentadores, gerentes de projeto, equipe
de suporte, equipe jurídica, marketing, etc.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 5
Requisitos Processo de software da PBH/Prodabel 9
Conflito de interesses
Requisitos Processo de software da PBH/Prodabel 10
Direitos do usuário
• Esperar que o analista fale a sua língua.
• Esperar que o analista compreenda o negócio.
• Esperar que o analista escreva a especificação de requisitos.
• Receber explicação do analista sobre os produtos gerados.
• Receber tratamento respeitoso e profissional do analista.
• Receber alternativas do analista.
• Descrever características do produto que facilitarão sua vida.
• Ter oportunidade de ajustar o produto para prover reuso.
• Receber estimativas corretas de tempo e custo.
• Receber informações sobre o impacto dos pedidos de mudança.
• Receber um sistema que atenda aos requisitos.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 6
Requisitos Processo de software da PBH/Prodabel 11
Responsabilidades dos usuários (a “revanche”)
• Explicar a terminologia da área de negócio.
• Disponibilizar tempo para prover requisitos, elucidá-los e atualizá-los.
• Ser específico e preciso ao prover informações para os requisitos.
• Tomar decisões em tempo hábil sobre requisitos.
• Não pressionar por estimativas de prazo e custo inviáveis.
• Respeitar as estimativas de prazo e custo informadas.
• Definir com o analista as prioridades dos requisitos.
• Revisar os documentos de requisitos e avaliar protótipos.
• Comunicar necessidades de mudanças nos requisitos assim que souber.
• Seguir o processo definido para solicitar pedidos de mudança.
• Respeitar o processo de engenharia de requisitos.
Requisitos Processo de software da PBH/Prodabel 12
Analista de requisitos
• Analista de requisitos é o indivíduo que tem como
responsabilidade principal coletar, analisar, 
documentar e validar as necessidades dos 
envolvidos no projeto.
• O analista serve como principal condutor através do 
qual os requisitos fluem dos clientes até a equipe de 
desenvolvimento.
• Avalie como isto acontece na sua área funcional:
____________________________________________
____________________________________________
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 7
Requisitos Processo de software da PBH/Prodabel 13
Canais de comunicação do analista
Requisitos Processo de software da PBH/Prodabel 14
Competências requeridas de um analista
• Habilidades:
• Ouvir.
• Entrevistar e questionar.
• Analisar.
• Moderar.
• Observar.
• Escrever.
• Organizar.
• Modelar.
• Inter-relacionar.
• Criar.
• Conhecimentos:
• Engenharia de requisitos.
• Processo de software.
• Gerenciamento de projetos.• Qualidade.
• Domínio da aplicação.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 8
Requisitos Processo de software da PBH/Prodabel 15
Importante
• Não assuma que um desenvolvedor talentoso ou
usuário avançado automaticamente pode se tornar
um analista de requisitos efetivo sem treinamento, 
material de apoio e acompanhamento. 
• As atribuições de um analista demandam
habilidades, conhecimentos e atitudes diferentes.
• Analise se você tem as habilidades e conhecimentos
requeridos de um analista de requisitos:
• Habilidades: __ Sim __ Não
• Conhecimentos: __ Sim __ Não
Requisitos Processo de software da PBH/Prodabel 16
Requisitos no PSP
• Os assuntos relacionados a requisitos de software no Processo
de Software da PBH/Prodabel estão disponíveis no próprio
processo.
• As principais referências para a estruturação do fluxo são:
• Disciplina de Requisitos do RUP: O PSP é aderente ao RUP 
e, por consequência, requisitos orientam todo o processo de 
desenvolvimento de software.
• Resultados esperados do MPS.BR: Os REP específicos de 
Gerência de Requisitos devem ser atendidos.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 9
Requisitos Processo de software da PBH/Prodabel 17
Requisitos e o RUP
Requisitos Processo de software da PBH/Prodabel 18
Resultados Específicos (REP) de GRE
� GRE 1. O entendimento dos requisitos é obtido junto aos
fornecedores de requisitos;
� GRE 2. Os requisitos de software são aprovados utilizando
critérios objetivos;
� GRE 3. A rastreabilidade bidirecional entre os requisitos e os
produtos de trabalho é estabelecida e mantida;
� GRE 4. Revisões em planos e produtos de trabalho do projeto
são realizadas visando identificar e corrigir inconsistências em
relação aos requisitos;
� GRE 5. Mudanças nos requisitos são gerenciadas ao longo do 
projeto.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 10
Requisitos Processo de software da PBH/Prodabel 19
Fluxo de requisitos do PSP
Requisitos Processo de software da PBH/Prodabel 20
Fluxo de requisitos do PSP
• Atividade “Obter entendimento”:
– Elaborar especificação de requisitos
– Elaborar modelo de caso de uso
• Atividade “Desenvolver requisitos”:
– Especificar caso de uso
– Elaborar especificação suplementar
• Atividade “Gerenciar requisitos”:
– Registrar solicitação
– Analisar impacto
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 11
Requisitos Processo de software da PBH/Prodabel 21
Requisitos no PSP
• Principais papéis :
– Analista de requisitos
– Desenvolvedor
• Principais artefatos:
– Especificação de requisitos
– Modelo de casos de uso
– Caso de uso (detalhado)
– Especificação suplementar
Requisitos Processo de software da PBH/Prodabel 22
Fontes de requisitos
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 12
Requisitos Processo de software da PBH/Prodabel 23
Fontes de requisitos
• Entrevistas e discussões com usuários potenciais.
• Documentos dos produtos atuais ou concorrentes.
• Especificação de requisitos.
• Relatórios de problemas e pedidos de melhoria.
• Pesquisas de marketing e questionários de usuários.
• Observação do usuário no trabalho.
• Análise de cenários e tarefas de usuários.
• Eventos e respostas.
• Outros: _____________________________________
Requisitos Processo de software da PBH/Prodabel 24
Outros tipos de entradas
• Requisitos não relacionados com o produto, como necessidades
de treinamento dos usuários.
• Restrições de projeto como prazo e custo.
• Uma premissa.
• Informação adicional de um contexto histórico para ajudar a 
entender o contexto.
• Dê um exemplo de cada caso:
Treinamento: __________________________________________
Projeto: ______________________________________________
Premissa: ____________________________________________
Informação adicional: ___________________________________
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 13
Requisitos Processo de software da PBH/Prodabel 25
Diretrizes para explicitação de requisitos
• Escreva sentenças completas com gramática, ortografia e pontuação
corretas. Mantenha parágrafos curtos e diretos.
• Use a voz ativa. Ex: “O sistema deve fazer algo” ao invés de “Alguma coisa
deve ser feita”.
• Quando definir requisitos na forma “O usuário deve...” identifique o ator (“O 
comprador deve...”).
• Use termos consistentes definidos no glossário. Evite sinônimos.
• Decomponha requisitos de alto nível em requisitos mais detalhados de 
forma a torná-los claros e para reduzir a ambiguidade.
• Use listas, figuras, gráficos e tabelas, se necessário.
• Enfatize os trechos mais importantes de informação.
• Evite termos ambiguos, tais como: adequado, eficiente, flexível, melhor, 
maximizar, normalmente, robusto, várias, suficiente, amigável…
Requisitos Processo de software da PBH/Prodabel 26
Especificação de requisitos
• É a base para a equipe de análise e desenho, pois
descreve funções e desempenho requeridos de um 
sistema baseado em computação e as regras que
guiarão seu desenvolvimento.
• Limita cada elemento alocado ao sistema e também
descreve as informações (dados e controle) que
constituem as entradas e saídas do sistema.
• Pode ser um documento escrito, um modelo
gráfico, um modelo matemático formal, uma
coleção de cenários de uso, um protótipo ou
qualquer combinação dos itens citados.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 14
Requisitos Processo de software da PBH/Prodabel 27
Verificação e validação (V&V)
• Verificação:
− Tem como propósito confirmar que cada serviço e/ou
produto de trabalho do processo ou do projeto
atende apropriadamente os requisitos especificados.
− Normalmente desempenhada pela equipe técnica.
• Validação:
− Tem como propósito confirmar que um produto ou
componente do produto atenderá a seu uso
pretendido quando colocado no ambiente para o qual
foi desenvolvido.
Requisitos Processo de software da PBH/Prodabel 28
Verificação e Validação
� Verificação: “Estamos construindo certo o 
produto?”
- Ponto de vista do desenvolvedor / equipe.
� Validação: “Estamos construindo o produto 
certo?”
- Ponto de vista do usuário final / cliente.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 15
Requisitos Processo de software da PBH/Prodabel 29
Técnicas para V&V de requisitos
• Revisão - exemplos:
• Discussão de um problema técnico na hora do café.
• Apresentação do projeto de software para uma audiência
de clientes, administradores e pessoal técnico.
• Revisões Técnicas Formais: inclui avaliações técnicas
de software realizadas em pequenos grupos
(walkthrough).
� Inspeção: análise detalhada feita por um grupo com 
papéis e organização bem definidos.
� Testes: execução de um programa com o objetivo
de encontrar erros.
Requisitos Processo de software da PBH/Prodabel 30
Exemplos de critérios de V&V
• Os requisitos estão estruturados claramente? Não há problemas de 
interpretação incorreta?
• A fonte (pessoa, regimento, documento, etc.) foi identificada? A 
estrutura final do requisito foi examinada pela/contra a fonte original?
• O requisito está definido em termos quantitativos? 
• Quais são os requisitos relacionados a cada um? Eles estão
claramente identificados através de uma matriz de referência cruzada
ou outro mecanismo?
• O requisito viola alguma regra de domínio?
• O requisito é passível de teste?
• O requisito é rastreável para os objetivos gerais?
• Os requisitos associados à performance, comportamento e 
características operacionais foram estruturados claramente?
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 16
Requisitos Processo de software da PBH/Prodabel 31
Exemplos de critérios de V&V
• Consistente. Há algum conflito de requisitos?
• Completo. Todas as funções requeridas pelo cliente foram
incluídas e contêm informações para as demais atividades?
• Real. Os requisitos podem ser implementados com os recursos e 
tecnologia disponíveis?• Completo: cada requisito contém toda a informação necessária ao
desenho e implementação?
• Viável: deve ser possível implementar cada requisito considerando
as capacidades e limitações existentes.
• Necessário: devem ser descritas as capacidades realmente
necessárias aos usuários.
• Priorizado: cada requisito deve ser priorizado.
• Não-ambíguo: todos os leitores dos requisitos têm que ter uma
única e consistente interpretação do seu significado.
Requisitos Processo de software da PBH/Prodabel 32
Priorização de requisitos
• Projetos de software possuem limitações de recursos que nos obrigam a 
definir a prioridade relativa dos requisitos. A priorização ajuda o gerente de 
projeto a resolver conflitos, planejar iterações e fazer as compensações
necessárias.
• Quando as expectativas do cliente são altas e o tempo é curto, faz-se 
necessário entregar o produto com as funcionalidades mais relevantes, o mais
cedo possível.
• Perguntas úteis:
• Há outra maneira de satisfazer as necessidades que esse requisito trata?
• Qual será a consequência de omitir esse requisito?
• Qual será o impacto nos objetivos de negócio se o requisito não for 
implementado nessa iteração?
• Por que o usuário ficaria descontente caso esse requisito fosse adiado
para a última iteração?
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 17
Requisitos Processo de software da PBH/Prodabel 33
Priorização de requisitos
O que fazer?Média prioridadeNão urgente
Baixa prioridadeAlta prioridadeUrgente
Não importanteImportante-
0,3050350322,2421RQ2
1,1733,3216,7138,9732RQ3
-100610061001866Total
Priorida
de
Risco
%
Risco
relativo
Custo
%
Custo
relativo
Valor
%
Valor
Total
Perda
relativa
Benefício
relativo
Requisito
0,9316,7133,3238,9713RQ1
--0,5-1--12Peso
Prioridade = Valor % / [ (custo % * peso custo) + ( risco % * peso risco) ] 
Requisitos Processo de software da PBH/Prodabel 34
Modelagem visual de requisitos
• Nenhuma forma de representação de requisitos provê
individualmente um entendimento completo.
• Normalmente, combinações de reprentações textuais e 
gráficas mostram uma visão completa do sistema
estudado. Alguns mecanismos visuais são:
• Protótipos;
• Tabelas e árvores de decisão;
• Diagramas DFD, DER, classes, estados, sequência.
• Casos de uso.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 18
Requisitos Processo de software da PBH/Prodabel 35
Gerenciamento de requisitos
• Os requisitos passam a compor uma baseline após serem
revisados e aprovados pelos envolvidos no processo de 
desenvolvimento de requisitos. Nesse momento, passam a 
definir o acordo entre desenvolvedores e clientes. Esse acordo é
a ponte entre o desenvolvimento e o gerenciamento de 
requisitos.
• O gerenciamento de requisitos envolve as seguintes atividades:
• Controlar mudanças na baseline de requisitos.
• Manter planos de projetos de acordo com os requisitos.
• Controlar versões dos requisitos e documentos associados.
• Monitorar o status dos requisitos na baseline.
• Gerenciar as ligações entre requisitos e outros produtos de trabalho.
Requisitos Processo de software da PBH/Prodabel 36
Controle de versões de requisitos
• Cada versão dos documentos de requisitos deve ser unicamente
identificada. Cada membro da equipe deve ser capaz de acessar
a versão corrente dos requisitos. Mudanças devem ser 
documentadas e comunicadas a todos envolvidos. 
• Para minimizar confusão, conflitos e desentendimentos, somente
pessoas designadas podem atualizar os requisitos e ter certeza
de que o número de versão muda sempre que ocorrerem
mudanças.
• Na sua visão como poderia ser feito esse controle?
______________________________________________________
______________________________________________________
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 19
Requisitos Processo de software da PBH/Prodabel 37
Monitoramento de status
• Monitorar o status de cada requisito ao longo do 
desenvolvimento provê uma maneira mais refinada de se medir o 
progresso do projeto.
• Classificar os requisitos em status é mais simples e útil do que
atribuir um percentual de conclusão. Exemplos de status:
• Proposto: requisito solicitado por pessoa autorizada.
• Aprovado: realizada análise de impacto, estimativas de projeto e 
alocação para uma release específica.
• Implementado: código desenhado, escrito e testado.
• Verificado: funcionamento confirmado e requisito integrado.
• Rejeitado: requisito proposto mas não planejado para
implementação em nenhuma release.
Requisitos Processo de software da PBH/Prodabel 38
Controle de mudanças
• Procedimentos que visam garantir:
• Mudanças de requisitos propostas são avaliadas
cuidadosamente antes de atualizadas.
• Responsáveis tomam decisões sobre mudanças solicitadas.
• Mudanças aprovadas são comunicadas a todos interessados.
• O projeto incorpora mudanças de uma maneira consistente.
• Você acha que os mecanismos de CM devem ser 
formais ou informais? Explique!
______________________________________________
______________________________________________
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 20
Requisitos Processo de software da PBH/Prodabel 39
Política de controle de mudanças
• Todas as mudanças de requisitos devem seguir o processo definido. Se uma
solicitação de mudança fugir ao processo, está fora!
• Para as mudanças não aprovadas nenhum trabalho de desenho e 
implementação deve ser feito. A única atividade é análise de viabilidade.
• Em alguns casos o grupo gestor deve decidir se uma solicitação deve ser 
implementada.
• O conteúdo da base de mudanças deve ser visto por todos envolvidos.
• Análise de impacto deve ser feita para toda mudança.
• O texto original do pedido de mudança não deve ser alterado.
• Cada mudança em requisitos incorporada deve ser rastreável até o pedido
aprovado.
• A razão de cada aprovação/reprovação deve ser registrada.
Requisitos Processo de software da PBH/Prodabel 40
Papéis no controle de mudanças
• CCB (Change Control Board): grupo que decide aprovar ou
rejeitar mudanças propostas para um projeto específico.
• Avaliador: apoia o CCB analisando o impacto de um pedido de 
mudança. Pode ser um técnico, o cliente, etc.
• Modificador: responsável por realizar as mudanças em um 
produto de trabalho a partir das solicitações aprovadas.
• Originador: quem submete um pedido de mudança.
• Destinatário (Recebedor): quem recebe as novas solicitações.
• Verificador: responsável por determinar se as mudanças foram
feitas corretamente.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 21
Requisitos Processo de software da PBH/Prodabel 41
Análise de impacto
• Geralmente desenvolvida por um técnico com grande
conhecimento. Possui três aspectos:
• Entender as possíveis implicações de se fazer a mudança.
• Identificar todos arquivos, modelos e documentos que devem ser 
modificados se a mudança ocorrer.
• Identificar tarefas necessárias para implementar a mudança e estimar o 
esforço, tempo e recursos necessários.
• Importante: deixar de analisar impacto não muda o tamanho da
tarefa mas deixa o escopo do trabalho como uma surpresa.
• Você já viu realizar-se análise de impacto em algum projeto?
______________________________________________________
Requisitos Processo de software da PBH/Prodabel 42
Rastreabilidade de requisitos
• Rastreabilidade é a característica que permite
acompanhar a vida de um requisito, desde a origem até
a implementação.
• A rastreabilidade pode ajudar a:
• garantir que os requisitos especificados são associados as 
necessidades dos clientes.
• garantir que todo produto de trabalho está associado aos
requisitos identificados.
• A restreabilidade deve ser BIDIRECIONAL, ou seja, 
permitir que se caminhe nos dois sentidos.
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 22
Requisitos Processo de software da PBH/Prodabel 43
Matriz de rastreabilidade
• Legenda:
– U: o requisito da linha “usa”o requisito da coluna
– R: há um relacionamento entre os requisitos
Requisitos Processo de software da PBH/Prodabel 44
Requisitos e ferramentas CASE
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 23
Requisitos Processo de software da PBH/Prodabel 45
Requisitos e ferramentas CASE
Requisitos Processo de software da PBH/Prodabel 46
Requisitos e ferramentas CASE
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 24
Requisitos Processo de software da PBH/Prodabel 47
Requisitos e ferramentas CASE
Requisitos Processo de software da PBH/Prodabel 48
Requisitos e ferramentas CASE
Processo de software PBH/Prodabel
C2-Engenharia de requisitos 25
Requisitos Processo de software da PBH/Prodabel 49
Referências Bibliográficas
• WIEGERS, Karl, Software requirements, 2º
edition, 2006.
• SOMMERVILLE, Ian, Engenharia de Software, 
Addison Wesley, 6ª edição, 2003.
• PRESSMAN, Roger S., Engenharia de Software, 
McGraw Hill, 5ª Edição, 2002.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 1
Processo de Software da PBH/Prodabel – PSP
Gerência de Engenharia de Software (GESS-PB)
Superintendência de Arquitetura de Sistemas (SAS-PB)
Diretoria de Sistemas e Informação (DS-PB)
Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A)
Versão 1.2
Técnicas de levantamento (elicitação) 
de requisitos de software
Técnicas de elicitação Processo de software da PBH/Prodabel 2
Objetivos
• Apresentar as principais técnicas para o 
levantamento (elicitação) de requisitos.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 2
Técnicas de elicitação Processo de software da PBH/Prodabel 3
Roteiro
• Observação pessoal.
• Pesquisa.
• Questionário.
• Entrevista.
• Reuniões.
• Brainstorming.
• JAD
Técnicas de elicitação Processo de software da PBH/Prodabel 4
Observação pessoal
• Consiste em conviver com situações cotidianas.
• Possibilita a confirmações recebidas como: leiaute, 
problemas de relacionamento, erros de 
procedimento, segurança do trabalho, etc.
• Vantagens: não interrupção das atividades, não
exigência de disponibilidade do tempo de 
envolvidos.
• Desvantagens: ausência de evidências formais, 
causar mal-estar na área envolvida, conclusões
comprometedoras.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 3
Técnicas de elicitação Processo de software da PBH/Prodabel 5
Pesquisas
• Pesquisa interna: averiguação física de uma
atividade e processo.
• Vantagens: percepção do pesquisador, 
esclarecimento de dúvidas.
• Desvantagens: cria “mal estar” entre os
participantes, demanda muito tempo.
• Pesquisa externa: utilizada quando não se dispõe
de qualquer experiência para descrever os
requisitos. Utiliza informações de acervos externos
sociedades profissionais, periódicos, livros técnicos
e relatórios de pesquisa.
Técnicas de elicitação Processo de software da PBH/Prodabel 6
Questionário
• Instrumento que envolve os processos de 
preparação em formulário, distribuição, 
recolhimento e tabulação.
• Pode ser precedido de um pré-teste.
• Vantagens: agilidade, custo, facilidade, 
abrangência de pessoas, mensuração uniforme, 
anonimato, ausência de pressão por resultados
imediatos.
• Desvantagens: manipulação de respostas antes 
de entregar, tendência de utilização de resposta
padrão, frieza.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 4
Técnicas de elicitação Processo de software da PBH/Prodabel 7
Entrevista
• Diálogo entre entrevistado e entrevistador.
• Vantagens: as perguntas podem ser alteradas
(conteúdo, ordem, eliminação, inclusão), podem ser 
esclarecidos pontos das perguntas, podem ser 
avaliadas as reações dos entrevistados, pode-se 
motivar o entrevistado.
• Desvantagens: alcança menos pessoas, tratamento
diferenciado aos entrevistados, desvios de curso, 
demanda tempo, avaliações subjetivas, alterações nas
perguntas e conteúdo, desestimulo, impossibilidade de 
avaliação prévia, respostas politicamente corretas.
Técnicas de elicitação Processo de software da PBH/Prodabel 8
Seminário
• Reunião planejada de pessoas-chave de diversas
áreas com o objetivo de obter informações gerais
sobre a empresa.
• Também chamada de workshops e dinâmica de 
grupo.
• Vantagens: rapidez na identificação de problemas
de relacionamento, estrangulamentos e visão
integrada de problemas.
• Desvantagens: mobilizar um grande número de 
pessoas ao mesmo tempo, interferindo na rotina de 
trabalho da empresa.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 5
Técnicas de elicitação Processo de software da PBH/Prodabel 9
Brainstorming
• Técnica de obtenção de informações em reuniões. Etapas:
• Geração de idéias:
• Não permitir críticas ou debates;
• Deixar a imaginação voar;
• Procurar quantidade;
• Mudar e combinar idéias.
• Seleção de idéias:
• Decidir com base em um limite de votos
• Decidir com base em discurso de campanha
• Juntar idéias e aplicar critérios;
• Utilizar sistemas de pontuação.
Técnicas de elicitação Processo de software da PBH/Prodabel 10
JAD
� Joint Application Design (Projeto de Aplicação 
Conjunta).
� Método criado pela IBM no ano de 1977.
� Consiste em reuniões estruturadas intensivas e em 
grupo, onde participam os representantes do usuário e 
da informática.
� Cada sessão é composta por uma ou mais reuniões e 
dura de um a três dias.
� Toda reunião é conduzida por um facilitador (ou 
mediador) que visa obter o consenso de forma rápida.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 6
Técnicas de elicitação Processo de software da PBH/Prodabel 11
Principais características do JAD
� As reuniões substituem as entrevistas individuais.
� O processo de trabalho é altamente estruturado.
� Os papéis são bem definidos.
� As decisões são baseadas em consenso.
� O facilitador elimina as barreiras de comunicação.
� Os recursos visuais dinamizam o trabalho.
Técnicas de elicitação Processo de software da PBH/Prodabel 12
Reuniões ao invés de entrevistas
� Os usuários se sentem prestigiados e parte integrante do 
processo, visto que suas opiniões são consideradas.
� As divergências são resolvidas pelo grupo, pois todas as 
idéias são discutidas por todos.
� Pode significar grande economia de tempo de 
desenvolvimento. Entretanto, a carga horária alocada ao 
projeto tende a ser maior se comparada ao uso de 
entrevistas individuais, devido a uma participação mais 
intensa dos usuários.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 7
Técnicas de elicitação Processo de software da PBH/Prodabel 13
Processo de trabalho estruturado
� Os produtos a serem alcançados são previamente 
discutidos e são a base de todo o trabalho. 
� Cada sessão tem sua finalidade definida e todos os 
participantes conhecem os resultados esperados. 
� Os trabalhos de cada sessão são feitos baseados 
em uma agenda padrão adotada em todas as 
reuniões. Somente a abordagem da sessão é que 
varia.
� Os resultados são insumos para o projeto.
Técnicas de elicitação Processo de software da PBH/Prodabel 14
Papéis são bem definidos
� Executivo patrocinador: autoridade das áreas de negócio 
envolvidas. Redime conflitos, estabelece as diretrizes e 
objetivos e abre os trabalhos.
� Gerente de projeto: principal contato do facilitador durante o 
processo.
� Equipe: responsável pelo conteúdo da sessão. São as pessoas-
chave das áreas envolvidas, em todos os níveis.
� Facilitador: Guia imparcial, garante participação e consenso.
� Documentador: registra decisões tomadas.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 8
Técnicas de elicitação Processo de software da PBH/Prodabel 15
Decisões baseadas em consenso
� Consenso não é a unanimidade, mas a concordância 
de que a solução encontrada é a melhor para o 
grupo.
� Consenso também é aquela solução com a qual os 
participantes irão conviver sem ferir suas próprias 
convicções e valores essenciais.
� A forma mais produtiva de decisão em grupo é aquelabaseada em consenso.
� A condução ao consenso é a principal tarefa do 
facilitador.
Técnicas de elicitação Processo de software da PBH/Prodabel 16
Facilitador elimina barreiras de 
comunicação
� O facilitador é uma pessoa neutra do grupo que 
não avalia nem contribui com idéias. 
� Sugere métodos que ajudem o grupo a concentrar 
energia em tarefas específicas.
� Protege todos os membros do grupo contra 
ataques.
� Garante a participação de todos de forma 
homogênea. 
� A presença do facilitador torna a reunião mais 
produtiva.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 9
Técnicas de elicitação Processo de software da PBH/Prodabel 17
Recursos visuais dinamizam o 
trabalho
� O andamento das sessões se beneficia do uso de 
recursos visuais como transparências, slides, 
vídeos, flipcharts, micros etc. 
� Todos os resultados das discussões são exibidos 
através de recursos adequados para que todos 
possam ver.
� Tais recursos estimulam os sentidos, esclarecem 
pontos confusos e fazem uso eficaz do tempo.
Técnicas de elicitação Processo de software da PBH/Prodabel 18
Detalhamento do processo JAD
� Tipos de sessões JAD: gerenciais e técnicas.
� Ciclo de trabalho de uma sessão: preparação, 
execução e revisão.
� Agenda padrão de uma sessão: introdução, revisão 
de perspectiva gerencial, abertura pelo executivo 
patrocinador, visão da área de informática, regras 
de conduta, abordagem da sessão, revisão de 
pendências, revisão geral, avaliação da sessão.
� Abordagem da sessão: varia de acordo com o tipo 
de sessão.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 10
Técnicas de elicitação Processo de software da PBH/Prodabel 19
Sessão de gerenciamento
� Visa discutir o escopo do projeto, objetivos, metas, 
recursos e estratégias a serem adotadas. É
tipicamente a primeira sessão de um projeto, 
permitindo identificar suas partes componentes e 
prioridades.
� Participantes: gerentes de alto nível e executivos das 
áreas de negócios envolvidas, bem como o 
representante da área de informática
� Número de participantes: máximo 20
Técnicas de elicitação Processo de software da PBH/Prodabel 20
Sessão técnica
� Define as funções componentes do sistema, a lógica 
de funcionamento do negócio e de que forma os 
elementos se relacionam e são tratados.
� Devem ser orientadas par suprir as informações 
necessárias à criação dos modelos de dados e 
processos.
� Participantes: gerentes e supervisores das áreas de 
negócio. Devem ser capazes de conhecer o negócio, 
fluxos de trabalho.
� Número de participantes: máximo 10
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 11
Técnicas de elicitação Processo de software da PBH/Prodabel 21
Ciclo de trabalho JAD
� Devido ao seu alto grau de planejamento, 
estruturação e formalização, o JAD pode ser 
visualizado como um ciclo de processo que engloba 
as fases:
− Preparação;
− Sessão (a execução de uma sessão);
− Revisão.
Técnicas de elicitação Processo de software da PBH/Prodabel 22
Ciclo de trabalho - preparação
� Examinar adequação do JAD: avaliar em conjunto 
com o gerente de projeto: os riscos (para o negócio, 
projeto e técnica), tamanho do projeto, domínio da 
metodologia, etc.
� Planejar: dimensionar nº de sessões, duração, 
alocação de recursos.
� Elaborar a perspectiva gerencial: finalidade, escopo, 
objetivos e restrições.
� Familiarizar-se com a área de negócios: entrevistar 
participantes previamente.
� Preparar agenda da sessão: seguir padrão.
� Preparar participantes: informar agenda e pedir 
“exercício de casa”.
� Preparar ferramenta de documentação.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 12
Técnicas de elicitação Processo de software da PBH/Prodabel 23
Ciclo de trabalho - sessão
� Preparar ambiente: arrumação das mesas, verificação 
dos equipamentos audiovisuais, checklist dos 
materiais, preparação de pastas.
� Condução da sessão: apresentação dos participantes, 
explicar agenda, abordar logística, rever perspectiva 
gerencial, desenvolver agenda.
� Documentação: anotar todas as deliberações da 
reunião, ler todo o material e gerar documentação.
� Encerramento: revisão geral da agenda, avaliação da 
sessão, entrega da documentação produzida.
Técnicas de elicitação Processo de software da PBH/Prodabel 24
Ciclo de trabalho - revisão
� Rever documentação: verificar se informações estão 
corretas, corrigir falhas de comunicação, encaminhar 
documentação aos participantes.
� Examinar avaliações: avaliar se o método está sendo 
efetivamente útil e a satisfação dos participantes.
� Preparar pasta do projeto: contendo perspectiva 
gerencial, plano de sessões, agenda de cada sessão, 
lista de participantes de cada sessão, documentação 
produzida em cada sessão e questionários de 
avaliação.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 13
Técnicas de elicitação Processo de software da PBH/Prodabel 25
Elaboração da agenda JAD
� Identificar a finalidade e objetivos da sessão.
� Identificar produtos (resultados esperados).
� Identificar as informações conhecidas.
� Esboçar as etapas da agenda.
� Verificar coerência lógica das etapas.
� Identificar os participantes prováveis.
� Identificar as etapas que os participantes não tem 
condições de realizar na sessão.
� Identificar os dados prévios para as sessões.
Técnicas de elicitação Processo de software da PBH/Prodabel 26
Agenda padrão JAD
� Introdução: 
− Data, local, início e fim previstos
− Objetivos: Levantamento, acompanhamento, informativa, definição de 
tarefas, tomada de decisões, etc. 
− Moderador, demais participantes e funções
− Atividades prévias
− Regras de conduta
� Abordagem da sessão:
− Desenvolvimento dos itens específicos da pauta
� Revisão
− Pendências
− Conclusões
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 14
Técnicas de elicitação Processo de software da PBH/Prodabel 27
Agenda padrão JAD - Introdução
� Revisão do JAD, papéis, horários, apresentação dos 
participantes e da agenda.
� Revisão da perspectiva gerencial: comentários sobre a 
definição da alta gerência.
� Abertura pelo executivo patrocinador: mostra o apoio da 
cúpula, importância, objetivos e motivo de escolha da 
equipe.
� Visão da área de Informática: questões tecnológicas e de 
andamento de projeto.
� Regras de conduta: comportamentos indicados para 
sessão.
Técnicas de elicitação Processo de software da PBH/Prodabel 28
Agenda padrão JAD – Abordagem da 
sessão
� Passos específicos para se alcançar os 
objetivos da sessão.
− Finalidade
− Produto esperado
− Processo envolvido
− Sequência
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 15
Técnicas de elicitação Processo de software da PBH/Prodabel 29
Agenda padrão JAD – Revisão
� Revisão das pendências: situação do item, 
responsável e data prevista para a solução.
� Revisão geral: rápida passagem pelo material 
produzido para verificar se o resultado está coerente e 
coeso, de acordo com o previsto.
� Avaliação da sessão: obtenção do feedback dos 
participantes sobre o método utilizado e desempenho 
do facilitador.
Técnicas de elicitação Processo de software da PBH/Prodabel 30
Considerações sobre o JAD
� Enquanto técnica, o JAD propõe captar os pontos 
principais das demais técnicas visando tornar mais 
produtivas as reuniões.
� A estrutura do JAD pressupõe um trabalho considerável 
de documentação e atividades preliminares e 
posteriores.
� É óbvia a importância e uso de reuniões como 
mecanismos de interação entre pessoas em qualquer 
aspecto da sociedade.
� Para qualquer situação de reunião profissional pode ser 
seguido o modelo do JAD.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 16
Técnicas de elicitação Processo de software da PBH/Prodabel 31
Exemplo de agenda JAD - Introdução
� Explicação: serão explicados aspectos preliminares 
sobre a sessão (Duração: 10 Min.). Aspectos:
− Período: 1, 2 e 3/4 de 2009;
− Horário: 8h às17h. Intervalo: 10h às 10h15, 15h30 às 
15h45. Almoço: 12h às 13h.
− Recursos disponíveis: Projetor, computador, quadro 
magnético e flipchart.
− Apresentação dos participantes: Nicolau dos Santos 
(Executivo patrocinador), Philip Kotler (Gerente de 
Marketing), Bill Gates (Gerente de Informática), 
Domenico de Masi (Gerente de RH), José Silva 
(Facilitador) e Sra. Maria Santos (Documentadora).
Técnicas de elicitação Processo de software da PBH/Prodabel 32
Exemplo de agenda JAD – Introdução
� Funcionamento do JAD: O Sr. José Silva fará uma 
explicação do JAD e suas principais características 
como trabalho em equipe, decisão por consenso, 
papel do facilitador, agenda, etc.
� Apresentação dos assuntos da agenda: Serão lidos 
os itens da Abordagem da Sessão.
� Revisão da perspectiva gerencial: Os participantes 
expressarão suas opiniões e sugestões. Duração 50 
Min.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 17
Técnicas de elicitação Processo de software da PBH/Prodabel 33
Exemplo de agenda JAD – Introdução
� Abertura pelo executivo patrocinador: O Sr. 
Nicolau dos Santos mostrará a importância do 
projeto no contexto do negócio, o que a 
administração pretende alcançar e por que 
aquela equipe foi escolhida. Duração: 15 Min.
� Visão da área de informática: O Sr. Bill Gates 
falará das atuais tecnologias e tendências no 
escopo do projeto. Duração: 20 Min.
Técnicas de elicitação Processo de software da PBH/Prodabel 34
Exemplo de agenda JAD – Introdução
� Regras de conduta: Serão explicadas as normas de 
comportamento a serem seguidas durante a sessão. 
São vedadas conversas em paralelo, utilização de 
telefone celular, interromper a fala de outro 
participante, fumar durante a sessão, críticas 
destrutivas ou pessoais a opinião de outros 
participantes. Duração 5 Min.
� Abordagem da sessão: Nesta etapa serão discutidos 
os assuntos específicos da sessão. Os assuntos serão 
divididos em seis etapas. Duração: 3:00 H.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 18
Técnicas de elicitação Processo de software da PBH/Prodabel 35
Exemplo de agenda - Abordagem da sessão
� Tema 1: Descrição do ambiente atual
− Início: 8h. Duração: 1h.
− Finalidade: Descrever a situação atual e as áreas de negócios.
− Produto esperado: descrição da situação atual, incluindo: 
processos atuais (possibilidades, pontos fortes e fracos, 
restrições), situação competitiva e oportunidades para a 
organização.
− Processo envolvido: participantes deverão preencher 
previamente um questionário que será apresentado durante a 
sessão.
− Sequência: Discussão dos pontos apresentados, brainstorming, 
seguido de votação.
Técnicas de elicitação Processo de software da PBH/Prodabel 36
Exemplo de agenda - Abordagem da sessão
� Tema 2: Descrição dos problemas das áreas.
− Início: 10 H 15. Duração: 1 H 30.
− Finalidade: Apontar os principais erros existentes na 
situação atual. Serão usados para definir e justificar 
objetivos e soluções a serem adotadas.
− Produto esperado: descrição dos problemas atuais do 
negócio.
− Processo envolvido: Idem tema 1.
− Sequência: Brainstorming, seguido de votação.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 19
Técnicas de elicitação Processo de software da PBH/Prodabel 37
Exemplo de agenda - Abordagem da sessão
� Tema 3: Descrição dos objetivos para a nova situação. 
− Início: 13 H. Duração: 1 H.
− Finalidade: Listar os objetivos a serem alcançados através de 
modificações nas áreas de negócios. Os objetivos devem estar 
associados a problemas encontrados na etapa anterior.
− Produto esperado: descrição de todos os objetivos.
− Processo envolvido: Idem ao tema 1.
− Sequência: Idem ao tema 2.
Técnicas de elicitação Processo de software da PBH/Prodabel 38
Exemplo de agenda - Abordagem da sessão
� Tema 4: Descrição dos requisitos. 
− Início: 14h. Duração: 1 H 30.
− Finalidade: Definição das soluções (requisitos) para a nova 
situação esperada. Define como serão alcançados os 
objetivos.
− Produto esperado: descrição dos requisitos.
− Processo envolvido: Idem ao tema 1.
− Sequência: Idem ao tema 1.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 20
Técnicas de elicitação Processo de software da PBH/Prodabel 39
Exemplo de agenda - Abordagem da sessão
� Tema 5: Descrição das restrições para os requisitos. 
− Início: 15 H 45. Duração: 30 Min.
− Finalidade: Definição de restrições de ordem física, política, 
legal, que possam afetar os requisitos estabelecidos. As 
restrições determinam limites, fronteiras e balizamentos para 
o sistema.
− Produto esperado: descrição das restrições.
− Processo envolvido: Idem ao tema 1.
− Sequência: Idem ao tema 1.
Técnicas de elicitação Processo de software da PBH/Prodabel 40
Exemplo de agenda - Abordagem da sessão
� Tema 6: Prioridade dos requisitos. 
− Início: 16 H 15. Duração: 30 Min.
− Finalidade: Dar prioridade aos requisitos.
− Produto esperado: Indicação da prioridade de cada 
requisito.
− Processo envolvido: através do estabelecimento dos 
critérios de prioridade como custo, competitividade, 
facilidade de implementação e posterior associação a cada 
requisito.
− Sequência: Descrição de cada item e votação.
Processo de software PBH/Prodabel
C3-Técnicas de elicitação 21
Técnicas de elicitação Processo de software da PBH/Prodabel 41
Exemplo de agenda JAD - Revisão
� Revisão de pendências: Serão resolvidas as pendências e 
agendadas novas. Consiste em: Descrição da pendência, 
situação, responsável, data para solução. Duração 5 Min.
� Revisão geral: Será feita uma passagem pelo material produzido 
na sessão, avaliando os resultados obtidos. Duração 5 Min.
� Avaliação da sessão: Será obtido o feedback de todos os 
participantes sobre o método utilizado e sobre o comportamento 
do facilitador, visando adequar e melhorar o processo para as 
próximas sessões. Duração 5 Min.
Técnicas de elicitação Processo de software da PBH/Prodabel 42
Referências bibliográficas
� Costa, Wilson Dias Da - JAD Joint Application 
Design, Ibpi Press, 1994.
� Gause, D. e Weinberg, G. Explorando 
Requerimentos de Sistemas, Makron Books, 1989.
Processo de software PBH/Prodabel
C4-Casos de uso 1
Processo de Software da PBH/Prodabel – PSP
Gerência de Engenharia de Software (GESS-PB)
Superintendência de Arquitetura de Sistemas (SAS-PB)
Diretoria de Sistemas e Informação (DS-PB)
Empresa de Informática e Informação de Belo Horizonte (Prodabel S/A)
Versão 1.2
Casos de uso
Requisitos Processo de software da PBH/Prodabel 2
Objetivos
� Descrever as dificuldades encontradas para se 
modelar sistemas com base somente em
requisitos.
� Mostrar como os casos de uso se encaixam na
modelagem de comportamento dos sistemas.
� Especificar as diretrizes para a escrita de casos
de uso efetivos.
Processo de software PBH/Prodabel
C4-Casos de uso 2
Requisitos Processo de software da PBH/Prodabel 3
Roteiro
� Requisitos e casos de uso
� Definição de caso de uso
� Definição de ator
� Relacionamentos
� Diagrama de caso de uso
� Estrutura de um caso de uso
� Descrição de um caso de uso
� Processo de modelagem de casos de uso
� Diretrizes para elaboração de casos de uso
Requisitos Processo de software da PBH/Prodabel 4
Interessados nos requisitos
� Clientes: Precisam saber se o sistema está sendo
desenvolvido conforme desejam.
� Gerentes: Precisam ter um entendimento geral do 
que o sistema irá fazer de forma a planejar e 
controlar o projeto.
� Analistas: Precisam descrever e documentar o 
que o sistema irá fazer.
� Desenvolvedores: Precisam entender o que o 
sistema deve fazer para implementa-lo.
� Testadores: Precisam saber o que o sistema
deveria fazer para poder verifica-lo.
Processo de software PBH/Prodabel
C4-Casos de uso 3
Requisitos Processo de software da PBH/Prodabel 5
Natureza dos requisitos
Necessidades
Requisitos de usuário
Domínio da
solução
Requisitos de sistemas
Requisitos de desenho
Domínio do 
problema
Produtoa ser 
construído
Requisitos Processo de software da PBH/Prodabel 6
Separação entre domínios
� A separação em domínios indica que os
requisitos de software tratam da solução e não
do problema.
� O formato da pirâmide reflete o volume relativo
do problema: poucas necessidades podem exigir
vários requisitos.
� O relacionamento de rastreabilidade deve ser 
mantido entre todos os níveis.
Processo de software PBH/Prodabel
C4-Casos de uso 4
Requisitos Processo de software da PBH/Prodabel 7
Rastreabilidade dos requisitos
N1
Ru1 Ru2
Nx
Ruy
Rs1 Rs2 Rs3 Rsz
Rd1 Rd2 Rd3 Rd4 Rdn
P: Essa figura representa rastreabilidade uni ou bidirecional? ___________________
Requisitos Processo de software da PBH/Prodabel 8
Limitações dos requisitos
• Dados os requisitos de um caixa eletrônico:
– O sistema deve permitir clientes fazer saques de 
suas contas.
– O sistema deve assegurar que o limite da conta
nunca será ultrapassado.
– Se um cliente tentar sacar de um caixa que não
pertença a instituição em que tem conta, o sistema
deve cobrar uma taxa.
• Surgem as questões:
– Em qual ordem essas coisas devem ser feitas
(caso a ordem importe)?
– A taxa deve ser cobrada antes ou depois do 
saque?
Processo de software PBH/Prodabel
C4-Casos de uso 5
Requisitos Processo de software da PBH/Prodabel 9
Limitações dos requisitos
• Para um dado conjunto de requisitos, pode ser 
praticamente impossível entender o que os
autores dos requisitos querem que seja feito.
• Os requisitos normalmente são ambíguos e 
incompletos pois não informam quando e sob 
quais condições os comportamentos ocorrem.
• A seqüência é um requisito em certos casos.
• Os requisitos tradicionais capturam abordagens, 
com ênfase em requisitos declarativos e 
sentenças do tipo “deve”, falhando em capturar o 
comportamento dinâmico do sistema.
• Outra: ___________________________________
Requisitos Processo de software da PBH/Prodabel 10
Modelagem de casos de uso
• Um caso de uso é uma forma de expressar
os requisitos do sistema, especialmente seu
comportamento.
• A idéia básica por trás da modelagem de um 
caso de uso é a seguinte:
–Capturar a essência do que um sistema deve
fazer. Para tal, deve-se inicialmente observar
quem irá usar o sistema.
–Depois disso, deve-se pensar no que o 
sistema deverá fazer para realizar o que o 
usuário necessita.
Processo de software PBH/Prodabel
C4-Casos de uso 6
Requisitos Processo de software da PBH/Prodabel 11
Casos de uso no contexto dos requisitos
Necessidades
Requisitos
funcionais
Requisitos
não funcionaisCasos
de uso
Especificação
suplementar
Especificação
suplementar
P: Casos de uso são uma especificação completa de todos os requisitos? ___________
Requisitos Processo de software da PBH/Prodabel 12
Casos de uso e requisitos
� Um caso de uso contém a especificação de um 
conjunto de requisitos, apresentados de forma 
narrativa ao invés de estrutura de tópicos ou outra
(lembra dos fluxogramas?).
� Um caso de uso coloca os requisitos no contexto da
descrição de algo que o usuário deseja.
� A granularidade dos requisitos e dos casos de uso é
bastante diferente. Explique: ___________________
� Casos de uso expressam comportamento: Quando
bem escritos, os casos de uso especificam
exatamente o que o sistema deve fazer.
Processo de software PBH/Prodabel
C4-Casos de uso 7
Requisitos Processo de software da PBH/Prodabel 13
Casos de uso e requisitos
� Casos de uso são uma boa técnica para
modelagem de requisitos. Eles provêm uma
maneira padronizada de capturar, explorar e 
documentar o que um sistema deve fazer.
� Um caso de uso pode atender a vários requisitos
e um mesmo requisito pode ser atendido por um 
ou vários casos de uso. Dê um exemplo: 
________________________________________
� Um requisito não é um caso de uso e vice 
versa.
Requisitos Processo de software da PBH/Prodabel 14
Casos de uso e a natureza dos requisitos
� Casos de uso capturam “facilmente” (sob o ponto de vista do 
usuário) conjuntos de requisitos funcionais, descrevendo o 
comportamento do sistema como uma interação entre usuários ou
outros sistemas e o sistema em questão, para fazer algo útil, 
conforme seus interesses.
� Casos de uso não envolvem: interfaces externas, formatos de 
dados, regras de negócio e fórmulas, algumas vezes complexas.
� Requisitos não funcionais são melhor descritos usando textos
declarativos ou meios visuais. 
� Descrever requisitos não funcionais por meio de casos de uso é
uma maneira de confundir ambos. Exemplo:
_______________________________________________________
Processo de software PBH/Prodabel
C4-Casos de uso 8
Requisitos Processo de software da PBH/Prodabel 15
Modelo de casos de uso
� “Um modelo de caso de uso é um modelo de um 
sistema definido em termos de casos de uso, 
atores e o relacionamento entre eles” [OMG].
� Um modelo de caso de uso pode conter um 
conjunto de diagramas de caso de uso, 
agrupados por similaridade.
� Modelos de caso de uso provêm uma boa visão
geral sobre o sistema. Entretanto, a grande força
dos casos de uso está em sua descrição textual, 
que será vista mais à frente.
Requisitos Processo de software da PBH/Prodabel 16
Representação de casos de uso
� Um caso de uso descreve como um ator usa um 
sistema para atingir um objetivo e o que o sistema
faz para o ator atingir seus objetivos.
� Descreve uma estória de como um sistema e seus
atores colaboram para um dados objetivo.
� A UML representa casos de uso como elipses:
Processo de software PBH/Prodabel
C4-Casos de uso 9
Requisitos Processo de software da PBH/Prodabel 17
Atores
� “Conjunto coerente de papéis que os usuários
exercem quando interagem com os casos de 
uso”. [OMG]
� Aspectos chave dos atores:
− Representam pessoas ou outros sistemas.
− Definem os papéis que os usuários ou outros
sistemas exercem.
− Estão fora do sistema, e geralmente fora do controle
do mesmo.
− Impõem requisitos que o sistema deve atender.
Requisitos Processo de software da PBH/Prodabel 18
Representação de atores
� Um ator define um papel que um usuário pode
exercer quando interage com o sistema. Um 
usuário ainda pode um indivíduo ou outro
sistema.
� A UML representa atores como bonecos:
Processo de software PBH/Prodabel
C4-Casos de uso 10
Requisitos Processo de software da PBH/Prodabel 19
Stakeholders e atores
� Stakeholder é alguém ou algo que tem um 
interesse legal no comportamento do caso de 
uso. Obs: conceito análogo à GP. 
� Um ator é qualquer coisa que tem um 
comportamento. Um ator pode ser uma pessoa, 
companhia ou organização, um programa de 
computador ou um sistema computacional
� Todo ator primário, é naturalmente, um 
stakeholder, mas alguns stakeholders nunca
interagem diretamente com o sistema.
Requisitos Processo de software da PBH/Prodabel 20
Ator primário
� É o stakeholder que chama o sistema para entregar um 
de seus serviços. Ele tem um objetivo com respeito ao
sistema - que pode ser satisfeito por sua operação.
� Geralmente o caso de uso começa porque o ator
primário envia uma mensagem, pressiona um botão, 
pressiona uma tecla ou de alguma outra forma inicia a 
estória.
� Entretanto, há pelo menos duas situações em que um 
UC não é iniciado por um ator primário: 
− Quando, por exemplo, um operador de telefone inicia o caso
de uso em nome de um cliente. 
− Quando o caso de uso é acionado pelo ator “tempo”.
Processo de software PBH/Prodabel
C4-Casos de uso 11
Requisitos Processo de software da PBH/Prodabel 21
Atores secundários
� Atores externos que provêm um serviço ao
sistema. 
� Devem ser identificados a fim de achar as 
interfaces externas que o sistema usará e os
protocolos que cruzam essas interfaces.
� Um ator pode ser primário em um caso de uso e 
secundário em outro. Exemplo:
_________________________________________
Requisitos Processo de software da PBH/Prodabel 22
Comunicação entre ator e caso de uso
� Razões para o ator acionar o caso de uso:
− Solicitar dados armazenados no sistema.
− Mudardados armazenados no sistema.
− Informar que algo importante aconteceu em torno do 
sistema.
� Razões para o caso de uso acionar o ator:
− Informar ao ator se algo importante aconteceu com o 
sistema.
− Pedir apoio para tomada de alguma decisão.
− Delegar responsabilidades a atores.
Processo de software PBH/Prodabel
C4-Casos de uso 12
Requisitos Processo de software da PBH/Prodabel 23
Relacionamentos
� Casos de uso e atores não existem sozinhos.
� A UML define diversos de relacionamentos no 
modelo de casos de uso:
− Comunicação: Interação direta entre ator e caso de uso. É a 
situação mais comum.
− Inclusão: Provê a habilidade de extrair seções comuns
entre dois ou mais casos de uso e coloca-las em um caso
de uso separado, favorecendo o reuso.
− Extensão: Usado em casos onde um comportamento
opcional ou excepcional é inserido em um caso de uso
existente.
− Generalização: Usado quando elementos possuem
comportamentos em comum. Ex: atores.
Requisitos Processo de software da PBH/Prodabel 24
Diagramas do modelo de caso de uso
• Diagrama com uma visão geral com principais
atores e casos de uso. Também chamado, por
alguns autores, “Diagrama de Contexto”. 
• Diagrama somente com atores correlatos.
• Diagrama da perspectiva de um único ator, 
mostrando casos de uso e demais atores a ele
associados.
• Diagramas somente com casos de uso correlatos.
• Diagramas da perspectiva de um único caso de 
uso, mostrando atores e demais casos de uso a ele
associados.
Processo de software PBH/Prodabel
C4-Casos de uso 13
Requisitos Processo de software da PBH/Prodabel 25
Exemplo de diagrama de caso de uso
Detalhar pagamento
Fazer pagamento com 
dinheiro
Fazer pagamento com 
cheque
Requisitos Processo de software da PBH/Prodabel 26
Descrição de Casos de Uso
� “Descrição de um conjunto de seqüências de 
ações, incluindo variações, que um sistema
executa para atingir um resultado de valor
observável para um ator em particular”. [OMG]
� Aspectos chave de caso de uso:
− É iniciado por um ator.
− É provido pelo sistema (“responde ao ator”).
− Pode envolver mais de um ator.
− Descreve como o sistema e seus atores colaboram
para atender o objetivo do ator.
− Provê uma imagem coerente de como o sistema será
usado.
Processo de software PBH/Prodabel
C4-Casos de uso 14
Requisitos Processo de software da PBH/Prodabel 27
Descrição de um caso de uso
� A UML define que os casos de uso possuem dois
elementos de modelagem: uma representação gráfica e 
uma descrição textual.
� Entretanto, não é definido um padrão para a descrição
textual de um caso de uso.
� Portanto, a descrição de um caso de uso pode variar
desde um texto livre com alguns parágrafos até uma
estrutura de dados com campos bem delimitados. 
� Há vantagens e desvantagens em ambas abordagens. Ex:
− Vantagem: __________________________________________
− Desvantagem: _______________________________________
Requisitos Processo de software da PBH/Prodabel 28
Estrutura geral de um caso de uso
� Identificação
− Nome
� Descrição
− Pré-condições
− Pós-condições
− Fluxo de eventos
� Fluxo principal (mais comum)
� Fluxos alternativos
� Fluxos de exceção
� Sub-fluxos (deve-se evitar)
Processo de software PBH/Prodabel
C4-Casos de uso 15
Requisitos Processo de software da PBH/Prodabel 29
Estrutura de um caso de uso
� Nome: Deve ser único e identificar o que é atingido
através da interação entre o caso de uso e o ator.
� Descrição:
− Pré-condições: Descrição textual que define restrições
quando o caso de uso deve iniciar.
− Pós-condições: Descrição textual que define restrições
quando o caso de uso termina. 
− Fluxo de eventos: Descrição textual do que o sistema faz
em relação ao caso de uso. É estruturado em:
� Fluxo principal: Fluxo principal ou padrão.
� Fluxos alternativos: Fluxos com cenários alternativos ao principal.
� Sub-fluxos: Subdivisão de um fluxo para fins de clareza. EVITAR!
Requisitos Processo de software da PBH/Prodabel 30
Descrição de um caso de uso
� A descrição de um caso de uso narra uma estória de 
como o sistema e seus atores colaboram para atingir um 
objetivo específico.
� É uma descrição passo a passo de uma forma particular 
de usar o sistema. A estrutura de um caso de uso é
narrativa por natureza.
� Todo caso de uso deve ter:
− Início (como o ator inicia o caso); 
− Meio (como sistema e atores interagem);
− Fim (como o caso de uso é encerrado).
Processo de software PBH/Prodabel
C4-Casos de uso 16
Requisitos Processo de software da PBH/Prodabel 31
Importância da descrição textual
� Cerca de 90% do modelo de caso de uso reside 
nas descrições. Portanto, é a parte mais
trabalhosa de se modelar.
� A parte mais importante de um caso de uso é a 
descrição.
� A parte mais importante da descrição é o fluxo de 
eventos.
� O fluxo de eventos tem uma estrutura bem
definida, baseada nos conceitos dos fluxos
principal, alternativos e de exceção.
Requisitos Processo de software da PBH/Prodabel 32
Cenários (fluxos) e passos
� Um conjunto de casos de uso é uma estória já
desdobrada de atores primários perseguindo
objetivos. Cada caso de uso tem um enredo
cruzado e mostra o sistema alcançando o objetivo
ou o abandonando. É um descrição “teatral”.
� Esse enredo está presente na forma de um cenário
básico e um conjunto de fragmentos de cenários, 
como extensões dele.
� Cada cenário ou fragmento começa com uma
condição de acionamento que indica quando ele é
executado e vai até mostrar a conclusão ou o 
abandono de seu objetivo.
Processo de software PBH/Prodabel
C4-Casos de uso 17
Requisitos Processo de software da PBH/Prodabel 33
Estrutura típica de fluxo de eventos
Fluxo principal
Fluxo alternativo
Fluxo alternativo
Requisitos Processo de software da PBH/Prodabel 34
Fluxo principal
� Descrição, de cima para baixo, de um cenário
bastante característico no qual o objetivo do ator
primário é alcançado e todos interesses dos 
stakeholders são satisfeitos.
� O fluxo principal descreve a forma mais usual 
(padrão) de se atingir os objetivos do ator
principal.
� Todas as outras maneiras de ter sucesso e o 
tratamento de todas as falhas, são descritos nas
extensões do fluxo principal nos fluxos alternativos
e de exceção.
Processo de software PBH/Prodabel
C4-Casos de uso 18
Requisitos Processo de software da PBH/Prodabel 35
Organização de cenários
� Fluxos alternativos estendem o fluxo principal para tratar as 
variações e exceções.
� Sub-fluxos podem ser usados para facilitar a leitura de um fluxo
complexo. Pode ser substituído por outro caso de uso.
� Pré e pós condições podem ser usadas para melhor esclarecer o 
escopo de um caso de uso e documentar qualquer premissa feita
a respeito do estado do sistema (antes ou depois do UC). Pré-
condições são mais comuns que pós-condições.
� A descrição deve ser longa o suficiente para poder descrever a 
estória e simples o suficiente para não dificultar os trabalhos nem
tornar o modelo complexo. Deve-se utilizar linguagem clara e 
objetiva.
Requisitos Processo de software da PBH/Prodabel 36
Estrutura comum aos fluxos
� Uma condição sob a qual o cenário é executado: para o 
cenário principal é a pré condição mais o acionador. Para um 
cenário de extensão, é a condição de extensão.
� Um objetivo a alcançar: para o principal, é o nome do caso de 
uso. Para um cenário de extensão, o objetivo é completar o 
caso de uso ou ingressar no cenário de sucesso.
� Um conjunto de passos de ação: formam o corpo do cenário e 
seguem as mesmas regras em todo cenário ou fragmento de 
cenário.
� Uma condição de fim: objetivo atingido ou abandonado.
� Um possível conjunto de extensões escritas como fragmentos
de cenário.
Processo de software PBH/Prodabel
C4-Casos de uso 19
Requisitos Processo de software da PBH/Prodabel 37
Condições de extensão
� São as condições sob as quais o sistema tem um comportamento
diferente (fluxos alternativos e/ou exceção). 
� Exemplo:
...
“4. Usuário solicita salvamento do arquivo”
...
�