Apostila Requisitos v1.2

Processo de Software da PBH/Prodabel
PSP
Requisitos de Software e
Casos de uso
Gerncia de Engenharia de Software (GESS-PB)

Superintendncia de Arquitetura de Sistemas (SAS-PB)
Diretoria de Sistemas e Informao (DS-PB)
Empresa de Informtica e Informao de Belo Horizonte (Prodabel S/A)
Verso 1.2
Sumrio
1. Requisitos de software
2. Engenharia de requisitos
3. Tcnicas de levantamento (elicitao) de requisitos
4. Casos de uso
5. Modelagem de casos de uso
6. Exerccios
Processo de software PBH/Prodabel
Processo de Software da PBH/Prodabel PSP
Requisitos de software

Verso 1.2
Objetivos
Entender o que um requisito
Apresentar as classificaes dos requisitos
Requisitos
C1-Introduo
Processo de software da PBH/Prodabel
Roteiro
Problemas de desenvolvimento de software
Definio de requisitos
Classificao dos requisitos
Visibilidade
Natureza
Regras de negcio
Requisitos e processos
Interessados nos requisitos
Engenharia de requisitos
Desenvolvimento de requisitos
Gerenciamento de requisitos
Requisitos
Problemas do desenvolvimento de software

A parte mais difcil de construir um software decidir
precisamente o que deve ser feito.
Nenhuma outra parte do trabalho conceitual to difcil 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 difcil de retificar posteriormente.
(Frederick Brooks)
Requisitos
C1-Introduo
Problemas clssicos do desenvolvimento de software
Requisitos
Problemas com requisitos

Envolvimento insuficiente dos usurios.
Crescimento dos requisitos de usurio.
Requisitos ambguos.
Gold plating (bala de prata).
Especificaes minimalistas.
Excesso de classes de usurio.
Planejamento inacurado.
Outros:
__________________________________________
Requisitos
C1-Introduo
Processo de requisitos efetivo

Reduo de defeitos nos requisitos.
Reduo do retrabalho de desenvolvimento.
Reduo de caractersticas desnecessrias.
Reduo de custos para evolues.
Desenvolvimento agilizado.
Reduo dos problemas de comunicao.
Reduo do crescimento do escopo.
Reduo do caos no projeto.
Estimativas mais acuradas.
Aumento da satisfao dos envolvidos.
Requisitos
Requisitos
O termo requisito nem sempre utilizado pela
indstria de software de modo consistente.
Em alguns casos, um requisito visto como uma
declarao abstrata, de alto nvel, de uma funo
que o sistema deve fornecer ou de uma restrio do
sistema.
No outro extremo, ele pode ser uma definio
detalhada, matematicamente formal, de uma funo
do sistema.
Que definio adotar?
__________________________________________
Requisitos
C1-Introduo
Documento de requisitos
Se uma empresa deseja estabelecer um contrato para o
desenvolvimento de um projeto de software, suas necessidades
tm que ser definidas de forma suficientemente abstrata para que
uma soluo a priori no seja definida.
No caso de contratao 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 definio 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 afirmaes mostram que a definio de requisitos deve ser
feita por meio de refinamentos sucessivos, indo do conceitual em
direo ao fsico.
Requisitos
Definio de requisitos
1. Condio ou capacidade necessria a um usurio
para resolver um problema ou atingir um objetivo.
2. Condio ou capacidade que deve ser alcanada ou
possuda por um sistema ou componente de sistema
para satisfazer um contrato, padro, especificao
ou outro documento formalmente imposto.
3. Uma representao documentada de uma condio
ou capacidade como nos itens 1 e 2 acima.
Fonte: [IEEE Standard Glossary of Software Engineering
Terminology, 1990]
Requisitos
C1-Introduo
10
Definio de requisitos II
Requsitos so uma especificao do que deve
ser implementado. Eles constituem descries
de como o sistema deve se comportar, ou uma
propriedade ou atributo do sistema. Podem
caracterizar uma restrio no processo de
desenvolvimento do sistema.
Fonte: Sommervile e Sawyer, Requirements
Engineering, 1997].
Requisitos
11
O que requisito no
Especificao de requisitos no incluem:
Detalhes de desenho;
Implementao;
Informaes de teste;
Requisitos de projeto;
Limites de recursos e tempo;
necessidade de um tutorial para os usurios;
Etc
Requisitos
C1-Introduo
12

Quanto a visibilidade
Requisitos de usurio;
Requisitos de sistema;
Requisitos de desenho.
Quanto a natureza
Funcionais;
No funcionais.
Requisitos
13

+ Conceitual
Domnio do
problema
=> Negcio
Necessidades
Problema a ser
resolvido
Requisitos de usurio
Domnio da
soluo
Requisitos de sistemas
=> Sistema
Requisitos de desenho
+ Fsico
Requisitos
C1-Introduo
Produto a ser
construdo
14
Separao entre domnios

A separao em domnios indica que os
requisitos de software tratam da soluo para um
problema.
O formato da pirmide reflete o volume relativo
do problema: poucas necessidades podem exigir
vrios requisitos.
Rastreabilidade deve ser mantida entre todos os
nveis.
Requisitos
15
Necessidades
Tambm conhecidas como requisitos de negcio, representam
objetivos de alto nvel da organizao ou cliente que requisitou o
sistema. Tipicamente so originadas do patrocinador do projeto,
o adquirente. Por ex: o gerente dos usurios ou o setor de
marketing.
Descrevem porque a organizao est implementando o sistema
os objetivos que espera-se atingir. Normalmente so
contemplados num documento de viso ou proposta do projeto.
Ex: Reduzir os custos operacionais [em y%]; Aumentar
participao no mercado [em x%]; Implantar nova linha de
produtos e servios.
D um exemplo na sua rea de trabalho:
____________________________________________________
Requisitos
C1-Introduo
16
Requisitos quanto visibilidade

Requisitos de usurio: Declaraes em linguagem natural e
tambm em diagramas sobre as funes que o sistema deve
fornecer e as restries sob as quais deve operar.
Requisitos de sistema: Estabelecem detalhadamente as funes

e restries de sistema. O documento de requisitos de sistema,
tambm chamado Especificao Funcional ou de Requisitos,
deve ser preciso. Ele pode servir como um contrato entre
comprador e desenvolvedor.
Requisitos de desenho: Uma descrio abstrata que base para

detalhes de implementao. Essa especificao acrescenta mais
detalhes Especificao de Requisitos do Sistema. um
documento orientado implementao.
Requisitos
17
Pblico-alvo dos documentos

Requisitos de
usurio
Requisitos de
sistema
Requisitos de
desenho
Requisitos
C1-Introduo
Gerentes de clientes
Usurios finais
Tcnicos do cliente
Gerentes do fornecedor
Arquitetos de sistemas
Usurios finais de sistemas
Tcnicos do cliente
Desenvolvedores de software
(eventual)
Tcnicos do cliente
(eventualmente)
Desenvolvedores de software
18
Exemplo de requisitos de usurio e sistema

Requisitos de usurio:
O sistema deve oferecer um meio de representar e acessar
arquivos externos criados por outras ferramentas.
Especificao de requisitos de sistema:
O usurio deve dispor de recursos par definir o tipo dos
arquivos externos.
Cada tipo de arquivo pode ser representado como um cone
especfico na tela do usurio.
Quando um usurio 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
19
Requisitos funcionais
Declaraes de funes que o sistema deve fornecer,
como o sistema deve reagir a entradas especficas e
como deve se comportar em dadas situaes.
Descrevem as funcionalidades ou servios que um
sistema oferece.
Dependem do tipo de software, usurios esperados e
do tipo de sistema onde o software ser utilizado.
Enquanto requisitos funcionais de usurio podem ser
declaraes de alto nvel do que o sistema deve fazer,
requisitos funcionais de sistema devem descrever os
servios do sistema em detalhes.
Requisitos
C1-Introduo
20
10
Requisitos funcionais
Especificam funcionalidades de software que
os desenvolvedores devem construir para
possibilitar aos usurios executar suas tarefas,
satisfazendo aos requisitos de negcio.
Esse tipo de requisitos descrito
tradicionalmente pela sentena 'deve.
Ex: O sistema deve enviar uma mensagem
com a confirmao de reserva para o usurio.
Requisitos
21
Exemplos de requisitos funcionais

Sistema de biblioteca:
O usurio 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
usurio ler documentos no repositrio de
documentos.
Cada pedido ser alocado a um nico identificador
(ID_Pedido), que o usurio poder copiar para a
rea de armazenagem permanente da conta.
Requisitos
C1-Introduo
22
11
Requisitos no funcionais
Restries sobre as funes oferecidos pelo sistema. Destacamse aqui as restries de tempo, processo e padro.
Ex.: tempo de resposta, requisitos de armazenamento,

confiabilidade, capacidade dos dispositivos de I/O, etc...
Tambm podem ser especificados uma determinada ferramenta

CASE, linguagem de programao ou processo de
desenvolvimento.
Podem ser mais crticos que os requisitos funcionais.

Ex: ________________________________________________
Caso no sejam atendidos, o sistema pode tornar-se inutilizvel.

Ex: ________________________________________________
Requisitos
23
Classificao dos requisitos no funcionais

Requisitos no funcionais
Requisitos de produto
Requisitos organizacionais
Requisitos externos
Facilidade de uso
Entrega
Interoperabilidade
Eficincia
Implementao
ticos
Padres
Legais
Desempenho
Espao
Privacidade
Confiabilidade
Segurana
Portabilidade
Requisitos
C1-Introduo
24
12
Classificao dos requisitos no funcionais

Requisitos de produto: Especificam o comportamento do
produto.
Requisitos organizacionais: Decorrem de polticas e

procedimentos nas organizaes 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
25
Exemplos de requisitos no funcionais

Requisitos de produto:
Deve ser possvel que toda a comunicao necessria
entre o software e o usurio seja expressa no conjunto
padro de caracteres ASCII.
Requisitos de organizao:
O processo de desenvolvimento e os documentos
entregues devero estar de acordo com o processo e os
produtos definidos em XYZCo-SP-STAN-95.
Requisitos externos:
O sistema no dever revelar aos operadores nenhuma
informao pessoal sobre os clientes alm de seus nomes
e cdigo.
Requisitos
C1-Introduo
26
13
Metas e requisitos
Requisitos no funcionais podem ser difceis de
estabelecer e requisitos imprecisos so difceis para
verificar.
Metas so teis a medida que elas esclarecem as
intenes dos usurios do sistema
Meta:
Uma inteno do usurio, como fcil de usar, rpido.
Requisito no funcional verificvel:

Uma sentena que use alguma mtrica que possa ser
objetivamente testada.
Requisitos
27
Exemplos
Uma meta do sistema
O sistema deve ser fcil de ser usado por
controladores experientes e organizado de tal forma
que os erros possam ser minimizados.
Requisito no funcional verificvel

Controladores experientes devem estar aptos a
usar todas as funes do sistema aps um
treinamento de duas horas
Aps o treinamento, o nmero mdio de erros
cometidos pelos usurios experientes no pode
exceder o total de dois por dia.
Requisitos
C1-Introduo
28
14
Mtricas para requisitos

Propriedades
Mtrica
Velocidade
Transaes processadas por segundo

Tempo de resposta ao usurio/evento
Tempo de refresh de tela
Tamanho
K Bytes
Nmero de chips de RAM
Facilidade de uso
Tempo de treinamento
Nmero de frames de ajuda
Confiabilidade
Tempo mdio para falhar

Taxa de ocorrncia de falhas
Disponibilidade
Robustez
Tempo de reincio aps falha

Porcentagem de eventos que causam falhas
Probabilidade de corrupo de dados
Portabilidade
Porcentagem de declaraes dependentes de sistema alvo

Nmero de sistemas alvo
Requisitos
29
Atributos de qualidade
Os requisitos no funcionais tambm so conhecidos
como atributos de qualidade (norma ISO 9126):
Viso do cliente:
Viso do
desenvolvedor:
Disponibilidade
Eficincia
Flexibilidade
Manutenibilidade
Integridade
Portabilidade
Reusabilidade
Testabilidade
Interoperabilidade
Confiabilidade
Robustez
Usabilidade
Requisitos
C1-Introduo
30
15
Exemplos de atributos de qualidade

Disponibilidade: O sistema deve estar 99,5 % do tempo
disponvel nos dias de semana de 6h s 18h.
Eficincia: O sistema dever estar reservar pelo menos 25%
da capacidade do processador em condies de pico.
Integridade: Somente usurios que tem acesso como Auditor
devem ser habilitados a visualizar dados de transaes de
clientes.
Interoperabilidade: O sistema deve ser capaz de importar
qualquer registro vlido de funcionrio, provido pelo sistema
Pessoal.
Confiabilidade: No mximo cinco em cada 1.000 transaes
podem falhar.
Requisitos
31
Regras de negcio
No so exatamente requisitos, pois existem fora dos
limites de qualquer sistema especfico.
Geralmente restringem quem pode desempenhar
determinadas tarefas ou diz que o sistema deve conter
certas funcionalidades.
Normalmente inclui polticas da corporao,

regulaes governamentais, padres da indstria,
prticas contbeis e algoritmos computacionais.
Requisitos
C1-Introduo
32
16
Regras de negcio
Uma regra de negcio uma sentena que define ou
restringe algum aspecto do negcio. Tem por
objetivo atender a estrutura, controlar ou influenciar o
comportamento do negcio.
Classificao das regras de negcio:
- Fato
- Restrio
- Habilitador
- Clculo
- Inferncia
Requisitos
33
Fato
Sentenas simples verdadeiras sobre o negcio.
Tipicamente descrevem associaes ou relaes entre
termos de negcio relevantes. So tambm chamadas
de invariantes.
Exemplos:
Cada continer deve ter um nico cdigo de barra
identificador.
Todo pedido deve ter uma carga de entrega.
Taxas de vendas no so computadas nas cargas de envio.
Requisitos
C1-Introduo
34
17
Restries
Restringem as aes que o sistema ou usurios podem
executar. Algumas palavras e frases sugerem
restries como deve e no deve.
Exemplos:
Tripulao 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
responsvel.
Requisitos
35
Habilitador
Regra que dispara alguma atividade sob uma condio
especfica.
Exemplos:
Se a data de expirao de um produto tiver sido atingida, o
responsvel deve ser notificado por email.
No ltimo dia da quinzena, gerar os relatrios gerenciais e
disponibilizar aos gestores.
Requisitos
C1-Introduo
36
18
Clculo
Clculos realizados usando frmulas matemticas especficas ou
algoritmos. Vrios clculos seguem regras externas as
organizaes.
Exemplos:
O preo total de um pedido determinado pela soma dos preos 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:
Id
Itens vendidos
Desconto (%)
Desc1
1a5
Desc2
6 a 10
10
Desc3
mais de 10
20
Requisitos
37
Inferncia
Regra que estabelece algum novo conhecimento
baseado na verdade de certas condies. Uma
inferncia cria um novo fato de outros fatos ou de
clculos. So geralmente escritos no formato se
ento.
Exemplos:
Se o pagamento no for recebido em 30 dias corridos, o ttulo
ser protestado.
Produtos com taxa de toxidade maiores que 5 mg/kg so
considerados perigosos.
Requisitos
C1-Introduo
38
19
Engenharia de requisitos de software

Verso 1.2
Objetivos
Apresentar o conceito de Engenharia de
requisitos
Apresentar a disciplina Requisitos do PSP
Requisitos
C2-Engenharia de requisitos
Roteiro
Processo de Software da PBH / Prodabel (PSP)
MPS.BR
RUP
Gerncia de requisitos
Requisitos
Processo de estabelecer os servios que um cliente
requer de um sistema e as restries em que o
mesmo desenvolvido e ser operado.
Os requisitos so a descrio dos servios de
sistema e restries que so gerados durante o
processo de engenharia de requisitos.
Os processos usados dependem do domnio da
aplicao, pessoas envolvidas e organizao.
Requisitos
Atividades da engenharia de requisitos

Levantamento (Elicitao)
Anlise
Especificao
Verificao e validao
Controle de verses
Controle de mudanas
Requisitos
Limites entre desenvolvimento e

gerenciamento de requisitos
Requisitos
Requisitos e outras disciplinas
Requisitos

Indivduo ou organizao que recebe direta ou
indiretamente algum benefcio 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 so
analistas, desenvolvedores, testadores,
documentadores, gerentes de projeto, equipe
de suporte, equipe jurdica, marketing, etc.
Requisitos
Conflito de interesses
Requisitos
Direitos do usurio
Esperar que o analista fale a sua lngua.
Esperar que o analista compreenda o negcio.
Esperar que o analista escreva a especificao de requisitos.
Receber explicao do analista sobre os produtos gerados.
Receber tratamento respeitoso e profissional do analista.
Receber alternativas do analista.
Descrever caractersticas do produto que facilitaro sua vida.
Ter oportunidade de ajustar o produto para prover reuso.
Receber estimativas corretas de tempo e custo.
Receber informaes sobre o impacto dos pedidos de mudana.
Receber um sistema que atenda aos requisitos.
Requisitos
10
Responsabilidades dos usurios (a revanche)

Explicar a terminologia da rea de negcio.
Disponibilizar tempo para prover requisitos, elucid-los e atualiz-los.
Ser especfico e preciso ao prover informaes para os requisitos.
Tomar decises em tempo hbil sobre requisitos.
No pressionar por estimativas de prazo e custo inviveis.
Respeitar as estimativas de prazo e custo informadas.
Definir com o analista as prioridades dos requisitos.
Revisar os documentos de requisitos e avaliar prottipos.
Comunicar necessidades de mudanas nos requisitos assim que souber.
Seguir o processo definido para solicitar pedidos de mudana.
Respeitar o processo de engenharia de requisitos.
Requisitos
11
Analista de requisitos
Analista de requisitos o indivduo que tem como
responsabilidade principal coletar, analisar,
documentar e validar as necessidades dos
envolvidos no projeto.
O analista serve como principal condutor atravs do
qual os requisitos fluem dos clientes at a equipe de
desenvolvimento.
Avalie como isto acontece na sua rea funcional:
____________________________________________
____________________________________________
Requisitos
12
Canais de comunicao do analista
Requisitos
13
Competncias requeridas de um analista

Habilidades:
Ouvir.
Entrevistar e questionar.
Analisar.
Conhecimentos:
Engenharia de requisitos.
Moderar.
Processo de software.
Observar.
Gerenciamento de projetos.
Escrever.
Qualidade.
Organizar.
Modelar.
Domnio da aplicao.
Inter-relacionar.
Criar.
Requisitos
14
Importante
No assuma que um desenvolvedor talentoso ou
usurio avanado automaticamente pode se tornar
um analista de requisitos efetivo sem treinamento,
material de apoio e acompanhamento.
As atribuies 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
__ No
Conhecimentos:
__ Sim
__ No
Requisitos
15
Requisitos no PSP
Os assuntos relacionados a requisitos de software no Processo
de Software da PBH/Prodabel esto disponveis no prprio
processo.
As principais referncias para a estruturao do fluxo so:
Disciplina de Requisitos do RUP: O PSP aderente ao RUP
e, por consequncia, requisitos orientam todo o processo de
desenvolvimento de software.
Resultados esperados do MPS.BR: Os REP especficos de
Gerncia de Requisitos devem ser atendidos.
Requisitos
16
Requisitos e o RUP
Requisitos
17
Resultados Especficos (REP) de GRE

GRE 1. O entendimento dos requisitos obtido junto aos

fornecedores de requisitos;
GRE 2. Os requisitos de software so aprovados utilizando

critrios objetivos;
GRE 3. A rastreabilidade bidirecional entre os requisitos e os

produtos de trabalho estabelecida e mantida;
GRE 4. Revises em planos e produtos de trabalho do projeto

so realizadas visando identificar e corrigir inconsistncias em
relao aos requisitos;
GRE 5. Mudanas nos requisitos so gerenciadas ao longo do

projeto.
Requisitos
18
Fluxo de requisitos do PSP
Requisitos
19
Fluxo de requisitos do PSP

Atividade Obter entendimento:
Elaborar especificao de requisitos
Elaborar modelo de caso de uso
Atividade Desenvolver requisitos:

Especificar caso de uso
Elaborar especificao suplementar
Atividade Gerenciar requisitos:

Registrar solicitao
Analisar impacto
Requisitos
20
10
Requisitos no PSP
Principais papis :
Analista de requisitos
Desenvolvedor
Principais artefatos:
Especificao de requisitos
Modelo de casos de uso
Caso de uso (detalhado)
Especificao suplementar
Requisitos
21
Fontes de requisitos
Requisitos
22
11
Fontes de requisitos
Entrevistas e discusses com usurios potenciais.
Documentos dos produtos atuais ou concorrentes.
Especificao de requisitos.
Relatrios de problemas e pedidos de melhoria.
Pesquisas de marketing e questionrios de usurios.
Observao do usurio no trabalho.
Anlise de cenrios e tarefas de usurios.
Eventos e respostas.
Outros: _____________________________________
Requisitos
23
Outros tipos de entradas

Requisitos no relacionados com o produto, como necessidades
de treinamento dos usurios.
Restries de projeto como prazo e custo.
Uma premissa.
Informao adicional de um contexto histrico para ajudar a
entender o contexto.
D um exemplo de cada caso:
Treinamento: __________________________________________
Projeto: ______________________________________________
Premissa: ____________________________________________
Informao adicional: ___________________________________
Requisitos
24
12
Diretrizes para explicitao de requisitos

Escreva sentenas completas com gramtica, ortografia e pontuao
corretas. Mantenha pargrafos curtos e diretos.
Use a voz ativa. Ex: O sistema deve fazer algo ao invs de Alguma coisa
deve ser feita.
Quando definir requisitos na forma O usurio deve... identifique o ator (O
comprador deve...).
Use termos consistentes definidos no glossrio. Evite sinnimos.
Decomponha requisitos de alto nvel em requisitos mais detalhados de
forma a torn-los claros e para reduzir a ambiguidade.
Use listas, figuras, grficos e tabelas, se necessrio.
Enfatize os trechos mais importantes de informao.
Evite termos ambiguos, tais como: adequado, eficiente, flexvel, melhor,
maximizar, normalmente, robusto, vrias, suficiente, amigvel
Requisitos
25
Especificao de requisitos
a base para a equipe de anlise e desenho, pois
descreve funes e desempenho requeridos de um
sistema baseado em computao e as regras que
guiaro seu desenvolvimento.
Limita cada elemento alocado ao sistema e tambm
descreve as informaes (dados e controle) que
constituem as entradas e sadas do sistema.
Pode ser um documento escrito, um modelo

grfico, um modelo matemtico formal, uma
coleo de cenrios de uso, um prottipo ou
qualquer combinao dos itens citados.
Requisitos
26
13
Verificao e validao (V&V)

Verificao:
Tem como propsito confirmar que cada servio e/ou
produto de trabalho do processo ou do projeto
atende apropriadamente os requisitos especificados.
Normalmente desempenhada pela equipe tcnica.
Validao:
Tem como propsito confirmar que um produto ou
componente do produto atender a seu uso
pretendido quando colocado no ambiente para o qual
foi desenvolvido.
Requisitos
27
Verificao e Validao
Verificao: Estamos construindo certo o

produto?
- Ponto de vista do desenvolvedor / equipe.
Validao: Estamos construindo o produto

certo?
- Ponto de vista do usurio final / cliente.
Requisitos
28
14
Tcnicas para V&V de requisitos

Reviso - exemplos:
Discusso de um problema tcnico na hora do caf.
Apresentao do projeto de software para uma audincia
de clientes, administradores e pessoal tcnico.
Revises Tcnicas Formais: inclui avaliaes tcnicas
de software realizadas em pequenos grupos
(walkthrough).
Inspeo: anlise detalhada feita por um grupo com

papis e organizao bem definidos.
Testes: execuo de um programa com o objetivo
de encontrar erros.
Requisitos
29
Exemplos de critrios de V&V

Os requisitos esto estruturados claramente? No h problemas de
interpretao 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 so os requisitos relacionados a cada um? Eles esto
claramente identificados atravs de uma matriz de referncia cruzada
ou outro mecanismo?
O requisito viola alguma regra de domnio?
O requisito passvel de teste?
O requisito rastrevel para os objetivos gerais?
Os requisitos associados performance, comportamento e
caractersticas operacionais foram estruturados claramente?
Requisitos
30
15
Exemplos de critrios de V&V

Consistente. H algum conflito de requisitos?
Completo. Todas as funes requeridas pelo cliente foram
includas e contm informaes para as demais atividades?
Real. Os requisitos podem ser implementados com os recursos e
tecnologia disponveis?
Completo: cada requisito contm toda a informao necessria ao
desenho e implementao?
Vivel: deve ser possvel implementar cada requisito considerando
as capacidades e limitaes existentes.
Necessrio: devem ser descritas as capacidades realmente
necessrias aos usurios.
Priorizado: cada requisito deve ser priorizado.
No-ambguo: todos os leitores dos requisitos tm que ter uma
nica e consistente interpretao do seu significado.
Requisitos
31
Priorizao de requisitos
Projetos de software possuem limitaes de recursos que nos obrigam a
definir a prioridade relativa dos requisitos. A priorizao ajuda o gerente de
projeto a resolver conflitos, planejar iteraes e fazer as compensaes
necessrias.
Quando as expectativas do cliente so altas e o tempo curto, faz-se
necessrio entregar o produto com as funcionalidades mais relevantes, o mais
cedo possvel.
Perguntas teis:
H outra maneira de satisfazer as necessidades que esse requisito trata?
Qual ser a consequncia de omitir esse requisito?
Qual ser o impacto nos objetivos de negcio se o requisito no for
implementado nessa iterao?
Por que o usurio ficaria descontente caso esse requisito fosse adiado
para a ltima iterao?
Requisitos
32
16
Priorizao de requisitos
Importante
No importante
Urgente
Alta prioridade
Baixa prioridade
No urgente
Mdia prioridade
O que fazer?
Peso
Requisito
Benefcio
relativo
Perda
relativa
Valor
Total
Valor
%
1
Custo
relativo
0,5
Custo
%
Risco
relativo
Risco
%
Priorida
de
RQ1
38,9
33,3
16,7
0,93
RQ2
22,2
50
50
0,30
RQ3
38,9
16,7
33,3
1,17
Total
18
100
100
100
Prioridade = Valor % / [ (custo % * peso custo) + ( risco % * peso risco) ]

Requisitos
33
Modelagem visual de requisitos

Nenhuma forma de representao de requisitos prov
individualmente um entendimento completo.
Normalmente, combinaes de reprentaes textuais e
grficas mostram uma viso completa do sistema
estudado. Alguns mecanismos visuais so:
Prottipos;
Tabelas e rvores de deciso;
Diagramas DFD, DER, classes, estados, sequncia.
Casos de uso.
Requisitos
34
17
Os requisitos passam a compor uma baseline aps 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 mudanas na baseline de requisitos.
Manter planos de projetos de acordo com os requisitos.
Controlar verses dos requisitos e documentos associados.
Monitorar o status dos requisitos na baseline.
Gerenciar as ligaes entre requisitos e outros produtos de trabalho.
Requisitos
35
Controle de verses de requisitos

Cada verso dos documentos de requisitos deve ser unicamente
identificada. Cada membro da equipe deve ser capaz de acessar
a verso corrente dos requisitos. Mudanas devem ser
documentadas e comunicadas a todos envolvidos.
Para minimizar confuso, conflitos e desentendimentos, somente
pessoas designadas podem atualizar os requisitos e ter certeza
de que o nmero de verso muda sempre que ocorrerem
mudanas.
Na sua viso como poderia ser feito esse controle?
______________________________________________________
______________________________________________________
Requisitos
36
18
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 concluso. Exemplos de status:
Proposto: requisito solicitado por pessoa autorizada.
Aprovado: realizada anlise de impacto, estimativas de projeto e
alocao para uma release especfica.
Implementado: cdigo desenhado, escrito e testado.
Verificado: funcionamento confirmado e requisito integrado.
Rejeitado: requisito proposto mas no planejado para
implementao em nenhuma release.
Requisitos
37
Controle de mudanas
Procedimentos que visam garantir:
Mudanas de requisitos propostas so avaliadas
cuidadosamente antes de atualizadas.
Responsveis tomam decises sobre mudanas solicitadas.
Mudanas aprovadas so comunicadas a todos interessados.
O projeto incorpora mudanas de uma maneira consistente.
Voc acha que os mecanismos de CM devem ser

formais ou informais? Explique!
______________________________________________
______________________________________________
Requisitos
38
19
Poltica de controle de mudanas

Todas as mudanas de requisitos devem seguir o processo definido. Se uma
solicitao de mudana fugir ao processo, est fora!
Para as mudanas no aprovadas nenhum trabalho de desenho e
implementao deve ser feito. A nica atividade anlise de viabilidade.
Em alguns casos o grupo gestor deve decidir se uma solicitao deve ser
implementada.
O contedo da base de mudanas deve ser visto por todos envolvidos.
Anlise de impacto deve ser feita para toda mudana.
O texto original do pedido de mudana no deve ser alterado.
Cada mudana em requisitos incorporada deve ser rastrevel at o pedido
aprovado.
A razo de cada aprovao/reprovao deve ser registrada.
Requisitos
39
Papis no controle de mudanas

CCB (Change Control Board): grupo que decide aprovar ou
rejeitar mudanas propostas para um projeto especfico.
Avaliador: apoia o CCB analisando o impacto de um pedido de
mudana. Pode ser um tcnico, o cliente, etc.
Modificador: responsvel por realizar as mudanas em um
produto de trabalho a partir das solicitaes aprovadas.
Originador: quem submete um pedido de mudana.
Destinatrio (Recebedor): quem recebe as novas solicitaes.
Verificador: responsvel por determinar se as mudanas foram
feitas corretamente.
Requisitos
40
20
Anlise de impacto
Geralmente desenvolvida por um tcnico com grande
conhecimento. Possui trs aspectos:
Entender as possveis implicaes de se fazer a mudana.
Identificar todos arquivos, modelos e documentos que devem ser
modificados se a mudana ocorrer.
Identificar tarefas necessrias para implementar a mudana e estimar o
esforo, tempo e recursos necessrios.
Importante: deixar de analisar impacto no muda o tamanho da

