Análise de Sistemas Jaime Wojciechowski

Prévia do material em texto

A
N
Á
LISE D
E SISTEM
A
S
JAIME WOJCIECHOWSKI
Código Logístico
59856
Fundação Biblioteca Nacional
ISBN 978-65-582-1013-9
9 7 8 6 5 5 8 2 1 0 1 3 9
Análise de Sistemas 
Jaime Wojciechowski
IESDE BRASIL
2021
© 2021 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e 
do detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: Krasnopolski/Linas Sinkunas/Shutterstock
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
W828a
Wojciechowski, Jaime
Análise de sistemas / Jaime Wojciechowski. - 1. ed. - Curitiba [PR] : 
IESDE, 2021.
138 p. : il.
Inclui bibliografia
ISBN 978-65-5821-013-9
1. Análise de sistemas. 2. Métodos orientados a objetos (Computação). 
3. UML (Computação). I. Título.
21-69939 CDD: 005.117
CDU: 004.415.2
Jaime Wojciechowski Doutor em Informática Aplicada em Engenharia Florestal 
pela Universidade Federal do Paraná (UFPR). Mestre 
em Informática Aplicada em Inteligência Artificial pela 
Pontifícia Universidade Católica do Paraná (PUCPR). 
Graduado em Matemática (bacharelado e licenciatura) 
pela mesma instituição. Atua, desde 1994, como 
docente no ensino superior e ingressou na UFPR no 
ano de 2006, onde é professor titular das disciplinas 
de Análise e Projetos de Sistemas no curso superior de 
Tecnologia em Análise e Desenvolvimento de Sistemas; 
Modelagem Ágil de Software no curso de Especialização 
em Desenvolvimento Ágil de Software; Aprendizado 
de Máquina e Laboratório de Inteligência Artificial 
no curso de Especialização em Inteligência Artificial 
Aplicada; Sistemas Computacionais Aplicados no curso 
de Especialização em Manejo Florestal; e é vice-diretor 
do Setor de Educação Profissional e Tecnológica. Foi 
analista de sistemas em ambiente de desenvolvimento 
de grande porte (mainframe). Trabalhou na área de 
desenvolvimento e treinamento para a formação de 
novos programadores no Banco do Estado do Paraná 
(Banestado), no Itaú, no Santander Banespa e no HSBC 
Bank Brasil.
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
1 Introdução à análise de sistemas e Levantamento de Requisitos 9
1.1 Introdução à análise de sistemas 9
1.2 Levantamento de Requisitos 17
1.3 Análise Orientada a Objetos (UML) 29
1.4 Métodos Ágeis aplicados ao desenvolvimento de sistemas 34
2 Casos de Uso e Histórias de Usuário 41
2.1 Diagrama de Caso de Uso 41
2.2 Níveis do Diagrama de Caso de Uso 48
2.3 Prototipação de telas 53
2.4 Histórias de Usuário 56
3 Objetos e classes 67
3.1 Objetos e classes 67
3.2 Relacionamentos entre as classes 73
3.3 Diagrama de Classes 80
3.4 Diagrama de objetos 87
4 Diagrama de Sequência 91
4.1 Elementos do Diagrama de Sequência 91
4.2 Práticas do Diagrama de Sequência 100
4.3 Operadores do Diagrama de Sequência 112
5 Diagramas suplementares da UML 118
5.1 Diagrama de Transição de Estados 118
5.2 Diagrama de Atividades 125
5.3 Diagrama de Pacotes 130
 Gabarito 135
