Analise de Requisitos Software

Rildo F Santos
Analise de Requisitos de Software
rildosan@uol.com.br
rildo.santos@companyweb.com.br
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Anlise de Requisitos de Software

Verso 28
Rildo F Santos (rildosan@uol.com.br)
Todos os direitos reservados e protegidos 2006 e 2007
Contedo:
Sobre o Autor
Sobre a Apresentao
Introduo
1 Requisitos de Software
2 - Identificao e Elicitao de Requisitos

3 - Anlise de Requisitos
4 - Especificao de Requisitos com Caso de Uso
5 - Validao de Requisitos
6 - Gerenciamento de Mudana de Requisitos
Anexo
Verso 28
Sobre o autor:
Coach e Consultor de Gesto de Negcios, Inovao e Tecnologia para a Gesto 2.0, a Gesto gil.
A Gesto gil ajuda as empresas a responder mais rpido as demandas de negcio e mudanas. A Gesto 2.0, abrange
Planejamento Estratgico, Gesto por Processos geis, Gesto de Projetos geis, Tecnologia da Informao (Mtodos geis),
Inovao e Liderana.
Minha Experincia:
Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de
Software. Formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em Engenharia
de Software pela Universidade Mackenzie.
Rildo Santos
Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheo Mtodos geis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Servio),
RUP/UP - Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA.
Possuo fortes conhecimentos de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de
Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI;
E experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Conhecimento dos principais
frameworks e padres: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papis como: Estrategista de Negcio, Gerente de Negcio, Gerente de Projeto, Arquiteto de Software,
Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicaes, Seguro, Sade,
Comunicao, Segurana Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs.
Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Verso 28
Sobre o Apresentao
Esta apresentao discute e fornece informao sobre o Ciclo de Requisitos de Software, indo da
elicitao at a especificao de requisitos de software.
abordado as principais tcnicas, ferramentas e melhores prticas para desenvolvimento da
especificao de requisitos
Verso 28
Introduo
Anlise de Requisitos: Introduo

Um entendimento completo dos requisitos de software essencial para um o sucesso do
desenvolvimento do software. No importa quo bem projetado ou quo bem codificado
seja, um programa mal analisado e especificado frustrar o usurio.
Anlise de requisitos um processo de descoberta, refinamento, modelagem e
especificao.
O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado
durante o planejamento do projeto de software, aperfeioado em detalhes.
Modelos, diagramas, fluxos so criados para melhor compreenso do problema.
O analista e o usurio desempenham um papel ativo na anlise e especificao de
requisitos.
O cliente (usurio) tenta reformular um conceito de funo e desempenho de software, s
vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e
solucionador de problemas.
Entretanto, a anlise e especificao de requisitos pode parecer uma tarefa relativamente
simples, mas as aparncias enganam. O grau comunicao elevado. Da, surgem as
oportunidades de interpretaes errneas e informaes falsas. A ambigidade provvel.
O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a
declarao de um cliente annimo:
Sei que voc acredita que entendeu o que acha que eu disse, mas no estou certo
que percebeu que aquilo que ouviu no o que eu pretendia dizer...
Verso 28
Introduo
Ciclo de Desenvolvimento de Software:

Melhores Prticas: A Metodologia de Teste deve ser aplicada durante todo o ciclo
de desenvolvimento do software
Fases
Fluxos de Trabalho Concepo Elaborao
Construo
Transio
Modelagem de Negcios
Nosso
escopo
Requisitos
Anlise e Projeto
Implementao
Teste
Implantao
Opcional
Gerncia de Configurao
Gerncia de Projeto
Ambiente
Iteraes
Preelim.
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iteraes
Verso 28
Introduo
Da perspectiva da engenharia de software, a elicitao de requisitos talvez a mais parte mais critica
do processo de desenvolvimento de software.
Estudos indicam que os requisitos, s detectados depois do software implementado ou erros na anlise
de requisitos, so at 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Verso 28
Requisitos de Software
Objetivo desta parte:
apresentar e discutir o Ciclo de Requisitos de Software:
Identificao, Elicitao, Anlise, Especificao e
Validao
Verso 28
Introduo
Um cenrio comum:
Verso 28
Requisitos
Definies de requisito (segundo IEEE)

1) Uma condio ou uma capacidade de que o usurio necessita para solucionar um
problema ou alcanar um objetivo.
2) Uma condio ou uma capacidade que deve ser alcanada ou possuda por um sistema
ou componente do sistema, para satisfazer um contrato, um padro, uma especificao
ou outros documentos impostos formalmente.
3) Uma representao documentada de uma condio ou capacidade, conforme os itens
(1) e (2).
Verso 28
10
Contexto de Definio de Requisito:
Stakeholder = Todos os clientes interessados no contexto de requisitos
Verso 28
11
Elicitao de Requisitos
A elicitao de requisitos corresponde a identificar junto aos clientes/usurios quais so
os objetivos do sistema, o que deve ser acompanhado, como o sistema se encaixa no
contexto das necessidades do negcio e, finalmente, como ser a utilizao do sistema
no dia-a-dia.
A parte mais rdua na construo de um software consiste exatamente em identificar
o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do
trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade
para efetuar correes posteriores. " F. Brook
Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas
das razes desta dificuldade:
Problemas de escopo:
Os limites do sistema so geralmente definidos de forma incompleta, ou os
clientes/usurios especificam detalhes tcnicos desnecessrios;
Problemas de compreenso:
Os clientes/usurios geralmente no esto completamente certos das necessidades, tm
uma pouca compreenso ou do domnio do seu negcio, omitem informaes que julgam
bvias e etc.
Problemas de volatilidade:
Os requisitos mudam o tempo todo.
Verso 28
12
Para ajudar a superar estes problemas, os desenvolvedores devem abordar os requisitos
de forma simples, prtica e organizada. Alguns passos so recomendados para atividade
de Elicitao de Requisitos de Software:
- Avaliar a viabilidade tcnica e de negcio para o sistema proposto;
- Identificar as pessoas que vo auxiliar a especificar os requisitos e compreender seus
preconceitos organizacionais;
- Definir o ambiente tcnico no qual o sistema ser instalado;
- Identificar regras de domnio que limitam a funcionalidade ou desempenho do software
que ser construdo;
- Definir um ou mais mtodos de elicitao de requisitos;
- Solicitar participao de vrias pessoas para que os requisitos sejam definidos a partir
de diversos pontos de vista;
- Identificar claramente a justificativa de existncia para cada requisito registrado;
- Identificar requisitos ambguos que sero candidatos a prototipao.
Os documentos criados como conseqncia da atividade de elicitao de requisitos iro
depender do tamanho do software/sistema que ser construdo.
Verso 28
13
Para a maioria dos sistemas, estes documentos de trabalho incluem:

- As necessidades e viabilidade estruturadas;
- O limite de escopo do software/sistema;
- Lista de clientes, usurios e outros stakeholders* que participaram da atividade de
elicitao de requisitos;
- Descrio do ambiente tcnico do sistema;
- Lista de requisitos e as regras de domnio aplicveis a cada um.
- Conjunto de cenrios de uso capazes de prover uma idia do uso do sistema ou
produto sob diferentes condies de operao;
- Qualquer prottipo que eventualmente tenha sido desenvolvido para melhor definir os
requisitos.
Cada um destes documentos deve ser revisado por todas as pessoas que tenham
participado da elicitao de requisitos.
Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade
Verso 28
14
Objetivos da Elicitao de Requisitos:
Obter conhecimento relevante para o problema e prover o mais correto entendimento de