tarefa mas deixa o escopo do trabalho como uma surpresa.
Voc j viu realizar-se anlise de impacto em algum projeto?
______________________________________________________
Requisitos
41
Rastreabilidade de requisitos
Rastreabilidade a caracterstica que permite
acompanhar a vida de um requisito, desde a origem at
a implementao.
A rastreabilidade pode ajudar a:
garantir que os requisitos especificados so 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.
Requisitos
42
21
Matriz de rastreabilidade
Legenda:
U: o requisito da linha usa o requisito da coluna
R: h um relacionamento entre os requisitos
Requisitos
43
Requisitos e ferramentas CASE
Requisitos
44
22
Requisitos
45
Requisitos
46
23
Requisitos
47
Requisitos
48
24
Referncias Bibliogrficas
WIEGERS, Karl, Software requirements, 2
edition, 2006.
SOMMERVILLE, Ian, Engenharia de Software,
Addison Wesley, 6 edio, 2003.
PRESSMAN, Roger S., Engenharia de Software,
McGraw Hill, 5 Edio, 2002.
Requisitos
49
25
Tcnicas de levantamento (elicitao)

de requisitos de software
Verso 1.2
Objetivos
Apresentar as principais tcnicas para o

levantamento (elicitao) de requisitos.
Tcnicas de elicitao
C3-Tcnicas de elicitao
Roteiro
Observao pessoal.
Pesquisa.
Questionrio.
Entrevista.
Reunies.
Brainstorming.
JAD
Tcnicas de elicitao
Observao pessoal
Consiste em conviver com situaes cotidianas.

Possibilita a confirmaes recebidas como: leiaute,
problemas de relacionamento, erros de
procedimento, segurana do trabalho, etc.
Vantagens: no interrupo das atividades, no
exigncia de disponibilidade do tempo de
envolvidos.
Desvantagens: ausncia de evidncias formais,
causar mal-estar na rea envolvida, concluses
comprometedoras.
Tcnicas de elicitao
Pesquisas
Pesquisa interna: averiguao fsica de uma
atividade e processo.
Vantagens: percepo do pesquisador,

esclarecimento de dvidas.
Desvantagens: cria mal estar entre os

participantes, demanda muito tempo.
Pesquisa externa: utilizada quando no se dispe

de qualquer experincia para descrever os
requisitos. Utiliza informaes de acervos externos
sociedades profissionais, peridicos, livros tcnicos
e relatrios de pesquisa.
Tcnicas de elicitao
Questionrio
Instrumento que envolve os processos de

preparao em formulrio, distribuio,
recolhimento e tabulao.
Pode ser precedido de um pr-teste.
Vantagens: agilidade, custo, facilidade,
abrangncia de pessoas, mensurao uniforme,
anonimato, ausncia de presso por resultados
imediatos.
Desvantagens: manipulao de respostas antes
de entregar, tendncia de utilizao de resposta
padro, frieza.
Tcnicas de elicitao
Entrevista
Dilogo entre entrevistado e entrevistador.
Vantagens: as perguntas podem ser alteradas

(contedo, ordem, eliminao, incluso), podem ser
esclarecidos pontos das perguntas, podem ser
avaliadas as reaes dos entrevistados, pode-se
motivar o entrevistado.
Desvantagens: alcana menos pessoas, tratamento

diferenciado aos entrevistados, desvios de curso,
demanda tempo, avaliaes subjetivas, alteraes nas
perguntas e contedo, desestimulo, impossibilidade de
avaliao prvia, respostas politicamente corretas.
Tcnicas de elicitao
Seminrio
Reunio planejada de pessoas-chave de diversas

reas com o objetivo de obter informaes gerais
sobre a empresa.
Tambm chamada de workshops e dinmica de
grupo.
Vantagens: rapidez na identificao de problemas
de relacionamento, estrangulamentos e viso
integrada de problemas.
Desvantagens: mobilizar um grande nmero de
pessoas ao mesmo tempo, interferindo na rotina de
trabalho da empresa.
Tcnicas de elicitao
Brainstorming
Tcnica de obteno de informaes em reunies. Etapas:
Gerao de idias:
No permitir crticas ou debates;
Deixar a imaginao voar;
Procurar quantidade;
Mudar e combinar idias.
Seleo de idias:
Decidir com base em um limite de votos
Decidir com base em discurso de campanha
Juntar idias e aplicar critrios;
Utilizar sistemas de pontuao.
Tcnicas de elicitao
JAD
Joint Application Design (Projeto de Aplicao

Conjunta).
Mtodo criado pela IBM no ano de 1977.
Consiste em reunies estruturadas intensivas e em
grupo, onde participam os representantes do usurio e
da informtica.
Cada sesso composta por uma ou mais reunies e
dura de um a trs dias.
Toda reunio conduzida por um facilitador (ou
mediador) que visa obter o consenso de forma rpida.
Tcnicas de elicitao
10
Principais caractersticas do JAD

As reunies substituem as entrevistas individuais.
O processo de trabalho altamente estruturado.
Os papis so bem definidos.
As decises so baseadas em consenso.
O facilitador elimina as barreiras de comunicao.
Os recursos visuais dinamizam o trabalho.
Tcnicas de elicitao
11
Reunies ao invs de entrevistas

Os usurios se sentem prestigiados e parte integrante do

processo, visto que suas opinies so consideradas.
As divergncias so resolvidas pelo grupo, pois todas as

idias so discutidas por todos.
Pode significar grande economia de tempo de
desenvolvimento. Entretanto, a carga horria alocada ao
projeto tende a ser maior se comparada ao uso de
entrevistas individuais, devido a uma participao mais
intensa dos usurios.
Tcnicas de elicitao
12
Processo de trabalho estruturado

Os produtos a serem alcanados so previamente

discutidos e so a base de todo o trabalho.
Cada sesso tem sua finalidade definida e todos os
participantes conhecem os resultados esperados.
Os trabalhos de cada sesso so feitos baseados
em uma agenda padro adotada em todas as
reunies. Somente a abordagem da sesso que
varia.
Os resultados so insumos para o projeto.
Tcnicas de elicitao
13
Papis so bem definidos

Executivo patrocinador: autoridade das reas de negcio

envolvidas. Redime conflitos, estabelece as diretrizes e
objetivos e abre os trabalhos.
Gerente de projeto: principal contato do facilitador durante o
processo.
Equipe: responsvel pelo contedo da sesso. So as pessoaschave das reas envolvidas, em todos os nveis.
Facilitador: Guia imparcial, garante participao e consenso.
Documentador: registra decises tomadas.
Tcnicas de elicitao
14
Decises baseadas em consenso

Consenso no a unanimidade, mas a concordncia
de que a soluo encontrada a melhor para o
grupo.
Consenso tambm aquela soluo com a qual os

participantes iro conviver sem ferir suas prprias
convices e valores essenciais.
A forma mais produtiva de deciso em grupo aquela

baseada em consenso.
A conduo ao consenso a principal tarefa do

facilitador.
Tcnicas de elicitao
15
Facilitador elimina barreiras de

comunicao
O facilitador uma pessoa neutra do grupo que

no avalia nem contribui com idias.
Sugere mtodos que ajudem o grupo a concentrar
energia em tarefas especficas.
Protege todos os membros do grupo contra
ataques.
Garante a participao de todos de forma
homognea.
A presena do facilitador torna a reunio mais
produtiva.
Tcnicas de elicitao
16
Recursos visuais dinamizam o

trabalho
O andamento das sesses se beneficia do uso de
recursos visuais como transparncias, slides,
vdeos, flipcharts, micros etc.

Todos os resultados das discusses so exibidos
atravs de recursos adequados para que todos
possam ver.
Tais recursos estimulam os sentidos, esclarecem
pontos confusos e fazem uso eficaz do tempo.
Tcnicas de elicitao
17
Detalhamento do processo JAD

Tipos de sesses JAD: gerenciais e tcnicas.

Ciclo de trabalho de uma sesso: preparao,
execuo e reviso.
Agenda padro de uma sesso: introduo, reviso
de perspectiva gerencial, abertura pelo executivo
patrocinador, viso da rea de informtica, regras
de conduta, abordagem da sesso, reviso de
pendncias, reviso geral, avaliao da sesso.
Abordagem da sesso: varia de acordo com o tipo
de sesso.
Tcnicas de elicitao
18
Sesso de gerenciamento
Visa discutir o escopo do projeto, objetivos, metas,

recursos e estratgias a serem adotadas.
tipicamente a primeira sesso de um projeto,
permitindo identificar suas partes componentes e
prioridades.
Participantes: gerentes de alto nvel e executivos das
reas de negcios envolvidas, bem como o
representante da rea de informtica
Nmero de participantes: mximo 20
Tcnicas de elicitao
19
Sesso tcnica
Define as funes componentes do sistema, a lgica

de funcionamento do negcio e de que forma os
elementos se relacionam e so tratados.
Devem ser orientadas par suprir as informaes
necessrias criao dos modelos de dados e
processos.
Participantes: gerentes e supervisores das reas de
negcio. Devem ser capazes de conhecer o negcio,
fluxos de trabalho.
Nmero de participantes: mximo 10
Tcnicas de elicitao
20
10
Ciclo de trabalho JAD

Devido ao seu alto grau de planejamento,

estruturao e formalizao, o JAD pode ser
visualizado como um ciclo de processo que engloba
as fases:
Preparao;
Sesso (a execuo de uma sesso);
Reviso.
Tcnicas de elicitao
21
Ciclo de trabalho - preparao

Examinar adequao do JAD: avaliar em conjunto

com o gerente de projeto: os riscos (para o negcio,
projeto e tcnica), tamanho do projeto, domnio da
metodologia, etc.
Planejar: dimensionar n de sesses, durao,
alocao de recursos.
Elaborar a perspectiva gerencial: finalidade, escopo,
objetivos e restries.
Familiarizar-se com a rea de negcios: entrevistar
participantes previamente.
Preparar agenda da sesso: seguir padro.
Preparar participantes: informar agenda e pedir
exerccio de casa.
Preparar ferramenta de documentao.
Tcnicas de elicitao
22
11
Ciclo de trabalho - sesso

Preparar ambiente: arrumao das mesas, verificao

dos equipamentos audiovisuais, checklist dos
materiais, preparao de pastas.
Conduo da sesso: apresentao dos participantes,
explicar agenda, abordar logstica, rever perspectiva
gerencial, desenvolver agenda.
Documentao: anotar todas as deliberaes da
reunio, ler todo o material e gerar documentao.
Encerramento: reviso geral da agenda, avaliao da
sesso, entrega da documentao produzida.
Tcnicas de elicitao
23
Ciclo de trabalho - reviso

Rever documentao: verificar se informaes esto

