Engenharia de Software II - Apostila

Faculdade de ecnologia de Praia Grande
ENGENHARIA DE SOFTWARE II
Simone Maria Viana Romano
Se eu tivesse oito horas para derrubar

uma rvore, passaria seis afiando
meu machado (Abraham Lincoln).
2 SEMESTRE DE 2013
ENGENHARIA DE SOFTWARE
Sumrio
INFORMAES IMPORTANTES .................................................................................................................... 7
OBJETIVOS: .................................................................................................................................................. 7
Sugesto de Livros, Revistas e Sites ............................................................................................................... 7
Softwares ......................................................................................................................................................... 7
Quantidade de aulas semanais e Quantidade de faltas permitidas ............................................................... 7
Abono de Faltas .............................................................................................................................................. 8
Contato ............................................................................................................................................................ 8
Avisos .............................................................................................................................................................. 8
Contedo das Avaliaes ................................................................................................................................ 8
Forma de Avaliao........................................................................................................................................ 8
Disciplinas, Dias e Horrios que me encontro na Fatec ............................................................................... 8
Erros da Apostila: ........................................................................................................................................... 8
TRABALHO SEMESTRAL................................................................................................................................. 9
TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5) ........................................... 10
DESENVOLVIMENTODESOFTWARE.................................................................................................. 14
1BIMESTRE
REQUISITOSDESOFTWARE................................................................................................................................... 16
IMPORTNCIA DOS REQUISITOS............................................................................................................... 17
QUALIDADE DOS REQUISITOS ................................................................................................................... 18
TIPOS DE REQUISITOS .................................................................................................................................. 19
EXEMPLO DE REQUISITOS FUNCIONAIS ............................................................................................... 20
EXEMPLO DE REQUISITOS NO FUNCIONAIS ...................................................................................... 20
EXEMPLO DE REQUISITOS DE DOMINIO ............................................................................................... 20
PROBLEMAS COMUNS NOS REQUISITOS ............................................................................................... 20
CLASSES DE REQUISITOS .......................................................................................................................... 20
ENGENHARIADEREQUISITOS............................................................................................................................... 21
OBJETIVOS DA ENGENHARIA DE REQUISITOS ...................................................................................... 22
TAREFA 02 - QUESTES DE REQUISITOS (0,5) ...................................................................................... 23
ELICITAODEREQUISITOS................................................................................................................................. 26
OBJETIVOS DA ELICITAO DE REQUISITOS ........................................................................................ 28
PASSOS PARA A ELICITAO DE REQUISITOS....................................................................................... 28
QUESTES QUE PRECISAM SER RESPONDIDAS ..................................................................................... 29
DOCUMENTAO DO ELICITAO DE REQUISITOS ............................................................................ 29
IDENTIFICAO E ELICITAO DE REQUISITOS .................................................................................. 30
IDENTIFICAO DOS REQUISITOS ......................................................................................................... 30
PROBLEMAS NA IDENTIFICAO DOS REQUISITOS ............................................................................ 31
EXEMPLO DE DECLARAO DO PROBLEMA ........................................................................................ 31
CARACTERSTICAS DA ELICITAO DE REQUISITOS.......................................................................... 31
DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS ......................................... 32
TAREFA 03 ELICITAO DE REQUISITOS (0,5) ................................................................................... 33
TCNICAS PARA ELICITAO DE REQUISITOS ................................................................................... 34
ETNOGRAFIA ................................................................................................................................................. 36
ENTREVISTAS ................................................................................................................................................ 37
Etapas ............................................................................................................................................................ 37
Forma de Entrevistar .................................................................................................................................... 37
Perguntas que devem ser respondidas .......................................................................................................... 37
BRAINSTORMING .......................................................................................................................................... 38
BRAINSWRITING ........................................................................................................................................... 39
EXERCCIOS ................................................................................................................................................ 40
JAD ....................................................................................................................................................................... 41
ETAPAS PARA PREPARAR UMA REUNIO JAD..................................................................................................... 41

PREPARAO .............................................................................................................................................. 42
SESSO ......................................................................................................................................................... 46
REVISO ....................................................................................................................................................... 51
PAPEIS DE CADA UM DENTRO DA REUNIO .......................................................................................... 52
O CLIENTE (PATROCINADOR) .................................................................................................................. 52
ENGENHEIRO DE SOFTWARE ................................................................................................................... 52
EQUIPE ........................................................................................................................................................ 53
OBSERVADOR .............................................................................................................................................. 53
DOCUMENTADOR ...................................................................................................................................... 53
LDER DE SESSO OU FACILITADOR ...................................................................................................... 53
FIGURINHAS DIFCIEIS NA REUNIO ..................................................................................................... 54
TAREFA 04 TECNICA JAD (1,0)............................................................................................................... 57
ESPECIFICAO DE REQUISITOS .............................................................................................................. 58
MODELO DE ESPECIFICAO DE REQUISITOS ...................................................................................................... 58
PASSOS PARA ESPECIFICAR OS REQUISITOS ........................................................................................ 58
VISO E ESCOPO ................................................................................................................................................. 60
EXERCCIOS ................................................................................................................................................ 60
TAREFA 05 ESPECIFICAO DE REQUISITOS (0,5) ........................................................................... 61
VERIFICAO E VALIDAO DE REQUISITOS ..................................................................................... 62
TIPOS DE DEFEITO ........................................................................................................................................ 63
OMISSO ...................................................................................................................................................... 64
AMBIGUIDADE ............................................................................................................................................ 64
INCONSISTNCIA ........................................................................................................................................ 64
FATO INCORRETO ...................................................................................................................................... 64
INFORMAO ESTRANHA ......................................................................................................................... 64
DOCUMENTO DE REQUISITOS .............................................................................................................................. 64
DEFEITOS NO DOCUMENTO DE REQUISITOS....................................................................................... 65
CONSEQUENCIAS ....................................................................................................................................... 65
PEQUENO CHECKLIST DE REQUISITOS..................................................................................................... 65
TCNICAS DE VALIDAO DE REQUISITOS ........................................................................................... 65
REVISO DE REQUISITOS ......................................................................................................................... 65
REVISES DE SOFTWARE ............................................................................................................................ 66
TIPOS DE REVISO DE SOFTWARE .......................................................................................................... 66
PROCESSO DE INSPEO DE SOFTWARE .............................................................................................. 67
PROCESSO TRADICIONAL DE INSPEO ............................................................................................... 68
GERENCIAMENTO DE MUDANA DE REQUISITOS .............................................................................. 69
EVOLUO DOS REQUISITOS .................................................................................................................... 71
REQUISITOS PERMANENTES E VOLTEIS............................................................................................... 71
CLASSIFICAO DOS REQUISITOS.......................................................................................................... 71
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ................................................................... 72
RASTREABILIDADE ..................................................................................................................................... 72
SUPORTE FERRAMENTA: ....................................................................................................................... 72
ETAPAS PARA O RASTREAMENTO ............................................................................................................ 73
EXERCCIOS ................................................................................................................................................ 74
MATRIZ DE RASTREABILIDADE ................................................................................................................ 76
RASTREABILIDADE ...................................................................................................................................... 76
OBJETIVOS................................................................................................................................................... 76
MATRIZ DE RASTREABILIDADE DEFINIDAS ........................................................................................................ 78
EXERCCIOS ................................................................................................................................................ 79
ORIENTAO A OBJETOS ............................................................................................................................ 80
HISTRIA ........................................................................................................................................................ 80
CONCEITOS FUNDAMENTAIS ............................................................................................................................... 81
OBJETO ........................................................................................................................................................ 82
ATRIBUTO .................................................................................................................................................... 83
OPERAO X MTODO ............................................................................................................................. 83

CLASSE ......................................................................................................................................................... 84
ESTADO ........................................................................................................................................................ 84
MENSAGEM ................................................................................................................................................. 84
ENCAPSULAMENTO ................................................................................................................................... 84
HERANA ..................................................................................................................................................... 85
POLIMORFISMO ......................................................................................................................................... 86
ANLISE ORIENTADA A OBJETOS ............................................................................................................ 87
EXERCCIOS ................................................................................................................................................ 88
2 BIMESTRE UML ...................................................................................................................................... 91
HISTRIA ............................................................................................................................................................ 91
CONCEITO ....................................................................................................................................................... 92
UTILIZAO ................................................................................................................................................... 93
NOTAO ....................................................................................................................................................... 94
VANTAGENS ....................................................................................................................................................... 94
FASES DO DESENVOLVIMENTO UML ....................................................................................................... 94
COMPONENTES DA UML ...................................................................................................................................... 95
MODELOS DE ELEMENTOS ......................................................................................................................... 95
CLASSES ....................................................................................................................................................... 95
OBJETOS ...................................................................................................................................................... 95
ESTADOS ...................................................................................................................................................... 96
PACOTES ...................................................................................................................................................... 96
COMPONENTES .......................................................................................................................................... 96
RELACIONAMENTOS .................................................................................................................................. 97
MECANISMOS GERAIS ............................................................................................................................. 101
DIAGRAMAS ..................................................................................................................................................... 101
DIAGRAMAS ESTRUTURAIS (ESTTICOS) ............................................................................................. 101
DIAGRAMAS COMPORTAMENTAIS (DINMICOS) ............................................................................... 102
EXERCCIOS .............................................................................................................................................. 103
DIA PORTABLE ............................................................................................................................................... 105
MICROSOFT VISIO 2003 ............................................................................................................................... 107
DIAGRAMA DE MODELO UML ............................................................................................................................ 107
ATIVIDADE DE UML ................................................................................................................................. 108

COLABORAO DE UML ......................................................................................................................... 108
COMPONENTE UML ................................................................................................................................. 109
IMPLANTAO DE UML .......................................................................................................................... 109
SEQUNCIA DE UML ................................................................................................................................ 109
GRFICO DE ESTADO DE UML .............................................................................................................. 109
ESTRUTURA ESTTICA DE UML ............................................................................................................. 110
CASO DE USO ............................................................................................................................................ 110
PROPRIEDADES DA FORMA ...................................................................................................................... 110
OBSERVAES .......................................................................................................................................... 111
DIAGRAMA DE CASO DE USO .................................................................................................................... 112
CASOS DE USO ............................................................................................................................................. 112
ATOR ................................................................................................................................................................ 113
COMO IDENTIFICAR OS ATORES ........................................................................................................... 113
CASO DE USO .................................................................................................................................................... 113
COMO IDENTIFICAR CASOS DE USO .................................................................................................... 114
CENRIO ....................................................................................................................................................... 114
RELACIONAMENTO DE EXTENSO ................................................................................................................ 114
RELACIONAMENTO DE INCLUSO ................................................................................................................. 115
RELACIONAMENTO DE ESPECIALIZAO .................................................................................................... 115
RELACIONAMENTO ENTRE CASOS DE USO ......................................................................................... 115
EXEMPLO: ESTUDO DE CASO LOCADORA DE VECULOS ............................................................. 117
ANLISE DE CASOS DE USO ..................................................................................................................... 118
EXERCCIOS .............................................................................................................................................. 118
TAREFA 06 DIAGRAMA DE CASO DE USO (1,0) ................................................................................. 123
DIAGRAMA DE CLASSES ............................................................................................................................. 124

CLASSE .......................................................................................................................................................... 124
CONVENES ........................................................................................................................................... 125
ATRIBUTOS................................................................................................................................................... 125
OPERAES .................................................................................................................................................. 125
VISIBILIDADE .................................................................................................................................................... 125
RELACIONAMENTOS.................................................................................................................................. 125
ASSOCIAO ............................................................................................................................................. 126
AGREGAO ............................................................................................................................................. 126
COMPOSIO ........................................................................................................................................... 127
CLASSE DE ASSOCIAO ........................................................................................................................ 127
HERANA ................................................................................................................................................... 128
DIAGRAMA DE CLASSE ............................................................................................................................. 129
COMO FAZER UM DIAGRAMA DE CLASSES ......................................................................................... 130
IDENTIFICANDO AS CLASSES ................................................................................................................. 130
IDENTIFICANDO OS ATRIBUTOS ........................................................................................................... 131
IDENTIFICANDO O COMPORTAMENTO ............................................................................................... 131
IDENTIFICANDO GENERALIZAES ..................................................................................................... 131
IDENTIFICANDO ASSOCIAO .............................................................................................................. 131
EXEMPLO ESTUDO DE CASO: LOCADORA DE VECULOS ............................................................. 131
EXERCCIOS .............................................................................................................................................. 132
DIAGRAMA DE OBJETOS ............................................................................................................................ 136
EXERCCIOS ................................................................................................................................................. 137
TAREFA 07 DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0) .......................................... 138
DIAGRAMA DE SEQUENCIAS ..................................................................................................................... 139
EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAO INTERNA .................................... 142
EXERCCIOS .............................................................................................................................................. 147
TAREFA 8 DIAGRAMA DE SEQUENCIAS (1,0) .................................................................................... 148
ANEXO - SOLUES PARA PROBLEMAS NA ENGENHARIA DE REQUISITOS ............................ 150
ELICITAO DE REQUISITOS ................................................................................................................... 151
PROBLEMAS .............................................................................................................................................. 151
DESAFIOS................................................................................................................................................... 151
PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS .............................................................. 152
PROBLEMA: POLTICA NA ORGANIZAO .......................................................................................... 152
PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAO DOS REQUISITOS DE ALTO NVEL
DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS FUNCIONAIS E NO
FUNCIONAIS. ............................................................................................................................................. 152
PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO SISTEMA DOS
SEUS REQUISITOS .................................................................................................................................... 152
CASOS DE USO .................................................................................................................................................. 153
PROBLEMA: DIFICULDADE NA DESCRIO DE REQUISITOS FUNCIONAIS E NO-FUNCIONAIS.
..................................................................................................................................................................... 153
PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA DEFINIO DA
SOLUO ................................................................................................................................................... 153
PROBLEMA: DETALHAMENTO TCNICO DESNECESSRIO DURANTE A ESPECIFICAO
FUNCIONAL DO SISTEMA. ...................................................................................................................... 154
GERNCIA DE REQUISITOS ................................................................................................................................ 154
PROBLEMA: DIFICULDADES DE ESTABELECER UMA ESTRATGIA PARA A ATUALIZAO E
REUTILIZAO DE CASOS DE USO ....................................................................................................... 154
PROBLEMA: REPRESENTAR A ATUALIZAO DE CASOS DE USO ................................................... 154
PROBLEMA: DIFICULDADE DE INTEGRAO DAS PRTICAS DE GERNCIA DE REQUISITOS
COM GERNCIA DE CONFIGURAO. ................................................................................................. 155
PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS
EM MANUTENO. ................................................................................................................................... 155
PROBLEMA: DIFICULDADE DE IMPLANTAO E MANUTENO DA RASTREABILIDADE DOS
REQUISITOS............................................................................................................................................... 155
PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS

REQUISITOS............................................................................................................................................... 155
INFORMAES IMPORTANTES
OBJETIVOS:
Aplicar um processo de desenvolvimento de software, nfase na definio e
elicitao dos requisitos:
Apresentar e discutir o Ciclo de Requisitos de Software: Identificao,
Elicitao, Anlise, Especificao e Validao;
Apresentar e discutir as atividades de Identificao e elicitao de requisitos;
Apresentar e discutir as atividades da anlise de requisitos de software;
Apresentar as principais tcnicas para especificao de requisitos de software;
Apresentar as principais tcnicas para validao de requisitos de software;
Apresentar as principais tcnicas para processo de gerenciamento de
mudana de requisitos de software.
EMENTA:
Contexto atual das empresas em relao aos projetos de tecnologia de
informao. Modelagem de Negcio para o desenvolvimento de software.
Conceitos, evoluo e importncia da Engenharia de Requisitos. Entendendo e
analisando os problemas e as necessidades dos usurios, clientes e
envolvidos no projeto. Tcnicas de elicitao. Requisitos, seus tipos e matriz
de rastreabilidade. Definio do sistema a partir dos requisitos.
Gerenciamento de requisitos
Sugesto de Livros, Revistas e Sites
ENGENHARIA DE SOFTWARE Fundamentos, Mtodos e Padres 3 Edio
Editora GEN LTC Autor: Wilson de Pdua Paula Filho 2010;
ESPECIFICAO DE SISTEMAS DE SOFTWARE UTILIZANDO ANALISE E
PROJETO ESTRUTURADOS Editora UNICAMP Autor: Thelma C. dos Santos
Chiossi e Regina Lcia O. Moraes 2006;
ENGENHARIA DE SOFTWARE 6 Edio Editora MH - MCGRAW
HILL/NACIONAL Autor: Roger S. Pressman 2006;
AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements,
Springer-Verlag, 2005.
REVISTAS E SITES:
Revista Engenharia de Software: www.devmedia.com.br;
http://engenhariadesoftware.blogspot.com/;
http://www.sigsoft.org/;
http://rildosan.blogspot.com/;
http://www.yuml.me;
http://www.wthreex.com/rup/;
http://www.engenharia-software.com
http://www.facebook.com/connect/uiserver.php?app_id=318148321616976&
method=permissions.request&redirect_uri=http%3A%2F%2Fapps.facebook.c
om%2Fpromonlogicalisestag%2F%3Ffb_source%3Dsearch%26ref%3Dts%26f
ref%3Dts&response_type=none&display=page&auth_referral=1
Softwares
Dia Portable, Visio (Fatec), Word.
Mquina Virtual na Fatec : Engenharia de Software.

Quantidade de aulas semanais e Quantidade de faltas permitidas
Quatro (4) aulas semanais e poder ter vinte (20) faltas no semestre.
Abono de Faltas
Abono de faltas somente com atestado mdico.
No final do semestre, no caso do aluno ter nota e ter entregue no mnimo
70% das atividades poder eliminar as faltas em excesso da seguinte forma:
para cada 2 horas/aula excedida dever ser entregue manuscrito um relatrio
de apresentao de TCC (DEIXAR NA SECRETARIA).
Contato
Email: simone_viana@yahoo.com.br e/ou simone@fatecpg.com.br
Obs. O email: simonemviana@gmail.com usado somente para envio
de formulrios no Google Docs no h acesso da caixa postal.
TODOS OS EMAILS ENVIADOS PELO YAHOO OU PELO FATECPG SERO
RESPONDIDOS EM UM PRAZO DE 48 HORAS. CASO NO HAJA RESPOSTA,
FAVOR ENVIAR NOVAMENTE.
Solicito que todos deixem o email atualizado na secretaria da Fatec
pois por este email que consta no seu cadastro que eu entro em
contato, avisando faltas, reposies, assuntos gerais, etc.
Avisos
Na pgina de ENGENHARIA DE SOFTWARE sempre ter avisos pertinentes ao
contedo da disciplina.
Contedo das Avaliaes
Sempre o contedo das avaliaes ser o apresentado at uma semana antes
das provas bimestrais, podendo ter eventualmente uma reviso antes da
avaliao.
Forma de Avaliao
Haver duas provas bimestrais que podero ser dissertativas ou objetivas
com valor de 10,0 pontos;
Haver tarefas avaliativas em sala de aula que pode ter valor at 3,0 pontos
que sero acrescidos a nota do bimestre;
Estas tarefas podero ser feitas em laboratrio, em casa com data de entrega
estipulada ou em sala de aula, realizadas em grupo ou individualmente,
participao em sala de aula, relatrios a partir de vdeos assistidos, estudos
de casos, entre outros.
ATENO!!!! CASO O ALUNO FALTE INDEPENDENTE DE TER
ATESTADO OU TER ATESTADO NO SER ACEITO A TAREFA POIS O
MESMO NO ASSISTIU A AULA.
Disciplinas, Dias e Horrios que me encontro na Fatec
Engenharia de Software II quinta-feira (13h10 as 16h40);
quarta-feira (19h as 22h30);
Banco de Dados quarta-feira (13h10 as 16h40);
quinta-feira (19h as 22h30);
Laboratrio de Banco de Dados quarta e quinta-feira (16h50 as 18h30)
Sbado (8h as 11h30).
Erros da Apostila:
Caso seja encontrado erro na apostila, favor enviar por email.
Obrigada!
TRABALHO SEMESTRAL
O trabalho semestral dever ser entregue na ltima aula

do segundo semestre (antes da prova de avaliao do
segundo bimestre) e dever ter:
Capa contendo o nome dos alunos (mximo 5), o ciclo e o
perodo;
Estudo de caso descritivo;
Agenda da reunio JAD;
Ata contendo o resultado da reunio JAD;
Especificao de Requisitos (mnimo 4);
Diagrama de Caso de Uso (contendo todo o projeto);
Diagrama de Classes (contendo todo o projeto);
Diagrama de Objetos (com base no diagrama de classes);
Diagrama de Sequncia (de um caso de uso).
Obs. Poder ser feito manuscrito ou utilizando um software e
no necessrio entregar encadernado.
Aviso: eu sou cliente.

Portanto quero ver o
trabalho pronto e no tiro
dvidas do mesmo.
Bom Trabalho!!!!
10
TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)
1.
a)
b)
c)
d)
e)
Segundo a IEEE Computer Society, a engenharia de software a

aplicao de uma abordagem sistemtica, disciplinada e quantificvel
ao desenvolvimento, operao e manuteno de software, isto ,
a aplicao da engenharia ao software. Acerca dos princpios da
engenharia de software, assinale a opo correta. (CESPE - 2010 SAD-PE - Analista de Controle Interno Tecnologia da Informao)
A engenharia de requisitos de um software, em geral, precede a
engenharia dos requisitos do sistema de informaes no qual o
software ser usado.
A manuteno de software uma atividade da engenharia de
software que necessita do emprego de recursos que drenam cerca de
50% do investimento total em um software durante todo o seu ciclo
de vida.
A gerncia de configurao de software uma atividade que envolve
o emprego de conceitos e prticas, tais como identificao de itens de
configurao, controle, contabilizao e auditoria.
desejvel que o valor da coeso e o do acoplamento, duas
importantes propriedades da arquitetura de um software, sejam
maximizados durante a engenharia de software.
Em ferramentas CASE, como refactoring, melhor adotar-se uma
abordagem formal que uma abordagem heurstica.
2. Um requisito de software expressa as necessidades e restries

colocadas em um produto de software que contribuem para a soluo
de algum problema do mundo real. Acerca desse assunto, assinale a
opo correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno
Tecnologia da Informao)
a) Os contratantes ou clientes so os principais colaboradores
envolvidos no fornecimento de informaes para o processo de
levantamento ou elicitao de requisitos de software, os demais
grupos de pessoas que podem fornecer informaes so
considerados de importncia secundria.
b) As necessidades dos usurios a serem atendidas por um produto
de software constituem a classe de requisitos funcionais, e as
restries mencionadas na definio de requisitos constituem a
classe de requisitos no funcionais.
c) Entre as fontes de informao para a elicitao de requisitos,
destacam-se, alm dos colaboradores, o conhecimento do domnio
de aplicao em que o software funcionar, o ambiente operacional
do software e o ambiente organizacional.
d) A negociao de requisitos, de forma similar observao do
ambiente organizacional, uma atividade tpica da fase de
elicitao de requisitos.
e) A tcnica de casos de uso, empregada em alguns modelos de
desenvolvimento de software atuais, mais aderente construo
11
de cenrios durante a construo de prottipos que durante a

3. O conjunto de atividades e resultados associados que resulta em um
produto de software recebe o nome de (UFG - 2010 - UFG - Analista
de TI - Desenvolvimento de Sistemas):
a) engenharia de software.
b) processo de software.
c) especificao de software.
d) implantao de software.
4. Assim como a Engenharia de Software, existe tambm na rea de
informtica a chamada Cincia da Computao. Assinale a alternativa
que melhor apresenta a diferena entre Engenharia de Software e
Cincia da Computao. (FUNIVERSA - 2009 - IPHAN - Analista Tecnologia da Informao)
a) A Cincia da Computao tem como objetivo o desenvolvimento de
teorias e fundamentaes. J a Engenharia de Software se
preocupa com as prticas de desenvolvimento de software.
b) A Engenharia de Software trata da criao dos sistemas de
computao (softwares) enquanto a Cincia da Computao est
ligada ao desenvolvimento e criao de componentes de hardware.
c) A Engenharia de Software trata dos sistemas com base em
computadores, que inclui hardware e software, e a Cincia da
Computao trata apenas dos aspectos de desenvolvimento de
sistemas.
d) A Cincia da Computao trata dos sistemas com base em
computadores, que inclui hardware e software, e a Engenharia de
Software trata apenas dos aspectos de desenvolvimento de
sistemas.
e) A Cincia da Computao destina-se ao estudo e soluo para
problemas genricos das reas de rede e banco de dados e a
Engenharia de Software restringe- se ao desenvolvimento de
sistemas.
5. Para garantir o desenvolvimento de qualidade, suficiente que a
equipe tenha as ferramentas mais atuais de engenharia de software e
os melhores computadores. (CESPE - 2010 - BASA - Tcnico Cientfico Tecnologia da Informao - Arquitetura de Tecnologia)
_____ Certo
____ Errado
6. Sobre a engenharia de software, considere:
I. Atualmente todos os problemas na construo de software de alta
qualidade no prazo e dentro do oramento foram solucionados.
II. Ao longo dos ltimos 50 anos, o software evoluiu de um produto de
indstria para um ferramental especializado em soluo de
problemas e anlise de informaes especficas.
12
III. Todo projeto de software iniciado por alguma necessidade do

negcio.
IV. O intuito da engenharia de software fornecer uma estrutura para
a construo de software com alta qualidade. (FCC - 2010 - TRE-RS
- Analista Judicirio - Analista de Sistemas Suporte)
Est correto o que consta em
a) III e IV, somente.
b) II e III, somente.
c) I, II e IV, somente.
d) II, III e IV, somente.
e) I, II, III e IV.
7. De acordo com Pressman, a engenharia de software baseada em
camadas, com foco na qualidade: (FGV - 2010 - BADESC - Analista de
Sistemas - Desenvolvimento de Sistemas): Essas camadas so:
a) mtodos, processo e teste.
b) ferramentas, mtodos e processo.
c) mtodos, construo, teste e implantao.
d) planejamento, modelagem, construo, validao e implantao.
e) comunicao, planejamento, modelagem, construo e implantao.
8.
O objetivo da Engenharia de Software estabelecer uma sistemtica

abordagem de desenvolvimento, atravs de ferramentas e tcnicas
apropriadas, dependendo do problema a ser abordado, considerando
restries e recursos disponveis. A Engenharia de Software: (FCC 2008 - METR-SP - Analista Trainee - Cincias da Computao)
I. no se confunde com a Cincia da Computao, pois enquanto
esta visa o desenvolvimento de teorias e fundamentaes, a
Engenharia de Software se preocupa com as prticas de
desenvolvimento de software.
II. tem como foco nico o tratamento dos aspectos de
desenvolvimento de software, o que a diferencia da Engenharia
de Sistemas, que trata dos sistemas baseados em computadores,
incluindo hardware e software.
III. tem como mtodos as abordagens estruturadas para o
desenvolvimento de software que incluem os modelos de
software, notaes, regras e maneiras de desenvolvimento.
IV. segue princpios, tais como, o da Abstrao, que identifica os
aspectos importantes sem ignorar os detalhes e o da
Composio, que agrupa as atividades em um nico processo
para distribuio aos especialistas.
correto o que consta em:
a) I e II, apenas.
b) III e IV, apenas.
c) I, II e III, apenas.
d) II, III e IV, apenas.
e) I, II, III e IV.
13
9. No processo de engenharia de software, os requisitos funcionais podem

