Academia BR Bdep Requisitos

Banco de Dados
Anlise de Requisitos
Vtor E. Silva Souza

(vitorsouza@inf.ufes.br)
http://www.inf.ufes.br/~ vitorsouza
Departamento de Informtica
Centro Tecnolgico
Universidade Federal do Esprito Santo
Licena para uso e distribuio
Este obra est licenciada com uma licena Crea8ve
Commons Atribuio-Compar8lhaIgual 4.0 Internacional;
You are free to (for any purpose, even commercially):
Share: copy and redistribute the material in any
medium or format;
Adapt: remix, transform, and build upon the material;
Under the following terms:
AOribu8on: you must give appropriate credit, provide a link to
the license, and indicate if changes were made. You may do
so in any reasonable manner, but not in any way that suggests
the licensor endorses you or your use;
ShareAlike: if you remix, transform, or build upon the
material, you must distribute your contribu8ons under the
same license as the original.
Mais informaes podem ser encontradas em:

http://creativecommons.org/licenses/by-sa/4.0/
Maio 2014 Banco de Dados - Anlise de Requisitos 2
Crditos
Algumas informaes foram re8radas e adaptadas de
apresentaes de um curso sobre Engenharia de
Requisitos do prof. Steve Easterbrook, modicadas pelo
prof. John Mylopoulos.

Desenvolvimento de sistemas
Gesto de servios de uma
Problema biblioteca.
Validao
Descrio do
Correspondncia
Toda solicitao de emprs-

problema timo deve ser atendida.
Verificao
Correteza
Descrio da Processo de check-out de

soluo livros da biblioteca.
Sistema de check-out de
Sistema livros da biblioteca.

Separao entre problema e soluo
O problema mais bvio pode no ser o problema que
deve ser resolvido;
Deve-se discu8r o problema com os stakeholders para
um melhor entendimento;
Uma descrio precisa do problema:
Auxilia nas escolhas de projeto;
Permite a criao de bons casos de teste;
Auxilia na comunicao entre a equipe de
desenvolvimento.
Stakeholders so pessoas que so afetadas pelo
problema e, portanto, tem algo a dizer sobre
sua soluo. Ex.: clientes, usurios, etc.
Engenharia de Requisitos
Domnio do Problema Domnio da Soluo
Requisitos Hardware
Software
Propriedades do
Outros recursos
domnio
Propriedades do domnio:
Coisas que so verdadeiras independente de
construirmos ou no um sistema;
Requisitos:
Coisas que queremos tornar verdadeiras aps a
construo do sistema;
Especicao:
Uma descrio do comportamento que o sistema deve
ter para atender os requisitos.
Problema vs. soluo
Exemplo: evitar acesso no autorizado aos
computadores do departamento:
alunos algoritmos de
hackers criptografia
senhas
administradores arquivos de senha
do sistema usurios
gerenciamento da
processo memria
digitao
de criao formulrios
da senha contedo da cache
de senhas
no teclado
sockets seguros
post-its com (transm. rede)
senhas escritas
Coisas que o sistema Coisas Coisas internas

no consegue observar compartilhadas do sistema

Especicao
Requisito (R):
Os computadores devero ser acessados somente
por pessoal autorizado;
Propriedades do domnio (D):
Pessoal autorizado pode memorizar uma senha;
Senhas no so compar8lhadas entre pessoas;
Especicao (S):
Acesso aos computadores ser liberado mediante
digitao de nome de usurio e senha;
S, D R
E se as suposies sobre o domnio forem falsas?
Especicao
As fronteiras so maleveis:
Ex.: incluso de sensores.
pessoas
esperando botes de algoritmo de
pessoas
chamada movimentao
no elevador
botes de andar
o andar que as pessoas indicao do andar
esperando querem ir algoritmo de controle
acionamento do
motores do motor
elevador abertura
regras de da porta
segurana

Completude e correo
Critrios de correo:
Um determinado sistema sa8sfaz a especicao;
A especicao, dadas as propriedades de domnio,
sa8sfaz os requisitos.
Critrios de completude:
Descobrimos todos os requisitos importantes;
Descobrimos todas as propriedades de domnio
relevantes.

Entender o que os stakeholders querem;
Analisar a necessidade;
Vericar a fac8bilidade;
Negociar uma soluo razovel;
Especicar a soluo sem ambiguidade;
Validar a especicao;
Gerenciar mudanas nos requisitos;
Etc.
Neste curso veremos apenas uma parte da

Engenharia de Requisitos.

Banco de Dados Anlise de Requisitos
ELICITAO DE REQUISITOS

So funes desta fase do processo:
Concepo;
Elicitao;
Elaborao;
Negociao;
Especicao;
Validao;
Gerenciamento.
Independente se
feitas em sequncia
ou em paralelo...

Concepo
Geralmente a primeira fase do processo;
Iden8cao de um problema ou oportunidade;
Perguntas genricas e superciais;
Obje8vo estabelecer:
Um entendimento bsico do problema;
Quem so os stakeholders;
A natureza da soluo desejada;
A eccia da comunicao entre o engenheiro de
requisitos e os especialistas de domnio.

Primeiras perguntas (exemplos)
Quem est pedindo esta soluo?
Quem ir us-la?
Qual seu benemcio econmico?
De que problema(s) esta soluo ir tratar?
Em que ambiente de negcio ela est inserida?
Existem qualidades fundamentais (desempenho,
segurana, etc.) relevantes ao problema?
...

Primeiras perguntas (exemplos)
Meta-questes auxiliam a estabelecer a ecincia da
comunicao analista-especialistas:
Voc a pessoa certa para responder estas
questes? Suas respostas so ociais?
Minhas questes so relevantes?
Estou perguntando coisas demais?
Existe outra pessoa que pode prover mais
informaes?
Existe alguma pergunta que eu deveria ter feito e
no z?
Com quem mais eu deveria conversar sobre isso?

Elicitao
A meta descobrir informaes sobre o problema:
Os obje8vos dos stakeholders (problema);
As funes do sistema (soluo) a ser construdo (o
que ele deve fazer);
Como o sistema se encaixa nas necessidades de
negcio do cliente;
Como ser usado no dia-a-dia.
A8vidade muito complicada;
Requer alto nvel de organizao.

