Engenharia de Requisitos

iai Instituto de Artes Interativas

Heyder Martins
heyderlmartins@gmail.com
 Agenda

1. Fatores de Fracasso em Projetos

2. Gerenciamento de Requisitos
3. O Que Requisito?
4. O que faz um Analista de Requisitos?
5. Atividades da Engenharia de Requisitos

Levantamento (Elicitao) de Requisitos

Anlise de Requisitos
Especificao de Requisitos
Validao de Requisitos
Gerenciamento de Requisitos
 Agenda

6. Tipos de Requisitos
7. Requisitos Funcionais
8. Requisitos No Funcionais
9. Analisando o Problema
10. Identificando as Partes Interessadas
11. Atores
12. Glossrio
13. Elicitao de Requisitos
Entrevistas
Questionrios
Workshop de Requisitos
Brainstorming
Prototipao
Anlise Documental
 Agenda

14. Documento de Viso

15. Regras de Negcios
16. Casos de Uso
17. Modelagem de Casos de Uso
 10 Maiores Fatores de Fracasso em Projetos

1. Falta de inputs do usurio.

2. Requisitos e especificaes inconsistentes e/ou incompletas.
3. Mudanas nos requisitos e especificaes.
4. Falta de apoio da alta gerncia.
5. Incompetncia tecnolgica.
6. Falta de recursos.
7. Expectativas no realistas.
8. Objetivos no claros.
9. Projeo de tempo no realista.
10. Novas tecnologias.

Fonte: Standish Group

Os Altos Custos de Erros nos Requisitos

A Regras 1-10-100
Estgio
.5 - 1 Requisitos
2.5 Design
5 Codificao
10 Teste de Unidade
25
Teste de Aceitao
100
Manuteno
 Impacto dos Erros nos Requisitos

Os erros de requisitos descobertos tardiamente

representam retrabalho.

Quanto mais tarde descoberto o erro de requisitos, maior o

custo do retrabalho.
 Impacto dos Erros nos Requisitos

Retrabalho para:

Atualizar cronogramas
Corrigir especificaes
Corrigir modelos de projeto (design)
Corrigir cdigo fonte
Corrigir roteiros de testes
Testar novamente
Homologar novamente
Atualizar manuais
Outros ...
 Gerenciamento de Requisitos

Gerenciamento de Requisitos uma abordagem sistemtica

para:

Elicitar, organizar e documentar os requisitos

Estabelecer e manter o acordo entre o cliente e o time de

projeto sobre o escopo do projeto e suas mudanas
 Gerenciamento de Requisitos

Gerenciamento de Requisitos No Fcil, Porque...

Os Requisitos:

No so sempre bvios
Podem vir de vrias fontes
Nem sempre so fceis de serem expressos em palavras
MUDAM !!!

Em grande nmero, se no forem bem gerenciados, tendero

a sair do controle.
 Gerenciamento Eficaz de Requisitos

Manter uma declarao clara dos requisitos com:

Requisitos de boa qualidade.

Identificar e manter os atributos dos requisitos.
Manter a rastreabilidade para outros requisitos e outros
artefatos de projeto.
 Fatores que Contribuem para o Sucesso do Projeto

Envolvimento do Usurio
Suporte da Gerncia Executiva
Declarao Clara do Objetivos de Negcio
 Como Aumentar as Chances de Sucesso?

Analisando Criteriosamente o Problema a Ser Resolvido.

Entenda o problema e obtenha o acordo do cliente sobre o problema
a ser resolvido.

Levantando os Requisitos
Identifique quem ir utilizar o sistema (Atores)
Levante como o sistema ser utilizado (Casos de Usos)

Gerenciando os Requisitos
Especifique completamente os requisitos
Gerencie expectativas, mudanas e erros em requisitos
Controle o andamento dos problemas de escopo
Envolva toda a equipe nos requisitos
 O Que Requisito?

REQUISITO uma CONDIO ou CAPACIDADE que o

sistema deve atender.

Requisito uma condio ou capacidade que deve ser

alcanada ou possuda por uma soluo, ou componente de
uma soluo, para satisfazer um contrato, padro,
especificao ou outros documentos formalmente impostos.
 O Que Requisito?

Portanto, de forma prtica, os requisitos representam as

funcionalidades e caractersticas as quais o software em
anlise deve atender.

Requisitos especificam O QUE o sistema deve FAZER e no

COMO o sistema FAZ.
 O que faz um Analista de Requisitos?

O Analista de Requisitos:

Entende o usurio

Trabalha no domnio da soluo de um problema

Analisa e entende o problema a ser resolvido

Entende a estrutura e a dinmica do negcio do cliente
 O que faz um Analista de Requisitos?

O Analista de Requisitos:

Trabalhar definindo O QUE precisa ser feito

Deve garantir que clientes e desenvolvedores compartilhem a

mesma viso sobre a soluo a ser construda
Identifica quem ir utilizar o sistema (atores)
Levanta como o sistema ser utilizado (casos de uso)
Gerencia os requisitos ao longo do ciclo de vida do projeto
 O que faz um Analista de Requisitos?

O objetivo maior da Anlise de Requisitos :

Entregar software de qualidade no prazo, no oramento e

que atendam s reais necessidades dos clientes.
 Atividades da Engenharia de Requisitos

1. Levantamento de Requisitos
2. Anlise de Requisitos
3. Especificao de Requisitos
4. Validao dos Requisitos
5. Gerenciamento dos Requisitos
 Levantamento (Elicitao) de Requisitos

o conjunto de atividades que permitem ao analista

trabalhar junto com as partes interessadas para:

Compreender suas necessidades e problemas.

Compreender o ambiente no qual a soluo ser inserida.
Levantar quais so as caractersticas que a soluo em
construo deve possuir.
 Anlise de Requisitos

o conjunto de atividades que permitem ao analista

trabalhar junto com as partes interessadas e o time de projeto
para:

Priorizar os requisitos que retornem maior valor ao

negcio.
Classificar e organizar os requisitos.
Verificar as relaes entre requisitos (p.e. dependncia e/ou
conflitos entre requisitos).
Negociar uma viso nica em relao aos requisitos.
 Especificao de Requisitos

o conjunto de atividades que permitem ao analista:

Estruturar os requisitos utilizando descries textuais,

modelos e/ou diagramas.
Permitir que as partes interessadas e o time de projeto
possam ter uma base para o acordo da soluo que ser
construda.
Produzir uma viso organizada e estruturada dos requisitos
para permitir o desenvolvimento pelo time de projeto.
 Validao de Requisitos

o conjunto de atividades que permitem ao analista:

Formalizar o acordo entre as partes interessadas de que o

requisito ou um conjunto de requisitos representa
exatamente uma soluo que vai atender s necessidades
das partes interessadas.
 Gerenciamento de Requisitos

o conjunto de atividades que permitem ao analista:

Controlar e rastrear os requisitos e suas modificaes em

todos os momentos durante o projeto.
Entender os efeitos provocados pelas mudanas nos
requisitos.
 Tipos de Requisitos

Classificao do BABoK:

Requisitos de Negcio
Requisitos das Partes Interessadas
Requisitos da Soluo
Requisitos Funcionais
Requisitos No Funcionais

Requisitos de Transio
 Tipos de Requisitos

Podemos verificar que existem vrios tipos de requisitos.

Por exemplo:

Os requisitos de Negcios esto intimamente com os objetivos de

negcio que necessitam ser atingidos com o projeto. Os requisitos de
negcios descrevem as razes que levaram ao incio do projeto.

Os requisitos das partes interessadas expressam as necessidades dos

usurios em termos das caractersticas que a soluo deve atender.

J os Requisitos de Soluo fornecem os requisitos detalhados para o

software que ser construdo.
Requisitos de Negcios x Requisitos Funcionais

RN 01 Indicadores de A soluo deve permitir o clculo e

Consumo por Cliente extrao de indicadores de consumo por
cliente.

RF 01 Cadastro de O sistema deve permitir a incluso, consulta,

Clientes atualizao e excluso dos dados cadastrais de
clientes.
RF 02 Registro de O sistema deve registrar de forma cronolgica
Compras Realizadas cada compra realizada pelos clientes.
RF 03 Emitir relatrio de O sistema deve permitir a emisso de
Consumo por Cliente relatrios de consumo por cliente filtrando a
consulta por intervalo de datas.
 Tipos de Requisitos

Neste curso iremos nos concentrar nos requisitos de

solues de software, que so divididos em:

Requisitos Funcionais

Requisitos No Funcionais
 Requisitos Funcionais

Requisitos Funcionais descrevem o comportamento e a

informao que a soluo ir gerenciar, as aes ou
respostas especficas.

Os Requisitos Funcionais so escritos no formato

declarativo ou na forma de casos de usos.
 Escrevendo Requisitos Declarativos

Representam os requisitos funcionais que no sero

expressos no formato de casos de usos. Estes requisitos
devem ser escritos:

Se aplicveis todo o software Em um documento de

especificaes suplementar.

Se aplicveis um caso de uso em especfico na seo

Requisitos Especiais do caso de uso.
 Requisitos No Funcionais

Capturam condies no ligadas diretamente ao

comportamento da soluo, mas a condies
ambientais sob as quais a soluo deve permanecer
efetivo e as qualidades que o sistema precisa possuir.