ser tambm definidos como requisitos de (FCC - 2008 - METR-SP Analista Trainee - Cincias da Computao):
a) qualidade.
b) capacidade.
c) segurana.
d) desempenho.
e) manuteno.
10. Analise as seguintes afirmaes relativas Engenharia de Software:
I. A anlise de requisitos responsvel pela especificao dos
requisitos de software e hardware que sero utilizados durante o
processo de desenvolvimento de um sistema.
II. A anlise de requisitos define a metodologia de programao a ser
utilizada no desenvolvimento do sistema.
III. A especificao de requisitos fornece ao desenvolvedor e ao cliente
os parmetros para avaliar a qualidade logo que o sistema for
construdo.
IV. A anlise de requisitos possibilita que o engenheiro de software
especifique a funo e o desempenho do sistema e estabelea
quais so as restries de projeto que o sistema deve atender.
Esto corretos os itens: (ESAF - 2004 - CGU - Analista de Finanas e
Controle - rea - Tecnologia da Informao - Prova 3):
a) I e II
b) II e III
c) III e IV
d) I e III
e) II e IV
14
1 BIMESTRE DESENVOLVIMENTO DE SOFTWARE

O que processo de software?
O que desenvolvimento de
software?
Processo de software um conjunto de atividades que objetivam o

desenvolvimento e a evoluo de software.
Principais atividades so:
ESPECIFICAO: define o que o sistema dever fazer, considerando
as suas restries.
DESENVOLVIMENTO: produo do software.
VALIDAO: checagem se o software faz o que o usurio deseja.
EVOLUO: mudanas no software para atender s novas
demandas.
O processo de engenharia de requisitos envolve criatividade,
interao de diferentes pessoas, conhecimento e experincia para
transformar informaes diversas (sobre a organizao, sobre leis, sobre o
sistema a ser construdo etc.) em documentos e modelos que direcionem
o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998).
Figura 1 Processo de Engenharia de Requisitos

(Fonte: adaptado de (KOTONYA;SOMMERVILLE, 1998))
J desenvolvimento de software um conjunto de atividades para

especificar, projetar, implementar e testar sistemas de software.
As atividades necessrias para o desenvolvimento de software so:
especificao, projeto, validao e evoluo.
15
Para o sucesso do desenvolvimento do software necessrio um

entendimento dos requisitos de software. No importa se foi bem
projetado e/ou codificado; se o software tiver tido uma anlise e uma
especificao mal feita, o usurio se sentir frustrado.
Anlise de requisitos um processo de descoberta, especificao,
modelagem e refinamento.
O analista de sistema ou engenheiro de software estabelece o
escopo1 do software e durante o planejamento do projeto de software vai
sendo refinado e seus detalhes sendo aperfeioados e atravs da criao
de diagramas, fluxos e modelos, o problema torna-se compreensvel.
O analista/engenheiro e o usurio possuem um papel ativo na anlise
e especificao de requisitos.
O cliente ou usurio tenta reformular um conceito de funo e
desempenho de software, sem detalhes concretos. J o analista, indaga,
consulta e soluciona os problemas.
Porm, a anlise e a especificao de requisitos parece ser uma tarefa
simples, mas no bem assim...
A comunicao um fator importante, pois as interpretaes erradas
e informaes falsas surgem a todo momento. A ambigidade provvel.
Podemos entender o dilema, repetindo 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...
ESCOPO
O QUE EST
SENDO
PROJETADO!!!!
ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e descrio

sumria do trabalho a ser realizado. feita na etapa de iniciao do projeto e detalhada
na etapa de planejamento. Descreve as caractersticas do produto e o trabalho
necessrio para realiz-lo. O consenso inicial sobre o escopo do projeto estabelecido
entre pessoas, organizaes ou departamentos de organizaes, sendo uma pessoa,
empresa, o cliente, o demandante do servio, o prestador de servios designado ou outra
pessoa, para faz-lo.
1
16
REQUISITOS DE SOFTWARE
Figura 2 Levantamento de Requisitos (Fonte: Web)
Segundo o IEEE, define requisitos de software como:

Uma condio ou uma capacidade de que o usurio
necessita para solucionar um problema ou alcanar um
objetivo;
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;
Uma representao documentada de uma condio ou
capacidade.
Outros conceitos de requisitos de software...

Requisitos de um sistema so descries dos servios que devem ser
fornecidos por esse sistema e as suas restries operacionais
(SOMMERVILLE, 2007);
Um requisito de um sistema uma caracterstica do sistema ou a
descrio de algo que o sistema capaz de realizar para atingir seus
objetivos (PFLEEGER, 2004);
17
Um requisito descrito como uma propriedade que o software deve

exibir para resolver algum problema no mundo real (SWEBOK, 2004);
Um requisito alguma coisa que o produto tem de fazer ou uma

qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON,
2006).
Existem em diversos nveis:
Figura 3 Requisitos (extrado da WEB)
IMPORTNCIA DOS REQUISITOS

Quanto mais cedo no ciclo de desenvolvimento do sistema se
descobre um erro, mais barato fica para acert-lo.
FASE
CUSTO DE ERRO
REQUISITO
1
ANLISE
5
PROJETO
10
IMPLEMENTAO
20
TESTE
50
MANUTENO
200
Figura 4 Custo dos erros nas fases
A dificuldade de descobrir erros na fase de requisitos est no fato

de neste momento da anlise, o analista est descobrindo o
funcionamento do negcio que ele desconhece, e ainda a relao
analista X usurio muito recente, fazendo com que a relao de
confiana ainda esteja em avaliao de ambas as partes. Ambiguidades
decorrentes de nossa linguagem, omisses e fatos incorretos, so as
principais causas.
O uso de inspees, validao dos requisitos atravs de encontros
sucessivos com o usurio, ajudam a minimizar estes problemas.
Pesquisa realizada na Standish Group com 350 companhias e
8.000 projetos diferentes, onde:
Sucesso quando cobre todas as funcionalidades em tempo e
dentro do custo;
18
Problemtico quando no cobre todas as funcionalidades

exigidas, custo maior e atraso;
Fracasso quando o projeto foi cancelado durante o
desenvolvimento.
Figura 5 Pesquisa de projetos
As causas podem ser:
Figura 6 Tipos de Fatores
Precisamos dos requisitos para entender o que o cliente quer, para

documentar o que o cliente quer e para assegurar a qualidade e a
satisfao do cliente. Tambm podemos entender o problema do
negcio, documentar o escopo do projeto e definir suas restries e
definir os critrios de aceitao e gerenciar as expectativas do cliente.
QUALIDADE DOS REQUISITOS

As qualidades desejveis para um requisito so:
Verificvel: Tem que existir uma maneira de verificar se o
produto contempla o requisito;
19
Priorizvel: Se todos os requisitos tm a mesma prioridade, h

algum problema, etc.;
Modificvel: As ideias sempre mudam, logo os requisitos
devem mudar tambm (Scott Ambler);
Inteligvel, Rastrevel, Completo, Claro (no ambguo).
TIPOS DE REQUISITOS
FUNCIONAIS: os requisitos funcionais descrevem o que o sistema

deve fazer, isto , as funes necessrias para atender os objetivos
do sistema. Exemplos: Cadastrar Clientes; Fazer Anlise de Crdito;
Fazer uma Transao com Banco de Dados; Cadastrar um Registro
de Atendimento; Imprimir Relatrio, etc.
Outras Definies:
o Segundo SOMMERVILLE (2007), so declaraes de servios que
o sistema deve prover, descrevendo o que o sistema deve fazer;
o PFLEEGER (2004), diz que um requisito funcional descreve uma
interao entre o sistema e o seu ambiente;
o Ainda em SOMMERVILLE (2007) seria como o sistema deve
reagir a entradas especficas, como o sistema deve se comportar
em situaes especficas e o que o sistema no deve fazer.
NO FUNCIONAIS (RNF ou Suplementares): Declaram as

caractersticas que o sistema deve possuir e que esto relacionadas
s suas funcionalidades. Com as caractersticas: performance,
portabilidade, segurana, usabilidade, qualidade do servio (QoS),
confidencialidade,
confiabilidade,
portabilidade,
preciso,
integridade, eficincia, entre outras. Estes tipos de requisitos so as
causas as principais insatisfaes dos usurios com relao ao
software.
o
Os requisitos no funcionais tm origem nas necessidades dos
usurios, em restries de oramento, em polticas
organizacionais, em necessidades de interoperabilidade com
outros sistemas de software ou hardware ou em fatores
externos como regulamentos e legislaes (SOMMERVILLE,
2007).
DOMNIO: muito relacionado as regras de negcio ou

comportamento prprio do sistema numa determinada aplicao ou
no contexto funcionando para uma empresa.
Outras Definies:
o
SOMMERVILLE (2007) diz que descrevem restries sobre os
servios ou funes oferecidos pelo sistema;
o
Ou ainda, as quais limitam as opes para criar uma soluo
para o problema (PFLEEGER, 2004);
20
EXEMPLO DE REQUISITOS FUNCIONAIS
O software deve permitir que o atendente consulte o relatrio com os

resultados dos testes clnicos de um paciente.
[RF01] O software deve permitir que o atendente efetue cadastro de
clientes;
[RF02] O software deve permitir que o caixa efetue o registro de itens
vendidos;
[RF03] O software deve permitir que o administrador gere o um
relatrio de vendas por ms.
EXEMPLO DE REQUISITOS NO FUNCIONAIS
CONFIABILIDADE: O sistema deve estar disponvel 99% das

vezes;
SEGURANA: dados devem ser protegidos;
DESEMPENHO: sistema deve processar x requisies por segundo;
CAPACIDADE: deve suportar x usurios concorrentemente.
EXEMPLO DE REQUISITOS DE DOMINIO
[RN1] os campos referente a oramento projeto vinculado s

estaro ativos se o tipo de projeto for vinculado;
[RN2] o campo valor total orado para o projeto calculado
somando-se os valores definidos para todas as rubricas includas no
oramento do projeto, seja ele vinculado ou no-vinculado.
[RN3] A soma dos percentuais a ser distribudo entre os fundos
includos no plano de aplicao deve ser entre 0 e 100%.
PROBLEMAS COMUNS NOS REQUISITOS
Nem sempre so bvios;

So originados de vrias fontes (=conflitos de interesse);
Nem sempre retratam um problema que possvel ser expressado
por palavras;
Sempre mudam;
Os usurios nem sempre sabem o que desejam;
Os usurios tm uma tendncia de privilegiar a sua rea ou o seu
ponto de vista;
Os analistas pensam que entendem os problemas melhor do que os
prprios usurios!
CLASSES DE REQUISITOS
Os requisitos podem ser vistos em trs classes distintas:

o Essenciais;
o Importantes;
o Desejveis.
Em princpio, sistema deve resolver todos os requisitos de
essenciais para requisitos desejveis.
21
RECORDANDO!!!!!
A especificao de um requisito
funcional deve determinar O QUE
o sistema deve fazer sem a
preocupao de COMO fazer.
ENGENHARIA DE REQUISITOS
A Engenharia de Requisitos o processo pelo qual os requisitos
de um produto de software so coletados, analisados, documentados e
gerenciados ao longo de todo o ciclo de vida do software (AURUM;
WOHLIN, 2005).
Pode ser descrita como o processo de descobrir, analisar,
documentar e verificar as funes e restries do sistema
(SOMMERVILLE, 2003).
Em resumo, podemos dizer que tratamento de requisitos envolve
atividades
de
desenvolvimento
(Levantamento,
Anlise
e
Documentao de Requisitos), gerncia (Gerncia de Requisitos) e
controle da qualidade (Verificao, Validao e Garantia da Qualidade
de Requisitos).
Figura 7 Etapas da Engenharia de Requisitos (Fonte: extrado da Web)
22
Ao conjunto de atividades relacionadas a requisitos, d-se o nome

de Processo de Engenharia de Requisitos.
Descreve as atividades relacionadas INVESTIGAO e
DEFINIO DE ESCOPO de um sistema. um processo sistemtico de
desenvolvimento de requisitos atravs de um processo cooperativo de
anlise onde os resultados das observaes so codificados em uma
variedade de formatos e as observaes so constantemente
verificadas.
Pode ser classificada em:
PRODUO:
levantamento,
registro,
comprometimento e verificao;
A produo de requisitos responsvel por:
Levantar Requisitos;
Registrar Requisitos;
Obter Comprometimento;
Verificar requisitos.
obteno
de
GERNCIA: controle de mudanas, gerncia de configurao,

rastreabilidade e gerncia da qualidade de requisitos.
A gerncia de requisitos responsvel por:
Controlar Mudanas;
Gerenciar Configurao;
Implementar Rastreabilidade;
Gerenciar Qualidade.
OBJETIVOS DA ENGENHARIA DE REQUISITOS

Estabelecer uma viso comum entre o cliente e a equipe de
projeto em relao aos requisitos que sero atendidos pelo
projeto de software;
Registrar e acompanhar requisitos ao longo de todo o processo
de desenvolvimento;
Documentar e controlar os requisitos alocados para
estabelecer uma baseline para uso gerencial e da equipe de
desenvolvimento;
Manter planos, artefatos e atividades de software consistentes
com os requisitos alocados.
23
TAREFA 02 - QUESTES DE REQUISITOS (0,5)
1) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de

requisitos que podem ser utilizadas em conjunto ou individualmente.
So elas:
a) gerao de casos de teste, revises de requisitos, gerenciamento de
mudanas e prototipao.
b) revises de requisitos, prototipao, gerao de casos de teste e
anlise automatizada da consistncia.
c) prototipao, anlise automatizada da consistncia, revises de
requisitos e gerenciamento de mudanas.
d) gerenciamento de mudanas, anlise automatizada da consistncia,
revises de requisitos e gerao de casos de teste.
e) anlise automatizada da consistncia, prototipao, gerenciamento
de mudanas e gerao de casos de teste
2) Um requisito de software expressa as necessidades e restries
colocadas em um produto de software que contribuem para a soluo
de algum problema do mundo real. Acerca desse assunto, assinale a
opo correta.
a) Os contratantes ou clientes so os principais colaboradores
envolvidos no fornecimento de informaes para o processo de
levantamento ou elicitao de requisitos de software, os demais
grupos de pessoas que podem fornecer informaes so
considerados de importncia secundria.
b) As necessidades dos usurios a serem atendidas por um produto de
software constituem a classe de requisitos funcionais, e as restries
mencionadas na definio de requisitos constituem a classe de
requisitos no funcionais.
c) Entre as fontes de informao para a elicitao de requisitos,
destacam-se, alm dos colaboradores, o conhecimento do domnio
de aplicao em que o software funcionar, o ambiente operacional
do software e o ambiente organizacional.
d) A tcnica de casos de uso, empregada em alguns modelos de
desenvolvimento de software atuais, mais aderente construo
de cenrios durante a construo de prottipos que durante a
e) A negociao de requisitos, de forma similar observao do
ambiente organizacional, uma atividade tpica da fase de elicitao
de requisitos.
3) Sobre os processos de engenharia de requisitos, na elicitao e na
anlise ocorre total interao com os stakeholders no sistema, sendo o
principal objetivo:
a) obteno dos requisitos.
b) homologao do sistema.
c) elaborao do manual do usurio.
24
d) converso de especificaes em requisitos.

e) execuo do estudo de viabilidade do sistema.
4) A respeito de anlise de requisitos, julgue os itens a seguir.
I O usurio deve ser capaz de pesquisar tanto no banco de dados
inteiro como em uma parte dele.
II A interface de usurio para o sistema deve ser implementada em
HTML sem frames ou em applets Java.
III O sistema deve fornecer vises apropriadas para que o usurio
possa ler documentos.
IV Cada ordem deve ter um identificador nico (OSID), que o usurio
deve poder copiar na rea permanente de armazenamento da
conta.
V O processo de desenvolvimento do sistema e os documentos
devem ser realizados conforme o padro interno da empresa.
So requisitos funcionais apenas os itens:
a) I, II e III.
b) I, II e V.
c) ) I, III e IV.
d) II, IV e V.
e) III, IV e V.
5) Identifique com V as afirmativas verdadeiras e com F, as falsas.
( ) Os requisitos no funcionais restringem o sistema que est sendo
desenvolvido e o processo de desenvolvimento que deve ser usado e
esto, frequentemente, relacionados s propriedades emergentes do
sistema de modo que se aplicam ao sistema em sua totalidade.
( ) A prototipao no considerada uma tcnica usada para validao
de requisitos, pois ocorre na fase final do processo de
desenvolvimento, representado a entrega do sistema aos usurios
finais e clientes.
( ) Pode-se considerar que a entrada para o estudo de viabilidade
consiste em um conjunto preliminar de requisitos de negcios, um
esboo da descrio do sistema e como esse sistema pretende
apoiar os processos de negcios.
A alternativa que contm a sequncia correta, de cima para baixo, a:
a) V
V
F
b) V
F
V
c) F
F
V
d) F
V
F
e) V
V
V
6) A engenharia de requisitos ajuda os engenheiros de software a
compreender melhor o problema que eles vo trabalhar para resolver.
Ela inclui um conjunto de tarefas que levam a um entendimento de
qual ser o impacto do software sobre o negcio, do que o cliente quer
e de como os usurios finais vo interagir com o software. A funo de
negociao no processo de engenharia de requisitos:
25
a) especifica, revisa e valida o problema de modo a garantir que seu

entendimento e o entendimento do cliente sobre o problema
coincidam.
b) refina e modifica os requisitos. uma ao de modelagem de
anlise composta de vrias tarefas de modelagem e refinamento.
c) define quais so as prioridades, o que essencial, o que
necessrio. Clientes, usurios e outros interessados so solicitados a
ordenar os requisitos e depois discutir os conflitos de prioridade.
d) ajuda o cliente a definir o que necessrio.
e) define o escopo e a natureza do problema a ser resolvido.
7) Requisitos no-funcionais esto diretamente relacionados com a
satisfao dos usurios. Assinale a alternativa que no indique um
requisito no-funcional:
a) O sistema de arquivos deve ser protegido, para acesso, apenas, de
usurios autorizados.
b) O software deve ser implementado usando os conceitos de
orientao a objetos.
c) O tempo de desenvolvimento do software no deve ultrapassar seis
meses.
d) O software poder ser executado em plataforma windows e linux.
e) O software deve emitir relatrios de vendas a cada quinze dias.
8) As declaraes de servios que o sistema deve fornecer, de como ele
deve reagir a entradas especficas ou se comportar em determinadas
situaes, so chamadas de requisitos:
a) No-funcionais
b) De domnio.
c) De sistema.
d) Funcionalidades.
e) De usurio.
9) Considerando-se a especificao de requisitos de um software,
incorreto afirmar:
a) a fase de especificao de requisitos pode ser iniciada logo aps as
fases de anlise e projeto. Por essa razo, fundamental que haja a
participao ativa do usurio.
b) h tcnicas para a elicitao dos requisitos; entre elas, est o uso de
entrevista e brainstorm com os potenciais usurios.
c) quanto mais cedo for identificado um problema na fase de anlise de
requisitos, menor ser o custo de corrigi-lo.
d) o gerenciamento de requisitos contempla um conjunto de atividades
que auxiliam no controle e alteraes dos requisitos durante a
execuo projeto.
e) o seu objetivo representar as necessidades e restries dos
usurios de um sistema.
26
ELICITAO DE REQUISITOS
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." Fred Brook
Uma das partes mais crticas do processo de desenvolvimento de
software a elicitao (levantamento) de requisitos.
H estudos que indicam que os requisitos detectados depois
do software implementado ou erros de anlise custam at vinte
vezes mais caros que qualquer outro tipo de erro.
FASES DE UMA ELICITAO DE REQUISITOS
Um projeto de elicitao de requisitos tm as seguintes fases:
Figura 8 Etapas de uma Elicitao de Requisitos (Fonte: extrado da Web)
Nesta etapa um dos artefatos2 principais a criao do documento

viso.
Produto de trabalho do processo: os papis usam os artefatos para executar atividades e