Tcnicas de elicitao
As primeiras perguntas daro somente um
entendimento bsico do problema;
Para elicitar os requisitos, devemos u8lizar abordagens
mais sos8cadas. Veremos algumas destas:
Amostragem;
Inves8gao;
Entrevista;
Observao;
Ques8onrio;
Proto8pao.

Possveis problemas na elicitao
De escopo:
Os limites do sistema no so bem denidos;
O cliente especica muitos detalhes inteis.
De entendimento:
O cliente no tem certeza do que quer;
No conhece as capacidades e limitaes do
ambiente computacional;
Possui problemas de comunicao com os
engenheiros de sotware;
Omite informaes consideradas bvias;

De entendimento (con8nua):
Especica requisitos que conitam com os de outro
cliente;
Especica requisitos ambguos.
Pol8cos:
Funcionrios no colaboram por acharem que o
sistema lhes custar o emprego;
Brigas pol8cas internas.
De vola8lidade:
Os requisitos mudam com o tempo.


Elaborao
Tem por obje8vo a reduo da ambiguidade (se
possvel, sua eliminao);
So u8lizados modelos (o nvel de formalidade pode
variar, dependendo do projeto);
Formalizar os requisitos em modelos auxilia na
iden8cao de falhas na elicitao;
Modelos so teis tambm para negociao e
validao.

Negociao
No incomum:
Clientes quererem mais do que possvel ser feito;
Stakeholders terem requisitos conitantes.
Deve-se reconhecer os ml8plos pontos de vista e
tentar negociar uma soluo adequada;
Idealmente, deve-se evitar situaes em que hajam
vencedores e perdedores.
Coloque trs stakeholders numa sala e

pergunte que tipo de sistema eles querem.
Voc provavelmente vai obter quatro ou mais
opinies diferentes (Annimo)

Especicao
Produto nal da Engenharia de Requisitos;
Uma especicao pode ser:
Um documento escrito;
Modelos grcos;
Um modelo formal matem8co;
Um prot8po;
Qualquer combinao dos itens acima...
a base das fase seguintes da Engenharia de Sotware;
Varia de acordo com caracters8cas do projeto
(tamanho, cri8calidade, etc.).

Validao
Revises tcnicas para averiguar que:
Todos os requisitos foram elencados sem
ambiguidade;
Inconsistncias, omisses e erros foram detectadas e
corrigidas;
Tudo est documentado de acordo com padres
estabelecidos pela organizao.

Gerenciamento
A8vidades que ajudam no controle e rastreamento de
mudanas nos requisitos:
Cada requisitos recebe um iden8cador;
So montadas tabelas de rastreamento:
funcionalidades, dependncias, subsistemas,
interface, etc.;
Mudanas nos requisitos podem ser mais facilmente
propagadas para frente;
Bugs no sotware pronto podem ser analisados em
termos dos requisitos (para trs).

TCNICAS DE ELICITAO

Amostragem
H muitos stakeholders. Quais devem par8cipar?
H muitos documentos. Quais devem ser analisados?
Amostragem:
Seleo sistem8ca de elementos representa8vos;
8l em combinao com outras tcnicas;
Reduz custos, acelera o processo de elicitao;
Reduz tendncias (de uma seleo sem critrio).
Tamanho da amostra: depende substancialmente do
custo envolvido e do tempo requerido/disponvel.

Amostragem
Passos:
1. Determinar o que ser coletado e para que;
2. Determinar a populao a ser amostrada;
3. Escolher o 8po de amostra;
4. Decidir sobre o tamanho da amostra.
Elementos so No baseada em Baseada em

selecionados... probabilidades probabilidades
diretamente, sem Randmica
De Convenincia
restries: Simples
segundo um Randmica
Intencional
critrio especfico: Complexa

Amostra de Convenincia
Irrestrita (no h critrio de seleo);
No u8liza probabilidades;
Mais fcil;
Geralmente apresenta resultados irreais;
Ex.: aviso chamando os interessados a par8cipar de
uma reunio.

Amostra Intencional
So estabelecidos critrios de seleo;
No leva em conta probabilidades;
Amostra moderadamente convel;
Ex.: escolha de um grupo de indivduos que aparenta
ter conhecimento na rea do novo sistema.

Amostra Randmica Simples
Baseada em probabilidades;
No h critrios de seleo;
Parte de uma lista de documentos/pessoas a ser
amostrada:
Todos possuem igual probabilidade de serem
escolhidos;
Escolhe-se N elementos;
Dependendo da quan8dade de documentos e
pessoas, se torna impra8cvel.

Amostra Randmica Complexa
Deve ser a escolha preferencial;
U8liza probabilidades em cima de critrios de seleo
(no sobre toda a populao).

Inves8gao
Algumas informaes so dimceis de obter por
entrevistas ou observao:
Histrico da organizao;
Direcionamento futuro;
Informaes nanceiras;
Contextos da organizao;
Etc.
U8liza-se de inves8gao (anlise de documentos).

Inves8gao
Documentos quan8ta8vos:
Relatrios de resultados, chas e formulrios, etc.
Observar como so feitos os clculos, procurar
oportunidades de o8mizao, uxo de comunicao,
redundncia/campos inteis, uxos no ociais, etc.;
Documentos qualita8vos:
Memorandos, quadros de aviso, manuais, etc.;
Iden8car termos que caracterizam o que bom
ou ruim para a organizao, disputas (internas e
externas), pol8cas e caracters8cas da org., etc.

Entrevista
Conversa direcionada com um propsito especco;
Formato pergunta resposta, geralmente 2 pessoas
(mas pode haver casos com mais de um entrevistador
ou entrevistado);
Obje8va obter:
As opinies do entrevistado (descoberta de
problemas-chave a serem tratados);
Seus sen8mentos sobre o estado atual do sistema;
Metas organizacionais e pessoais;
Procedimentos informais.