APRESENTAÇÃOVídeo
O desenvolvimento de software é uma das tarefas mais fascinantes e 
necessárias atualmente. Em todas as áreas do conhecimento, do trabalho 
e da produção, os softwares são imprescindíveis. Usamos algum tipo de 
software na maioria das nossas atividades diárias, no uso do celular, nos 
carros, nos estudos, no trabalho e no lazer, dentre muitas outras tarefas do 
dia a dia. É impossível gerenciar uma empresa sem o uso de softwares, e o 
funcionamento de quase todos os aspectos da vida diária é administrado 
por eles.
Esta obra busca não só apresentar as teorias de análise que fundamentam 
a construção de softwares e os procedimentos adotados nas empresas 
que os produzem, mas também mostrar as ferramentas que podem ser 
aplicadas para informatizar um determinado processo de negócio. Portanto, 
o livro tem um cunho essencialmente prático, em que você terá contato com 
o embasamento do conceito e, em seguida, será levado a realizar práticas 
com estudos de caso reais a fim de aplicar efetivamente a técnica, tal qual se 
aplicam nas empresas de desenvolvimento de software.
Serão abordados os primeiros aspectos da modelagem, desde o 
Levantamento dos Requisitos, passando pelo embasamento de Métodos 
Ágeis e partindo para a explicação detalhada dos principais diagramas da 
Análise Orientada a Objetos (UML).
Ao final do estudo, você contará com diversas ferramentas práticas de 
modelagem de sistemas e terá condições de, com base em um determinado 
problema, fazer toda a atividade de modelagem usando os diagramas da UML.
Bons estudos!
Introdução à análise de sistemas e Levantamento de Requisitos 9
1
Introdução à análise de sistemas 
e Levantamento de Requisitos
As atividades de análise de sistemas são de extrema importância no 
processo de desenvolvimento de um software. Muitas vezes as empresas 
negligenciam essas atividades por diversos motivos. É consenso que exis-
te uma grande expectativa (e pressão) por parte dos clientes em receber 
o produto final que solicitaram, ou seja, um software pronto, contemplan-
do todas as suas solicitações e, não raro, resolvendo todos os problemas 
de negócio.
Diferentemente de muitos produtos que exigem um processo com-
pleto e muito bem formalizado para se chegar ao produto final, um 
software, muitas vezes por uma visão equivocada da equipe de desen-
volvimento, aceita que algumas etapas do processo de desenvolvimento 
sejam suprimidas, e mesmo assim se chega a um software “funcionando”. 
A palavra foi colocada entre aspas para indicar que é muito questionável 
entregar um software, mesmo que “funcionando”, se etapas do processo 
forem suprimidas.
Neste capítulo serão apresentadas as bases das teorias de análise, seu 
histórico e a motivação para que as teorias evoluam. Também veremos 
o ciclo de desenvolvimento de um sistema, a visão das fases em que são 
aplicadas essas teorias e qual sua importância no processo como um 
todo. Finalmente teremos o primeiro contato com o que se chama de 
Métodos Ágeis, conjunto de práticas que vem revolucionando a indústria 
de desenvolvimento de software.
1.1 Introdução à análise de sistemas
Vídeo As atividades de análise fazem parte do ciclo de desenvolvimento de um sis-
tema e têm um papel de extrema importância na qualidade do produto final. Os 
prejuízos causados pela entrega de um software cujas etapas não foram seguidas 
da maneira correta são praticamente intangíveis. É muito difícil medir os efeitos 
negativos da falta de planejamento e de tarefas realizadas sem os devidos proce-
dimentos formais.
Como medir as perdas do negócio de uma empresa com um software que fre-
quentemente apresenta erros e muitas vezes apresenta resultados que não são 
10 Análise de Sistemas
aqueles esperados? Como medir as perdas de um software de difícil manutenção, 
seja para conserto de erros ou simplesmente para acomodar novas funcionalida-
des? O que é mais barato para uma empresa: a correção de um erro em uma hora 
ou em três dias? A demora na correção de um erro pode ocorrer devido à estrutura 
do software ter sido mal construída, aos programas terem sido codificados sem 
um padrão, sem uma estruturação dos módulos, sem planejamento nem análise, 
sem uma modelagem dos processos, ou seja, o que se diz na prática: “saíram pro-
gramando direto”.
Esse é um grande erro que as empresas cometem. Um software mal construído 
será carregado por anos (e talvez décadas), sempre commuito esforço (e dinheiro) 
para mantê-lo funcionando, sempre impactando negativamente a imagem da em-
presa e seus negócios.
Nosso objetivo na tarefa de desenvolver um sistema é fazer com que todas as 
etapas do desenvolvimento sejam realizadas de modo fluente, tranquilo e, princi-
palmente, com produtividade, baixo custo e qualidade.
1.1.1 Conceitos iniciais
Segundo Stair e Reynolds (2015), sistemas de informação são componentes 
que interagem entre si, coletando, manipulando e disseminando dados e informa-
ções, a fim de atingir um objetivo. Já Laudon e Laudon (2005) definem sistemas de 
informação como um conjunto de elementos inter-relacionados que coleta, proces-
sa, armazena e distribui informações com o intuito de apoiar a tomada de decisão, 
a coordenação e o controle de uma organização.
Já um software pode ser definido como um conjunto de instruções (programa de 
computador) que, ao ser executado por um computador, produz um determinado 
resultado desejado e adequado à finalidade para a qual foi construído (PRESSMAN; 
MAXIM, 2016). É o termo genérico usado para descrever programas executados em 
um computador que manipulam dados e produzem o resultado para o qual foram 
projetados. O termo computador pode se referir a notebook, celular, tablet, smart 
TV, console de videogame etc.
Portanto, os softwares correspondem à parte lógica do computador, consistin-
do em programas que controlam o trabalho do hardware (STAIR; REYNOLDS, 2015).
A Figura 1 caracteriza um software e representa os componentes de um sistema 
de informações (SI).
Como exemplos de software podemos citar um 
site da internet, um aplicativo de celular, um editor de 
textos, planilhas eletrônicas, o programa que controla 
uma smart TV, um navegador de páginas na internet, 
um jogo, um editor de áudio ou vídeo, um app de strea-
ming, um controlador de semáforos das ruas e muitos 
outros. Por suas áreas de atuação, podem ser sistemas 
de informação, softwares embarcados, aplicativos de 
celular, softwares científicos, aplicações web, softwa-
res de inteligência artificial, dentre outros.
Figura 1
Componentes de um SI
Dados de 
entrada
Processamento
Dados de saída
• Software
Fonte: Elaborada pelo autor.
Introdução à análise de sistemas e Levantamento de Requisitos 11
Sistemas de informação e software se confundem. Tratar um deles como sendo 
o outro não traz grandes problemas, pois o que realmente importa para os usuá-
rios é a sua utilização.
1.1.2 Histórico da análise de sistemas
Os computadores surgiram na década de 1950, porém, até o início dos anos 
1970, eram utilizados basicamente no meio científico e militar. Com a populariza-
ção do seu uso, principalmente em empresas, sistemas de informações começa-
ram a ser construídos com o objetivo de resolver ou informatizar os processos de 
negócio dessas empresas.
Inicialmente as linguagens de programação eram complexas, a produção de 
programas demandava muitas linhas de código e a forma de se passar instruções 
aos computadores era difícil e exigia muita habilidade dos programadores. Não era 
rara a produção de programas imensos, porém a maioria do corpo do programa 
se referia à maneira de se comunicar com a máquina, sendo que a resolução do 
problema do negócio propriamente dito tinha de ficar em segundo plano.
Com isso, os programadores se preocupavam muito com as questões técni-
cas dos computadores e não conseguiam focar aquilo que realmente importava, 
ou seja, resolver o problema do seu usuário. Por causa disso, muitos erros eram 
cometidos, tanto de interpretação do negócio como de resolução equivocada do 
problema. Também, nessa época, não existia nenhuma estruturação dos proces-
sos a serem programados e muito menos uma organização dos dados utilizados 
pelo sistema.
A Figura 2 exemplifica essa situação. No lado esquerdo da figura, na primeira 
coluna, temos um conjunto de programas do sistema e, no lado direito, na segunda 
coluna, um exemplo de um conjunto de dados totalmente desestruturado. Podemos 
imaginar a dificuldade de manipular esses dados sem nenhuma estruturação, bem 
como de manter atualizada a estrutura depois de inserções de novos dados.
Figura 2
Programas e dados desestruturados
Fonte: Elaborada pelo autor.
Dados
Dados x
. . .
. . .
Dados y
. . . 
. . . 
Dados z
Programa 1
Programa 2
Programa 3
Programa n
12 Análise de Sistemas
Para amenizar esse cenário, nos anos 1970 surgiram as teorias de análise. Tais teo-
rias tinham o objetivo de fazer com que os profissionais tivessem um tempo para ana-
lisar o problema e estruturar uma solução antes da efetiva codificação dos programas.
1.1.2.1 Análise Estruturada
A primeira teoria de análise que surgiu foi chamada de Análise Estruturada 
(YOURDON; CONSTANTINE, 1992). Basicamente a referida teoria procurou dar uma 
estrutura aos processos e introduziu o conceito de diagramas para demonstrar a 
solução do problema. Surgiram então os dois primeiros diagramas básicos da Aná-
lise, o Fluxograma e o Diagrama de Fluxo de Dados (DFD), que foram amplamente 
utilizados até meados dos anos 1980.
As Figuras 3 e 4 mostram um exemplo de Fluxograma e um DFD (no qual está re-
presentado o negócio de uma locadora de filmes, algo que não existe mais nos dias de 
hoje, porém o exemplo foi usado para refletir como a teoria é antiga e ultrapassada).
Figura 3
Exemplo de fluxograma
Fonte: Elaborada pelo autor.
Inserir cartão
Cliente informa a senha Sistema emite a mensagem 
“Senha inválida”
Cliente informa o valor Sistema libera o dinheiro
<<Válida>>
<<Inválida>>
Figura 4
Exemplo de DFD
Fonte: Elaborada pelo autor.
Admin. 
videolocadora
Manter clientes Locar fitas
Manter fitas Entidade externa
ClienteGerar relatórios
D1 Clientes D3 Mov. fitas
D2 Fitas
Comando
Dados fita
Dados fita
Dados fita
Dados fita
Dados fita
Doc. controle
Recibo
Relatórios
Solicitação
Dados cliente
Dados cliente
Dados Locação
Dados locaçãoDados Cliente
Carteira
Introdução à análise de sistemas e Levantamento de Requisitos 13
Porém, mesmo com a introdução dessa fase de análise no processo de desen-
volvimento do sistema, problemas e dificuldades continuavam acontecendo. A 
questão agora era a falta de estruturação dos dados que o sistema manipulava. 
Não existia uma forma definida e cada sistema organizava seus dados da maneira 
que imaginava ser a correta para a sua solução. Com isso, diversos problemas de 
manipulação dos dados ocorriam, sistemas diferentes não conseguiam se comuni-
car e o esforço para se trabalhar com esses dados era muito grande.
Surgiram então os Sistemas Gerenciadores de Banco de Dados (SGBD), am-
plamente utilizados até os dias de hoje. A proposta desses sistemas era armazenar 
e fornecer ferramentas de manipulação desses dados, fazendo com que os pro-
gramas somente fizessem solicitações aos SGBDs para consultar, atualizar, incluir 
e excluir seus dados. Porém, para a utilização desses sistemas, foi necessária a 
estruturação dos dados. Surgiram então as técnicas de organização dos dados em 
forma de tabelas, linhas e colunas e foram introduzidas técnicas de normalização e 
relacionamentos entre os dados. Com isso, surgiram os bancos de dados.
A Figura 5 mostra a estrutura da modelagem da Análise Estruturada.
Fonte: Elaborada pelo autor.
Admin.
videolocadora
Manter clientes Locar fitas
Manter fitas Entidade externa
ClienteGerar relatórios
D1 Clientes D3 Mov. fitas
D2 Fitas
Comando
Dados fita
Dados fita
Dados fita
Dados fita
Dados fita
Doc. Controle
Recibo
Relatórios
Solicitação
Dados cliente
Dados cliente
Dados locação
Dados LocaçãoDados cliente
Processos
Programa 1
Programa 2
Programa 3
Programas
Carteira
Figura 5
Análise estruturada Banco de dados
Aluno
cpf int PK
nome Text N
Matricula_numero int FK
Curso
codigo int PK
nome Text
Professor
cpf int PK
matricula int
nome text
Disciplina
codigo int PK
nome int
Curso_codigo int FK
Professor_cpf int FK
Matrícula
numero int PK
cpf_aluno int
codigo_disciplina int
Disciplina_codigoint FK
14 Análise de Sistemas
Entretanto, apesar do avanço que a Análise Estruturada trouxe, os problemas 
nos sistemas continuavam ocorrendo. Os processos estavam estruturados e os da-
dos organizados, porém a principal questão nesse modelo era que qualquer pro-
cesso tinha autorização para manipular qualquer dado do modelo. Mesmo que o 
processo não tivesse relação nenhuma com determinado dado, nada o impedia de 
acessá-lo. Isso causava muitos problemas de programadores inexperientes codifi-
carem programas que deveriam ter um objetivo, porém esses objetivos eram ne-
gligenciados, desse modo o programa começava a interferir em outros processos 
fora do seu escopo e, o mais grave, começava a manipular dados que não eram 
condizentes com o real objetivo daquele programa.
1.1.2.2 Análise Orientada a Objetos
Para amenizar essas questões, surgiu nos anos 1990 a Análise Orientada a Obje-
tos (RUMBAUGH et al., 1994). O princípio básico dessa teoria é o conceito de encap-
sulamento, segundo o qual determinados dados devem ser manipulados somente 
por suas operações num componente chamado Objeto. Assim, se identificamos um 
conjunto de dados relativos a um cliente de banco, por exemplo, devemos ter um 
conjunto de processos (ou operações ou funções) que será responsável por ma-
nipular esses dados. Em outras palavras, não existe a possibilidade de processos 
que tratam de financiamentos do banco manipularem diretamente os dados dos 
clientes. Isso é de grande importância, pois somente as operações relativas aos 
clientes conhecem as regras para se manipular seus dados e essas regras ficam 
concentradas nas operações desses dados.
Como mostra a Figura 6, esse encapsulamento de dados e operações está 
representado na forma de um círculo contendo os dados e um outro à sua vol-
ta contendo suas operações, dando a ideia de que os dados estão “protegidos” 
pelas operações, ou seja, suas operações são as únicas que têm permissão para 
manipulá-los.
É evidente que existe a possibilidade de outros processos necessitarem de da-
dos que não são de sua responsabilidade, porém, nesse caso, esse processo só 
consegue acessar o dado fazendo uma solicitação às suas operações (representado 
pelas setas na figura), e essa solicitação é chamada de mensagem entre os objetos. 
Essa união entre dados e operações será chamada de objeto.
Figura 6
Modelo de Objetos
Fonte: Elaborada pelo autor.
operações
dados
Objeto 1
operações
dados
Objeto 2
operações
dados
Objeto n
operações
dados
Objeto 3
Para conhecer melhor as 
teorias de análise mais 
antigas, leia a obra Análise 
Estruturada de Sistemas, 
que determinou as tendên-
cias do desenvolvimento 
de software na década de 
1970.
GANE, C.; SARSON, T. São Paulo: 
LTC, 1983.
Livro
Introdução à análise de sistemas e Levantamento de Requisitos 15
Como exemplo, suponha um sistema de vendas de produtos. Os objetos en-
volvidos nesse negócio poderiam ser: produtos, clientes, fornecedores e, princi-
palmente, a venda. A representação desse sistema orientado a objetos seria o que 
mostra a Figura 7.
Figura 7
Exemplo de modelo de objetos
Fonte: Elaborada pelo autor.
incluir
nome
CPF
Cliente
incluir
nome
CNPJ
Fornecedor
vender
numero
data
Venda
mostraTela
Campos da tela
TELA DE VENDAS
consultar
nome 
dimensoes
ProdutoBanco de dados
Vimos que a evolução das teorias de análise nos levou a modelos mais comple-
xos, porém os problemas passaram a ser mais controlados e a qualidade dos siste-
mas melhoraram, fazendo com que se chegasse a um padrão utilizado por todo o 
mercado de produção de sistemas.
Não só a teoria de Análise Orientada a Objetos se solidificou no mercado, mas 
uma grande área surgiu para dar as diretrizes para todo o processo complexo de 
desenvolvimento de um software e foi chamada de Engenharia de Software, sendo 
seus precursores nomes como Roger S. Pressman, Bruce R. Maxim (PRESSMAN; 
MAXIM, 2016) e Ian Sommerville (SOMMERVILLE, 2011).
1.1.3 Ciclo de desenvolvimento de um sistema
Para o completo desenvolvimento de um sistema, desde a necessidade de um 
cliente informatizar a solução de um determinado problema de negócio até a efe-
tiva utilização do sistema no ambiente real, existe um ciclo de desenvolvimento 
cobrindo diversas atividades. Muitas formas foram propostas para esses ciclos, que 
também foram evoluindo no decorrer dos anos, sempre com novos modelos capa-
zes de resolver os problemas dos modelos anteriores.
Independentemente do tipo de ciclo, quatro fases básicas no processo sempre 
são identificadas: Iniciação, Elaboração, Construção e Transição (KRUCHTEN, 2003). 
Essa nomenclatura pode ser diferente nas várias propostas existentes, mas pode-
mos focar esses termos para entendermos em qual dessas fases atua a análise de 
sistemas. As características de cada uma das fases são:
16 Análise de Sistemas
Como o nome já diz, é a fase em que se inicia a investigação acerca das 
necessidades do usuário, busca-se o entendimento do negócio e do proble-
ma a ser resolvido. São levantados os Requisitos (ou funcionalidades) que 
serão atendidos pelo sistema e é obtido um acordo (ou consenso) com as 
partes envolvidas (usuário e equipe de desenvolvimento).
Iniciação
Nessa fase é projetada uma solução que satisfaça os Requisitos. É feita a 
modelagem do sistema por meio de construção de documentos e diagramas 
que apresentem ao usuário uma ideia de como será o produto final. A equipe de 
analistas de sistemas toma como base os materiais produzidos na fase anterior. 
Elaboração
Nessa fase são codificados os programas e componentes de software que se 
transformarão no produto final, um software funcionando. A equipe de progra-
mação toma como base todo o material produzido na fase anterior para cons-
truir um software como foi especificado no projeto.
Construção
Com os componentes de software construídos, nessa fase é feito o plane-
jamento da entrega, os testes de software, bem como sua homologação pelo 
usuário e, finalmente, o software é liberado para o ambiente produtivo.
Transição
A Figura 8 mostra o detalhamento 
das atividades em cada uma das fases. 
Ela é comumente chamada de gráfico 
das baleias. Na coluna da esquerda, 
as disciplinas representam as ativida-
des que devem ser realizadas, na linha 
horizontal, aparecem as iterações. As 
“barrigas”, representadas horizontal-
mente, indicam a carga de trabalho de 
cada atividade em cada fase, quanto 
mais alta, maior a carga.
Atividades
Modelagem de Negócios
Requisitos
Análise e Design
Implementação
Teste 
Implementação
Gerenciamento de 
Configuração e Mudança
Gerenciamento de Projeto
Ambiente
Figura 8
Ciclo de Desenvolvimento
Fonte: Kruchten, 2003.
Introdução à análise de sistemas e Levantamento de Requisitos 17
Esse modelo foi amplamente utilizado pelas empresas durante anos. Suas 
desvantagens foram a formalização, o excesso de procedimentos e artefatos que 
eram construídos e, muitas vezes, não tinha utilidade por não agregar valor ao 
produto final.
Porém, a estrutura geral do modelo, como as fases e suas atividades, permane-
ceu nas metodologias mais modernas.
Existem outros ciclos de 
desenvolvimento mais antigos 
que não foram abordados por 
não serem mais utilizados. São 
exemplos: cascata, incremental e 
prototipação.
Curiosidade
1.2 Levantamento de Requisitos
Vídeo A fase de Iniciação do ciclo de desenvolvimento de um sistema começa com o 
Levantamento de Requisitos.
Essa tarefa é primordial para que o software seja desenvolvido da maneira 
correta e atenda totalmente às necessidades do cliente. Sua importância e sua 
abrangência são tão grandes que uma nova área foi criada, chamada Engenharia 
de Requisitos.
O uso sistemático de técnicas para obter, documentar e manter as informa-
ções para conseguir uma Lista de Requisitos que atendem aos objetivos do cliente 
no seu negócio é uma boa definição de Engenharia de Requisitos. Suas práticas e 
ferramentas facilitam a comunicação com o cliente a fim de identificar e entender 
suasnecessidades e obter um consenso para a solução que será entregue. Em suas 
principais práticas estão tarefas, técnicas, orientações, papéis e responsabilidades 
(VASQUEZ, 2016).
O profissional responsável por essas tarefas é o analista de requisitos (que tam-
bém pode ser o analista de sistemas). Ele realiza as atividades previstas na fase de 
Levantamento de Requisitos e no mapeamento dos processos de negócio. A docu-
mentação técnica de especificação de Requisitos de softwares fornece um vasto 
material aos analistas de sistemas para que possam trabalhar na fase de Elabora-
ção, fazendo a modelagem do sistema.
Levantar Requisitos significa entender o negócio e o problema do cliente, iden-
tificar suas necessidades de software, investigar quais são as suas expectativas 
em relação à solução informatizada que será adotada, em resumo, definir o que o 
software vai fazer.
Nesse quesito, o maior problema que pode ocorrer é a dificuldade de comuni-
cação entre o analista e o cliente.
Na fase de Levantamento de Requisitos, então, é definido o escopo do sistema 
para se ter claro a que o sistema vai atender (e também a que ele não vai atender) 
e, principalmente, são identificados os seus Requisitos.
1.2.1 Conceitos
O conceito principal nessa área é o de Requisito. Segundo Vasquez (2016, p. 18), 
“é uma condição ou capacidade do sistema, solicitada pelo usuário, para resolver um 
18 Análise de Sistemas
problema ou atingir um objetivo”. Na prática, os Requisitos são funções, objetivos, 
propriedades ou restrições que o sistema deve possuir para satisfazer usuários.
De modo geral, um Requisito é uma condição necessária para satisfazer um 
objetivo, é uma exigência, solicitação, desejo e necessidade. Para Vasquez (2016):
Um usuário necessita que o sistema resolva seu problema ou 
o ajude a alcançar seu objetivo.
Requisitos estão relacionados a necessidades
Um usuário deve possuir a condição dada pelo sistema para 
satisfazer um contrato, padrão, especificação ou outro documen-
to formalmente imposto.
Requisitos estão relacionados a propriedades
Uma representação documentada de uma condição ou capaci-
dade como nas duas primeiras definições.
Requisitos possuem uma especificação
Os Requisitos estão ligados ao atendimento do negócio do sistema. Por exem-
plo, uma das funções de um sistema de venda de jogos pela internet é ter uma ou 
mais telas capazes de realizar a venda de um determinado jogo. Esse é o objetivo 
principal do sistema. Portanto, vender jogos é um Requisito do sistema (provavel-
mente o principal).
1.2.2 Tipos de Requisitos
Na análise do problema para a elaboração da Lista de Requisitos, podemos 
identificar vários tipos. É importante conseguirmos separar os Requisitos nesses 
tipos com o objetivo de melhor atuarmos no seu detalhamento e implementação. 
Os tipos de Requisitos serão especificados a seguir.
1.2.2.1 Requisitos Funcionais
Descrevem o comportamento que o software deve ter em termos de serviços 
para o negócio do usuário. Têm como objetivo as necessidades do assunto de 
que trata o sistema do cliente.
Os Requisitos Funcionais se referem às funções relacionadas com o negócio do 
cliente, com as funções que atendam diretamente às suas necessidades. Definem 
o que o sistema fará para atender ao pedido do cliente. São os Requisitos mais im-
portantes. O quadro a seguir apresenta exemplos desse tipo de Requisito.
Introdução à análise de sistemas e Levantamento de Requisitos 19
Quadro 1
Exemplos de Requisitos Funcionais em diversos negócios
O sistema deve cadastrar médicos profissionais.
O sistema deve emitir um relatório de clientes.
O sistema deve passar um cliente da situação “em consulta” para “consultado” quando o cliente 
terminar de ser atendido (mudança de estado).
O cliente pode consultar seus dados no sistema.
Executar a baixa dos boletos de contas a receber.
Renovar contrato.
Emitir certificado de participação do aluno no curso.
Vender passagem aérea.
Fonte: Elaborado pelo autor.
Quando um Requisito Funcional estiver escrito em um nível macro, passando 
uma ideia ampla, ele é chamado de Requisito Funcional Agregador. Não é indicado 
trabalhar com esse tipo na fase de modelagem do sistema, pois invariavelmente 
ele terá de ser subdividido para sua implementação. Então, o mais indicado é fazer 
essa divisão na fase de Levantamento dos Requisitos. Exemplos: efetuar gestão dos 
cursos; gerenciar relacionamento com clientes etc.
De maneira contrária aos Requisitos Agregadores, um Requisito Funcional pode 
ser fragmentado em vários Requisitos chamados de Requisitos de Subfunção. Tam-
bém não é indicado relacionar somente os Requisitos de Subfunção, pois eles só 
têm a função de mostrar as partes de um Requisito.
Por exemplo: o Requisito Funcional Sacar dinheiro em um caixa eletrônico teria 
três subfunções:
1. validar senha;
2. verificar saldo;
3. debitar conta.
1.2.2.2 Requisitos não Funcionais
Representam limitações ou determinações impostas aos Requisitos Funcionais. 
Falam das condições do ambiente no qual o software será executado e como esse 
ambiente pode afetar ou restringir a perfeita realização dos Requisitos Funcionais. 
Descrevem como o sistema deve funcionar. Entre outros aspectos, falam sobre:
 • O ambiente – segurança, comunicação etc.
 • A organização – locais de operação, tipos de hardware etc.
 • A implementação – linguagem de programação, Banco de Dados e 
