Apostila Análise de Sistemas

Prévia do material em texto

Z91a Zoucas, Alessandra Casses
 Análise de Sistemas / Alessandra Casses Zoucas. – 
 Florianópolis : Publicações do IF-SC, 2010.
 74 p. 
 Inclui Bibliografia.
 1. Análise de sistemas. 2. Diagrama de casos de uso. 3. 
 Diagrama de sequência. 4. Diagrama de Fluxo de Dados. 5. 
 Ciclo de vida. II. Título.
 CDD: 001.61 
 
Catalogado por: Augiza Karla Boso CRB 14/1092
 Rose Mari Lobo Goulart CBR 14/277
Organização de conteúdo: 
Andrino Fernandes 
Elaine Luz Barth
Comissão Editorial:
Hamilcar Boing
Andrino Fernandes 
Elaine Luz Barth
Produção e design instrucional:
Andrino Fernandes 
Elaine Luz Barth
Projeto gráfico:
Paulo Ricardo Rodrigues de Lima
Capa: 
Lucio Baggio
Revisão ortográfica: 
Marcos Pessoa
Editoração Eletrônica: 
Hudson Ricardo Borges
Sumário
Capítulo 1 - Introdução a Análise de Sistemas
1.1Conceitos Básicos ..........................................................................................................11
1.2 Linha do Tempo ...........................................................................................................12
1.3.1 Análise Estruturada ..................................................................................................14
1.4 Revendo a história .......................................................................................................15
1.5 Análise Essencial ..........................................................................................................16
1.6 Análise Orientada a objeto ...........................................................................................18
1.6.1 Abstração de Dados: .................................................................................................19
1.6.2 Atributos: ...................................................................................................................19
1.6.3 Relacionamentos: ......................................................................................................20
1.7 Problema X Solução .....................................................................................................21
Capítulo 2 - Levantamento de Requisitos
2.1 Requisitos Funcionais ...................................................................................................27
2.3 Rastreabilidade .............................................................................................................29
2.4 Processo de Engenharia de Requisitos ..........................................................................30
2.5 Técnicas para Levantamento de requisitos ...................................................................31
2.7 Gerência de Requisitos .................................................................................................33
2.8 Quais são as pricipais atividades da Gerência de Requisitos? .......................................34
2.9 Regra de Negócio (RNE) ..............................................................................................34
Capítulo 3 - Diagrama de casos de uso
3.1 Sistema ........................................................................................................................3 8
3.2 Ator ..............................................................................................................................3 8
3.3 Casos de uso ................................................................................................................39
3.4 Documentação de casos de uso ....................................................................................4 0
3.6 Relacionamentos .........................................................................................................43
Capítulo 4 - Diagrama de Sequência
4.1 Alguns elementos de um diagrama de sequência ..........................................................50
4.2 Diagrama de Classe ......................................................................................................51
4.3 Exercícios de Aprendizagem .........................................................................................52
Capítulo 5 - Diagrama de Fluxo de Dados - DFD
5.1 Como elaborar um DFD ...............................................................................................56
5.2 Níveis do DFD ..............................................................................................................58
5.3 Vantagem do uso de DFD´s em níveis .......................................................................5 9
5.4 Exercícios de aprendizagem ..........................................................................................60
Capítulo 6 - Ciclo de Vida
6.2 Os componentes do desenvolvimento de um ciclo de vida ...........................................64
6.3 Modelos de ciclo de vida ..............................................................................................64
 6.3.1 MODELO SEQUENCIAL ....................................................................................64
 6.3.2 MODELO CASCATA ...........................................................................................64
 6.3.2 MODELO V .........................................................................................................6 6
 6.3.4 MODELOS INCREMENTAIS ...............................................................................66
 6.3.5 RUP (Rational Unified Process) ...........................................................................67
 6.3.6 MODELO EVOLUTIVO .......................................................................................71
Apresentação
Caro estudante, 
Você já pensou que um dos fatores de sucesso na construção de um software tem relação direta 
com a comunicação entre o fornecedor do sistema e os seus clientes?
Sabe por que isso acontece? Porque o fornecedor do sistema deve procurar compreender os 
problemas do seu cliente para propor soluções de software que se aproximem das expectativas 
destes clientes. Para isto, é necessário que se obtenha e se documente informações sempre cole-
tadas junto ao cliente. Elas servem de suporte na construção do software que deve estar alinhado 
a essas expectativas. 
Existem outros fatores importantes. Por exemplo, o sucesso de um software tem relação direta 
com a comunicação do fornecedor do sistema e sua equipe de desenvolvimento de software. Isto 
acontece por que o fornecedor do sistema deve procurar transmitir claramente para sua equipe 
de desenvolvimento de software as características da solução proposta e aprovada pelo cliente. 
Assim, ele poderá ter uma garantia inicial de que o software que será construído atenderá às 
expectativas do seu cliente.
Entretanto, as coisas não são tão simples como podem parecer. Estabelecer estas comunicações 
de forma eficiente não é uma tarefa fácil. Tipicamente, pode ocorrer ruído nesta comunicação, e 
isto pode acarretar na construção de um software com problemas do ponto de vista do usuário. 
Sendo assim, nesta disciplina você estudará os elementos que auxiliam na geração de uma 
comunicação eficiente (com a menor interferência de ruídos possível) visando sempre a garantia 
de que o produto criado atenderá as expectativas do cliente. Para atingir este objetivo iremos 
estudar técnicas de levantamento e documentação das necessidades dos nossos clientes, tanto 
do ponto de vista do usuário quanto do ponto de vista do desenvolvedor de software. 
Seja bem-vindo(a) a disciplina Análise de sistemas. É um prazer acompanhá-lo (a) em mais uma 
jornada no mundo virtual. Realize todas as atividades recomendadas e planeje os seus estudos. 
Sucessoe boas aulas!
Um abraço,
Profa. Alessandra Zoucas
1
CAPÍTULO
Introdução a Análise de Sistemas
Objetivo
Apresentar alguns conceitos básicos que 
estão relacionados à análise de sistemas. 
Verificar as principais metodologias de de-
senvolvimento. Estudar a diferença entre 
domínio do problema e solução.
Introdução a Análise de Sistemas
11
A seguir são apresentados conceitos que estão presentes no con-
teúdo desta apostila. Logo, para maior aproveitamento da leitu-
ra é importante que o leitor saiba onde encontrar as definições 
apropriadas para os conceitos tratados neste material de modo a 
familiarizar-se com eles.
1.1Conceitos Básicos
Análise: derivado do grego analýein - desatar, soltar, significa 
dissolução de um conjunto em suas partes. Em sentido amplo, 
empregam-se os termos “análise” e “analisar” como sinônimo 
de exame e examinar, pesquisa e pesquisar, verificação e verifi-
car [1].
Análise de Sistemas: representa o estudo detalhado de uma 
área de trabalho (processo), que antecede uma ação que, quase 
sempre, implica no desenvolvimento de um conjunto de pro-
gramas integrados (sistemas) destinados à execução, controle 
acompanhamento do processo [1].
Analista de Sistemas: é o profissional que atua na área de de-
senvolvimento, manutenção e produção de sistemas e na custo-
mização de sistemas.
Características (Features): permite definir um escopo mais re-
finado do trabalho a ser feito. É uma abstração intermediária 
entre as necessidades dos stakeholders e os requisitos do sistema 
[12].
Necessidades: está ligada diretamente com o real problema 
de negócio que será resolvido, ou seja, o objetivo é resolver o 
problema. Deve orientar todo o processo de identificação de 
requisitos [12].
Processo: conjunto de atividades inter-relacionadas, que trans-
forma entradas em saídas (ABNT, 1998).
Produto de Software: é a entidade de software disponível para 
liberação do usuário [12].
Qualidade de Software: é a totalidade das características de 
um produto de software que lhe concede a capacidade de satis-
Análise de Sistemas
12
fazer às necessidades explícitas e implícitas, ou seja, é a capacidade em 
atender aos requisitos [12].
Sistema: conjunto de elementos (subsistemas) independentes entre si, 
com vistas a atingir um objetivo [1].
1.2 Linha do Tempo
Inicialmente falaremos sobre a linha do tempo relacionada ao desen-
volvimento de software [2]:
 
Introdução a Análise de Sistemas
13
1970 - Crise do Software
Entre outros, foram atribuídos como principais fatores dessa cri-
se: o desenvolvimento de softwares de forma “artesanal”, con-
Análise de Sistemas
14
tínuos erros de execução, tempo da coleta de dados, descumprimento 
de prazos, problemas relacionados aos custos, inexistência de docu-
mentação ou elegibilidade da mesma, falta de comunicação durante 
do desenvolvimento do software, falta de testes e a insatisfação dos 
usuários [2].
1.3 Metodologias de desenvolvimento de Softwares
A partir de 1970 surgiram metodologias para o desenvolvimento de 
Softwares identificadas como: Análise Estruturada, Análise Essencial, 
e Análise Orientada a Objetos. 
1.3.1 Análise Estruturada
Esta análise é utilizada para auxiliar 
na comunicação entre as pessoas en-
volvidas no processo de desenvolvi-
mento do software, assim como no 
gerenciamento da complexidade, en-
tendimento do problema e na redu-
ção dos custos [2].
A metodologia de Análise Estruturada 
é baseada na decomposição funcio-
nal e na utilização de diagramas de 
fluxos de dados (DFD). Suas princi-
pais fases são [3]:
Figura 1. Fonte: http://www.zsc.com.br/images/ANALISAR.gif
Fase 1- Estudo Inicial
O ponto inicial desta metodologia é dado pelo esforço de garantir que 
os sistemas escolhidos para serem desenvolvidos são aqueles que se 
garantem em ambientes competitivos. A relação custo benefício (do 
ponto de vista financeiro) é considerada como o critério mais impor-
tante no processo de seleção, quando então, os sistemas são aponta-
dos como responsáveis pela contribuição crescente do faturamento, 
crescentes custos ou a melhoria dos serviços oferecidos [3]. 
Introdução a Análise de Sistemas
15
Fase 2 – Estudo Detalhado
Nesta fase procura-se entender o sistema de forma detalhada e 
o usuário pode participar de forma informal para sanar algumas 
dúvidas que o analista do sistema possa ter sobre o processo [3].
Neste estudo detalhado os seguintes elementos deverão estar 
presentes [3]:
•	 A definição dos usuários do novo sistema, com suas respon-
sabilidades e funções.
•	 Um modelo lógico do sistema atual que é um diagrama de 
fluxo de dados geral, os sistemas de interfaces e um DFD 
detalhado de cada processo considerado importante.
•	 Uma declaração com os ganhos que são esperados com o 
sistema;
•	 Um orçamento dos gastos necessários para finalização das 
próximas fases.
 