Entrevista
importante para o entrevistador:
Construir uma base de conana e entendimento;
Manter o controle da entrevista;
Vender a ideia do sistema;
Evitar questes tendenciosas (que induzem).
Etapas principais:
Planejamento: ler material existente, estabelecer
obje8vos, decidir quem entrevistar, marcar;
Conduo: questes obje8vas x subje8vas,
organizao estruturada x no estruturada;
Relatrio da entrevista: documentao.
Entrevista: questes subje8vas
Vantagens:
Proveem riqueza de detalhes;
Revelam novos ques8onamentos;
Colocam o entrevistado vontade;
Permitem maior espontaneidade.
Desvantagens:
Podem resultar em muitos detalhes irrelevantes;
Perda do controle da entrevista;
Respostas muito longas para se obter pouca informao
8l;
Podem dar a impresso de que o entrevistador est
perdido, sem obje8vos.

Entrevista: questes obje8vas
Vantagens:
Ganho de tempo, vo direto ao ponto em questo;
Mantm o controle da entrevista;
Levam a dados relevantes.
Desvantagens:
Podem ser maantes para o entrevistado;
Podem falhar na obteno de detalhes importantes;
No constroem uma anidade entre entrevistador e
entrevistado.

Entrevista: estrutura
Geral Especfico
Especfico Geral
Funil Pirmide
Especfico
Geral
Especfico
Diamante

Entrevista: registro
Gravador/lmadora: Anotaes:
Requer permisso; Mantm o entrevistador
Registro completo; alerta;
Rapidez e melhor Mostra interesse e
desenvolvimento; preparao do
Reproduo para outros entrevistador.
membros da equipe; Pode haver perda do
Pode deixar o andamento da conversa;
entrevistado nervoso ou Muita ateno a fatos e
distrado; no a sen8mentos e
Pode haver necessidade opinies.
de transcrever a ta.

Entrevista: relatrio
Deve capturar a essncia da entrevista;
Escreva o relatrio o mais breve possvel para assegurar
a qualidade;
Registre: entrevistado, entrevistador, data, assunto e
obje8vos;
Diga se os obje8vos foram alcanados;
Aponte obje8vos para entrevistas futuras;
Registre os pontos principais da entrevista e sua
opinio.

Ques8onrios
Questes escritas e distribudas para um conjunto de
pessoas envolvidas com o sistema;
Obje8vos:
Procurar quan8car o que foi achado em entrevistas;
Determinar quanto um sen8mento realmente
difundido ou limitado;
Examinar uma grande amostra de usurios para
sen8r problemas ou levantar questes importantes
antes das entrevistas (estudo exploratrio).
Muito similar s entrevistas, pode ser u8lizado em
conjunto para esclarecimentos ou aprofundamentos.

Ques8onrio: cuidados
No possvel renar/explicar questes ou mudar a
estrutura como em entrevistas. Portanto se deve:
Ter questes claras e no ambguas;
Ter uxo denido (capture o interesse primeiro,
deixe itens controversos por l8mo);
Levantar, antecipadamente, as dvidas das pessoas
que iro respond-lo. Testar o ques8onrio.
Use a linguagem dos usurios, garanta preciso tcnica;
Prime pela simplicidade, perguntas rpidas;
Evitar que os usurios se sintam inves8gados ou
obrigados. Pergunte s aquilo que saibam responder.

Ques8onrio: obje8vas vs. subje8vas
Subjetivas Objetivas
Tempo gasto para responder Alto Baixo
Natureza exploratria Alta Baixa

Ampliture e profundidade Alta Baixa
Facilidade de preparao Fcil Difcil
Facilidade de anlise Difcil Fcil
Questes subjetivas: cuidado com respostas muito amplas,

que dificultem o processamento;
Questes objetivas: cuidado com escalas para evitar
perguntas tendenciosas ou o efeito coluna do meio.
Observao
Observar o comportamento dos tomadores de
deciso em seu ambiente de trabalho;
Tomadas de deciso: aes que inuenciam o dia-
a-dia da tarefa a ser automa8zada;
Diversos nveis: operacional, gerencial, estratgico;
Obje8vos:
Levantar o que realmente feito na pr8ca;
Iden8car relacionamentos e inuncias de lderes;
Obter informaes no capturadas de outra forma e/
ou conrmar/negar informaes de inves8gao,
entrevistas e ques8onrios.

Observao
Preparao:
Quem (ou o que)? (Quais a8vidades)
Quando? (Por horrio ou por evento)
Onde?
Por que?
Como? (Nvel de detalhes)
Registro (documentao);
Preparar os formulrios de registro de antemo para
serem preenchidos durante a observao.

Proto8pao
Construo de uma verso incompleta do sistema para
que futuros usurios o experimentem;
Permite capturar:
Reaes iniciais do usurio;
Sugestes de melhorias, novas capacidades;
Prioridades em relao s diferentes funes.
Um prot8po pode ser:
No operacional (somente interface);
Arranjado s pressas (completo, porm ruim);
Primeiro de uma srie (completo, piloto);
Caracters8cas selecionadas (uma fa8a do sistema).
Proto8pao
Vantagens Desvantagens
Permite alterar o sistema Maior dificuldade
mais cedo (quando o custo de gerenciamento
menor); do projeto;
Oportunidade de avaliao Adoo do
de viabilidade do sistema; prottipo como
Leva a sistemas que sistema completo.
atendem melhor as
necessidade dos usurios.
Prottipos devem ser construdos rapidamente, enfatizando a interface

com o usurio e com envolvimento dos mesmos para feedback
imediato e sua subsequente modificao.

Tcnicas de elicitao na pr8ca
Elicitao o meio;
A informao a ser levantada o m;
O que queremos descobrir?
Quem so os stakeholders?
Quais so seus obje8vos?
Quais funcionalidades querem pro sistema?
Quais so os elementos de informao do sistema?
Cenas dos prximos captulos...

Exerccio
No contexto do problema escolhido para o seu trabalho
pr8co, tente responder as seguintes questes:
Quais tcnicas seriam teis para entender o contexto
atual e o problema a ser resolvido? Por que?
Quais tcnicas no seriam teis? Por que?
Para as tcnicas escolhidas, esboce:
Inves8gao: que documentos inves8gar?
Entrevista/ques8onrios: quem vai responder? Qual o teor
das perguntas?
Observao: o que observar?
Proto8pao: que parte do sistema seria proto8pada? Por
que?

ANLISE DE OBJETIVOS