o que esperado do software/sistema;
Tcnicas para Elicitao de Requisitos:
- Cenrios: representar tarefas que executam e as que desejam executar
- Tcnicas tradicionais: questionrios, entrevistas, anlise de documentao existente
- Tcnicas de elicitao de grupo: Dinmica de grupo
- Prototipao: quando existe alto grau de incerteza e necessita de um rpido feedback
Verso 28
15
Requisitos. Road Map
Fazer identificao e elicitao

de requisitos
Regras de
negcio
Documento de Viso
Fazer Anlise de Requisitos

Usurios e
Clientes
Fazer Especificao de Requisitos
Documentos
Documento de
Requisitos
Fazer Validao de Requisitos

Documento de
Especificao
de Requisitos
Verso 28
16
Identificao e Elicitao de
Requisitos
apresentar e discutir as atividades de Identificao e
elicitao de requisitos
Verso 28
17
Identificao e Elicitao de Requisitos

de requisitos
Regras de
negcio
Documento de Viso

Usurios e
Clientes
Documentos
Documento de
Requisitos

Documento de
Especificao
de Requisitos
Verso 28
18

Identificao e elicitao de requisitos uma tarefa que parece simples, mas, no devemos
nos enganar, s vezes, para obtermos algumas informaes exigido muita dedicao,
persistncia e tcnica.
Esta parte apresenta e discute as principais tcnicas para identificao e elicitao de
requisitos de software.
Por que o elicitao importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente da
elicitao de requisitos, pois, a base que permitir ao Analista tirar concluses sobre as
situaes, problemas ou fenmenos e, assim, sugerir propostas que possam contribuir para
a soluo do problema.
Entretanto, esta atividade, nem sempre est presente no processo de desenvolvimento,
raramente ela elaborada de forma metodolgica, geralmente tem uma abordagem
intuitiva.
Principais caractersticas de uma boa elicitao de requisitos:
Definir as tcnicas de coleta de requisitos baseadas em fatores operacionais, tticos e
financeiros;
Criar um planejamento com objetivo de alcanar as metas estabelecidas, tais como:
Prazos, Custos e Qualidade;
Promover a integrao e o comprometimento de todos os envolvidos no processo, por
exemplo: Clientes, Fornecedores, Usurios e o Patrocinador.
Identificar os documentos e procedimentos que definem as polticas de negcios da
empresa.
Verso 28
19
Uma Simples Comparao:
Elicitao Boa
Elicitao Ruim
Bom Diagnstico
Diagnstico ineficiente
Solues eficientes
Solues medocres
Satisfao dos usurios
Insatisfao dos usurios
Melhoria dos processos e reduo de custo Problemas operacionais e financeiros
Verso 28
20
Documento (Artefato) desta etapa: Documento de Viso
Participantes:
Analistas e
Especialista
em Negcios
Reunies e
Workshops
Documentos
e sistemas
Objetivo:
Descrever
a viso inicial
do software
identificao/
elicitao de
Requisitos
Participantes:
Usurio,
Clientes,
Fornecedores e
Patrocinadores
Entrevistas
Verso 28
Observao
de campo
Documento
de viso
21

As fases da Identificao/Elicitao de Requisitos:
Um projeto de elicitao de requisitos tm as seguintes fases:
Como deve ser feito ?
Planejamento
Identificar Fontes
Tcnicas
O que devo coletar ?
Elicitao de
Requisitos
Identificar Funcionalidades
Identificar Restries e Riscos
Como devo documentar ?
Documentao
Documento de Viso
Verso 28
22
As informaes podem ser identificadas ou encontradas em diversas fontes:

- Usurios;
- Documentos;
- Especificaes tcnicas;
- Clientes;
- Sistemas legados
- Patrocinadores;
- Analista de Negcio
- Domain Experts - Especialista em uma ou mais rea de negcio
Verso 28
23
Quais so as tcnicas ?
Existem vrias tcnicas, todas elas possuem seus
prprios conceitos, vantagens e desvantagens,
que podem ser usada nesta atividade entre elas
esto:
- Reunies formais;
- Reunies informais;
- Entrevistas;
- Questionrios;
- Workshop;
- Brainstorming;
- JAD (Join Application Development)
- Fast;
- Anlise de Documentos;
- Manual de Sistemas Legados.
Verso 28
24

Quais as informaes que devo identificar, levantar e
coletar ?
Aps a atividade de Identificao/Elicitao de Requisitos,

atravs de alguma tcnica formal ou informal, as seguintes
informaes que devemos obter so:
Entendimento do problema, identificao da
lista dos principais usurios, lista dos principais Requisitos,
identificao dos Riscos e as Restries do software.
Da podemos organizar as informaes da seguinte maneira:
- Contexto (Declarao do problema e Diagrama de
Contexto);
- Identificao dos usurios e entidades externas;
- Identificao dos Requisitos;
- Identificao dos Riscos e
- Identificao das Restries.
Verso 28
25

- Contexto:
Aps o entendimento do problema podemos escrever a
Declarao do Problema e tambm desenhar um diagrama de
contexto.
- Declarao do problema:
uma descrio narrativa, que apresenta de forma concisa e
clara s necessidades dos usurios.
Esta narrativa tambm deve descrever o cenrio atual e as
necessidades futuras.
A linguagem usada neste documento pode ser tcnica ou de
negcios, entretanto, evite o usar jarges que no se
enquadram no escopo do problema.
- Diagrama de Contexto:
Estabelece quais so as fronteiras do software e principais
funcionalidades, ou seja, onde as responsabilidades do
software comeam e quando acabam.
Verso 28
26

- Identificao dos Stakeholders
Que stakeholders ?
Stakeholders podem ser pessoas ou entidades que influenciam
a construo do software.
Exemplo:
- Usurios, porque definem os requisitos
- Gerentes, Diretores, Patrocinadores porque influenciam
atravs de tomada de deciso.
Verso 28
27
- Identificao dos Requisitos:

Identificar as funcionalidades do software que deve ter para atender as
necessidades do usurio.
Para identificar voc pode fazer as seguintes perguntas:
- O que o software deve fazer ?
- Quais funcionalidades ele deve ter ?
Devemos identificar tambm as principais caractersticas do software
como:
- Performance:
Qual tempo de resposta adequado ?
- Segurana:
Quais so os requisitos de segurana que o software precisa?
- Usabilidade:
O software deve seguir a identidade visual da empresa,as interfaces
devem ser intuitivas e amigveis
Os requisitos encontrados no devem ser descritos neste momento,
precisamos apenas identific-los, ou seja, uma informao de alto
nvel.
Verso 28
28

- Identificao dos Requisitos: Tipos de Requisitos
Os requisitos podem ser divididos em duas categorias:
Requisitos
Requisitos
Funcionais
Requisitos
No-Funcionais
Definem as
funcionalidades do
sistema. O que sistema
deve fazer.
Declaram as
caractersticas que o
sistema deve possuir e
que esto relacionadas
s suas
funcionalidades.
Verso 28
29

Requisitos Funcionais:
Os requisitos funcionais descrevem o que o sistema deve fazer, isto , as funes
necessrias para atender os objetivos do sistema.
Exemplo:
- Cadastrar Clientes;
- Fazer Anlise de Crdito;
- Fazer uma Transao com Banco de Dados;
- Cadastrar um Registro de Atendimento;
- Imprimir Relatrio
- etc.
Verso 28
30

Requisitos No Funcionais:
Os requisitos no funcionais dizem respeito as caractersticas do software, exemplos:

performance, portabilidade, segurana, usabilidade e etc. Estas caractersticas descrevem
tambm a qualidade do servio (QoS).
A no considerao ou esquecimento desses fatores na Workflow de Requisitos constitui
uma das principais razes de uma eventual insatisfao dos usurios com relao a um
software.
Os requisitos no funcionais tambm so chamamos de RNF ou Requisito
Suplementares.
Exemplos de RNF:
- Confidencialidade;
- Confiabilidade;
- Performance;
- Qualidade;
- Usabilidade;
Verso 28
- Portabilidade;
- Preciso;
- Integridade;
- Segurana
- etc.
31

- Identificao dos Requisitos:
Os requisitos de software podem ser identificados no texto da declarao do

problema (geralmente so verbos que identificam algumas aes).
Este documento possibilita a identificao, extrao e

classificao dos requisitos
- Requisitos funcionais e
- Requisitos no funcionais.
Texto da Declarao do Problema
Verso 28
32
Exemplo:
Declarao do Problema
Exemplo: Acompanhamento das estatsticas de aprendizado do aluno e da turma (professor)
Informao: Relatrio de aproveitamento do aluno e da turma (s)
O sistema deve registrar as principais aes de cada usurio.
O sistema deve fornecer um relatrio do aproveitamento do aluno.
O relatrio de aproveitamento do aluno deve conter o tempo de uso do software,
o nmero de exerccios feitos, o nmero de acertos e o de erros.
O sistema deve fornecer um relatrio do aproveitamento da turma.
O relatrio de aproveitamento da turma deve conter a mdia e o desvio-padro
dos seguintes dados: tempo de uso do software, nmero de exerccios feitos,
nmero de acertos e erros de cada exerccio.
Requisitos No-Funcionais:
O sistema deve usar grficos comparativos do aproveitamento do aluno com a mdia
da turma
O sistema deve usar cores na construo dos grficos
O tempo de resposta na elaborao do relatrio no pode ser superior a 15 segundos.
Verso 28
33
- Identificao de Riscos:
Os riscos so a principal razo de falha em um projeto de software.
Para um projeto ter sucesso importante a identificao dos riscos o
mais cedo o possvel. Assim poderemos criar um plano para reduzi-los.
No Documento de Viso precisamos apenas identificar e criar uma
Lista de Riscos encontrados.
Os eventos de riscos podem ter vrias origens como:
- Poltica:
O software pode sofre a influncia de Poltica de Negcios da
Empresa ou Leis, Decretos, Normas e Regulamentos que regulam a
sociedade.
Problemas financeiros
Exemplos de Sistemas que tem restries legais:
- SPB (Sistema Brasileiro de Pagamentos) - Banco Central
- Sistema de Faturamento e Contbil (Secretria da Fazenda
Municipal, Estaduais e Federais)
- Sistema de Folha de Pagamento (Ministrio do Trabalho e
Previdncia Social)
- Sistema de Conta Corrente (Banco Central - CPMF)
Verso 28
34
- Identificao de Riscos:
- Tecnologia:
Uso de tecnologias emergentes; Integrao com legado
- Recursos:
Oramento estreito; Contratao de Terceiros
- Habilidade:
Falta de domnio da tecnologia (conhecimento e experincia)
- Requisitos:
Requisitos no so plenamente conhecidos
Verso 28
35

- Identificao das Restries:
Definem o conjunto de restries impostas sobre o
desenvolvimento do software.
Restries definem, por exemplo, a adequao a custos e
prazos, a plataforma tecnolgica, aspectos legais
(licenciamento), limitaes sobre a interface com usurio,
componentes de hardware e software a serem adquiridos etc.
Nesta momento apenas identificamos as restries e criamos
uma Lista das Restries, esta lista podem ser divida em
partes como:
Restries de Hardware, Restries de Software e Restries
de Ambiente e Tecnologia.
Exemplo de Restrio:
Quando o projeto requer uma determinada tecnologia, tal
como WebServices.
Ou quando o software necessita de algum hardware ou
software em especifico. Tal como um servidor exclusivo para
banco de dados.
Verso 28
36
Documento de Viso:
Objetivo:
Fazer uma descrio da viso do software
Este documento tem as as seguintes sees:
- Declarao do Problema;
- Lista dos Stakeholders
- Lista dos Requisitos
- Lista de Riscos
- Lista das Restries
Verso 28
37

Exemplo de Simples Documento de Viso:
Documento de Viso:
Data: ________ | Autor: ________ | Reviso: ____
ndice:
1.0 - Introduo
1.1 Objetivo do documento
1.2 Escopo
1.3 Abreviaturas, Siglas e etc.
2.0 Contexto
2.1 Declarao do Problema
3.0 Lista de Stakeholders
3.1 Stakeholders primrios
3.2 Stakeholders segundrios
4.0 Lista dos Requisitos
4.1 Requisitos funcionais
4.2 Requisitos no funcionais
5.0 Lista dos Riscos
6.0 Lista das Restries
6.1 Software
6.2 Hardware
6.3 Ambiente e Tecnologia
Verso 28
38
Anlise de Requisitos
apresentar e discutir as atividades da anlise de
requisitos de software
Verso 28
39

de requisitos
Regras de
negcio
Documento de Viso

Usurios e
Clientes
Documentos
Documento de
Requisitos

Documento de
Especificao
de Requisitos
Verso 28
40
Anlise de Requisitos: Introduo

A anlise de requisitos procura sistematizar o processo de definio de requisitos.
Essa sistematizao necessria porque a complexidade dos sistemas exige que se
preste mais ateno ao correto entendimento do problema antes do comprometimento de
uma soluo. Uma definio para requisitos apresentada a seguir.
Requisitos: Condio necessria para a obteno de certo objetivo, ou

para o preenchimento de certo objetivo.
O Documento de Viso um artefato importante na Anlise de Requisitos, destacamos

algumas razes:
- Da perspectiva da engenharia de software, a elicitao de requisitos talvez a mais parte
mais critica do processo de desenvolvimento de software.
Estudos indicam que os requisitos, s detectados depois do software implementado ou
erros na anlise de requisitos, so at 20 vezes mais caros de se corrigir que qualquer
outro tipo de erro.
Verso 28
41
A Anlise de Requisitos deve ser:
Correta: Quando cada requisito expresso nela for encontrado no software;
No Ambgua: Cada requisito deve ter somente uma interpretao;
Completa: Quando incluir todos os requisitos significativos relacionados as
funcionalidades e requisitos relacionados a qualidade do servio (tambm
conhecidos como requisitos no funcionais)
Consistente: Quando no existir conflito entre os requisitos;
Verificvel: Quando for possvel verificar/validar cada requisito;
Modificvel: Quando os requisitos podem ser facilmente alterados.
Verso 28
42
Atividades da Anlise de Requisitos
A anlise de requisitos possibilita que o Analista de Sistemas especifique as
funcionalidades, classificando e detalhando os requisitos encontrados na coleta.
Os requisitos funcionais sero descritos em detalhes. E os requisitos no funcionais sero
classificados.
Detalhar os
Requisitos Funcionais
Classificar os
Requisitos no Funcionais
Descrever os Usurios
e Entidades Externas
Documento de Requisitos
Fazer Plano de Reduo

de Risco
Verso 28
43
Anlise de Requisitos. Detalhar

Os requisitos funcionais devem ser detalhados. Devemos usar um formato padro para
esta atividade. Veja o exemplo:
Lista de Requisitos funcionais
Autor:
Reviso:
Nome
Cdigo
Data Atualizao:
Descrio
Fazer Reserva RF01E Esta funcionalidade dever permitir o usurio (funcionrio)

a fazer reserva de apartamentos, as aes que estaro
disponveis so: criar, remover, alterar e consultar reservas.
Cada reserva dever ter um cliente e um apartamento e
respectiva perodo)
Verso 28
44