Fase 3 – Definição e Projeto de Soluções Alternativas
Nesta fase busca-se definir as soluções para os problemas do 
sistema atual. Os objetivos da organização, definidos da fase ini-
cial, são convertidos em um conjunto de objetivos do sistema 
[3].
Fase 4 – Projeto Físico
O grupo do projeto refina a alternativa escolhida em um projeto 
físico específico que envolverá o detalhamento do DFD, projeto 
do banco de dados e a racionalização e normalização [3].
1.4 Revendo a história
No final da década de 60, 
com a introdução da pro-
gramação estruturada, apa-
receram as técnicas estrutu-
radas. Foi na década de 70 
que Steven Myers e Cons-
tantine propuseram os con-
ceitos de projeto estrutura-
do. 
Figura 2. Fonte: http://www.exkola.com.br/site/files/carreira/carreira-818.jpg
Análise de Sistemas
16
Neste sentido buscou-se aplicar os conceitos de projeto estruturado à 
análise de sistemas com o intuito de desenvolver um método de espe-
cificação de requisitos adequado ao projeto estruturado [3].
Em 1979, Gane e Sarson, descrevem em seu trabalho a metodologia 
de desenvolvimento de sistemas denominada STRADIS (Structured 
Analysis, Design and Implementation of Information Systems) que in-
corpora a análise, projeto e implementação estruturada de sistemas de 
informação.
 
Gane e Sarson salientam em seu trabalho que para completar o de-
senvolvimento do sistema é necessário definir um planejamento que 
contenha os planos de testes e aceitabilidade do sistema [3].
De modo geral, na Análise Estruturada são enfatizadas as funções do 
sistema e os processos. Ela não modela o comportamento temporal, 
bem como os relacionamentos complexos de dados. Nesta análise são 
utilizadas as seguintes ferramentas [2]:
•	 Diagrama de Fluxo de Dados;
•	 Dicionário de Dados
•	 Especificação da Lógica de Processos. 
1.5 Análise Essencial
A Análise Essencial é considerada uma evolução da Análise Estrutura 
em função de preocupar-se com o controle e utilizar ferramentas para 
representação dos requisitos do sistema.
Na etapa de análise procura-se detalhar o propósito do sistema (de-
finição do problema) e identificar os requisitos do software. Onde os 
requisitos correspondem ao conjunto de características que o sistema 
deve possuir para alcançar o propósito do sistema [5].
No decorrer do processo de análise, o analista precisa encarar a com-
plexidade das situações reais, entendê-las e representá-las de uma for-
ma simplificada que permita a compreensão do sistema que será de-
senvolvido. Para tal, é necessário limitar o escopo, subdividindo o todo 
complexo em partes simples e gerenciáveis, obtendo as características 
essenciais da realidade e modelar o relacionamento destas característi-
cas criando um modelo [5]. 
Introdução a Análise de Sistemas
17
O modelo é uma representação da abstração da realidade, ou 
seja, ele representa o conjunto de característicasde uma situação 
real. Os modelos possuem níveis de abstração que representam 
o grau de detalhes das características do sistema. 
De um modo geral, os sistemas de informação são considerados 
em três níveis [5]:
•	 Conceitual: as características do sistema são consideradas 
independentes do ambiente computacional (hardware e sof-
tware) onde o sistema será implementado.
•	 Lógico: as características são consideradas como dependen-
tes de um dado tipo de sistema computacional e indepen-
dentes dos produtos.
•	 Físico: as características são consideradas como dependen-
tes de um dado sistema computacional, ou seja, dependem 
da linguagem de programação, do compilador, do sistema 
gerenciador de banco de dados etc.
Nas etapas iniciais do processo de desenvolvimento, o analista 
de sistemas representa o sistema através de modelos conceituais. 
Em seguida, as características lógicas e físicas são representadas 
por outros modelos.
O método de Análise Essencial de Sistemas indica que um siste-
ma deve ser modelado por meio de três dimensões [5]:
•	 Dados: refere-se aos aspectos estáticos e estruturais do sis-
tema;
•	 Controle: considera os aspectos temporais e comportamen-
tais do sistema; e
•	 Funções: considera a transformação de valores.
A Análise Essencial considera dois níveis relacionados ao grau 
de abstração, são eles [5]:
•	 Modelo Essencial: representa o sistema em um grau de 
abstração totalmente independente das restrições de tecno-
logias; e
•	 Modelo de Implementação: leva em consideração as res-
trições tecnológicas relacionadas ao hardware e software 
que serão utilizados na implementação (desenvolvimento) 
do sistema. 
Análise de Sistemas
18
De um modo geral a Análise Essencial foi considerada uma evolução 
da Análise Estruturada de Sistemas. No entanto, a Análise Essencial 
procurou determinar um novo ponto de partida para a especificação 
de um sistema: a identificação dos eventos que o afetam. Passando a 
abranger também o levantamento de requisitos, uma vez que a análise 
estruturada focava somente na análise de requisitos [5].
A análise essencial depurava os sistemas em subsistemas para torná-
los mais leves e operacionais, percebendo-se então a proximidade 
entre funções e dados, pois cada subsistema era provido de dados 
através de banco de dados particionado e conhecido como memória 
essencial. Pode-se dizer que esta metodologia foi o limite para o estudo 
mais sólido dos métodos orientados a objetos [6].
1.6 Análise Orientada a objeto
A Análise Orientada ao Objeto tem como característica a intercalação 
de métodos e atributos em um único plano, na especificação de “en-
capsulamento”, o banco de dados orientado ao objeto é visto como 
um modelo de dados munido de inteligência. 
Para entendermos melhor o conceito da análise orientada a objetos 
utilizaremos o exemplo do corpo humano. A menor unidade do nos-
so corpo é a célula, ela possui métodos e funções integradas [6]. No 
entanto, não temos apenas uma, mas um conjunto de células que for-
mam os tecidos e respectivamente um órgão, e os órgãos formam sis-
temas (Digestivo, Nervoso, etc ...). Em uma visão geral, o conjunto de 
todos esses sistemas forma o nosso corpo.
Sendo assim, analogamente definimos: a) célula como Objeto, b) Ór-
gão como Classe, c) Sistema como pacote e d) nosso corpo como um 
componente [6].
 