arquitetura.
 • A qualidade – tempo de resposta, facilidade de uso, eficiência e facilidade de 
manutenção.
20 Análise de Sistemas
O quadro a seguir apresenta exemplos desse tipo de Requisito.
Quadro 2
Exemplos de Requisitos não Funcionais
Requisito Descrição
RNF1 – Tempo de resposta on-line
Todas as solicitações on-line feitas no sistema devem ter a 
resposta num tempo inferior a 15 segundos.
RNF2 – Disponibilidade do sistema
O sistema deve estar disponível ao usuário 24 horas/dia per-
mitindo paradas de até 5 minutos nos dias úteis e 1 hora em 
dias não úteis.
RNF3 – Autenticação dos usuários
Todos os usuários devem ser autenticados ao ingressar no 
sistema e suas senhas devem estar criptografadas.
Fonte: Elaborado pelo autor.
A prioridade de tratamento deve ser para os Requisitos Funcionais. Os Requi-
sitos não Funcionais podem ser tratados em um momento secundário do projeto.
1.2.3 Elicitação de Requisitos
Elicitação de Requisitos é a ação de aplicar as técnicas para o Levantamento dos 
Requisitos (VASQUEZ, 2016). Existe um longo caminho desde os primeiros contatos 
com o cliente a fim de conhecer suas necessidades até chegar a uma Lista de Re-
quisitos. Reuniões, análise de documentos e planilhas existentes, conhecimento de 
sistemas legados, dentre outras, são atividades que devem ser realizadas para se 
chegar ao objetivo.
É importante saber aplicar as técnicas corretas para que todos os detalhes e pe-
culiaridades do sistema fiquem esclarecidos e não ocorram entendimentos confli-
tantes ou insuficientes que acarretem um sistema que não coincide com os anseios 
do cliente.
A seguir veremos algumas técnicas e como aplicá-las para levantar os Requisitos.
1.2.3.1 Entrevistas e reuniões
Uma entrevista ou reunião, no âmbito do Levantamento de Requisitos, consiste 
no processo de ouvir e registrar as necessidades e os desejos dos clientes. O obje-
tivo é deixar o cliente descrever seu problema, apontar possíveis soluções e, princi-
palmente, demonstrar o funcionamento e as regras do seu negócio. O analista de 
requisitos busca respostas sobre os Requisitos, problemas e desafios da área de ne-
gócios, então é muito importante que o escopo da entrevista ou reunião fique res-
trito ao seu objetivo e que nenhum detalhe deixe de ser tratado (VASQUEZ, 2016).
Primeiramente uma entrevista ou reunião deve ser guiada por uma pauta de 
perguntas muito bem elaboradas pelo analista de requisitos. Novas questões po-
dem ser inseridas no decorrer do encontro dependendo do caminho que o assunto 
percorra e, também, para um maior detalhamento das questões levantadas.Para o bom andamento do encontro, algumas atitudes devem ser evitadas:
Introdução à análise de sistemas e Levantamento de Requisitos 21
11
Julgar/criticar as informações emitidas pelo outro
O cliente deve se sentir à vontade para passar as informações sem que seja julgado sobre a assertividade dos 
procedimentos que realiza. A informatização do processo por meio do sistema visa justamente à criação de um novo 
processo por meio do sistema que atenda perfeitamente à sua vontade.
22
Completar frases ou cortar a fala
É comum o analista de requisitos ter um entendimento prévio sobre o negócio do usuário e ter a ansiedade de colocar 
a sua opinião acerca dos procedimentos que estão sendo descritos pelo cliente. Essa discussão é benéfica, porém 
nunca se deve perder de vista que é o cliente quem tem a última palavra e que é a sua vontade que deve ser atendida. 
Então, o analista deve se conter e não interromper ou substituir as falas do cliente com a intenção de que a conversa vá 
em alguma direção de seu interesse.
33
Ser arrogante ou deixar a impressão de que sabe mais do que o outro
Na mesma linha do tópico anterior, o analista deve ter uma postura humilde perante o cliente. Jamais usar termos ou 
ter uma postura que denote superioridade ou que diminua a figura do cliente. O cliente deve se sentir à vontade para 
expressar suas opiniões e ter a ciência de que está no controle da situação.
55
Dar a solução antes de ouvir o problema
Oficialmente é o cliente quem detém o conhecimento do assunto que está sendo levantado. Então, a solução do 
problema deve vir dele. Mesmo que o analista conheça o problema e possíveis soluções, deve se comportar como um 
colaborador e deixar com que o cliente faça sua explanação completa antes de opinar sobre a solução.
66
Falta de cortesia, pontualidade e simpatia ou visual inapropriado
Na mesma linha do tópico anterior, o analista deve ter uma postura humilde perante o cliente. Jamais usar termos ou 
ter uma postura que denote superioridade ou que diminua a figura do cliente. O cliente deve se sentir à vontade para 
expressar suas opiniões e ter a ciência de que está no controle da situação.
77
Local, hora ou duração inadequada
O local do encontro deve ser preparado, organizado, tranquilo e sem interrupções. Deve-se definir um horário para iniciar 
(e esse horário deve ser seguido, salvo atraso do cliente) e, principalmente, a duração deve ser respeitada (salvo também 
se o cliente deseja que seja estendida).
44
Corrigir, seja informação técnica ou gramática
As correções devem ser feitas no sentido de enriquecer a fala do cliente, não constrangê-lo. Se o analista entender que 
alguma informação técnica está incorreta, deve se colocar na postura de que não compreendeu direito a informação 
e necessita de mais esclarecimentos. Deve deixar que o cliente chegue à conclusão de que a informação não está 
totalmente esclarecida ou correta. Ao final da fala, pode-se até resumir, em outras palavras, a informação recebida para 
validar o entendimento entre as partes. Já os erros gramaticais e de natureza semelhante devem ser relevados e não 
devem ser corrigidos abertamente, salvo se comprometer o entendimento da informação e, mesmo assim, seguindo a 
estratégia já descrita.
22 Análise de Sistemas
88 Vocabulário impróprio
O vocabulário deve ser formal e apropriado para o assunto, evitando piadas e linguagem vulgar.
99
Demonstrar despreparo sobre o assunto
O analista precisa se preparar para a entrevista, deve estudar o assunto, ter as perguntas organizadas e ter um 
mecanismo simples e ágil para registrar as respostas.
Uma entrevista ou reunião pode ter questões abertas e/ou fechadas, dependen-
do da necessidade de entendimento do assunto:
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Essas questões têm a vantagem de deixar o 
cliente mais à vontade para discorrer sobre 
o assunto, permitem que o analista se 
adapte ou conheça o vocabulário do cliente 
e fornecem uma riqueza maior de detalhes.
Como desvantagens, podem permitir que 
o cliente explique detalhes desnecessários 
que não são do escopo do problema e 
fazer com que o foco seja desviado. Isso 
consumirá mais tempo e poderá dificultar a 
interpretação das respostas obtidas.
Questões abertas
Nesse tipo de questão, é possível investigar 
os detalhes, as opiniões e as preferências 
do cliente. Numa resposta textual, a 
tendência é que o cliente consiga explicar 
melhor o assunto. 
Essas questões têm um conjunto de 
respostas predefinidas. Ele serve para 
delimitar o assunto em questão e restringir 
aquilo que se tem interesse em descobrir. 
A criação dessas questões deve ser muito 
bem estudada e organizada. 
As vantagens dessas questões são que 
economizam tempo, pois requerem a 
escolha de uma opção delimitada por parte 
do cliente. Pode-se fazer uma interpretação 
mais simples das respostas e facilitam o 
controle do encontro por parte do analista.
Como desvantagens, as questões 
fechadas podem dar a sensação de 
restrição para o cliente e dar a conotação 
de que outras questões que ele acha 
importante não podem ser abordadas. 
Perde-se a riqueza de detalhes que muitas 
vezes são de grande importância.
Questões fechadas
Uma boa entrevista ou reunião deve então balancear questões abertas e fecha-
das, sempre com um estudo prévio de qual tipo será mais vantajoso e apropriado 
para cada tema que se deseja levantar.
As questões de uma entrevista ou reunião (abertas ou fechadas) podem ter as 
seguintes estruturas:
Nessa estrutura, inicia-se o encontro com questões fechadas e, dependendo das respostas, 
questões abertas podem ser inseridas para o detalhamento dessas respostas. É uma estrutura 
que permite o foco em subtópicos e facilita a organização do analista.
Pirâmide
Ao contrário da anterior, inicia-se o encontro com questões abertas, e as fechadas são 
inseridas para tentar organizar ou detalhar as respostas das questões abertas.
(Continua)
Funil
Introdução à análise de sistemas e Levantamento de Requisitos 23
É uma combinação das anteriores. Inicia-se com questões fechadas e, em seguida, são 
inseridas questões abertas, podendo-se voltar às fechadas. Essa estrutura é mais dinâmica, 
porém a tendência é que o encontro fique mais longo.
Diamante
Uma entrevista ou reunião deve ser muito bem preparada. Para isso, as seguin-
tes diretrizes devem ser seguidas:
 • Defina claramente o objetivo do encontro e de quais informações você precisa.
 • Identifique as pessoas adequadas que podem participar.
 • Descubra quem é o dono do processo.
 • Avalie conversar com pessoas em vários níveis organizacionais que serão afe-