Obje8vos
Requisitos prescrevem o que um sistema deve fazer;
Obje8vos explicam o porqu;
Aumentam o nvel de abstrao e trazem vantagens:
Critrio de completude/per8nncia dos requisitos;
Maior legibilidade em documentos complexos;
Explorao de alterna8vas;
Deteco de conitos entre stakeholders;
Maior estabilidade.

O escopo do problema
Imagine uma biblioteca de uma faculdade:
Livros no esto disponveis no incio do perodo;
Isso um sintoma. Bibliotecrios, por que?
Porque os professores no nos mandam a bibliograa
em tempo hbil;
Tambm um sintoma? Professores, por que?
Porque as matrias so alocadas no l8mo minuto;
Sintoma? Comisso de ensino, por que?
Porque no sabemos quais professores esto
disponveis no perodo at o l8mo minuto;
Sintoma? Chefe do departamento, por que?
Porque existe incerteza com relao a afastamentos,
novas contrataes (subs8tutos), monitores, etc.
...

Quando termina?
Todo problema pode ser visto como sintoma de outro;
Cuidado para no con8nuar indenidamente;
Abordagem vericar com os stakeholders se:
possvel resolver este problema, independente de
sua causa (do problema maior)?
Resolver este problema (e no a causa) ajuda?
Querem que seja resolvido?
Algum vai pagar para resolver este problema
(independente da causa)?
A anlise de factibilidade ajuda

com essas questes.

O escopo da soluo
Escolheu-se como problema o atraso no envio da
bibliograa por parte dos professores:
Soluo: informa8zar os formulrios de envio do
programa da disciplina;
E j que estamos fazendo isso:
Que tal informa8zar tambm o envio de ordens de
compra de livros que no temos s editoras?
Aproveita-se tambm para informa8zar a gerncia
da coleo, livros que estragam, somem, etc.
Da j automa8zamos tambm o emprs8mo/
devoluo de livros pelos alunos...
Opa! Este novo sistema est me custando muito caro!

Quando termina?
Podemos informa8zar sempre cada vez mais;
Abordagem vericar com os stakeholders se:
A soluo escolhida implementvel (independente
das alterna8vas)?
Implementar esta alterna8va (independente de
outras) ajuda a resolver o problema? A soluo
sa8sfaz?
Algum vai pagar para implementar esta soluo?
A anlise de alternativas ajuda

com essas questes.

Exerccio: sistema de check-out de um hotel
Sistema atual: contas dos clientes so atualizadas duas
vezes por dia, incluindo diria, servio de quarto, frigobar,
pay-per-view, telefone, etc.
Quando o cliente deixa o hotel, deve mencionar cobranas
recentes (daquele dia), que so ento adicionadas conta
para serem pagas;
Gerncia do hotel gostaria de mudar o sistema porque:
Erros nas contas so frequentes: clientes no pagam
alguns consumos ou so cobrados em dobro por outros;
H uma expecta8va de crescimento dos negcios: uma
extenso do hotel est sendo construda;
Atualizao manual dos registros dos hspedes pode se
tornar problem8ca aps a expanso;
Querem ter atualizaes em tempo real dos registros dos
hspedes a par8r de qualquer ponto de consumo.

Quais so os problemas?
Quais so as alterna8vas?
Quais so os critrios de seleo?
Qual a sua recomendao?

Quais so os problemas?
Perda de renda por registros defasados/errados;
Registrar informaes tem um alto custo;
Potenciais problemas com expanso dos negcios;
Quais so as alterna8vas?
Manter o sistema atual;
Manter o sistema, com atualizaes mais frequentes;
Construir um sistema integrado, em tempo real;
Quais so os critrios de seleo?
Custo-benemcio (desenvolvimento e operao, sistema novo
vs. sistema atual, reduo de perdas);
Convenincia/sa8sfao dos hspedes;
Qual a sua recomendao?
??

Stakeholders
Primeiras perguntas devem iden8car os stakeholders:
Quem est apresentando o problema / solicitando
sua soluo?
Quem est pagando pelo desenvolvimento?
Quem se benecia economicamente com ele?
Quem so as pessoas que usaro o sistema ou
par8ciparo do mesmo?
Em uma empresa, vericar se os gerentes/diretores
esto cientes e apoiam a inicia8va. Departamento de
marke8ng geralmente tambm se envolve;
Ao longo do projeto, pode-se iden8car novos.

Obje8vos dos stakeholders
Iden8cados os stakeholders, passamos para a
elicitao dos seus obje8vos.
Quando perguntei dos No trabalhar o mnimo No chame-os de meus

seus objetivos para o ano possvel enquanto evito a objetivos se voc quer
que vem eu tinha outra ira do troll de cabelos dizer os seus objetivos.
ideia em mente. pontiagudos.
Exerccio: agenda de reunies
Empresa de grande porte precisa fazer vrias reunies
(internas e externas) diariamente;
Reunies variam em data, hora, local, par8cipantes,
recursos exigidos;
Empresa possui vrias salas de reunio, variando
tambm em localizao, tamanho, recursos;
Gostariam de um sistema que:
U8lizasse as salas de maneira eciente;
Promovesse reunies com boa par8cipao;
Priorizasse funcionrios que usam os recursos de
maneira responsvel.

Quem so os stakeholders? Existem diferentes papis?

Quem so os stakeholders? Existem diferentes papis?
Alta gerncia;
Organizadores de reunio;
Par8cipantes de reunio;
Secretrias.

O que a alta gerncia quer?

O que a alta gerncia quer?
Evitar desperdcio de recursos;
Alta par8cipao em reunies;
Prioridades no agendamento;
Reduzir a carga de trabalho das secretrias para que
elas possam focar em outras coisas;
Uso responsvel do sistema de agendamento.

O que os organizadores de reunio querem?

O que os organizadores de reunio querem?
Organizar reunies mais rapidamente (sem depender
das secretrias);
Vericar facilmente todas as salas disponveis para
uma escolha adequada de sala de reunio;
Re-agendamento facilitado em caso de mudanas;
Saber os compromissos dos potenciais par8cipantes
da reunio para melhor escolha de data/hora.

O que os par8cipantes da reunio querem?

O que os par8cipantes da reunio querem?
Que as reunies possam se adaptar a mudanas em
seus calendrios pessoais;
Diminuir a quan8dade de conitos de agenda;
Privacidade.