Por meio destas relações temos a capacidade de nos comunicarmos 
com as pessoas, e do ponto de vista da orientação ao objeto, pode-
mos concluir que os componentes devem ser compatíveis entre si e 
para interpretar a comunicação existem ferramentas que suportam as 
linguagens unificadas de modelagem, como a UML (Unified Modeling 
Language) [6].
As características fundamentais de uma metodologia orientada a obje-
tos são: abstração de dados, atributos e relacionamentos. 
Introdução a Análise de Sistemas
19
1.6.1 Abstração de Dados:
Ao invés de decompor em funções e procedimentos, caracte-
rísticas predominantes das técnicas estruturadas, a metodologia 
orientada a objetos reforça a abstração. A abstração dos dados 
inclui o conceito de superclasse e subclasse [3].
A partir da abstração surge o conceito de objeto, que é uma 
abstração de um conjunto de coisas do mundo real, de tal forma 
que [3]: a) todas as coisas do mundo real do conjunto devem ter 
as mesmas características; b) todas as instâncias estão sujeitas (e 
conforme) as mesmas normas.
Todo objeto tem uma descrição que é uma declaração formal 
que permite afirmar se um dado elemento do mundo real é ou 
não uma instância do objeto [3].
Os objetos podem se enquadrar em cincos categorias, são elas 
[3]:
•	 Tangíveis (exemplos: carro, casa, computador, etc.);
•	 Funções (exemplos: analista de sistemas, advogado, cliente, 
etc.);
•	 Interações (exemplos: venda casamento, ensinamento, etc.);
•	 Incidentes (exemplos: evento, acidente, abrir, etc.);
•	 Especificações (exemplos: modelo 123, codigo23, etc.);
1.6.2 Atributos:
Um atributo é a abstração de uma única característica possuída 
pelo objeto (entidade) [3], por exemplo, um objeto “Livro” pos-
sui como atributo o “ISBN”.
Um atributo pode ser classificado como: [3]
•	 Completo: possui todas as informações pertinentes ao ob-
jeto;
•	 Fatorado: Cada atributo deve captar um aspecto separado 
da abstração do objeto;
•	 Mutuamente independente: os atributos possuem valores in-
dependentes uns do outros.
•	 A classificação dos atributos é dada por elementos [3]:
•	 Descritivos: são as características são intrínsecas do objeto;
•	 Nominativos: os nomes e rótulos arbitrários; e
•	 Referenciais: há fatos que ligam uma instância de um deter-
Análise de Sistemas
20
minado objeto a instância de outro objeto.
1.6.3 Relacionamentos:
Eles representam a abstração do conjunto de associações existentes no 
mundo real. Eles são classificados conforme a sua multiplicidade [3], 
em três tipos, tais como:
1:1 – Uma dada instância de um objeto do tipo X é associada a uma, 
e somente uma, instância de um objeto do tipo Y [3].
1:M – Um objeto do tipo X é associado com um ou mais instâncias de 
um objeto do tipo Y [3].
M:M – Para cada instância de um objeto do tipo X é associada com 
uma ou mais instâncias de um objeto do tipo Y.
IMPORTANTE LEMBRAR QUE...
•	 A essência da abordagem orientada a objetos está voltada ao con-
ceito de encapsular os dados e as funções de tal maneira que o 
único meio de obter acesso ou atualizar os dados é através das 
funções associativas [3].
•	 De um modo geral a análise de sistemas consiste em métodos e 
técnicas de investigação e especificação da solução de problemas, 
a partir dos requisitos levantados para criação e implementação de 
um software [7]. Ou seja, é uma atividade cujo objetivo é entender 
o problema e definir a solução mais adequada.
•	 Esse processo de análise não é trivial, uma vez que é preciso enten-
der o problema de tal forma que o sistema desenvolvido atenda a 
necessidade do cliente.
•	 A falta de análise de sistemas pode comprometer futuras amplia-
ções no sistema, comprometer a tomada de decisões, dificultar a 
manutenção, tornar o sistema desconhecido de todos os usuários 
fazendo que apenas uma pessoa conheça o sistema entre outros 
pontos negativos [7].
Neste sentido percebemos a importância em estudar a análise de siste-
mas e para entendermos melhor sobre este tema falaremos na próxima 
seção sobre o problema versus a solução, uma vez que, o foco da aná-
lise de sistemas gira em torno deles (autora).
Introdução a Análise de Sistemas
21
1.7 Problema X Solução
O processo de desenvolvimento de 
software pode ser dividido, em geral, 
em quatro grandes fases: análise, pro-
jeto, implementação (codificação/ 
programação) e testes [7].
Na fase de análise destaca-se a inves-
tigação do problema, onde o analista 
desistemas precisa identificá-lo e en-
tendê-lo de maneira eficiente e clara.
Para que se possa definir o problema 
é preciso entender a situação atual. O 
resultado dessa análise é o enunciado 
do problema e o projeto é conside-
rado como a solução. Sendo que, os 
problemas mal elaborados podem, eventualmente, ser resolvi-
dos, no entanto, a solução não atenderá à expectativa do cliente 
[7]. 
Qual é a melhor forma de enten-
der o problema é interagindo com 
o usuário, questionando o mes-
mo, criando um canal de comuni-
cação direto com ele, presencial 
ou não [6].
É muito importante que o pro-
cesso de análise tenha qualidade, 
pois a correção dos problemas de 
entendimento durante essa fase 
implica em determinado custo. 
Na fase de projeto os custos aumentam. Entretanto, é bom des-
tacar que na fase de implementação este cenário piora, porque 
os custos continuam a crescer, e ao final, na fase de implantação 
os custos são ainda bem maiores. 
Para entender o domínio do problema alguns questionamentos 
devem ser feitos, são eles [8]:
•	 Por que é necessário desenvolver um projeto?
•	 Quais são os objetivos de negócio?
•	 O que o cliente precisa resolver?
Figura 3. Fonte: http://4.
bp.blogspot.com/_TelWejOUjJ8/
SxE5CLX8y4I/AAAAAAA-
AALo/oambNw9AffM/s320/
Interroga%C3%A7%C3%A3o.jpg
Figura 4. Fonte: http://www.rev.vagner-
queiroz.nom.br/FigSemAE_NT_D.jpg
Análise de Sistemas
22
•	 O que incomoda o cliente?
•	 Modelar o negócio proporciona uma visão geral do domínio do 
problema.
Outro ponto importante! Neste processo é necessário identificar quem 
são os usuários do sistema e os representantes dos grupos de usuários, 
negociar as responsabilidades de cada representante, definir como 
será a comunicação com os fornecedores e os representantes dos usu-
ários [8].
É importante entender quais são as necessidades destes usuários, aqui-
lo que realmente eles precisam para atender o real problema do cliente 
[8].
A seguir, alguns exemplos de necessidade que os usuários costumam 
descrever:
•	 “Eu preciso diminuir o tempo de atendimento do cliente no bal-
cão”;
•	 “Eu necessito que as informações pessoais do cadastro de clientes 
sejam emitidas de forma rápida”.
Este tipo de necessidade, descrita em alto nível, representa o que o 
usuário espera que o sistema faça [8]. 
Para “traduzir” as necessidades do usuário o analista de sistemas preci-
sa realizar uma boa análise, sem ter pressa de implementar o sistema. 
De nada adianta um sistema ser eficiente, ter uma interface bonita se 
não atende as expectativas do cliente.
O conjunto de necessidades que devem ser atendidas é denominada 
de requisitos do sistema [10].Este tema será explorado no próximo 
capítulo.
Atividades de Aprendizagem
1) Com relação às metodologias de desenvolvimento de software, clas-
sifique as alternativas abaixo como:
A – Análise Estruturada;
B – Análise Essencial;
C – Análise Orientada a Objetos
( ) É uma evolução da análise estruturada, ela preocupa-se com o 
Introdução a Análise de Sistemas
23
controle e utiliza ferramentas para representar os requisitos, bem 
como, a elicitação dos requisitos.
( ) Sua análise baseia-se na decomposição funcional e na utili-
zação de diagramas de fluxo de dados.
( ) Sua principal característica é a intercalação de métodos e atri-
butos em um único plano, na especificação de “encapsulamen-
to”, onde o banco de dados orientado é visto como um modelo 
de dados munido de inteligência.
( ) Foi o limite para os estudos mais sólidos dos métodos orien-
tados a objetos.
( ) Suas principais fases são: estudo inicial; estudo detalhado; 
definição e projeto de soluções alternativas; e o projeto físico;
( ) As características principais deste metodologia é abstração de 
dados, atributos e relacionamentos.
 ( ) Indica que um sistema deve ser modelado em três (3) dimen-
sões: dados; controle; e funções.
2) A partir da descrição abaixo de uma dada situação, analise a 
lacuna da direita e identifique de afirmação pertence ao domínio 
do problema ou da solução.
Situação: Uma clínica médica contratou a sua empresa para 
desenvolver um sistema web para que seus pacientes possam 
verificar a disponibilidade de datas e marcar consultas com seu 
médico. Você foi selecionado como o analista de sistemas deste 
projeto. Após o levantamento inicial de requisitos desse sistema, 
e você obteve as seguintes informações:
( P ) Domínio do Problema ( ) A secretária verifica na sua 
agenda de papel a disponibi-
lidade de data para uma con-
sulta com um determinado 
médico.
( S ) Domínio da Solução ( ) A secretária marca em sua 
agenda de papel a consulta de 
um paciente com um determi-
nado médico 
( ) Um paciente entra em con-
tato com a clínica, via telefo-
ne, para marcar uma consulta 
com um determinado médico.
 
Análise de Sistemas
24
( ) Um paciente entra em contato com a clínica, 
via telefone, para identificar quais são os espe-
cialidades médicas que a clínica oferece. (exem-
plos: Pediatra, Cardiologista, Clínica Geral etc.)
( ) Um paciente deve verificar em um página 
web a disponibilidade de data para uma consulta 
com um determinado médico.
( ) A secretária pode marcar a consulta para um 
paciente acessando o sistema web da clínica.
( ) Um paciente pode marcar sua consulta com 
um determinado médico acessando o sistema 
web da clínica.
( ) Um paciente pode acessar o sistema web da 
clínica para identificar quais são os especialida-
des médicas que a clínica oferece. (exemplos: Pe-
diatra, Cardiologista, Clínica Geral etc.)
 
2
CAPÍTULO
Levantamento de Requisitos
Objetivo
Neste momento iniciaremos nossos estu-
dos sobre requisitos do sistema. Veremos 
formas de levantamento dos requisitos 
junto aos clientes e estaremos estudando 
também os processos de engenharia e ge-
rência de requisitos.
Levantamento de Requisitos
27
O levantamento de requisitos, também denominado de elicita-
ção de requisitos, refere-se à etapa de compreensão do proble-
ma voltada ao desenvolvimento do software, isto é, serão iden-
tificadas as necessidades do usuário para resolver um problema 
ou atingir um objeto [11]. 
Qual é o foco desta etapa? É alinhar a visão do problema entre 
o usuário e os desenvolvedores. É neste momento que o analista 
de sistemas e o cliente, juntos, tentam levantar e definir as ne-
cessidades. Essas necessidades são chamadas de requisitos [11].
O resultado do levantamento de requisitos é o documento de 
requisitos. Ele contém todos os tipos de requisitos identificados, 
normalmente, escritos em linguagem natural. 
Os requisitos podem ser classificados como:
•	 Requisito	Funcional:
•	 Requisito	Não-Funcional.
2.1 Requisitos Funcionais
O requisito funcional descreve as funcionalidades do sistema, 
isto é, ele representa o que o sistema deve fazer. 
Exemplos:
Requisito Funcional 01 (REF.01): O sistema deve listar todos 
os alunos cadastrados em uma turma.
Requisito Funcional 02 (REF.02): O sistema deve calcular a 
média dos alunos de uma turma.
Requisito Funcional 03 (REF.03): O sistema deve permitir o 
CRUD (Create, Read, Delete, Up date) de alunos.
Requisito Funcional 04 (REF.04): O sistema deve gerar um 
relatório com a média dos alunos de uma turma.
No entanto, após a redação dos requisitos é necessário verificar 
se realmente foi entendida a necessidade do cliente, ou seja, a 
partir dos requisitos elicitados é possível modelar a solução para 
o problema.
A Tabela 1 apresenta alguns resultados onde, provavelmente, 
houve falhas na identificação dos requisitos.
 