corretas, corrigir falhas de comunicao, encaminhar
documentao aos participantes.
Examinar avaliaes: avaliar se o mtodo est sendo
efetivamente til e a satisfao dos participantes.
Preparar pasta do projeto: contendo perspectiva
gerencial, plano de sesses, agenda de cada sesso,
lista de participantes de cada sesso, documentao
produzida em cada sesso e questionrios de
avaliao.
Tcnicas de elicitao
24
12
Elaborao da agenda JAD

Identificar a finalidade e objetivos da sesso.

Identificar produtos (resultados esperados).
Identificar as informaes conhecidas.
Esboar as etapas da agenda.
Verificar coerncia lgica das etapas.
Identificar os participantes provveis.
Identificar as etapas que os participantes no tem
condies de realizar na sesso.
Identificar os dados prvios para as sesses.
Tcnicas de elicitao
25
Agenda padro JAD

Introduo:
Data, local, incio e fim previstos
Objetivos: Levantamento, acompanhamento, informativa, definio de
tarefas, tomada de decises, etc.
Moderador, demais participantes e funes
Atividades prvias
Regras de conduta
Abordagem da sesso:
Desenvolvimento dos itens especficos da pauta
Reviso
Pendncias
Concluses
Tcnicas de elicitao
26
13
Agenda padro JAD - Introduo

Reviso do JAD, papis, horrios, apresentao dos

participantes e da agenda.
Reviso da perspectiva gerencial: comentrios sobre a
definio da alta gerncia.
Abertura pelo executivo patrocinador: mostra o apoio da
cpula, importncia, objetivos e motivo de escolha da
equipe.
Viso da rea de Informtica: questes tecnolgicas e de
andamento de projeto.
Regras de conduta: comportamentos indicados para
sesso.
Tcnicas de elicitao
27
Agenda padro JAD Abordagem da

sesso
Passos especficos para se alcanar os

objetivos da sesso.
Finalidade
Produto esperado
Processo envolvido
Sequncia
Tcnicas de elicitao
28
14
Agenda padro JAD Reviso

Reviso das pendncias: situao do item,

responsvel e data prevista para a soluo.
Reviso geral: rpida passagem pelo material

produzido para verificar se o resultado est coerente e
coeso, de acordo com o previsto.
Avaliao da sesso: obteno do feedback dos
participantes sobre o mtodo utilizado e desempenho
do facilitador.
Tcnicas de elicitao
29
Consideraes sobre o JAD

Enquanto tcnica, o JAD prope captar os pontos

principais das demais tcnicas visando tornar mais
produtivas as reunies.
A estrutura do JAD pressupe um trabalho considervel
de documentao e atividades preliminares e
posteriores.
bvia a importncia e uso de reunies como
mecanismos de interao entre pessoas em qualquer
aspecto da sociedade.
Para qualquer situao de reunio profissional pode ser
seguido o modelo do JAD.
Tcnicas de elicitao
30
15
Exemplo de agenda JAD - Introduo

Explicao: sero explicados aspectos preliminares

sobre a sesso (Durao: 10 Min.). Aspectos:
Perodo: 1, 2 e 3/4 de 2009;
Horrio: 8h s 17h. Intervalo: 10h s 10h15, 15h30 s
15h45. Almoo: 12h s 13h.
Recursos disponveis: Projetor, computador, quadro
magntico e flipchart.
Apresentao dos participantes: Nicolau dos Santos
(Executivo patrocinador), Philip Kotler (Gerente de
Marketing), Bill Gates (Gerente de Informtica),
Domenico de Masi (Gerente de RH), Jos Silva
(Facilitador) e Sra. Maria Santos (Documentadora).
Tcnicas de elicitao
31
Exemplo de agenda JAD Introduo

Funcionamento do JAD: O Sr. Jos Silva far uma

explicao do JAD e suas principais caractersticas
como trabalho em equipe, deciso por consenso,
papel do facilitador, agenda, etc.
Apresentao dos assuntos da agenda: Sero lidos
os itens da Abordagem da Sesso.
Reviso da perspectiva gerencial: Os participantes
expressaro suas opinies e sugestes. Durao 50
Min.
Tcnicas de elicitao
32
16

Abertura pelo executivo patrocinador: O Sr.

Nicolau dos Santos mostrar a importncia do
projeto no contexto do negcio, o que a
administrao pretende alcanar e por que
aquela equipe foi escolhida. Durao: 15 Min.
Viso da rea de informtica: O Sr. Bill Gates
falar das atuais tecnologias e tendncias no
escopo do projeto. Durao: 20 Min.
Tcnicas de elicitao
33

Regras de conduta: Sero explicadas as normas de

comportamento a serem seguidas durante a sesso.
So vedadas conversas em paralelo, utilizao de
telefone celular, interromper a fala de outro
participante, fumar durante a sesso, crticas
destrutivas ou pessoais a opinio de outros
participantes. Durao 5 Min.
Abordagem da sesso: Nesta etapa sero discutidos
os assuntos especficos da sesso. Os assuntos sero
divididos em seis etapas. Durao: 3:00 H.
Tcnicas de elicitao
34
17
Exemplo de agenda - Abordagem da sesso

Tema 1: Descrio do ambiente atual

Incio: 8h. Durao: 1h.
Finalidade: Descrever a situao atual e as reas de negcios.
Produto esperado: descrio da situao atual, incluindo:
processos atuais (possibilidades, pontos fortes e fracos,
restries), situao competitiva e oportunidades para a
organizao.
Processo envolvido: participantes devero preencher
previamente um questionrio que ser apresentado durante a
sesso.
Sequncia: Discusso dos pontos apresentados, brainstorming,
seguido de votao.
Tcnicas de elicitao
35

Tema 2: Descrio dos problemas das reas.

Incio: 10 H 15. Durao: 1 H 30.
Finalidade: Apontar os principais erros existentes na
situao atual. Sero usados para definir e justificar
objetivos e solues a serem adotadas.
Produto esperado: descrio dos problemas atuais do
negcio.
Processo envolvido: Idem tema 1.
Sequncia: Brainstorming, seguido de votao.
Tcnicas de elicitao
36
18

Tema 3: Descrio dos objetivos para a nova situao.
Incio: 13 H. Durao: 1 H.
Finalidade: Listar os objetivos a serem alcanados atravs de
modificaes nas reas de negcios. Os objetivos devem estar
associados a problemas encontrados na etapa anterior.
Produto esperado: descrio de todos os objetivos.
Processo envolvido: Idem ao tema 1.
Sequncia: Idem ao tema 2.
Tcnicas de elicitao
37

Tema 4: Descrio dos requisitos.

Incio: 14h. Durao: 1 H 30.
Finalidade: Definio das solues (requisitos) para a nova
situao esperada. Define como sero alcanados os
objetivos.
Produto esperado: descrio dos requisitos.
Tcnicas de elicitao
38
19

Tema 5: Descrio das restries para os requisitos.

Incio: 15 H 45. Durao: 30 Min.
Finalidade: Definio de restries de ordem fsica, poltica,
legal, que possam afetar os requisitos estabelecidos. As
restries determinam limites, fronteiras e balizamentos para
o sistema.
Produto esperado: descrio das restries.
Tcnicas de elicitao
39

Tema 6: Prioridade dos requisitos.

Incio: 16 H 15. Durao: 30 Min.
Finalidade: Dar prioridade aos requisitos.
Produto esperado: Indicao da prioridade de cada
requisito.
Processo envolvido: atravs do estabelecimento dos
critrios de prioridade como custo, competitividade,
facilidade de implementao e posterior associao a cada
requisito.
Sequncia: Descrio de cada item e votao.
Tcnicas de elicitao
40
20
Exemplo de agenda JAD - Reviso

Reviso de pendncias: Sero resolvidas as pendncias e

agendadas novas. Consiste em: Descrio da pendncia,
situao, responsvel, data para soluo. Durao 5 Min.
Reviso geral: Ser feita uma passagem pelo material produzido
na sesso, avaliando os resultados obtidos. Durao 5 Min.
Avaliao da sesso: Ser obtido o feedback de todos os
participantes sobre o mtodo utilizado e sobre o comportamento
do facilitador, visando adequar e melhorar o processo para as
prximas sesses. Durao 5 Min.
Tcnicas de elicitao
41
Referncias bibliogrficas
Costa, Wilson Dias Da - JAD Joint Application

Design, Ibpi Press, 1994.
Gause, D. e Weinberg, G. Explorando
Requerimentos de Sistemas, Makron Books, 1989.
Tcnicas de elicitao
42
21
Casos de uso

Verso 1.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.
Requisitos
C4-Casos de uso
Roteiro
Requisitos e casos de uso
Definio de caso de uso
Definio de ator
Relacionamentos
Diagrama de caso de uso
Estrutura de um caso de uso
Descrio de um caso de uso
Processo de modelagem de casos de uso
Diretrizes para elaborao de casos de uso
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.
Requisitos
C4-Casos de uso
Natureza dos requisitos

Domnio do
problema
Necessidades
Requisitos de usurio
Domnio da
soluo
Requisitos de sistemas
Requisitos de desenho
Requisitos
Produto a ser
construdo
Separao entre domnios

A separao em domnios indica que os

requisitos de software tratam da soluo e no
do problema.
O formato da pirmide reflete o volume relativo
do problema: poucas necessidades podem exigir
vrios requisitos.
O relacionamento de rastreabilidade deve ser
mantido entre todos os nveis.
Requisitos
C4-Casos de uso
Rastreabilidade dos requisitos
N1
Ru1
Rs1
Rd1
Rs2
Rd2
Nx
Ru2
Rs3
Rd3
Ruy
Rsz
Rd4
Rdn
P: Essa figura representa rastreabilidade uni ou bidirecional? ___________________

Requisitos
Limitaes dos requisitos

Dados os requisitos de um caixa eletrnico:
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 no
pertena a instituio em que tem conta, o sistema
deve cobrar uma taxa.
Surgem as questes:
Em qual ordem essas coisas devem ser feitas
(caso a ordem importe)?
A taxa deve ser cobrada antes ou depois do
saque?
Requisitos
C4-Casos de uso
Limitaes dos requisitos

Para um dado conjunto de requisitos, pode ser
praticamente impossvel entender o que os
autores dos requisitos querem que seja feito.
Os requisitos normalmente so ambguos e
incompletos pois no informam quando e sob
quais condies os comportamentos ocorrem.
A seqncia um requisito em certos casos.
Os requisitos tradicionais capturam abordagens,
com nfase em requisitos declarativos e
sentenas do tipo deve, falhando em capturar o
comportamento dinmico do sistema.
Outra: ___________________________________
Requisitos
Modelagem de casos de uso