tados pelo projeto.
 • Estude bem o assunto, analise a documentação, converse com pessoas que 
conhecem o assunto.
 • Familiarize-se com o vocabulário da área de negócio.
 • Comunique claramente os participantes para que eles também se prepara-
rem para o encontro.
 • Use a técnica conhecida como 5W+2H no preparo das questões:
 • What - o que será feito?
 • Why - por que será feito?
 • Where - onde será feito?
 • When - quando será feito?
 • Who - quem fará?
 • How - como será feito?
 • How much - quanto custará?
A técnica de Elicitação de Requisitos, conhecida como entrevista ou reunião, é 
uma das técnicas mais utilizadas na tarefa de Levantamento de Requisitos e am-
plamente difundida na área de desenvolvimento de software. A imensa maioria 
dos sistemas desenvolvidos têm no seu início de desenvolvimento um conjunto de 
entrevistas e reuniões.
1.2.3.2 Análise de documentos
É uma forma de elicitar Requisitos pelo estudo da documentação disponível so-
bre uma solução existente, com o objetivo de identificarinformações relevantes 
para o desenvolvimento de uma nova solução.
A análise de documentos é parte fundamental da Elicitação de Requisitos. Nem 
sempre as partes envolvidas estarão disponíveis ou cooperarão com o projeto, en-
tão o analista de requisitos deve focar a documentação sobre o negócio que está 
disponível na corporação.
Essa análise permite obter conteúdo sobre o contexto abordado ou aumentar o 
nível de domínio sobre o problema, além de possíveis soluções a serem adotadas. 
24 Análise de Sistemas
Sempre há algo documentado previamente que deverá ser analisado para depois 
partir para outras técnicas de elicitação.
Os documentos podem trazer informações sobre o domínio do problema, ne-
cessidades do negócio (oportunidades, problemas e objetivos), partes interessadas 
e impactadas.
São exemplos de documentos a serem analisados:
 • planos de negócio, marketing e contratos;
 • pedidos de proposta e fluxos de processos atuais;
 • modelos de dados lógicos e regras de negócio;
 • guias, websites e manuais;
 • relatórios, manuais, memorandos e documentação de software.