Análise de Sistemas
28
Tabela 1. Resultado da falha na análise de requisitos
Fonte: [19]
2.2 Requisitos não-funcionais
Requisitos Não Funcionais (RNF) são requisitos que expressam res-
trições que o software deve atender ouqualidades específicas que o 
sistema deve possuir. Eles não associados diretamente com as funções 
presentes no sistema.
Os requisitos não funcionais podem ser classificados sob os seguintes 
aspectos:
•	 Usabilidade;
•	 Desempenho;
•	 Robustez;
•	 Critérios de Segurança;
•	 Portabilidade;
•	 Restrições de Hardware e Software;
•	 Questões sobre padronização e normatização;
•	 Questões sobre a distribuição e instalação.
Alguns exemplos de RNF:
Requisito Não Funcional 01 (RNF.01): O sistema deve emitir o rela-
tório da média dos alunos em 5 segundos (desempenho).
Requisito Não Funcional 02 (RNF.02): O sistema deve ser execu-
tado no sistema operacional Windows Vista e Linus nas distribuições 
Ubuntu e Famelix (restrições de software).
Requisito Não Funcional 03 (RNF.03): A especificação do servidor 
de banco de dados é SGBD MySql, com processador Core 2 Duo da 
Intel, 4GB de memória RAM ... (restrições de harware).
Levantamento de Requisitos
29
Requisito Não Funcional 04 (RNF.04): A interface do módulo 
de relatórios deve ser orientada ao uso de atalhos do teclado 
(usabilidade).
Requisito Não Funcional 05 (RNF.05): O sistema deve estar 
em conformidade com a norma XXXX (normatização).
ATENÇÃO: Há alguns requisitos que podem ser considerados 
como híbridos, ou seja, eles apresentam características de re-
quisitos funcionais e não funcionais. Um exemplo deste tipo de 
requisito seria: “O sistema deve emitir uma nota fiscal para um 
cliente, em um tempo máximo de 5 segundos” [9].
NOTE QUE: No exemplo acima, você deve observar que além 
do requisito funcional (emitir uma nota fiscal), há também um 
requisito não funcional, de desempenho, associado.
O que é mais importante na elicitação de requisitos: encontrá-los 
ou classificá-los corretamente? Com certeza o mais importante é 
encontrá-los [9].
2.3 Rastreabilidade
Para garantir que todas as características foram endereçadas por 
requisitos de software e todas as necessidades foram endereça-
das por características tem-se a rastreabilidade que é a base para 
avaliação de impacto [12].
A Tabela 2 apresenta uma rastreabilidade bidirecional entre as 
necessidades de características.
Característica 1 Característica 2 ... Característica M
Necessidade 1 X ...
Necessidade 2 X ...
... ... ... ... ...
Necessidade N X ... X
Tabela 2. Rastreabilidade Bidirecional - Fonte: Adaptado de [12]
Requisito 1 Requisito 2 ... Requisito M
Requisito 1 X ...
Requisito 2 X ...
... ... ... ... ...
Requisito N X ... X
Tabela 3. Rastreabilidade entre Requisitos - Fonte: Adaptado de [12]
Análise de Sistemas
30
A seguir são apresentadas 10 práticas para requisitos eficazes (Young, 
1999):
Figura 5. Fonte: http://www.inf.ufes.br/~labes/resources/images/imgPalm.jpg
1. Compromisso com abordagem.
2. Estabelecer e utilizar uma equipe responsável para os requisitos.
3. Definir as necessidades reais do cliente.
4. Utilizar e melhorar continuamente o processo de requisitos.
5. Manter iterações sobre os requisitos do sistema e os requisitos da 
arquitetura.
6. Usar um mecanismo para manter a comunicação no projeto.
7. Selecionar métodos familiares e manter um conjunto de produtos 
de trabalho.
8. Executar verificação e validação de requisitos.
9. Fornecer um mecanismo efetivo para acomodar as mudanças nos 
requisitos.
10. Executar o desenvolvimento com práticas bem conhecidas e pro-
vadas pela indústria, na organização e no projeto.
2.4 Processo de Engenharia de Requisitos
Todo processo deve definir quem irá fazer o que, como e quando será 
atingido o objetivo. O processo de engenharia de requisitos possui as 
seguintes fases: elicitação, análise e modelagem, Verificação e Valida-
ção e gerência [12].
•	 Na elicitação (levantamento) de requisitos os requisitos são iden-
tificados e entendidos, aplicando técnicas como: entrevistas, obser-
vação, análise de documentos, questionários, etc....
•	 Na análise e modelagem é representado o entendimento do pro-
blema, aplicando técnicas como: casos de uso (USC), diagrama de 
Levantamento de Requisitos
31
fluxo de dados (DFD), Tabelas de decisão, modelo entidade 
relacionamento (MER), etc...
•	 A verificação e validação dos requisitos é realizada utilizan-
do as técnicas de checklist, inspeções, revisões, etc...
•	 Na gerência são estabelecidos e mantidos um entendimen-
to comum entre o cliente e a equipe de projeto relacionadas 
às mudanças dos requisitos no sistema.
Na fase de elicitação de requisitos é preciso identificar quais são 
as fontes de informação para coletar os dados. As fontes de in-
formação são os clientes, usuários, desenvolvedores, especialis-
tas de domínio, documentos, os sistemas legados e a literatura 
[12].
Para encontrar estas fontes é preciso responder alguns questio-
namentos, tais como:
•	 Quem utiliza ou utilizará o sistema?
•	 Existe alguma solução em uso?
•	 Existem produtos similares?
•	 Qual a documentação utilizada hoje?
•	 Há normas ou legislações a serem seguidas?
•	 Quais são os livros, teses, artigos relacionados com a aplica-
ção que está sendo analisada?
2.5 Técnicas para Levantamento de requisitos
Para levantar os requisitos funcionais e não funcionais há diver-
sas técnicas, dentre elas as mais aplicadas são as entrevistas, a 
observação e a prototipação de telas.
A entrevista - é uma das técnicas 
mais empregadas para identificar e 
entender os requisitos definidos pelo 
usuário. Pode ser utilizada em qual-
quer situação, pois é uma técnica 
muito simples e direta. Para se ter su-
cesso com esta técnica é preciso que o 
conhecimento do entrevistador não 
interfira na troca de informações que 
se movimentam durante a etapa de 
levantamento de requisitos.
Figura 6. Fonte: http://suachance.
files.wordpress.com/2009/06/entre-
vsita.jpg
Análise de Sistemas
32
A observação - é um método científico, 
aplicado no desenvolvimento de uma in-
vestigação. É caracterizada por perceber, 
visualizar e não interpretar, apenas obser-
var. Seu resultado é uma descrição do que 
foi visualizado, sem que haja qualquer ju-
ízo de valor. O moderador desta observa-
ção deverá acompanhar a realização das 
tarefas. O contato com um utilizador inex-
periente quando este interage com o siste-
ma, permite uma percepção facilitada do 
ponto de vista das dificuldades encontra-
das na navegação ou no uso de uma interface. 
Prototipação de telas - Ela per-
mite identificar as expectativas do 
cliente principalmente nos aspectos 
de usabilidade. De um modo geral 
ela envolve programação. Neste 
momento é apresentando ao clien-
te um esboço da interface do siste-
ma que será desenvolvido [9].
Figura 8. Fonte: [9]
Dentre os requisitos levantados, esperam-se como atributos destes re-
quisitos que eles sejam [12]:
•	 Claros;
•	 Bem escritos;
•	 Sem ambigüidades;
•	 Implementáveis;
•	 Com baixa abstração;
•	 Verificável; e
•	 Rastreáveis.
2.6 Análise e Modelagem de Requisitos
Esta etapa consiste na documentação formal, por meio de uma de-
terminada ferramenta, dos dados coletados na etapa de elicitação de 
requisitos. Seu objetivo é abstrair o requisito de tal forma que seja 
possível identificar todos os detalhes e suas dependências com outros 
Figura 7. Fonte: http://3.bp.blogspot.
com/_Hrnl06uDEmE/SUA5RxV9qDI/
AAAAAAAAAEE/t1JhthJc0mc/s320/
observar.jpg
Levantamento de Requisitos
33
requisitos. As técnicas de Modelagem são:
•	 Casos de uso;
•	 Diagrama de Fluxo de Dados (DFD)
•	 Tabelas de decisão:
•	 Diagramas de Estado;
•	 Dicionário de dados;
•	 Modelo Entidade-Relação (ER).
O caso de uso é um meio para especificar as exigências requeri-
das por um sistema, ou seja, ele representa um padrão de com-
portamento do sistema.
O diagrama de fluxo de dados (DFD) é uma notação gráfica 
utilizada para representar os fluxosde informação e as transfor-
mações ocorridas pela passagem dos dados das entradas para 
as saídas.
A Tabela de decisão é uma forma organizada em Tabela para ex-
pressar qual o conjunto de condições que é necessário acontecer 
para que um dado conjunto de ações seja realizado.
O diagrama de estados é uma técnica que descreve o comporta-
mento do sistema, ela permite descrever todos estados possíveis 
que um objeto pode estar e como o seu estado é comprometido 
por eventos que o atingem.
O DFD especifica a informação por meio de rótulos, no entanto, 
não descreve o seu significado. Já o dicionário de dados descre-
ve o conteúdo dos itens de informação. 
2.7 Gerência de Requisitos
Na etapa de desenvolvi-
mento é normal que no-
vos requisitos sejam defi-
nidos e/ou que requisitos 
já definidos sejam altera-
dos. Estas mudanças são 
consideradas na etapa de 
desenvolvimento e de-
vem ser acompanhadas 
Figura 9. Fonte: http://www.pirelliclubtruck.com.br/
revistaclubtruck/revista/truck13/imagens/gestao_01.
jpg
Análise de Sistemas
34
para garantir que todos os artefatos afetados por uma alteração de re-
quisitos sejam alterados.
2.8 Quais são as pricipais atividades da Gerência de 
Requisitos? 
São elas: controle das solicitações de mudanças, gerenciamento do 
escopo, gerenciamento das inconsistências entre requisitos e o projeto, 
e manutenção da rastreabilidade entre os requisitos.
A solicitação da mudança inicia por meio de uma solicitação formal. 
Em seguida avalia-se o seu impacto, para tal é preciso ter uma rastre-
abilidade consistente. Logo após, determina-se a viabilidade, aprova-
ção, revisa-se o planejamento e executam-se as ações corretivas para 
as inconsistências (caso existam).
Para manter o escopo do projeto os requisitos devem ser mantidos 
dentro do escopo que foi definido para o projeto, ou seja, não devem 
ser realizadas atividade que vão além do solicitado, uma vez que, este 
tipo de ação pode impactar no prazo e custo do projeto.
2.9 Regras de Negócio (RNE)
Além dos requisitos funcionais e não funcionais, existem as regras de 
negócio que descrevem como uma dada funcionalidade deve ser rea-
lizada. Vejamos alguns exemplos de regras de negócio:
Regra de Negócio 01 (RNE. 01): A senha deve ter no mínimo 6 e 
no máximo 10 caracteres, alfanuméricos e não deve aparecer durante 
a digitação.
Regra de Negócio 02 (RNE. 02): A média final deve ser calculada 
através da somatório das notas dos quatro bimestres e dividida por 
quatro.
Regra de Negócio 03 (RNE. 03): A forma do registro no log de 
operações deve ser dd-mm-aaaa (exemplo: 01-01-2010), hora hh:mm 
(exemplo: 12:12).
No próximo capítulo vamos focalizar os casos de uso.
3
CAPÍTULO
Diagrama de casos de uso
Objetivo
Neste capítulo estudaremos formas de 
especificar sistemas orientados a objetos 
com foco na visão do usuário. Veremos a 
definição e documentação dos casos de 
uso e seus tipos de relacionamentos.
Diagrama de casos de uso
37
Um diagrama de casos de uso visa permitir a compreensão do 
comportamento de um sistema por qualquer pessoa, buscando 
apresentar o sistema visto pela perspectiva do usuário. 
Dentre todos os diagramas da UML (Unified Modeling Langua-
ge) é o mais abstrato e informal, sendo muito utilizado no início 
da modelagem do sistema, principalmente nas etapas de elici-
tação e análise de requisitos. No entanto, nada impede que ele 
possa ser consultado e modificado em outras fases [13].
Este tipo de diagrama é muito útil para o entendimento dos re-
quisitos do sistema, facilitando a especificação, visualização e 
documentação das características, funções e serviços do sistema 
almejado pelo usuário [13].
A Tabela 4 apresenta os elementos básicos, que compõem um 
caso de uso, e sua representação gráfica.
Elemento Descrição Sintaxe
Caso de uso Representa um diá-
logo entre um ator e 
sistema
uc U s e C a s e M ode l
N om e do C a s o de 
U s o
Ator Representa um papel 
que pode ser assumi-
do por um usuário
uc U s e C a s e M ode l
N om e do C a s o de 
U s o
Sistema Representa o limite 
entre o sistema e os 
atores do sistema
Associação Representa a parti-
cipação de um ator 
em um caso de uso
 