Um caso de uso uma forma de expressar
os requisitos do sistema, especialmente seu
comportamento.
A idia bsica por trs da modelagem de um
caso de uso a seguinte:
Capturar a essncia 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
usurio necessita.
Requisitos
C4-Casos de uso
10
Casos de uso no contexto dos requisitos

Necessidades
Requisitos
Requisitos
funcionais
no funcionais
Casos
de uso
Especificao
suplementar
Especificao
suplementar
P: Casos de uso so uma especificao completa de todos os requisitos? ___________

Requisitos
11
Casos de uso e requisitos

Um caso de uso contm a especificao de um

conjunto de requisitos, apresentados de forma
narrativa ao invs de estrutura de tpicos ou outra
(lembra dos fluxogramas?).
Um caso de uso coloca os requisitos no contexto da
descrio de algo que o usurio 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.
Requisitos
C4-Casos de uso
12
Casos de uso e requisitos

Casos de uso so uma boa tcnica para

modelagem de requisitos. Eles provm uma
maneira padronizada de capturar, explorar e
documentar o que um sistema deve fazer.
Um caso de uso pode atender a vrios requisitos
e um mesmo requisito pode ser atendido por um
ou vrios casos de uso. D um exemplo:
________________________________________
Um requisito no um caso de uso e vice
versa.
Requisitos
13
Casos de uso e a natureza dos requisitos

Casos de uso capturam facilmente (sob o ponto de vista do

usurio) conjuntos de requisitos funcionais, descrevendo o
comportamento do sistema como uma interao entre usurios ou
outros sistemas e o sistema em questo, para fazer algo til,
conforme seus interesses.
Casos de uso no envolvem: interfaces externas, formatos de
dados, regras de negcio e frmulas, algumas vezes complexas.
Requisitos no funcionais so melhor descritos usando textos
declarativos ou meios visuais.
Descrever requisitos no funcionais por meio de casos de uso
uma maneira de confundir ambos. Exemplo:
_______________________________________________________
Requisitos
C4-Casos de uso
14
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 provm uma boa viso
geral sobre o sistema. Entretanto, a grande fora
dos casos de uso est em sua descrio textual,
que ser vista mais frente.
Requisitos
15
Representao 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 estria de como um sistema e seus
atores colaboram para um dados objetivo.
A UML representa casos de uso como elipses:
Requisitos
C4-Casos de uso
16
Atores
Conjunto coerente de papis que os usurios

exercem quando interagem com os casos de
uso. [OMG]
Aspectos chave dos atores:
Representam pessoas ou outros sistemas.
Definem os papis que os usurios ou outros

sistemas exercem.
Esto fora do sistema, e geralmente fora do controle

do mesmo.
Impem requisitos que o sistema deve atender.
Requisitos
17
Representao de atores
Um ator define um papel que um usurio pode

exercer quando interage com o sistema. Um
usurio ainda pode um indivduo ou outro
sistema.
A UML representa atores como bonecos:
Requisitos
C4-Casos de uso
18
Stakeholders e atores
Stakeholder algum ou algo que tem um

interesse legal no comportamento do caso de
uso. Obs: conceito anlogo GP.
Um ator qualquer coisa que tem um
comportamento. Um ator pode ser uma pessoa,
companhia ou organizao, um programa de
computador ou um sistema computacional
Todo ator primrio, naturalmente, um
stakeholder, mas alguns stakeholders nunca
interagem diretamente com o sistema.
Requisitos
19
Ator primrio
o stakeholder que chama o sistema para entregar um

de seus servios. Ele tem um objetivo com respeito ao
sistema - que pode ser satisfeito por sua operao.
Geralmente o caso de uso comea porque o ator
primrio envia uma mensagem, pressiona um boto,
pressiona uma tecla ou de alguma outra forma inicia a
estria.
Entretanto, h pelo menos duas situaes em que um
UC no iniciado por um ator primrio:
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.
Requisitos
C4-Casos de uso
20
10
Atores secundrios
Atores externos que provm um servio 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 primrio em um caso de uso e
secundrio em outro. Exemplo:
_________________________________________
Requisitos
21
Comunicao entre ator e caso de uso

Razes para o ator acionar o caso de uso:
Solicitar dados armazenados no sistema.
Mudar dados armazenados no sistema.
Informar que algo importante aconteceu em torno do

sistema.
Razes para o caso de uso acionar o ator:
Informar ao ator se algo importante aconteceu com o

sistema.
Pedir apoio para tomada de alguma deciso.
Delegar responsabilidades a atores.
Requisitos
C4-Casos de uso
22
11
Relacionamentos
Casos de uso e atores no existem sozinhos.
A UML define diversos de relacionamentos no

modelo de casos de uso:
Comunicao: Interao direta entre ator e caso de uso. a

situao mais comum.
Incluso: Prov a habilidade de extrair sees comuns

entre dois ou mais casos de uso e coloca-las em um caso
de uso separado, favorecendo o reuso.
Extenso: Usado em casos onde um comportamento

opcional ou excepcional inserido em um caso de uso
existente.
Generalizao: Usado quando elementos possuem

comportamentos em comum. Ex: atores.
Requisitos
23
Diagramas do modelo de caso de uso
Diagrama com uma viso geral com principais

atores e casos de uso. Tambm 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.
Requisitos
C4-Casos de uso
24
12
Exemplo de diagrama de caso de uso
Detalhar pagamento
Requisitos
Fazer pagamento com
Fazer pagamento com
dinheiro
cheque
25
Descrio de Casos de Uso

Descrio de um conjunto de seqncias de

aes, incluindo variaes, que um sistema
executa para atingir um resultado de valor
observvel 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.
Requisitos
C4-Casos de uso
26
13

A UML define que os casos de uso possuem dois

elementos de modelagem: uma representao grfica e
uma descrio textual.
Entretanto, no definido um padro para a descrio
textual de um caso de uso.
Portanto, a descrio de um caso de uso pode variar
desde um texto livre com alguns pargrafos at uma
estrutura de dados com campos bem delimitados.
H vantagens e desvantagens em ambas abordagens. Ex:
Vantagem: __________________________________________
Desvantagem: _______________________________________
Requisitos
27
Estrutura geral de um caso de uso

Identificao
Nome
Descrio
Pr-condies
Ps-condies
Fluxo de eventos
Fluxo principal (mais comum)
Fluxos alternativos
Fluxos de exceo
Sub-fluxos (deve-se evitar)
Requisitos
C4-Casos de uso
28
14

Nome: Deve ser nico e identificar o que atingido

atravs da interao entre o caso de uso e o ator.
Descrio:
Pr-condies: Descrio textual que define restries

quando o caso de uso deve iniciar.
Ps-condies: Descrio textual que define restries

quando o caso de uso termina.
Fluxo de eventos: Descrio textual do que o sistema faz

em relao ao caso de uso. estruturado em:
Fluxo principal: Fluxo principal ou padro.
Fluxos alternativos: Fluxos com cenrios alternativos ao principal.
Sub-fluxos: Subdiviso de um fluxo para fins de clareza. EVITAR!
Requisitos
29

A descrio de um caso de uso narra uma estria de

como o sistema e seus atores colaboram para atingir um
objetivo especfico.
uma descrio 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:
Incio (como o ator inicia o caso);
Meio (como sistema e atores interagem);
Fim (como o caso de uso encerrado).
Requisitos
C4-Casos de uso
30
15
Importncia da descrio textual

Cerca de 90% do modelo de caso de uso reside

nas descries. Portanto, a parte mais
trabalhosa de se modelar.
A parte mais importante de um caso de uso a
descrio.
A parte mais importante da descrio o fluxo de
eventos.
O fluxo de eventos tem uma estrutura bem
definida, baseada nos conceitos dos fluxos
principal, alternativos e de exceo.
Requisitos
31
Cenrios (fluxos) e passos

Um conjunto de casos de uso uma estria j

desdobrada de atores primrios perseguindo
objetivos. Cada caso de uso tem um enredo
cruzado e mostra o sistema alcanando o objetivo
ou o abandonando. um descrio teatral.
Esse enredo est presente na forma de um cenrio
bsico e um conjunto de fragmentos de cenrios,
como extenses dele.
Cada cenrio ou fragmento comea com uma
condio de acionamento que indica quando ele
executado e vai at mostrar a concluso ou o
abandono de seu objetivo.
Requisitos
C4-Casos de uso
32
16
Estrutura tpica de fluxo de eventos

Fluxo principal
Fluxo alternativo
Fluxo alternativo
Requisitos
33
Fluxo principal
Descrio, de cima para baixo, de um cenrio

bastante caracterstico no qual o objetivo do ator
primrio alcanado e todos interesses dos
stakeholders so satisfeitos.
O fluxo principal descreve a forma mais usual
(padro) de se atingir os objetivos do ator
principal.
Todas as outras maneiras de ter sucesso e o
tratamento de todas as falhas, so descritos nas
extenses do fluxo principal nos fluxos alternativos
e de exceo.
Requisitos
C4-Casos de uso
34
17
Organizao de cenrios
Fluxos alternativos estendem o fluxo principal para tratar as

variaes e excees.
Sub-fluxos podem ser usados para facilitar a leitura de um fluxo
complexo. Pode ser substitudo por outro caso de uso.
Pr e ps condies 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). Prcondies so mais comuns que ps-condies.
A descrio deve ser longa o suficiente para poder descrever a
estria e simples o suficiente para no dificultar os trabalhos nem
tornar o modelo complexo. Deve-se utilizar linguagem clara e
objetiva.
Requisitos
35
Estrutura comum aos fluxos

Uma condio sob a qual o cenrio executado: para o

cenrio principal a pr condio mais o acionador. Para um
cenrio de extenso, a condio de extenso.
Um objetivo a alcanar: para o principal, o nome do caso de
uso. Para um cenrio de extenso, o objetivo completar o
caso de uso ou ingressar no cenrio de sucesso.
Um conjunto de passos de ao: formam o corpo do cenrio e
seguem as mesmas regras em todo cenrio ou fragmento de
cenrio.
Uma condio de fim: objetivo atingido ou abandonado.
Um possvel conjunto de extenses escritas como fragmentos
de cenrio.
Requisitos
C4-Casos de uso
36
18
Condies de extenso
So as condies sob as quais o sistema tem um comportamento