produzem
artefatos
ao
executarem
as
atividades
(http://www.wthreex.com/rup/manuals/intro/kc_artifact.htm acessado em 08/12/2011)
27
Figura 9 Esquema para criao do documento viso (Fonte: extrado da Web)
Figura 10 Erros de Requisitos (Fonte: extrado da Web)
A elicitao de requisitos corresponde a identificar junto aos

stakeholders3 quais so os objetivos do sistema ou produto, o que deve
ser acompanhado, como o sistema ou produto se 'encaixa no contexto
das necessidades do negcio e, finalmente, como ser a utilizao do
sistema ou produto no dia-a-dia.
um processo complexo, porm simples.
H diversas razes para a complexidade, dentre elas, destacam-se
os seguintes problemas:
Qualquer pessoa ou organizao que tenha interesse, ou seja, afetado pelo projeto. A palavra
deriva de stake (interesse, participao, risco) e holder (aquele que possui).
28
Escopo: Os limites do sistema so geralmente definidos de

forma incompleta, ou os clientes4 ou usurios especificam
detalhes tcnicos desnecessrios;
Compreenso: Os clientes ou usurios geralmente no esto

completamente certos das necessidades, tm uma pouca
compreenso ou do domnio do seu negcio, omitem
informaes que julgam bvias, etc.;
Volatilidade: Os requisitos mudam o tempo todo.
OBJETIVOS DA ELICITAO DE REQUISITOS

O objetivo da elicitao de requisitos obter conhecimento
relevante para o problema e prover o mais correto entendimento de o
que esperado do software/sistema.
PASSOS PARA A ELICITAO DE REQUISITOS

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.
H uma diferena entre cliente e usurio. O primeiro refere-se a quem contratou o

desenvolvimento do sistema que no necessariamente ser quem utilizar o sistema (usurio).
29
QUESTES QUE PRECISAM SER RESPONDIDAS
Figura 11 Questes que precisam ser respondidas
DOCUMENTAO DO ELICITAO DE REQUISITOS

Os documentos criados atravs da elicitao de requisitos iro
depender do tamanho do sistema que ser construdo.
Estes documentos incluem as seguintes informaes:
As necessidades e viabilidade estruturadas;
O limite de escopo do software/sistema;
Lista de clientes, usurios e outros stakeholders
participaram da atividade de elicitao de requisitos;
que
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 ideia do
uso do sistema ou produto sob diferentes condies de
operao;
Qualquer
prottipo
que
eventualmente
desenvolvido para melhor definir os requisitos.
tenha
sido
Cada um destes documentos deve ser revisado por todas as

pessoas que tenham participado da elicitao de requisitos.
30
IDENTIFICAO E ELICITAO DE REQUISITOS

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.
As informaes podem ser identificadas ou encontradas em
diversas fontes, como: analista de negcio, clientes, documentos,
Domain
Experts5
especificaes
tcnicas,
sistemas
legadospatrocinadores ou usurios.
IDENTIFICAO DOS REQUISITOS
Tambm chamada de descoberta de requisitos, tem o objetivo de

identificar os requisitos a ideia inicial do sistema para compreender o
domnio do problema.
Identificar as funcionalidades do software que deve ter para
atender as necessidades do usurio.
Para identificar podemos fazer as seguintes perguntas para
identificar tambm as principais caractersticas do software:
Quanto a
performance, qual
tempo de
resposta
adequado?
Quais
funcionalidades
ele deve ter?
Quanto
usabilidade, o
software identifica
visualmente a
empresa e possui
interface
amigvel?
Especialista em uma ou mais rea de negcio.
O que o software
deve fazer?
Quais so os
requisitos de
segurana que o
software
precisa?
31
Os requisitos encontrados no devem ser descritos neste

momento, precisamos apenas identific-los (informao de alto nvel).
Os requisitos de software podem ser identificados no texto da
declarao do problema (geralmente so verbos que identificam
algumas aes). Este documento classifica os requisitos em dois tipos.
PROBLEMAS NA IDENTIFICAO DOS REQUISITOS
ESCOPO: Limite do sistema mal definido ou detalhes tcnicos

desnecessrios confundem os objetivos globais;
ENTENDIMENTO: Clientes/usurios no esto completamente certos
dos que necessrio, no tem pleno entendimento do domnio do
problema, tm dificuldade de comunicar as necessidades, tm pouca
compreenso das capacidades;
VOLATILIDADE: Requisitos mudam com o tempo.
EXEMPLO DE DECLARAO DO PROBLEMA
Acompanhamento das estatsticas de aprendizado do aluno e da

turma (professor);
Informao: Relatrio de aproveitamento do aluno e da turma(s).
REQUISITOS FUNCIONAIS:
o Sistema deve registrar as principais aes de cada usurio;
o 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 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 O sistema deve usar grficos comparativos do aproveitamento
do aluno com a mdia da turma;
o O sistema deve usar cores na construo dos grficos;
o O tempo de resposta na elaborao do relatrio no pode ser
superior a 15 segundos.
CARACTERSTICAS DA ELICITAO DE REQUISITOS
Definir as tcnicas de coleta de requisitos baseadas em fatores

operacionais, tticos e financeiros;
32
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.
DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS
Figura 12 Diferena entre uma boa e uma m elicitao (Fonte: extrado da Web)
TAREFA 03 ELICITAO DE REQUISITOS (0,5)
No caa-palavras abaixo, encontre os itens:
33
34
TCNICAS PARA ELICITAO DE REQUISITOS

No existe maneira nica de especificar os requisitos.
A identificao e elicitao de requisitos uma tarefa que parece
simples, mas, no devemos nos enganar, s vezes, para obtermos
algumas informaes exigida muita dedicao, persistncia e tcnica.
Esta parte apresenta e discute as principais tcnicas para identificao
e elicitao de requisitos de software.
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.
Tipos de Tcnicas
Existem vrias tcnicas para a elicitao de requisitos, todas elas
possuem seus prprios conceitos, vantagens e desvantagens. Dentre
elas,
destacam-se
(KENDALL;
KENDALL,
2010;
KOTONYA;
SOMMERVILLE, 1998; AURUM; WOHLIN, 2005):
WORKSHOP DE REQUISITOS: idealizado para encorajar o
consenso acerca dos requisitos da aplicao e acerca das aes
a serem tomadas em um curto intervalo de tempo. Formato:
reunio intensiva (mximo 2 dias) com pessoas chaves visando
criar ou revisar as principais funcionalidade do sistema em
desenvolvimento, com a participao de um mediador;
QUESTIONRIOS: o uso de questionrios possibilita ao
analista
obter
informaes
como
postura,
crenas,
comportamentos e caractersticas de vrias pessoas que sero
afetas pelo sistema;
Quem so os usurios (ou perfis de usurio)?
Quem o cliente?
Eles tm necessidades diferentes em relao ao sistema?
Onde mais pode ser encontrada uma soluo para este problema?
Estas questes nos foram a ouvir antes de sair propondo uma soluo
para o problema.
OBSERVAO: consiste em observar o comportamento e o
ambiente dos indivduos de vrios nveis organizacionais.
Utilizando-se essa tcnica, possvel capturar o que realmente
feito e qual tipo de suporte computacional realmente
necessrio. Ajuda a confirmar ou refutar informaes obtidas
com outras tcnicas e ajuda a identificar tarefas que podem ser
automatizadas e que
no foram identificadas pelos
interessados;
35
ANLISE DE DOCUMENTAO: pela anlise de documentos

existentes na organizao, analistas capturam informaes e
detalhes difceis de conseguir por entrevista e observao.
Documentos revelam um histrico da organizao e sua
direo.
CENRIOS: com o uso desta tcnica, um cenrio de interao
entre o usurio final e o sistema montado e o usurio simula
sua interao com o sistema nesse cenrio, explicando ao
analista o que ele est fazendo e de que informaes ele
precisa para realizar a tarefa descrita no cenrio. O uso de
cenrios ajuda a entender requisitos, a expor o leque de
possveis interaes e a revelar facilidades requeridas;
PROTOTIPAGEM (PROTOTIPAO): um prottipo uma
verso preliminar do sistema, muitas vezes no operacional e
descartvel, que apresentada ao usurio para capturar
informaes especficas sobre seus requisitos de informao,
observar reaes iniciais e obter sugestes, inovaes e
informaes para estabelecer prioridades e redirecionar planos;
VANTAGENS:
o
permitem
aos
clientes
e
usurios
do
sistema
experimentar o sistema;
o
entendendo melhor como o sistema pode ser usado para
dar suporte aos seus trabalhos;
o
mal-entendidos entre projetistas e usurios podem ser
identificados quando a funcionalidade do sistema
demonstrada usando o prottipo;
o
funes que esto faltando podem ser detectadas usando
o prottipo;
o
durante o desenvolvimento de um prottipo, requisitos
incompletos e inconsistentes so descobertos.
DESVANTAGENS:
o
custo do desenvolvimento de um prottipo;
o
tempo requerido para desenvolver um prottipo (que
pode aumentar o tempo de entrega ao usurio);
o
o uso de um prottipo pode induzir os usurios a
prestarem mais ateno na interface com o usurio do
que nos requisitos da aplicao;
o
os usurios podem tornar-se familiares com uma
interface com o usurio antes da verso final do sistema
estar desenvolvida.
LINGUAGEM NATURAL: na maioria das organizaes, os
requisitos so escritos como pargrafos de linguagem natural,
adicionados por diagramas e equaes.
o Vantagem: Linguagem natural a nica notao que
geralmente entendvel por todos os leitores potenciais dos
requisitos.
o Desvantagem: Os requisitos em linguagem natural podem
ser ambguos, pouco claros e causar mal entendidos.
Exemplo: Casos
(sentenas).
36
de
Uso
Lista
de
Caractersticas
DINMICAS DE GRUPO: h vrias tcnicas de levantamento

de requisitos que procuram explorar dinmicas de grupo para a
descoberta e o desenvolvimento de requisitos, tais como:
brainstorming, brainswriting e JAD.
ETNOGRAFIA
Tcnica de observao que pode ser utilizada para compreender os
requisitos sociais e organizacionais, ou seja, entender a poltica
organizacional bem como a cultura de trabalho com objetivo de
familiarizar-se com o sistema e sua histria. Os cientistas sociais e
antroplogos usam tcnicas de observao para desenvolver um
entendimento completo e detalhado de culturas particulares.
Nesta tcnica, o analista se insere no ambiente de trabalho em que o
sistema ser utilizado. O trabalho dirio observado e so anotadas as
tarefas reais em que o sistema ser utilizado. O principal objetivo da
etnografia que ela ajuda a descobrir requisitos de sistema implcitos,
que refletem os processos reais, em vez de os processos formais, onde as
pessoas esto envolvidas.
Etnografia particularmente eficaz na descoberta de dois tipos de
requisitos:
1. Os requisitos derivados da maneira como as pessoas realmente
trabalham, em vez da maneira pelas quais as definies de processo
dizem como elas deveriam trabalhar;
2. Os requisitos derivados da cooperao e conscientizao das
atividades de outras pessoas.
Alguns itens importantes que devem ser executados antes, durante e
depois do estudo de observao:
Antes, necessrio identificar as reas de usurio a serem
observadas; obter a aprovao das gerncias apropriadas para
executar as observaes; obter os nomes e funes das pessoas
chave que esto envolvidas no estudo de observao; e explicar
a finalidade do estudo;
Durante, necessrio familiarizar-se com o local de trabalho
que est sendo observado. Para isso preciso observar os
agrupamentos organizacionais atuais; as facilidades manuais e
automatizadas;
coletar
amostras
de
documentos
e
procedimentos escritos que so usados em cada processo
especfico que est sendo observado; e acumular informaes
estatsticas a respeito das tarefas, como: frequncia que
ocorrem, estimativas de volumes, tempo de durao para cada
pessoa que est sendo observada. Alm de observar as
operaes normais de negcios acima importante observar as
excees;
37
Depois, necessrio documentar as descobertas resultantes das

observaes feitas. Para consolidar o resultado preciso rever
os resultados com as pessoas observadas e/ou com seus
superiores.
A anlise de observao tem algumas desvantagens como, consumir
bastante tempo e o analista ser induzido a erros em suas observaes.
Mas em geral a tcnica de observao muito til e frequentemente
usada para complementar descobertas obtidas por outras tcnicas.
ENTREVISTAS
Tcnica amplamente utilizada, que consiste em conversas
direcionadas com um propsito especfico e com formato perguntaresposta. Seu objetivo descobrir problemas a serem tratados, levantar
procedimentos importantes e saber a opinio e as expectativas do
entrevistado sobre o sistema. Deve ser bem planejada e preparada
cuidadosamente para saber quem foi entrevistado, definir os objetivos da
entrevista, preparar antecipadamente as questes que sero formuladas
(ou parte delas).
Etapas
Apresentar-se;
Repassar a agenda (objetivos, patrocinador, motivo da escolha do
entrevistado);
Postura do entrevistador: credibilidade, iseno, discrio; no criar
ressentimentos;
Deixar o entrevistado falar (reduo da interferncia);
Direcionar a discusso para os objetivos;
Evitar perguntas fechadas;
No ultrapassar o tempo;
Notar sinais de impacincia.
Forma de Entrevistar
Relacione a parte da entrevista c/ partes do sistema;

Obtenha pontos de vista alternativos;
Solicite detalhes do item que voc estiver interessado;
Estabelea a dependncia do assunto com outros;
Confirme os dados obtidos;
Focalize os requisitos (no os problemas tcnicos);
No confunda sintomas com o problema.
Perguntas que devem ser respondidas
Quem so o cliente e o usurio?

Possuem necessidades diferentes?
Quais so suas: Capacidades, Backgrounds, Ambientes, etc.
Qual o problema?
38
Como resolvido atualmente?

Qual a razo para resolv-lo?
Qual o valor de uma soluo bem-sucedida?
Onde mais uma soluo pode ser encontrada?
BRAINSTORMING
Representantes de diferentes grupos de interessados engajam-se em
uma discusso informal para rapidamente gerarem o maior nmero
possvel de ideias focadas em um objetivo claro e pr-definido.
Regras devem ser seguidas em uma sesso de Brainstorm:
No permitir crticas ou debate;
Deixar a imaginao voar;
Gerar tantas ideias quanto for possvel;
Mudar e combinar ideias;
Sesso consiste em duas fases: GERAO DE IDEIAS e
CONSOLIDAO;
Processo relativamente no estruturado que pode ou no
produzir a mesma qualidade ou nvel de detalhe de outros
processos.
TECNICAS PARA CONDUZIR
Inicie a sesso divulgando CLARAMENTE os objetivos;

Certifique-se que cada participante compreendeu exatamente os
objetivos (obter feedback);
Convide escriba para anotar cada ideia no flip-chart;
Anote com clareza e preciso evite telegrafar;
No deixe que se percam as ideias havendo vrias ideias
simultneas, pea que cada um anote as suas ideias numa folha
para depois pass-las para o flip-chart.
Incentive a participao de todos;
Evite que ideias sejam discutidas, seja qual for o pretexto;
No tente esmiuar, detalhar ou entender uma ideia;
No permita que hajam justificativas para uma ideia;
A sesso deve durar entre 15 e 60 minutos;
O clima deve ser descontrado, mas no CIRCO!
Aps uma sesso de Brainstorming as pessoas PRECISAM relaxar!
Aps a sesso de brainstorming, deve haver um estudo de
viabilidade e adequao para cada ideia (organizar as ideias).
BALDE DE GUA GELADA
Isso no possvel...
No temos tempo para...
Tudo isso j foi tentado...
No momento no estamos em condies...
39
Na prtica as coisas so diferentes...

Se isso fosse til, algum j teria tido a ideia...
Isso muito antiquado...
Isso moderno demais...
Vamos voltar a conversar no incio do prximo ano...
J temos muitos projetos...
Voc sabe que isso no funciona...
Vamos nomear uma comisso para cuidar disso...
No temos nada com isso...
No problema do nosso departamento...
Vamos esperar os acontecimentos...
Melhor seria pensarmos um pouco mais...
Outra vez voc com essas suas ideias...
Se voc acha que no nosso Pas isso vai funcionar...
Isso contra o regulamento...
Parece bom, mas... duvido que funcione...
Isso s vai dar mais trabalho pr gente ...
Acho que algum vai ficar furioso quando souber disso...
Exemplos:
1) Contexto: automao de iluminao.
Aspecto surgido no brainstorming: Configurao de iluminao
automtica.
Sentena descritiva: O dono de casa deve poder definir uma
programao da iluminao da casa baseado nos horrios do dia.
2) Contexto: Sistema de entrada de ordens de venda.
Aspecto surgido no brainstorming: Rapidez.
Sentena descritiva: O tempo de resposta deve ser suficientemente
bom para no interferir na realizao das aes do processo de venda.
3) Contexto: Sistema de rastreamento de falhas.
Aspecto surgido no brainstorming: Notificao automtica.
Sentena descritiva: Todos os grupos cadastrados devem ser
notificados por email quando houver alguma modificao no processo
de fabricao.
BRAINSWRITING
Dividir os participantes em grupos de 4 ou 5 pessoas. Os grupos
recebem uma questo.
O trabalho:
- Escrever a sua opinio sobre a questo;
- Ao terminar, colocar a folha no centro da mesa;
- Pegar a folha de respostas de outro integrante do grupo;
- Criticar as colocaes encontradas;
40
- Criticar todos os trabalhos do grupo, por escrito;

- Completado o ciclo, o grupo pode receber nova pergunta;
- Os presentes criticam todas as posies dos grupos.
Observaes:
- Pode haver um relator por grupo;
- Cada grupo pode receber uma questo diferente.
- Exige um relator do trabalho final.
EXERCCIOS
1. Vamos conduzir uma entrevista: em dupla fazer uma entrevista a

respeito de um sistema de controle de tarefas. Estas tarefas so
semanais, feitas de forma individual com notas entre 1,0 e 10,0
pontos.
2. Baseado na tcnica BRAINWRITING em grupo de cinco pessoas,
discutir sobre o assunto: COMO RESOLVER O PROBLEMA DE
QUALIDADE DO SERVIO NA EDUCAO.
41
J AD
Tradicionalmente, JAD tem sido um mtodo utilizado por profissionais
de processamento de dados e usurios para definio de requisitos de
sistemas. Por isto o nome JAD Joint Application Design (ou
Development). Atualmente, o JAD tem sido um mtodo utilizado por todos
que desejam trabalhar em projetos, sejam da rea de informtica ou no,
ou que queiram tomar decises que afetem mltiplas reas da
organizao. O conceito de JAD surgiu na IBM em 1977, e entrou no Brasil
na dcada de 80, mas s comeou a ser utilizado efetivamente, aps
alguns nomes de peso na anlise de sistemas avalizarem tal
metodologia. Tcnica que rene determinado nmero de pessoas em
sesses bem estruturadas para, com tempo e esforo reduzidos,
consolidar um objetivo pr-determinado.
Figura 13 JAD
ETAPAS PARA PREPARAR UMA REUNIO JAD
Figura 14
Etapas para preparao do JAD
42
PREPARAO
- OBJETIVOS
Garantir a escolha dos participantes apropriados;

Garantir que a Agenda seja preparada de forma adequada;
Garantir o acordo do Grupo quanto aos objetivos e produtos a serem
obtidos;
Garantir que todo o material necessrio tenha sido providenciado.
- ETAPAS
1. Examinar, se a utilizao do JAD adequada;

2. Planejar as Sesses (quantas, de que tipo, quando...);
3. Elaborar a Perspectiva Gerencial (ideia clara do projeto e da sesso,
obtidas do Patrocinador do projeto finalidade, escopo, objetivos e
restries);
4. Familiarizar-se com as reas de negcio sob estudo (glossrio,
entrevistas preliminares bem curtas,...);
5. Preparar a Agenda da Sesso (roteiro de passos a serem seguidos);
6. Preparar os participantes (mtodos e abordagem da sesso,
informaes a providenciar previamente, resultados de sesses
anteriores);
7. Preparar a Agenda Detalhada (desdobramento do roteiro da sesso
com durao prevista para cada item, lembretes, dicas, ...);
8. Preparar as ferramentas para documentao (ex.: Metodologia p/
Mapeamento de Processos e ARIS da IDS SCHEER, Questionrios e
Formulrios).
Figura 15 Responsabilidades na etapa de Preparao do JAD
43
- AGENDA
Identificar a finalidade e os objetivos da reunio (Sesso);

Identificar os produtos (resultados esperados);
Identificar as informaes conhecidas;
Esboar as etapas da agenda;
Verificar se etapas so logicamente coerentes;
Identificar os participantes provveis;
Identificar as etapas que os participantes no tm condio de realizar
na sesso;
Identificar que informaes devem ser providenciadas antes da sesso,
para viabilizar o item 7;
Rever: esboo satisfaz os itens 1 e 2 ?
Refinar o trabalho, incluindo a documentao necessria.
CRITRIOS PARA A ESCOLHA DOS PARTICIPANTES:
Possui conhecimento e capacidade analtica em relao ao assunto;
Tem habilidade na resoluo de divergncias e sabe resolver suas
diferenas em confrontos de ideias e pontos de vista;
Pode ser afetado pelas decises tomadas, tendo a oportunidade de
compartilhar suas expectativas com o grupo;
Concorda de antemo com as regras de soluo de conflitos e de
tomada de deciso determinadas pelo grupo;
Tem disponibilidade para participar com criatividade e eficcia;
EXEMPLO DE CARTA CONVITE
PARA: Ver Lista de Distribuio
Rio de Janeiro, 21 de Maio de
2002
DE: Yyyyyy Patrocinador do projeto Cargo
REF.: Projeto XPTO Sesso de Trabalho
Foi selecionado para participar da Sesso de Mapeamento de Processos do
projeto XPTO.
Esta Sesso integra o mtodo JAD, j apresentado, que vem sendo utilizado
com sucesso por grandes empresas. O seu tempo ser mais produtivo do que se
voc participasse de entrevistas individuais.
Voc foi selecionado pela sua habilidade, relao com o assunto e
capacidade de contribuir com ideias criativas e indispensveis produo de um
trabalho de alto nvel. Voc ter meu completo apoio e suporte.
A Sesso ter a durao de trs dias, de 27/05/2002 at 29/05/2002, com
realizao na parte da manh de cada dia, das 9:00h s 13:00h, na Sala Nxxx do
SENAI Artes Grficas, localizado na Rua So Francisco Xavier N xx, bairro da Tijuca.
Veja em anexo, a agenda de convocao detalhando a Finalidade,
Objetivos, Escopo (Tpicos), Lder da Sesso, Participantes, Documentos a Levar e
Informaes Necessrias, Restries e Eventuais Observaes.
Quaisquer dvidas devero ser imediatamente encaminhadas ao Sr.
Xxxxxx,.
Grato pela sua cooperao,
Yyyyyy Patrocinador do Projeto XPTO.
44
MODELO DE AGENDA DE CONVOCAO:
Figura 16 Modelo de Agenda

TOPICOS PARA A AGENDA PADRO
Introduo:
Breve reviso do mtodo JAD (s se no for conhecido);
Horrios, intervalos, facilidades, etc.;
Apresentao dos participantes;
Apresentao da agenda, esclarecendo o que ser tratado em
cada etapa.
Reviso da Perspectiva Gerencial:

Definies estabelecidas p/ o projeto pelo Patrocinador;
Abertura pelo Patrocinador (s para 1 sesso):
Discurso de 5 min. mostrando a importncia do projeto no
contexto do negcio, o que se espera alcanar e porque aquela
equipe foi escolhida.
Viso da rea de Informtica:
Rpida posio do Engenheiro de Software sobre o andamento
dos trabalhos, prximas etapas e informaes tecnolgicas de
interesse.
Regras de Conduta:
Cdigo de cooperao estabelecido pelo Facilitador com o Grupo,
para maior produtividade da sesso.
45
Abordagem da Sesso:
Roteiro passo a passo das etapas especficas (dirigidas aos
produtos metodolgicos) para se alcanar os objetivos da sesso.
Reviso das Pendncias:
Atualizao do Controle de Pendncias documentando o item,
data de registro, situao, responsvel pela soluo, data de
trmino prevista.
Reviso Geral:
Reviso do material produzido na sesso, verificando se est
coeso e de acordo com o que estava previsto.
Avaliao e Encerramento da Sesso:
Avaliao dos participantes sobre o
mtodo
desempenho do lder, para melhoria contnua.
usado
e o
DEVERES DAS PESSOAS CONVOCADAS PARA O JAD
Avaliar a agenda divulgada;

Reunir informaes e arquivos;
Convocar subordinados para esclarecimentos;
Preparar-se para contribuir efetivamente durante a realizao
da reunio;
Estar certo de que compreendeu os objetivos e tpicos,
questionando-se:
Onde posso contribuir melhor?
O que no entendo e no me compete? (Devo silenciar nestas
horas)
O que gostaria de alcanar e o que me satisfaz se for alcanado?
Que elementos devo levar para a reunio?
Preciso realizar contatos prvios?
Usarei recursos audiovisuais? A sala suporta sua utilizao?
O que preciso alterar na minha agenda, em funo da reunio?
ATIVIDADES A SEREM REALIZADAS NO DIA ANTERIOR A SESSO
Providenciar todo o material necessrio: Transparncias; Folhas de

flip-chart; Projetor; Tela; Canetas para quadro; Material a ser
projetado e/ou transparncias; Fita colante; Pastas do Projeto JAD
para os participantes, etc.
Revisar a Agenda Detalhada (aquela que contm o script a ser
seguido pelo facilitador).
Posicionar os documentadores quanto aos pontos em que so
esperadas as suas participaes, atravs de reunio em que lhes
disponibilizada uma cpia da Agenda Detalhada.
Providenciar equipamentos dos documentadores: Micros com os
softwares necessrios instalados, Impressoras, Questionrios,
Checklists, Formulrios, etc.
46
Arrumar a sala de reunio.

Montar e testar equipamentos.
Figura 17 Layout da sala de reunio de JAD
SESSO
OBJETIVOS
Realizar reunio com os participantes definidos na fase de

Preparao;
Produzir as informaes necessrias para obteno dos resultados
previstos na fase de Preparao;
Buscar a criao de sinergia do Grupo no desenvolvimento de ideias
e conceitos;
Obter consenso quanto aos resultados.
ETAPAS
Preparao do Ambiente (condies adequadas, arrumao das

mesas, equipamentos, material necessrio, auxlios visuais, pastas
dos participantes) no dia anterior ao da realizao da sesso;
Conduo da Sesso (conforme Agenda Detalhada);
Documentao (providenciar ferramentas formulrios, micro,
software, impressora,...; observar passos da Agenda Detalhada;
documentar decises; documentar detalhes; ler o que j foi
documentado; gerar a documentao do dia para os participantes);
47
Encerramento da Sesso (verificar atendimento de todos os itens,

avaliar a sesso, entregar a documentao produzida, apresentar os
resultados da ltima sesso);
Figura 18 Responsabilidades da etapa Sesso de JAD

TCNICAS PARA APOIAR A SESSO
Figura 19 Tcnicas de Apoio
Passo 1: Definir o problema e despersonaliz-lo, escrevendo-o no

quadro ou no chart, para que se torne problema do grupo;
Passo 2: Fazer o grupo gerar possveis solues;
48
Passo 3: Avaliar as solues com o grupo, atravs de critrios

estabelecidos, evitando que algum se considere dono de alguma
delas;
Passo 4: Fazer o grupo decidir sobre a mais adequada;
Passo 5: Fazer o grupo determinar o mtodo de implementao da
soluo escolhida, se necessrio;
Passo 6: Se problema no desapareceu, coloc-lo na Lista de
Pendncias.
AVALIAO DA SESSO
49
50
Figura 20 Relatrio de Avaliao de Sesso

AVALIAO DE ACORDO COM O TOTAL OBT IDO
Aps Preenchidos Todos os Itens da Avaliao, Some Todos os Graus

e Obtenha o Total Geral:
Entre 0 e 7 significa que suas reunies esto boas;
De 8 a 14 suas reunies podem ser melhoradas;
De 15 a 22 suas reunies comeam a preocupar;
De 23 em diante, suas reunies andam MAL, muito h que ser feito
para que alcancem o nvel ideal.
fundamental que cada um tambm se inclua como causador dos
problemas e disfunes da lista de verificao. No se deve julgar
somente os outros, mas principalmente ns mesmos.
51
ANALISADOR DA REUNIO PARA TODOS OS PARTICIPANTES
Figura 21 Modelo de anlise da reunio
REVISO
Rever a documentao produzida na sesso;

Examinar possveis melhorias na sistemtica adotada.
ETAPAS
Rever a Documentao (verificar informaes incompletas, corrigir

falhas de comunicao entre facilitador e documentadores,
sumarizar os resultados, encaminhar verso definitiva da
documentao para os participantes);
Examinar
Avaliaes
(visa
processo
permanente
de
aperfeioamento; efetua tabulao e anlise comparativa entre as
sesses);
Preparar a Pasta do Projeto JAD contendo:
o
Perspectiva Gerencial;
o
Plano de Sesses;
o
Carta-convite para participao do grupo;
o
Agenda de cada sesso;
o
Lista de Participantes de cada sesso;
o
Documentao produzida em cada sesso;
o
Questionrios de Avaliao.
52
Figura 22 Responsabilidades na etapa de Reviso do JAD
Ao final da reviso deve ser preparado um resumo do que foi

produzido na sesso, para ser apresentado ao Patrocinador do projeto.
PAPEIS DE CADA UM DENTRO DA REUNIO

H dois grupos de participantes:
O CLIENTE (PATROCINADOR)
Detm autoridade formal sobre as reas de negcios afetadas pelo

sistema. O cliente estabelece as diretrizes e objetivos do projeto.
responsvel pela abertura da primeira sesso de trabalho, na qual o grupo
ter oportunidade de sentir o real interesse da administrao superior pelo
sucesso do projeto e em dar o seu apoio.
ENGENHEIRO DE SOFTWARE
o responsvel pelo sucesso ou fracasso do projeto;

Participa do JAD na condio de membro da equipe;
o principal contato do Lder da Sesso;
Familiariza o Lder da Sesso com o projeto e com a equipe
envolvida.
53
EQUIPE
So os responsveis pelo contedo da sesso. Representam as reas

envolvidas no projeto, incluindo a de informtica. Os participantes so
escolhidos entre as pessoas-chave das reas de negcio, seja no nvel
operacional ou no. O importante que, na sesso, no h distino
hierrquica, todos so iguais.
OBSERVADOR
Interessado no projeto especificamente ou em conhecer a

sistemtica utilizada;
No um participante no podendo, por isso, opinar durante a
sesso.
DOCUMENTADOR
o responsvel pelo registro das decises e especificaes

produzidas;
No caso Xerox, ele tambm um membro de equipe;
Segue orientao do Lder da Sesso no que respeita aquilo que
considerado relevante para ser documentado.
LDER DE SESSO OU FACILITADOR
o responsvel pela conduo da reunio. Deve ser um guia do

grupo. O seu trabalho conduzir os participantes ao longo da agenda,
garantindo que todos so ouvidos e que h consenso em torno das
decises tomadas. Deve ser um facilitador.
PERFIL DO LDER
Pessoa com facilidade de comunicao;

Capacidade de sntese;
Facilidade para resumir, esclarecer e sumarizar ideias e conceitos,
inclusive escolhendo as frases mais apropriadas que reflitam os
argumentos/ideias apresentados pelos participantes;
Falar claramente, precisamente;
Falar pausadamente e sem bairrismos;
Capacidade de dirigir discusses para o ponto objetivo;
Evitar disperses em consideraes no relevantes;
Evitar dilogos paralelos;
Controlar o horrio de incio e fim dos trabalhos;
Controlar e informar passo a passo as etapas da agenda;
Separe as ideias das pessoas;
Mostre um interesse natural;
Oua bem, inclusive com os olhos;
Mantenha os papis claramente definidos;
No confundir os participantes com jarges da rea de sistemas.
54
DICAS PARA SER UM BOM LDER
No
No
No
No
No
No
No
No
No
se irrite;
se ofenda;
brigue;
monopolize;
seja o dono da verdade;
faa o tipo sabido
leve tudo na brincadeira;
ignore algum participante;
permita uma dupla em debate.
DOCUMENTADOR OU ESCRIBA
um auxiliar do lder de sesso. responsvel pelo registro das

decises e especificaes produzidas.
Apenas as informaes relevantes so documentadas, segundo
orientao do lder de sesso.
OBSERVADORES
So interessados em conhecer a sistemtica utilizada ou interessados

no projeto especificamente. Os observadores no so participantes,
portanto, no esto autorizados a opinar durante a sesso.
FIGURINHAS DIFCIEIS NA REUNIO
O ATRASADINHO
Sempre chega atrasado s reunies;

D seu show na chegada;
Insiste em interromper a sequncia de argumentao do grupo.
Sempre que algum chegar atrasado, evidencie sutilmente, atravs
do cumprimento. Convide-o a olhar a memria do grupo e no faa uma
reviso. Isso seria punir os que chegaram na hora.
O QUE SAI MAIS CEDO
Abala a energia e a moral do grupo saindo da reunio antes de seu

trmino.
Na primeira oportunidade, procure saber o motivo do padro de
comportamento. Sugira, ao agendar a prxima reunio, que todos
optem por um horrio em que podero estar integralmente.
O DISCO QUEBRADO
Joga areia em todas as ideias;

Superctico e crtico;
Sempre esfriando o entusiasmo do grupo, dizendo algo do tipo isso
nunca vai funcionar.
55
Evidenciar para o grupo os pontos que o ctico no concorda,

buscando obter consenso do grupo.
O MENEADOR
Expressa discordncia ativamente via linguagem corporal e tiques

no-verbais, tais como:
Revirar os olhos, balanar a cabea, cruzar e descruzar os braos,
etc;
Indiretamente influencia o grupo a rejeitar uma ideia, uma reunio,
etc.
Procure interpel-lo, questionando se ele discorda de alguma
coisa, ou se gostaria de enriquecer o que foi dito.
O COCHICHADOR
Vive cochichando durante as reunies, mantendo conversas

paralelas;
Coloca o lder da sesso, assim como os membros do grupo, em
segundo plano.
Neste caso, s intervir quando houver absoluta certeza de que os
cochichos esto sendo negativos para a reunio. Algumas vezes, basta
aproximar-se dos cochichadores para que a conversa diminua.
O DESINTERESSADO
Senta afastado da mesa ou no fundo da sala;

Expressa
desaprovao
ou
desinteresse,
ignorando
os
procedimentos;
Pode cochilar, ler alguma coisa, ficar rabiscando papis, para evitar
qualquer tipo de engajamento na sesso.
Uma boa estratgia envolver o desinteressado em alguma atividade
de apoio.
O AGRESSIVO
Dispara ataques verbais e pessoais contra outros membros do grupo

e/ou contra o lder da sesso;
Constantemente ridiculariza um determinado ponto de vista ou
posio de outra pessoa.
Relembre as regras do grupo, lembrando que devemos respeitar as
opinies alheias. Quando estas medidas no forem suficientes, colocar no
quadro a essncia das discordncias e iniciar o procedimento de obteno
de consenso.
O REI DA VOZ
Fala muito e excessivamente alto;

Domina a discusso;
Aparentemente impossvel faz-lo calar;
56
Pode ser algum de nvel hierrquico acima dos demais membros, o