Tabela 4. Sobre um Caso de Uso
Fonte: Adaptado de [12]
uc use case model
uc use case 
model
Nome 
do caso de uso
Nome do ator
Análise de Sistemas
38
A seguir, você estudará em detalhes cada elemento do caso de uso. 
3.1 Sistema
Entende-se como sistema todo e qualquer tipo sistema. Ele identifica a 
funcionalidade básica do escopo inicial, bem como, os termos e defini-
ções no início do trabalho, tais como: glossário e catálogo.
Sua notação é uma caixa, como o nome do sistema exposto em cima 
ou dentro da caixa.
3.2 Ator
O ator é alguém ou alguma coisa que interage, de alguma forma, com 
o sistema. Ele representa um papel, não um usuário individual do sis-
tema, onde uma pessoa pode assumir diferentes atores dentro de um 
sistema [12].
A figura 10 representa alguns exemplos de atores.
 
Figura 10. Fonte Própria
Atenção!! O ator é uma classe e não uma instância. Ele deve ter um 
nome que represente o seu papel dentro do sistema e sua interação 
com o sistema é dada através da troca de mensagens. 
Algumas dicas para identificar os atores [12]:
•	 Quem utilizará a funcionalidade principal do sistema?
•	 Quem necessita administrar e manter o sistema funcionando?
Diagrama de casos de uso
39
•	 Quais dispositivos de hardware o sistema precisará manipu-
lar?
•	 Com quais outros sistemas, o sistema precisará interagir?
•	 Quem tem interesse nos resultados que o sistema produzirá?
Assim como uma classe o ator pode ser generalizado/ especiali-
zado, ou seja, há herança entre atores. Exemplo: Um ator “pes-
soa física” pode herdar as características de um ator “Pessoa”.
3.3 Casos de uso
Os casos de usos referem-se às funcionalidades que podem ser 
utilizadas pelos atores, eles descrevem e validam o que o sistema 
irá fazer. 
A Figura 11 apresenta um exemplo da notação de um caso de 
uso.
Figura 11. Exemplo de Caso de Uso
Fonte: Própria
Os casos de uso podem ser classificados como primários ou se-
cundários. Um caso de uso primário refere-se a um determinado 
processo focalizado nos requisitos funcionais do software, como 
por exemplo: cadastrar uma turma ou gerar um relatório das 
médias dos alunos. Enquanto que um caso de uso secundário 
se refere a um processo periférico, como a manutenção de um 
cadastro [13].
Para identificar os casos de usos de um sistema é preciso verificar 
quais são as necessidades dos atores, como por exemplo:
•	 Funcionário: cadastra DVD’s;
•	 Cliente: loca DVD’s; e
•	 Sistema Financeiro: valida situação do cliente.
Outros questionamentos que podem ser realizados para encon-
trar os casos de uso de um sistema:
Análise de Sistemas
40
•	 Quais são as funções que os atores esperam do sistema?
•	 O que cada ator precisa fazer?
•	 O ator precisa realizar as operações de cadastro, exclusão, altera-
ção e busca sobre alguma coisa no sistema?
•	 Quais são as entradas e saídas do sistema? Qual a origem e destino 
dos dados?
Assim como nos requisitos, nos casos de uso também deverá haver 
rastreabilidade bidirecional, conforme a Tabela 5. 
Requisito 1 Requisito 2 ... Requisito M
Caso de Uso 1 X ...
Caso de Uso 2 X ...
... ... ... ... ...
Caso de Uso N X ... X
Tabela 5. Matriz de Rastreabilidade Bidirecional
Fonte: Adatpado [12]
Para cada requisito funcional deve haver, pelo menos, um caso de uso. 
Assim como, para cada caso de uso, pelo menos, um requisito funcio-
nal. Em ambos os casos pode ser 1 para 1..n. 
Os casos de uso devem ser documentados, eles fornecem instruções 
em linhas gerais sobre o funcionamento do sistema, das atividades quedeverão ser executadas, dos atores envolvidos, das possíveis restrições 
entre outras [13].
A documentação produzida, além de ser utilizada no momento da im-
plementação do sistema, é utilizada como base para a construção de 
outros diagramas, como o de sequência, por exemplo, e ela fornece 
um relatório ao cliente sobre o comportamento esperado de um dado 
caso de uso [13]. 
3.4 Documentação de casos de uso
A documentação de um caso de uso descreve, por meio de uma lin-
guagem simples, a função do caso de uso, quais atores interagem com 
ele, quais fases serão executadas pelo ator e pelo sistema para que o 
caso de uso execute sua função [13]. Um caso de uso deve, sempre, 
ser iniciado por um ator [12].
Não há um formato específico, definido pela UML, para documentar 
casos de uso de tal forma que represente as características do próprio 
Diagrama de casos de uso
41
diagrama. Isto permite uma flexibilidade no formato da docu-
mentação que permite até pseudocódigo, no entanto, o objetivo 
da documentação do caso de uso é permitir que até mesmo os 
usuários mais leigos entendam o que o caso de uso faz [13].
A seguir é apresentada uma sugestão de documentação para um 
caso de uso na Tabela 6.
Nome do Caso de Uso Abrir Conta
Caso de Uso Geral
Ator Principal Cliente
Atores Secundários Funcionário
Resumo Este caso de uso descreve as fases para 
abrir uma conta corrente
Pré-Condições 1. A solicitação da abertura da conta 
deve ter sido aprovada anteriormente
Pós-Condições É necessário fazer um depósito inicial
Fluxo Principal
Ações do Ator Ações do Sistema
1. Solicitar a abertura da conta
2. Consultar o cliente pelo CPF (Pessoa 
Física) ou CNPJ (Pessoa Jurídica)
3. Informar a senha da conta
4. Abrir a conta
5. Informar o valor a ser depo-
sitado
6. Registrar o depósito
7. Emitir o cartão da conta
Restrições/Validações 1. Para abrir uma conta a idade do 
cliente deve ser maior ou igual a 18 
anos
2. O valor mínimo de depósito é R$ 
50,00
3. O cliente precisa fornecer um com-
provante de residência no seu nome 
(conta de água, luz ou telefone fixo)
Análise de Sistemas
42
Fluxo Alternativo – Manutenção do Castrado do Cliente
Ações do Ator Ações do Sistema
1. Se for necessário, Executar o 
Caso de Uso Manter Cliente, para 
gravar ou atualizar o cadastro do 
cliente
Fluxo Exceção – Cliente Menor de Idade
Ações do Ator Ações do Sistema
1. Emitir uma mensagem para clien-
te informando que ele não possui 
a idade mínima para abertura da 
conta
2. Recusar a solicitação da abertura 
da conta
Tabela 6. Documentação do Caso de Uso - Abertura de Conta
Fonte: Adaptado de [13]
Comentário:
•	 De acordo com o modelo apresentado, primeiramente é preciso 
apresentar uma descrição sobre o caso de uso. 
•	 O campo “Caso de Uso de Geral” é utilizado quando há casos de 
usos especializados, como por exemplo uma conta especial, caso 
estivéssemos documentando o caso de uso de uma conta espe-
cial ele estaria derivando do caso de uso “Abrir Conta”. Como no 
exemplo da Tabela 6 trata-se do caso de uso geral, o campo “Caso 
de Uso Geral” ficou em branco [13].
•	 Já o campo “ator principal” identifica o ator que mais interage com 
o caso de uso, onde os atores secundários são aqueles que menos 
interagem com o caso de uso. 
•	 No exemplo foram identificados dois atores: o Cliente e o Funcio-
nário. O cliente é considerado como ator principal porque é ele 
quem solicita o serviço. No entanto, quem interage realmente com 
o serviço a funcionalidade de abertura da conta é o ator Funcioná-
rio, e na documentação deste caso de uso, as ações tomadas pelo 
Funcionário são representadas pelas ações do sistema.
•	 Em seguida tem-se o campo “Resumo” que apresenta o objeti-
vo do caso de uso. Logo após, vem as pré e pós-condições que 
representam determinadas condições que precisam ser satisfeitas 
para que o caso de uso seja executado (pré-condições) e concluído 
(pós-condições).
•	 O fluxo principal representa a sequência das ações que devem ser 
realizadas. Onde o fluxo alternativo representa uma situação que 
Diagrama de casos de uso
43
não está compreendida no fluxo principal, ou seja, é uma 
situação que foge da situação ideal do caso de uso. 
•	 Já o fluxo de exceção trata as situações que precisam ser tra-
tadas para dar continuidade ao fluxo da execução da tarefa 
quando uma determinada regra de negócio não foi atendi-
da, como neste exemplo, é esperado que a idade mínima do 
cliente seja igual ou superior a 18 anos.
•	 Por fim, têm-se as restrições e validações do sistema a fim de 
torná-lo mais robusto, elas representam as regras de negócio 
da empresa.
3.5 Associações
Uma associação representa a participação de um ator em um 
caso de uso, ela é o único relacionamento entre atores e casos 
de uso [12]. Também podem ocorrer associações entre casos de 
usos, neste caso, este tipo de relacionamento recebe os seguintes 
nomes: inclusão, exclusão ou generalização [13].
A associação entre um ator e o caso de uso representa que este 
ator se relaciona com a função que está sendo representada pelo 
caso de uso, conforme apresentado na Figura 12.
Figura 12. Associação entre Ator e Caso de Uso
Fonte: Adatpado [13]
3.6 Relacionamentos
Generalização /Especialização
Quando um caso de uso é uma especialização de outro caso de 
uso [12], ou seja, é uma forma de associação entre os casos de 
uso que possuem características semelhantes e algumas particu-
laridades exclusivas [13].
Análise de Sistemas
44
O exemplo da Figura 13 representa o relacionamento entre a função 
de abertura de conta que difere em umas características quando se 
classifica como conta especial e poupança. No entanto, elas possuem 
algumas características que são comuns a elas, enquanto contas ban-
cárias, independentes de seu tipo.
 