1.2.3.3 Conhecimento dos sistemas legados
Um sistema legado é aquele que o cliente já utiliza para resolver o problema 
relacionado ao assunto e que deseja substituir pelo novo sistema. É possível e 
aconselhável levantar as informações do negócio e, consequentemente, levantar e 
compreender os Requisitos conhecendo esse sistema já existente. Esse estudo tan-
to permite que se conheça o funcionamento do sistema como as regras do negócio, 
as dificuldades existentes (já que o cliente deseja que o sistema seja substituído) e 
as facilidades (que podem ser incorporadas no novo sistema).
É importante se envolver com a equipe de usuários do sistema legado, com a 
equipe de desenvolvimento que mantém o sistema funcionando e, se possível, 
ter acesso ao sistema no papel de usuário para testar todas as suas funcionalida-
des. Com isso, é possível ter uma boa noção daquilo que o sistema atende para 
propor uma abordagem mais moderna e funcional, cobrindo todas as necessida-
des do cliente com maior dinamismo e eficiência. Também é possível analisar os 
programas desse sistema e extrair dali as regras de negócio e o funcionamento 
do processo.
1.2.4 Especificação de Requisitos
Se a tarefa de Elicitação de Requisitos descobre as peças do quebra-cabeça, 
então a análise e Especificação de Requisitos procura montá-lo (VASQUEZ, 2016).
Durante a aplicação das técnicas para levantar quais são os Requisitos, na me-
dida do possível, o analista deve procurar escrever uma Lista de Requisitos. Esse é 
o objetivo final do trabalho de levantamento.
Porém, não é uma tarefa fácil. Normalmente o cliente tem sua forma própria de 
registrar as informações e processos e nem sempre de uma maneira estruturada. 
Para ilustrar, vejamos a situação colocada na Figura 9.
Introdução à análise de sistemas e Levantamento de Requisitos 25
Ve
ct
or
_V
isi
on
/S
hu
tte
rs
to
ck
O que o senhor espera 
desse sistema?
Eu tenho uma loja de peças. Gostaria que o meu PV 
fosse interligado com o meu estoque e eu pudesse 
a qualquer momento alterar valores dos FPs. Posso 
oferecer descontos a alguns tipos de clientes, mas 
preciso autorizar essa operação.
No fim do mês, quero um relatório dos produtos que 
mais venderam. Preciso também saber a estatística 
de vendas por forma de pagamento.
De tempos em tempos deve aparecer na tela do 
sistema uma promoção relâmpago que dê um brinde 
ao cliente.
Preciso que o sistema controle os pedidos também.
Figura 9
Diálogo entre usuário e analista
Fonte: Adaptado de Melo, 2011.
Podemos perceber nesse diálogo a dificuldade que existe em entender os ter-
mos usados pelo usuário, bem como a falta de informações em alguns pontos:
Quadro 3
Diálogo entre usuário e analista – dúvidas
O que é PV e FP?
Que tipos de clientes podem receber descontos?
Como seria feita a autorização de desconto e por quem?
Quais quantidades de produtos devem aparecer no relatório dos que mais venderam?
Quanto tempo significa “de tempos em tempos”?
Fonte: Adaptado de Melo, 2011.
O processo de Levantamento dos Requisitos envolve então muitas conversas, 
reuniões, entrevistas, estudo dos sistemas legados, entre outros, em um trabalho 
criterioso de Elicitação dos Requisitos, no qual o maior desafio é chegar a um con-
senso de entendimento daquilo que o usuário deseja e principalmente extrair as 
regras e o funcionamento do seu negócio.
Como exemplo, poderíamos ter o seguinte cenário na fase de Levantamento 
dos Requisitos, conforme mostra a Figura 10.
26 Análise de Sistemas
M
on
ke
y B
us
in
es
s 
Im
ag
es
/S
hu
tte
rs
to
ck
Fonte: Elaborada pelo autor.
Figura 10
Ilustração do processo de montagem da Lista de Requisitos
Blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli bli blá 
blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan blá blá 
blá Blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli bli 
blá blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan blá 
blá blá blá blá blá bli bli bli piripipi piripipi poropopó poropopó bli bli 
bli blá blá blá poropopó John Snow piripipi piripipi Dynaris Targeryan 
blá blá blá
Nessa figura, as pessoas sentadas em uma mesa conversando simbolizam uma 
reunião na qual o problema está sendo discutido e o cliente está repassando suas 
necessidades. A tabela em forma de planilha simboliza os sistemas legados que já 
existem e que devem ser substituídos. Após o trabalho de elicitação, o objetivo final 
é chegar a uma Lista de Requisitos.
Os Requisitos devem ser especificados segundo algumas regras, com o objetivo 
de colocá-los em uma estrutura que facilite sua modelagem e implementação nas 
fases seguintes do processo de desenvolvimento. As seguintes regras são sugeri-
das (VASQUEZ, 2016):
 • Expressar um e somente um Requisito por vez.
 • Evitar cláusulas condicionais complexas.
 • Usar uma terminologia clara e consistente.
 • Expressar Requisitos em uma sentença com verbo e em voz ativa.
 • Indicar claramente o que ou quem é responsável pela ação realizada pelo 
Requisito.
O exemplo a seguir, extraído de Vasquez (2016), mostra a forma errônea de 
se escrever um Requisito. A referida escrita expressa vários Requisitos em um só 
e inclui cláusulas condicionais, além de não incluir o verbo que caracteriza a ação 
principal realizada.
Quadro 4
Exemplo de Lista de Requisitos – forma equivocada de escrita
Requisito Descrição
R1 – 
Controle de portaria
Para realizar o controle de entrada e saída da portaria, deve ser realizado o 
cadastro do visitante com os seguintes atributos: nome, RG e foto. Caso a visita 
tenha sido liberada pelo condomínio, então podem ser registradas a data e a 
hora em que o visitante acessou a portaria. Ao sair do condomínio, devem ser 
registradas a data e a hora em que o visitante saiu, mas isso só deve ser permi-
tido para visitante com registro de entrada e sem registro de saída.
Fonte: Adaptado de Vasquez, 2016.
Introdução à análise de sistemas e Levantamento de Requisitos 27
Os mesmos Requisitos deveriam ser reestruturados conforme mostra o quadro 
a seguir.
Quadro 5
Exemplo de Lista de Requisitos – forma correta de escrita
Requisito Descrição
R1 – Manter cadastro do visitante
O porteiro realiza o cadastro do visitante com os seguintes 
atributos: nome, RG e foto.
R2 – Liberar acesso ao visitante
O porteiro cadastra a liberação do acesso selecionando um 
visitante já cadastrado e indica a data e hora de início da visita.
R3 – Registrar saída do visitante O porteiro registra a data e hora do fim da visita.
Fonte: Adaptado de Vasquez, 2016.
Por exemplo, considere o seguinte estudo de caso com as especificações de um 
determinado problema e, em seguida, qual seria a lista de todos os Requisitos que 
o sistema deve atender.
Suponha uma Escola de Natação que deseja informatizar o processo de controle dos alunos e 
suas aulas. A escola oferece aulas de natação e hidroginásticaem diversas turmas com dias e 
horários definidos. Os professores podem atuar em várias turmas e nas duas modalidades. O 
aluno, ao se matricular, deve poder escolher uma modalidade e qual turma deseja. No decorrer 
das aulas, os professores devem registrar a presença dos alunos.
É normal que o próprio cliente já faça suas solicitações na forma de Requisitos. É comum ouvir 
solicitações do tipo:
• Desejo ter um cadastro de todos os meus alunos.
• Preciso de um relatório com todas as mensalidades pagas no mês.
• Tenho de ter uma tela (palavras do cliente) para fazer a matrícula dos alunos.
• Quero que os professores controlem a frequência dos alunos nas aulas.
Para esse problema, teríamos os seguintes Requisitos:
Quadro 6
Lista de Requisitos da Escola de Natação
Requisito Descrição
R1 - Manter cadastro dos alunos
Permitir o cadastro completo dos alunos (pes-
quisar, incluir, alterar, excluir e consultar).
R2 - Manter cadastro dos professores
Permitir o cadastro completo dos professores 
(pesquisar, incluir, alterar, excluir e consultar).
R3 - Manter cadastro das turmas
Permitir o cadastro completo das turmas, sua 
modalidade (natação ou hidroginástica), seus 
dias/horários e qual professor responsável.
R4 – Matricular alunos Matricular os alunos nas turmas.
R5 - Registrar frequência
Registrar frequência no diário de classes de 
cada aula.
Fonte: Elaborado pelo autor.
Estudo de caso
Para cada Requisito, devemos entender quais são as regras de negócio que cada 
um deve seguir. Por exemplo, no R4 – Matricular alunos, pode ser que o dono da es-
cola coloque algumas restrições do tipo: “pessoas com mais de 80 anos só podem se 
matricular na modalidade hidroginástica”. Esse é um exemplo de regra de negócio.
As regras de negócio impõem restrições de negócio ao Requisito, impedindo 
que informações inconsistentes sejam registradas no sistema do ponto de vista do 
negócio. Alguns aspectos sobre as regras de negócio são:
28 Análise de Sistemas
As regras que dizem respeito aos Requisitos funcionais são leis que regem o ne-
gócio e são definidas pelo especialista do assunto.
Mostram como os Requisitos devem ser feitos.
Descrevem de modo complementar o funcionamento do Requisito.
Descrevem políticas corporativas, legislação pertinente, regulamenta-
ções governamentais, padrões de mercado. 
Não são ligadas à solução (de software), mas ao domínio do problema.
Existem independentemente do software e de o processo estar automatizado 
ou não. 
Não devem ser confundidas com Requisitos não Funcionais.
Alguns exemplos de regras de negócio são:
 • Somente alunos com mais de 75% de frequência podem ser aprovados na 