Estes requisitos devem ser escritos:

Em um documento de especificaes suplementar.

 Requisitos No Funcionais

Os usurios naturalmente focam seus esforos em

especificar requisitos que representam funcionalidades ou
comportamentos de sistemas. Mas necessrio mais do que
isso para o sucesso do software. Usurios tem expectativas
sobre quo bem o software vai trabalhar.

Da perspectiva tcnica, os No funcionais guiam

significantemente o projeto e arquitetura do sistema, p.e.
particionar o sistema a ser construdo em vrios servidores
para atingir desempenho superior ou integridade
necessrios.
 Requisitos No Funcionais

Em um mundo perfeito todo sistema deveria entregar o

mximo valor aos seus usurios, porm, no mundo real,
devem ser cuidadosamente considerados pois podem
encarecer bastante o projeto. Por isso voc tem que ajudar
seus usurios a se decidirem sobre os no funcionais que
devem ser includos.

Como os usurios geralmente no apresentam

prontamente estes requisitos, o analista deve ativamente
levantar estes requisitos.
 Disponibilidade

Disponibilidade uma medida do up time

planejado para o sistema.

So mais crticas para aplicaes web e de utilizao

global.

Exemplo: o sistema deve estar 99,5%

disponvel aos finais de semana e ao menos
99,95% durante a semana.
 Eficincia

Eficincia uma medida de quo bem o sistema utiliza os

recursos de processamento: processador, espao em disco,
memria, banda de comunicao. Se o sistema consumir
muitos recursos, fatalmente os usurios vo passar por
degradao de desempenho.

Exemplo: ao menos 25% da capacidade do processador

e RAM disponvel para a aplicao devem estar ociosos
nas condies planejadas de picos de utilizao.

Especifique previses de crescimento e estouros de demanda.

 Integridade

Integridade (que engloba segurana) restringe o

acesso no autorizado a funes do sistema, prevenindo perda
de informao, proteo contra virus, proteo privacidade e
segurana dos dados registrados no sistema. um problema
importante em sistemas web.

Especifique: verificao da identidade no usurio, nveis de

privilgios, restries de acesso, indique todo contedo que
deve ser protejido.

Exemplo: somente usurios que tenham privilgio de

acesso auditor devem ser capazes de visualizar
informaes das transaes
 Interoperabilidade

Interoperabilidade indica quo fcil o sistema pode

trocar informaes ou servios com outros sistemas.
Pode ser especificada um requisito de interface externa e
definir os tipos de arquivos padres para importao e
exportao por exemplo.

Exemplo: O sistema deve possuir uma API de

servios REST para implementar as funes que
devem estar disponveis para utilizao por
outros sistemas.
 Confiabilidade

Confiabilidade especifica a capacidade do software de

manter sua performance ao longo do tempo. As principais
medidas so:

Tempo de ocorrncia entre Falhas (MTBF)

Tempo de recuperao aps falhas (MTTR)

Exemplo: O sistema deve possuir um tempo mdio

entre falhas e 45 dias. O tempo de recuperao deve ser
de at 2 horas realizado por uma equipe de suporte.
 Robustez

Robustez ou tolerncia a falhas, o grau com o

sistema continua operando propriamente quando
confrontado com entradas invlidas, defeitos em
componentes de software ou hardware, e condies
no esperadas de operao.

Exemplo se o sistema falhar no meio de uma

operao X, ele salva o estado e continua o
processamento posteriormente.
 Usabilidade

Usabilidade a medida do esforo requerido para que

um usurio consiga operar o sistema com sucesso.

Fatores Humanos
Esttica
Documentao
Responsividade
Exemplo: Um usurio que nunca utilizou o sistema deve
ser capaz de realizar as operaes bsicas do sistema
dentro de 30 minutos de operao.
 Desempenho

Desempenho definem quo bem e quo rpido deve executar

determinadas operaes. Engloba velocidade (p.e. tempo de resposta
do banco de dados) , throughput (transaes por segundo), capacidade
(carga de utilizao concorrente) e timing (para sistemas em tempo
real).

Exemplos:

O ciclo de controle de temperatura deve executar

completamente dentro de 80 milisegundos.

Todas as pginas web devem carregar em 15 segundos ou

menos com uma conexo de 256Kbps.

O processador da fila de X deve processar ao menos 5000

registros por minuto.
 Analisando o Problema

Iniciar o levantamento de informaes para subsidiar a

elaborao de um documento de Viso.

Obter o acordo das principais caractersticas e metas do

sistema.

Os requisitos das partes interessadas so os principais

subsdios para a anlise do problema.
 Porque Analisar o Problema?

Para evitar o Sim, o sistema atende os requisitos, mas no