O que as secretrias querem?

O que as secretrias querem?
Reduzir a carga de trabalho de agendamento.

Modelo de obje8vos estratgico
Representam os obje8vos dos stakeholders;
Usado em diferentes propsitos:
Nos permi8r comparar diferentes solues para
alcanar os mesmos obje8vos;
Mostrar a interao entre os diferentes atores do
sistema como ele hoje (AS-IS);
Mostrar a interao entre os diferentes atores do
novo sistema aps sua implantao (TO-BE).

A linguagem i*
Abordagem de modelagem criada pelo prof. Eric Yu na
Universidade de Toronto;
Prope o uso de conceitos de interao social em
modelos de anlise de requisito e projeto de sistemas;
Mais informaes: hOp://istar.rwth-aachen.de/

Elementos de modelagem bsicos de i*
Ator Objetivo D
Dependncia
Fronteira que
delimita o Tarefa
ponto de vista Meio-fim
do ator.
Recurso
Decomposio
Objetivo
soft
--
-
+
So como objetivos normais (hard), porm ++
no possuem um critrio preciso para Contribuio
satisfao.

Exemplo: interao dos atores AS-IS

Exemplo: comparao entre alterna8vas

Exerccio: comparao entre alterna8vas
Exerccio: avalie o obje8vo das secretrias Reduzir a
carga de trabalho de agendamento, com relao aos
critrios de qualidade: Baixo custo e Eccia.

Exerccio: comparao entre alterna8vas

Exemplo: interao dos atores TO-BE

Ferramentas para modelagem
Especcas:
OpenOME:
hOp://sourceforge.net/projects/openome/
Genricas:
LibreOce Draw:
hOps://www.libreoce.org/discover/draw/
OmniGrae (Mac, no-gratuita):
hOp://www.omnigroup.com/omnigrae/
Microsot Visio (Windows, no-gratuita):
hOp://oce.microsot.com/pt-br/sotware-de-
diagramacao-prossional-microsot-visio-
FX103472299.aspx.
Modelo de obje8vos t8co
Representam como os obje8vos de um determinado
ator so alcanados;
Relao com modelo estratgico mostra:
Per8nncia: um elemento t8co (requisito) existe
porque sa8sfaz um elemento estratgico (obje8vo);
Completude: todos os elementos estratgicos
(obje8vos) so sa8sfeitos pelos elementos t8cos
(requisitos).
Abordagem para construo:
Para cada obje8vo estratgico, perguntar: o que o
sistema deve fazer para sa8sfazer este obje8vo?

Exemplo: modelo de obje8vos t8co

Exerccio
Como podemos sa8sfazer o seguinte obje8vo
estratgico dos organizadores de reunio?
Re-agendamento facilitado em caso de mudanas.

Exemplo: modelo de obje8vos t8co

Exemplo: ml8plos atores envolvidos

Recapitulando...
Obje8vos estratgicos aumentam o nvel de abstrao,
trazendo algumas vantagens;
Primeiro iden8camos os stakeholders;
Em seguida levantamos seus obje8vos at que se
acredite que o modelo esteja completo;
Obje8vos t8cos fazem a transio para um nvel de
abstrao mais baixo (funcionalidades do sistema):
Para cada obje8vo estratgico, vericar como ele
pode ser sa8sfeito pelo sistema;
Con8nuar at que o modelo esteja completo, i.e.,
sa8sfaz todos os obje8vos estratgicos.

Prximos passos
Descrever as funcionalidades do sistema u8lizando
cenrios / casos de uso;
Toda tarefa deve estar contemplada nos casos
descritos, assegurando novamente a completude;
A decomposio de tarefas, no entanto, cria vrios
nveis de granularidade;
preciso escolher qual nvel ser associado a um caso
de uso.

Granularidade
...

Exerccios
1. Dado um problema, analise sua descrio (use o problema
entregue pelo professor ou o problema escolhido para seu
trabalho pr8co, se quiser);
2. Iden8que os stakeholders;
3. Iden8que os obje8vos dos stakeholders e crie modelos de
obje8vos na viso estratgica:
Como o sistema atualmente (AS-IS)?
Quais so as alterna8vas para melhoria? Como avaliar
estas alterna8vas segundo critrios relevantes?
Como voc imagina o novo sistema (TO-BE)?
4. Crie modelos de obje8vos na viso t8ca, mostrando como
os obje8vos dos stakeholders seriam sa8sfeitos.

CASOS DE USO

Por qu? O que? Como?
Objetivos Cenrios Projeto Cdigo
Cenrios indicam o que ser feito

para solucionar o problema, mas
sem se preocupar com tecnologias
de implementao.
No projeto de sistemas que

Objetivos retratam o problema e levamos em considerao a
indicam porque uma determinada tecnologia e dizemos como o
soluo necessria (e ideal). sistema far o que deve fazer.

Como descrever os cenrios
Linguagem natural;
Linguagem natural estruturada;
Formulrios e modelos (templates).
Linguagem de descrio de projeto;
Baseadas em linguagem de programao.
Notaes grcas;
Especicaes matem8cas.

Casos de uso
Uma forma de estruturar requisitos:
Modelos grcos e linguagem natural baseada em
formulrios;
Representam o que os usurios podem fazer no
sistema;
So independentes do mtodo de anlise (OO,
estruturado, etc.).

Casos de uso
Um caso de uso captura um contrato que descreve
o comportamento do sistema sob vrias condies
a medida que ele responde a requisies de um de
seus usurios. (Alistair Cockburn)
Um caso de uso conta uma histria sobre como um

usurio final (interpretando um de uma srie de papis)
interage com o sistema dentro de um conjunto de
circunstncias. (Roger Pressman)
Um caso de uso especifica um comportamento de um

sistema segundo uma perspectiva externa e uma
descrio de um conjunto de sequncias de aes
realizadas pelo sistema para produzir um resultado de
valor observvel por um ator. (Grady Booch)

Casos de uso
So interaes picas entre o sistema e um ator
humano, outro sistema ou disposi8vo;
Capturam uma funo visvel ao ator;
Busca a8ngir uma meta do usurio.
Por isso a ligao com o modelo de

objetivos, que veremos frente.