que o torna ainda mais inabalvel.
Procurar aproximar-se da pessoa, ou sugerir que faa anotaes
individuais.
O INTRPRETE
Sempre fala por outra pessoa, normalmente sem ser solicitado;

Recoloca as ideias alheias, frequentemente distorcendo-as durante a
sua explanao.
Confirme com o dono da ideia se ela foi recolocada pelo intrprete
com fidelidade.
O FOFOQUEIRO
Traz boatos ou rumores para a reunio;

Tenta ampliar seu poder, dando a impresso que tem informaes
de cocheira;
Leva o grupo a debater ou argumentar baseado na veracidade
daquelas informaes.
Sempre que as assertivas forem do tipo ouvi dizer, Acho que tem
uma circular, o lder da sesso deve tentar esclarecer: quem disse
isso?, Qual mesmo a circular?.
O "MVEIS E UTENSLIOS"
Usa credenciais, idade, tempo de casa, etc, no debate de uma

questo;
Focaliza a ateno do grupo em aspectos circunstanciais, ao invs
de explorar o verdadeiro assunto.
Acolher as observaes e relembrar que o objetivo do projeto
ampliar a viso do problema e ter a aceitao do grupo. Essas so
pessoas do tipo que muito resistente a mudanas.
O LDER FRUSTRADO
Vive dizendo ao lder da sesso o que fazer ou o que no fazer;

Tenta controlar a reunio, diminuindo os esforos do lder.
Acate as sugestes que no alterem a estrutura de sua agenda, e as
que interferirem, agradea a colaborao e mostre seu ponto de vista.
O OCUPADO
Sempre entrando e saindo das reunies com papis e pastas

debaixo dos braos;
Permite que seja chamado com frequncia por outras pessoas;
Tenta dar a impresso de muito ocupado para dar ateno integral
reunio e ao grupo.
Pedir ao prprio ocupado que sugira o que fazer para no haver
interrupes (sugira outros horrios de reunio, anotar recados...)
57
O MAL-EDUCADO
Entra no meio das discusses, interrompendo os comentrios de

algum;
Demonstra impacincia;
Fica insatisfeito quando suas prprias ideias no so bem recebidas.
O grupo sempre espera, neste caso, a interveno do lder da sesso.
Sugira que ele espere os colegas completar o raciocnio antes de contestlos.
O CARENTE
Gasta mais tempo e energia preocupado em obter aprovao do

lder da sesso do que com o contedo da reunio.
Quando este estiver iniciando alguma colocao olhando diretamente
para voc, voc deve indicar que ele deve se dirigir ao grupo.
TAREFA 04 TECNICA JAD (1,0)
Em grupo de cinco pessoas, identifi que

um
componente, resolva o estudo de caso abaixo:
papel
para
cada
Controle de Estoque de uma Rede de Supermercados

O sistema de controle de estoque de uma rede de supermercados mantm na
base de dados a descrio de todas as informaes que permitem a manuteno
de seu estoque de mercadorias. O controle efetuado para cada ponto de venda
da rede, mas centralizado em uma nica base de dados, que efetua os pedidos
de compra para todos os pontos de venda ao mesmo tempo. Quando um novo
produto deve ser comprado, emitida uma ordem de compra com a quantidade
total comprada, indicando tambm a quantidade do produto que deve ser
entregue em cada ponto de venda. Um pedido de compra pode incluir tambm
mais do que um produto comprado do mesmo fornecedor. Para que esse sistema
possa funcionar, o sistema de controle de estoque mantm trs informaes
fundamentais: o estoque de cada produto existente em cada ponto de venda da
rede, as informaes sobre os fornecedores e as informaes sobre os pedidos
em andamento. O estoque consiste na descrio de cada produto, incluindo a
maneira como ele medido (por volume, unidade, peso, etc.), como embalado
e nmero de embalagens disponveis em cada armazm. Mantm-se tambm os
dados sobre os preos de compra e venda, e taxa esperada e medida de venda
por ms. Como essas informaes so tratadas de maneira centralizada, elas so
atualizadas em lotes por meio da comunicao de cada ponto de venda com a
central, e no para cada produto vendido em caixa. Sobre os fornecedores so
registrados dados gerais como identificadores, endereos, pontos de distribuio,
etc., e tambm a relao de produtos disponveis e prazos de entrega. Todos os
pedidos so mantidos num histrico, onde as vrias atividades correspondentes
so registradas, alm de datas, valores e produtos envolvidos. As atividades de
um pedido so: emisso do pedido de compra, entregas em cada ponto de venda
e pagamentos efetuados. Estas atividades podem assumir status de parciais ou
totais, alm de confirmao ou no do aceite o pedido e seu respectivo
encerramento. Note que em pedido pode constar de mais de um produto e,
nesse caso, cada produto dever ser tratado separadamente.
58
ESPECIFICAO DE REQUISITOS
No documento da especificao de requisitos descrevemos os
requisitos funcionais (obrigatrios) e requisitos no-funcionais
(opcionais). Obs. H um outro exemplo de especificao de requisitos
no Anexo A.
MODELO DE ESPECIFICAO DE REQUISITOS
Figura 23 Modelo de especificao de requisitos
Onde:
Caso de Uso: nome do caso de uso;
Objetivo: breve descrio do caso de uso;
Atores: envolvidos naquele caso de uso;
Condio de incio: o que dispara a funcionalidade no contexto do
sistema;
Fluxo Principal: interao entre sistema e ator para que o objetivo
seja atingido;
Fluxo alternativo: apoio do fluxo principal para que seja possvel
atingir os objetivos secundrios.
Regras de negcio: restries nas funcionalidades.
PASSOS PARA ESPECIFICAR OS REQUISITOS
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.
59
Exemplo: Clientes so pessoas fsicas e possuem nome,

endereo e telefone:
CASO DE USO: CADASTRAR CLIENTE
OBJETIVO: PERMITIR QUE O FUNCIONARIO INSIRA, EXCLUA, ALTERE OU CONSULTE
CLIENTES NO SISTEMA.
ATOR: FUNCIONARIO
CONDICAO DE INICIO: FUNCIONARIO SELECIONA A OPCAO CADASTRAR CLIENTE
Obs. Dever ser definido como ser aps o cadastrar cliente. Como ser o dilogo? O
sistema dever apresentar na tela um conjunto de clientes j cadastrados e no final
apresentar as opes de inserir, excluir ou alterar um cliente selecionado, pois ao
lado de cada nome haver a opo de seleo para trabalhar com as opes de
excluir ou alterar.
FLUXO PRINCIPAL:
1. O sistema apresenta tela de cadastro de cliente contendo:
- Lista de Clientes cadastrados com as informaes para cada cliente:
* Opo de Seleo
* Nome
* Endereo
* Telefone
- Apresenta ao final as opes:
* Incluir novo
* Excluir cliente
* Editar cliente
2. O Funcionrio seleciona a opo Incluir novo [A16] [A27]
3. O sistema apresenta a tela de incluso de novo cliente contendo:
- Nome
- Endereo
- Telefone
- As Opes:
* Salvar
* Cancelar
4. O funcionrio informa os dados do cliente e seleciona a opo salvar [A3 8]
5. O sistema conclui a incluso do novo cliente
Decidir: retorna a tela principal ou o caso de uso encerrado?
6. O sistema retorna para a tela inicial.
7. O caso de uso encerrado. No final de cada fluxo importante destacar para que
parte ou tela do sistema ser desviado e informar que o caso de uso est encerrado.
FLUXO ALTERNATIVO: PODERO OU NO SER EXECUTADOS
[A1] O funcionrio seleciona a opo excluir Cliente.
1. O sistema exclui o cliente selecionado.
2. O sistema retorna ao passo 1 do fluxo principal.
[A2] O funcionrio seleciona a opo editar Cliente.
1. O sistema apresenta a tela com as informaes do cliente selecionado para
edio:
- Nome
- Endereo
- Telefone
- As opes: * Salvar * Cancelar
2. O funcionrio informa os dados do cliente e seleciona a opo salvar. [A4]
3. O sistema atualiza os dados do cliente.
6
Excluir Cliente
Editar cliente
CANCELAR fluxo alternativo
60

[A3] O funcionrio seleciona a opo Cancelar.
VISO E ESCOPO
O documento que deve ser criado deve ter a viso e o escopo do
programa a ser desenvolvido deve apresentar e deixar claro o que ser
feito. Deve ser focado a no cliente, levantando os requisitos principais
na viso macro, sem detalhamento para que o cliente perceba o que
est sendo feito. Os objetivos so levantamentos com reunies
semanais at fechar pois depois comea o levantamento de requisitos.
Nesta viso temos os objetivos principais e as prioridades dele.
Para seguir uma linha de raciocnio que definido pelo cliente ou
representantes deste cliente (stakeholders envolvidos no projeto).
Para que quando for levantar os requisitos no sair da viso sabendo
que vai ser feito e o que no vai ser feito (documento do escopo), onde
s poder ser feito o que est definido.
Deve ter nvel alto de abstrao e dever ter se haver ou no:
manuais, treinamentos e se for um sistema grande dever ser dividido
em subsistemas e depois poder ser integrado. A equipe precisa
lembrar o processo de usabilidade (caso parar um o outro permanece
funcionando) e tambm poder ser reutilizado.
O escopo deve conter tudo que o projeto deve fazer. importante
verificar se todo o escopo est sendo mantido (PLANEJAMENTO,
DEFINIO, VERIFICAO E CONTROLE DO ESCOPO).
importante criar uma estrutura analtica do projeto (EAP) onde
so definidos os blocos de trabalho para completar o projeto como um
todo.
EXERCCIOS
1) Funcionrios so identificados pelo seu nmero de matrcula, e

devem conter ainda nome, endereo, telefone e dependentes (nome e
data de nascimento), alm de estar associado, obrigatoriamente a uma
filial.
a) Requisito Funcional: CADASTRAR FUNCIONRIO
2) O sistema deve permitir que o setor de atendimento ao cliente
consulte os clientes cadastrados por nome, cpf, data de nascimento e
status (se est em dia ou inadimplente)
b) Requisito Funcional: CONSULTAR CLIENTES
3) Ponto de Venda: Um cliente chega no caixa com os itens que deseja
comprar. O caixa usa o sistema para registrar cada item. A cada item
comprado, o sistema apresenta o subtotal da compra e os detalhes do
item. O cliente entra com informao do pagamento, o qual o sistema
61
valida e registra. O sistema atualiza o estoque. O cliente recebe um

recibo do sistema e vai embora com os itens.
c) Requisito Funcional: PROCESSAR VENDA
4) Jogo de Banco Imobilirio. Requisito Funcional: JOGAR
TAREFA 05 ESPECIFICAO DE REQUISITOS (0,5)
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 chegada e partida, e
qual tipo de apartamento 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.
62
VERIFICAO E VALIDAO DE REQUISITOS
Ser que realmente

entendi o que o cliente
deseja?
Um software considerado com qualidade se est em conformidade

com as especificaes e padres de desenvolvimento documentados e que
atenda as necessidades dos usurios. Para garantir a qualidade do
software, um conjunto de atividades tcnicas devem ser aplicadas durante
todo o processo de desenvolvimento. O objetivo garantir que tanto o
processo de desenvolvimento quanto o produto de software atinjam nveis
de qualidade especificados.
A validao e a verificao (VV&T) tem o objetivo de garantir a
qualidade do software, assegurando que este cumpra as suas
especificaes e atenda s necessidades de seus usurios.
Validao importante uma vez que o custo para remover um erro
de requisitos grande.
De acordo com o IEEE, define validao e verificao como:
VALIDAO: avalia um sistema ou componente para
determinar se ele satisfaz os requisitos para ele especificados; O
software deve atender s necessidades dos usurios.
VERIFICAO: avalia um sistema ou componente para
determinar se os produtos de uma dada atividade de
desenvolvimento satisfazem as condies impostas no incio desta
atividade. Os artefatos construdos devem estar de acordo com a
especificao do software.
VALIDAR :
Estamos construindo
o produto certo???
VERIFICAR :
Estamos construindo
certo o produto??
63
Usamos mtodos para validar e verificar para:

Resultados de estudos experimentais evidenciam benefcios da
utilizao destes mtodos no desenvolvimento de software;
A utilizao destes mtodos na indstria tm mostrado resultados
positivos considerando PRODUTIVIDADE e QUALIDADE.
Ao inspecionar o software, h um aumento significativo na
produtividade, qualidade e estabilidade dos projetos.
Corrigir um defeito aps a entrega do produto 100 vezes mais caro
do que corrigi-lo durante as atividades de requisitos e projeto do sistema
(Boehm, Basili, 2001).
TIPOS DE DEFEITO
A maior parte de origem humana;

So gerados na comunicao e na transformao de informaes;
Permanecem presentes nos diversos produtos de software produzidos e
liberados;
A maioria encontra-se em partes do produto de software raramente
utilizadas e/ou executadas.
A principal causa a traduo incorreta das informaes e quanto
antes ser identificada, menor o custo de correo do defeito e maior a
probabilidade de corrigi-lo corretamente, por isto sempre importante
introduzir atividades de verificao e validao ao longo de todo o
desenvolvimento.
Figura 24 Tipos de Defeitos
64
OMISSO
Algum requisito importante relacionado funcionalidade, ao

desempenho, s restries de projeto, ao atributo, ou interface
externa no foi includo;
No est definida a resposta do software para todas as possveis
situaes de entradas de dados;
Faltam sees na especificao de requisitos;
Faltam referncias de figuras, tabelas e diagramas;
Falta definio de termos e unidades de medidas.
AMBIGUIDADE
Um requisito tem vrias intepretaes devido a diferentes termos

utilizados para uma mesma caracterstica ou vrios significados de um
termo para um contexto em particular.
INCONSISTNCIA
Dois ou mais requisitos conflitantes.
FATO INCORRETO
Um requisito descreve um fato que no verdadeiro, considerando as

condies solicitadas para o sistema.
INFORMAO ESTRANHA
As informaes fornecidas no requisito no so necessrias ou mesmo

usadas.
DOCUMENTO DE REQUISITOS
Por ser o primeiro artefato tangvel a ser produzido pois descreve
todas as caractersticas e as funes que o software a ser desenvolvido
deve possuir. Atua como um contrato entre o cliente e o desenvolvedor e
a base para todas as etapas subsequentes do desenvolvimento e
normalmente escrito em linguagem natural.
65
DEFEITOS NO DOCUMENTO DE REQUISITOS
Figura 25 Defeitos no Documento de Requisitos
CONSEQUENCIAS
Estimativas de esforo e prazo deixam de fazer sentido;

Desperdcio de recursos;
Produto final no atende as necessidades do usurio;
Corrigir defeitos aps a entrega do produto pode ser at cem vezes
mais caro que corrigi-los nas primeiras fases do desenvolvimento;
Em projetos recentes de software, teramos um esforo de retrabalho
entre 40% a 50% do esforo total.
PEQUENO CHECKLIST 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?
TCNICAS DE VALIDAO DE REQUISITOS

REVISO DE REQUISITOS
Anlise manual sistemtica dos requisitos.
66
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.
estabelecida?
ADAPTABILIDADE. O requisito pode ser modificado sem grande

impacto sobre outros requisitos?
origem
do
requisito
claramente
REVISES DE SOFTWARE
o processo ou atividade para leitura de um artefato de seu software
visando assegurar que ele cumpre sua especificao e atende s
necessidades de seus usurios e ocorre em diferentes momentos do
software.
Tem como objetivo validar e verificar os artefatos de software.
Pode ser aplicada a qualquer artefato produzido ao longo do processo
de desenvolvimento de software.
As revises podem ser:
PARES (PEER-REVIEWS): aumenta a probabilidade de defeitos a
serem encontrados. Utilizam:
o ANNIMIDADE: relacionamentos pessoais no afetam a
reviso.
o INDEPENDNCIA DOS REVISORES EM RELAO AO ARTEFATO
A SER REVISADO: permite uma avaliao objetiva sem
conflitos de interesse.
TIPOS DE REVISO DE SOFTWARE
INSPEO DE SOFTWARE
Os benefcios e custos so:

Inspees vm sendo utilizadas h mais de duas dcadas;
Existe
evidncia
experimental
de
sua
usabilidade
e
adequabilidade;
Provem um bom meio para o gerente do projeto monitorar a
qualidade e progresso do projeto;
67
Podem amenizar atividades de manuteno, evitando que erros

se propaguem pelo ciclo de vida;
Apresentam baixo custo devido ao fato do revisor no precisar
investir muito tempo ou mesmo no demandar ferramentas
sofisticadas para realiz-las. Entretanto uma alta taxa de
atividades de inspeo ao longo do pr0ocesso pode acrescer de
5% a 10% o custo final.
Figura 26 Comparativo de Com e Sem Inspeo
PROCESSO DE INSPEO DE SOFTWARE
Figura 27 Processo de Inspeo
Composta por PAPEIS E ATIVIDADES
68
PAPEIS: atuam ao longo das atividades da inspeo para que no final

do processo tenha um documento com os requisitos de software bem
elaborados.
- moderador:
- inspetor;
- autor do documento.
ATIVIDADES:
- planejamento: efetuado pelo moderador que identificada baseada
nas caractersticas do artefato, quem seriam os mais interessados em
participar da inspeo e distribua para as pessoas selecionadas nesta
atividade;
- preparao individual: recebiam o material e se preparavam para a
reunio para identificar defeitos.
- reunio de inspeo: depois marcava a reunio e durante ela era
feito a leitura critica do documento de requisitos para encontrar os
defeitos. No final tinha-se a lista de defeitos que era entregue ao autor
- retrabalho: fazer os reajustes de acordo com o que foi elaborado.
- continuao: verifica se precisa ou no passar por outra inspeo.
PROCESSO TRADICIONAL DE INSPEO
PLANEJAMENTO
Responsvel: moderador
Tarefas:
- Definir contexto da inspeo: descrio da inspeo, como a
preparao individual dever ocorrer, documento a ser inspecionado,
autor do documento, entre outros.
- Selecionar inspetores: recomenda-se utilizar entre 3 e 5 inspetores em
uma inspeo.
- Distribuir material.
PREPARAO INDIVIDUAL
- Responsvel: Inspetor
- Tarefas: estudar os artefatos e fazer anotaes sobre os artefatos.
REUNIO DE INSPEO
- Envolvidos: moderador, inspetores e autor
- Tarefas:
- Leitura do documento com a equipe discutindo possveis defeitos
(durao recomendada 2 horas);
- Produzir uma lista de defeitos;
- Em casos de discordncia a deciso sobre registrar um defeito ou no
(falso positivo) do moderador.
RETRABALHO
- Responsvel: Autor
- Tarefa: corrigir os defeitos encontrados.
CONTINUAO
- Responsvel: Moderador
- Tarefa:
69
- Analisar correes do autor e inspeo como um todo;

- Re-avaliar qualidade do artefato inspecionado;
- Decidir sobre a necessidade de uma nova inspeo.
WALKTHROUGHS
Alternativa com um processo menos rigoroso do que o de inspees de

software. Papis sugeridos: lder, autor, escrivo e revisores.
Procedimento: os participantes so guiados atravs dos artefatos pelo
lder (que eventualmente o prprio autor) em uma reunio. Durante est
reunio deve interromper a apresentao caso encontrem defeitos. Muitas
vezes condies de entrada e sada e decises so pressupostos pelo lder
que segue sua linha de raciocnio durante a apresentao.
Possuem custo aproximadamente igual ao de inspees mas seus
resultados so inferiores:
No providenciar resultados mensurveis;
No fornecer base para a aplicao de controle estatstico de processos,
necessrios para evoluir na maturidade de processos de software.
Pode ser usado para atividades de brainstorming para explorar
alternativas de projeto e resoluo de problemas (focadas em encontrar
defeitos).
GERENCIAMENTO DE MUDANA DE REQUISITOS
Figura 28 Esquema do Gerenciamento de Requisitos (Fonte: extrado da Web)
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:
70
Novos requisitos surgem durante o processo de desenvolvimento.

Diferentes pontos de vista possuem diferentes requisitos e esses so
frequentemente contraditrios.
Mudanas nos requisitos
A prioridade dos requisitos pode 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.
Os
principais
objetivos
desse
processo
so
(KOTONYA;
SOMMERVILLE, 1998):
Gerenciar alteraes nos requisitos acordados;
Gerenciar relacionamentos entre requisitos;
Gerenciar dependncias entre requisitos e outros documentos
produzidos durante o processo de software.
Para tal, o processo de gerncia de requisitos deve incluir as seguintes
atividades:
Figura 29 Atividades de Gerncia de Requisitos (Fonte:
WIEGERS, 2003)
O controle de mudana define os procedimentos, processos e padres

que devem ser utilizados para gerenciar as alteraes de requisitos,
assegurando que qualquer proposta de mudana seja analisada conforme
os critrios estabelecidos pela organizao (KOTONYA; SOMMERVILLE,
1998). Mudanas podem ser necessrias em diferentes momentos e por
71
diferentes razes. De maneira geral, o controle de mudanas envolve

atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003):
Verificar se uma mudana vlida;
Descobrir quais os requisitos e artefatos afetados pela mudana, o
que envolve rastrear informaes;
Estimar o impacto e o custo das mudanas;
Negociar as mudanas com os clientes;
Alterar requisitos e documentos associados.
EVOLUO DOS REQUISITOS
Figura 30 Evoluo dos Requisitos (Fonte: extrado da Web)
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;
72
Requisitos Consequentes: 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.
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS
Durante o processo de engenharia de requisitos, ser necessrio

planejar:
IDENTIFICAO DOS REQUISITOS: Como os requisitos so
individualmente identificados;
PROCESSO DE MUDANA DE GERENCIAMENTO: O processo

seguinte anlise de uma mudana de requisito;
POLTICAS
DE
RASTREABILIDADE:
quantidade
de
informaes (histrico) sobre o relacionamento entre requisitos
que mantida. Como rastrear as mudanas de requisitos e seus
possveis impactos.
SUPORTE FERRAMENTA: suporte ferramenta necessrio

para auxiliar no Gerenciamento de Mudanas de Requisitos.
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
dependentes;
DE
REQUISITOS:
links
entre
requisitos
RASTREABILIDADE DO PROJETO: links dos requisitos para o

projeto.
SUPORTE FERRAMENTA:
Armazenamento dos requisitos: Os requisitos devem

gerenciados em uma memria de dados segura e gerenciada;
ser
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.
73
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.
Figura 31 Principais Estgios do Gerenciamento de Mudanas de Requisitos (Fonte:

extrado da Web)
ETAPAS PARA O RASTREAMENTO
1.Rastrear requisitos do usurio nos do sistema;

2.Rastrear requisitos no projeto;
3.Rastrear requisitos nos procedimentos de teste;
4.Rastrear requisitos do usurio no plano.
Figura 32 Etapas para o Rastreamento (Fonte: extrado da Web)
74
EXERCCIOS
1) Assinale a opo correta quanto a requisitos de software.( CESPE - 2010 TRE-MT - Tcnico Judicirio - Programao de Sistemas)
a)Requisitos funcionais descrevem as propriedades emergentes do
sistema, como segurana e tempo de resposta.
b)Requisitos no funcionais so descritos de forma qualitativa e no
quantitativa
c) Requisitos so provenientes de pessoas relevantes para o sistema, e
no de outros sistemas que interagem com o sistema que est sendo
especificado.
d)A matriz de rastreabilidade no oferece suporte para requisitos
funcionais.
e)Reviso de requisitos, prototipao e gerao de casos de teste so
exemplos de tcnicas de validao de requisitos.
2) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de
requisitos que podemser utilizadas em conjunto ou individualmente.
So elas (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas):
a) gerao de casos de teste, revises de requisitos, gerenciamento de
mudanas e prototipao.
b) revises de requisitos, prototipao, gerao de casos de teste e
anlise automatizada da consistncia.
c) prototipao, anlise automatizada da consistncia, revises de
requisitos e gerenciamento de mudanas.
d) gerenciamento de mudanas, anlise automatizada da consistncia,
revises de requisitos e gerao de casos de teste.
e) anlise automatizada da consistncia, prototipao, gerenciamento de
mudanas e gerao de casos de teste.
3) No que diz respeito aos sistemas de software, teste um conjunto de
atividades que podem ser planejadas antecipadamente e conduzidas
sistematicamente. Um tipo I de teste se refere ao conjunto de atividades
que garante que o software implementa corretamente uma funo
especfica, associado construo do produto de forma correta ou no,
enquanto um tipo II se refere a um conjunto de atividades diferente que
garante que o software construdo corresponde aos requisitos do cliente,
associado construo do produto certo. Esses testes do tipo I e II so
denominados, respectivamente (FGV - 2010 - FIOCRUZ - Tecnologista em
Sade - TI - Sistemas de Informao):
a) Depurao e homologao.
b) Homologao e aceitao.
c) Aceitao e verificao.
d) Verificao e validao.
e) Validao e depurao.
4) Verificao e validao so atividades da anlise de software,
necessrias para se identificar o que o software precisa executar, seguida
75
de uma avaliao do usurio quanto s atividades definidas. (CESPE - 2011 TJ-ES - Tcnico de Informtica - Especficos)
___ CERTO ___ ERRADO
5) Os produtos de trabalho resultantes da engenharia de requisitos so
avaliados quanto qualidade durante a etapa de validao de requisitos.
Analise
os
itens
a
seguir
referentes
a
essa
etapa:
I. Um dos principais mecanismos de validao de requisitos a avaliao
tcnica formal.
II. O modelo de anlise pode garantir que os requisitos foram
consistentemente declarados.
III. frequentemente til examinar cada requisito em face de um
conjunto de questes do tipo checklist.
IV. A equipe de reviso que avalia os requisitos inclui apenas pessoas com
conhecimento tcnico na rea de TI, como engenheiros de softwares,
desenvolvedores etc.
Est correto o que consta em:
a) I, II, III e IV
b) II e IV
c) I, II e IV
d) II, III e IV
e) I, II e III
6) Assim como o software, os requisitos tambm devem ser avaliados
quanto qualidade. A validao, atividade da engenharia de requisitos,
responsvel por garantir que os requisitos tenham sido declarados de
forma clara e precisa. Alm disso, a validao busca detectar
inconsistncias, erros e omisses, objetivando alinhar os requisitos s
normas estabelecidas para o projeto, produto e processo. (CESPE - 2011 TJ-ES - Analista Judicirio - Anlise de Sistemas - Especficos)
___ CERTO ___ ERRADO
76
MATRIZ DE RASTREABILIDADE
Matrizes de rastreabilidade so os principais artefatos produzidos na
fase de gerncia de requisitos. Elas relacionam os requisitos identificados
a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas
possam ser procuradas rapidamente para entender como uma modificao
em um requisito vai afetar diferentes aspectos do sistema.
RASTREABILIDADE
Tcnica usada para prover relacionamento entre requisitos, projeto e
implementao final do sistema. uma caracterstica de sistemas nos
quais os requisitos so claramente ligados s suas fontes e aos artefatos
criados durante o ciclo de vida de desenvolvimento de sistema.
a habilidade de descobrir a histria de toda caracterstica do
sistema, dado que os impactos de mudanas nos requisitos podem ser
identificados. (Hamilton, 1991)
Figura 33 Esquema Rastreabilidade
OBJETIVOS
GERENCIAR O PROJETO:
o Acompanhar a evoluo
desenvolvimento;
dos
requisitos
ao
longo
do
77
o Registrar
status
de
cada
requisito
em
relao
ao
desenvolvimento, em relao a modificaes aceitas e
justificativas associadas;
o Estabelecer uma viso comum entre o cliente e a equipe de
projeto em relao aos requisitos que sero atendidos pelo
projeto de software;
ACOMPANHAR AS MUDANAS:
o Atualmente tem-se a convico que mudanas em requisitos ao
longo do processo de desenvolvimento de software fazem parte
do processo;
o Motivos: necessidades no identificadas inicialmente, alteraes
no contexto, correo de erros ou mesmo novas perspectivas por
parte dos stakeholders;
o Alteraes em requisitos podem implicar em mudanas em
artefatos de projeto, cdigo, casos de testes, etc.
GARANTIA DE QUALIDADE:
o Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO
9001.
A rastreabilidade auxilia:
ANLISE DE COMPLETUDE NA ALOCAO DE REQUISITOS A
COMPONENTES DO SOFTWARE: A avaliao dos links de
rastreabilidade de requisitos a artefatos de design e implementao
identifica requisitos ainda no alocados ou implementados;
RESOLUO DE REQUISITOS EM CONFLITO: diferentes representantes