resolve o meu problema

Para evitar retrabalho

Para criar o contexto para o entendimento dos requisitos

que sero detalhados
 Obtenha Acordo sobre o Problema

Qual o problema?

Entenda a perspectiva do usurio

Documente o problema

Obtenha o acordo sobre ele

 Obtenha Acordo sobre o Problema

Qual realmente o problema?

Pesquise e busque a causa raiz do problema (qual o problema

por trs do problema? No aceite a primeira declarao do
problema)

Foque em eliminar a causa raiz

Utilize Pareto (80/20) para focar na eliminao das causas

razes que vo resolver a maior parte dos problemas.
 Declarao do Problema

uma declarao sucinta a respeito da necessidade do

negcio e tambm sobre o que constituiria uma soluo
bem sucedida para o problema.

Tambm identifica os principais interessados e descreve o

impacto positivo que recebero do projeto.
 Declarao do Problema

O problema de (descrio do problema)

Afeta (as partes interessadas afetadas pelo problema)

Cujo
(impacto sofrido pelas partes interessadas)
Impacto

Uma soluo bem

(listar os principais benefcios de uma soluo
sucedida seria Bem sucedida)
 Identificando as Partes Interessadas

Parte integrante da anlise do problema identificar e

conhecer quem possui o problema e/ou est sofrendo com
ele.

Uma parte interessada (stakeholder) qualquer pessoa que

afetada pelo resultado de um sistema.

Saiba diferenciar os reais interessados em resolver algum

problema dos que esto pagando a conta.
 Identificando as Partes Interessadas

Certifique-se de considerar todos os afetados analisando:

Qual ou quais so as reas solicitantes do sistema?

Quem ganha trabalho com a implantao do sistema?

Quem recebe os benefcios produtivos e/ou financeiros

com a implantao do sistema?
Quem ir manter o sistema?

Quais so as pessoas iro interagir com o sistema?

 Atores

Atores so usurios do sistema, logo, no fazem parte do

sistema.

Atores podem ser uma pessoa ou um sistema externo.

 Atores

Como o ator externo, ele ajuda a delimitar as fronteiras do

sistema.

Portanto, funcionalidades que so representadas por atores

no precisam ser construdas.
 Atores

Considere como atores humanos:

Conjunto de usurios do sistema

Futuros administradores do sistema

 Atores

Considere como atores no humanos:

Outros sistemas

Dispositivo de comunicaes

Sistemas de relatrios
 Glossrio

uma artefato de grande importncia para o incio e

desenvolvimento de qualquer projeto e para todas as partes
interessadas.

Ajuda no entendimento e utilizao de termos especiais e

especficos do projeto e/ou do domnio de negcio.

Objetivos:

Definir os termos usados no projeto

Ajudar a prevenir maus entendidos

 Glossrio - Guidelines

Inicie o glossrio to logo surja algum termo especfico

relativo ao negcio e/ou projeto.

Continue atualizando o documento durante toda a vida do

projeto.

Utilize em outros artefatos (casos de usos, especificaes de

requisitos, etc.) os termos conforme mencionados no
glossrio.
 Elicitao de Requisitos

O objetivo da elicitao coletar as informaes das partes

interessadas do projeto.

Objetivos da lio:

Identificar as fontes dos requisitos

Listar os problemas na elicitao das necessidades e requisitos

Identificar as tcnicas para elicitao de necessidades e requisitos

 Problemas que Podem ser Encontrados

As partes interessadas:

No sabem o que realmente querem

So incapazes de articular o que querem

Pensam que eles sabem o que querem, mas no consegue

reconhecer aps a entrega
 Problemas que Podem ser Encontrados

Analistas:

Pensam que entendem os problemas dos usurios melhor do

que eles

Nem sempre as partes interessadas agiro para o sucesso do

projeto
 Problemas que Podem ser Encontrados

O Negcio:

Pode ser muito dinmico ocasionando vrias mudanas e

conflitos nos requisitos
 Fontes dos Requisitos

No deixe de incluir na elicitao:

Usurios finais

Especialistas no domnio do negcio

Documentao e especificaes existentes

Modelos de negcios e processos

Regras de negcios
 Fontes dos Requisitos

No deixe de incluir na elicitao:

Statement of Work (SoW)

Request for Proposal (RFP)

Leis e regulamentos

Sistemas legado

Outros ...
 Processos de Elicitao

No processo de elicitao ocorre uma discusso contnua

dos requisitos entre o time de desenvolvimento e o cliente
at que um acordo seja obtido.

Esteja preparado para retrabalhar os requisitos at que

estejam em nvel tal que seja obtido o acordo com o cliente
em relao aos requisitos.
 Tcnicas de Elicitao