Descrio de Regras de Negcio
Nome do Projeto
Objetivo
id
RN01
Servio de Atendimento e Reserva de Apartamento

Descrever todas as regras de negcio para para o servio de atendimento e reserva de apartamentos.
Nome da Regra
Registrar Reserva de
Apartamento
Descrio da Regra de Negcio

A confirmao do registro de reserva de apartamento deve ocorrer aps o pagamento de
25% do valor da estadia.
Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem
preferncia de data e tipo de apartamento.
No perodo de baixa a estao (de mar a jun e ago a nov) o valor da diria tem um
desconto de 40%.
Para que agilizar o atendimento manter a satisfao do cliente as consultas de reserva devem
ser feitas em no mximo 30 segundos.
Data
Os cdigos permitem a rastreabilidade
01/01/08
Nome / Equipe
RFS
Verso
Status
2.1
Vigente
Requisitos Funcional
RN: RN01
Nome: Reserva
Descrio: Servio de Atendimento e Reserva de Apartamento
ID
Nome
Descrio
RFC01
Registrar Reserva
de Apartamento
Esta funcionalidade dever permitir o usurio (funcionrio) a fazer reserva de apartamentos,

as aes que estaro disponveis so: criar, cancelar, alterar e consultar reservas.
Verso 28
45
Anlise de Requisitos. Classificar

Agora vamos descrever os Requisitos No Funcionais. Entretanto, precisamos
categorizar estes requisitos, as mais frequente so:
- Performance:
Tempo de resposta
- Segurana:
Uso de senhas, certificados digitais e etc..
- Usabilidade:
Identidade Visual e Interfaces amigveis
- Disponibilidade:
O software deve estar disponvel para usurio 24x7. Exemplo: Tolerncia a falha
- Flexibilidade:
Capacidade de adaptao quando um requisito muda
- Portabilidade:
Capacidade de se adaptar a outros ambientes (sistemas operacionais)
- Escalabilidade:
Capacidade de responder aumento de carga (novos usurios)
Outras categorias como Integrao, Processamento, Manutenvel e etc.
Verso 28
46
Anlise de Requisitos. Classificar e Detalhar

Bem vamos descrever os requisitos no funcionais. Como na descrio dos Requisitos
funcionais, precisamos ter um padro
Lista de Requisitos No funcionais
Categoria: Performance
Autor:
Reviso:
Req. Funcional
Fazer
Consulta
Data Atualizao:
Cdigo
Descrio
RNFP1
As consultas que sero realizadas pelo cliente no podero

exceder ao tempo de resposta de 15 segundos
Por que preciso de um cdigo ?
Este cdigo tem como objetivo facilitar a rastreabilidade.
Ele pode ser usado no Formulrio de Caso de Uso, por exemplo, desta
forma conseguiremos identificar qual o caso de uso que realiza este
RNF, no caso de mudanas.
Verso 28
47
Anlise de Requisitos. Classificar e Detalhar

Continuao:
Lista de Requisitos No funcionais
Categoria: Usabilidade
Autor:
Reviso:
Data Atualizao:
RF /
Aplicao
Cdigo
Descrio
Aplicao
RNFU1
As cores, as fontes e logotipos devem seguir o Manual de

Identidade Visual da empresa.
Aplicao
RNFU2
As interfaces com usurio devem seguir padro de interfaces

estabelecido pelo Manual de Sistema
Verso 28
48

Lista de Stakeholders:
Precisamos descrever todos as pessoas e/ou organizao que influenciam a tomada de
deciso ou participam direta ou indiretamente do processo de construo do software.
Mais uma vez criaremos um formato padro. Veja o exemplo:
Lista de Stakeholders
Autor:
Reviso:
Data Atualizao:
Nome
Descrio
Cliente
So todas as pessoas fsicas ou jurdicas que fazem reservas
Colaborador
qualquer pessoa que presta algum tipo servio para

empresa
Verso 28
49

Lista de Stakeholders:
Continuao:
Lista dos Stakeholders
Autor:
Reviso:
Data Atualizao:
Nome
Descrio
Administradora de
Carto de Crdito
Entidade que faz validao de um carto de crdito presente

em transao de pagamento.
Verso 28
50
Anlise de Requisitos. Elaborar:

Plano de Mitigao de Riscos:
Precisamos elaborar um Plano de Mitigao de Risco, para os risco que j foram
identificados. Este plano deve detalhar como mitigar os riscos identificados.
Exemplo:
Foi identificado o Risco de Habilidade, pois, somente uma pessoa da equipe conhece a
Web 2.0, as outras pessoas nunca trabalharam com esta tcnologia.
Para mitigar este risco toda equipe dever receber treinamento de Web 2.0, antes do
comeo do projeto.
Verso 28
51
Anlise de Requisitos. Artefato

Documento de Requisitos:
Objetivo:
Classificar, descrever os requisitos de software,
usurios e entidade externas e elaborao do
plano de reduo de risco
Este documento tem as seguintes sees:
- Requisitos Funcionais
- Requisitos No Funcionais
- Descrio do Usurios e Entidades Externas
- Plano de Reduo de Risco
Verso 28
52
Anlise de Requisitos. Artefato.Template

Data: ________ | Autor: ________ | Reviso: ____
ndice:
1.0 - Introduo
1.1 Objetivo do documento
1.2 Escopo
2.0 Descrio dos Requisitos Funcionais
3.0 Descrio dos Requisitos No Funcionais
4.0 Lista dos Stakeholders (clientes e usurios)
4.1 Stakeholders primrios
4.2 Stakeholders segundrioss
5.0 Plano de Mitigao de Riscos
Verso 28
53
Mitos e Lendas:
O que dito:
- Usurios no entendem do negcio...
- Requisitos so estticos...
- Achar que tem a soluo, mesmo antes de conhecer todo o problema...
Entretanto, a realidade outra...

- Requisitos no so estticos, eles mudam constantemente...
- Fazer amplas discusses que envolvam o maior
nmero de pessoas que conheam o negcio, antes de
apresentar uma a soluo
Verso 28
54
Especificao de Requisitos
com Caso de Uso
apresentar as principais tcnicas para especificao
de requisitos de software.
Verso 28
55
Especificao de Requisitos com Caso de Uso

de requisitos
Regras de
negcio
Documento de Viso

Usurios e
Clientes
Documentos
Documento de
Requisitos

Documento de
Especificao
de Requisitos
Verso 28
56
Requisitos
Funcionais
Documento
de Viso
Requisitos No
Funcionais
Restries
de Projeto
Documento de
Requisitos
Arquitetura
do Software
Especificao de Requisitos
Comportamento externo
Casos de Uso
Comportamento interno
Seqncia
Estrutura
Implementao
Verso 28
Colaborao
Classes
Distribuio
57

O produto que devemos ter aps Anlise de Requisitos a A especificao de
Requisitos feita atravs de Casos de Uso, conforme definido pela UML. Um
conjunto de casos de uso importante para se compreender o que o usurio
quer. Um caso de uso descreve uma funcionalidade (requisito) a ser oferecida
pelo sistema, ou seja, um servio.
Anlise de Casos de Uso:

Casos de uso expressam o dilogo entre os usurios e o sistema
Casos de uso expressam o qu o sistema dever fazer. E no como fazer.
Casos de uso formam a base para testes e documentao do sistema
O modelo de casos de uso expressam todos os casos de uso do sistema e os seus
relacionamentos.
As tcnicas para criar e expressar casos de uso em uma aplicao Web so as
mesmas para construir outros sistemas de software.
Objetivos:
Identificar os atores;
Identificar os casos de uso;
Desenhar os casos de uso e
Escrever cenrios.
Verso 28
58
Transformar os Requisitos
Funcionais em Casos de Uso:
Calcular Total
Cliente
Fazer Cadastro
Funcionrio
Fazer Pedido
Emitir NF
59
Verso 28
Atividades e Passos:
Fazer Diagrama de
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever cenrios
Ferramenta de
Modelagem UML
Escrever Formulrio
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
Verso 28
60
Introduo:
Caso de Uso uma representao grfica e semntica da
interao do usurio e o sistema.
Os diagramas de caso de uso so usados para capturar os
requisitos funcionais do sistema. Ajuda o entendimento do
contexto dos requerimentos do sistema.
Os casos de uso podem ser agrupados em pacotes, desta
forma temos uma organizao funcional.
Verso 28
61

O que so Caso de Uso?
So diagramas de que permitem visualizar, especificar e
documentar o comportamento de um elemento. Esses
diagramas fazem com que sistema, subsistemas e classes
fiquem acessveis e compreensveis, por apresentarem
uma viso externa sobre como esses elementos interagem
com sistema.
Definio:
Caso de Uso uma descrio de um conjunto de
seqncias de aes, inclusive variantes, que um sistema
pode produzir um resultado de valor observvel por
um ator. A representao grfica uma elipse.
Caso de Uso
Gerenciar
Reserva
Ator
Os nomes de casos de uso

so breves expresses verbais
ativas.
Usurio
Nome
Verso 28
62
Casos de Uso e Cenrios:

Os casos de uso exibem a funcionalidade na perspectiva do usurio. Entretanto,
podemos ter vrios caminhos para completar esta funo.
Um cenrios como uma instance do Caso de uso, isto , um caminho lgico com
incio e fim.
Principais caractersticas:
- Cenrios no contm declaraes condicionais;
- Pode ter mesmo comeo, mas, com final diferente;
- Um cenrio narrativa de uma situao e
- Os cenrios devem descrever os bons caminhos e maus tambm.
Verso 28
63

Exemplos:
Em dada Loja virtual, podemos o seguinte cenrio de Compra de um produto:
O cliente navega no catlogo de itens e adiciona os itens desejado sua cesta de
compra. Quando o cliente deseja pagar, fornece os dados do carto de crdito e
confirma a compra. O sistema solicita o endereo de entrega para o pedido.
O sistema verifica a autorizao do carto de crdito e confirma a transao
imediatamente enviando um e-mail para o usurio.
Este um dos cenrio que pode acontecer. Se houver algum problema, com a
autorizao da transao do carto de crdito teremos um novo cenrio.
Verso 28
64

Exemplos:
Autorizao de acesso.
O usurio executa a aplicao, o sistema exibe a janela de identificao que pede a
identificao do usurio, ou seja, seu nome e sua senha, O usurio informa seu
nome e sua senha, o sistema valida as informaes e d a autorizao de acesso ao
sistema.
Se senha for invalida ou nome neste caso teremos um novo cenrio.
Verso 28
65
Casos de Uso e Fluxo de Eventos:
Uso caso de uso descreve o qu um sistema (ou subsistema, classe, ou interface) faz,
ele no especifica como isso feito. Ao fazer uma modelagem, importante manter
clara a separao de questes entre a viso interna e externa.
Podemos especificar o comportamento de um caso de uso pela descrio do fluxo de
eventos no texto de maneira suficientemente clara para que qualquer pessoa possa
entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como
e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os
atores e o fluxo bsico e fluxo alternativo do comportamento.
Tipos de fluxos:
Fluxo de eventos principal e
Fluxo alternativo de eventos.
Verso 28
66
Casos de Uso e Fluxo de Eventos:

Tipicamente descrevemos um fluxo de eventos para um caso de uso. Os fluxos de eventos
ajudam a compreenso dos requisitos do sistema, entretanto, voc desejar utilizar
os diagramas de interao para especificar esses fluxos graficamente. Alm disso, voc
tambm utilizar um diagrama de seqncia para especificar o fluxo principal de um
caso de uso e variao deste diagrama para especificar os fluxos excepcionais.
Fluxo Normal
Fluxo
alternativo 2
Fluxo
alternativo 1
Fluxo
alternativo 3
Cenrio 1
Verso 28
67

Casos de Uso e Formulrio:
Os formulrios devem ter as seguinte informaes:
- Ponto de ativao (momento que caso de uso comea)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pr-condio
- Fluxo Normal
- Fluxo Alternativo
- Ps-condio.
Opcionalmente podemos acrescentar outros itens ao Formulrio de Caso Uso.

Exemplos:
- Nome ou cdigo dos Requisitos (RN e RNF) que esto associados a este caso de uso
Verso 28
68
Exemplo Formulrio de Descrio de Caso Uso:

Nome: Fazer Busca Produto
Ponto de ativao: Este caso de uso comea quando entra na pgina
de Busca e seleciona um item da caixa de seleo
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pr-condio: Aplicao Disponvel
Fluxo Normal:
1 - O visitante seleciona a pgina de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o boto buscar
5 - O sistema processa a busca
6 - Retorna as informaes sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a pgina de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o boto buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem produto no encontrado
Ps-condio: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto
Requisito No Funcional: --69
Verso 28

Organizao dos Casos de Uso:
Os casos de uso tambm podem ser organizados pela especificao de relacionamento de
generalizao, incluso e extenso, existentes entre eles. Esses podem ser aplicados com
a finalidade de fatorar o comportamento comum (obtendo esse comportamento a partir de
outros casos de uso que ele inclui) e fatorar variantes (obtendo esse comportamento em
outros casos de uso que o estendem)
Verso 28
70
Exemplos de Casos de Uso:
Manter informaes dos

cursos
Manter informao de
aluno
Manter informao de
professor
Gerente de
Educo
Gerar catalogo
Pedir lista dos

matriculados
Sistema de
cobrana
Matrcula nos
Cursos
Professor
Aluno
Selecionar curso
para ensinar
Verso 28
71

Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papis que os usurios de casos de
uso desempenham quanto interagem com esses casos de uso. Geralmente um
ator representa um papel, que pode ser de pessoa, de um sistema ou de um
dispositivo e etc...
Cenrios:
narrativa de determinado fato ou de uma situao.
O caso de uso deve ser descrito atravs de cenrios. Devem ser construdos tantos
cenrios quantos forem necessrios para se entender completamente todo o
sistema. Podem ser considerados como teste informais para validao dos requisitos do
sistema.
Formulrio:
a representao estruturada de um ou mais cenrios
Verso 28
72

Generalizao:
Entre os casos de uso parecida generalizao existente entre as classes.
No caso de uso a generalizao significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poder acrescentar ou
sobrescrever o comportamento de seu pai; poder ser substitudo em qualquer local
qual o pai aparea.
Include:
Quando voc estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetio
Extends:
Quando estivermos descrevendo uma variao em comportamento normal,
entretanto, querendo fazer uma descrio mais controlada, explicando os pontos de
extenso no caso de uso.
Realizes:
Especifica a colaborao entre os casos de uso
* Use (obsoleto): Especifica que a semntica do elemento de origem depende da
semntica da parte pblica do destino. Substitudo pelo include.
Verso 28
73

Generalizao:
Podemos usar a generalizao entre casos de uso, pelo mesmo motivo que utilizamos
nas classes, para compartilhar comportamento:
Receber Pagamento
generalizao
Pagto Carto de Crdito
Verso 28
Pagto Carto de Dbito
74

Generalizao:
A generalizao tambm pode ser aplicado aos atores e seus respectivos papis. Veja
o exemplo:
Funcionrio
Recepcionista
Verso 28
Gerente de
Reservas
75