disciplina.
 • Somente clientes com mais de 18 anos podem abrir conta corrente.
 • Compras acima de R$ 500,00 podem ser parceladas.
 • Crianças de até 23 meses transportadas no colo do responsável não pagam 
passagem.
O Quadro 7 mostra algumas estruturas de regras de negócio com exemplos.
Quadro 7
Estruturas de regras de negócio
Tipo de estrutura Estrutura Exemplo
Regra para obrigar
“(Sujeito da frase) 
deve...”
Um pedido de empréstimo acima de R$ 1.000,00 
deve ter dois avalistas.
Regra para restringir
“(Sujeito da frase) pode 
... somente se...”
Um saque pode ser feito somente se a conta es-
tiver ativa e o saldo for suficiente.
Regra para proibir
“(Sujeito da frase) não 
pode...”
Um cliente não pode fazer um empréstimo se ti-
ver restritivos.
Fonte: Elaborado pelo autor.
Finalmente, o resultado final da fase de Levantamento de Requisitos deve ser 
uma Lista de Requisitos no formato do Quadro 8.
Introdução à análise de sistemas e Levantamento de Requisitos 29
Quadro 8
Lista de Requisitos da Escola de Natação completa
Requisito Descrição Regras de negócio
R1 - Manter cadastro dos 
alunos
Permitir o cadastro completo dos alu-
nos.
Permitir pesquisar, incluir, alterar e consultar.
Não permitir a exclusão de um aluno, somente 
marcar como inativo.
R2 - Manter cadastro dos 
professores
Permitir o cadastro completo dos pro-
fessores.
Permitir pesquisar, incluir, alterar, excluir e 
consultar.
R3 - Manter cadastro das 
turmas
Permitir o cadastro completo das 
turmas, sua modalidade (natação ou 
hidroginástica), seus dias/horários e 
qual professor responsável.
Não permitir o cadastro de duas turmas da mes-
ma modalidade no mesmo horário.
R4 – Matricular alunos Matricular os alunos nas turmas.
Pessoas com mais de 80 anos só podem se ma-
tricular na modalidade hidroginástica.
R5 - Registrar frequência
Registrar frequência no diário de clas-
ses de cada aula.
Fonte: Elaborado pelo autor.
No ciclo de desenvolvimento do sistema, essa atividade corresponde à fase de 
Iniciação. A próxima fase, de Elaboração, consiste em informar como o sistema será 
modelado e como a solução será proposta e organizada. Os artefatos que serão 
construídos terão como base essa Lista de Requisitos.
1.3 Análise Orientada a Objetos (UML)
Vídeo No ciclo de desenvolvimento, a fase de Elaboração é a responsá-
vel pelo projeto de solução do sistema. Nela são produzidos artefatos 
(documentos e diagramas) que irão balizar a construção do software.
É nessa fase que são aplicadas as técnicas de análise vistas ante-
riormente. Inicialmente figurava a Análise Estruturada, em seguida a 
Análise Estruturada Moderna (ou Análise Essencial) e, atualmente, o 
padrão de mercado é a Análise Orientada a Objetos (UML).
1.3.1 Conceitos
O termo Unified Modeling Language ou linguagem de modelagem 
unificada (UML) surgiu da necessidade de se padronizar a linguagem 
de modelagem da Análise Orientada a Objetos e possibilitou a uni-
ficação da escrita dos diversos diagramas previstos na técnica. Com 
o tempo, esse termo passou a ser quase um sinônimo da Análise 
Orientada a Objetos (BOOCH; RUMBAUGH; JACOBSON, 2012).
A versão inicial da UML foi apresentada em 1996 por Grady Booch, 
James Rumbaugh e Ivar Jacobson como consequência da junção das 
melhores características de cada um dos métodos de representação 
do processo de software que cada um desses autores desenvolveu.
A UML tornou-se então a linguagem padrão de modelagem adota-
da pelas empresas de desenvolvimento de software (GUEDES, 2018).
30 Análise de Sistemas
O conceito básico nessa teoria é o de Objeto, no qual os componentes de software 
foram considerados como objetos (do mundo real) com suas características e funções.
Um dos grandes problemas das teorias anteriores era a grande interferência 
que um determinado componente (programa ou dado) poderia ter sobre outro, 
ou seja, não havia nenhuma restrição que um determinado programa manipulas-
se dados ou interagisse com programas que não estavam relacionados com sua 
função, que não eram de sua responsabilidade. Com isso, era comum ocorrerem 
muitos erros de programadores que, de maneira inadvertida, alteravam funções 
ou dados, os quais acabavam impactando erros em partes do sistema que diziam 
respeito a outro assunto.
Um Objeto tem encapsulado seus dados e operações responsáveis por mani-
pular esses dados. Uma operação de um determinado Objeto não tem autorização 
(ou acesso) para manipular dados de outro Objeto se não pela solicitação ao Objeto 
responsável por esse dado. Com isso, os acessos não autorizados ficavam inviabili-
zados e, em tese, cada Objeto cuidava somente de suas funções.
Podemos exemplificar esse mecanismo de encapsulamento de um Objeto na 
Figura 11.
Figura 11
Encapsulamento de um Objeto
Fonte: Elaborada pelo autor.
incluir
nome
CPF
Cliente
vender
alterarDados
pedido 
data
Venda
Nesse exemplo, digamos que é necessária uma alteração no atributo data que 
se encontra no objeto venda. A única operação que tem autorização (e conhece as 
regras de negócio para esse procedimento) é a operação alterarDados desse Objeto. 
Seria impossível a operação incluir do Objeto cliente fazer uma alteração nesse atri-
buto data. Caso o Objeto cliente realmente necessite dessa alteração, a única forma 
possível seria fazer uma solicitação à operação alterarDados do Objetovenda.
Com esse mecanismo, evita-se o acesso descontrolado aos dados do sistema, 
impõe-se um conjunto de regras que somente os responsáveis pelos dados conhe-
cem e aplicam. Assim, o sistema tem maior integridade dos seus dados.
1.3.2 Artefatos da UML
Para a modelagem do sistema e representação da solução informatizada, a UML 
dispõe de diversos diagramas. Dentre os principais, pode-se citar os apresentados 
na sequência.
1.3.2.1 Digrama de caso de uso
Apresenta graficamente todos os Requisitos do sistema, bem como a interação 
com as entidades externas. A Figura 12 apresenta um exemplo desse diagrama.
Na tese de doutorado do autor 
deste livro, foi desenvolvido um 
software totalmente orientado a 
Objetos, o JCarbon, cujo objetivo 
é estimar o carbono em florestas 
usando técnicas de inteligência 
artificial. O software pode ser 
acessado em: www.jcarbon.ufpr.
br. Acesso em: 17 mar. 2021.
Curiosidade
http://www.jcarbon.ufpr.br
http://www.jcarbon.ufpr.br
Introdução à análise de sistemas e Levantamento de Requisitos 31
Figura 12
Exemplo de Diagrama de Caso de Uso de uma Escola de Natação
Fonte: Elaborada pelo autor.
Manter 
modalidade
Pesquisar 
modalidade
Pesquisar 
turma
Registrar 
presença do 
aluno
Pesquisar 
professor
Manter 
turma
Manter aluno
Pesquisar 
aluno
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
<<extend>>
Ator atendente
Ator professor
<<extend>>
Manter 
professor
Matricular 
aluno
1.3.2.2 Diagrama de Classes
É utilizado para modelar as classes de objetos, seus atributos, suas operações e 
relacionamento com outras classes. Ele fornece uma visão estrutural do sistema. A 
Figura 13 mostra um exemplo desse diagrama.
- cpf : int
- nome : String
Pessoa


Aluno
Matricula Turma
Diario
- dataAdmissao : Date 
Professor
- descricao : int
- data : Date - descricao : String
- data : int
Modalidade
Figura 13
 Exemplo de Diagrama de Classes de uma Escola de Natação 
Fonte: Elaborada pelo autor.
* *
*
*
32 Análise de Sistemas
1.3.2.3 Diagrama de Sequência
Determina a sequência de mensagens que devem ser trocadas entre os objetos 
do sistema para que um caso de uso realize completamente sua função. A Figura 
14 mostra um exemplo desse diagrama.
 