do cliente ou usurio trazem suas necessidades em relao ao sistema.
Essas necessidades iro gerar requisitos que podem ser conflitantes. A
rastreabilidade possibilita identificar rapidamente as origens dos
requisitos em conflito, para soluo do problema detectado;
VERIFICAO: na anlise de cobertura de requisitos nos testes, a

rastreabilidade entre requisitos e casos de testes permite identificar
requisitos ou funcionalidades para os quais foram previstos casos de
testes;
CORREO DE DEFEITOS (BUGS): aps a identificao do componente

que originou o erro, a anlise do problema pode indicar que a origem
do defeito no est no cdigo propriamente dito, mas nos requisitos ou
em artefatos de design. Os links indicaro quais artefatos devero ser
revistos e corrigidos, incluindo testes;
VALIDAO: a etapa final de validao do sistema criado junto ao

conjunto de clientes e usurios se beneficia da rastreabilidade,
permitindo mostrar a completude da implementao em relao aos
requisitos acordados entre clientes e desenvolvedores;
78
ANLISE DE IMPACTO NA EVOLUO DO SISTEMA: a existncia de

links de rastreabilidade entre requisitos e componentes possibilita
identificar rapidamente quais componentes sero afetados por
mudanas em um requisito ou mesmo por incluso de novos requisitos;
PREVISO DE CUSTOS E PRAZOS: quando uma nova funcionalidade
deve ser includa no sistema em implementao ou quando uma
mudana num requisito j implementado solicitada, o gerente de
projeto necessita de estimativas confiveis para poder negociar custos
e prazos junto ao cliente;
GERENCIAMENTO DE RISCOS: a rastreabilidade apoia a identificao

de artefatos atingidos por cada fator de risco, possibilitando a
elaborao de estratgias para tratamento ou mitigao dos riscos (por
exemplo, riscos associados a custos e cronograma);
UPGRADE DE HARDWARE E/OU AMBIENTE OPERACIONAL: em sistemas

embarcados ou em software utilitrio existem relacionamentos fortes
entre componentes do hardware e do software. Na mudana de verso
do ambiente operacional ou na troca de hardware, links de
rastreabilidade possibilitam identificar rapidamente componentes
atingidos;
REUSO DE COMPONENTES: obter ativos reusveis a partir de sistemas

existentes tem incrementado o reuso na indstria; uma abordagem que
propicia este incremento utiliza a recuperao de links de
rastreabilidade entre cdigo e documentos escritos em linguagem
natural.
MATRIZ DE RASTREABILIDADE DEFINIDAS

Com a matriz abaixo possvel visualizar as ligaes entre os requisitos
de software.
79
Figura 34 Matriz de Rastreabilidade
A matriz de rastreabilidade de requisitos destinada a apoiar o

trabalho do engenheiro de software nas atividades do processo de
desenvolvimento, criando automaticamente elos de rastreabilidade entre
os requisitos e cenrios de aplicao.
<nome da empresa>
APROVAES
Nome
Data
Assinatura
Nome
Data
Assinatura
<nome do projeto>
Matriz de Rastreabilidade de Requisitos
Data: dia/ms/ano
Elaborado por:
<nome(s) do(s) elaborador(es)>
ID Requisito
Descrio Prioridade Responsvel / Verso Caso de Teste
Data
Data
Proprietrio
Alterao Concluso
Id do
Descrio Prioridade
requisito (Feature)
do
elencada
identificado no
requisito.
para o
Documento
requisito.
(Anlise) de
Requisitos.
Figura 35 Modelo de Matriz
Nome do
Nmero Identificao Data de
Data de
responsvel da verso do caso de alterao concluso
pela
do
teste elaborado
do
do
execuo e requisito.
para o
requisito. requisito.
controle do
requisito.
requisito.
de Rastreabilidade (Fonte: extrado da Web)
EXERCCIOS
1) As polticas de rastreabilidade de requisitos so decididas durante o

estgio de (FCC - 2010 - MPE-RN - Analista de Tecnologia da
Informao - Engenharia de Software)
80
a) Agregao dos requisitos funcionais, apenas.

b) implementao do sistema, apenas.
c) implementao do sistema.
d) eliminao dos requisitos no funcionais.
e) gerenciamento de requisitos.
2) O gerenciamento de requisitos deve compreender e controlar
mudanas nos requisitos de sistema, alm de avaliar os seus impactos.
Para atingir esse propsito, podem ser mantidas informaes de
rastreabilidade a serem usadas para avaliar quais outros requisitos
seriam afetados por uma mudana, bem como o impacto da mudana
de requisitos no projeto e na implementao do sistema. (CESPE - 2009
- SECONT-ES - Auditor do Estado Tecnologia da Informao)
___ CERTO ____ ERRADO
ORIENTAO A OBJETOS
HISTRIA
Adaptado da Revista: ENGENHARIA DE SOFTWARE MAGAZINE
Em 1962, Ole-Johan Dahl e Kristen Nygaard criaram uma

linguagem chamada Simula, baseada na linguagem Algol 60 que tinha
o objetivo permitir o projeto de simulaes. Surgia a primeira
linguagem orientada a objetos, apresentando os conceitos de classe e
herana.
Essa foi a semente que inspirou o desenvolvimento de uma nova
linguagem, a primeira totalmente orientada a objetos o SmallTalk.
Nela, no existem tipos primitivos, tudo representado em forma de
objeto: nmeros, caracteres etc.
Disponibilizada ao pblico no incio dos anos 80, SmallTalk
solidificou para a comunidade os conceitos de classe, objeto, atributo,
mtodo, encapsulamento, herana e mensagem.
A partir da, novas linguagens surgiram, como o C++ (verso OO
da linguagem C), Object Pascal (verso OO do Pascal), Eiffel e Java
(criado a partir do C++).
81
Figura 36 Tela do programa Smalltalk
http://zeromeia.net84.net/smalltalk/programando.html
CONCEITOS FUNDAMENTAIS
Figura 37 Conceitos fundamentais da UML
Surgiu devido a necessidade em se enfatizar unidades discretas, e

obter a reutilizao de cdigo, mantendo-se a qualidade do software.
82
O foco da Orientao a Objetos sobre os dados, em vez dos

processos, compondo mdulos auto-suficientes os objetos ,
encerrando em sua estrutura todo o conhecimento dos dados e dos
processos para manipulao desses dados.
Objetivo Principal: possibilidade de se abstrair diretamente os
conceitos do mundo real, sem subterfgios para se chegar soluo
computacional.
Se um dos conceitos fundamentais de orientao a objetos no for
atendido, no podemos afirmar que determinada tecnologia possa ser
nomeada como orientada a objetos. Exemplo: Visual Basic, que antes da
sua verso .NET no implementava todos os conceitos.
OBJETO
Figura 38 Exemplo de Objeto
Objeto qualquer coisa existente no mundo real, em formato

concreto ou abstrato, ou seja, que exista fisicamente ou apenas
conceitualmente, o qual se pode caracterizar e identificar
comportamentos.
Podemos afirmar que um objeto uma caixa-preta que recebe e
envia mensagens, ou seja, num sistema orientado a objetos, os objetos
trocam informaes por meio de mensagens.
Num sistema orientado a objetos no modelamos apenas objetos
de negcio. Muitas vezes, de acordo com a arquitetura utilizada,
modelamos objetos computacionais, visuais ou no.
Exemplo: ao levantarmos os requisitos para informatizar uma
concessionria, encontraremos o objeto automvel (fsico), da mesma
forma que podemos modelar o objeto venda (conceitual).
83
ATRIBUTO
Figura 39 Exemplo de Atributo
So as caractersticas ou propriedades associadas aos objetos.

Para os objetos de negcio, comum usarmos o conceito de atributo.
Para os objetos visuais, utilizamos o conceito de propriedade.
Exemplos:
atributos da classe Cargo: descricao e salario;
atributos da classe Automvel: modelo, cor, numeroPortas, ano,
placa, etc.
OPERAO X MTODO
Figura 40 - Exemplo de Operao x Mtodo
O comportamento dos objetos representado pelas operaes.

Contudo, a operao para um objeto representa apenas a definio
do servio que ele oferece a outras estruturas.
Quando tratamos da implementao dessa operao, ou seja, da sua
representao em cdigo, estamos nos referindo ao seu mtodo.
Os mtodos de uma classe manipulam somente as estruturas de
dados daquela classe, ou seja, para se ter acesso aos dados de outra
classe, isso deve ser feito por meio de mensagens.
84
Exemplo: operaes da classe Cargo:

cadastrar() e reajustarSalario(percentual: float).
RESUMINDO: as operaes so mtodos ou funes que atuam sobre
os objetos e afetam o comportamento dos mesmos.
CLASSE
Ao modelarmos uma classe precisamos sempre considerar o

contexto. Se no fosse isso, bastaria um famoso metodologista publicar as
solues para todas as classes de negcio. EXEMPLOS:
EXEMPLO 1: Desta forma, no teremos necessariamente os mesmos
atributos e operaes para a classe aluno, por exemplo, modelada num
sistema acadmico de uma escola de nvel mdio, e a mesma classe
aluno, modelada num sistema acadmico de uma Universidade. No
garantia termos os mesmos atributos e operaes nem se
considerarmos dois sistemas acadmicos modelados para distintas
Universidades.
EXEMPLO 2: classe Automvel. Se estivermos no contexto de uma
concessionria,
teremos
operaes
como:
cadastrar,
alterarProprietario, etc. Em contrapartida, se estivermos no contexto
de um simulador para auto-escola, seu comportamento deve reproduzir
o objeto real, com operaes como: ligar, aumentar marcha, reduzir
marcha, acelerar etc.
ESTADO
So os valores assumidos pelos atributos de um objeto.

Exemplo: em um determinado objeto cargo, o estado do seu atributo
salario o valor R$ 5000,00.
MENSAGEM
a solicitao que um objeto faz a outro, invocando a execuo de

um determinado servio. Por exemplo, para que um objeto possa calcular
a folha de pagamento, ele precisa saber o salrio de cada funcionrio.
Assim, ele passa uma mensagem ao objeto cargo, solicitando a execuo
do servio obterSalario, que nada mais do que uma operao do objeto
cargo.
ENCAPSULAMENTO
a utilizao de um sistema orientado a objetos que no deve

depender de sua implementao interna, e sim de sua interface.
Isso garante que os atributos e os mtodos estaro protegidos, s
podendo ser acessados pela interface disponibilizada pelo objeto, ou seja,
sua lista de servios. Essa proteo garante que os usurios de uma
classe no sejam influenciados por quaisquer alteraes feitas em seu
contedo. Exemplo:
85
Na prtica, imagine uma classe Produto que possua a operao

obterPrecoVenda: float. Essa operao pblica, tornando-se um servio
disponibilizado a outras classes. Em qualquer rotina que se queira mostrar
o preo de venda de um produto, basta instanciar um objeto Produto, e
passar uma mensagem para executar o servio, ou seja, chamar a
execuo da operao obterPrecoVenda.
Suponha que as rotinas A, B, C e D usem esse servio e que at
ontem esse valor de venda fosse obtido apenas com um clculo simples:
precoVenda = precoCusto * (1 + lucro/100)
Esse clculo est na implementao de uma operao, ou seja, o
seu mtodo, e fica encapsulado (escondido).
Suponha agora que hoje foi colocada uma nova verso da classe
Produto, na qual esse clculo passa a ser:
precoVenda = precoCusto * (1 + lucro/100)
precoVenda = precoVenda * (1 - descontoMes/100)
As rotinas A, B, C e D recebero uma exceo em virtude da regra de
clculo ter sido alterada? No, eu respondo. transparente para essas
rotinas (e precisa ser assim) que houve alterao na forma de clculo do
preo de venda. Se estivermos diante de um componente (por exemplo,
uma dll), absolutamente nada ser preciso fazer com essas rotinas. Se
estivermos com as rotinas dentro do mesmo pacote que a classe, basta
recompilar tudo.
HERANA
Ao refinarmos a modelagem de um sistema comum encontrarmos

caractersticas redundantes entre objetos. Essa redundncia pode ser
evitada pela separao dos atributos e operaes numa classe comum,
identificada como superclasse.
Essa classe comum (superclasse) passa a ser a generalizao de
outras classes que encerram em si apenas os atributos e operaes
especficos a cada uma. Exemplo: Suponha que temos duas classes:
Cliente e Funcionario. So atributos dessas classes:
Cliente (cpf, nome, dataNascimento, endereco, dataPrimeiraCompra);
Funcionario (cpf, nome, dataNascimento, endereco, dataAdmissao,
funcao).
Imagine que existem operaes que validam o CPF, retornam a idade
de um cliente ou funcionrio, ou formatam o endereo. E que todas essas
funes apaream em duplicidade nas classes Cliente e Funcionrio. Numa
situao dessas, o que se espera na orientao a objetos que essa
redundncia seja eliminada com a herana.
Assim, cria-se uma superclasse Pessoa, e a ela so atribudos todos
os atributos e operaes comuns Cliente e Funcionario. Sobram nas
subclasses (Cliente e Funcionario) somente os atributos e operaes
especficos a cada um. Na prtica, ao se usar uma subclasse, tem-se
acesso a todos os elementos das classes ascendentes, como se tivessem
sido criadas na prpria classe filha. Abaixo o resultado:
CLASSES
Antes da herana
Cliente
Funcionario
86
ATRIBUTOS
cpf
nome
dataNascimento
endereco
dataPrimeiraCompra
cpf
nome
dataNascimento
endereco
dataAdmissao
funo
Aps a herana
Pesoa
cpf
nome
dataNascimento
endereco
Cliente
dataPrimeiraCompra
Funcionrio
dataAdmissao
funcao
Quando uma subclasse possui mais do que uma superclasse dito
que temos uma herana mltipla.
A herana no precisa se limitar aos objetos de negcio. Pelo
contrrio, um dos maiores ganhos que ns temos com a orientao a
objetos a possibilidade de se estender todo esse conceito de utilizao
para todos os componentes do nosso sistema.
Exemplo: podemos criar uma classe para um relatrio, com o
logotipo da empresa, dados de identificao do cabealho e do rodap, e a
partir dessa classe, herdar todos os outros relatrios do sistema,
particularizando em cada um, as caractersticas especficas. Imagine o
esforo necessrio para se trocar o logo e incluir o nome do usurio
logado em todos os 1000 relatrios de um sistema: calculo uns dois
minutos.
POLIMORFISMO
Uma operao pode ter implementaes diferentes em diversos

pontos da hierarquia de classes. Isso significa que ela ter a mesma
assinatura (mesmo nome, lista de argumentos e retorno), porm
implementaes diferentes (mtodos). Isso o polimorfismo (poli =
muitas; morphos = forma).
Exemplo: H uma operao calcularSalario() que pertence classe
Funcionario. Herdamos de Funcionario a classe Professor, o que resulta
automaticamente na herana de calcularSalario(). Contudo o clculo do
salrio de um professor no o mesmo que o clculo do salrio de um
87
funcionrio, o que nos leva a ter a mesma operao, porm com mtodos
diferentes.
ANLISE ORIENTADA A OBJETOS

O que anlise????
A anlise visa investigar e resolver um problema. O objetivo da

anlise levar o analista ou projetista a investigar e a descobrir como
tratar o problema que ele tem em mos. Ao finalizar a anlise, dever
ocorrer uma compreenso completa do problema
e, portanto, o
projeto ser a sua soluo.
A anlise orientada a objetos uma atividade essencial num
processo de desenvolvimento de software.
Seu objetivo principal identificar objetos, atributos desses
objetos e as operaes que atuam sobre eles.
Note que a anlise essencial para criao de um modelo de
classes do sistema a partir dos casos de uso (da etapa de
levantamento de requisitos). O objetivo da anlise identificar as
classes necessrias para implementar os casos de uso do sistema,
como discutido adiante.
Um processo de desenvolvimento de software compreende um
conjunto de atividades, dentre elas, levantamento de requisitos,
anlise e projeto como etapas iniciais do processo de desenvolvimento
de software.
Antes de iniciar a modelagem com uma linguagem como a UML,
devemos proceder a anlise orientada a objetos, que compreende os
seguintes passos:
1) Entender o problema do cliente e identificar e documentar os
requisitos;
2) Descrever os requisitos funcionais usando diagramas de casos de
uso da UML;
3) Identificar objetos e classes a partir das informaes no documento
de requisitos, descrio do sistema e especificao de casos de uso;
4) Identificar relacionamentos entre as classes do item 3;
5) Identificar atributos e operaes (para as classes identificadas no
item 3);
6) Elaborar e analisar os diagramas de classes de sistema, adicionando
e/ou corrigindo atributos e operaes, bem como revisando os
relacionamentos identificados.
88
EXERCCIOS
1)
O paradigma de orientao a objetos centrado em conceitos que

envolve os seguintes princpios fundamentais: abstrao,
encapsulamento, herana e polimorfismo. Esse paradigma evoluiu
desde a sua concepo original e tornou-se uma fora pivotal no
desenvolvimento da cincia, da tecnologia e de quaisquer outros
domnios em que aplicada, inclusive na rea de desenvolvimento
de software. A esse respeito, assinale a opo correta. (CESPE 2010 - SAD-PE - Analista de Controle Interno Tecnologia da Informao)
a)
Na implementao de linguagens de programao orientada a objetos

(POO), o polimorfismo , usualmente, possvel por meio do emprego da
tcnica de ligao esttica, de modo que a escolha da implementao
especfica que tratar determinado envio de mensagem ser efetuada
em tempo de compilao.
O conceito de abstrao, presente na POO, oferece maior suporte aos
mtodos de desenvolvimento embasados em refinamentos top-down que
aos embasados em refinamentos bottom-up.
Na POO, o encapsulamento aplica-se, fundamentalmente, aos campos ou
variveis de estado de determinado objeto, sendo de pouca utilidade a
sua aplicao a mtodos.
Uma das formas comuns de se evitar o uso excessivo de herana como
mecanismo de refinamento de POO o emprego de delegao, que evita
a criao de nmero excessivo de subclasses em modelos orientados a
objetos.
Nas linguagens orientadas a objeto da atualidade, comum o uso de
herana mltipla, que permite a determinada classe herdar diretamente
das implementaes de uma ou mais classes, possibilitando mais
expressividade semntica e facilitando a manipulao do sistema de
tipos nessas linguagens.
b)
c)
d)
e)
2) Com relao ao emprego de conceitos do paradigma de orientao a

objetos na anlise e no projeto de sistemas de software, assinale a
opo correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno
Tecnologia da Informao)
a)
b)
c)
Os mtodos clssicos de anlise e de projeto orientado a objetos buscam

refinar aplicao orientada a objetos, desde os requisitos at o cdigo,
empregando o conceito de desenvolvimento sem compartimentos, no
qual as abstraes orientadas a objeto de nvel mais elevado so
transformadas em novo conjunto de abstraes que pouco preservam as
relaes com nvel superior por meio da transio bem definida entre as
fases do processo de desenvolvimento.
Um modelo orientado a objetos em nvel de anlise , tipicamente,
composto por grande nmero de classes inter-relacionadas, contendo
cada uma delas um conjunto de variveis de estado e mtodos em sua
interface.
Na modelagem orientada a objetos, a nfase reside nos dados mantidos
pelas abstraes do modelo, em oposio ao que ocorre nos mtodos
estruturados, cuja nfase inicial recai sobre as funes realizadas pelas
abstraes do modelo.
d)
e)
89
Aspectos como concorrncia, distribuio e persistncia so mais

comumente trabalhados na fase de projeto orientado a objetos que na
fase de anlise.
Um conjunto de cartes adequadamente desenvolvidos por meio da
tcnica CRC (Class-Responsibilities-Colaborators) constitui um artefato
til para um desenvolvedor iniciar o processo de codificao de um
programa orientado a objetos, na linguagem de programao na qual
tenha proficincia.
3)
Considere: Casas ABC Ltda., Empresa e Nome da Empresa.

Na orientao a objetos, os itens acima representam,
respectivamente, (FCC - 2008 - TCE-AL - Programador)
a) Atributo, classe e objeto.
b) Classe, atributo e objeto.
c) Classe, objeto e atributo.
d) Objeto, atributo e classe.
e) Objeto, classe e atributo.
4)
Os conceitos de generalizao e especializao da orientao a

objetos esto diretamente relacionados ao conceito de (FCC - 2008 TCE-AL - Programador)
a) Agregao
b) Associao
c) Encapsulamento
d) Polimorfismo
e) Herana
5)
Os componentes de uma biblioteca de software, no modelo

orientado a objetos, correspondem a (FCC - 2008 - TCE-AL Programador)
a) Objetos
b) Classes
c) Subclasses
d) Mtodos
e) Mensagem
6)
Sobre os conceitos de orientao a objetos, considere:

I. Classe encapsula dados para descrever o contedo de alguma
entidade do mundo real.
II. Objetos so instncias de uma classe que herdam os atributos
e as operaes da classe.
III. Superclasse uma especializao de um conjunto de classes
relacionadas a ela.
IV. Operaes, mtodos ou servios fornecem representaes dos
comportamentos de uma classe.
Est completo e correto o que consta em (FCC - 2011 - TRT - 23
REGIO (MT) - Analista Judicirio - Tecnologia da Informao)
a) I, II, III e IV
90
b) I, II e IV, apenas.
c) II, III e IV, apenas.
d) I e II, apenas
e) II e IV, apenas.
7) A Anlise e Projeto Orientado a Objetos, um recurso tem como meta
principal reduzir o nmero de variveis globais usadas dentro de
um programa, consistindo na separao dos aspectos externos de
um objeto, permitindo que a sua implementao possa ser
modificada sem que afete as aplicaes que o utilizam. Este
recurso denominado:
a) Encapsulamento
b) Independncia
c) Polimorfismo
d) Modularidade
e) Herana
8) Orientao a Objetos um paradigma de anlise, projeto e
programao de sistemas de software. A respeito desse
paradigma, assinale a afirmativa incorreta. (FGV - 2009 - MEC Analista de Sistemas - Especialista)
a) Um objeto pode ser considerado um conjunto de dados.
b) Os objetos possuem identidade, estado e comportamento.
c) Um evento pode existir se no houver um objeto a ele
associado.
d) Um objeto pode existir mesmo que no exista nenhum evento
associado a ele.
e) A orientao a objetos implementa o conceito de abstrao,
classe, objeto, encapsulamento, herana e polimorfismo.
9) Em desenvolvimento de sistemas, focalizar nos aspectos essenciais
inerentes a uma entidade e ignorar propriedades significa
concentrar-se no que um objeto e faz antes de se decidir como
ele ser implementado. Na orientao a objetos, este um
conceito tpico (FCC - 2011 - TRE-RN - Tcnico Judicirio - Programao de
Sistemas)
a) Herana
b) Reusabilidade
c) Abstrao
d) Encapsulamento
e) Compartilhamento
91
2 BIMESTRE UML
Adaptado da Revista Engenharia de Software Magazine
HISTRIA
Figura 41 Os trs amigos da UML
No incio da dcada de 90 havia mais de 50 mtodos disputando

o mercado para se tornar o mtodo principal para a orientao a
objetos. Contudo, a maior parte desses mtodos cometia um grave
pecado: ser uma extenso dos mtodos estruturados. Os maiores
prejudicados eram os usurios que no conseguiam encontrar uma
soluo nica e devidamente discutida.
Em 1995, mesmo com contribuies valiosas de outros
metodologistas, trs metodologias comearam a dominar o mercado:
OMT Object Modeling Technique de James Rumbaugh, mtodo Booch
de Grady Booch e OOSE Object-Oriented Software Engineering de
Ivar Jacobson.
Nasceu ainda como um mtodo, teve a mudana de perspectiva,
passando a ser uma linguagem de modelagem, desacoplando o
processo de desenvolvimento. Nascia a UML Unified Modeling
Language na sua verso 0.9.
92
Figura 42 Evoluo da UML (site official da OMG)
Em 1996, a UML j era vista pelas organizaes como uma tima

estratgia para seus negcios. A OMG (Object Management Group)
emitiu uma RFP (Request for Proposals), que objetivava receber
propostas de padronizao para uma metodologia de desenvolvimento
orientado a objetos. Respostas foram recebidas da comunidade de
engenharia de software e de grandes empresas (Digital, HP, IBM,
Microsoft, Oracle e Unisys, entre outras) fortalecendo a proposta da
UML.
Os objetivos que levaram os desenvolvedores da linguagem UML
a lanarem sua verso 2.0 foi reestrutur-la e refin-la de maneira a
torn-la mais fcil de aplicar, implementar e adaptar, melhorando sua
preciso e capacidade de reutilizao.
CONCEITO
A UML uma linguagem usada para especificar, visualizar e
documentar os artefatos de um sistema baseado em objeto, sob
desenvolvimento. Ela representa a unificao das notaes de Booch,
Rumbaugh e Jacobson, bem como as melhores ideias de uma
quantidade de outros tericos de metodologia. Unificando as notaes
usadas por esses mtodos baseados em objeto, a Unified Modelling
Language oferece a base para um padro de fato no domnio de anlise
e projeto baseado em objeto, apoiada em uma ampla base de
experincia (Rational Software Corporation).
93
Figura 43 Planta de uma casa
Ou seja, uma linguagem para visualizar, especificar, construir e

documentar artefatos de sistema de software. apenas uma abordagem
de notao e no propem/define como organizar as atividades de
projeto. Por isto, pode ser ajustada para satisfazer a diferentes situaes
de desenvolvimento e ciclos de vida. Onde:
VISUALIZAR: facilitar entendimento dos modelos projetados;
ESPECIFICAR: permite construir modelos precisos, no ambguos e
completos;
CONSTRUIR: por possuir semntica, os elementos da UML podem estar
associados a linguagens de programao.
UTILIZAO
A UML pode ser usada para modelar visualmente:
A interao de sua aplicao com o mundo externo;
O comportamento de sua aplicao;
A estrutura de seu sistema;
Os componentes de seu sistema;
A arquitetura de sua empresa;
Ajuda a visualizar o sistema;
Especifica a estrutura e o comportamento;
Proporciona um guia para a construo do sistema;
Documenta as decises tomadas.
94
NOTAO
Possui semntica bem definida;

Satisfaz
bem
as
necessidades
para
representao de um sistema;
bem entendida pelos participantes;
genrica e flexvel;
No
especifica para
linguagem de
programao.
VANTAGENS
Padro aberto e no proprietrio;

Independncia do processo de desenvolvimento;
Aplicvel a todas as fases do ciclo de desenvolvimento;
Independncia de linguagem de implementao;
Integrao das melhores prticas de modelagem;
Extensvel;
Suporte a conceito de alto nvel.
FASES DO DESENVOLVIMENTO UML
ANLISE DE REQUISITOS: captura as decises e necessidades dos