As tcnicas de elicitao so teis para a coleta de

informaes sobre as necessidades das partes interessadas.

So tambm usadas para levantar as informaes sobre os

requisitos funcionais e no funcionais, bem como os
requisitos detalhados da soluo.

O objetivo utilizar mais de uma tcnica para que ambas se

confirmem e se complementem.
 Entrevistas

uma tcnica simples e direta de levantamento de

requisitos.

So utilizadas para obter entendimento sobre problemas e

potenciais solues pela perspectiva do usurio.

til para levantar informaes com partes interessadas

chave do projeto.

Pressupe que ser realizada com uma ou poucas pessoas.

 Questes de Livre Contexto

So questes de alto nvel de abstrao que encorajam o

entrevistado a falar livremente, sem sofrer influncias do
entrevistador.

Exploram os requisitos pela perspectiva das partes

interessadas.

So boas para ganhar o entendimento inicial e geral do

problema a ser resolvido.
 Questes de Contexto Fechado

So questes nas quais as possveis respostas so

fornecidas para o entrevistado, que deve selecionar uma
delas.
 Entrevista Estruturada

O entrevistador prepara, previamente, um conjunto pr-

definido de questes e procura respostas para elas.

O conjunto selecionado de perguntas guiam a entrevista a

ser realizada.
 Entrevista No Estruturada

O entrevistador no possui um roteiro definido ou uma lista

de perguntas iniciais.

O entrevistador e o entrevistado discutem abertamente

tpicos de interesse.
 Vantagens

uma tcnica simples e direta.

Permite aos entrevistados maior liberdade para expressar

opinies.

Pode ser utilizada em quase todas as situaes e tipos de

projetos.
 Desvantagens

No se aplicam quando se tenta obter o consenso de um

grupo.

O entrevistador pode acabar influenciando o entrevistado.

 Categorias de Questes

Do usurio
Descubra quais so os usurios

Quais so as responsabilidades deste usurios

Do processo
Qual o problema?

Como o problema resolvido atualmente?

O que seria uma boa soluo para o problema?

Do produto
Em qual ambiente o produto ser inserido?

Quais so as expectativas para usabilidade? Confiabilidade? Etc.

 Dicas

No assuma que usurios podem descrever atividades

complexas. As pessoas geralmente podem fazer coisas que
depois no conseguem descrever.

Cuidado para no questionar assertivamente demais para

no deix-los na defensiva.

Escute bem mais do que fala.

 Questionrios

A elaborao de questionrios pode ser muito til para a

coleta de informaes.

Deve ser precedida de entrevistas que ajudaro a

determinar as questes corretas a serem feitas.
 Questionrios

Pode ser til para coletas informaes quando:

As pessoas esto distribudos geograficamente

As pessoas so muitas para serem entrevistados ou

participarem de um workshop

Quando voc precisa que seja realizada uma anlise estatstica

dos dados coletados
 Tipos de Perguntas

Geralmente os questionrios so compostos por perguntas

de contexto fechado para facilitar a anlise estatstica.

Inclua algumas perguntas de contexto aberto para levantar

novas idias.
 Workshop de Requisitos

uma das tcnicas mais eficientes em termos de custo e

rapidez para a elicitao de requisitos.

Coloca todos os interessados no mesmo local, guiados por

um facilitador e com um foco bem definido e por um tempo
curto, porm, de trabalho intenso.
 Vantagens

Acelera o levantamento de requisitos pois os conflitos entre

os requisitos so descobertos e trabalhados durante a
mesma seo e por todos em conjunto.

Os resultados do workshop ficam disponveis todos

imediatamente.

O custo e o prazo tendem a serem menores.

 Desvantagens

Pode ser difcil conseguir a agenda de todos os

participantes.

O sucesso depende muito da experincia do facilitador.

 Preparao

Definir objetivos, participantes e obter agenda dos

participantes.

Determinar como os resultados sero documentados.

Organizar os recursos necessrios (sala, projetor, quadro

branco, etc.).

Enviar material com antecedncia para os participantes.

 Execuo

Apresentar as metas e a agenda do workshop.

Informar aos participantes as regras que sero adotadas.

Facilitar o workshop e manter as discusses focadas nos

objetivos.

Garantir que todos sejam ouvidos.

Obter o consenso no caso de conflitos.

 Registrar Resultados

Documentar os resultados.

Sintetizar e consolidar as concluses.

 Acompanhamento

Acompanhar quaisquer itens em aberto/pendncias a

serem resolvidas.

Completar a documentao e apresentar aos participantes e

patrocinador.

Determinar os prximos passos.

 Brainstorming

uma tcnica para a rpida gerao de idias que pode ser

utilizada para:

Levantar idias para novos requisitos (caractersticas) a incluir