Figura 14
Exemplo de Diagrama de Sequência do Caso de Uso de realizar matrícula de uma Escola de Natação
: Matricula: Aluno: Turma: ModalidadeTela
sd DS – Realizar Matrícula – Resolvido
: Ator Atendente 
1 : Entrada ()
1.1 : buscar ()
1.1.1 : buscar ()
2.1 : buscar ()
3.1 : buscar ()
4.1 : salvar ()
2 : CPF ()
3 : Modalidade ()
4 : Efetivar ()
Fonte: Elaborada pelo autor.
1.3.2.4 Diagrama de Atividades
Permite demonstrar os fluxos de um processo. Pode ser usado para mostrar 
vários tipos de processos: um simples algoritmo, um caso de uso, um conjunto de 
casos de uso ou para mapeamento de processos. A Figura 15 mostra um exemplo 
desse diagrama.
Introdução à análise de sistemas e Levantamento de Requisitos 33
Figura 15
Exemplo de Diagrama de Atividades da solicitação de um extrato bancário
Fonte: Elaborada pelo autor.
Solicitar 
conta
Verificar 
conta
Apresentar extrato
Solicitar 
período
Validar 
período
Apresentar 
mensagem 
Senha inválida
Apresentar 
mensagem 
Período inválido
Solicitar 
senha
<<Inválida>>
<<Senha inválida>> <<Período inválido>>
<<Senha válida>>
1.3.2.5 Diagrama de Transição de Estado
Permite demonstrar a mudança dos possíveis estados de um Objeto e as condi-
ções para que isso ocorra. A Figura 16 mostra um exemplo desse diagrama.
Figura 16
Exemplo de Diagrama de Transição de Estados da situação de uma bagagem em um aeroporto
Fonte: Elaborada pelo autor.
Despachando Checando
Enviando para PF
Aguardando embarque
Transportando ao avião
Embarcando
Voando
DesembarcandoTransportando do aviãoEntrando na esteira
Transportando para 
Reclamações
Retirando
Aguardando retirada
Irregular
Passageiro não retirouPassageiro 
retirou
34 Análise de Sistemas
1.3.2.6 Diagrama de Pacotes
Permite a visualização dos pacotes de classes ou funções. A Figura 17 mostra 
um exemplo desse Diagrama com Pacotes de classes, e a Figura 18 mostra pacotes 
de funções.
Figura 17
Exemplo de Diagrama de Pacotes com Classes
Prova
Recurso
Prova Discursiva Prova Objetiva
Avaliação
Vagas
Cargo
Localidade
Fonte: Elaborada pelo autor.
Figura 18
Exemplo de Diagrama de Pacotes de Funções
Fonte: Elaborada pelo autor.
view controller
daomodel
A UML possui outros diagramas suplementares que não serão vistos aqui.
1.4 Métodos Ágeis aplicados ao 
desenvolvimento de sistemasVídeo
Os métodos de desenvolvimento ágil de software surgiram no início de 2000. 
Seu foco central era que os processos de produção de software deveriam se con-
centrar em indivíduos e interações sobre os processos e, principalmente, no produ-
to final, ou seja, no software funcionando (COHN, 2011).
O vídeo Google Systems 
Design Interview With An 
Ex-Googler (Entrevista de 
design de sistemas do 
Google com um ex-goo-
gler), publicado pelo 
canal Clément Mihailescu, 
mostra uma entrevista de 
um ex-analista da Google e 
explica, em termos gerais, 
como é o processo de 
desenvolvimento das fun-
cionalidades das aplicações 
Google usando Análise 
Orientada a Objetos.
Disponível em: https://www.youtube.
com/watch?v=q0KGYwNbf-0. Acesso 
em: 17 mar. 2021.
Vídeo
https://www.youtube.com/watch?v=q0KGYwNbf-0
https://www.youtube.com/watch?v=q0KGYwNbf-0
Introdução à análise de sistemas e Levantamento de Requisitos 35
1.4.1 Motivações para a criação dos Métodos Ágeis
A indústria de produção de software tornou-se extremamente burocrática e um 
grande esforço era dedicado à produção de documentos, diagramas e artefatos de 
modelagem que, em tese, deveriam ser úteis para melhorar a qualidade do produ-
to final.
Porém, nem sempre isso ocorria. O processo era engessado em normas e pa-
drões e as equipes eram obrigadas a segui-los. O resultado, quase sempre, era o 
atraso na entrega do sistema, um alto custo e a equipe insatisfeita com a metodo-
logia de trabalho.
Segundo Prikladnicki, Willi e Milani (2014, p. XIV), “a única constante no desen-
volvimento de software é a mudança, portanto criar mecanismos para adaptar-se a 
ela é mais eficaz do que tentar combatê-la”.
O mercado não aceitava mais o desperdício de tempo e dinheiro para produ-
zir artefatos que não tinham nenhuma utilidade. Como exemplo, imagine dezenas 
de documentos e diagramas escritos e desenhados com a proposta de solução 
e arquitetura do sistema, mas que, no momento de se fazer a programação dos 
componentes de software, nenhum era visto, nada do que foi escrito servia de base 
para a construção do software e todo o esforço gasto na sua produção era inútil.
No mínimo, esse modelo era muito custoso, pois horas tinham sido gastas na 
escrita de documentos que não seriam mais usados. Era como se o mais impor-
tante do processo fosse a produção de documentos, e não a produção efetiva do 
sistema (VALENTE, 2020).
Os Métodos Ágeis surgiram então com o objetivo de adotar práticas eficientes 
em todo o processo de desenvolvimento. Nesses métodos, só se produz aquilo que 
é útil e ajuda no desenvolvimento, os artefatos são construídos na medida exata da 
necessidade, sem perda de tempo e sem uso indevido de recursos.
Considerando que a prioridade é o cliente, os Métodos Ágeis surgiram também 
com o objetivo de enxugar o processo de desenvolvimento e dar mais agilidade às 
etapas, a fim de atender aos Requisitos.
Segundo Cohn (2011), os Métodos Ágeis se justificam por algumas razões:
 • maior produtividade e menores custos;
 • maior engajamento e satisfação no trabalho por parte da equipe de 
desenvolvimento;
 • atendimento rápido às demandas do mercado;
 • maior qualidade;
 • e, principalmente, maior satisfação do cliente.
1.4.2 Princípios e valores do Manifesto Ágil
Os Métodos Ágeis surgiram então como uma filosofia de trabalho, uma forma 
de se estruturar equipes, uma nova maneira de se realizar as atividades.Essa filo-
sofia foi materializada no que foi chamado de Manifesto Ágil (BECK et al., 2001), um 
Lean Inception – Como 
alinhar pessoas e construir 
o produto certo (que 
em tradução livre seria 
pensamento enxuto) traz 
excelentes reflexões sobre 
o uso de Métodos Ágeis 
no desenvolvimento de 
software com uma lingua-
gem simples e divertida.
CAROLI, P. São Paulo: Caroli, 2018.
Livro
36 Análise de Sistemas
documento que serviu de base para as organizações implantarem essa filosofia nas 
suas equipes de trabalho. Os quatro valores do Manifesto Ágil, assim como apare-
cem em Beck et al. (2001), são:
11
33
22
44
Indivíduos e interações mais 
importantes que processos e 
ferramentas.
Colaboração com o cliente mais 
que negociação de contrato.
Software funcionando mais que 
documentação abrangente.
Responder a mudanças mais que 
seguir um plano.
A seguir são apresentados os 12 princípios do Manifesto (BECK et al., 2001):
1. A maior prioridade é satisfazer o cliente por meio da entrega contínua e 
adiantada de software com valor agregado.
2. Mudanças nos Requisitos são bem-vindas, mesmo tardiamente no 
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando à 
vantagem competitiva para o cliente.
3. Software deve ser entregue funcionando frequentemente, de poucas 
semanas a poucos meses, com preferência com menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em 
conjunto durante todo o projeto.
5. Projetos devem ser construídos em torno de indivíduos motivados. Eles 
devem ter o ambiente e o suporte necessário e receber confiança para 
fazerem o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma 
equipe de desenvolvimento é a conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os 
patrocinadores, desenvolvedores e usuários devem ser capazes de manter 
um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e bom design aumentam a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é 
essencial.
11. As melhores arquiteturas, Requisitos e designs emergem de equipes 
auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, 
então, refina e ajusta seu comportamento.
Os valores e princípios desse Manifesto se aplicam a todas as etapas do desen-
volvimento de um software, desde a fase de Iniciação e Elaboração até as fases de 
construção e transição. Então, temos a tarefa de utilizar e construir os artefatos 
dessas fases seguindo esses princípios. Como o nome já diz, os Métodos Ágeis têm 
seu foco na agilidade de realizar as tarefas e isso significa que devemos otimizar 
Introdução à análise de sistemas e Levantamento de Requisitos 37
as atividades e construir os artefatos que necessariamente serão úteis, no nível de 
detalhamento que ajude os desenvolvedores nas fases seguintes.
Desse modo, a construção dos diagramas previstos na UML será ensinada mi-
nuciosamente, mas o detalhamento e a profundidade de sua utilização na prática 
devem ser avaliados. Não devemos esquecer que esses diagramas servirão de base 
aos programadores para a construção do software e alguns fatores devem ser leva-
dos em conta nessa avaliação:
A atribuição de tarefas para a equipe de programação deve levar em conta sua experiência. 
Se o conhecimento na tecnologia e no negócio do sistema é baixo, deve-se detalhar melhor os 
artefatos da UML. Caso contrário, pode-se pular algumas etapas, suprimir alguns artefatos ou 
escrevê-los de modo mais geral e sem muitos detalhes.
Experiência da equipe
Muitas vezes existe uma escassez de recursos, poucos profissionais à disposição e não existe 
a possibilidade de se realizar completamente as etapas. Nesse caso, a única alternativa é 
suprimir etapas.
Recursos
Muitas vezes a entrega tem data definida. Como o foco nos Métodos Ágeis é a entrega de 
um produto final, por vezes pode não existir tempo hábil para se realizar as tarefas de modo 
completo. Por conta disso, e com a ciência de toda a equipe e do cliente, pode-se suprimir 
etapas e diminuir o detalhamento.
Prazo
Todos esses aspectos devem ser medidos e avaliados no desenvolvimento 
e seguindo os princípios de agilidade e aplicação correta das técnicas. O “soft-
ware funcionando”, um dos principais valores do Manifesto, será entregue ao 
final do processo.
1.4.3 Introdução ao Scrum
Os Métodos Ágeis, personificados no Manifesto Ágil, trouxeram para a área de 
desenvolvimento de software uma nova filosofia de trabalho, uma nova aborda-
gem de como encarar os projetos, as equipes e, principalmente, o cliente. Porém, 
os profissionais em um determinado momento se perguntaram: e daí? O que eu 
faço agora? Gostei, mas como trabalho com isso? Concordo com todos os valores e 
princípios, mas na prática como aplico tudo isso?
Foi necessário então criar uma metodologia capaz de dotar as equipes com fer-
ramentas que transformassem uma filosofia de trabalho em algo palpável, que pu-
desse ser aplicado na prática e os resultados esperados fossem atingidos.
Nesse sentido, o Scrum é uma ferramenta (comumente chamada de framework) 
usada para implementar o desenvolvimento ágil (COHN, 2011). O conceito básico 
do Scrum é a Sprint (nome dado para os ciclos do projeto). Para entendermos esse 
conceito, temos de conhecer os termos incremental e iterativo.
Nas páginas 5 a 15 do livro 
Métodos ágeis para desen-
volvimento de software, você 
encontra, de maneira deta-
lhada, comentada e muito 
bem fundamentada, todos 
os valores e princípios do 
Manifesto Ágil, bem como 
quem são seus autores.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. 
Porto Alegre: Bookman, 2014.
Livro
38 Análise de Sistemas
O desenvolvimento de um software de maneira incremental envolve a constru-
ção “pedaço por pedaço”: primeiro uma parte é desenvolvida, depois a próxima 
parte e assim por diante. Por exemplo, um site de vendas de produtos incremental 
pode envolver primeiro o desenvolvimento do cadastro dos produtos, em seguida 
o cadastro dos clientes e, finalmente, a funcionalidade de venda dos produtos.
Por outro lado, o desenvolvimento iterativo aceita a possibilidade de retrabalho, 
de construir novamente aquilo que já foi feito, porém com um incremento de qua-
lidade nessa nova construção. Voltando ao exemplo do site de vendas de produtos, 
podemos primeiro desenvolver uma versão preliminar do site inteiro, com poucos 
detalhes, com as telas com pouca qualidade, com alguns recursos não informa-
tizados. O site é lançado para uso e recebe feedbacks do cliente e usuários; em 
seguida, passa-se para uma segunda versão, aprimorando a primeira e corrigindo 
as falhas.
Uma Sprint do Scrum, então, combina as melhores características das duas 
abordagens, incremental e iterativa. Com isso, o cliente recebe entregas rápidas do 
produto e vai contribuindo para a sua melhoria.
Os benefícios de se trabalhar com Sprints são:
 • O software funcionando encoraja o feedback do cliente.
 • O software funcionando ajuda a equipe a avaliar seu progresso.
 • O software funcionando permite que o produto seja entregue antes do 