usurios (funes); diagrama de caso de uso mostra que os futuros
usurios podem esperar do aplicativo e no se preocupando de como
ser implementado. Mostra o que o usurio vai fazer. Ou seja,
documento com todas as funes que ele precisa;
ANALISE: objetos e mecanismos que estaro no domnio

problema. As classes se relacionam (diagrama de classes);
DESIGN: O resultado da analise atravs de perifricos,. Banco de

dados, comunicao entre sistemas, integrao, componentes que
precisam ser colocados;
PROGRAMAO: as classes do design so convertidas para a

linguagem orientada a objeto, como Java, .Net. Esta converso
dependendo da linguagem pode ou no ser fcil;
TESTES: unidade (classes individuais ou grupos, feita por

programadores), integrao (classes e componentes integrados para
verificar se as classes esto cooperando uma com as outras e
aceitao (testa o sistema como uma caixa preta verificando todo o
sistema. Se est de acordo com os requisitos).
do
95
COMPONENTES DA UML
VISES: mostra diferentes aspectos do sistema que esta sendo

modelado. uma abstrao com base em diversos diagramas;
MODELOS DE ELEMENTOS: representam definies comuns como

mensagens, relacionamentos entre as classes, casos de uso, etc.;
MECANISMOS GERAIS: comentrios suplementares, ou seja,

informaes ou semnticas sobre os componentes do modelo. Podem
ter mecanismos de extenso para estender a UML em um mtodo ou
processo;
DIAGRAMAS: grficos que descrevem as vises;
TESTES: h documentao de testes. Como por exemplo, casos de

teste.
MODELOS DE ELEMENTOS
So os conceitos utilizados nos diagramas. Pode ser uma
representao grfica presente em diversos diagramas ou definido para
que faa parte de um diagrama. So eles: CLASSES, OBJETOS, ESTADOS,
PACOTES, COMPONENTES e RELACIONAMENTOS9.
CLASSES
Descrio de um tipo de objeto. Objeto uma instncia de uma

classe que define os seus atributos e comportamentos. Exemplo:
Figura 44 Exemplo de Classe
OBJETOS
Elemento que pode manipular, acompanhar seu comportamento,

criar, destruir, etc. Tem a semntica de ser exibido sublinhado e antes da
classe vem o nome do objeto instanciado. Exemplo:
Usado para conectar outros modelos de elementos.
96
Figura 45 Exemplo de Objetos
ESTADOS
Todos os objetos possuem um estado que significa o resultado de

atividades executadas pelo objeto, e normalmente determinada pelos
valores de seus atributos e ligaes com outros objetos.
PACOTES
Mecanismo de agrupamento, onde todos os modelos de elementos

podem ser agrupados.
Figura 46 Exemplo de Pacotes
COMPONENTES
Pode ser tanto um cdigo em linguagem de programao como um

cdigo executvel j compilado.
97
Figura 47 Exemplo de Componentes
RELACIONAMENTOS
Os relacionamentos ligam as classes/objetos entre si criando relaes

lgicas entre estas entidades. Tipos de relacionamentos:
ASSOCIAO;
GENERALIZAO;
DEPENDNCIA E REFINAMENTOS.
TIPOS DE ASSOCIAO
NORMAIS: tipo mais comum. apenas uma conexo entre classes.

Possui um verbo ou substantivo na linha da associao e pode ter
uma seta indicando a direo.
Figura 48 Exemplo de Associao
RECURSIVA: possvel conectar uma classe a ela mesma atravs

de uma associao e que ainda representa semanticamente a
conexo entre dois objetos, mas os objetos conectados so da
mesma classe.
98
Figura 49 Exemplo de Recursividade
QUALIFICADA: associaes classificadas so usadas como

associaes de um para vrios (1..*) ou de vrios para vrios (*).
Figura 50 Exemplo de Qualificada
EXCLUSIVA: uma restrio em duas ou mais associaes. Onde

os objetos s podem participar de uma classe em determinado
momento (linha tracejada).
Figura 51 Exemplo de Exclusividade
ORDENADA: as associaes entre objetos podem ter uma ordem

implcita. O padro para uma associao desordenada.
CLASSE: uma classe pode ser associada a uma outra associao.
99
Figura 52 Exemplo de classe associativa
TERNRIA: mais de duas classes podem ser associadas entre si, a

associao ternria associa trs classes.
Figura 51 Exemplo de classe ternria
AGREGAO: caso particular da associao. Pode ser:

o
COMPARTILHADA: quando uma das classes uma parte, ou

est contida da outra, mas esta parte pode fazer estar contida
na outras vrias vezes em um mesmo momento;
Figura 52 Exemplo de agregao
100
COMPOSIO: uma classe que est contida na outra vive e

constitui a outra. Se o objeto da classe que contm for
destrudo, as classes da agregao de composio sero
destrudas juntamente j que as mesmas fazem parte da
outra.
Figura 53 Exemplo de composio
GENERALIZAO: relacionamento entre um elemento geral e um

outro mais especfico. Pode ser:
Figura 54 Exemplo de generalizao
NORMAL: a classe mais especfica (subclasse) herda tudo da classe mais

geral (superclasse);
RESTRITA: especifica informaes mais precisas sobre como a
generalizao deve ser usada e estendida no futuro. As restries
definem a generalizaes restritas com mais de uma subclasse:
DEPENDNCIAS: conexo semntica entre dois modelos de elementos,
um independente e outro dependente.
101
Figura 55 Exemplo de dependncia
REFINAMENTOS: tipo de relacionamento entre duas descries de

uma mesma coisa, mas em nveis de abstrao diferentes e podem
ser usados para modelar diferentes implementaes de uma mesma
coisa.
MECANISMOS GERAIS
ORNAMENTO: anexado ao modelo acrescentando semntica.

Exemplo separar o tipo de instancia que colocado em negrito.
Uma classe colocada em negrito e se h um objeto colocado
sublinhado. Outro a multiplicidade;
NOTA: nem tudo pode ser definido na linguagem e para colocar
observaes usamos notas em UML e pode ser colocada em
qualquer lugar do diagrama.
DIAGRAMAS
Um diagrama uma representao grfica parcial ou total de um
modelo. Apresentao grfica de uma coleo de elementos de modelo,
geralmente processados como um grfico de arcos (relacionamentos) e
vrtices (outros elementos de modelo) conectados.
A UML 2.0 (verso atual) define 13 tipos de diagramas divididos
em duas categorias de modelagem: ESTTICA (ESTRUTURAL) ou
DINMICO (COMPORTAMENTO).
DIAGRAMAS ESTRUTURAIS (ESTTICOS)
Definem estaticamente a arquitetura de um modelo. So usados

para modelar as coisas que compem um modelo - as classes, os
objetos, as relaes e os componentes fsicos. Alm disso, tambm so
usados para modelar os relacionamentos e as dependncias entre
elementos. Fazem parte dos diagramas da modelagem estruturada:
DIAGRAMA DE CLASSES apresenta classes conectadas por
relacionamentos. Usado para exibir entidades do mundo real, alm
de elementos de anlise e projeto;
DIAGRAMA DE OBJETOS apresenta objetos e valores de dados.
Corresponde a uma instncia do diagrama de classes, mostrando o
estado de um sistema em um determinado ponto do tempo;
102
DIAGRAMA DE COMPONENTES mostra as dependncias entre

componentes de software, apresentando suas interfaces;
DIAGRAMA DE ESTRUTURA COMPOSTA usado para mostrar a
composio de uma estrutura. til em estruturas compostas de
estruturas complexas ou em projetos baseados em componentes;
DIAGRAMA DE PACOTES usado para organizar elementos de
modelo e mostrar dependncias entre eles;
DIAGRAMA DE IMPLANTAO mostra a arquitetura do sistema
em tempo de execuo, as plataformas de hardware, artefatos de
software e ambientes de software (como sistemas operacionais e
mquinas virtuais).
DIAGRAMAS COMPORTAMENTAIS (DINMICOS)
Os diagramas dinmicos ou de comportamento apresentam as

variedades da interao e do estado instantneo dentro de um modelo
enquanto executado. So eles:
DIAGRAMA DE CASOS DE USO mostra os casos de uso, atores e
seus relacionamentos que expressam a funcionalidade de um
sistema;
DIAGRAMA DE ATIVIDADES representa a execuo de aes ou
atividades e os fluxos que so disparados pela concluso de outras
aes ou atividades;
DIAGRAMA DE MQUINA DE ESTADOS representa as aes
ocorridas em resposta ao recebimento de eventos;
DIAGRAMAS DE INTERAO:
o DIAGRAMA DE SEQUNCIAS mostra as interaes que
correspondem a um conjunto de mensagens trocadas entre
objetos e a ordem que essas mensagens acontecem;
o DIAGRAMA DE COMUNICAO antigo diagrama de colaborao,
que mostra objetos, seus inter-relacionamentos e o fluxo de
mensagens entre eles;
o DIAGRAMA TEMPORAL mostra a mudana de estado de um
objeto numa passagem de tempo, em resposta a eventos
externos;
o DIAGRAMA DE VISO GERAL DE INTERAO uma variao do
diagrama de atividades que mostra de uma forma geral o fluxo
de controle dentro de um sistema ou processo de negcios. Cada
n ou atividade dentro do diagrama pode representar outro
diagrama de interao.
103
Pode-se afirmar que possvel se completar a modelagem de um

sistema de pequeno ou mdio porte, com sucesso, com apenas trs
diagramas (casos de uso, classes e sequncias), tendo o suporte,
dependendo do contexto, de trs outros diagramas (objetos, atividades
e mquina de estados). O paradigma da orientao a objetos veio
definitivamente ocupar um espao que h muito se necessitava no
mercado de desenvolvimento. Cabe aos desenvolvedores entenderem a
importncia de se respeitar todos os seus conceitos, para que se
obtenha o melhor do que ele nos prope.
EXERCCIOS
1)
Os diagramas UML da categoria comportamental so os de (FCC 2008 - TCE-AL - Programador)

a) Classes, Objetos e componentes
b) Casos de Uso, Sequncias e Classes
c) Classes, Atividades e Sequncias
d) Casos de uso, atividades e mquina de estados
e) Objetos, estrutura composta e mquinas de estado
2)
Um diagrama UML uma apresentao grfica de uma coleo de

elementos
do
modelo
de
um
sistema.
O diagrama utilizado pela UML que apresenta a interao entre os
objetos em relao ao tempo o de (FESMIP-BA - 2011 - MPE-BA Analista de Sistemas)
a) Componentes
b) Implantao
c) Estado
d) Classes
e) Sequncia
3)
Na UML, os diagramas de sequncia e os diagramas de atividade,

tambm denominados diagramas de interao, auxiliam a modelar
os aspectos dinmicos de sistemas. Um diagrama de interao
formado pelo conjunto de objetos e seus relacionamentos e inclui
as mensagens que podero ser enviadas entre eles. (CESPE - 2010 TRE-BA - Tcnico Judicirio - Programao de Sistemas)
__ Certo __ Errado
4)
Analise as seguintes afirmativas sobre os Diagramas de Interao

da UML.
I. Um Diagrama de Interao mostra a interao entre um
conjunto de objetos e seus relacionamentos, incluindo as
mensagens que podero ser trocadas entre eles.
II. Diagramas de Sequncia e Diagramas de Colaborao so
Diagramas de Interao e modelam aspectos dinmicos de
sistemas.
104
III. Diagramas de Colaborao do nfase ordenao temporal

das mensagens trocadas entre os objetos.
Marque a alternativa CORRETA: (FUMARC - 2011 - BDMG - Analista de
Sistemas)
a) Afirmativas I e II so verdadeiras.
b) Afirmativas I e III so verdadeiras.
c) Afirmativas II e III so verdadeiras.
d) Todas as afirmativas so verdadeiras.
5) A respeito da linguagem UML correto afirmar que (Concurso
Serpro-2001):
a) no se trata de uma linguagem de documentao.
b) voltada para a representao conceitual e fsica de um sistema.
c) no abrange a documentao para a realizao de testes.
d) no deve ser empregada para a documentao de artefatos que
faam uso de sistemas completos de software.
e) uma linguagem utilizada para a realizao de testes de
programas.
6) Entre outros, a UML inclui os diagramas de (Concurso Serpro-2001):
a) classes, objetos, fluxo de dados e de atividades.
b) classes, implantao, grficos de estado e de sequncias.
c) objetos, classes, contexto, implantao.
d) classes, objetos, testes, implantao.
e) objetos, casos de uso, contexto, implantao.
7) Na UML, as classes A e B legam suas estruturas e comportamentos
classe C. Considerando apenas o fato apresentado nessa
circunstncia, correto afirmar que a se aplica tipicamente o
conceito de (FCC - 2009 - TRT - 7 Regio (CE) - Analista Judicirio - Tecnologia
da Informao)
a) delegao.
b) derivao.
c) herana mltipla.
d) mtodo polimrfico.
e) multiplicidade.
8) A UML define em sua verso 2.0, treze tipos de diagramas, divididos
em duas categorias: diagramas estruturais e diagramas dinmicos.
Assinale a alternativa que no indique um diagrama estrutural da
UML. (FGV - 2009 - MEC - Analista de Sistemas - Especialista)
a) Diagrama de Viso Geral.
b) Diagrama de Implantao.
c) Diagrama de Pacotes.
d) Diagrama de Classes.
e) Diagrama de Objetos.
105
DIA PORTABLE
Figura 56 Tela principal do Dia Portable
O Dia Portable uma ferramenta baseada no Microsoft Visio, com

a qual pode-se compor layouts, fluxogramas, organogramas e
diagramas em geral, contando tambm com objetos para modelagem
UML e de sistemas Estruturados. Este programa pode ser utilizado
tanto em seu computador como a partir de um pendrive.
Auxilia os analistas e desenvolvedores de sistemas na criao e
integrao dos diagramas de dados da UML com a lgica. Com ele
possvel especificar recursos, transaes, trocas de comunicao, plano
de custos com tempo, esforo, entre outras. Alm disto, alm de
modelagem de negcio voltada para informtica, tambm possvel
montar diversos tipos de diagramas.
A interface disposta de forma que no centro est o espao para o
projeto, acima esto os menus e opes e esquerda encontram-se as
ferramentas para modelagem. Ainda com relao a estas ferramentas,
elas esto dispostas em dois grupos. O mais acima possui formas
geomtricas, textos, setas e opes de linha para ligao. Logo abaixo
esto os objetos de um diagrama conforme categoria.
Basicamente estas categorias so quatro: variados, fluxograma,
UML e outras folhas. Esta ltima categoria contm 35 grupos de
objetos, constando entre eles alguns relacionados ciberntica, luzes,
peas de quebra cabea, hidrulicos, banco de dados, UML, BPMN,
106
cisco, entre muitos outros. Desta forma, muito pouco provvel que
voc no venha a encontrar o desenho que precisa para seu diagrama.
Para utiliz-lo simples, basta abrir um novo projeto e comear a
desenhar seus diagramas. Para inserir novos objetos, primeiro escolha
uma categoria na caixa de opes no lado esquerdo da tela. Feito isto,
escolha as formas que deseja inserir em seu projeto e para adicion-las
basta clicar sobre a figura com o mouse e arrast-la at o quadro (ou
clicar sobre a figura e sobre o quadro)
medida que uma figura vai sendo posicionada na tela, voc pode
observar seu enquadramento correto por meio do fundo quadriculado e
das rguas horizontais e verticais dispostas para tal funo. Se aps
inserir a figura houver algum problema, para apag-la basta selecionar
e utilizar o delete do teclado.
Na barra de ferramentas situada na borda superior do programa
esto disponveis diversos tipos de opes para ajudar em seu
desenho, como opes de criao de camadas, exibio de grade,
posicionamento, mtodos de entrada, seleo, gravao de seu
diagrama, entre outras.
107
MICROSOFT VISIO 2003
Figura 57 Tela principal do Visio 2003
Na barra de ferramentas situada na borda superior do programa

esto disponveis diversos tipos de opes para ajudar em seu desenho,
como opes de criao de camadas, exibio de grade, posicionamento,
mtodos de entrada, seleo, gravao de seu diagrama, entre outras.
Clique em Software e Banco de Dados e escolha...
DIAGRAMA DE MODELO UML
Surge a tela a seguir:
Figura 58 Tela do Diagrama do Modelo UML
Divide-se em:
ATIVIDADE DE UML
Figura 59 Atividade de UML
COLABORAO DE UML
Figura 60 Colaborao de UML
108
COMPONENTE UML
Figura 61 Componente UML
IMPLANTAO DE UML
Figura 70 Implantao de UML
SEQUNCIA DE UML
Figura 62 Sequncia de UML
GRFICO DE ESTADO DE UML
Figura 63 Grfico de Estado de UML
109
110
ESTRUTURA ESTTICA DE UML
Figura 64 Estrutura Esttica de UML
Nesta rea se encontra as formas para o diagrama de classes.

CASO DE USO
Figura 65 Caso de Uso
PROPRIEDADES DA FORMA
Para inserir uma forma necessrio selecion-la e arrast-la para a
rea de trabalho. Com a forma na rea de trabalho, d um clique duplo e
surge a tela de propriedades de acordo com a forma escolhida.
111
Figura 66 Exemplo de Propriedades
Para salvar o arquivo como imagem basta escolher o menu ARQUIVO,

SALVAR ou SALVAR COMO e escolher em SALVAR COMO TIPO, o Formato
JPEG (*.jpg):
Figura 67 Tela do Salvar Como
OBSERVAES
Neste site h uma apostila sobre o assunto:

http://www.projetoderedes.com.br/apostilas/apostilas_so.php
Serial: PHGVY-62VQH-6YR3J-46D86-TG2MT
112
DIAGRAMA DE CASO DE USO
Figura 68 Etapas do caso de uso
CASOS DE USO
Descreve um conjunto particular de funcionalidades do sistema,
modelando o dilogo que uma entidade externa, chamada ator, realiza
com o sistema.
Especifica o comportamento de um sistema ou parte dele.
tambm uma descrio do conjunto de passos que o sistema executar
para desempenhar suas funes.
baseado em um cenrio descritivo de como a entidade externa
interage com o sistema. Identifica eventos que podem ocorrer e
descreve a resposta do sistema para estes eventos.
Quando combinados, os casos de uso constituem todas as formas
de uso do sistema e fornecem uma viso do sistema focada na
funcionalidade.
Possibilita um formato de apresentao compreensvel que pode
ser utilizado para aprimorar a comunicao, especialmente entre os
projetistas da aplicao e os clientes. So muito usados nas fases
posteriores do ciclo de vida, ajudando na identificao dos objetos,
desenvolvimento de planos de teste e documentao.
113
Figura 57 Exemplo de diagrama de caso de uso
O fator mais importante para o caso de uso a ESPECIFICAO

PARA CADA CASO DE USO.
Anlise tradicional: O QUE O SISTEMA DEVE FAZER?
Anlise por caso de uso: O QUE O SISTEMA DEVE FAZER... E PARA
QUEM?
ATOR
So entidades do meio ambiente (externa ao sistema)
que interagem com o sistema para obter alguma
funcionalidade. Podem ser: humanos, outros sistemas,
organizaes, dispositivos externos, etc., que interagem com
o sistema. Alguns atores do incio a eventos enquanto outros
interagem com o sistema em decorrncia do resultado de outros
eventos.
COMO IDENTIFICAR OS ATORES
Quem utilizar as funcionalidades do sistema?

Quem ir manter, administrar e fazer com que o sistema permanea
em operao?
Quem se interessa pelos resultados produzidos pelo sistema?
Com quais outros dispositivos ou sistemas o sistema em foco ir
interagir?
CASO DE USO
Utilizado para representar as funcionalidades do
sistema. Representar o que o sistema faz (no como).
uso.
A descrio do caso de uso ocorre na especificao de casos de
Exemplo: Cliente de banco pode usar um caixa automtico para

sacar dinheiro, transferir dinheiro ou consultar o saldo da conta:
114
Ator: CLIENTE
Casos de Uso: sacar dinheiro, transferir dinheiro e consultar
saldo.
COMO IDENTIFICAR CASOS DE USO
O ator precisa ler, criar, destruir, modificar ou armazenar algum tipo de

informao no sistema?
O trabalho do ator pode ser simplificado ou tornado mais eficiente
atravs de novas funes no sistema?
Quais as funes que o ator necessita no sistema?
O que o ator necessita fazer?
Quais so os principais problemas com a implementao atual do
sistema?
Quais so as entradas e as sadas desejadas?
CENRIO
Um cenrio a descrio de uma das maneiras pelas quais um caso
de um pode ser realizado.
Um cenrio tambm chamado de instncia de um caso de uso.
Normalmente h diversos cenrios para um mesmo um caso de uso.
RELACIONAMENTO DE EXTENSO
Um caso de uso pode ser estendido por outro (funcionalidade).
Pode ser usada para:
Simplificar fluxos de eventos complexos;
Representar comportamentos opcionais;
Lidar com excees.
A extenso ocorre em pontos especficos (pontos de extenso).
115
A extenso pode ou no ser usada pelo caso de uso de origem.

O <<extend>> ocorre somente entre casos de uso.
Em uma especificao de caso de uso, a extenso seria o fluxo
alternativo (comportamento opcional).
RELACIONAMENTO DE INCLUSO
Um caso de uso pode ser incluir outro no sentido de sempre utilizar
suas funcionalidades. Pode ser usada para:
Representar comportamentos reutilizveis;
Simplificar fluxos de eventos complexos.
O <<include>> um vnculo obrigatrio, ou seja, SEMPRE usar as
suas funcionalidades (inclui todo o comportamento do caso de uso que
est sendo includo).
RELACIONAMENTO DE ESPECIALIZAO
Um caso de uso pode ser especializar outro (adio/refinamento do
fluxo de eventos original). Especializao permite modelar comportamento
de estruturas de aplicao em comum.
Este tipo de relacionamento ocorre entre atores e entre casos de uso.
RELACIONAMENTO ENTRE CASOS DE USO
GENERALIZAO:
classes;
mesma
semntica
da
generalizao
entre
INCLUDE: caso de uso base incorpora o comportamento do caso de

uso includo (reutilizao);
EXTEND: caso de uso base incorpora o comportamento de um outro

caso de uso em local especificado. Utilizamos este relacionamento
quando necessrio modelar parte do caso de uso que o usurio
pode ver como comportamento opcional do sistema.
116
Figura 71 Tipos de Relacionamentos
As setas do <<include>> e do <<extend>> so tracejadas, o que

muda o sentido da seta: no include, a seta parte do caso de uso base
para o caso de uso a ser includo. J no extend a seta parte do caso de
uso que estende para o caso de uso estendido.
Exemplo de INCLUDE:
Figura 72 Exemplo de diagrama de caso de uso <<include>>
117
Exemplo de EXTEND:
Figura 73 Exemplo de diagrama de caso de uso <<extend>>
EXEMPLO: ESTUDO DE CASO LOCADORA DE VECULOS

Uma locadora de veculos deseja um sistema para facilitar o atendimento a
seus clientes. O processo de aluguel de carros atual confuso e est gerando
insatisfao entre os clientes. A locadora composta basicamente pelos seus
funcionrios e carros para aluguel. Os funcionrios so identificados por cpf,
nome, endereo, telefone. J os carros esto divididos em diversos tipos:
popular, luxo, utilitrio, etc. As informaes importantes sobre os carros a serem
armazenadas so: cdigo (chapa do carro), tipo, modelo, ano, cor, chassis, km e
valor do aluguel (dirias e semanais).
Os funcionrios sero responsveis pelo cadastro dos clientes e dos carros
adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar
baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais
possuem uma taxa de desconto e um valor de quilometragem extra para seus
aluguis. Qualquer cliente identificado por RG, nome, CPF, telefone, endereo,
cidade.
Desta forma, o cliente poder solicitar o aluguel de carros a um funcionrio
da locadora. Os tpicos abaixo descrevem as funcionalidades do sistema.
Alugar Carro: cliente deve solicitar ao funcionrio o aluguel do carro. O
sistema verifica se o carro solicitado pelo cliente est disponvel. Caso
esteja, o processo de locao concludo e o carro passa a estar
indisponvel. A data de aluguel deve ser guardada para calculo do valor do
aluguel na devoluo.
Dar Baixa: cliente faz devoluo do carro para o funcionrio e solicita
nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel.
O funcionrio coloca o status do carro novamente como disponvel, solicita
ao sistema para calcular o valor a ser pago e emite o recibo para o cliente.
Cadastrar Cliente: cliente solicita ao funcionrio que o cadastre na
locadora. O funcionrio recebe os dados e cadastra-o.
118
Cadastrar Carro: funcionrio cadastra o carro adquirido.
CASOS DE USO: Alugar carro, dar baixa, cadastrar cliente e

cadastrar carro;
ATOR: Funcionario.
ANLISE DE CASOS DE USO

Os 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;
Escrever cenrios.
EXERCCIOS
1) A figura abaixo ilustra um Diagrama de Casos de Uso e utilizada

no desenvolvimento de projetos de sistemas, utilizando
ferramentas da Anlise Orientada a Objetos. O relacionamento
entre o ator Cliente e o caso de uso Comprar um produto,
denominado e definido como: (FGV - 2009 - MEC - Analista de Sistemas
- Especialista)
a)
b)
c)
d)
e)
2)
Associao/uma funcionalidade do sistema do ponto de vista

usurio
Generalizao/uma funcionalidade do sistema do ponto de vista
usurio.
Associao/uma funcionalidade do sistema do ponto de vista
relacionamento.
Globalizao/uma funcionalidade do sistema do ponto de vista
relacionamento.
Generalizao/ uma funcionalidade do sistema do ponto de vista
relacionamento.
ESTUDO DE CASO: RESERVA DE PASSAGENS AREAS:
119
do
do
do
do
do
120
Com base na lista de requisitos funcionais, elabore o diagrama de

caso de uso:
RF1: Sistema deve permitir o cadastro de usurios.
RF2: Sistema deve permitir que usurio se identifique.
RF3: Sistema deve consultar a classe de voo.
RF4: Sistema deve consultar o trecho da viagem.
RF5: Sistema deve permitir consulta aos aeroportos.
RF6: Sistema deve permitir consulta as datas disponveis de ida e
volta.
RF7:Sistema deve permitir que usurio consulta as formas de
pagamento.
RF8:Sistema deve enviar para os usurios cadastrados e-mails
promocionais.
RF9: Sistema deve permitir que usurio consulta CEP no sistema de
correios
RF10: Sistema deve permitir que o usurio solicite a reserva on-line.
RF11: Sistema deve gerar cdigo da reserva.
RF12: Sistema deve emitir e-mail para usurio confirmando a reserva
com dados.
RF13: Sistema deve permitir que usurio cancela a reserva.
RF14: Sistema deve permitir que o administrador emita relatrio de
reservas confirmadas.
RF15: Sistema deve permitir que o administrador emita relatrio de
reservas canceladas.
RF16: Sistema deve validar o pagamento junto com a operadora de
carto.
RF17: Sistema deve permitir que o Administrador emita relatrio de
usurio cadastrados.
RF18: Sistema deve permitir que usurio edite seus dados pessoais.
3)
ESTUDO DE CASO: GESTO DE USURIO DE SISTEMAS DE