diferente (fluxos alternativos e/ou exceo).
Exemplo:
...
4. Usurio solicita salvamento do arquivo
...
Extenses:
4a. Sistema detecta a necessidade de salvamento
4a1. ... (passos)
4b. Salvamento falha
4b1. ... (passos)
Requisitos
37
Condies de extenso - exceo

A condio deve dizer o problema detectado.

Exemplos:
Senha invlida.
Rede inoperante.
Cliente no responde.
Dinheiro indisponvel.
Obs: no levantar cdigos de erro internos.

Racionalize e rena as falhas similares, de modo a

simplificar a anlise.
Avalie as condies de falhas dentro de falhas.
Requisitos
C4-Casos de uso
38
19
Exemplo de descrio de caso de uso

Nome: Registrar sinistro.
Ator primrio: Atendente.
Pr-condio: Segurado e aplice habilitados.
Fluxo principal:
1. Atendente informa nmero da aplice do segurado.
2. Sistema retorna informaes da aplice.
3. Atendente confirma dados do segurado.
4. Sistema confirma que no h nenhum sinistro em aberto para o segurado.
5. Atendente informa detalhes do sinistro: tipo, local, data, hora, descrio.
6. Sistema valida os dados informados e gera nmero (sequencial no ano) da
comunicao.
7. Atendente informa nmero da comunicao ao segurado
8. Atendente designa um agente para o atendimento.
9. Sistema solicita confirmao para fechamento da comunicao.
10. Atendente confirma operao.
10. Sistema salva os dados e envia e_mail para o agente designado.
Requisitos
39

(cont.)
Fluxos alternativos:
FA1. Atendente informa que ligao somente para consulta.
1. Sistema registra informao.
FA2. Atendente pode salvar os dados incompletos a qualquer

momento, antes da concluso do UC.
1. Registrar comunicao com status Pendente.
FA3. Atendente altera informaes da aplice ou data do sinistro.

1. Sistema valida informaes e verifica se aplice est disponvel.
1. Atendente informa cdigo da aplice ou CPF/CGC ou nome do segurado.
2. Sistema edita aplice a partir dos dados da pesquisa.
(E se no encontrar? _______________________________________________)
3. Atendente altera data ou outros dados do sinistro.
Requisitos
C4-Casos de uso
40
20

Fluxos de exceo:
FE1. Informao de aplice encontrada no corresponde ao segurado:
1. Atendente informa nmero correto de aplice.
FE2. Sistema no encontra aplice, a partir de detalhes:
1. Atendente informa detalhes corretos.
FE3. Sistema identifica comunicao duplicada:
1. Sistema exibe lista de comunicaes existentes.
2. Atendente seleciona uma comunicao.
2a. Atendente edita comunicao.
FE4. Atendente termina sem completar informaes obrigatrias.

1. Sistema informa que transao no pode ser concluda.
Requisitos
41
Requisitos
C4-Casos de uso
42
21
Estgios de escrita dos casos de uso

Estgio de escrita Propsito principal
Descoberta
Identificar caso de uso
Atividades associadas
Gerenciamento de escopo
Breve descrio
Gerenciamento de escopo
Esboo inicial
Esboo essencial
Riscos atacados
Desconhecer limites
do sistema
Resumir propsito do caso Ambiguidade na
de uso
definio do modelo
Resumir formato e extenso -Desconhecer
do caso de uso
extenso, escala ou
complexidade do
sistema
-Desconhecer casos de
uso requeridos
Resumir essncia do caso Facilidade de uso
de uso
-Gerenciamento de escopo
-Estimativa inicial
-Prototipagem visando
atender requisitos e atacar
riscos tecnolgicos
-Desenho de interface com

usurio
-Prototipagem visando
atender requisitos e atacar
riscos tecnolgicos
Descrio
Permitir adicionar detalhes Nenhum (passo
Nenhum (passo
detalhada
de forma incremental
intermedirio)
intermedirio)
Descrio completa Prover completa
-No saber exatamente -Anlise e desenho
especificao funcional para o que o sistema deve
-Implementao
o comportamento
fazer
-Testes de integrao
encapsulado pelo caso de
-No ter uma
-Testes de sistema
uso
especificao de
-Documentao de usurio
requisitos
-Estimativa refinada
compartilhada
Requisitos
43
Caso de uso e as disciplinas do RUP

Requisitos: O modelo de caso de uso construdo

nessa disciplina.
Anlise e desenho: Casos de uso so realizados pelos
modelos de anlise e desenho. Aqui descrito como
os objetos se relacionam para atingir o objetivo do
caso de uso.
Implementao: O cdigo desenvolvido para
executar os casos de uso.
Testes: Os casos de uso servem de base para
identificar os casos de teste e procedimentos
especficos.
Requisitos
C4-Casos de uso
44
22
Relacionamento entre o modelo de casos de

uso e outros modelos
Verificado por
Expresso por
Implementado por
Realizado por
Requisitos
45
Ciclo de escrita de caso de uso

Especifique o escopo e os limites do sistema.
Identifique os atores primrios.
Identifique os objetivos dos usurios para com o

sistema.
Selecione um caso de uso para expandir:
Capture os stakeholders e interesses;
Escreva o fluxo principal;
Identifique os fluxos alternativos e de exceo;
Escreva os passos de tratamento de extenso;
Extraia os fluxos complexos para subcasos de uso.
Reajuste o conjunto: adicione, subtraia e junte casos de

uso conforme necessrio, iterativamente.
Requisitos
C4-Casos de uso
46
23
BITTNER, Kurt e SPENCE, Ian, Use Case

Modeling, Addison-Wesley, 2003.
COCKBURN, Alistair, Escrevendo casos de
uso eficazes, Bookman, 2005.
OMG, Object Management Group, UML www.omg.org, 2004.
Requisitos
C4-Casos de uso
47
24
Modelagem de casos de uso

Verso 1.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.
Requisitos
C5-Modelagem casos de uso
Roteiro
Diretrizes para elaborao de casos de uso
Requisitos
Identificao de atores
Inicie identificando os atores principais (usurios).
Trabalhe do especfico para o geral.
No esquea os atores de apoio.
Considere todas as informaes sobre requisitos.
Lembre-se que atores nem sempre so pessoas.
Observe os limites (escopo) do sistema.
Identifique as fontes de informao.
Requisitos
Identificao de atores
No confunda atores com os dispositivos de E/S. Ex:

terminal de auto atendimento.
No confunda atores com papis da organizao ou
ttulos de emprego. Ex: gerente, superintendente.
No generalize em excesso. Ex: ________________
Caracterize os atores e crie uma descrio breve de
cada ator. Faa isto na lista de atores.
Associe os atores aos tipos de usurios, stakeholders
e papis destes. Ex: ___________________________
Requisitos
Questes para identificar atores

Quem ir utilizar o sistema?
Quem ir fornecer, receber ou remover informao?
Quem est interessado em determinado requisito?
Quais outros sistemas devem interagir com este?
Quais so os recursos externos ao sistema?
Quem inicia o sistema (interao)?
Quem ir manter o sistema?
Existe algum ator disparado por evento ou tempo?

Requisitos
Lista de atores
Nome e breve descrio.
Escopo (responsabilidades).
Ambiente fsico de uso do sistema.
Quantidade e tipo de usurios representados pelo

ator (para dimensionamento da rede).
Freqncia de uso (para dimensionamento da rede).
Nveis de conhecimento sobre negcio e tecnologia.
Faixa etria.
Etc: _______________________________________
Requisitos
Localizao dos casos de uso

Inicie identificando as metas dos atores.

Considere as necessidades de informao do
usurio e sistema.
No confunda caso de uso com funo. Uma
funo pode corresponder a vrios casos de
uso e vice-versa.
No se esquea dos casos de uso de apoio e
operacionais. Ex: ________________________
Requisitos
Questes para identificar casos de uso

Para cada ator quais so as necessidades (objetivos)

que o sistema deve atender?
O ator dever informar ao sistema que tipo de
mudanas de estado / situaes?
Quais casos de uso iro iniciar, parar, configurar,
apoiar e manter o sistema?
Sobre quais eventos o sistema deve ser informado?
Sobre quais ocorrncias o sistema deve registrar e
informar aos atores?
O modelo de casos de uso representa os interesses de
todos os stakeholders?
Requisitos
Diretrizes para elaborar fluxos de UC

Descrever como o fluxo inicia e termina.

Descrever quais dados so trocados entre ator e caso de
uso. prefervel descrever grupos de dados a itens
elementares.
No descrever detalhes de interface com o usurio a menos
que seja necessrio para entender o comportamento do
sistema. Ex: no descrever que tipo de boto ser utilizado.
Descrever o fluxo de eventos, no somente a funcionalidade.
Iniciar o fluxo com o ator (mais comum) ou o sistema.
Descrever somente os eventos que pertenam ao caso de

uso em questo.
Requisitos
10
Diretrizes para elaborar fluxos

Descrever o que o sistema faz e no como projetado.

Detalhar o fluxo de eventos, respondendo a todas as perguntas,
principalmente para os testes (que tero por base o UC).
Utilizar vocabulrio simples, na medida do possvel.
Escrever sentenas curtas e frases diretas.
Evitar advrbios como muito, mais, ao invs, etc.
Evitar terminologia vaga como informao, relevante,

suficiente, etc.
Utilizar pontuao correta.
Deixar clara a seqncia de eventos.
Destacar termos que se encontram no glossrio (jargo tcnico).

Requisitos
11
Diretrizes para escrever passos

Utilizar estrutura gramatical simples:

Sujeito + verbo + objeto direto + preposio.
Sistema deduz a quantia do saldo da conta
Mostrar claramente quem comanda a ao:

Pessoa1 Pessoa2 ou Pessoa1 Sistema
Escrever com uma viso geral:
Errado:
Pegar carto e senha. Deduzir quantia do saldo.
Certo:
Cliente insere carto e senha.
Sistema deduz quantia do saldo da conta.
Requisitos
12

Descrever o objetivo do passo, evitando passos muito curtos