Figura 13. Exemplo de Generalização
Fonte: Adaptado de [13]
Quando um caso de uso é uma especialização de outro caso de uso 
[12], ou seja, é uma forma de associação entre os casos de uso que 
possuem características semelhantes e algumas particularidades exclu-
sivas [13].
Este tipo de relacionamento também pode ocorrer entre atores, con-
forme apresentado na Figura 14.
 
Figura 14. Exemplo de Generalização entre Atores - Fonte: Adaptado de [13]
Diagrama de casos de uso
45
Include (Inclusão)
A associação de inclusão é utilizada quando há uma situação 
comum entre dois ou mais casos de uso. Este tipo de relacio-
namento indica obrigatoriedade, isto é, quando um dado caso 
de uso possui uma inclusão com outro, a execução do primeiro 
implica também na execução do segundo [13].
Figura 15. Exemplo de Inclusão
Fonte: Adaptado de [13]
No exemplo apresentado na Figura 15 nota-se que, toda vez que 
for realizado um saque ou um depósito, obrigatoriamente, deve-
se registrar essas operações.
Extend (Extensão)
Este tipo de relacionamento permite adicionar novos comporta-
mentos ao caso de uso sem prejudicar o seu entendimento [12]. 
Esta associação de extensão é utilizada para descrever situações 
opcionais de um dado caso de uso, ou seja, ela representa cená-
rios que somente ocorrerão em situações específicas.
Para facilitar o entendimento, será apresentado um exemplo de 
login onde é necessário o usuário de registrar quando não possui 
cadastro, conforme a Figura 16.
 
Figura 16. Formulário de Login - Fonte: De-
senvolvido a partir do exemplo de [13]
Análise de Sistemas
46
A Figura 17 representa um exemplo onde há uma associação por ex-
tensão.
 
Figura 17. Exemplo de Extensão
Fonte: Adaptado de [13]
Este exemplo representa uma situação do formulário de login apre-
sentado na Figura 17 onde um usuário precisa logar-se para acessá-lo. 
No caso do usuário não possuir login/senha ele pode clicarna opção 
“Auto-registrar”, para se cadastrar no sistema, sendo que essa situação 
ocorrerá apenas uma vez, depois, o usuário terá acesso ao sistema e 
não passará novamente por esta situação [13].
No próximo capítulo apresentaremos os diagramas de sequência e 
classe.
4
CAPÍTULO
Diagrama de Sequência
Objetivo
Neste capítulo estudaremos outras formas 
de especificar sistemas orientados a obje-
tos, entretanto neste momento o foco é a 
visão do desenvolvedor. Sendo assim, vere-
mos a definição e a documentação dos dia-
gramas de sequencia e de classe.
Diagrama de sequência
49
O diagrama de sequência é um diagrama de comportamento 
que preocupa-se com a ordem temporal em que as mensagens 
são trocadas entre os objetos envolvidos em dado processo [13], 
isto é, ele apresenta a interação dos objetos organizados no tem-
po.
A utilização deste tipo de diagrama pode ser empregada para 
detalhar a colaboração na realização de um caso de uso [18].
Um diagrama de sequência identifica o evento gerador do pro-
cesso modelado e o ator envolvido, bem como ele determina 
como o processo deve ser implementado.
A Figura 18 apresenta um diagrama de sequência para a função 
Buscar Imóvel.
Figura 18. Diagrama de Sequência da Função Buscar Imóvel
Fonte: Própria
Análise de Sistemas
50
4.1 Alguns elementos de um diagrama de sequência
•	 Atores: são os mesmos descritos nos diagramas de casos de uso
•	 Linha de Vida: representa o tempo de vida em que o objeto existe 
durante um processo.
•	 Mensagem Síncrona: demonstra a ocorrência de eventos, envol-
vendo métodos.
•	 Retorno: é um tipo de mensagem que indica a resposta para o 
objeto ou ator que a chamou.
 
Figura 19. Elementos do Diagrama de Sequência
Fonte: [18]
Diagrama de sequência
51
4.2 Diagrama de Classe
O diagrama de classe é um dos mais utilizados da UML. Ele 
serve de apoio para a maioria dos demais diagramas. Ele define 
a estrutura das classes que serão utilizadas no sistema, determi-
nando os seus métodos e atributos de cada classe, bem como, o 
relacionamento entre as classes [13].
A Figura 20 apresenta um exemplo de diagrama de classes.
 
Figura 20. Diagrama de Classes
Fonte: Própria
Análise de Sistemas
52
Atividades de Aprendizagem
1) Com relação aos diagramas de sequência leia as afirmativas e assi-
nale V para as alternativas Verdadeiras e F para as alternativas Falsas.
( ) O diagrama de sequência é um diagrama comportamental que se 
preocupa em demonstrar a ordem espacial em que as mensagens são 
trocadas entre os objetos envolvidos em um determinado processo.
( ) A construção do diagrama de sequência geralmente considera um 
único caso de uso.
( ) Um diagrama de sequência costuma identificar o ator responsável 
pelo evento gerador do processo que está sendo modelado.
( ) Em um diagrama de sequência as mensagens enviadas por cada 
objeto são representadas por setas entre os objetos que se relacionam.
 
( ) Diagramas de sequência possuem dois eixos: o eixo vertical, que 
mostra o tempo e o eixo horizontal, que mostra os objetos envolvidos 
na sequência de uma certa atividade.
( ) Os diagramas de sequência mostram apenas os objetos que são 
criados como parte do cenário documentado pelo diagrama.
5
CAPÍTULO
Diagrama de Fluxo de dados - DFD
Objetivo
Neste capítulo estudaremos formas de 
especificar sistemas estruturados. Estuda-
remos também a definição e a documen-
tação dos diagramas de fluxo de dados 
(DFD).
Diagrama de Fluxo de dados - DFD
55
Um Diagrama de Fluxo de Dados (DFD) é uma das mais utiliza-
das ferramentas que, em forma de notação gráfica, nos auxilia 
na modelagem de sistemas operativos mais complexos do que 
apenas a manipulação dos dados. Ele apresenta uma visão es-
truturada dos dados, ou seja, um fluxo de dados que nos per-
mite representar várias visões do sistema, analisado assim em 
diferentes níveis de detalhamento [12]
Estes níveis de detalhamento variam de acordo com a clareza 
dos processos do projeto, onde o Diagrama de Contexto repre-
senta uma visão macro do sistema, e em seguida temos os dia-
gramas de níveis. O nível mais alto é conhecido como DFD de 
nível 0, que está logo abaixo do diagrama de contexto, onde 
neste nível serão mostradas as funções mais importantes do sis-
tema. Caso não esteja claro o processo, o mesmo é aperfeiçoado 
a cada nível [12].
Este ponto de vista do projeto, visando o fluxo de dados nos per-
mite uma visão mais ampla do sistema, pois no ponto vista das 
pessoas, máquinas e da empresa, só é possível visualizar apenas 
partes do que acontece com o sistema. Isto significa uma grande 
mudança em relação às formas clássicas de analise de sistemas, 
que costumavam primeiramente abordar a visão do usuário em 
relação ao sistema [12].
De forma resumida um DFD representa (como acontece com a 
transformação dos dados que se movimentam pelo sistema) e 
apresenta as funções e sub-funções que modificam o fluxo de 
dados.
Análise de Sistemas
56
Elementos que compõe um Diagrama de Fluxo de Dados:
Notação Gane e 
Sarson
Notação 
DeMarco e 
Yourdan
Processo Um processo mostra 
uma parte do sistema 
que altera as entradas 
e saídas, e tem no 
mínimo eu fluxo de 
dados de entrada e 
outro de saída.
Nome
n
Nome
Repositório 
de Dados
É utilizado para 
representar os dados 
armazenados de algu-
ma forma.
Nomen Nome
Entidade 
Externa
Ilustra um agente 
esterno ao sistema que 
está sendo modelado, 
e interage com ele. 
Nome Nome
Fluxo de 
Dados
Mostra um dado ou 
uma coleção deles, e 
sempre inicia ou termi-
na em um processo.
Nome Nome
 