no sistema

Organizar e entender melhor idias

Condensar idias diferentes em uma nica

 Brainstorming

A nfase da tcnica a rpida gerao do maior nmero de

idias possvel em um curto perodo de tempo.

Encoraje as pessoas a contribuir com idias. Nesta fase

crticas ou debates no so permitidos.

Logo aps, encoraje as pessoas a discutirem, combinarem e

apresentarem variaes sobre as idias.
 Prototipao

Tem o objetivo de capturar os requisitos de interface do

usurio e prover contexto para os requisitos no visveis e/ou
para os requisitos que descrevem a interao do ator com a
interface com o usurio.

Usado para:

Ganhar feedback da soluo proposta

Reduzir os riscos de gaps de entendimento dos requisitos

Prover visualizao antecipada da navegabilidade e interface com o

usurio
 Prototipao

Tipos: Descartveis e Evolutivos

Os descartveis tm como nico objetivo a elicitao e

validao de requisitos.

Os evolutivos so gradativamente adaptados e utilizados na

gerao do produto de software final (software funcional).
 Vantagens

Uma imagem vale mais do que 1000 palavras

Ajuda no entendimento dos requisitos textuais

essencial para minimizar riscos de entendimentos de

requisitos

Permite validar antecipadamente aspectos visuais e de

interao entre o usurio e o sistema
 Cuidados

No tomar um tempo excessivo nesta atividade

Os desenvolvedores podem ficar totalmente presos ao

prottipo gerado

O usurio tende a criar expectativas em relao a entrega

do produto final (principalmente se o prottipo for do tipo
evolutivo)
 Anlise Documental

o levantamento de informaes importantes atravs da

anlise de documentao sobre processos, domnio do
conhecimento, manuais, outras aplicaes e requisitos
recebidos do cliente.

Algumas vezes os times de projeto recebem os requisitos

em um documento produzido pelo cliente. Neste caso deve-
se revisar todos os requisitos recebidos e acrescentar os
detalhes necessrios.
 Vantagens

Permite no comear a elicitao do zero

um bom meio para confirmar requisitos levantados

atravs de outras tcnicas de elicitao.
 Desvantagens

Est limitada perspectiva atual, no contribuindo para o

estado futuro (sistema a ser construdo).

A documentao pode estar desatualizada ou ser muito

extensa.
 Documento de Viso

Os objetivos principais do documento de Viso so:

Descrever a aplicao em termos gerais, incluindo descries

de mercado alvo, usurios do sistema e caractersticas da
aplicao.

Definir em alto nvel, tanto o problema a ser resolvido quanto

as caractersticas da soluo apresentada para solucionar o
problema.
 Documento de Viso

O documento de Viso importante pois:

Coloca todos os envolvidos na mesma pgina

Serve como base para o acordo dos principais grupos

interessados no projeto: time de gesto, time de marketing e
time de desenvolvimento
 Documento de Viso

Estrutura Bsica:

Introduo e objetivo do documento

Principais partes interessadas
Descrio do problema
Declarao do problema
Descrio da soluo proposta em termos de requisitos
funcionais e no funcionais
Estimativas iniciais
Premissas e restries
 Caractersticas (Features) do Produto

Uma feature uma capacidade do sistema que atende

diretamente uma necessidade de uma parte interessada.

As caractersticas mostram exatamente o que o sistema vai

fazer.
 Caractersticas (Features) do Produto

As caractersticas so listadas no documento de Viso.

Elas devem ser escritas de forma que todos entendam, time

e partes interessadas.
 Caractersticas (Features) do Produto

A lista de features prov a base para a definio do produto

e o gerenciamento do escopo do projeto.

Ao longo do projeto, maiores detalhes sero acrescentados

s features atravs do modelo de casos de usos.
 Regras de Negcios

Todas as organizaes operam segundo um conjunto de

polticas, leis e padres da indstria, p.e., Bancos, Aviao,
Sade, Petrleo, etc.

As regras de negcios refletem justamente este conjunto de

polticas, leis e padres que devem ser respeitados com a
utilizao de um sistema computacional ou no.

Logo a principal caracterstica da regra de negcio que ela

possui vida alm do sistema e deve ser seguida mesmo
que haja uma interrupo em sistemas.
 Regras de Negcios

Exemplos:

O imposto sobre vendas no calculado sobre o valor do frete.

O valor do seguro deve ser calculado razo de 1% sobre o preo

total dos itens do pedido.

Se o pedido contiver entre 1 e 20 peas, aplicar desconto de 15%,

caso o pedido contenha acima de 20 peas, aplicar desconto de
25%.
 Benefcios de Utilizar Casos de Usos

Vantagens da modelagem de casos de usos:

Deixam evidente o porque o sistema necessrio

Casos de usos mostram os objetivos que os usurios querem

atingir com o sistema

Os requisitos so colocados em contexto de forma os requisitos

relacionados so expressos em uma srie de passos que o ator
pode realizar para atingir uma meta no sistema.
 Benefcios de Utilizar Casos de Usos

Os casos de usos deixam evidente porque o sistema

necessrio

Casos de usos representam qual uso os usurios fazem

do sistema

Atores representam quem ou o que utiliza o sistema

Casos de usos fornecem contexto para os requisitos

Se bem escritos, so fceis de entender
Facilitam o acordo entre time de projeto e o cliente
 Benefcios de Utilizar Casos de Usos

Vantagens da modelagem de casos de usos:

O modelo captura o que os usurios pensam a respeito do sistema e o

que o sistema deveria fazer

Casos de usos deveriam ser totalmente entendveis para o usurio

padro sem a necessidade de tradues, que geralmente so
necessrias em outras formas de especificao.

a melhor forma de capturar requisitos dos usurios e coloca-los em

contexto, um requisito sem contexto no de muita utilidade.
 Composio do Modelo

Diagrama de Casos de Usos

Fornece visualizao grfica do sistema

Especificaes de Casos de Usos

So descries textuais dos atores e dos casos de usos

So as partes mais importantes do modelo em relao a

descrio dos passos de execuo do sistema
 Casos de Uso

Os casos de usos so um meio de organizar os requisitos a

partir da perspectiva do usurio e no seu prprio
vocabulrio.

Todos os requisitos que contribuem para que um usurio

complete uma determinada tarefa so reunidos em um
nico caso de uso.

O modelo de casos de usos uma coleo de todos os casos

de usos.
 Quem l os Casos de Uso

O time do cliente, que composto por clientes e usurios

O time de desenvolvimento
 Modelo de Casos de Uso

Como saber se voc est construindo o sistema correto?

Apresente o modelo de casos de usos para o cliente e questione

se modelo apresentado o que eles querem do sistema.

O modelo tambm fornece um conjunto consistente de

requisitos que guiam de forma nica todo o time de
desenvolvimento.
 Atores

O ator algum ou algo fora do sistema que interage com

ele.
 Caso de Uso

Um caso de uso define um conjunto de cenrios de uso,

onde cada cenrio uma sequncia de aes do sistema que
retorna um valor observvel para um ator.
 Associao

Representa uma interao entre um ator e um caso de uso.

Representada por uma linha slida contendo uma seta e

uma ou em ambas as extremidades.

A direo da flecha representa quem inicia a comunicao.

Cada associao um dilogo nos dois sentidos ator caso

de uso e caso de uso ator.
 Modelagem de Casos de Usos

Elaborar o modelo de casos de usos significa colocar juntos

todos os pedaos que voc identificou at determinado
momento.

Assim como um quebra-cabea, cada pea vai contribuir

para que o todo faa sentido, formando a soluo que ser
entregue.
 Modelagem de Casos de Usos

Identifique atores pergunte-se: quem est interagindo

com o sistema em determinado momento?

Atores so Funes, papis e no pessoas em particular.

Uma mesma pessoa usurio pode atuar como vrios

atores diferentes.

Tente ao mximo evitar intitular um ator de Usurio.

 Como Identificar Atores?

Quem usa o sistema?

Quem fornece ou obtm informaes do sistema?

Em quais departamentos da empresa o sistema usado?

Quem administra e mantm o sistema?

Quais outros sistemas se comunicam ou trocam

informaes com o sistema?
 Casos de Usos

Identifique e detalhe os casos de usos

Casos de usos definem uma sequncia de aes executadas

por um sistema que retorna um resultado de valor para o
ator.

medida que eles so identificados, os casos de usos e

atores devem ser adicionados ao diagrama de casos de usos.
O prximo passo rascunhar a os fluxos de eventos dos
casos de usos identificados.
 Casos de Usos

Um caso de uso descreve um fluxo completo de aes que um

sistema executa e que finaliza com um resultado de valor
obtido pelo ator.

Se o caso de uso no retorna valor para o ator, provavelmente

ele muito pequeno. Ele provavelmente faz parte de um outro
caso de uso.

O valor retornado pelo caso de uso para um usurio

especfico, se ele retorna valor para mais de um ator,
provavelmente o caso de uso grande demais. Ele
provavelmente deve ser quebrado em casos de usos menores.
 Identificando Casos de Usos

Para que o ator vai usar o sistema?

Quem vai criar, armazenar, alterar, remover ou consultar

dados do sistema?

Prever casos de usos para:

Manuteno do sistema

Tarefas agendadas
 Casos de Usos