FORMAO:
RF1:O software deve identificar e validar todos os usurios que
desejarem acess-lo, identificando o seu perfil.
RF2:O software deve disponibilizar ao usurio identificado: as
funcionalidades associadas ao seu perfil e ao seu papel no sistema
(coordenador, bolsista, etc), as funcionalidades de acesso restrito
e as funcionalidades de acesso pblico.
RF3:O software deve disponibilizar ao usurio no identificado somente
as funcionalidades pblicas.
RF4:O software deve permitir ao usurio recuperar a sua senha, caso
esquea.
RF5:O software deve permitir que o administrador inclua, altere ou
exclua usurios.
RF6:O software deve permitir que o administrador inclua, altere ou
exclua perfis de acesso.
121
RF7:O software deve permitir que o administrador associe as

funcionalidades disponveis nos mdulos aos perfis cadastrados ou
exclua dos perfis as funcionalidades previamente associados.
RF8:O software deve permitir que o administrador associe um usurio
a um perfil de acesso.
RF9:O software deve permitir ao administrador consultar as
funcionalidades associadas a um perfil.
RF10:O software deve permitir ao administrador consultar aos usurios
associados a um determinado perfil.
RF11:O software deve permitir ao administrador indicar se
determinado usurio pode administrar seus substitutos ou no.
RF12:O software deve permitir que os usurios devidamente
autorizados designem um ou mais substitutos com os respectivos
perodos de substituio (data inicial e final) e selecionem um
subconjunto das suas funcionalidades as quais os substitutos tero
acesso.
RF13:O software deve permitir que todos os usurios faam a
manuteno de seus dados pessoais: email, localizao, senha e
telefones.
RF14:O software deve permitir que os administradores reenviem a
senha de qualquer usurio e que os usurios reenviem a prpria
senha.
RF15:O software deve gerar senhas temporrias, vlidas somente no
primeiro login, quando as senhas forem reenviadas pelos
administradores ou pelos prprios usurios.
RF16:O software deve solicitar a troca de senha, aps o login, para
todas as senhas que j expiraram.
RF17:O software deve, caso o usurio corrente seja um substituto,
apresentar a lista de usurios que ele est substituindo na data
corrente.
RF18:O software deve, caso o usurio corrente seja um substituto,
permitir que ele selecione o usurio com o qual vai atuar, caso ele
seja substituto de mais de um usurio.
4) Estudo de Caso: Transportadora:
Os funcionrios da transportadora devem cadastrar clientes, filiais,
veculos, funcionrios, tipos de veculos, cidades, distancias, categorias
de frete e fretes de clientes.
Clientes so pessoas fsicas e possuem: nome, endereo e telefone.
Filiais tm: nome, endereo, telefone, funcionrio responsvel e
vrios veculos. Veculos devem possuir placa e um tipo de veiculo,
alm de ser necessariamente de uma filial.
Funcionrios so identificados pela matricula e tm ainda: nome,
endereo, telefone e dependentes (nome e data de nascimento),
alm de estar associado, obrigatoriamente a uma filial. Tipo de
122
veculo apresenta uma descrio (caminho, moto, etc) e o peso

mximo que Pode transportar alm de estar associado a veculos.
Cidades contm nome e estado a que pertence, representando as
cidades abrangidas pela empresa. Distncia envolve as cidades
origem e destino e para cada par de cidades atendidas, deve haver
a distncia em quilmetros entre elas.
Categoria do frete deve conter descrio e um percentual, que deve

incidir sobre o valor do frete onde, por exemplo, entregas rpidas
tm aumento de 10% entregas super-rpidas tem aumento de 30%
e entrega normal no tem acrscimo no valor. Cada frete tem um
cdigo, um cliente, o veiculo deve efetuar o frete, cidade origem e
destino, funcionrio responsvel e itens a serem transportados, no
podendo haver um frete sem os dados citados. Ainda precisa ter o
valor a ser calculado atravs da distncia percorrida entre as
cidades: origem e destino e da categoria do frete. Para isso, deve
existir um valor padro para o km rodado. Um item de transporte
cada objeto a ser transportado num frete e deve possuir apenas
uma descrio e seu peso. Por fim, temos que o sistema ainda deve
emitir Nota Fiscal com todas as informaes de um determinado
frete, logo aps o seu cadastramento.
a) Diagrama de Caso de Uso;

b) Especificao do caso de uso: Cadastrar Cliente.
5) Com base nos requisitos funcionais, criar um diagrama de caso de
uso:
RF01 Cadastrar aparelho de refrigerao
RF02 Efetuar logon de funcionrio
RF03 Cadastrar funcionrio
RF04 Consultar histrico
RF05 Consultar temperatura de ambiente
RF06 Alterar temperatura de ambiente
RF07 Encaminhar ordem de servio
RF08 Gerar relatrio de gastos
RF09 Gerar relatrio de performance e consumo
RF10 Consultar funcionrio
RF11 Remover funcionrio
RF12 Consultar aparelho de refrigerao
RF13 Remover aparelho de refrigerao
6) ESTUDO DE CASO: LOCADORA DE VECULOS
Uma locadora de veculos deseja um sistema para facilitar o
atendimento a seus clientes. O processo de aluguel de carros atual
confuso e est gerando insatisfao entre os clientes. A locadora
formada basicamente pelos seus clientes e carros para aluguel. Os
carros esto divididos em diversos tipos: popular, luxo e utilitrio. As
informaes importantes sobre os carros a serem armazenadas so:
123
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem

e valor do aluguel (diria).
Os funcionrios sero responsveis pelo cadastro dos clientes e
dos carros adquiridos pela locadora, por efetuar o aluguel de um carro
para o cliente e dar baixa no aluguel. Existem clientes especiais e
clientes comuns. Os especiais possuem uma taxa de desconto e um
valor de quilometragem extra para seus aluguis. Qualquer cliente
identificado por RG, nome, CPF, telefone, endereo, contato.
a) Diagrama de Caso de Uso;
b) Especificao do caso de uso: Cadastrar Cliente e Efetuar Aluguel.
7) ESTUDO DE CASO: SALO DE FESTAS
RF01 - O software dever permitir que o gerente cadastre sales de festas.

RF02 - O software dever permitir que o gerente cadastre profissionais.
RF03 - O software dever permitir que o gerente realize o cadastramento de
servios utilizados em uma festa de casamento, como buffet, carros
utilizados.
RF04 - O software dever permitir que o cliente realize o cadastramento da
lista de convidados.
RF05 O software dever permitir que o cliente realize o cadastramento das
lojas de presentes.
RF06 - O software dever permitir que o cliente elabore da configurao da
festa pelo cliente.
RF07 - O software dever permitir a gerao do oramento para o cliente.
RF08 - O software dever permitir que o gerente realize a impresso de
relatrios de festas.
RF09 - O software dever permitir que o cliente cadastre a lista de presentes.
usurios.
RF11 - O software dever permitir a autenticao dos usurios
a) Diagrama de caso de uso;

TAREFA 06 DIAGRAMA DE CASO DE USO (1,0)
Para este sistema, o gerente deve cadastrar agncias, clientes e

abrir e fechar contas bancrias. Um cliente possui nome, endereo e
telefone. Um cliente pode abrir vrias contas e uma conta pode ser de
vrios clientes, para o caso de contas conjuntas.
Contas so de uma determinada agncia (que possui nome e
nmero), alm de poderem estar vinculadas a uma conta de
investimento, que nada mais que outra conta bancria. Contas ainda
devem possuir um nmero (formado pelo nmero da agncia e pelo
nmero da prpria conta) e saldo disponvel, podendo ser corrente
normal, corrente especial e poupana.
Para contas poupana, devem-se armazenar os dias de
vencimento e, para contas corrente especiais, informar o limite de
crdito. Contas ainda possuem movimentaes de saque e depsito,
124
que devem ter data e valor, alm do tipo de movimento, que pode ser
dbito ou crdito.
Clientes ainda podem solicitar cartes de contas bancrias, que
devem ter nmero, validade e senha para cada cliente, alm de tales
de cheques para contas correntes, que devem armazenar o nmero
inicial e final das folhas do talo. O sistema ainda deve permitir aos
clientes consultar saldos e extratos.
DIAGRAMA DE CLASSES
Representao dos dados manipulados e armazenados pelos
programas de acordo com os conceitos de Orientao a Objetos. Notao
fortemente baseada no Diagrama Entidade-Relacionamento de Peter
Chen. Deve-se observar que o Diagrama de Classes privilegia a descrio
segundo o paradigma OO. Resumindo: Trata de dados e funes.
CLASSE
uma descrio de um conjunto de objetos que compartilham os
mesmos atributos, operaes, relacionamentos e semntica.
Representa a abstrao de um conjunto de OBJETOS do Mundo Real
que possuem tipos de caractersticas e de comportamento em comum.
Exemplo: PESSOA.
Figura 75 Elementos de uma Classe (Fonte: RAMOS - USP)
Toda classe deve representar uma abstrao conceitual do domnio

do problema ou da soluo. Assim, uma classe bem estruturada deve ser
uma abstrao de um conceito presente no domnio do problema ou da
soluo, ser fortemente coesa e possui baixo acoplamento.
125
CONVENES
O nome da classe deve comear por letra maiscula;

O nome do atributo deve iniciar por minsculo, porm o segundo
nome deve ser maisculo. Exemplo: Cliente ou SensorTemperatura;
O nome da classe deve ser no singular;
Pode-se ter classes sem atributos ou mtodos;
Deve ter um nome que a diferencie das outras classes;
Normalmente so substantivos ou expresses breves;
ATRIBUTOS
Um atributo uma propriedade nomeada
de uma classe que descreve um intervalo de
valores que as instncias podem apresentar.
Uma classe pode ter qualquer nmero de
atributos ou mesmo nenhum atributo.
Representa alguma propriedade do item
que est sendo modelado, compartilhado por
todos os objetos desta classe. Um objeto de
uma classe poder ter valores especficos para
cada um dos seus atributos. Exemplo: Todo
estudando possui nome, data de nascimento, e
sexo.
OPERAES
Uma operao a assinatura de uma implementao de um servio
que pode ser solicitado por algum objeto da classe para modificar seu
estado.
VISIBILIDADE
uma propriedade cujo valor (pblico, protegido ou privado) denota
como o elemento poder ser visto externamente:
PBLICO (+): qualquer objeto pode acessar os atributos ou
operaes da classe que se relacione com a classe que o possui;
PROTEGIDO (#): atributos e operaes de uma classe so acessveis
apenas por suas subclasses, ou seja, pode ser acessado apenas pelos
descendentes da classe;
PRIVADO(-): atributos e operaes de uma classe so acessveis
apenas pela prpria classe.
RELACIONAMENTOS
Especifica como as classes se relacionam. Podem ser de trs tipos:
126
ASSOCIAO
Especifica que objetos de um elemento esto conectados a objetos de

outros elementos.
Figura 76 Exemplo de Associao entre Classes (Fonte: RAMOS - USP)
ASSOCIAO COM NAVEGAO

possvel navegar de objetos de um tipo at objetos do outro tipo. A
menos que seja especifico o contrrio, a navegao ser bidirecional. A
seta indica a direo a ser seguida.
Figura 77 Exemplo de Associao com Navegao (Fonte: RAMOS - USP)
AGREGAO
A informao de agregao representada por um losango colocado

junto classe que representa o elemento agregador ou o todo, ou seja,
o diamante indica a classe todo (a que agrega). RESUMO: FAZ PARTE.
127
Figura 78 Exemplo de Agregao entre Classes (Fonte: RAMOS - USP)
COMPOSIO
Tambm chamada de AGREGAO COMPOSTA uma variante

agregao simples, em que adicionada a seguinte semntica:
(1) forte pertena do todo em relao parte;
(2) tempo de vida delimitado (as partes no podem existir sem o
todo).
Adicionalmente, o todo responsvel pela disposio das suas
partes, ou seja, o todo responsvel pela criao e destruio das
suas partes. A informao de agregao composta representada por
um losango cheio colocado junto classe que representa o elemento
agregador ou o todo.
Figura 79 Exemplo de Composio entre Classes (Fonte: RAMOS - USP)
CLASSE DE ASSOCIAO
A associao entre classes pode tambm ter os seus prprios

atributos (e eventualmente operaes), devendo ser, por conseguinte,
modelada tambm como uma classe. A este tipo chamamos de CLASSE
DE ASSOCIAO.
128
Figura 80 Exemplo de Classe Associao (Fonte: RAMOS - USP)
HERANA
Simplifica a definio de classes que so quase iguais s que j foram

definidas. Permite a reutilizao de definies comuns. Geralmente
identifica-se uma herana quando diz-se a palavra um.
Figura 81 Exemplo de Herana (Fonte: RAMOS - USP)
HERANA MLTIPLA
Na herana nica, uma classe tem um conjunto de pais (uma cadeia
de superclasse). A herana mltipla envolve do que uma cadeia de
superclasses. Problemas:
Choques de nomes de atributos ou mtodos;
Dificulta a manuteno do cdigo fonte.
129
Figura 82 Exemplo de Herana Mltipla (Fonte: RAMOS - USP)
MULTIPLICIDADE
Embora a multiplicidade seja especificada para classes, ela define a
quantidade de objetos que participam de um relacionamento. Existem dois
indicadores de multiplicidade para cada associao ou agregao (uma em
cada final de linha).
Figura 85 Exemplo de Multiplicidade
DIAGRAMA DE CLASSE
utilizado para:
modelar a viso esttica do projeto de um sistema;
modelar o relacionamento entre os diversos objetos que faro
parte do sistema;
capturar o vocabulrio do problema;
ancorar os comportamentos em suas classes;
130
gerar as declaraes da estrutura das classes.
Figura 86 Exemplo de diagrama de classe
Explicao do diagrama de classes: CLIENTE pode estar associado a 0

OU N PEDIDOS e este est associado a pelo menos um tipo de pagamento
(abstrata, no instanciada: crdito, dinheiro ou cheque). PEDIDO
composto de partes (agregao): detalhes do pedido, ou seja, um ou mais
detalhes de pedido e est associado a um item do estoque que ser dado
baixa. A dificuldade elaborar o diagrama e no na leitura, principalmente
quando h muitas informaes. H projetos com 100 classes e tende a ter
complexidade alta e quando o domnio definido mais fcil.
COMO FAZER UM DIAGRAMA DE CLASSES
Identifique um primeiro conjunto de classes;

Adicione atributos e comportamentos;
Encontre generalizaes;
Adicione associaes;
Reveja o modelo construdo adicionando ou removendo classes,
atributos, associaes ou generalizaes.
IDENTIFICANDO AS CLASSES
Ler a especificao de requisitos;

Extrair nomes: simples ou compostos;
Eliminar os que so: redundantes, representam instncias, so vagos
ou genricos demais e desnecessrios para a soluo do problema;
Atentar na especificao para os nomes que indicam atores que
interagem com o usurio;
Decida baseando-se em seu conhecimento do domnio, na
especificao de requisitos ou em um especialista do domnio os
dados que devem ser contidos em cada classe.
131
IDENTIFICANDO OS ATRIBUTOS
Se um subconjunto de atributos de uma classe formam um grupo

coerente pode ser interessante criar uma outra classe para estes
atributos.
IDENTIFICANDO O COMPORTAMENTO
Ler a especificao de requisitos;

Extrair verbos: simples ou compostos;
Eliminar os que so: redundantes, representam instncias, so vagos
ou genricos demais ou desnecessrios para a soluo do problema;
Colocar os comportamentos extrados nas classes identificadas.
IDENTIFICANDO GENERALIZAES
Existem duas formas para identificao de generalizao:

o BOTTOM-UP: agrupa classes simulares criando uma superclasse;
o TOP-DOWN: procurar por classes mais genricas para ento, se
preciso, especializ-las.
IDENTIFICANDO ASSOCIAO
Comear com as classes considerando mais centrais e importantes;

Decidir quais os relacionamentos destas com as outras;
Uma associao existe se uma classe: possui, controla, est conectada
para, est relacionada para, parte de, tem como parte, membro de
e tem como membro;
Alguma outra classe no modelo;
Evite adicionar muitas associaes a uma classe. O acoplamento fica
muito alto;
Especifique a multiplicidade.
EXEMPLO ESTUDO DE CASO: LOCADORA DE VECULOS
Vamos
fazer juntos
????
Este estudo est completo na pgina 89.

Alugar Carro: cliente deve solicitar ao funcionrio o aluguel do carro. O
sistema verifica se o carro solicitado pelo cliente est disponvel. Caso
esteja, o processo de locao concludo e o carro passa a estar
132
indisponvel. A data de aluguel deve ser guardada para calculo do valor do

aluguel na devoluo.
Dar Baixa: cliente faz devoluo do carro para o funcionrio e solicita
nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel.
O funcionrio coloca o status do carro novamente como disponvel, solicita
ao sistema para calcular o valor a ser pago e emite o recibo para o cliente.
Cadastrar Cliente: cliente solicita ao funcionrio que o cadastre na
locadora. O funcionrio recebe os dados e cadastra-o.
Cadastrar Carro: funcionrio cadastra o carro adquirido.
PASSOS PARA IDENTIFICAR AS CLASSES (HEURSTICA)
1. Descrio dos requisitos;
2. Extrair os substantivos;
3. Tentativa de classes;
4. Eliminar classes estranhas;
5. Classes identificadas.
EXERCCIOS
1) Em relao aos relacionamentos abaixo responda:

a) Qual a representao mais correta a primeira ou segunda relao?
Por qu?
2)Qual a diferena de intepretao entre as duas representaes? Qual

seria mais indicada para um tribunal regional eleitoral?
133
3) Com base nos requisitos funcionais abaixo, defina um diagrama de

classes:
RF01 - O software dever permitir que o gerente cadastre sales de festas.

RF02 - O software dever permitir que o gerente cadastre profissionais.
servios utilizados em uma festa de casamento, como buffet, carros utilizados.
RF04 - O software dever permitir que o cliente realize o cadastramento da lista
de convidados.
RF05 O software dever permitir que o cliente realize o cadastramento das
lojas de presentes.
RF06 - O software dever permitir que o cliente elabore da configurao da festa
pelo cliente.
RF07 - O software dever permitir a gerao do oramento para o cliente.
RF08 - O software dever permitir que o gerente realize a impresso de
relatrios de festas.
RF09 - O software dever permitir que o cliente cadastre a lista de presentes.
usurios.
RF11 - O software dever permitir a autenticao dos usurios
4) Com base no estudo de caso abaixo faa o diagrama de classes:

Os funcionrios da transportadora devem cadastrar clientes, filiais,
veculos, funcionrios, tipos de veculos, cidades, distancias, categorias de
frete e fretes de clientes.
Clientes so pessoas fsicas e possuem: nome, endereo e telefone.
Filiais tm: nome, endereo, telefone, funcionrio responsvel e vrios

veculos. Veculos devem possuir placa e um tipo de veiculo, alm de
ser necessariamente de uma filial.
Funcionrios so identificados pela matricula e tm ainda: nome,

endereo, telefone e dependentes (nome e data de nascimento), alm
de estar associado, obrigatoriamente a uma filial. Tipo de veculo
apresenta uma descrio (caminho, moto, etc) e o peso mximo que
Pode transportar alm de estar associado a veculos.
Cidades contm nome e estado a que pertence, representando as

cidades abrangidas pela empresa. Distncia envolve as cidades origem
134
e destino e para cada par de cidades atendidas, deve haver a distncia

em quilmetros entre elas.
Categoria do frete deve conter descrio e um percentual, que deve

incidir sobre o valor do frete onde, por exemplo, entregas rpidas tm
aumento de 10% entregas super-rpidas tem aumento de 30% e
entrega normal no tem acrscimo no valor. Cada frete tem um cdigo,
um cliente, o veiculo deve efetuar o frete, cidade origem e destino,
funcionrio responsvel e itens a serem transportados, no podendo
haver um frete sem os dados citados. Ainda precisa ter o valor a ser
calculado atravs da distncia percorrida entre as cidades: origem e
destino e da categoria do frete. Para isso, deve existir um valor padro
para o km rodado. Um item de transporte cada objeto a ser
transportado num frete e deve possuir apenas uma descrio e seu
peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com
todas as informaes de um determinado frete, logo aps o seu
cadastramento.
4) Com base nos requisitos funcionais abaixo, faa o diagrama de caso de

uso e o diagrama de classe:
RF01. O sistema deve permitir secretaria cadastrar cursos contendo
cdigo, descrio e professor coordenador.
RF02. O sistema deve permitir secretaria cadastrar disciplinas de cursos
contendo cdigo, descrio, carga horria, ementa, bibliografia e prrequisitos;
RF03. O sistema deve permitir secretaria cadastrar alunos contendo
matrcula, o nome, endereo, telefone e curso para o qual aprovado.
RF04. O sistema deve permitir ao departamento de recursos humanos
(RH) cadastrar professores, contendo nome, endereo, telefone e titulao
mxima (graduao, especializao, mestrado, doutorado) e cursos que
esteja vinculado.
RF05. O sistema deve permitir secretaria abrir turmas de disciplinas e
cursos, informando ano e semestre, dias da semana e horrios de
realizao.
RF06. O sistema deve permitir aos coordenadores de curso alocar
professores a determinadas turmas.
RF07. O sistema deve permitir a secretaria matricular alunos em turmas.
RF08. O sistema deve permitir aos professores lanar avaliaes (duas
notas parciais, nota da prova final e frequncia) dos alunos das turmas
que estejam sob sua responsabilidade.
RF09. O sistema deve permitir aos alunos consultar suas avaliaes.
RF10. O sistema deve permitir secretaria emitir dirios de classes de
turmas.
RF11. O sistema deve permitir secretaria emitir histricos escolares de
alunos.
RF12. O sistema deve efetuar o clculo da aprovao de alunos em
turmas, sendo que para ser aprovado, deve-se ter frequncia mnima de
75%. Alm disso, para aprovao sem prova final, a mdia das notas
135
parciais deve ser maior ou igual a 70. Para reprovao direta esta mdia
deve ser menor que 30. Mdias entre 30 (inclusive) e 70 (exclusive)
colocam o aluno em prova final. Se mdia da prova final com a mdia
anterior for menor que 50, o aluno est reprovado, caso contrrio,
aprovado.
RF09. O sistema deve controlar a situao de um aluno, podendo estar
matriculado, trancado, formado, ou ter abandonado o curso.
5) Faa o diagrama de classes do estudo de caso abaixo:
formada basicamente pelos seus clientes e carros para aluguel. Os carros
esto divididos em diversos tipos: popular, luxo e utilitrio. As
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e
valor do aluguel (diria). Os funcionrios sero responsveis pe3lo
cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o
aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes
especiais e clientes comuns. Os especiais possuem uma taxa de desconto
e um valor de quilometragem extra para seus aluguis. Qualquer cliente
6) Faa o diagrama de controle de respostas das questes de uma prova:
A Instituio de Ensino UniLinense deseja controlar todas as
respostas referentes s questes, de uma determinada prova, aplicadas
aos alunos da instituio. Sabe-se que uma prova tem que ter
obrigatoriamente uma questo e pode ter vrias, as questes por sua vez
fazem parte da prova e s podem estar vinculada a uma determinada
prova.
Cada prova tem somente um professor responsvel e um mesmo
professor pode se responsabilizar por vrias provas. Os alunos a serem
controlados se subdividem em alunos regulares e alunos dependentes.
Ambos alunos respondem vrias questes e uma questo aplicada a
vrios alunos. Para cada questo aplicada a um aluno deseja-se
armazenar uma resposta.
7) Faa o diagrama de controle de venda de veculos:
O objetivo principal desse sistema controlar as vendas de veculos,
direto da fbrica, realizadas pelos Concessionrios aos clientes. Sabe-se
que um Concessionrio pode vender vrios Veculos diretamente da
fbrica e que os veculos podem ser vendidos em vrios concessionrios
(por exemplo, um Gol pode ser vendido por vrios concessionrios). Toda
Venda destinada a um e somente um Cliente e todo cliente pode
comprar vrios veculos.
136
DIAGRAMA DE OBJETOS
Representa a instncia (uma ocorrncia) do diagrama de classes.
Para cada classe temos um objeto (instncia) em um determinado tempo.
Podemos enxergar dados reais facilitando a compreenso e a
modelagem de estrutura complexas de dados. Auxilia ainda na
identificao de problemas na execuo de uma aplicao.
A representao grfica semelhante classe, um retngulo com
duas partes. Na primeira exibido o nome do objeto sublinhado (pode ser
omitido desde que mantenha os dois pontos e o nome da classe e na
segunda os seus atributos um em cada linha com seus respectivos
valores:
Nome do Objeto: nome do objeto : nome da classe. Exemplo:

func1: Funcionrio
Funcionrio1
: Funcionrio
Nome do Atributo: nome do atributo : tipo = valor. Exemplo:

Produto1:Produto
descrio= Sala
cor = azul
tamanho = 40
preo = 15,00
O relacionamento entre os objetos feito atravs de links que a

instncia de uma associao. Um nome de papel pode ser mostrado no
final de cada link. Multiplicidade no pode ser exibida para links, pois
esto instanciadas. Podem ser exibidos os adornos de agregao,
composio, navegao e qualificadores, notas, restries e pacotes.
Exemplo:
Diagrama de Classes
Funcionrio
nome : string
cargo : string
salrio : real
Projeto
trabalha
1..*
0..1
gerencia
FuncionrioContratado
FuncionrioTerceirizado
carteiraProfissional: string
dataAdmisso:date
inicioContrato:date
terminoContrato:date
prestadoraServicos:string
taxaAdministracao:real
descrio:string
inicio: date
fim : date
custo : real
137
Diagrama de Objetos
P1:Projeto
descrio= Desenvolvimento do Sistema DKA
inicio = 01/12/2006
fim = 02/02/2007
custo = 6000,00
gerente
F1:FuncionarioContratado
F1:FuncionarioContratado
nome = Firminiano Neves

cargo = Analista de Sistemas
salrio = 3800,00
carteiraProfissional = 01357-9
dataAdmissao = 15/01/1995
nome = Porsidnio Souza

salrio = 3500,00
carteiraProfissional = 02468-0
dataAdmissao = 01/10/2000
F1:FuncionarioTerceirizado
nome = Silvio Abreu
salrio = 2500,00
inicioContrato = 02/12/2006
fimContrato = 26/02/2007
prestadoraServio = SISTEM
taxaAdministrativa = 6
Figura 75 Modelo de Diagrama de Objetos
EXERCCIOS
01. Desenhe um diagrama de objetos para o diagrama de classes abaixo:
138
02. Suponha um objeto Matemtica de uma classe Disciplina. Escreva as

formas nas quais podemos representar esse objeto.
03. Marque dentre os elementos abaixo quais podem ser colocamos em
um diagrama de objetos:
( ) tipo dos atributos
( ) valor dos atributos
( ) nome de papel
( ) nome de associao
( ) multiplicidade
( ) agregao
( ) composio
( ) navegao
( ) notas
( ) restries
04.
Em UML, um diagrama de objetos

Tcnico/Programador de Computador):
(Concurso
Serpro-2001-
a) a representao de um conjunto de classes.

b) a representao do relacionamento entre interfaces.
c) representa retratos estticos de instncias de itens encontrados em
diagramas de classes.
d) abrange a viso dinmica de um sistema.
e) mostra a configurao dos ns de processamento em tempo de
execuo.
TAREFA 07 DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0)
Para este sistema, o gerente deve cadastrar agncias, clientes e abrir