Errado:
Usurio pressiona a tecla Tab (Com qual objetivo?...)
Certo:
Usurio informa nome e endereo
Mostrar a interao entre atores, no os movimentos:
Errado:
Sistema pergunta nome.
Usurio informa nome.
Sistema pergunta endereo.
Excesso de detalhes!
Usurio informa endereo.
Usurio pressiona OK.
Sistema apresenta perfil do usurio.
Certo:
Usurio informa nome e endereo.
Sistema apresenta perfil do usurio.
Requisitos
13

Pensar em um passo como representando uma transao. Siga

a estrutura:
Ator primrio envia solicitao e dados ao sistema.
Sistema valida solicitao e dados.
Sistema altera seu estado interno.
Sistema fornece resultado.
Preferir Valida ao invs de Verifica, em aes de validao:
Errado:
Sistema verifica se senha est correta.

Se est, sistema apresenta aes disponveis.
Certo:
Sistema valida senha.
Sistema apresenta aes disponveis.
Requisitos
14
Diretrizes para escrever casos de uso

Priorizar comunicao efetiva entre todos interessados.
Perseguir a simplicidade ao escrever casos de uso.
Lembrar-se que a audincia dos casos de uso so os

usurios, que devem ser capaz de entend-los.
O bom inimigo do timo. No existe perfeio na
escrita de casos de uso.
Requisitos
15
Diretrizes para escrever casos de uso

Associar sempre os casos de uso aos seus atores.
Nomear os casos de uso usando voz ativa.
Dar a cada caso de uso uma breve descrio.
Delimitar bem os casos de uso (escopo), dentro do devido

domnio (nvel de detalhe).
Associar casos de uso aos interessados e aos papis dos
interessados.
Associar os casos de uso aos requisitos e restries.
Requisitos
16
Alguns erros comuns

Cenrio sem sistema

1. Cliente passa carto e informa senha.
2. Cliente seleciona Saque e informa valor.
3. Cliente apanha dinheiro.
4. Cliente desconecta.
Cenrio sem ator primrio

1. Coleta carto e senha.
2. Coleta transao do tipo Saque.
3. Seleciona quantia desejada.
4. Valida saldo da conta.
5. Entrega o dinheiro.
6. Encerra.
Requisitos
17
Alguns erros comuns

Excesso de detalhes de interface:

1. Sistema apresenta tela de ID e senha.
2. Cliente digita ID e senha no sistema, clica em OK.
3. Sistema valida ID e senha e mostra tela Detalhes.
4. Cliente digita nome e endereo e clica em OK.
Nvel de objetivos muito baixo:

1. Usurio acessa sistema com ID e senha.
2. Sistema valida usurio.
3. Usurio fornece nome.
4. Usurio fornece endereo.
5. Usurio seleciona produto.
6. Sistema abre conexo com sistema de depsito.
7. Sistema de depsito retorna estoque atual.
Requisitos
18
Questes frequentes
Nmero excessivo de casos de uso.
Soluo: _________________________________________________________
Casos de uso CRUD.
Soluo: _________________________________________________________
Casos de uso excessivamente complexos.
Soluo: _________________________________________________________
Casos de uso que usurios no entendem.
Soluo: _________________________________________________________
Novos processos de negcio.
Soluo: _________________________________________________________
Uso excessivo de relacionamentos include e extend.
Soluo: _________________________________________________________
Requisitos
19
Nmero excessivo de casos de uso

Torna-se difcil o preenchimento de cada caso de em um

nvel adequado de abstrao quando se tem um nmero
excessivo de casos de uso.
Evite criar um caso de uso para cada cenrio possvel.
Ao invs disso, inclua os fluxos normal, alternativos e
excees em um nico caso de uso.
Tipicamente, h muito mais casos de uso do que
requisitos de negcio e mais requisitos funcionais do
que casos de uso.
Requisitos
20
10
Casos de uso CRUD

Por princpio, organize pequenos casos de uso do tipo Criar

<item>, Recuperar <item>, Alterar <item>, Excluir <item> em um
nico caso de uso Gerenciar <item>.
Isso reduz consideravelmente o nmero de casos de uso e o
trabalho.
Separe o caso de uso Gerenciar <item> somente se a
complexidade assim exigir.
Outra diretriz avaliar o nvel de acesso a uma funcionalidade.
Assim, o caso de uso Gerenciar <item> pode ser dividido
conforme o nvel de acesso ou a informao relativa pode ficar
em outro local, associado ao caso de uso. Esta situao ocorre
com frequncia com relao consulta.
Requisitos
21
Casos de uso excessivamente complexos

Escreva os casos de uso em funo da essncia dos
comportamentos dos atores e do sistema, ao invs de
especificar cada ao em detalhes.
Selecione um caminho de sucesso e derive dele vrios
caminhos simples como alternativos e exceo.
Tipicamente os fluxos alternativos e de exceo so mais
curtos e simples do que o fluxo principal.
Deixe as definies de dados para o dicionrio de dados e
no para os casos de uso.
Requisitos
22
11
Casos de uso que os usurios no entendem

Se os usurios no conseguem relatar a descrio de

seus processos de negcio ou tarefas do sistema, h
algo de errado com os casos de uso.
Escreva casos de uso da perspectiva do usurio e no

do sistema. Pea aos usurios para rev-los.
Nem sempre os casos de uso "full dressed

(exaustivos) so os mais indicados. Procure ser prtico.
Requisitos
23
Novos processos de negcio

Usurios podero ter dificuldade em lidar com casos de

uso se o software serve a um processo que no existe
ou est sendo alterado.
Avalie a possibilidade de realizar a modelagem de
processos de negcio antes de iniciar a modelagem de
casos de uso.
Problema: PSP no aborda modelagem de negcio!
Em ltima instncia, elabore um ou mais diagramas de

atividade com a viso de processos e associe os casos
de uso as atividades dos diagramas.
Requisitos
24
12
Uso excessivo de relacionamentos

include e extend
Incluso e extenso so situaes particulares, em que se

destaca um pedao do UC.
Ao se trabalhar com casos de uso pela primeira vez necessrio
adotar uma mudana na forma como analistas, usurios e
desenvolvedores pensam sobre requisitos.
Casos de uso no representam fluxos! Muitos problemas
surgem ao compar-los com outras tcnicas do paradigma
estruturado.
Esses elementos podem acrescentar uma complexidade
desnecessria para entendimento dos casos de uso.
Devem ser utilizados com parcimnia.
Requisitos
25
Tratamento de detalhes
Utilize o glossrio e o modelo de domnio para capturar

definies.
Use o modelo de domnio para capturar detalhes no
glossrio.
Capture regras de negcio no modelo de domnio.
Use sub-fluxos somente para simplificar descries
complexas. Em excesso, atrapalha a legibilidade.
Use fluxos alternativos para capturar comportamento
complexo e no usual.
Requisitos
26
13
Glossrio: O problema do domnio descrito atravs de um

conjunto simples de definies. Deve haver consenso a respeito
(envolver o usurio).
Modelo de domnio: Construdo atravs de diagramas de classe
UML, a partir dos termos-chave do glossrio. particularmente
importante se h relacionamentos complexos entre os objetos do
domnio do problema.
Especificao suplementar: Requisitos que no so claramente
capturados diretamente nos casos de uso ou interferem na clareza
do fluxo (tipicamente regras de negcio e requisitos no
funcionais).
Requisitos
27
Detalhes de informaes: Uma informao descrita em um

caso de uso pode ser composta por mais de um atributo
ou campo. Geralmente pode-se trata-la em grupo.
Listas de campos ou descries de dados: Cada atributo
possui nomes especficos que sero usados internamente
pelas classes. Deve haver um mapeamento de atributos.
Detalhes de campos e verificaes: Validaes e detalhes
especficos como tamanho, tipo, mscara de edio.
Devem constar do dicionrio de dados.
Esses itens deve fazer parte do caso de uso. As
especificaes devem constar de um documento a parte
que posteriormente ser associado ao caso de uso.
Requisitos
28
14
Exemplo de modelo de domnio
Requisitos
29
Exemplo de glossrio
Pedido: Um contrato entre a companhia e um cliente para

prover algum conjunto de itens para uma localizao em
particular de um cliente. Contm nmero e datas de
pedido, envio e entrega.
Item: Especifica a quantidade de um produto em
particular sendo pedido. Um item consiste da quantidade
de produto pedido, quantidade fornecida e o produto.
Cliente: Algum que solicita produtos. Possui um nome
e detalhes de contato.
Produto: Alguma coisa que pode ser vendida a um
cliente. A definio de um produto inclui descrio,
nmero e preo unitrio
Requisitos
30
15
BITTNER, Kurt e SPENCE, Ian, Use Case

Modeling, Addison-Wesley, 2003.
COCKBURN, Alistair, Escrevendo casos de
uso eficazes, Bookman, 2005.
OMG, Object Management Group, UML www.omg.org, 2004.
Requisitos
31
16

Apostila Requisitos v1.2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apostila Requisitos v1.2

Caricato da

Copyright:

Formati disponibili

Processo de Software da PBH/Prodabel

Gerncia de Engenharia de Software (GESS-PB)

Processo de software PBH/Prodabel

Processo de Software da PBH/Prodabel PSP

Gerncia de Engenharia de Software (GESS-PB)

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Problemas do desenvolvimento de software

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Problemas clssicos do desenvolvimento de software

Processo de software da PBH/Prodabel

Problemas com requisitos

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Processo de requisitos efetivo

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Classificao dos requisitos

Processo de software da PBH/Prodabel

Classificao dos requisitos

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Separao entre domnios

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Requisitos quanto visibilidade

Requisitos de sistema: Estabelecem detalhadamente as funes

Requisitos de desenho: Uma descrio abstrata que base para

Processo de software da PBH/Prodabel

Pblico-alvo dos documentos

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Exemplo de requisitos de usurio e sistema

Que software poderia ser este?

Processo de software da PBH/Prodabel

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Processo de software da PBH/Prodabel

Exemplos de requisitos funcionais

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Ex.: tempo de resposta, requisitos de armazenamento,

Tambm podem ser especificados uma determinada ferramenta

Podem ser mais crticos que os requisitos funcionais.

Caso no sejam atendidos, o sistema pode tornar-se inutilizvel.

Processo de software da PBH/Prodabel

Classificao dos requisitos no funcionais

Processo de software da PBH/Prodabel

Processo de software PBH/Prodabel

Classificao dos requisitos no funcionais

Requisitos organizacionais: Decorrem de polticas e

Requisitos externos: Abrangem todos os requisitos

Processo de software da PBH/Prodabel

Exemplos de requisitos no funcionais