Sistema (socio-tcnico) vs. sotware
Durante a anlise de requisitos, trabalhamos com a
ideia de sistema scio-tcnico;
A par8r do modelo de casos de uso, focaremos na parte
tcnica do sistema: sotware + hardware;
Cenrios so implementados em sotware;
Componentes de hardware relevantes so
representados como atores;
Interaes entre componentes humanos e
organizacionais seriam representadas em outros
modelos (fora do contexto dessa disciplina).

Obje8vos dos casos de uso
Devem responder [Jacobson]:
Quem so os atores?
O que podem fazer no sistema?
Que pr-condies existem?
Quais as tarefas principais realizadas?
Que excees devem ser consideradas?
Que variaes so possveis nas interaes?
Que informaes do sistema sero adquiridas,
produzidas ou alteradas?

Obje8vos dos casos de uso
Em resumo: representar o comportamento desejado do
sotware (em termos de requisitos funcionais);
Podem ser usados como base para:
Construo de casos de teste;
Es8ma8vas de custo (cronograma) e tempo;
Iden8cao dos riscos;
Denio de prioridades;
Proto8pao;
Manuais de usurio e documentao em geral.

Passos
1. Iden8cao dos atores;
2. Captura dos casos de uso;
3. Criao de diagramas de casos de uso;
4. Elaborao da descrio de cada caso de uso;
5. Anlise de possveis associaes entre casos de uso;
6. Separe os casos de uso em subsistemas.

1) Iden8cao dos atores
Um ator um papel especco que um usurio pode
desempenhar;
Um mesmo usurio pode desempenhar vrios
papis, cada hora sendo um ator diferente.
Modela qualquer coisa externa que possa interagir com
o sotware:
Usurios, outros sotwares, disposi8vos, etc.;
Delimitam o escopo do sotware;
No necessrio ser descrito em detalhes (basta um
pargrafo).

Perguntas para iden8car atores
Quem u8liza o sotware?
Quem instala e mantm o sotware?
Que outros sotwares/disposi8vos u8lizam o sotware
ou so u8lizados por ele?
Quem obtm informao do sotware?
Quem prov informao ao sotware?
O que o sotware faz automa8camente?

Exerccio: quais os atores deste sotware?

2) Captura dos casos de uso (UCs)
Pode ser feita a par8r dos modelos de obje8vos;
Tarefas do modelo de obje8vos t8co que sejam
implementadas em sotware;
Pode ser feita durante a concepo (conversas iniciais)
e elicitao (entrevistas, etc.);
Iden8que as interaes discretas entre usurios e
sotware;
Geralmente so iden8cados em paralelo com a
iden8cao dos atores;
Alguns casos e atores podem ser capturados em fases
mais avanadas.

Perguntas para iden8car casos de uso
Que funes o ator ir querer do sotware?
O sotware armazena informaes?
Que atores iro criar, ler, atualizar ou apagar estas
informaes?
O sotware precisa no8car algum ator sobre alguma
mudana interna?
Existem eventos externos que o sotware precisa estar
ciente?
Que atores informam o sotware sobre estes eventos?

Granularidade dos casos de uso
Casos de uso no devem ser muito pequenos nem
muito grandes;
Um bom caso de uso compreende uma sequncia de
transaes realizadas pelo sotware que produzem um
resultado de valor observvel para um par6cular ator.

Exerccio: que UCs podemos extrair daqui?




3) Diagramas de casos de uso
Representam atores, casos de uso e suas associaes;
Uma associao entre um ator e um caso de uso
signica que esmulos podem ser enviados entre
atores e casos de uso, que se comunicam entre si;
Proveem uma viso geral das funcionalidades do
sotware.

Diagramas de casos de uso - elementos

Diagramas de casos de uso - exemplo

Eventos que ocorrem automa8camente
Eventos podem ser disparados por determinadas
condies, geralmente temporais:
Ex.: realizar backup a cada sexta-feira.
Podemos mapear o evento como um ator ou trat-lo
como um elemento interno.

Diagramas de casos de uso - exemplo
FES
rtamento
formtica Especificao de Req
Diagrama de Casos de Uso do Subsistema Controle de Assinaturas
Os seguintes casos de uso compem este pacote:

Assinar Revista: um visitante qualquer paga e efetua a assinatura da revista para os
12
Maio meses;
2014 Banco de Dados - Anlise de Requisitos 116
Exerccio
Represente os atores e os casos de uso do sistema de
agendamento de reunies em um diagrama.

4) Descrio dos casos de uso
O diagrama insuciente para dizer o que cada caso de
uso faz;
Deve-se descrever textualmente o uxo de eventos de
cada caso separadamente;
Esta tarefa deve ser iniciada aps alguma estabilidade
dos casos de uso, para evitar perda de tempo.

O que pode constar na descrio
Iden8cador do caso de uso (UC1, UC2, etc.);
Nome do caso de uso;
Descrio breve / obje8vos;
Pr-condies e ps-condies;
Entradas e sadas de dados;
Fluxos (normal, alterna8vos, cenrios);
Classes/en8dades par8cipantes;
Restries de domnio;
Requisitos no-funcionais associados;
Outras observaes.

Curso normal e cursos alterna8vos
Curso normal: mundo perfeito, tudo ocorre como
planejado;
Cursos alterna8vos: excees, erros, uxos alterna8vos,
etc.
Para encontr-los, analise o curso normal e pergunte,
para cada item:
Tem alguma outra ao que pode ser feita?
Tem alguma coisa que pode dar errado?
Existe algum comportamento que pode ocorrer a
qualquer momento?

Exemplos de cursos alterna8vos
O ator sai da aplicao;
O ator cancela a operao corrente;
O ator pede ajuda;
O ator prov dados invlidos;
O ator prov dados incompletos;
O ator escolhe uma maneira alterna8va de realizar o
caso de uso;
O sistema falha;
O sistema est indisponvel.

Representao de cursos
Curso Normal:
Pargrafos;
Lista numerada (prefervel).
Cursos Alterna8vos:
Intercalados no curso normal como itens;
Intercalados no curso normal como pargrafos;
Em uma seo separada, de forma resumida;
Em uma seo separada, de forma detalhada
(semelhante ao curso normal).