Evite casos de usos muito pequenos (Menos de 03 pginas)

Evite casos de usos muito longos (mais de 10 pginas)

Quando voc tiver a primeira lista de casos de usos,

verifique se todas as funcionalidades requisitadas pelos
usurios foram contempladas.
 Especificando Casos de Usos

D um nome significativo ao caso de uso (nome comeando

com verbo no infinitivo).

O nome deve indicar o valor ou o objetivo que ser atingido

aps a execuo do caso de uso.

Ex: Consultar Catlogo de Produtos

 Especificando Casos de Usos

Escreva uma breve descrio sobre o propsito do caso de

uso.

Ex:

Consultar Catlogo de Produtos

Este caso de uso permite que o ator consulte os produtos

disponveis para compra.
 Rascunhe os Fluxos do Casos de Uso

Comece a especificar os casos de usos fazendo um

rascunho inicial, posteriormente, acrescente todos os
detalhes e passos.

Fluxo Bsico: a sequncia de aes que permitem ao

ator atingir o objetivo principal que deseja atingir.

Fluxos Alternativos: so as sequncias de aes para

comportamentos opcionais ou cenrios nos quais as
coisas saem errado.
 Rascunhe os Fluxos do Casos de Uso

Fluxo Bsico

1. Primeiro passo
2. Segundo passo
3. Terceiro passo

A1 Fluxo alternativo 01
A2 Fluxo Alternativo 02
A3 Fluxo Alternativo 03
 Rascunhe os Fluxos do Casos de Uso

Um nico Fluxo Bsico

Cenrio bem sucedido do incio ao fim

Vrios Fluxos Alternativos

Cenrios alternativos do ponto de vista do ator

Casos excepcionais
 Perguntas de Auxlio

Fluxo Bsico
Qual evento d incio ao caso de uso?
Como o caso de uso termina?

Fluxos Alterativos
Existem comportamentos opcionais para o caso de uso?
O que pode ocorrer de errado?
Que tipos de recursos podem estar indisponveis?
 Fluxo Bsico

O fluxo bsico enumera os passos principais do caso de uso.

Enumere os passos do fluxo bsico.

Escreva os passos da seguinte forma:

O que o ator faz?

O que o sistema faz em resposta?

No esquea de sempre descrever quais informaes so

trocadas?
 Fluxos Alternativos Especficos

So importantes para deixar o Fluxo Bsico fcil de ler e entender.

Geralmente a seo Fluxos Alternativos a maior do caso de uso.

Guidelines para escrever Fluxos Alternativos Especficos:

Informe o passo de incio do Fluxo Alternativo no fluxo bsico ou em outro fluxo

alternativo

Descreva a condio que disparada o incio do Fluxo Alternativo

Descreva a ao ou os passos de execuo do Fluxo Alternativo

Informe o passo no qual o caso de uso deve continuar aps a execuo do Fluxo
Alternativo

Se o caso de uso for finalizado aps o Fluxo Alternativo, escreva O caso de uso
encerrado.
 Fluxos Alternativos Genricos

So similares aos Fluxos Alternativos Especficos, porm, no

possuem ponto de incio especfico pois podem iniciar em qualquer
passo do fluxo de eventos.

Guidelines para escrever Fluxos Alternativos Genricos:

Descreva a condio que disparada o incio do Fluxo Alternativo

Descreva a ao ou os passos de execuo do Fluxo Alternativo

Informe o passo no qual o caso de uso deve continuar aps a execuo do Fluxo
Alternativo

Se o caso de uso for finalizado aps o Fluxo Alternativo, escreva O caso de uso
encerrado.
 Pr-Condies

uma restrio que deve ser verdadeira antes que o caso de

uso possa comear.

O ator tem que estar autenticado e autorizado no sistema.

A lista de produtos deve estar disponvel.

A Pr-Condio no o evento que inicia o caso de uso.

Deve ser observvel do ponto de vista do ator.

So opcionais e devem ser usadas apenas em caso de

necessidade de esclarecimentos.
 Ps-Condies

Uma Ps-Condio uma condio que deve ser verdadeira

ao final do caso de uso.

Representam os diferentes tipos de trminos que o caso de

uso pode retornar ao ator.

Por exemplo:

Ao final do caso de uso:

 Dicas Finais

Descreva somente os eventos que so visveis para o ator.

Tenha certeza de que o caso de uso retorna valor ao ator.

Procure no acrescentar informaes sobre a interface, caso

contrrio, cada vez que a interface mudar, ser necessrio
alterar a descrio do caso de uso. Deixe detalhes de
interface para o prottipo.

Use uma linguagem afirmativa e precisa.

 Obrigado!

Heyder Lopes Martins

heyderlmartins@gmail.com