Extends:
Podemos usa-lo para Demonstrar Variao de Comportamento:
Cada uma das extenses descreve as diferentes maneiras com que um passo do
caso de uso pode ser executado. Variao de Comportamento. Exemplo:
Locadora de Automveis
Devolver Veculo
Verso 28
<<include>>
<<extend>>
<<include>>
Alterar status do carro
Consulta Cliente
Calcular Multa
76
Explicando o estereotipo include

Um relacionamento de incluso entre casos de uso significa que o caso de uso base incorpora
explicitamente o comportamento de outro caso de uso em uma localizao especificada na base.
O caso de uso includo nunca permanece isolado, mas apenas uma instance como parte de
alguma base maior que o inclui. Voc pode pensar na incluso como o caso de uso base que o
obtm o comportamento a partir do fornecedor do caso de uso. Voc utiliza um relacionamento
de incluso para evitar descrever o mesmo fluxo de eventos vrias vezes, incluindo o
comportamento comum em um caso de uso prprio. O relacionamento de incluso
essencialmente um exemplo de delegao, voc coleta um conjunto de responsabilidades do
sistema e o captura um nico local (o caso de uso includo); depois, permite que outras partes do
sistema (outros casos de uso) incluam a nova agregao de responsabilidade sempre que
precisamos utilizar essa funcionalidade.
Fazer Pedido
<<include>> Validar Usurio
Acompanhar Pedido
<<include>>
Verso 28
77
Include. (Mais) exemplos:
Fazer Check IN
Fazer Check OUT
Gerenciar Reserva
Receber Pagamento
<<include>>
<<include>>
Verso 28
78
Casos de Uso - Identificao de Atores
Os atores no fazem parte do sistema - eles representam qualquer um e qualquer coisa

que faa interao com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode:
- Apenas fornecer informaes ao sistema
- Apenas receber informaes do sistema
- Fornecer e receber informaes ao sistema
Tipicamente os atores so identificados nas Declaraes de Problemas (Documento
de Viso) ou atravs de entrevistas com os usurios e outros envolvidos no processo,
como, Gerente, Especialista em Negcio, Analista de Sistema e Analista de Negcio,
por exemplo.
As seguintes questes podem ser usadas para identificar o atores:
- Onde o sistema ser usado ?
- Quais reas sero usurias do sistema ?
- O sistema usar recurso externo ?
- Quem ser o responsvel pelo sistema ?
- Quem sero os usurios do sistema ?
Verso 28
79
Um engano comum na identificao de casos de uso representar como Caso de uso

passos individuais, operaes ou transaes.
Exemplo:
No domnio de ponto de venda, algum pode definir um caso de uso chamado
Imprimindo o Recibo, quando de fato, a operao de impresso meramente um passo
no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se:
Um caso de uso uma descrio completa de processo, que inclui outros passos
ou transaes.
Verso 28
80
Estudo de Caso:
O hotel contm um nmero de apartamentos disponveis para ser alugado aos hospedes. Cada apartamento tem as
seguintes propriedades:
- Nmero, preos base, capacidade de pessoas
- Tipo (Single, double, triplo ou suite)
O preo de cada apartamento est relacionado com seu tipo e sazonalidades (perodos especiais, tais como: frias, natal,
carnaval...)
Um hospede pode fazer reserva de mais de um apartamentos atravs do telefone, Internet ou pessoalmente no balco de
reserva do Hotel .
Refinado pelo
Requisitos Funcionais
Gerenciar Reserva
...
Documento de
Viso
Documento
de Requisitos
Verso 28
81
Estudo de Caso:
Especificao de Requisitos:
3
Formulrio
Cenrios
Gerenciar Reserva
Usurio
Ator
Caso de Uso
Associao
Caso de Uso: Gerenciar Reserva
Verso 28
82

Estudo de Caso:
Escrevendo os Cenrios:
Gerenciamento de Reserva:
Cenrios
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
O cliente informa o perodo, ou seja, data de chegado e partida, e qual tipo de apartamento
ele precisa.
O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
ele precisa.
O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa
que no tem disponibilidade de apartamento para o perodo informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente aceita o apartamento e ento o funcionrio confirma a reserva.
Verso 28
83

Estudo de Caso:
Escrevendo os Cenrios:
Cenrios
ele precisa.
O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e informa
que no tem disponibilidade de apartamento para o perodo informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente no aceita a proposta do funcionrio e a reserva no confirmada.
Verso 28
84
Estudo de Caso:
Escrevendo o Formulrio:
Compilar os Cenrios em Formulrio:
Cenrios
Formulrio
Identificando a pr-condio e ps-condio:

Cenrio
Pr- condio
ele precisa.
O funcionrio do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Ps- condio
Verso 28
85
Estudo de Caso:
Compilar os Cenrios em Formulrio:
Primeiras linhas do cenrio
Gerenciar Reserva
caminho feliz
Gerenciar Reserva
caminho alternativo
Nome: Gerenciar Reserva

Ponto de ativao: Este caso de uso comea quando o
funcionrio do setor de reserva recebe uma solicitao de
reserva
Ator: Funcionrio
Objetivo: Fazer reservar de apartamentos
Pr-condio: Solicitao de reserva
Fluxo Normal:
Fluxo Alternativo:
Ps-condio: Reserva confirmada
ltima linha do cenrio

86
Verso 28
Estudo de Caso:
Formulrio:
Nome: Gerenciar Reserva
Ponto de ativao: Este caso de uso comea quando o funcionrio do setor de
reserva recebe uma solicitao de reserva
Ator: Funcionrio
Objetivo: Fazer reservar de apartamentos
Pr-condio: Solicitao de reserva
Fluxo Normal:
O cliente informa o tipo de apartamento
O cliente o perodo (data de chegada e partida)
O funcionrio do Hotel verifica a disponibilidade do apartamento
O funcionrio confirma a reserva
Fluxo Alternativo:
...
O funcionrio do Hotel verifica a disponibilidade do apartamento
O funcionrio faz proposta de outro apartamento para cliente
O cliente aceita e ento o funcionrio confirma a reserva
Ps-condio: Reserva confirmada
Verso 28
87
Estudo de Caso:
Especificao de Requisitos:
3
Formulrio
Cenrios
Funcionrio
Ator
Gerenciar Reserva
Caso de Uso
Associao
Caso de Uso: Gerenciar Reserva
Verso 28
88
Ferramenta: Enterprise Architect (EA)
Verso 28
89
Mitos e Lendas
Requisitos no so Casos de Uso;

Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo:
Caso de Uso Fazer Busca, est associado a dois requisitos:
(RF) Fazer Buscar
(RNF) O tempo de resposta para transao deve ser 10 segundos
(Desempenho)
Verso 28
90
Atividades e Passos:
Fazer Diagrama de
Casos de Uso
Casos de Uso
Escrever cenrios
Rational Rose
Escrever Formulrio
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
91
Verso 28

Vamos fazer os Caso de Uso (iniciais)
Especificao de Requisitos, como fazer:

1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO;
2 - Identifique tambm os ATORES e seus respectivos PAPIS;
3 - D um nome para o CASO DE USO, lembre-se que este nome deve ser
nico no modelo;
4 - Escreva os CENRIOS para o CASO DE USO;
5 - Compile os CENRIOS em nico FORMULRIO e
6 - Faa o Diagrama de Caso de Uso (Use Rational Rose para fazer isto).
Verso 28
92

Modelo do Formulrio de Descrio de Requisitos:
Data: ______ | Autor: ________ | Reviso: ____