Descrio de caso de uso exemplo
Projeto: RecMed
Subsistema: controleRecomendacaoMedicao
IdenDcador do Caso de Uso: UC10
Caso de Uso: Registrar o Uso de Recomendao
Descrio Sucinta: Este caso de uso permite o registro
de informaes sobre os resultados ob8dos com a
u8lizao das recomendaes.
A documentao completa deste sistema pode ser vista em

https://www.dropbox.com/sh/vud44xbrwz91xkf/X7_4sQnpYG,
pasta Exemplo TCC e Documentao Software, arquivo RecMed -
Documento_Especificacao_Requisitos_v1.0.docx

Descrio de caso de uso exemplo (cont.)
Fluxos de Eventos Normais:
Fluxo Pr- Descrio
condio
Registrar Nenhuma 1. O usurio informa a recomendao para a qual
o uso de deseja registrar os resultados de utilizao;
uma 2. O usurio registra informaes sobre os
recomen- resultados obtidos com a utilizao da
dao recomendao;
3. O usurio informa o contexto em que a
recomendao foi utilizada (nmero de projetos e
caractersticas dos projetos);
4. O usurio indica se o resultado obtido com o uso
da recomendao foi satisfatrio;
5. O usurio avalia a recomendao, registrando
sua opinio sobre ela (indica se a recomendao
tima, boa, regular, ruim ou pssima);
6. O registro de utilizao armazenado e
associado recomendao selecionada pelo
usurio no passo 1.
Fluxo Pr- Descrio
condio
Registrar Nenhuma 1. O u s u r i o i n f o r m a o a s p e c t o ( c o n j u n t o d e
o uso das recomendaes) para o qual deseja registrar resultados
recomen de uso;
2. As recomendaes presentes no aspecto informado so
daes
apresentadas para o usurio;
relaciona 3. O usurio registra informaes sobre os resultados
das a um obtidos com a utilizao das recomendaes do
aspecto aspecto;
4. O u s u r i o i n f o r m a o c o n t e x t o e m q u e a s
recomendaes foram utilizadas (nmero de projetos e
caractersticas dos projetos);
5. O usurio indica se o resultado obtido com o uso das
recomendaes presentes no aspecto foi satisfatrio;
6. O usurio avalia o aspecto, registrando sua opinio
sobre as recomendaes presentes nele (indica se so
timas, boas, regulares, ruins ou pssimas);
7. O registro de utilizao armazenado e associado a
todas as recomendaes presentes no aspecto
selecionado pelo usurio no passo 1.

Fluxos de Exceo:
Nome do fluxo Exceo Descrio
normal
relacionado
Registrar o uso 6. Dados invlidos (os dados 6.a Uma mensagem de
de uma fornecidos nos passos 2, 3, erro exibida solicitando
recomendao 4 ou 5 so invlidos ou no ao usurio a correo dos
foram informados) dados.
Registrar o uso 7. Dados invlidos (os dados 7.a Uma mensagem de
das fornecidos nos passos 3, 4, erro exibida solicitando
recomendaes 5 ou 6 so invlidos ou no ao usurio a correo dos
relacionadas a foram informados) dados.
um aspecto

Cenrios
Podemos agrupar casos de uso pequenos e similares
num nico caso de uso;
Neste caso, temos um caso de uso e vrios cenrios;
Ex.: Cadastrar Cliente = Incluir + Consultar + Alterar +
Excluir Cliente;
O exemplo anterior agrupou 2 cenrios: Registrar o
uso de uma recomendao e Registrar o uso das
recomendaes relacionadas a um aspecto;
Agrupar ou no deciso do analista;
Levar em considerao legibilidade e organizao.

Casos de uso cadastrais
Os casos de uso cadastrais (IACE: Incluir, Alterar,
Consultar e Excluir) so muito comuns e similares;
Pode-se fazer uma descrio tabular:
Iden8cador;
Caso de uso;
Aes possveis (I, A, C, E);
Observaes (dados a informar, restries de
integridade, uxos alterna8vos);
Possveis classes relacionadas.

Casos de uso cadastrais exemplo
Id. UC Aes Observaes Classes
UC Cadas- I, A, [I] Informar: nome, cdigo e descrio; Grupo,
01 trar C, E [E]: Grupos que possuem aspectos Aspecto
grupo associados no podem ser excludos;
[A]: Caso o grupo esteja associado a
um aspecto, exibida uma mensagem
informando isso ao especialista e
solicitada a confirmao da alterao.
UC Cadas- I, A, [I]: Informar: nome, grupo ao qual Grupo,
02 trar C, E pertence, propsito e fundamentao Aspecto,
aspecto terica; Recome
[E]: Aspectos que possuem ndacaoM
recomendaes associadas no podem edicao
ser excludos;
[A]: Caso o aspecto esteja associado a
uma recomendao, exibida uma
mensagem informando isso ao
especialista e solicitada a confirmao
da alterao.

Associaes entre casos de uso
Existem trs 8pos de associaes que podem ser
detectadas medida que os diagramas de casos de uso
so renados:
Relao de especializao (herana);
Relao de incluso;
Relao de extenso.

Relao de generalizao
Um caso de uso lho herda o comportamento e o
signicado do caso de uso pai;
Acrescenta ou sobrescreve comportamento do pai e
pode subs8tuir o pai em qualquer lugar que este
aparea.

Relao de incluso
Um caso de uso incorpora explicitamente o
comportamento de outro;
Funcionalidade comum separada em um caso que
reu8lizado por outros.

Relao de incluso (UML 2.1 spec.)
Uma relao de incluso entre dois casos de uso (UCs)
signica que o comportamento denido no UC includo
adicionado ao comportamento do UC base;
A relao de incluso foi feita para ser usada quando
existem partes comuns do comportamento de dois ou
mais UCs;
Esta parte comum ento extrada e descrita em um
UC separado, a ser includo por todos os UC base que
possuam esta parte em comum.

Relao de extenso
Um caso de uso base incorpora implicitamente o
comportamento de um outro caso de uso em um local
especicado;
Permite capturar os requisitos funcionais de um sistema
de forma incremental.