e fechar contas bancrias. Um cliente possui nome, endereo e telefone.
Um cliente pode abrir vrias contas e uma conta pode ser de vrios
clientes, para o caso de contas conjuntas.
Contas so de uma determinada agncia (que possui nome e
nmero), alm de poderem estar vinculadas a uma conta de investimento,
que nada mais que outra conta bancria. Contas ainda devem possuir
um nmero (formado pelo nmero da agncia e pelo nmero da prpria
conta) e saldo disponvel, podendo ser corrente normal, corrente especial
e poupana.
Para contas poupana, devem-se armazenar os dias de vencimento e,
para contas corrente especiais, informar o limite de crdito. Contas ainda
possuem movimentaes de saque e depsito, que devem ter data e
valor, alm do tipo de movimento, que pode ser dbito ou crdito.
Clientes ainda podem solicitar cartes de contas bancrias, que
devem ter nmero, validade e senha para cada cliente, alm de tales de
cheques para contas correntes, que devem armazenar o nmero inicial e
final das folhas do talo. O sistema ainda deve permitir aos clientes
consultar saldos e extratos.
139
DIAGRAMA DE SEQUENCIAS
Vamos imaginar a seguinte situao:
Preciso da lista de vendedores com o total
de vendas.
Relatrio de Comisses
Resposta:
100 Afonso 15.000,00
215 Andra 30.000,00
A quem pertence a matrcula 100?
RESPOSTA:
100 - Afonso
Figura 87 Exemplo de situao do cotidiano
Um diagrama de sequncias exibe a troca de mensagens entre os

objetos na ordem em que elas acontecem, no mostrando os detalhes do
que precisa para isto acontecer. A representao grfica feita assim:
o OBJETOS: retngulo alinhado no topo do diagrama partindo dele
uma linha vertical tracejada chamada LINHA DE VIDA desenhada
at o fim do diagrama. Exemplo:
LivroA:Livro
Figura 88 Exemplo de Objeto
o CRIAO DE UM OBJETO: a seta que representa essa mensagem

desenhada de forma a apontar sua cabea para o smbolo do
objeto. Pode conter o esteritipo <<create>>.
:Funcionrio
:ContraCheque
novo()
Figura 89 Exemplo de criao de objetos
o DESTRUIO DE UM OBJETO: a seta que representa essa

mensagem direcionada a um grande X colocado no final da linha
de vida. Pode conter o esteritipo <<destroy>>.
140
:Benefcio
:Funcionrio
excluirBenefcio()
Figura 90 Exemplo de destruio de objeto
o MENSAGENS: so enviadas de um objeto a outro, por meios das

setas que partem de uma linha de vida a outra, identificadas por
um nome de operao. Estas mensagens podem ser numeradas.
Ativao: quando um mtodo de um objeto est sendo
executado. Exemplo:
:Curso
:Aluno
obterNome(matrcula)
Ativao
Mensagem
de retorno
Mensagem
Figura 91 Exemplo de troca de mensagens
A iterao representa o envio da mesma mensagem diversas vezes

para o mesmo objeto, sendo comum o tratamento de colees de objetos.
A representao feita dentro de colchetes, incluindo ates do colchete
inicial, o asterisco (*). Exemplo:
*[para cada aluno da turma] CalcularMedia()
Chamada recursiva ou auto-chamada quando um objeto passa
mensagem para ele prprio. Exemplo:
Iterao
cursoX:Curso
disc1:Disciplina
Coordenador
obterGrade()
*[para cada disciplina]

obterInfDisciplina(cursoX)
[se a Disciplina tem

obterPreRequisito(disc1)
PreReq]
condio: s se
for verdadeira
Grade
auto-chamada
Figura 92 Exemplo de iterao
O diagrama de sequncias pode ser desenhado dentro de um frame

(verso 2.0) que identificar o diagrama. Use o prefixo sd(sequence
diagram) para indicar o tipo de interao.
141
sd DiagramaSeq1
objeto1
objeto2
mensagem
Figura 93 Exemplo de diagrama sequncia
O diagrama de sequncias frequentemente usado para representar

cenrios de casos de uso. Exemplo: CASO DE USO REGISTRAR VENDAS:
Diagrama de Classes:
Vendedor
Venda
matrcula : string
nome : string
dataAdmissao : date
salarioBruto : real
/salarioLiquido : real
percentualComissao : real
0..*
numero : integer
data : date
valor : real
grava()
obterListaVendedoresAtivos()
calcularSalarioLiquido(dataRef) : real
Figura 94 Exemplo de Diagrama de Classes
Caso de Uso: Registrar vendas

Objetivo: permite cadastrar as vendas efetuadas pelos vendedores.
Ator: assistente de gerncia
Cenrio Principal
1. O sistema prepara uma lista dos vendedores cadastrados na loja.
2. O usurio informa o nmero da venda.
3. O usurio informa ainda: a data da venda e o valor da venda.
4. O usurio seleciona o vendedor que efetuou a venda, a partir da lista
j montada pelo sistema.
5. O sistema efetua a gravao da venda.
Cenrio Alternativo: Venda j cadastrada.
2. Se o nmero da venda j estiver cadastrado, informar ao usurio,
mostrar as informaes da venda na tela e entrar em modo de
alterao dos dados.
142
Diagrama de Sequncias:
:Venda
:TelaCadastro
Assistente de
Gerncia
obterListaVendedoresAtivos()
numero_venda
busca(nmero_venda)
data, valor
seleo do vendedor
grava()
Figura 95 Exemplo de diagrama de sequncia
EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAO INTERNA
Vamos fazer
juntos???
:Vendedor
Figura 96 Estudo de caso diagrama de sequncia
143
144
Com base nas especificaes de caso de uso abaixo, vamos criar o

diagrama de sequncias:
Listagem 1. UC Manter Eleio
Descrio: Este caso de uso tem por objetivo manter o cadastro de eleies,
permitindo a incluso, alterao, excluso ou consulta de eleies.
Atores: Coordenadoria de Eleies
Cenrio principal:
1.
O sistema prepara uma lista de eleies cadastradas, exibindo para cada
uma: objetivo, data da eleio, status da apurao.
1.1. O usurio pode pesquisar uma eleio, informando os seguintes
critrios:
- objetivo
ou
- perodo inicial e final em que ocorreu a eleio
2. O sistema habilita as seguintes opes para o usurio:
2.1. Incluso de eleio
2.2. Alterao de eleio
2.2.1.
Para alterao, o usurio deve pr-selecionar a eleio
2.3. Excluso de eleio
2.3.1.
Para excluso, o usurio deve pr-selecionar a eleio
3.
Para a opo de Incluso ou Alterao:
3.1. O usurio informa/edita:
3.1.1.
objetivo da eleio
3.1.2.
data da eleio
4.
Para a opo de Excluso:
4.1. O sistema exibe os dados do item 3.1 desabilitados para edio.
4.2. O usurio confirma a excluso da eleio.
5.
O usurio confirma a operao.
5.1. O sistema atualiza o cadastro de eleies.
Cenrios alternativos:
Pesquisa de eleio
1.a. A pesquisa de eleio deve desconsiderar caixa alta e baixa, acentuao e
realizar a localizao dos trechos em qualquer ordem que os mesmos
apaream no cadastro.
1.b. A pesquisa de perodo deve ser feita considerando os perodos inicial e
final, inclusive; podendo ser informado apenas um dos perodos.
Permisso de Alterao da eleio
2.a. Se j houver data que indique o incio da votao, a eleio no poder
ser alterada. Exibir mensagem de erro e retornar ao passo 1.
Permisso de Excluso da eleio
2.b. Se j houver data que indique o incio da votao, a eleio no poder
ser excluda. Exibir mensagem de erro e retornar ao passo 1.
Validao da data de eleio
3.a. Se o usurio informar uma data de eleio que no seja futura, exibir
mensagem de erro e retornar ao passo 3.
3.a. Se o usurio informar uma data de eleio futura que j esteja cadastrada
para outra eleio, exibir mensagem de erro informando a qual eleio a data
j est cadastrada e retornar ao passo 3.
145
Listagem 2. UC Manter Candidatos

Descrio: Este caso de uso tem por objetivo manter o cadastro de candidatos,
permitindo a incluso, alterao, excluso ou consulta de candidatos.
Atores: Coordenadoria de Eleies
Pr-condio: existir cadastro prvio de eleies.
Cenrio principal:
1.
O sistema prepara uma lista de eleies cadastradas, que ainda no
tenham ocorrido a votao (incio de votao em branco), exibindo para cada
uma: objetivo, data da eleio, lista de candidatos cadastrados. Para cada
candidato cadastrado, exibir: nmero e nome.
2.
O usurio seleciona uma eleio.
3.
O sistema habilita as seguintes opes para o usurio:
3.1. Incluso de candidato
3.2. Alterao de candidato
3.2.1.
Para alterao, o usurio deve pr-selecionar tambm o
candidato.
3.3. Excluso de candidato
3.3.1.
Para excluso, o usurio deve pr-selecionar tambm o
candidato.
4.
Para a opo de Incluso ou Alterao:
4.1. O usurio informa/edita:
4.1.1.
nmero do candidato
4.1.2.
nome do candidato
4.1.3.
foto do candidato
5.
Para a opo de Excluso:
5.1. O sistema exibe os dados do item 4.1 desabilitados para edio.
5.2. O usurio confirma a excluso da eleio.
6.
O usurio confirma a operao.
6.1. O sistema atualiza o cadastro de candidatos.
Validao do nmero do candidato
4.a. Se o usurio informar um nmero de candidato j cadastrado na eleio
escolhida, exibir mensagem de erro informando a que candidato est associado
e retornar ao passo 4.
Listagem 3. UC Iniciar Votao
Descrio: Este caso de uso tem por objetivo dar incio votao de uma
eleio.
Atores: Mesrio
Pr-condio: existir uma eleio cuja data igual data vigente e que ainda
no tenha tido a votao iniciada.
Cenrio principal:
1.
O sistema busca a eleio cuja data igual data vigente.
2.
O usurio confirma o incio da votao.
2.1. O sistema atualiza o cadastro de eleies, registrando a data e hora
atual no campo incio da votao.
No se aplica
146
Listagem 4. UC Habilitar Eleitor

Descrio: Este caso de uso tem por objetivo validar o eleitor e liberar a urna
para votao.
Atores: Mesrio
Pr-condio: existir uma eleio cuja data igual data vigente e cujo incio
da votao j tenha sido preenchido.
Cenrio principal:
1.
O usurio informa a matrcula do eleitor.
1.1. O sistema busca o eleitor, exibindo o seu nome.
2.
O usurio libera a urna para votao.
Validao da matrcula do eleitor
1.a. Se o usurio informar um nmero de matrcula que no exista no
cadastro, exibir mensagem de erro e retornar ao passo 1.
1.b. Se o eleitor j tiver votado na eleio corrente, exibir mensagem de erro e
retornar ao passo 1.
Permisso para liberar a urna
2.a. Se o eleitor anterior ainda no tiver finalizado a votao, exibir mensagem
de erro e retornar ao passo 1.
Listagem 5. UC Votar
Descrio: Este caso de uso tem por objetivo permitir que o eleitor registre o
seu voto.
Atores: Eleitor
Pr-condio: a urna estar liberada para votao. Receber a identificao da
eleio e do eleitor habilitado para votao.
Cenrio principal:
1.
O sistema busca e exibe todos os candidatos associados eleio
identificada.
1.1. Para cada candidato, o sistema exibe: nmero do candidato, nome do
candidato e foto do candidato.
2.
O sistema habilita as opes Nulo e Branco.
3.
O usurio seleciona um dos candidatos ou uma das opes Nulo ou
Branco.
4.
O usurio confirma a votao.
5.
O sistema atualiza o cadastro de votao.
5.1. O sistema registra que o eleitor identificado j efetuou seu voto, sem
associ-lo ao voto.
5.2. O sistema computa 1 voto para o candidato selecionado ou para as
opes Nulo ou Branco.
5.3. O sistema libera a urna.
Permisso de correo da votao
4.a. O usurio pode solicitar a correo do seu voto, no momento de confirmar
a votao. Nesse caso, o sistema deve retornar ao passo 3.
147
EXERCCIOS
01. No diagrama de sequncias, o que representa a dimenso vertical?

02. No diagrama de sequncias, como chamada a linha que parte da
representao do objeto?
03. No diagrama de sequncias, o que representa um grande X no final
da linha de vida?
04. Como as mensagens so enviadas num diagrama de sequncias?
05. O que representa a ativao num diagrama de sequncias?
06. Indique quais elementos abaixo no aparecem em um diagrama de
sequncias:
objetos, mensagens, iterao, ns, condies, relacionamento de
agregao, ator e estado.
07. Faa o diagrama de sequncia para abertura de conta comum:
Inicialmente o Cliente solicita ao Funcionrio a abertura de uma
conta, ento o Banco faz uma consulta do cliente pelo seu CPF
(Mtodo), na classe Fsica, se o cliente se encontra cadastrado, a
consulta retorna com os Dados do Cliente, se no o cadastro do
cliente dever ser realizado.
No cadastro do cliente (Fsica), dever conter um mtodo para
validar o CPF, evitando assim, o cadastro de clientes com CPF
inexistente.
Aps o cadastro do cliente o funcionrio receber uma resposta do
Sistema informando que o cliente est atualizado, da mesma forma
que o funcionrio comunica ao cliente que seu cadastro foi
aprovado.
Ao receber a resposta do funcionrio, o cliente deve informar valor
do depsito a ser feito e sua senha. Essa mensagem ir disparar um
mtodo para abertura de uma nova conta comum, que por sua vez,
ir registrar esse histrico.
O Cliente dever ser informado sobre o status de sua conta, ou seja,
que a abertura da conta foi concluda.
08. Faa o digrama de sequncia para o encerramento de uma conta:
Neste caso o Cliente solicita ao Funcionrio o encerramento de sua
conta, o Funcionrio por sua vez deve verificar a conta, neste
momento, necessria a senha do cliente e em seguida se existe
Saldo.
Se o Funcionrio receber a resposta de que o saldo positivo, deve
haver o saque do valor.
148
Assim como qualquer movimentao, havendo o saque deve-se

registrar o histrico referente ao Saque.
Aps a confirmao do saque, deve ser disparado o mtodo de
encerramento de Conta. Em seguida avisar ao cliente.
09. Diagrama referente a solicitao de Extrato de uma conta comum
atravs de um caixa eletrnico.
10. Com base na especificao de caso de uso abaixo, criar um diagrama
de sequncias:
Criar Matrcula (CSU001)
Sumrio: O aluno solicita do sistema, sua matrcula em uma determinada
disciplina. O sistema verifica se o aluno possui os pr-requisitos necessrios e em
caso afirmativo registra a matrcula.
Ator Primrio: Aluno
Pr-condies: O aluno est logado no sistema.
Fluxo Principal
1. O aluno solicita o formulrio (tela) de matrcula.
2. O sistema solicita um cdigo de disciplina.
3. O aluno fornece um cdigo de disciplina.
4. O sistema exibe o nome completo (descrio) da disciplina.
5. O sistema verifica a grade do curso para conhecer os pr-requisitos para
aquela disciplina.
6. O sistema verifica o histrico do aluno para determinar se ele possui os prrequisitos necessrios.
7. Se sim, o sistema registra a nova matrcula, emite uma mensagem de
aceitao.
8. O sistema oferece alternativa de mais matrculas ou de encerramento.
10. O aluno seleciona encerramento e o caso de uso se encerra.
Fluxo Alternativo: O aluno seleciona mais matrculas e o caso de uso retorna
ao passo 2 (pode acontecer no passo 8).
Fluxo de exceo: O aluno no possui os pr-requisitos (pode acontecer no
passo 6).
1. O sistema reporta essa situao e retorna ao passo 8.
Ps-condies: As matrculas efetuadas tornam-se disponveis aos
coordenadores de curso para avaliao.
Regras de Negcio: Um aluno no pode se matricular em disciplinas que no
tenha cursado seus pr-requisitos.
TAREFA 8 DIAGRAMA DE SEQUENCIAS (1,0)

formada basicamente pelos seus clientes e carros para aluguel. Os carros
esto divididos em diversos tipos: popular, luxo e utilitrio. As
149
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e

valor do aluguel (diria). Os funcionrios sero responsveis pe3lo
cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o
aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes
especiais e clientes comuns. Os especiais possuem uma taxa de desconto
e um valor de quilometragem extra para seus aluguis. Qualquer cliente
a) Cadastrar cliente;
b) Efetuar aluguel.
150
ANEXO - SOLUES PARA PROBLEMAS NA ENGENHARIA DE

REQUISITOS
Figura 64 Requisitos
Recordando, engenharia de requisitos, descreve o conjunto de

atividades para a produo de requisitos e gerencia de requisitos. H dois
grupos de atividades:
PRODUO DE REQUISITOS
o LEVANTAMENTO: atividade que se relaciona com a obteno dos
requisitos e para isto temos analistas e engenheiros que
trabalham junto com o usurio para levantar as limitaes de
hardware, o funcionamento do sistema, desempenho do sistema,
e outras informaes necessrias para dar continuidade da
produo do software. H varias atividades como entrevistas,
JAD, BRAINTORMING, WORKSHOP DE REQUISITOS, USO DE
PROTOTIPOS PARA APOIAR O REQUISITO.
o Registro: uma vez identificados precisam ser documentados para
servir de base para o resto do desenvolvimento. Ou seja
especificao, descrio dos requisitos levantamentos junto com
o cliente neste contexto. Administrar o grande volume de
informaes levantados um problema, preciso identificar o
nvel de detalhe correto para suprir as necessidades de diferentes
atividades no ciclo de vida do projeto.
o VALIDAO: comprometimento do cliente de acordo com os
requisitos levantados; aceite do cliente sobre determinado
artefato. Ou seja identificamos o que o software atende.
151
o VERIFICAO: examina a especificao do software assegurando

que todos os requisitos foram definidos, sem omisso,
ambiguidade, detectando e corrigindo defeitos na fase de
definio dos requisitos, fornecendo uma melhor qualidade nos
requisitos que est sendo elaborada.
GERENCIA DE REQUISITOS
Os requisitos so volteis e diversos fatores contribuem para isto
(mudana externa, por exemplo: legislao, mercado, posicionamento
estratgico da empresa, erros ocorridos no processo de requisitos). E
isto traz a necessidade de alterao nos requisitos e esta alterao
precisa ser ordenada para que no haja perda de custo e prazo.
CONTROLE DE MUDANA: como so volteis, sofrem mudanas e
para conduzir a mudana necessrio o preparo e planejamento.
Uma forma para organizar definir um processo mais formal
para ter controle sobre a mudana e sobre isto h uma analise de
impacto para achar em que momento a mudana pode ser
atendida e o impacto desta mudana no software e esta mudana
pode ser aprovada ou rejeitada que dever apresentar os motivos
da rejeio.
GERENCIA DE CONFIGURAO: Assunto amplo. Garantir que
estamos trabalhando com as verses corretas dos diferentes
itens de configurao que esta sendo criado no desenvolvimento
e a especificao de requisitos um destes documentos. Para
garantir que a equipe esteja trabalhando na ultima verso.
RASTREABILIDADE: permite identificar ou entender como os
diferentes conceitos ou elementos esto sendo tratados nas
diferentes fases do desenvolvimento e devemos garantir que as
transformaes estejam correndo e de forma correta. Podemos
verificar a analise de impacto de uma alterao.
GERENCIAMENTO DA QUALIDADE DE REQUISITOS: garante que
as atividades do produto produzido esto sendo seguidas
corretamente.
ELICITAO DE REQUISITOS
Por ser onde identificamos os requisitos, ou seja a ideia inicial do
sistema, necessrio a compreenso do problema.
PROBLEMAS
Escopo;
Entendimento;
Volatilidade.
DESAFIOS
Falta de conhecimento do usurio das suas reais necessidades;
152
Falta de conhecimento do desenvolvedor do domnio do problema;

Domnio do processo de elicitao de requisitos pelos desenvolvedores;
Comunicao inadequada entre os desenvolvedores e usurios;
Dificuldade do usurio tomar decises;
Problemas de comportamento;
Questes tcnicas.
PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS

SOLUO
Identificar interessados apropriados;

Verificar constantemente a necessidade de participao de outros
usurios;
Utilizar tcnicas de apoio como workshop e requisitos JAD.
PROBLEMA: POLTICA NA ORGANIZAO

SOLUO
Ciclo de vida iterativo incremental;

Obteno explcita do comprometimento com os requisitos;
Anlise de impacto.
PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAO DOS REQUISITOS DE ALTO

NVEL DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS
FUNCIONAIS E NO FUNCIONAIS.
SOLUO
Necessrio aumentar a interao entre o engenheiro de requisitos e o

usurio;
Iniciar as entrevistas com o cliente com perguntas abertas;
Possibilidade de empregar tcnicas de elicitao complementares como
etnografia (observao do ambiente operacional do cliente).
PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO

SISTEMA DOS SEUS REQUISITOS
SOLUO
Estabelecer templates e diretrizes que orientem a separao adequada

do contedo do documento de requisitos;
Fazer uso de revises tcnicas para assegurar a qualidade dos
documentos produzidos.
153
CASOS DE USO
Figura 65 Exemplo de Especificao de Caso de Uso
PROBLEMA: DIFICULDADE NA DESCRIO DE REQUISITOS FUNCIONAIS E NOFUNCIONAIS.

SOLUO
Utilizao de revises tcnicas formais;

Treinamentos podem ser conduzidos
encontrados nas inspees.
focando
nos
problemas
PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA

DEFINIO DA SOLUO
SOLUO
Manter os passos simplificados, contudo assegurando que todas as

informaes
necessrias
(informaes
recebidas,
opes
disponibilizadas, informaes fornecidas e aes realizadas) estejam
descritas;
A separao do caso de uso em diversos casos de uso relacionados
atravs de incluses (includes) e extenses (extends).
PROBLEMA:
DETALHAMENTO
TCNICO
ESPECIFICAO FUNCIONAL DO SISTEMA.
154
DESNECESSRIO
DURANTE
SOLUO
Utilizao de revises tcnicas formais;

Treinamento pode ser fornecido para esclarecer o contedo apropriado
da especificao funcional.
GERNCIA DE REQUISITOS
PROBLEMA: DIFICULDADES DE ESTABELECER UMA
ATUALIZAO E REUTILIZAO DE CASOS DE USO
ESTRATGIA
PARA
SOLUO
Criar uma biblioteca de casos de uso estruturada de acordo a diviso

funcional (mdulos) dos sistemas da organizao;
Tratar cada caso de uso como um item de configurao.
PROBLEMA: REPRESENTAR A ATUALIZAO DE CASOS DE USO

SOLUO
Preenchimento de um histrico de verses dos casos de uso,

informando a data, as alteraes realizadas e o responsvel pelas
alteraes.
Tratar cada caso de uso como um item de configurao e inserir no
processo de gerncia de configurao.
Figura 63 Exemplo de histrico de verses
155
PROBLEMA: DIFICULDADE DE INTEGRAO DAS PRTICAS DE GERNCIA DE

REQUISITOS COM GERNCIA DE CONFIGURAO.
SOLUO
Definir um processo de gerncia de configurao padro. A evoluo

dos requisitos deve estar alinhada com a evoluo das baselines de
requisitos;
Os requisitos acordados em uma baseline somente podem ser alterados
atravs de solicitaes de mudana.
PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA

SISTEMAS EM MANUTENO.
SOLUO
Considerar uma abordagem evolutiva para a criao dos casos de uso,

onde inicialmente a documentao consiste de um resumo do caso de
uso (contendo, por exemplo, apenas o fluxo principal).
PROBLEMA:
DIFICULDADE
DE
IMPLANTAO
RASTREABILIDADE DOS REQUISITOS.
MANUTENO
DA
SOLUO
Estabelecer um processo de desenvolvimento que integre as atividades

relacionadas ao estabelecimento da rastreabilidade com as prprias
atividades de engenharia do software;
Algumas ferramentas CASE permitem o estabelecimento dos links de
rastreabilidade no momento da criao e atualizao dos artefatos.
PROBLEMA:
DIFICULDADES
DE
RASTREABILIDADE DOS REQUISITOS
ESTABELECIMENTO
RETROATIVO
DE
SOLUO
O estabelecimento retroativo de rastreabilidade pode ser

extremamente custoso e uma anlise de custo/benefcio deve ser
considerada antes de realizar esta tarefa.
BOAS FRIAS!!!!
Obrigada por tudo e me desculpe
por alguma coisa.

Engenharia de Software II - Apostila

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Engenharia de Software II - Apostila

Загружено:

Авторское право:

Доступные форматы

Faculdade de ecnologia de Praia Grande

Se eu tivesse oito horas para derrubar

ETAPAS PARA PREPARAR UMA REUNIO JAD..................................................................................................... 41

OPERAO X MTODO ............................................................................................................................. 83

ATIVIDADE DE UML ................................................................................................................................. 108

DIAGRAMA DE CLASSES ............................................................................................................................. 124

PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS

Dia Portable, Visio (Fatec), Word.

Mquina Virtual na Fatec : Engenharia de Software.

O trabalho semestral dever ser entregue na ltima aula

Aviso: eu sou cliente.

TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)

Segundo a IEEE Computer Society, a engenharia de software a

2. Um requisito de software expressa as necessidades e restries

de cenrios durante a construo de prottipos que durante a

III. Todo projeto de software iniciado por alguma necessidade do

O objetivo da Engenharia de Software estabelecer uma sistemtica

9. No processo de engenharia de software, os requisitos funcionais podem

1 BIMESTRE DESENVOLVIMENTO DE SOFTWARE

Processo de software um conjunto de atividades que objetivam o

Figura 1 Processo de Engenharia de Requisitos

J desenvolvimento de software um conjunto de atividades para

Para o sucesso do desenvolvimento do software necessrio um

ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e descrio

Figura 2 Levantamento de Requisitos (Fonte: Web)

Segundo o IEEE, define requisitos de software como:

Outros conceitos de requisitos de software...

Um requisito descrito como uma propriedade que o software deve

Um requisito alguma coisa que o produto tem de fazer ou uma

Figura 3 Requisitos (extrado da WEB)

IMPORTNCIA DOS REQUISITOS

A dificuldade de descobrir erros na fase de requisitos est no fato

Problemtico quando no cobre todas as funcionalidades

Figura 5 Pesquisa de projetos

As causas podem ser:

Figura 6 Tipos de Fatores

Precisamos dos requisitos para entender o que o cliente quer, para

QUALIDADE DOS REQUISITOS

Priorizvel: Se todos os requisitos tm a mesma prioridade, h

FUNCIONAIS: os requisitos funcionais descrevem o que o sistema

NO FUNCIONAIS (RNF ou Suplementares): Declaram as

DOMNIO: muito relacionado as regras de negcio ou

EXEMPLO DE REQUISITOS FUNCIONAIS

O software deve permitir que o atendente consulte o relatrio com os

CONFIABILIDADE: O sistema deve estar disponvel 99% das

EXEMPLO DE REQUISITOS DE DOMINIO

[RN1] os campos referente a oramento projeto vinculado s

Nem sempre so bvios;

Os requisitos podem ser vistos em trs classes distintas:

Figura 7 Etapas da Engenharia de Requisitos (Fonte: extrado da Web)

Ao conjunto de atividades relacionadas a requisitos, d-se o nome

GERNCIA: controle de mudanas, gerncia de configurao,

OBJETIVOS DA ENGENHARIA DE REQUISITOS

TAREFA 02 - QUESTES DE REQUISITOS (0,5)

1) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de

d) converso de especificaes em requisitos.

a) especifica, revisa e valida o problema de modo a garantir que seu

Figura 8 Etapas de uma Elicitao de Requisitos (Fonte: extrado da Web)

Nesta etapa um dos artefatos2 principais a criao do documento

Produto de trabalho do processo: os papis usam os artefatos para executar atividades e

Figura 9 Esquema para criao do documento viso (Fonte: extrado da Web)

Figura 10 Erros de Requisitos (Fonte: extrado da Web)

A elicitao de requisitos corresponde a identificar junto aos