Nome: <nome do caso de uso>
Ponto de ativao: <informar o ponto de ativao>
Ator: <informar os atores>
Objetivo: <descrever o objetivo>
Pr-condio: <descrever a pr-condio>

Fluxo Normal:
<descrever o fluxo normal>
Fluxo Alternativo:
<descrever o fluxo alternativo>
Ps-condio: <descrever a ps-condio>
RF: <informar os cdigo ou nomes dos RFs>
RNF: <informar os cdigo ou nomes dos RNFs>
Verso 28
93
Refinar: Atividades e Passos
Fazer Diagrama de
Casos de Uso
Casos de Uso
Escrever cenrios
Rational Rose
Escrever Formulrio
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
Neste momento vamos refinar o Diagrama de Caso de Uso:
1 - Identificar os pontos de extenso
2 - Identificar as generalizaes
3 - Identificar os pontos de incluso
Verso 28
94
Exemplo 2 Adicionando o <<include>>
Sem include:
Com include:
<<include>>
Buscar Apartamento
Funcionrio
Gerenciar
Reserva
<<include>>
Funcionrio
Verso 28
Gerenciar
Reserva
Cadastrar Cliente
95
Exemplo 1 Adicionando o <<include>> e <<extend>>
Cancelar
Check IN
<<extend>>
Recepcionista
Fazer Check IN
<<include>>
Recepcionista
Consultar
Reserva
Fazer Check IN
<<include>>
Consultar
Cliente
Verso 28
96
Exemplo 3 Adicionando o <<include>>
Sem include:
Com include:
<<include>>
Consultar
Cliente
<<include>>
Recepcionista
Fazer Check OUT
Consultar
Reserva
<<include>>
Recepcionista
Verso 28
Fazer Check
OUT
Receber
Pagamento
97
Validao de Requisitos
apresentar as principais tcnicas para validao de
requisitos de software.
Verso 28
98

de requisitos
Regras de
negcio
Documento de Viso

Usurios e
Clientes
Documentos
Documento de
Requisitos

Documento de
Especificao
de Requisitos
Verso 28
99
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usurio
deseja.
Validao importante uma vez que o custo para remover um erro de requisitos
grande.
Pequeno Check List de Requisitos:
Validade. O sistema fornece as funes que melhor atende as necessidades do
usurio?
Consistncia. Existem conflitos de requisitos?
Completeza. Todas as funes necessrias para o cliente esto includas?
Realismo. Os requisitos podem ser implementados com a tecnologia e oramento

disponveis?
Facilidade de verificao. Os requisitos podem ser checados?
Verso 28
100
Tcnicas de validao de requisitos

Reviso de requisitos:
- Anlise manual sistemtica dos requisitos
Prototipao:
- Uso de um modelo executvel do sistema para checar os requisitos.
Gerao de casos de teste:
- Desenvolver testes para validar a implementao dos requisitos.
Anlise automatizada da consistncia:
- Uso de ferramenta para verificar a consistncia do modelo.
Reviso de requisitos:
- Revises regulares devem ocorrer durante a formulao da definio dos requisitos
- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revises
- As revises podem ser formais (com documentos completos) ou informais. Uma boa
comunicao entre os desenvolvedores, clientes e usurios pode resolver problemas em
estgios iniciais
Verificao de revises:
- Verificabilidade. O requisito realisticamente testvel?
- Compreensibilidade. O requisito propriamente entendido?
- Rastreabilidade. A origem do requisito claramente estabelecida?
- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros
requisitos?
Verso 28
101
Caso de Teste
Definio: Caso de Teste
- Casos de Testes:
Especifica uma forma de fazer testes, incluindo o que testar (as entradas e/ou as sadas) ,
como testar e as condies de testes.
Em engenharia de software, Caso de Teste um conjunto de condies usadas para
teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna
do software, atravs de situaes que exercitem adequadamente todas as estruturas
utilizadas na codificao; ou ainda, garantir que os requisitos do software que foi
construdo sejam plenamente atendidos. Podemos utilizar os Casos de Uso para criar e
rastrear os Caso de Teste.
O Caso de Teste deve especificar a sada esperada e os resultados esperados do

processamento. Numa situao ideal, no desenvolvimento de casos de teste, se espera
encontrar o subconjunto dos casos de teste possveis com a maior probabilidade de
encontrar a maioria dos erros.
Os Casos de Uso so a base para os Casos de Teste
Verso 28
102
Caso de Teste
Definio: Modelo de Teste - Caso de Teste. Exemplo:
Caso de Teste
ID Caso Teste
ID Caso de Uso
Nome
Descrio
Fazer Login
Validar o Caso de Uso: Fazer Login de Acesso
Cenrio
Resultado Esperado
Resultado Observado
Fluxo Normal
Entrada: nome e senha
Usurio autorizado
(Sucesso)
Usurio autorizado (Sucesso)
OK
Fluxo Alternativo 1
Entrada: nome e senha
Mensagem usurio
invlido (Insucesso)
Usurio autorizado (Sucesso)
NOK
25
24
Nome do Testador:
OK ?
Data:
____/____/_____
Caso de Uso
Fluxo Normal
Fluxo
alternativo 2
Fazer Login
Fluxo
alternativo 1
Fluxo
alternativo 3
Descrio
do Caso de Uso
Cliente
Cenrio 1
Verso 28
103
Tcnicas de validao de requisitos
Verificao de Consistncia Automatizada:
Requisitos em
linguagem formal
Relatrio
Processador de
Requisitos
Anlise de
Requisitos
Base de Dados
de Requisitos
Verso 28
104
Gerenciamento de Mudana
de Requisitos
apresentar as principais tcnicas para processo de
gerenciamento de mudana de requisitos de software.
Verso 28
105
Gerenciamento de Mudana de Requisitos
Gerenciamento de Mudana de Requisitos o processo de controlar as mudanas nos

requisitos durante o processo de engenharia de requisitos e desenvolvimento.
Requisitos so inevitavelmente incompletos e inconsistentes:
Novos requisitos surgem durante o processo de desenvolvimento.
Diferentes pontos de vista possuem diferentes requisitos e esses so freqentemente
contraditrios.
Mudanas nos requisitos:
- A prioridade dos requisitos podem mudar para atender novas demandas de negcio
- Requisitos podem sofrer alterao quando muda a regra de negcio;
- As pessoas que pagam pelo software/sistema podem especificar os requisitos de maneira
conflitantes com os requisitos das pessoas que iro utilizar o software/sistema.
- A empresa e o ambiente tcnico do software/sistema se modificam durante o processo
de desenvolvimento
Verso 28
106
Evoluo dos requisitos
Entendimento
do problema
(alterado)
Entendimento
inicial do problema
Requisitos
iniciais
Requisitos
modificados
tempo
Verso 28
107

Requisitos permanentes e volteis:
- Requisitos permanentes. Requisitos estveis, derivados da atividade principal da
organizao.
Exemplo: Em um hospital sempre haver requisitos relativos aos pacientes, aos
mdicos, s enfermeiras e aos tratamentos.
- Requisitos volteis. Requisitos que se modificam durante o desenvolvimento ou
quando o software/sistema est em uso. Requisitos resultantes de polticas
governamentais ou resultantes de regra de negcio da empresa.
Exemplo: Plano de sade; Mudana na poltica de venda
Classificao dos requisitos:
Requisitos Mutveis:
- Requisitos que se modificam por causa do ambiente do sistema.
Requisitos Emergentes:
- Requisitos que surgem medida que a compreenso do cliente do sistema se desenvolve
Requisitos Conseqentes:
- Requisitos que resultam da introduo do sistema de computador.
Requisitos de compatibilidade:
- Requisitos que dependem de outros sistemas ou processos de negcio especficos dentro
da organizao
Verso 28
108