Tabela 7. Elementos de um DFD
Fonte:Adaptado de [12]
5.1 Como elaborar um DFD
1) Eleger nome expressivos:
•	 Evitar nomes de pessoas ou grupos;
•	 Nomear o processo a fim de identificar as suas funções;
•	 Os nomes devem ser familiares ao usuário.
2) Numerar os processos:
•	 A numeração não depende da ordenação entre os processos, ele 
apenas ajuda a identificá-los.
Diagrama de Fluxo de dados - DFD
57
Exemplo:
Figura 21. Numeração de Processos
Fonte: [12]
3) Redesenhar o DFD quantas vezes forem precisas para 
ter uma aparência legível:
 
•	 No mínimo 3 e no máximo 7 bolhas. Exceto no caso do 
diagrama de contexto:
Figura 22 - Diagrama de contexto
Fonte: [12]
4) Assegure-se de que o DFD possua uma relação lógica:
•	 Cuide para que não desenhe um processo com entradas e 
sem saídas;
•	 Tenha cuidado também para que o processo não tenha ge-
ração espontânea de dados, processo com saída, mas sem 
entrada. Com exceção da geração de números aleatórios.
Análise de Sistemas
58
5) Verifique se todos os processos e fluxos tenham rótulos:
•	 Falta de Atenção, erros, ou não soube nomear? 
•	 Fluxo: itens importantes de dados não foram relacionados ou fo-
ram reunidos;
•	 Processo: desordem do analista. “Desenhou em fluxograma dis-
farçado”.
6) Cuidado com o armazenamento de apenas leitura ou de ape-
nas escrita:
•	 Equivalente a diretriz de processos com apenas entradas ou ape-
nas saídas;
•	 Um bom armazenamento deve ter entradas e saídas.
5.2 Níveis do DFD
Em uma modelagem de diagramas mais complexos, é aconselhável 
que eles sejam criados em níveis, e que cada um apresente de forma 
sucessiva, os detalhes de uma parte do nível anterior.
O DFD do mais alto nível consiste numa visão do sistema inteiro; os flu-
xos de dados representam as interfaces entre o sistema e as entidades 
externas. Ele é conhecido como Diagrama de Contexto e é opcional.
Figura 23
Fonte: [12]
E1 E1
E2
Sistema
Diagrama de Contexto
Diagrama de Fluxo de dados - DFD
59
O diagrama que vem logo em seguida do Diagrama de contexto 
é conhecido como FIGURA 0, ou de nível0. Esta é a versão de 
mais alto nível que representa as principais funções do sistema e 
também as principais interfaces entre as funções.
5.3 Vantagem do uso de DFD´s em níveis 
•	 Com DFD’s em níveis é possível adotar a abordagem TOP-
DOWN. Com isso é possível que o gerente faça a leitura dos 
níveis mais altos, para um melhor entendimento, ou ainda 
ter uma visão geral do sistema. Programadores e usuários 
podem ler do mais resumido ao mais detalhado, limitando-
se as áreas do seu interesse.
•	 Não existem ligações entre a continuação em outra página. 
Fluxos de Dados que antecedem somem da próxima página, 
ele fica no contexto do pai, ou seja, cada página é referente 
a uma área de trabalho destinada a ele, você nunca terá que 
procurar em outra página e continuar sua leitura para ter 
uma descrição total.
•	 Todos os diagramas devem ocupar apenas uma página.
Exemplo de um Diagrama de Fluxo de Dados (DFD):
 
Figura 24. Exemplo de DFD
Fonte: [12]
Análise de Sistemas
60
Atividades de aprendizagem
1) Correlacione os termos apresentados com as definições descritas 
abaixo:
( A ) Processo 
( B ) Repositório de Dados 
( C ) Entidade Externa 
( D ) Fluxo de Dados 
 
( ) Mostra um agente externo ao sistema que está sendo modelado, e 
interage com ele.
( ) Mostra um dado ou uma coleção deles, e sempre inicia ou termina 
em um processo.
( ) É utilizado para representar os dados armazenados de alguma for-
ma.
( ) Mostra uma parte do sistema que altera as entradas e saídas, e tem 
no mínimo eu fluxo de dados de entrada e outro de saída.
6
CAPÍTULO
Ciclo de vida
Objetivo
Inicialmente, vamos descobrir juntos que 
existem diferentes ciclos de vida de sof-
tware, Isto é, formas distintas de se desen-
volver um software. Em seguida, iremos 
estudar os modelos de ciclo de vida de 
software mais tradicionais na literatura e 
no mercado.
Ciclo de vida
63
Um processo de software é utilizado para construir sistemas de 
qualquer natureza com o objetivo de favorecer a produção de 
sistemas com qualidade, que atenda as necessidades dos usuá-
rios, dentro do cronograma e orçamento planejado [15]. 
 
Ele não pode ser definido de forma universal, para que seja 
eficaz e produza um produto de qualidade, é necessário que o 
processo esteja alinhado com as especificações do projeto, ou 
seja, os processos devem ser definidos caso a caso, levando em 
consideração o domínio do problema, complexidade, tecnologia 
a ser adotada etc [15].
Dentro deste contexto, a escolha do modelo de ciclo de vida, ou 
modelo de processo, é o ponto de partida para definir o proces-
so de desenvolvimento do software.
De um modo geral, o modelo de ciclo de vida organiza as ati-
vidades do processo, definindo a sequência e as dependências 
das mesmas.
6.1 Algumas definições de ciclo de vida de sof-
tware
•	 Um framework que contém os processos, atividades e 
tarefas envolvidas na implementação, operação e manu-
tenção de um produto de software, levando em conside-
ração toda a vida do software, desde a definição de seus 
requisitos até o encerramento de seu uso (apud [16], 
ISO/IEC 12207);
•	 É dividir a vida de um produto ou projeto em fases (apud 
[16], SEI, Glossário do CMMI);
•	 É uma passagem completa por quatro fases: concep-
ção, elaboração, construção e transição. É o intervalo de 
tempo entre o início de concepção e o final da fase de 
transição (apud [16], IBM/ Rational, Glossário do RUP).
Análise de Sistemas
64
6.2 Os componentes do desenvolvimento de um ciclo 
de vida
Fases: indicam o progresso do projeto;
Atividades: requerem ações para criar e entregar o projeto;
Artefatos: são produtos palpáveis elaborados durante o projeto; e
Marcos: são eventos importantes no projeto.
Em geral, os modelos de processos possuem as fases de Análise e Es-
pecificação de Requisitos, Projeto, Implementação, Testes e Entrega e 
Implantação [15]. 
Há uma variedade de modelos com componentes diversos que podem 
ser aplicados a diferentes projetos. Não há um modelo mais correto 
que outro. É de responsabilidade do gerente de projeto definir o mo-
delo mais indicado para o seu projeto [16].
6.3 Modelos de ciclo de vida
Os principais modelos de ciclo de vida são classificados como [15]: 
Modelos Seqüenciais, Modelos Incrementais e Modelos Evolutivos.
6.3.1 MODELO SEQUENCIAL
Este modelo organiza o processo em uma sequência de fases. O mo-
delo cascata é considerado o principal modelo desta categoria e ele 
serviu como base para outros modelos, como os modelos incrementais 
e evolutivos [15].
6.3.2 MODELO CASCATA
O modelo cascata, também conhecido como modelo clássico, orga-
niza as atividades do processo de desenvolvimento de uma maneira 
seqüencial, conforme apresentado na Figura 25 [15].
 