Relao de extenso (UML 2.1 spec.)
Especica que o comportamento de um caso de uso (UC)
pode ser estendido pelo comportamento de outro UC (de
maneira geral, suplementar);
A extenso se d em um ou mais pontos de extenso
especcos denidos no UC estendido;
O UC estendido denido independente do UC extensor.
Ele possui signicado independentemente;
Por outro lado, o UC extensor 8picamente dene
comportamento que no necessariamente possui sen8do
sozinho;
Ao invs, o UC extensor dene um conjunto de
comportamentos modulares que incrementam e melhoram
a execuo do UC estendido em condies especcas.

Incluso x extenso
Extenso: quando es8ver descrevendo uma variao de
um curso normal, comportamento opcional;
Incluso: quando houver repe8o de um mesmo uxo
em dois ou mais casos de uso e se quer evitar isso.

Separao em subsistemas
Facilita o entendimento e a leitura;
U8liza-se o cone de pacote da UML;
Setas pon8lhadas indicam dependncia um pacote
solicita servios de outro (incluso, extenso, etc.).

FES
tamento
Par8cipao dos atores nos subsistemas
ormtica Especificao de Re
Diagrama de Casos de Uso do Sistema

Ferramenta CASE
Uma ferramenta CASE auxilia no desenho de diagramas
de caso de uso;
Vrias disponveis:
Astah community (hOp://astah.net/edi8ons/
community) nossa sugesto;
Visual Paradigm (hOp://www.visual-paradigm.com);
Magic Draw (hOp://www.nomagic.com/products/
magicdraw.html);
Papyrus (hOp://www.eclipse.org/papyrus/);
Dentre outras...

Padro de nomenclatura
Verique o padro de nomenclatura antes de comear:
Atores;
Casos de uso;
Pacotes;
Descrio do caso de uso.
Para a descrio, use o modelo.

Exerccio
A par8r de modelos de obje8vos de nvel t8co (u8lize
o projeto Pizza a Pezzi ou seu trabalho pr8co), produza
diagramas de caso de uso, iden8cando:
Atores;
Casos de uso (UCs);
Relaes ator x UC, UC x UC;
Para os UCs cadastrais, iden8que as aes possveis
e as restries de integridade associadas.

hJp://nemo.inf.ufes.br/

Academia BR Bdep Requisitos

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Academia BR Bdep Requisitos

Diunggah oleh

Hak Cipta:

Format Tersedia

Banco de Dados

Vtor E. Silva Souza

Mais informaes podem ser encontradas em:

Maio 2014 Banco de Dados - Anlise de Requisitos 3

Toda solicitao de emprs-

Descrio da Processo de check-out de

Maio 2014 Banco de Dados - Anlise de Requisitos 4

Coisas que o sistema Coisas Coisas internas

Maio 2014 Banco de Dados - Anlise de Requisitos 7

Maio 2014 Banco de Dados - Anlise de Requisitos 9

Maio 2014 Banco de Dados - Anlise de Requisitos 10

Neste curso veremos apenas uma parte da

Maio 2014 Banco de Dados - Anlise de Requisitos 11

Maio 2014 Banco de Dados - Anlise de Requisitos 12

Maio 2014 Banco de Dados - Anlise de Requisitos 13

Maio 2014 Banco de Dados - Anlise de Requisitos 14

Maio 2014 Banco de Dados - Anlise de Requisitos 15

Maio 2014 Banco de Dados - Anlise de Requisitos 16

Maio 2014 Banco de Dados - Anlise de Requisitos 17

Maio 2014 Banco de Dados - Anlise de Requisitos 18

Maio 2014 Banco de Dados - Anlise de Requisitos 19

Maio 2014 Banco de Dados - Anlise de Requisitos 20

Maio 2014 Banco de Dados - Anlise de Requisitos 21

Maio 2014 Banco de Dados - Anlise de Requisitos 22

Coloque trs stakeholders numa sala e

Maio 2014 Banco de Dados - Anlise de Requisitos 23

Maio 2014 Banco de Dados - Anlise de Requisitos 24

Maio 2014 Banco de Dados - Anlise de Requisitos 25

Maio 2014 Banco de Dados - Anlise de Requisitos 26

Maio 2014 Banco de Dados - Anlise de Requisitos 27

Maio 2014 Banco de Dados - Anlise de Requisitos 28

Elementos so No baseada em Baseada em

Maio 2014 Banco de Dados - Anlise de Requisitos 29

Maio 2014 Banco de Dados - Anlise de Requisitos 30

Maio 2014 Banco de Dados - Anlise de Requisitos 31

Maio 2014 Banco de Dados - Anlise de Requisitos 32

Maio 2014 Banco de Dados - Anlise de Requisitos 33

Maio 2014 Banco de Dados - Anlise de Requisitos 34

Maio 2014 Banco de Dados - Anlise de Requisitos 35

Maio 2014 Banco de Dados - Anlise de Requisitos 36

Maio 2014 Banco de Dados - Anlise de Requisitos 38

Maio 2014 Banco de Dados - Anlise de Requisitos 39

Maio 2014 Banco de Dados - Anlise de Requisitos 40

Maio 2014 Banco de Dados - Anlise de Requisitos 41

Maio 2014 Banco de Dados - Anlise de Requisitos 42

Maio 2014 Banco de Dados - Anlise de Requisitos 43

Maio 2014 Banco de Dados - Anlise de Requisitos 44

Tempo gasto para responder Alto Baixo

Natureza exploratria Alta Baixa

Facilidade de preparao Fcil Difcil

Facilidade de anlise Difcil Fcil

Questes subjetivas: cuidado com respostas muito amplas,

Maio 2014 Banco de Dados - Anlise de Requisitos 46

Maio 2014 Banco de Dados - Anlise de Requisitos 47

Prottipos devem ser construdos rapidamente, enfatizando a interface

Maio 2014 Banco de Dados - Anlise de Requisitos 49

Cenas dos prximos captulos...

Maio 2014 Banco de Dados - Anlise de Requisitos 50

Maio 2014 Banco de Dados - Anlise de Requisitos 51

Maio 2014 Banco de Dados - Anlise de Requisitos 52

Maio 2014 Banco de Dados - Anlise de Requisitos 53

Maio 2014 Banco de Dados - Anlise de Requisitos 54

A anlise de factibilidade ajuda