Planejamento do gerenciamento de requisitos:
Durante o processo de engenharia de requisitos, ser necessrio planejar:

A identificao dos requisitos:
Como os requisitos so individualmente identificados
Um processo de mudana de gerenciamento:
O processo seguinte anlise de uma mudana de requisito
Polticas de rastreabilidade:
A quantidade de informaes (histrico) sobre o relacionamento entre requisitos que
mantida.
Como rastrear as mudanas de requisitos e seus possveis impactos.
Suporte ferramenta:
O suporte ferramenta necessrio para auxiliar no Gerenciamento de Mudanas de
Requisitos
Verso 28
109
Rastreabilidade:
- Rastreabilidade preocupa-se com as relaes entre requisitos, suas fontes e o projeto do

software/sistema
Rastreabilidade de fonte:
Links de requisitos para stakeholders que propuseram os requisitos
Rastreabilidade de requisitos:
Links entre requisitos dependentes
Rastreabilidade do projeto:
Links dos requisitos para o projeto
Verso 28
110
Suporte ferramenta:
Armazenamento dos requisitos:
- Os requisitos devem ser gerenciados em uma memria de dados segura e gerenciada
Mudana de gerenciamento:
- O processo de mudana de gerenciamento um processo de fluxo de trabalho cujos
estgios podem ser definidos e o fluxo de informao entre esses estgios parcialmente
automatizado
Gerenciamento de rastreabilidade
- Recuperao automtica dos links entre requisitos
Verso 28
111
Gerenciamento de Mudanas de Requisitos:

Deve ser feita em qualquer proposta de mudana de requisito.
Principais estgios:
- Anlise do problema e especificao da mudana. Discute-se os problemas com os
requisitos e prope-se mudanas.
- Anlise e custo da mudana. Avalia-se os efeitos da mudana em outros requisitos do
sistema.
- Implementao das mudanas. O documento de requisitos e outros documentos so
alterados de forma a refletir as mudanas.
Solicitao
de Mudana de
Requisito
Anlise do Problema
e especificao da
mudana
Verso 28
Anlise e custo
mudana
implementao
da mudana
Requisito
Alterado
112
Exemplo: Matriz de Rastreabilidade (na ferramenta ReqPro):
Verso 28
113
Exemplo: Matriz de Rastreabilidade (na ferramenta EA):
Verso 28
114
Contedo:
Tcnicas para identificao/elicitao de requisitos:
- JAD
- FAST
Documento de Requisitos
- Padro IEEE/ANSI 830-1993:
Verso 28
115
Anexo
JAD (Join Application Development)
A tcnica JAD desenvolvida na IBM no fim dos anos 70 visa criar sesses de trabalho
estruturadas, atravs de uma dinmica de grupo e recursos visuais, em que analistas e
usurios trabalham juntos para projetar um sistema, desde os requisitos bsicos at o
layout de telas e relatrios, prevalecendo a cooperao e o entendimento
[PORTELLA1994]. Os desenvolvedores ajudam os usurios a formular os problemas e
explorar possveis solues, envolvendo-os e fazendo com que eles se sintam
participantes do desenvolvimento
JAD se baseia em quatro princpios bsicos:
1. Dinmica de grupo, com a utilizao de sesses de grupo facilitadas para aumentar a
capacidade dos indivduos;
2. Uso de tcnicas audiovisuais para aumentar a comunicao e o entendimento;
3. Manuteno do processo organizado e racional; e
4. Utilizao de documentao-padro, que preenchida e assinada por todos os
participantes de uma sesso.
A tcnica JAD tem duas grandes etapas: planejamento, cujo objetivo elicitar e
especificar requisitos; e projeto, em que se lida com o projeto do software. Nesta
monografia somente ser tratada a primeira etapa. Os participantes de uma sesso de
JAD desempenham seis diferentes papis: lder da sesso, representantes do usurio,
especialista, analista, representantes dos sistemas de informao e patrocinador
executivo.
Verso 28
116
Anexo
JAD (Join Application Development)
continuao
A tcnica pode ser usada tanto para elicitar como nas fases iniciais da especificao de
requisitos. Ela ajuda a identificar os assuntos que podem necessitar de rastreamento e
fornece uma perspectiva multifacetada dos requisitos. Sesses de JAD permitem aos
analistas coletar simultnea e eficientemente uma grande quantidade de requisitos do
sistema junto a uma gama de usurios-chave. So teis por considerar necessidades
especficas dos usurios. JAD tambm pode ser usada em conjunto com outra tcnica de
elicitao como, por exemplo, a prototipao. medida que os requisitos so obtidos nas
sesses, pode-se construir um prottipo que demonstre alguma funcionalidade destes
requisitos.
Verso 28
117
Anexo
FAST (facilited application specification technique):

Combina: identificao do problema, negociao e especificao de um conjunto
preliminar de requisitos.
Diretrizes bsicas:
- Encontro de clientes e desenvolvedores em local neutro
- Estabelecer regras para preparao e participao;
- sugerida uma agenda cobrindo todos os pontos importantes e que encoraja o livre
fluxo de idias;
- Facilitador(cliente,desenvolvedor, ou elemento externo) para controlar o encontro.
Verso 28
118
Anexo
Formato do documento de especificao de requisitos sugerido pela IEEE/ANSI 8301993:
Estrutura do Documento:
1.0 Introduo
1.1 propsito do documento de requisitos
1.2 escopo do produto
1.3 definies, acrnimos e abreviaes
1.4 referncias
1.5 viso geral do restante do documento
2.0 Descrio geral
2.1 perspectiva do produto
2.2 funes do produto
2.3 caractersticas do usurio
2.4 restries gerais
2.5 suposies e dependncias
3. Requisitos (Especficos)
os requisitos podem documentar interfaces externas, descrever funcionalidade e
desempenho do sistema, especificar requisitos lgicos de banco de dados,restries de
projeto, caractersticas de qualidade.
4. Apndices
5. ndice
Verso 28
119
Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial so de
responsabilidade de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou
fornecedor apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes
podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo e/ou educativo, no
visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema ou
erro envie um e-mail.
Criticas e Sugestes:
Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor envie
um e-mail.
Rildo F dos Santos (rildosan@uol.com.br)

Verso 28
120
Licena:
Verso 28
121
Rildo F Santos
rildosan@uol.com.br
Anlise de Requisitos de Software

Verso 28

Analise de Requisitos Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analise de Requisitos Software

Enviado por

Direitos autorais:

Formatos disponíveis

Rildo F Santos

Analise de Requisitos de Software

Anlise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

2 - Identificao e Elicitao de Requisitos

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Anlise de Requisitos: Introduo

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Ciclo de Desenvolvimento de Software:

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Definies de requisito (segundo IEEE)

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Contexto de Definio de Requisito:

Stakeholder = Todos os clientes interessados no contexto de requisitos

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Stakeholder = Todos os clientes interessados no contexto de requisitos

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Para a maioria dos sistemas, estes documentos de trabalho incluem:

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Objetivos da Elicitao de Requisitos:

Obter conhecimento relevante para o problema e prover o mais correto entendimento de

Stakeholder = Todos os clientes interessados no contexto de requisitos

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007

Analise de Requisitos de Software

Requisitos. Road Map

Fazer identificao e elicitao

Fazer Anlise de Requisitos

Fazer Especificao de Requisitos

Fazer Validao de Requisitos

Rildo F Santos (rildosan@uol.com.br)

Todos os direitos reservados e protegidos 2006 e 2007