Figura 25. Modelo Clássico/Cascata
Fonte: Adatptado [16]
Ciclo de vida
65
O Modelo Cascata é baseado nos processos convencionais de 
outras engenharias; possui uma abordagem sistemática e se-
qüencial cujos marcos e entregáveis são de fáceis de identificar; 
é fortemente documental e pouco iterativo; implica em uma es-
pecificação completa e é difícil introduzir mudanças depois de 
ter iniciado o processo [16].
As fases deste modelo são [16]:
1. Especificação (Requisitos): identificação e análise dos 
requisitos do sistema de acordo com as necessidades dos 
usuários;
2. Projeto (Design): é o detalhamento da solução para o 
sistema ser construído, ele incluiu padrões de projetos, 
algoritmos, definição da arquitetura etc.
3. Implementação: é a programação da solução na fase 
de projeto. Ela inclui os testes realizados sobre os módu-
los implementados (os testes de unidade).
4. Verificação e Validação: verificar se o que foi imple-
mentado está conforme a especificação e validar se o 
que foi implementado atende as necessidades do usuá-
rio. Esta fase também inclui os testes de integração.
5. Manutenção: evolução contínua do sistema trata os er-
ros e as adaptações do sistema.
A manutenção deve ser considerada em todos os ciclos de 
vida, ela não deve ser encarada como uma fase isolada e sim 
como uma aplicação contínua das atividades envolvidas nas 
fases anteriores [16].
Há quatro tipos de manutenção:
•	 Manutenção Corretiva: corrigir os erros encontrados;
•	 Manutenção Adaptativa: adaptar o software em relação 
a uma mudança externa. Exemplo: Atualização do sistema 
operacional;
•	 Manutenção Evolutiva: é melhoria contínua do software. 
Exemplo: Inclusão de uma nova funcionalidade.
•	 Manutenção Preventiva: é uma melhoria interna do siste-
ma para otimizar um recurso. Exemplo: Otimizar um deter-
minado algoritmo no código.
Análise de Sistemas
66
O modelo Cascata possui algumas críticas relacionadas à sua eficiên-
cia, sendo destacados, a seguir, alguns dos problemas identificados:
•	 Projetos reais não seguem o fluxo na sequência definida pelo 
modelo;
•	 Os requisitos precisam ser definidos claramente já no início do 
projeto, o que na prática é difícil ocorrer.
•	 O usuário terá uma versão operacional do sistema apenas no 
final do projeto;
•	 O atraso em uma fase impacta na outra na fase.
6.3.2 MODELO V
Este modelo é uma variação do modelo em cascata, que destaca a 
relação entre as atividades de teste e as demais fases do processo, con-
forma apresentado na Figura 26 [15].
Figura 26. Modelo V
Fonte: [15]
Este modelo sugere que os testes de unidade 
são utilizados para verificar a implementa-
ção e o projeto detalhado. A conexão entre 
os lados direito e esquerda do modelo impli-
ca que, para os problemas identificados em 
uma atividade de teste, na fase correspon-
dente do lado esquerdo e as fases subse-
qüentes podem ser executadas novamente 
para corrigir os problemas.
6.3.4 MODELOS INCREMENTAIS
Nos casos onde é possível utilizar o modeloseqüencial em função do 
tamanho do sistema e/ou quando é preciso disponibilizar uma versão 
de forma mais rápida para o cliente, indica-se o modelo incremental 
[15].
Ciclo de vida
67
No modelo incremental o sistema é dividido em módulos ou 
subsistemas, cujas versões são definidas, inicialmente com um 
pequeno subsistema funcional, que a cada ciclo insere novas 
funções [15].
O princípio do modelo é que, a cada iteração, é liberada uma 
versão operacional do sistema para o cliente utilizar e validar 
[15].
Destacam-se como as principais vantagens do modelo incre-
mental [15]:
•	 Economia no tempo e custo para se entregar a primeira 
versão;
•	 Redução dos riscos no desenvolvimento de cada itera-
ção em função do tamanho;
•	 O número de mudanças nos requisitos pode diminuir 
devido ao curto tempo de desenvolvimento de um in-
cremento.
Com relação as desvantagens [15]: 
•	 Quando os requisitos são instáveis ou incompletos, al-
guns incrementos podem ter de ser muito alterados;
•	 A gerência do projeto é complexa;
6.3.5 RUP (Rational Unified Process)
“O RUP é um framework de processo de desenvolvimento de 
software que fornece uma abordagem disciplinada para asso-
ciar tarefas e responsabilidades dentro de uma organização de 
desenvolvimento” [16]. Ele foi criado pela Rational e hoje é um 
produto da IBM.
O RUP foi um projeto criado para suportar a implementação 
de melhores práticas que adotam o ciclo de vida iterativo incre-
mental.
Análise de Sistemas
68
Os princípios do RUP são [16]:
•	 Tratar os riscos desde o começo e continuamente;
•	 Garantir que algo de valor vai ser entregue ao cliente;
•	 É focado no executável do software;
•	 Tratar das mudanças desde o começo do projeto;
•	 Definir uma linha de base da arquitetura desde o começo do 
projeto;
•	 Trabalhar em equipe;
•	 Qualidade é inerente a tudo;
As 6 melhores práticas [16]:
•	 Desenvolvimento realizado de modo iterativo;
•	 Gerenciar requisitos;
•	 Utilizar arquitetura de componentes;
•	 Modelagem visual (utilizando UML);
•	 Verificar a qualidade continuamente;
•	 Gerenciar configuração e mudanças.
A Figura 27 ilustra o modelo iterativo.
 
Figura 27. Modelo Iterativo: Tempo e Conteúdo
Fonte: [16]
No modelo iterativo uma iteração é uma sequência distinta com dura-
ção fixa de atividades, cujo resultado é uma release do produto exe-
cutável.
Onde um release refere-se ao software que já foi testado e ele é basea-
do em um build (ou em vários deles). Já um build refere-se ao software 
Ciclo de vida
69
que ainda está em teste, ele é gerado com maior frequência que 
o release. A Figura 28 ilustra o ciclo de vida iterativo.
 
Figura 28. Ciclo de Vida Iterativo
Fonte: [16]
As fases fornecem marcos bem definidos, cujos objetivos de 
cada fase são atingidos com a execução de uma ou mais itera-
ções dentro de cada fase.
•	 Fase de Concepção - o foco está voltado no conceito, vi-
são, identificação dos riscos, orçamento e requisitos, bem 
como, o objetivo do projeto de software precisa ser definido. 
•	 Fase de Elaboração - o foco está em prover a arquitetura 
do software.
•	 Fase de Construção - o foco está voltado na construção 
do software.
•	 Fase de Transição - o foco está na implementação e na 
liberação do produto final [16].
Exemplos de objetivos e critérios da Fase de Concepção [16]:
Objetivos Primários Critério de Avaliação do Marco
Estabelecer o escopo do projeto Os stakeholders concordam 
sobre o escopo
Estabelecer os critérios de aceita-
ção do projeto
Os stakeholders concordam 
sobre os critérios
Identificar as funcionalidades do 
sistema e selecionar aquelas que 
são críticas
Os stakeholders concordam com 
os requisitos elicitados e que 
há um entendimento sobre os 
mesmos
Análise de Sistemas
70
Estimar o custo e cronograma 
total do projeto
Os stakeholders concordam que 
as estimativas de custo/cronogra-
ma, prioridades, riscos e proces-
so são apropriadas.
Estimar riscos em potencial Todos os riscos foram registrados 
e avaliados e uma estratégia de 
mitigação foi definida
Configurar o ambiente de supor-
te para o projeto
O ambiente de suporte está 
pronto.
Tabela 8. Fonte: Adaptado de [16]
Exemplos de objetivos e critérios da Fase de Elaboração [16]:
Objetivos Primários Critério de Avaliação do Marco
Garantir que a arquitetura, requisi-
tos e planos são estáveis; estabele-
cer uma arquitetura controlada por 
baselines
A visão do produto, requisitos e 
arquitetura são estáveis.
Assegurar que os riscos são mitiga-
dos de forma eficiente para atender 
o custo/cronograma
Os riscos mais significantes foram 
destinados e estão sendo resolvidos 
de uma forma adequada
Demonstram que a arquitetura 
suportará os requisitos do sistema 
dentro do custo/ cronograma
Todos os aspectos de arquitetura 
do sistema e algumas funções estão 
sendo avaliadas em um protótipo.
Tabela 9. Fonte: Adaptado de [16]
Exemplos de objetivos e critérios da Fase de Construção [16]:
Objetivos Primários Critério de Avaliação do Marco
Alcançar versões úteis O sistema foi desenvolvido confor-
me as expectativas especificadas
Completar a análise, design, imple-
mentação e teste de toda a funcio-
nalidade requerida
Toda funcionalidade requerida foi 
incorporada no sistema.
Certificar que o sistema está pronto 
para ser posto no ambiente do 
cliente.
O sistema atendeu todos os critérios 
de aceitação quando testado no 
ambiente do cliente.
Tabela 10. Fonte: Adaptado de [16]
Ciclo de vida
71
Exemplos de objetivos e critérios da Fase de Transição [16]:
Objetivos Primários Critério de Avaliação do Marco
Repassar o sistema para os ca-
nais adequados de liberação 
O sistema passou nos critérios 
formais de aceitação no ambien-
te do usuário final
Tabela 11. Fonte: Adaptado de [16]
A figura abaixo representa o percentual de tempo gasto por fase. 
nota-se que a fase de construção consome mais tempo.
 
Figura 30. Distribuição do Tempo
6.3.6 MODELO EVOLUTIVO
Há alguns sistemas em que é difícil estabelecer os seus requisi-
tos, dada complexidade do mesmo, assim como estes requisitos 
são bastante instáveis. Dentro deste contexto é importante haver 
ciclos de vida que atendam este perfil de sistema, no entanto, de 
um modo geral, nem todo modelo incremental pode ser aplica-
do neste tipo de cenário. Para tal existem os modelos evolucio-
nários ou evolutivos que buscam preencher esse espaço [16].
Análise de Sistemas
72
6.3.7 MODELO ESPIRAL
O modelo espiral, apresentado na Figura 31, é um dos modelos evolu-
tivos mais difundidos [15].
Figura 31. Modelo Espiral
Fonte: [15]
Principais aspectos deste modelo [16]:
•	 Melhorias do modelo em cascata;
•	 Ele permite o envolvimento com o usuário;
•	 É iterativo com releases incrementais e extremamente focado 
na análise de riscos;
•	 Sua adoção não é trivial e envolve elevados custos;
•	 Pode não convergir para uma solução; e
•	 Não é muito utilizado.
Atividades de aprendizagem
Selecione a opção que representa a sequência correta das fases do 
ciclo de vida iterativo e incremental:
( ) Concepção, Elaboração, Construção, Transição
( ) Transição, Concepção, Elaboração, Construção
( ) Concepção, Transição, Construção, Elaboração 
( ) Transição, Concepção, Elaboração, Construção
REFERÊNCIA BIBLIOGRÁFICA
 [1] http://www.csgnet.org/informatica/conteudo.aspx?id_area=1&id_tema=13
Apostila: Introdução à Análise de Sistemas (2003)
 
[2]http://www.lcs.poli.usp.br/~jra/PROMINP/disciplina_OO_pdf/aula_I_Historia_
Abordagens_EstxOO.pdf
[3] Nascimento, Luciano Prado Reis. O usuário e o Desenvolvimento de Siste-
mas, Visual Books, Florianópolis, 2003.
[5] Falbo, Ricardo de Almeida. Análise de Sistemas Notas de Aula, UFPES, 2002. 
Disponível