desejado.
É consenso na área de desenvolvimento de software que uma Sprint não deve 
demorar mais do que duas semanas (apesar de se admitir Sprints de até 30 dias). 
Esse tempo é suficiente para se planejar um incremento no software e garantir que 
o cliente receba “novidades” em um curto espaço de tempo.
A Figura 19 ilustra a aplicação das Sprints no processo de entregas. O ciclo de 
14 dias representa uma Sprint, e o ciclo de 24 horas representa a avaliação diária 
do andamento da Sprint por parte da equipe de desenvolvimento.
Figura 19
Ciclo de entregas das Sprints
Fonte: Adaptada de De Paula, 2016.
SprintsRequisitos
14 dias
24 h
Incremento no 
software
Além do conceito de Sprint, o Scrum define algumas práticas para serem segui-
das (COHN,2011; SUTHERLAND, 2019):
 • Reuniões diárias, rápidas e objetivas de apenas 15 minutos com a equipe de 
desenvolvimento.
 • Mostrar o trabalho visualmente usando o quadro (conhecido como Kanban).
A equipe de desenvol-
vimento do Spotify é 
totalmente voltada aos 
Métodos Ágeis. Nela são 
aplicados praticamente to-
dos os valores e princípios 
do Manifesto Ágil. O vídeo 
Spotify Engineering Culture - 
Partes 1 e 2, produzido por 
eles, mostra a dinâmica da 
equipe de desenvolvimen-
to, bem como suas carac-
terísticas. A forma como 
trabalham é impressionan-
te, vale a pena conferir.
Disponível em: https://www.youtube.
com/watch?v=NoGhC1LaaAE. Acesso 
em: 17 mar. 2021.
Vídeo
https://www.youtube.com/watch?v=NoGhC1LaaAE
https://www.youtube.com/watch?v=NoGhC1LaaAE
Introdução à análise de sistemas e Levantamento de Requisitos 39
 • Ter equipes enxutas com até dez pessoas.
 • Nada de títulos de função: estudos demonstram que quando não são criados 
títulos para as pessoas que possam limitar o entendimento de seu papel den-
tro de uma equipe, elas trabalham melhor.
 • Priorização: quando várias coisas são prioridade, nada é uma prioridade. En-
tão, para que algo realmente seja feito, a metodologia Scrum propõe que as 
atividades devem ser priorizadas.
Essa foi uma breve introdução sobre o Scrum. Existem outros conceitos, papéis 
e práticas envolvidos que não serão trabalhados aqui.
CONSIDERAÇÕES FINAIS
Este capítulo trouxe um panorama geral das teorias de análise, como ocorreu 
sua evolução e por quais motivos. Com o objetivo de situar o leitor em qual ciclo as 
atividades se encaixam, mostrou como é o ciclo completo de desenvolvimento de 
um sistema.
Fizemos um detalhamento da primeira atividade da fase de Iniciação, cujo produto 
final, a Lista de Requisitos, será a base para a construção de todos os artefatos da UML.
Trouxemos, ainda, os aspectos gerais sobre a Análise Orientada a Objetos, os Mé-
todos Ágeis e o framework Scrum, que são os padrões da área de desenvolvimento de 
software na atualidade.
ATIVIDADES
1. A Análise Estruturada foi um avanço no processo de modelagem de um sistema, 
com a introdução de diagramas como Fluxograma, DFD e Modelo de Dados. Esses 
diagramas ajudavam o analista no entendimento e mapeamento da solução dos 
problemas de negócio. Porém, essa estrutura não evitava completamente os 
problemas nos softwares produzidos. Explique o principal problema dessa teoria 
no funcionamento dos softwares.
2. Explique qual é o propósito dos Diagramas de Caso de Uso, de Classes e de 
Sequência da UML.
3. Quais foram as motivações para que os Métodos Ágeis se tornassem padrão da 
indústria de desenvolvimento de software?
REFERÊNCIAS
BECK, K. et al. Manifesto for Agile Software development. 2001. Disponível em: http://www.agilemanifesto.
org/. Acesso em: 17 mar. 2021.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 12. ed. Rio de Janeiro: Elsevier, 2012.
COHN, M. Desenvolvimento de Software com Scrum. Porto Alegre: Bookman, 2011.
DE PAULA, G. B. Tudo sobre Metodologia Scrum: o que é e como essa ferramenta pode te ajudar a poupar 
tempo e gerir melhor seus projetos. Treasy, 14 fev. 2016. Disponível em: https://www.treasy.com.br/blog/
scrum/. Acesso em: 17 mar. 2021.
GUEDES, G. T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
KRUCHTEN, P. Introdução ao RUP - Rational Unified Process. Rio de Janeiro: Ciência Moderna, 2003.
LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informação. 3. ed. Rio de Janeiro: LTC, 2005.
MELO, A. C. Desenvolvendo aplicações com UML 2.2. Rio de Janeiro: Brasport, 2011.
http://www.agilemanifesto.org/
http://www.agilemanifesto.org/
https://www.treasy.com.br/blog/scrum/
https://www.treasy.com.br/blog/scrum/
40 Análise de Sistemas
PRESSMAN, R. S., MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: 
Bookman, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software. Porto Alegre: 
Bookman, 2014.
RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. São Paulo: Campus, 1994.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
STAIR, R. M.; REYNOLDS G. W. Princípios de Sistemas de Informações: uma abordagem gerencial. São Paulo: 
LTC, 2015.
SUTHERLAND, J. SCRUM: a arte de fazer o dobro do trabalho na metade do tempo. Rio de Janeiro: Sextante, 
2019.
VALENTE, M. T. Engenharia de software moderna. Princípios e práticas para desenvolvimento de software 
com produtividade. Leanpub, 2020. [e-book]
VAZQUEZ, C. E. Engenharia de Requisitos: software orientado ao negócio. São Paulo: Brasport, 2016.
YOURDON, E.; CONSTANTINE, L. L. Projeto estruturado de sistemas. São Paulo: Campus, 1992.
Casos de Uso e Histórias de Usuário 41
2
Casos de Uso e Histórias 
de Usuário
A fase de Elaboração, no ciclo de desenvolvimento de um sistema, 
corresponde ao momento de aplicação das teorias de análise de siste-
mas para que o ciclo seja modelado na forma de artefatos (documentos 
e diagramas) que demonstrem qual será a solução informatizada para o 
problema do cliente. Esses artefatos também irão delinear a arquitetura 
do software e como ele deve ser programado na fase de Construção.
Para a confecção desses artefatos, o analista de sistemas responsável 
por essa fase irá se basear em todas as informações coletadas na fase de 
Iniciação, por meio das atividades de Levantamento dos Requisitos.
Vimos que, na fase de Iniciação, o produto final foi uma Lista de 
Requisitos com especificações e regras de negócio. Neste capítulo, 
iremos construir os primeiros artefatos previstos na UML, o Diagrama 
de Caso de Uso, as Prototipações das telas (esboços) e a escrita das 
Histórias de Usuário.
Tais artefatos têm como objetivo dar uma visão funcional do sistema, 
detalhar seus processos e mostrar como será a solução informatizada em 
termos da organização dos seus Requisitos.
2.1 Diagrama de Caso de Uso
Vídeo O Diagrama de Caso de Uso tem como objetivo apresentar uma visão geral das 
funcionalidades do sistema, demostrando as entidades externas que terão acesso 
ao sistema e com quais funcionalidades cada entidade irá interagir (GUEDES, 2018; 
MELO, 2011).
Segundo Booch, Rumbaugh e Jacobson (2012, p. 263), “os diagramas de caso de 
uso são importantes para visualizar, especificar e documentar o comportamento 
de um sistema”.
Sua principal característica é a simplicidade em demonstrar graficamente tais 
funcionalidades, o que permite que seja compartilhado com o cliente para que se 
tenha uma visão do escopo do sistema e permita uma discussão em termos dos 
Requisitos que foram solicitados.
42 Análise de Sistemas
Por isso, esse diagrama pode e deve ser apresentado em reuniões com os clien-
tes, pois permite que sejam identificadas possíveis falhas na elaboração da Lista de 
Requisitos, percebidos Requisitos que não tenham sido identificados e, também, 
para deixar claro aquilo que o sistema não irá abordar (GUEDES, 2018).
2.1.1 Conceitos
Um Diagrama de Caso de Uso é composto de três elementos básicos: ator, caso 
de uso e relacionamento.
2.1.1.1 Ator
Os atores representam entidades externas ao sistema e que interagem com ele 
(DEBONI, 2003). Os atores fornecem e/ou recebem informações do sistema. Eles 
irão interagir com o sistema para satisfazer suas necessidades. Existem três tipos 
de atores:
São os atores mais fáceis de serem identificados. São as pessoas que irão 
manipular as telas, receber relatórios e fazer consultas aos dados.
Pessoas 
Em uma organização (empresa, indústria, loja, escritório, clube, dentre 
outros), um determinado órgão pode ser considerado um ator quando todas 
as pessoas desse órgão interagirem com o sistema. Por exemplo, em uma 
clínica médica, a Secretária, que atende aos pacientes que chegam para rea-
lizar consultas, exames e procedimentos, poderia ser considerada um ator 
perante o sistema de controle de consultas médicas da clínica. Note que, 
nesse exemplo, o paciente, os médicos