engSOFmod2__pos

Prévia do material em texto

S O F T W A R E
Engenharia de Software
E N G E N H A R I A
DE
Thiago Schaedler Uhlm
ann
Código Logístico
59009
Fundação Biblioteca Nacional
ISBN 978-85-387-6552-3
9 7 8 8 5 3 8 7 6 5 5 2 3
S O F T W A R E
E N G E N H A R I A
DE
THIAGO SCHAEDLER UHLMANN
Engenharia de Software
IESDE BRASIL
2020
Thiago Schaedler Uhlmann
© 2020 – 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.
Capa: IESDE BRASIL S/A. 
Imagem da capa: Andrey Suslov/mydegage/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
U31e
Uhlmann, Thiago Schaedler
Engenharia de software / Thiago Schaedler Uhlmann. - 1. ed. - 
Curitiba [PR] : IESDE, 2020. 
188 p. 
Inclui bibliografia
ISBN 978-85-387-6552-3
 1. Engenharia de software. 2. Software - Desenvolvimento. I. 
Título.
19-60521 CDD: 005.1
CDU: 004.41
Thiago Schaedler Uhlmann
Doutorando em Engenharia de Produção e Sistemas pela 
Pontifícia Universidade Católica do Paraná (PUCPR). Mestre 
em Design pela Universidade Federal do Paraná (UFPR). 
Bacharel em Administração pela FAE Centro Universitário. 
Atua profissionalmente como analista de processos ISO 
9001:2015 e como professor do ensino superior nas áreas 
de Gestão da Inovação, Governança de TI, Modelagem de 
Processos de Negócio e Gestão de Negócios. 
Sumário
Apresentação 7
1. Introdução à engenharia de software 9
1.1 Quem é o engenheiro de software 9
1.2 A prática da engenharia de software 13
1.3 O engenheiro de software e outros profissionais 17
2. Planejamento e processo de software 23
2.1 Estrutura básica do desenvolvimento de software 23
2.2 Modelos tradicionais de desenvolvimento 25
2.3 Modelos ágeis de desenvolvimento 33
3. Engenharia de requisitos 39
3.1 Métodos para a coleta de requisitos 40
3.2 Classificação de requisitos 48
3.3 Especificação e apresentação de requisitos 52
4. Modelagem de software com a UML 59
4.1 O que é a UML e por que utilizá-la? 60
4.2 Diagramas comportamentais 67
4.3 Diagramas estruturais 75
5. Gestão de projetos de software 83
5.1 Projeto de software: elementos básicos 83
5.2 Projeto de software: elementos acessórios 89
5.3 Projetos de arquiteturas de software 94
6. Gestão da qualidade em engenharia de software 103
6.1 Normas de qualidade 104
6.2 Qualidade em software 108
6.3 Melhorias em software 114
7. Testes e engenharia reversa em software 123
7.1 Modalidades de testes em software 124
7.2 Realização de testes 132
7.3 Manutenções e reengenharia 140
8. Práticas de engenharia de software 147
8.1 Design de interação 148
8.2 Jogos digitais 157
8.3 Projeto de WebApps e aplicativos móveis 167
Gabarito 175
Apresentação
As tecnologias da informação e comunicação estão 
cada vez mais presentes em nosso cotidiano. Utilizamos 
computadores, smartphones, tablets e outros dispositivos, 
que têm contribuído com grandes áreas, como nos avanços da 
medicina, ou com ações mais corriqueiras, como para pedir 
um lanche. 
Embora tenhamos familiaridade com esses dispositivos, 
muitas vezes, não nos atentamos sobre o quão complexo é 
elaborá-los, visto que somente funcionam se operados por 
softwares, os quais, para serem desenvolvidos, exigem do 
engenheiro a responsabilidade para gerenciar projetos e 
modelar, desenvolver e implantar softwares. 
Desse modo, a engenharia de software é uma área do 
conhecimento que tem sido cada vez mais procurada dentre 
as engenharias e as áreas relacionadas à TI. Isso se deve 
à crescente demanda do mercado em procurar softwares 
que, além de funcionarem adequadamente, sejam seguros, 
confiáveis, resistentes a ataques cibernéticos e que, portanto, 
não apresentem falhas, principalmente durante momentos 
críticos de sua utilização.
O objetivo principal desta obra é apresentar a você, 
estudante, um panorama geral da atuação profissional do 
engenheiro de software. Sendo assim, no primeiro capítulo, 
vamos iniciar com uma breve apresentação do que faz o 
engenheiro de software e sua atuação profissional em equipes 
multidisciplinares, ou seja, formadas por profissionais de 
diferentes áreas do conhecimento. 
Nos capítulos seguintes, trataremos de temas essenciais, 
como métodos de desenvolvimento de software, engenharia de 
requisitos, modelagem, gestão de projetos, testes e engenharia 
reversa. Por fim, apresentaremos algumas oportunidades de 
atuação do profissional de software, como no desenvolvimento 
de interfaces, jogos eletrônicos e aplicativos para dispositivos 
móveis. Dessa forma, por meio da leitura deste livro, você 
terá a oportunidade de conhecer essa área cada vez mais 
promissora.
Bons estudos!
1
Introdução à engenharia de software
Neste capítulo, você estudará o perfil do engenheiro de software 
e o mercado de atuação desse profissional, que é cada vez mais 
promissor.
Conhecerá a rotina de trabalho na engenharia de software, 
compreendendo as principais atividades realizadas e a relação desse 
engenheiro com as equipes de trabalho multidisciplinares, isto é, 
formadas por profissionais de diferentes áreas do conhecimento.
Você também aprenderá que, como os demais profissionais de 
engenharia, o engenheiro de software deve saber resolver problemas 
e maximizar o uso de recursos. Desse modo, serão abordados os 
processos básicos da engenharia de software, como engenharia de 
requisitos, planejamento, desenvolvimento, testes e manutenção.
Além disso, você compreenderá as diferentes maneiras de se 
organizar equipes, denominadas paradigmas.
1.1 Quem é o engenheiro de 
software
Você sabe o que exatamente faz um engenheiro 
de software?
Embora o nome guarde relações com a 
engenharia, pois, dentre as várias atribuições, 
também atua com projetos e com engenheiros, o engenheiro de 
software é um profissional da área de Tecnologia da Informação.
Vídeo
10 Engenharia de Software
Resumidamente, o engenheiro de software é o 
profissional responsável pelo desenvolvimento e 
pela implantação de produtos, serviços e sistemas de 
software, desde a ideia inicial até o produto final.
A definição de engenharia de software sofre pequenas variações 
de acordo com cada autor. Schach (2010, p. 4), por exemplo, 
define engenharia de software como “uma disciplina cujo objetivo 
é produzir software isento de falhas, entregue dentro do prazo e 
orçamento previstos, e que atenda às necessidades do cliente”.
De acordo com o IEEE (Institute of Electrical and Electronic 
Engineers) – entidade internacional que definiu as diretrizes 
dessa área – engenharia de software trata-se da “aplicação de 
uma abordagem sistemática, disciplinada e quantificável no 
desenvolvimento, na operação e na manutenção de software, isto 
é, a aplicação de engenharia ao software” (IEEE apud PRESSMAN; 
MAXIM, 2016).
Como você pode notar, desenvolver software requer disciplina 
e visão lógica e, ao mesmo tempo, sistêmica. Logo, assim que se 
gradua, um engenheiro de software deve ser capaz de coordenar 
projetos, administrar equipes de trabalho e, inclusive, gerenciar 
conflitos que podem surgir durante o processo de desenvolvimento.
Desse modo, o trabalho de um engenheiro de software se diferencia 
do trabalho de um desenvolvedor, ao passo que, conforme afirma 
Wazlawick (2013), o engenheiro de software consiste em um projetista, 
sendo o desenvolvedor de software um executor do processo.
Introdução à engenharia de software 11
O engenheiro de software deve, portanto, “fornecer aos 
desenvolvedores (inclusive gerentes, analistas e designers) as 
ferramentas e processos que deverão ser usados e será o responsável 
por verificar se esse uso está sendo feito efetivamente e de forma 
otimizada” (WAZLAWICK, 2013, p. 19).
Ainda segundo Wazlawick (2013), o surgimento da engenharia 
de software se deuem plena Guerra Fria, em que um grupo de 
estudos da OTAN (Organização do Tratado para o Atlântico Norte), 
em 1967, definiu que as atividades de software deveriam utilizar 
as mesmas filosofias e disciplinas de engenharia, uma vez que a 
qualidade do software desenvolvido, até então, era péssima.
Existem diferenças entre as áreas de engenharia de software, 
engenharia da computação e ciência da computação. O engenheiro 
de software atua em projeto, desenvolvimento e implantação de 
software; o engenheiro da computação se volta ao desenvolvimento 
de hardware, como computadores e equipamentos eletrônicos. 
O cientista da computação, por sua vez, desenvolve os modelos 
matemáticos, os algoritmos e as demais ferramentas teóricas que 
serão utilizados pelo engenheiro de software, o qual é, portanto, o 
elo de ligação entre os demais profissionais de TI.
Atualmente, o mercado encontra-se promissor para o engenheiro 
de software. Conforme dados da ABES (Associação Brasileira de 
Empresas de Software), o Brasil está em 1º lugar na América Latina 
em investimentos na área de software, e em 9º lugar mundialmente. 
Segundo a mesma entidade, hoje esse setor representa 1,9% do PIB 
nacional, sendo um mercado de US$18,6 bilhões.
12 Engenharia de Software
Figura 1 – O engenheiro de software é requisitado por organizações 
de diferentes áreas de atuação.
O engenheiro de software vem sendo requisitado em empresas 
de todos os portes, seja para atividades de desenvolvimento ou 
para gerenciamento de projetos. Além disso, esse profissional 
tem sido muito procurado para trabalhar em startups, ou seja, 
empresas de base tecnológica que atuam em ambientes de mercado 
de extrema incerteza, sendo necessário que o engenheiro domine 
outras habilidades, como trabalhar em equipes multidisciplinares 
e saber resolver problemas com o máximo de eficiência.
Um engenheiro de software deve saber que uma organização tem 
restrições financeiras, procedimentos a serem respeitados e perfis 
profissionais distintos. Logo, precisa considerar adequadamente 
essas situações em seu trabalho, bem como em seus projetos.
Esse profissional é o responsável pela gestão consciente 
de recursos humanos, de materiais financeiros e tecnológicos 
necessários para o desenvolvimento do software e de processos 
de desenvolvimento, desde a coleta de requisitos até a entrega do 
software em sua versão final.
Pr
ee
ch
ar
 B
ow
on
ki
tw
an
ch
ai
/S
hu
tt
er
st
oc
k
Introdução à engenharia de software 13
A atividade do engenheiro de software está sendo regulamentada 
pela Resolução n. 1.100 do CONFEA (Conselho Federal de 
Engenharia e Agronomia), a qual defende que esse profissional 
integra o grupo dos engenheiros eletricistas, tendo direitos e deveres 
de um engenheiro conforme a legislação em vigor (CONFEA, 2018).
Assim, é muito importante entendermos as competências 
necessárias para se tornar um engenheiro de software e a atuação 
desse profissional em equipes multidisciplinares.
Vamos estudar, na próxima seção, como é a prática profissional 
de um engenheiro de software.
1.2 A prática da engenharia de 
software
O engenheiro de software é um profissional 
de inovação e um projetista. Sendo assim, seus 
projetos resultam em produtos que resolvem 
problemas da sociedade para os quais, até aquele 
momento, ainda não havia uma solução mais eficaz ou mesmo 
existente.
A inovação em engenharia de software pode acontecer de 
diferentes formas: a primeira, mais frequente, é denominada 
inovação incremental ou melhoria contínua, em que há 
incrementação ou desenvolvimento de algo novo com base em 
uma solução existente; e a segunda, denominada inovação radical, 
consiste na criação de algo totalmente novo, do “zero”.
As aplicações da engenharia de software na sociedade são muito 
variadas, assim como os métodos utilizados para se desenvolver 
um software.
Desde a criação dos computadores, a forma de se desenvolver 
programas tem evoluído de modo acelerado, cabendo ao profissional 
Vídeo
14 Engenharia de Software
de engenharia de software manter-se constantemente atualizado a 
respeito dessas técnicas.
Dentre as aplicações, pode-se citar o desenvolvimento de 
aplicativos (locais e acessados pela internet), sistemas operacionais, 
sistemas para simulação, jogos eletrônicos, sistemas de banco de 
dados e sistemas para automação (robôs industriais, por exemplo).
Figura 2 – O engenheiro de software é um profissional de inovação e 
projetos.
O engenheiro de software, como todo engenheiro, é especialista 
em resolver problemas e fazer as coisas acontecerem. Por meio da 
aplicação de métodos, processos e controles, uma simples ideia pode 
se transformar em um produto de software altamente lucrativo e que 
resolverá muitos problemas da sociedade.
Desse modo, é preciso, primeiramente, considerar que o 
desenvolvimento de software é um processo composto de várias 
atividades consecutivas, sendo que para cada atividade existem 
métodos e ferramentas específicos, conforme apresentados a seguir.
• Engenharia de requisitos
Conforme o nome sugere, consiste na definição, com a 
participação do cliente ou usuário, do que o software necessita ter 
em termos de funcionalidade, requisitos de segurança, aparência das 
PI
YA
W
AT
 W
O
N
G
O
PA
SS
/S
hu
tt
er
st
oc
k
Introdução à engenharia de software 15
telas, botões, menus, compatibilidade com sistemas operacionais 
específicos, dentre outros.
Além disso, a engenharia de requisitos trata das restrições, 
ou seja, dos elementos de limitação que podem ser inseridos em 
um software para evitar operações indesejadas. Um software para 
automação industrial, por exemplo, deve prever a existência de um 
botão que, no caso de emergências e risco de acidentes, possa ser 
acionado fazendo com que todo o sistema pare.
Portanto, definir requisitos é essencial para que o software, uma 
vez desenvolvido, atenda às necessidades do usuário.
• Planejamento
Esta é a fase criativa do desenvolvimento de software. Envolve 
definir a sua arquitetura; criar esboços das telas; definir os 
diagramas básicos (diagramas de classes e atividades, por exemplo) 
e as linguagens de programação a serem utilizadas para cada 
funcionalidade do software.
Além disso, nessa fase pesquisa-se por soluções já existentes em 
software e que atendam, mesmo que de modo similar, os requisitos 
definidos no primeiro passo. Essas soluções podem ser aproveitadas 
no processo de construção do software (próxima etapa) para que a 
equipe de trabalho não gaste tempo desenvolvendo funcionalidades 
e arquiteturas que já existem e encontram-se disponíveis.
• Desenvolvimento ou codificação do software
Após ser planejado e esboçado, desenvolve-se o código-fonte do 
software e de suas partes.
Durante o processo de desenvolvimento, podem surgir incidentes 
ou problemas, forçando o projeto a ser modificado, ou erros podem 
passar despercebidos e somente aparecer quando o software estiver 
concluído.
16 Engenharia de Software
Recomenda-se, nessa fase, o uso de técnicas de desenvolvimento 
e a realização de testes em tempo real, pois, uma vez que o software 
estiver desenvolvido, modificações podem custar caro. 
• Fase de testes
Após desenvolvido e codificado, o software deve ser testado – 
atividade que deve ser repetida sempre que necessária. Isso se deve 
porque erros – mais conhecidos como bugs – podem custar caro, 
principalmente se o software já estiver em fase de lançamento.
A realização dos testes não precisa, necessariamente, ser feita 
pelo profissional responsável pelo desenvolvimento do software. 
Aliás, é recomendado que não seja, pois, profissionais externos têm 
uma visão diferente do software e tendem a encontrar erros não 
percebidos pelos programadores. Inclusive, existem profissionais de 
desenvolvimento de sistemas capacitados, especificamente, para a 
realização dessa tarefa.
• Manutenção e melhorias
Após o software ser desenvolvido e lançado, é necessária a 
realização de manutenção e melhoriascontínuas.
As necessidades do consumidor e as tecnologias encontram-se 
em constante mutação, sendo necessária a manutenção do software, 
que é realizada por meio de técnicas, como a do versionamento, 
em que diferentes versões são desenvolvidas com aprimoramentos, 
correções de falhas e novas funcionalidades.
Em muitos casos, o processo de desenvolvimento de um software 
não tem fim, pois sempre há alguma funcionalidade a incluir. Por 
esse motivo, softwares de versionamento têm sido cada vez mais 
utilizados por desenvolvedores para abrigar suas criações em 
contínuo estágio de desenvolvimento.
Além dos cinco métodos descritos, é importante ressaltar que, 
como em toda profissão, a prática de engenharia de software deve 
Introdução à engenharia de software 17
se ater a princípios éticos, de modo que os resultados do trabalho 
do profissional não prejudiquem a si e a organização ou o cliente.
Dessa forma, Sommerville (2011) cita como princípios éticos na 
engenharia de software: respeitar a confidencialidade das 
informações do cliente; não aceitar trabalhos fora de sua competência 
profissional; respeitar direitos de propriedade intelectual e realizar 
bom uso de computadores (não jogar em horário de trabalho ou 
espalhar vírus e malwares, por exemplo).
1.3 O engenheiro de software 
e outros profissionais
Em uma organização, o engenheiro de 
software pode assumir várias funções, atuando 
no desenvolvimento de software, na gestão de 
equipes ou mesmo como consultor.
Desse modo, sendo um profissional que produz inovação, 
o engenheiro de software deve estar preparado para conviver e 
trabalhar com pessoas de diferentes áreas do conhecimento, como 
outros engenheiros, administradores, designers, outros profissionais 
da área de TI, profissionais da área jurídica, matemáticos e 
profissionais de ciências humanas.
A esses grupos formados por profissionais de diferentes áreas do 
conhecimento (equipes multidisciplinares), o papel do engenheiro 
de software é abrangente, podendo variar desde a definição dos 
requisitos do projeto e a programação (ou codificação) do software, 
até a gestão do projeto como um todo.
Figura 3 – O engenheiro de software é um profissional que trabalha 
com equipes de diferentes áreas do conhecimento.
Vídeo
18 Engenharia de Software
So
ng
_a
bo
ut
_s
um
m
er
/S
hu
tt
er
st
oc
k
Durante o processo de desenvolvimento de software, é 
necessária a definição de papéis e responsabilidades, de modo que 
cada profissional saiba exatamente o que fará. Sommerville (2011) 
cita como exemplos as funções de gerente de projeto, gerente de 
configuração e programador.
Sendo tão relevante para o sucesso das organizações, o engenheiro 
de software deve apresentar uma série de competências relacionadas 
tanto à sua formação pessoal quanto ao seu desempenho profissional. 
Essas competências, conforme afirmam Pressman e Maxim (2016), 
são o senso de responsabilidade individual, a consciência aguçada 
das necessidades de sua equipe de trabalho, a honestidade, a 
capacidade de se mostrar resiliente sob pressão, o senso de lealdade, 
a atenção aos detalhes e o pragmatismo.
Constantine (1993 apud PRESSMAN; MAXIM, 2016) 
enumera paradigmas, ou padrões, para a formação de equipes de 
desenvolvimento. Esses paradigmas consideram questões como a 
formalidade de hierarquias, a colaboração entre os membros da 
equipe e a capacidade de solucionar problemas.
No paradigma fechado, a principal característica é a existência 
de uma hierarquia formal entre gestores e colaboradores, em que 
se predomina a ordem. Porém, essa estrutura pode não ser ideal 
quando se necessita desenvolver a criatividade e a inovação nas 
Introdução à engenharia de software 19
equipes de trabalho, uma vez que a comunicação entre os membros, 
nesse paradigma, tende a ser mais restrita.
No paradigma randômico, o que predomina é a iniciativa 
individual dos membros da equipe. Opostamente ao paradigma 
fechado, esse é mais adequado para o desenvolvimento de 
inovações. Porém, por depender de decisões individuais, podem 
surgir conflitos, caso seja preciso agir de modo mais ordenado, uma 
vez que nesse paradigma a possibilidade de surgirem divergências 
de opiniões é maior.
No paradigma sincronizado, o problema é segmentado de modo 
que os membros da equipe organizem-se para que cada um trabalhe 
em uma parte. Porém, a comunicação entre os membros, nesse caso, 
é prejudicada, uma vez que cada equipe, desenvolvendo apenas uma 
parte do software, terá conhecimento somente da parte que desenvolve, 
tendo pouco ou nenhum conhecimento das demais partes.
No paradigma aberto, por sua vez, predominam-se a 
colaboração, a comunicação e o consenso nas decisões. Para projetos 
inovadores e mais complexos, equipes estruturadas nesse paradigma 
tendem a se destacar. Como exemplo, têm-se as equipes estruturadas 
em rede, em que os profissionais colaboram mutuamente.
Independentemente do paradigma escolhido, é importante que 
o engenheiro de software saiba organizar a equipe de trabalho de 
modo que as potencialidades de cada membro sejam aproveitadas 
ao máximo para o desempenho das atividades do projeto. Para isso, 
é necessário que o gestor de projetos conheça as necessidades e saiba 
reconhecer os esforços de sua equipe de trabalho.
Sommerville (2011) enumera quatro fatores essenciais no 
gerenciamento de equipes: consistência, inclusão, honestidade e respeito.
A consistência diz respeito à valorização por igual de cada 
membro da equipe, considerando que as pessoas não devem sentir 
que seu trabalho é desvalorizado ou subvalorizado.
20 Engenharia de Software
A inclusão é derivada da consistência. Uma vez que o trabalho 
de um profissional deve ser valorizado, as propostas apresentadas 
por este devem ser levadas em consideração, independentemente do 
cargo ou do tempo de trabalho na organização.
A honestidade deve permear toda a equipe. O engenheiro de 
software deve estar consciente do seu nível técnico e ser honesto 
com os demais membros da equipe, não supervalorizando ou 
subvalorizando as suas habilidades.
O respeito é essencial em uma equipe multidisciplinar, na qual 
cada profissional deve ter consciência das diferenças do outro na 
maneira de pensar e de trabalhar, sem atribuir conclusões precipitadas 
em relação à competência deste em realizar as atividades do projeto. 
Isso é importante para que as competências de cada membro da 
equipe sejam adequadamente aproveitadas, sem que preconceitos 
prejudiquem o desempenho do projeto como um todo.
Desse modo, saber trabalhar em equipe é uma competência 
essencial para o engenheiro de software, uma vez que, sendo um 
gestor, necessita obter o melhor aproveitamento de profissionais e 
demais recursos necessários para o desenvolvimento de um software.
Considerações finais
Conforme estudamos, as atribuições do engenheiro de software 
são bastante diversas, assim como a forma como ele desempenha o 
trabalho e organiza as equipes.
Além disso, compreendemos a importância do mercado de 
software no Brasil e como este se encontra em crescimento, podendo 
observar que a atuação do engenheiro de software não se resume a 
atividades de programação, visto que, além de desenvolvedor, ele é 
gestor de projetos.
Introdução à engenharia de software 21
Por fim, pudemos entender, também, que o engenheiro de 
software é um profissional que sabe transformar necessidades e 
requisitos em soluções lucrativas e operacionalmente eficazes.
Ampliando seus conhecimentos
• O QUE UM ENGENHEIRO de software faz? 2018. 
1 vídeo (8min26s). Publicado pelo canal Código 
Fonte TV. Disponível em: https://www.youtube.com/
watch?v=wdU9L3DqU2w. Acesso em: 9 out. 2019.
Este vídeo explica, com uma linguagem clara e descontraída, 
as principais atividades de um engenheiro de software, além 
de apresentar de modo resumido o que são atividades de 
projeto, requisitos, processos, construção, testes, qualidade, 
depuração, entrega e manutenção.
• CONFEA – Conselho Federal de Engenhariae Agronomia. 
Resolução n. 1.100, de 24 de maio de 2018. Diário Oficial 
da União, Brasília, DF, 8 jun. 2018. Disponível em: http://
www.in.gov.br/materia/-/asset_publisher/Kujrw0TZC2Mb/
content/id/21012726/do1-2018-06-08-resolucao-n-1-100-
de-24-de-maio-de-2018-21012669. Acesso em: 9 out. 2019.
Esta resolução do Conselho Federal de Engenharia e 
Agronomia (CONFEA) regulamenta a atividade de engenharia 
de software. Conforme mencionado nesse capítulo, por meio 
dessa resolução, o profissional de engenharia de software 
integra o grupo dos engenheiros eletricistas, sendo, como todo 
engenheiro, um especialista em projetos.
https://www.youtube.com/watch?v=wdU9L3DqU2w
https://www.youtube.com/watch?v=wdU9L3DqU2w
22 Engenharia de Software
Atividades
1. Agora que você sabe o que faz um engenheiro de software, é 
hora de identificar como está o mercado de trabalho na área. 
Pesquise, em sites de emprego, a disponibilidade de vagas de 
trabalho para engenheiro de software. Escolha três vagas do 
seu interesse e descreva por que você ser interessou por elas.
2. Cite e descreva os quatro fatores essenciais para o 
gerenciamento de equipes de trabalho em engenharia de 
software.
3. Um dos processos essenciais na engenharia de software 
é a engenharia de requisitos. Qual é a importância desse 
processo?
Referências
CONFEA – Conselho Federal de Engenharia e Agronomia. Resolução 
n. 1.100, de 24 de maio de 2018. Diário Oficial da União, Brasília, DF, 8 
jun. 2018. Disponível em: http://www.in.gov.br/materia/-/asset_publisher/
Kujrw0TZC2Mb/content/id/21012726/do1-2018-06-08-resolucao-n-1-
100-de-24-de-maio-de-2018-21012669. Acesso em: 9 out. 2019.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem 
profissional. Porto Alegre: AMGH, 2015.
SCHACH, S. Engenharia de software: os paradigmas clássico e orientado a 
objetos. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson Prentice 
Hall, 2011.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de 
Janeiro: Elsevier, 2013.
2
Planejamento e processo de software
Agora que sabemos o que faz um engenheiro de software, os 
princípios que orientam a prática desse profissional e a relação 
dele com a equipe de trabalho, vamos conhecer, neste capítulo, o 
processo básico do desenvolvimento de software.
Além disso, vamos aprender os principais modelos utilizados para 
o desenvolvimento de sistemas, desde os tradicionais, já consagrados 
pela indústria de software, até os ágeis, cada vez mais utilizados.
Com relação aos tradicionais, vamos estudar os modelos em 
cascata, em espiral, em V, cíclico e RUP (Rational Unified Process). 
Já com relação aos ágeis, vamos conhecer os modelos XP (Extreme 
Programming), Scrum e AUP (Agile Unified Process).
Esses estudos são fundamentais, pois tratam de modelos que 
acompanharão a sua carreira como engenheiro de software.
2.1 Estrutura básica do 
desenvolvimento de software
Para começar a compreender o processo 
básico de desenvolvimento de software, imagine, 
por exemplo, que você vai construir uma casa. 
Antes de iniciar a construção, seja contratando 
um profissional de arquitetura e engenharia – que é o recomendado 
– ou construindo a sua casa por conta própria, você vai precisar de 
um projeto e de profissionais que o executem, os quais nortearão o 
seu trabalho.
Vídeo
24 Engenharia de Software
O mesmo ocorre com o desenvolvimento de um software, pois 
esse necessita de modelos para norteá-lo e garantir que, ao fim de 
todo o processo, ele seja funcional e confiável.
Todo modelo, seja tradicional ou ágil, segue uma metodologia 
genérica composta de cinco etapas: comunicação, planejamento, 
modelagem, construção e entrega (PRESSMAN; MAXIM, 2016).
Na primeira etapa, de comunicação, é realizado o contato com as 
partes interessadas para tratar de procedimentos do início do projeto 
(contratos, termos de abertura, dentre outros) e levantamento dos 
requisitos funcionais (relacionados à funcionalidade do sistema) e não 
funcionais (relacionados à segurança e às configurações do sistema).
Já na segunda etapa, de planejamento é definido o cronograma de 
atividades dos profissionais envolvidos, as estimativas de utilização 
de recursos (humanos, materiais, financeiros e tecnológicos) e 
como será realizado o acompanhamento do projeto (a definição de 
métricas de desempenho, por exemplo). A realização dessa etapa de 
modo efetivo depende da prévia definição dos requisitos da etapa 
anterior; ou seja, quanto mais detalhado for o levantamento dos 
requisitos, melhor será o planejamento.
Na terceira etapa, de modelagem, também conhecida como 
implementação e teste unitário, são realizadas as atividades de 
desenvolvimento do software propriamente dito. É nessa fase que 
o projeto do software começa a ganhar forma, com os primeiros 
diagramas e fluxogramas (diagramas UML, por exemplo).
Na construção, a quarta etapa, os requisitos são traduzidos 
em linhas de código, as quais formam os programas componentes 
do conjunto de software. Cada programa desenvolvido é testado 
unitariamente para a verificação de possíveis problemas ou “bugs”; 
desse modo, se encontrados, devem ser prontamente corrigidos, 
garantindo que, ao fim de todo o processo, o software esteja seguro 
e plenamente funcional. Essas unidades de programa desenvolvidas 
Planejamento e processo de software 25
são integradas no formato de um sistema completo, o qual também 
deve ser testado.
Por fim, na quinta etapa, acontece a entrega do sistema 
desenvolvido ao cliente, que também deverá testá-lo e verificar 
se atendeu aos seus requisitos. Nessa fase há também a realização 
de atividades de suporte técnico; assim, conforme necessário, ao 
instalar o sistema e colocá-lo em operação, manutenções corretivas 
e melhorias devem ser efetuadas.
Essas cinco etapas dizem respeito à estrutura básica de 
desenvolvimento de um software; ela é aplicada, de modo direto ou 
com adaptações, nos modelos tradicionais e ágeis.
Como você pode perceber, desenvolver um software não é uma 
tarefa simples, uma vez que requer interação com o usuário, 
planejamento e muitas etapas de testes. No entanto, os modelos 
descritos a seguir possibilitam muitas formas de aplicar as cinco 
etapas anteriormente descritas.
2.2 Modelos tradicionais 
de desenvolvimento
Apesar da existência dos modelos ágeis, 
conforme vamos estudar na próxima seção, os 
modelos tradicionais de desenvolvimento ainda 
são utilizados em projetos em que a existência de 
documentação e maior estruturação do software sejam relevantes.
Os principais modelos tradicionais fazem uso da estrutura básica 
de desenvolvimento, descrita na seção anterior (comunicação, 
planejamento, modelagem, construção e entrega), sendo que se 
diferenciam dos modelos ágeis pela forma e sequenciamento de 
aplicação de cada etapa da estrutura, uma vez que, nos modelos 
tradicionais, podem ser em cascata, em espiral, em V ou em formato 
cíclico, além do modelo RUP (Rational Unified Process).
Vídeo
26 Engenharia de Software
• Modelo em cascata
É o modelo mais antigo de desenvolvimento em engenharia de 
software e, de acordo com Sommerville (2011, p. 20), é “um processo 
dirigido a planos – em princípio, você deve planejar e programar 
todas as atividades do processo antes de começar a trabalhar nelas” 
(SOMMERVILLE, 2011, p. 20).
Nesse modelo, a estrutura básica de desenvolvimento é aplicada 
de modo sequencial, ou seja, com uma atividade precedendo a 
outra. Além disso, para passar de uma atividade a outra, é necessária 
a aprovação do responsável pelo desenvolvimento, geralmente por 
meio de um documento assinado. Dessa forma, nenhuma atividade 
pode ser iniciada até que a anterior esteja concluída, e o software é 
colocado em uso somente na etapa final (entrega).
A Figura 1, a seguir, representa o modelo em cascata. Observe 
que nesse modelo o processo flui de modo constante, como em uma 
cascata, e as cinco etapas são aplicadas sequencialmente.
Figura1 – Modelo em cascata
Comunicação 
Planejamento
Modelagem
Construção
Entrega
Fonte: Elaborada pelo autor com base em Pressman e Maxim, 2016.
Planejamento e processo de software 27
O modelo em cascata é adequado para ambientes de 
desenvolvimento estável, com pouca ou nenhuma alteração de 
requisitos, pois se trata de um modelo inflexível.
• Modelo em espiral
Esse modelo possibilita a repetição das etapas de desenvolvimento 
de modo cíclico. Nesse caso, as etapas de comunicação, planejamento, 
modelagem, construção e entrega se repetem com sucessivas versões 
cada vez mais sofisticadas do sistema. Desse modo, à medida que 
se efetua cada entrega, uma nova fase de comunicação se inicia por 
meio da revisão dos requisitos, sucedendo para uma nova sessão de 
planejamento, modelagem etc.
Observe na Figura 2, a seguir, que no modelo em espiral as 
fases acontecem em ciclos repetitivos. A linha em espiral simboliza 
o processo de desenvolvimento passando pelas cinco etapas, de 
modo repetitivo, e, ao fim de cada ciclo de cinco etapas, uma versão 
aprimorada do software é entregue ao usuário.
Figura 2 – Modelo em espiral
Modelagem
Planejamento
Comunicação
Entrega
Construção
Fonte: Elaborada pelo autor com base em Pressman e Maxim, 2016.
Esse modelo, em espiral, é adequado para o desenvolvimento 
de software em larga escala e para ambientes com mais incerteza 
em relação aos requisitos, uma vez que permite a revisão desses 
sempre que uma nova entrega é efetuada. Além disso, é adequado 
28 Engenharia de Software
para software de desenvolvimento contínuo, no qual novas versões 
podem ser lançadas a cada entrega.
Segundo Wazlawick (2013), o modelo em espiral é útil 
tambémpara projetos com fases bem definidas e com requisitos 
bem conhecidos e estáveis, além de ser recomendado para equipes 
inexperientes, pois fornece um modelo a ser seguido, o que evita 
esforços inúteis.
• Modelo em V
Esse modelo é uma variação dos modelos em cascata e espiral, 
e “descreve a relação entre ações de garantia da qualidade e ações 
associadas a comunicação, modelagem e atividades de construção 
iniciais” (PRESSMAN; MAXIM, 2016, p. 42).
Em outras palavras, esse modelo divide o processo de 
desenvolvimento em duas macroetapas mutuamente relacionadas: 
uma de projeto e codificação, e outra de testes, visando à garantia da 
qualidade do software.
Observe a seguir, na Figura 3, que na primeira macroetapa, à 
esquerda, é realizada primeiramente a modelagem de requisitos do 
sistema; depois efetua-se o projeto de arquitetura do sistema como 
um todo e, ainda, dos seus componentes, partindo para o fim da 
etapa, em que se gera o código do programa conforme a arquitetura 
planejada.
Na segunda macroetapa, representada na Figura 3, à direita, 
realizam-se os testes para validar as atividades realizadas na 
macroetapa anterior. Dessa forma, há primeiramente os testes 
dos códigos desenvolvidos; em seguida, acontecem os testes de 
integração da arquitetura do sistema e de seus componentes, 
partindo para o teste do sistema como um todo e, finalmente, para o 
teste de aceitação por parte do cliente, tendo como base os requisitos 
definidos para o programa.
Planejamento e processo de software 29
Figura 3 – Modelo em V
Implantação
Modelagem de 
requisitos
Projeto de 
arquitetura
Projeto de 
componente
Geração de código
Teste de aceitação
Teste de sistema
Teste de integração
Teste de unidade
Verifica
Verifica
Verifica
Verifica
Fonte: Elaborada pelo autor com base em Pressman e Maxim, 2016.
O modelo em V é indicado quando a realização de múltiplos 
testes seja necessária, pois possibilita melhor detecção de erros em 
cada etapa de realização.
• Modelo cíclico
Esse modelo tem formato cíclico, como o de espiral, porém 
enfatiza a rápida execução das etapas de planejamento e modelagem, 
adicionando uma etapa de construção de protótipos.
Observe na Figura 4, a seguir, que, assim como os demais 
modelos, o de prototipação inicia-se com a etapa de comunicação, 
a qual é uma das mais importantes. Nessa fase, uma reunião é feita 
com as partes interessadas no projeto (clientes, desenvolvedores, 
dentre outras) para definir os objetivos e os requisitos necessários 
para o desenvolvimento do software. Em seguida, as etapas de 
planejamento e modelagem são executadas no formato de um 
projeto rápido, em que se constrói um protótipo do software. Depois 
de entregue o software e recebido o feedback, o protótipo é discutido 
30 Engenharia de Software
em uma nova etapa de comunicação, na qual os requisitos do projeto 
são refinados, e assim sucessivamente.
Figura 4 – Modelo cíclico
Construção de 
protótipos
Modelagem rápida
Planejamento rápido
Comunicação
Entrega
(feedback)
Fonte: Elaborada pelo autor com base em Pressman e Maxim, 2016.
De acordo com Sommerville (2011, p. 30), o desenvolvimento 
de protótipos proporciona vantagens tanto aos clientes quanto aos 
desenvolvedores. Na definição de requisitos, um protótipo “pode 
ajudar na elicitação e validação de requisitos de sistema”, ao passo 
que, no projeto de sistema, um protótipo “pode ser usado para 
estudar soluções específicas do software e para apoiar o projeto de 
interface do usuário”.
• Modelo RUP
O modelo RUP (Rational Unified Process), também conhecido 
como Processo Unificado (PU), “reúne elementos de todos os 
modelos de processo genéricos, ilustra boas práticas de especificação 
e no projeto e apoia a prototipação e a entrega incremental” 
(SOMMERVILLE, 2011, p. 34).
O RUP foi desenvolvido como “uma tentativa de aproveitar 
os melhores recursos e características dos modelos tradicionais 
Planejamento e processo de software 31
de processo de software, mas caracterizando-os de modo a 
implementar muitos dos melhores princípios do desenvolvimento 
ágil de software” (PRESSMAN; MAXIM, 2016, p. 56).
A organização do RUP acontece em quatro fases, as quais – 
opostamente aos modelos anteriormente descritos, orientados a 
aspectos técnicos – são relacionadas a aspectos de negócio do cliente.
Na fase de concepção, realizam-se a comunicação e o 
planejamento com o cliente, tendo como objetivo estabelecer um 
estudo de caso para o negócio a ser desenvolvido. Nessa etapa, 
identificam-se as pessoas e os sistemas que irão interagir com o 
software que será desenvolvido e avalia-se a contribuição do sistema 
para o negócio. Portanto, caso o sistema não contribua, o projeto já 
é cancelado nessa fase.
Na segunda fase, a de elaboração, realiza-se a modelagem de 
uma arquitetura do sistema. Nessa etapa, busca-se a compreensão 
dos problemas do negócio, desenvolve-se o plano do projeto e 
identificam-se os riscos e as oportunidades. Dentre os modelos 
que podem ser desenvolvidos nessa fase encontram-se: o de caso 
de uso, o de análise, o de projeto, o de implementação e o de 
disponibilização (PRESSMAN; MAXIM, 2016).
Na fase de construção, efetuam-se a construção ou codificação 
do sistema e os testes de unidades para cada componente desse 
sistema. Implementam-se, nessa etapa, todos os recursos e 
funcionalidades, e integram-se todos os componentes e partes 
do sistema codificado. Ao fim dessa fase, um sistema deverá estar 
concluído e ser funcional.
Por último, na fase de transição, efetua-se a entrega do sistema ao 
cliente e coloca-se esse sistema para funcionar em um ambiente real. 
Nessa etapa é essencial realizar o monitoramento contínuo do sistema, 
tendo em vista que pode haver a necessidade de aperfeiçoamento 
contínuo, realizando-se o suporte técnico necessário.
32 Engenharia de Software
Na Figura 5, observe que, no processo unificado, as quatro fases 
são sequenciais, mas as fases de elaboração e construção podem ser 
realizadas de maneira concomitante, ou seja, ao mesmo tempo em 
que se elabora o sistema, também se faz a construção desse.
Figura 5 – Modelo RUP
Entrega
Comunicação 
Planejamento 
Elaboração 
Transição 
Concepção 
Construção 
Modelagem 
Construção 
Fonte: Elaborado pelo autor com baseem Pressman e Maxim, 2016.
Esse modelo é recomendado para projetos em que a estabilidade 
dos processos de desenvolvimento seja importante, já que o modelo 
sendo estruturado, ao ser aplicado, tende a reduzir os riscos de 
desenvolvimento de software.
Embora esses modelos tradicionais de desenvolvimento sejam 
amplamente utilizados, vale ressaltar que, na sociedade atual, os 
problemas acontecem de modo rápido, o que demanda soluções de 
desenvolvimento ainda mais velozes. Dessa forma, os modelos ágeis 
de desenvolvimento, alguns apresentados a seguir, têm ganhado 
cada vez mais espaço entre os desenvolvedores.
Vídeo
Planejamento e processo de software 33
2.3 Modelos ágeis de 
desenvolvimento
Vamos estudar agora os modelos ágeis de 
desenvolvimento de software, bastante necessários 
em um mundo de intensas mudanças.
Quando os prazos para o desenvolvimento de sistemas são 
cada vez menores, os requisitos mudam a todo tempo e os riscos, 
consequentemente, aumentam. Diante disso, faz-se necessário o uso 
de metodologias mais ágeis e informais, abordadas a seguir.
Os modelos ágeis têm origem em princípios estabelecidos pelo 
Manifesto para o Desenvolvimento Ágil de Software, desenvolvido 
por Kent Beck – criador do modelo XP (Extreme Programming) – e 
mais 16 desenvolvedores.
De acordo com esse manifesto, no processo de desenvolvimento 
de software é importante valorizar os seguintes aspectos: as 
interações entre os indivíduos acima de processos e sistemas; 
o software operacional acima da documentação completa; a 
colaboração com os clientes acima de negociação contratual; e as 
respostas às mudanças acima de seguir um plano.
Conforme afirma Sommerville (2011, p. 39), os modelos 
ágeis “são modelos de desenvolvimento incremental em que os 
incrementos são pequenos e, normalmente, as novas versões do 
sistema são criadas e disponibilizadas aos clientes a cada duas ou três 
semanas”. Dessa forma, são modelos de desenvolvimento de caráter 
cíclico, no qual as etapas de comunicação, planejamento, entre 
outras, se repetem em ciclos curtos e com a intensa participação dos 
clientes no processo de desenvolvimento.
Assim, justamente por se tratar de ciclos curtos de 
desenvolvimento, não é prioritário haver uma documentação 
completa ou mesmo um plano complexo para se seguir. Além 
disso, os contratos normalmente são por tempo de desenvolvimento, 
Na Figura 5, observe que, no processo unificado, as quatro fases 
são sequenciais, mas as fases de elaboração e construção podem ser 
realizadas de maneira concomitante, ou seja, ao mesmo tempo em 
que se elabora o sistema, também se faz a construção desse.
Figura 5 – Modelo RUP
Entrega
Comunicação 
Planejamento 
Elaboração 
Transição 
Concepção 
Construção 
Modelagem 
Construção 
Fonte: Elaborado pelo autor com base em Pressman e Maxim, 2016.
Esse modelo é recomendado para projetos em que a estabilidade 
dos processos de desenvolvimento seja importante, já que o modelo 
sendo estruturado, ao ser aplicado, tende a reduzir os riscos de 
desenvolvimento de software.
Embora esses modelos tradicionais de desenvolvimento sejam 
amplamente utilizados, vale ressaltar que, na sociedade atual, os 
problemas acontecem de modo rápido, o que demanda soluções de 
desenvolvimento ainda mais velozes. Dessa forma, os modelos ágeis 
de desenvolvimento, alguns apresentados a seguir, têm ganhado 
cada vez mais espaço entre os desenvolvedores.
Vídeo
34 Engenharia de Software
e não pela entrega de um software completo ou pelo cumprimento 
de requisitos.
Os principais modelos ágeis abordados neste Capítulo são o XP 
(Extreme Programming), o scrum e o AUP (Agile Unified Process).
• Modelo XP
É um modelo ágil que considera o desenvolvimento de software 
sob uma perspectiva diferente dos demais modelos. Para essa 
metodologia, a definição de requisitos é feita considerando cenários 
ou histórias de clientes; os programadores trabalham sempre em pares 
e o código é escrito em definitivo apenas após a realização de testes.
O projeto na XP segue o princípio KISS (Keep It Simple 
Stupid); sendo assim, é melhor um projeto simples com múltiplos 
incrementos posteriores do que projetos mais complexos logo de 
início. Desse modo, quando concluído, cada projeto é integrado ao 
sistema e todos os testes, após essa integração, devem apresentar 
sucesso.
• Modelo scrum
Esse modelo tem caráter cíclico, cujo nome diz respeito a uma 
jogada no esporte rugby, na qual os atletas se encontram corpo a 
corpo. Nesse modelo, as atividades de desenvolvimento ocorrem em 
um ciclo denominado sprint.
O ciclo de trabalho no scrum consiste na realização de tarefas 
de desenvolvimento, definidas em uma lista de prioridades de 
requisitos, chamada de backlog. Dessa forma, é realizada uma reunião 
inicial, denominada sprint planning meeting, em que são feitas as 
definições de planejamento das atividades que serão desenvolvidas. 
Em seguida, iniciam-se os ciclos de desenvolvimento, denominados 
sprints, nos quais cada desenvolvedor desempenha a tarefa que lhe 
foi designada.
Planejamento e processo de software 35
No modelo scrum, a cada ciclo de 24 horas, são realizadas 
reuniões de 15 minutos, nas quais a equipe de desenvolvimento, 
sob a liderança do scrum master, responde às seguintes questões 
(PRESSMAN; MAXIM, 2016): o que você realizou desde a última 
sprint? Você está tendo alguma dificuldade? O que você vai fazer 
antes da próxima reunião?
Após a realização das sprints, a equipe apresenta as 
funcionalidades do software implantadas e, então, um novo ciclo de 
desenvolvimento se inicia.
• Modelo AUP
Trata-se de uma variante do Processo Unificado voltada para 
o desenvolvimento ágil. Esse processo adota as atividades clássicas 
do RUP – concepção, elaboração, construção e transição –, porém 
com ciclos repetitivos para tornar o modelo mais ágil. Cada iteração 
adota as seguintes atividades:
1. Modelagem: elaboração de modelos, preferencialmente com 
o uso da UML (Unified Modeling Language).
2. Implementação: transformação dos modelos em código.
3. Testes: realização de testes para a descoberta de erros e 
oportunidades de melhoria no código.
4. Entrega: entrega de um incremento do código e feedback dos 
usuários.
5. Configuração e gerenciamento do projeto: gerenciamento de 
configurações, alterações, riscos e controle.
6. Gerenciamento do ambiente: gerenciamento de processos, 
padrões, ferramentas e tecnologias de suporte.
Embora sejam diferentes, todos os métodos ágeis apresentados 
são importantes. Cabe à equipe de desenvolvimento, conforme as 
necessidades de cada projeto e as preferências pessoais, escolher o 
mais adequado para utilizar em cada caso.
36 Engenharia de Software
Considerações finais
Neste capítulo, estudamos os principais modelos utilizados para 
o desenvolvimento de um software.
Primeiramente, conhecemos a estrutura básica do 
desenvolvimento de software, abordando as etapas de comunicação, 
planejamento, modelagem, construção e entrega.
Em seguida, identificamos os principais modelos tradicionais 
– em cascata, em espiral, em V, cíclico e RUP – e, com relação 
aos modelos ágeis, estudamos os princípios do Manifesto Ágil de 
Desenvolvimento de Software, além dos modelos XP, scrum e AUP.
Estudar os modelos de desenvolvimento de software é muito 
importante para que possamos escolher o mais adequado para 
determinado projeto e fazer o máximo aproveitamento dos recursos 
disponíveis.
Vale ressaltar que não há modelo mais correto ou melhor. A 
escolha do modelo mais adequado dependerá do tipo de sistema 
que deveremos construir, do perfil da nossa equipe de projeto e dos 
requisitos do nosso cliente.
Ampliando seus conhecimentos
• BECK, K. Programação extrema explicada: acolha as 
mudanças. Porto Alegre: Bookman, 2004.
Neste livro, o criador do Extreme Programming apresenta 
esse modelo com uma linguagem simples e clara. A obra é 
recomendada para quem deseja um estudo mais aprofundado 
do modelo XP, estudado neste capítulo.• SCOTT, K. O processo unificado explicado. Porto Alegre: 
Editora Bookman, 2002.
Planejamento e processo de software 37
Neste livro, explica-se o RUP (Rational Unified Process), o 
qual, conforme estudamos neste capítulo, é um dos modelos 
tradicionais mais usados para o desenvolvimento de sistemas.
• RUBIN, K. S. Scrum essencial: um guia prático para o mais 
popular processo ágil. Rio de Janeiro: Alta Books, 2017.
Nesse livro, explica-se de maneira didática o modelo ágil 
scrum, abordado neste capítulo, com ilustrações e descrições 
de fácil compreensão.
Atividades
1. No modelo ágil scrum são desempenhadas as funções de 
scrum master, product owner e development team. Pesquise 
e disserte sobre a importância de cada uma delas.
2. Uma variante do modelo XP é o Industrial XP, que 
adota práticas diferenciadas para projetos em grandes 
organizações. Pesquise e descreva as características desse 
modelo alternativo
3. Neste capítulo, tratamos brevemente do Manifesto de 
Desenvolvimento Ágil de Software. Uma variante desse 
manifesto são os 12 princípios do software ágil. Pesquise e 
descreva esses princípios.
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson 
Prentice Hall, 2011.
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de 
Janeiro: Elsevier, 2013.
3
Engenharia de requisitos
Neste capítulo, vamos tratar da definição de requisitos, uma 
das mais importantes atividades da engenharia de software. 
Dessa forma, é importante, primeiramente, compreendermos que 
dependendo da situação, o mesmo software pode ser tanto um 
serviço quanto um produto.
Sendo um serviço, é importante definirmos os requisitos 
considerando que todo software é criado de pessoas para pessoas 
e que cada usuário tem necessidades específicas. Um software é 
intangível, ou seja, não pode ser tocado, o que significa que o valor 
desse serviço é baseado na percepção de quem vai utilizá-lo. Diante 
disso, é essencial que o engenheiro ouça o que o cliente tem a dizer 
para que o software seja desenvolvido de modo que atenda às suas 
necessidades.
Já como produto a ser comercializado, devemos considerar que 
um software requer o uso de recursos para o seu desenvolvimento, 
os quais muitas vezes são escassos ou caros, como pessoas, materiais 
e tecnologias. Sendo assim, definir previamente requisitos de 
desenvolvimento é mais do que uma atividade obrigatória de um 
engenheiro de software, é uma responsabilidade.
Assim, neste capítulo, vamos tratar dos requisitos sob os pontos 
de vista do usuário e do sistema. Primeiramente, vamos apresentar 
métodos úteis para a coleta de requisitos, depois estudaremos quais 
requisitos podem ser coletados por meio desses métodos e, por fim, 
observaremos as formas de organizar e apresentar os requisitos para 
o cliente e para a equipe de desenvolvimento.
40 Engenharia de Software
3.1 Métodos para a coleta de 
requisitos
Imagine que você vai comprar um presente 
para uma pessoa que não é muito próxima de 
você – no amigo secreto da empresa onde você 
trabalha, por exemplo. Para não errar na escolha e evitar que a pessoa 
fique chateada, você, provavelmente, realizará uma entrevista com 
os amigos próximos dela, observará os seus hábitos, o modo como 
se veste, objetos que costuma usar, e, inclusive, poderá perguntar a 
ela mesma do que gosta, quais são seus hobbies etc. Com isso, você 
levantará os requisitos necessários para a escolha do presente. Esse 
processo é bastante semelhante ao da engenharia de requisitos.
Todo software é desenvolvido tendo em vista um usuário ou 
grupo de usuários. Assim, para que o engenheiro obtenha 
sucesso no desenvolvimento de um serviço ou produto, 
inicialmente, é necessário definir quais requisitos o software 
deverá apresentar.
Segundo Pfleeger (2004, p. 111), requisito é “uma característica do 
sistema ou a descrição de algo que o sistema é capaz de realizar, para 
atingir os seus objetivos”, ou seja, trata do que um sistema necessita 
possuir ou como deverá se comportar para que esteja conforme às 
necessidades do usuário. Desse modo, a engenharia de requisitos 
é “o conjunto de técnicas empregadas para levantar, detalhar, 
documentar e validar os requisitos de um produto” (PAULA FILHO, 
2009, p. 165), ou seja, consiste em efetuar a gestão dos requisitos 
de um software durante todo o ciclo de desenvolvimento, desde a 
concepção até a entrega.
Vídeo
Engenharia de requisitos 41
Ainda segundo Paula Filho (2009), os requisitos de um software 
devem atender a determinadas características, conforme apresenta 
a Figura 1.
Figura 1 – Características para o levantamento de requisitos de um 
produto ou software
Características 
para o 
levantamento 
de requisitos
Correção
Precisão
Completeza
Consistência
Priorização
Verificabilidade
Modificabilidade
Rastreabilidade
Fonte: Elaborada pelo autor com base em Paula Filho, 2009.
A característica correção, apresentada na figura, prevê que o 
requisito do software seja corretamente descrito e que ele seja realmente 
o do software a ser construído, já a precisão trata da descrição do 
requisito, não permitindo interpretações ambíguas em relação ao que 
deve ser feito. A completeza diz respeito ao requisito abranger, de 
modo completo, aspectos relativos a funcionalidade, desempenho, 
interfaces, restrições e aspectos de qualidade, sem cláusulas de 
pendências; já a consistência possibilita que o requisito não apresente 
conflitos com outros requisitos, de modo lógico ou temporal. A 
priorização caracteriza-se pelo requisito poder ser classificado, em 
42 Engenharia de Software
conjunto com outros requisitos, conforme sua importância (essencial, 
desejável ou opcional, por exemplo); a verificabilidade trata do 
requisito ser verificável quanto à sua conformidade com o produto 
final desenvolvido. A modificabilidade permite que o requisito 
seja modificável quando necessário. Por fim, a rastreabilidade diz 
respeito ao requisito poder ser rastreável quanto aos seus antecedentes 
e consequências, podendo ser relacionada à origem do requisito (para 
trás) ou aos resultados obtidos (para frente).
Para garantir que esses aspectos sejam obtidos no levantamento 
dos requisitos, é necessário considerar nesse processo as 
características do usuário e as especificações de sistema. Assim, o 
processo de engenharia de requisitos, segundo Pressman (2011), é 
composto de algumas fases, conforme podemos observar na figura 
a seguir.
Figura 2 – Fases da engenharia de requisitos
Concepção
Negociação
Levantamento
Especificação
Elaboração
Validação
Gestão
Fonte: Elaborada pelo autor com base em Pressman, 2011.
Engenharia de requisitos 43
O processo inicial da definição dos requisitos, conforme 
podemos observar na Figura 2, é a concepção, na qual são 
previstos os problemas que serão solucionados pelo software 
e são identificadas as partes interessadas1. Em seguida, há o 
levantamento das informações necessárias para a elaboração dos 
requisitos, que acontece por meio de técnicas, como entrevistas e 
etnografia, aplicadas junto às partes interessadas. Já na elaboração, 
as informações obtidas são analisadas, o que permite descrever 
como os usuários interagirão com o sistema e, assim, construir 
um modelo de requisitos para ser apresentado. Posteriormente, 
há a fase de negociação, na qual são discutidos possíveis conflitos 
relacionados ao que as partes interessadas desejam e ao que pode ser 
desenvolvido até se chegar a um consenso. Na sequência, elabora-se 
o modelo de especificação de requisitos de software – ou SRS 
(Software Requirements Specification) –, documento contendo a 
descrição detalhada dos requisitos do sistema a ser desenvolvido. 
Depois, ocorre a validação do que foi descrito na especificação de 
requisitos de software junto ao usuário, detectando e corrigindo 
prováveis inconsistências, omissõese erros. Por fim, na etapa de 
gestão, uma vez validada, a especificação de requisitos de software é 
acompanhada durante o processo de desenvolvimento de modo que, 
caso necessário, correções e mudanças possam ser feitas.
Além disso, o levantamento dos requisitos deve considerar, 
além do usuário, todas as partes interessadas nesse sistema 
(stakeholders), visto que, segundo Sommerville (2011), no 
processo de definição dos requisitos podem surgir dificuldades, 
como o fato de as partes interessadas nem sempre sabem o 
1 Uma parte interessada, denominada stakeholder, é “quem tem alguma influência 
direta ou indireta sobre os requisitos do sistema” (SOMMERVILLE, 2011, p. 70), ou seja, 
todo indivíduo envolvido no processo de desenvolvimento de um sistema.
44 Engenharia de Software
que desejam de um sistema; elas podem utilizar linguagem 
própria ou jargões técnicos para explicar os requisitos, termos 
nem sempre compreensíveis para os engenheiros de software. 
Podem haver diferenças em termos de prioridades ou de opiniões 
com relação a requisitos necessários ou não para determinado 
sistema. A definição de requisitos pode ser influenciada por 
fatores políticos (por exemplo, influência na organização) e os 
requisitos definidos pelas partes interessadas podem mudar com 
o tempo, assim como as prioridades para cada requisito, o que 
pode dificultar o processo de desenvolvimento do sistema.
Desse modo, durante o levantamento de requisitos, para verificar 
quais são as necessidades dos usuários em relação ao software que 
será desenvolvido, realizam-se técnicas como entrevistas, análise de 
cenários, etnografia e coleta colaborativa, descritas a seguir. Nessa 
etapa, também é necessário realizar um levantamento sobre pessoas, 
processos e recursos envolvidos no desenvolvimento e na utilização 
do software. Pode-se também realizar pesquisa em base de dados, 
artigos, documentos técnicos de hardware e software, dentre outras 
fontes, a fim de se obter informações adicionais que possam ser 
utilizadas como base para a definição dos requisitos.
• Entrevistas
A entrevista é uma das técnicas primárias para a descoberta 
de requisitos. Em um ambiente formal, ou informal, realizam-se 
perguntas para saber a opinião das partes interessadas sobre quais 
seriam os requisitos do sistema para o usuário. Recomenda-se a 
realização das entrevistas em equipe, isto é, com vários profissionais 
de engenharia de software trabalhando juntos e anotando as 
respostas das perguntas. As entrevistas podem ser de dois tipos, 
conforme figura a seguir.
Engenharia de requisitos 45
Figura 3 – Tipos de entrevista durante a definição de requisitos
abertas fechadas
não há um roteiro definido de 
perguntas – inicia-se com uma 
pergunta inicial e a entrevista 
evolui conforme as respostas dos 
stakeholders.
as perguntas são previamente 
definidas e os stakeholders se 
atêm apenas a responder às 
perguntas realizadas.
Entrevistas (em equipe) 
Fonte: elaborada pelo autor com base em Sommerville, 2011.
As entrevistas são adequadas para uma compreensão 
abrangente a respeito dos hábitos das partes interessadas, das 
dificuldades enfrentadas nos sistemas que atualmente usam e das 
expectativas relacionadas ao novo sistema que será desenvolvido 
(SOMMERVILLE, 2011). Outra vantagem das entrevistas é 
o esclarecimento de jargões técnicos, processos, atividades e 
conhecimentos nem sempre claros para os engenheiros de software. 
Além disso, elas podem servir para esses profissionais obterem 
conhecimento, mesmo que pouco, da cultura da organização e de 
suas relações de poder – elementos que também podem influenciar 
no desenvolvimento do software.
• Análise de cenários
Outro método para a coleta de requisitos consiste na análise de 
cenários. Segundo Sommerville (2011, p. 73), “as pessoas geralmente 
acham mais fácil se relacionar com exemplos da vida real do que com 
descrições abstratas. Elas podem compreender e criticar um cenário 
46 Engenharia de Software
de como elas podem interagir com um sistema de software”. Assim, 
essa técnica, conforme o nome sugere, está relacionada à montagem 
e simulação de cenários hipotéticos para a utilização do software, 
como a criação de histórias no método Extreme Programming.
Dentre as situações que podem ser simuladas com a análise 
de cenários, encontram-se casos de uso do sistema por parte do 
usuário, possíveis usos inadequados, possíveis erros ou exceções 
apresentadas pelo sistema, bem como atividades simultâneas que 
podem acontecer durante a execução do sistema.
Sommerville (2011) sugere que a análise de cenários seja 
realizada por escrito, contendo cinco elementos básicos:
Figura 4 – Elementos básicos para a análise de cenários
01 02
04 05
03
Suposição 
inicial
Situação 
normal de 
utilização
Outras 
atividades
Estado do 
sistema na 
conclusão
O que pode 
dar errado
Fonte: elaborada pelo autor com base em Sommerville, 2011.
Na suposição inicial, expõe-se a situação na qual o software 
será utilizado – o cenário-base; na situação normal de utilização, 
descreve-se o processo de utilização do software, passo a passo, 
considerando o papel de cada usuário nesse processo. Na etapa que 
considera o que pode dar errado, descreve-se, a partir da situação 
normal de utilização, os possíveis erros que podem acontecer durante 
a utilização do software. Em outras atividades, verificam-se outras 
atividades ou restrições com relação ao uso do software, as quais 
não se encontram na situação normal de utilização. Por fim, em 
Engenharia de requisitos 47
estado do sistema na conclusão, abordam-se os processos relativos 
à finalização do uso do sistema e como a sua utilização é concluída.
• Etnografia
Essa possível técnica para o levantamento de requisitos 
considera que o uso do software é realizado em um contexto social 
e organizacional, ou seja, é considerado parte de uma cultura. A 
etnografia “é uma técnica de observação que pode ser usada para 
compreender os processos operacionais e ajudar a extrair os requisitos 
de apoio para estes processos” (SOMMERVILLE, 2011, p. 75).
A etnografia consiste na observação do uso de um artefato em 
seu ambiente pelos usuários. Um observador se introduz nesse 
ambiente e realiza anotações a respeito do uso desse software – 
da forma como o sistema é utilizado, o porquê de determinadas 
funcionalidades serem usadas ou não e as interações dos usuários 
com a interface do sistema.
Assim, essa técnica permite a identificação de requisitos com 
base na realidade da utilização do sistema no ambiente de trabalho, e 
não apenas com base em suposições ou estudos. Além disso, permite 
a identificação de requisitos com base na observação da cooperação 
entre as pessoas e na troca de conhecimentos, experiências e 
opiniões entre elas.
• Coleta colaborativa
A coleta colaborativa de requisitos é uma técnica em que se 
realizam reuniões com a participação das partes interessadas e dos 
engenheiros de software. Essas reuniões são realizadas segundo 
regras estabelecidas para a participação, e “é sugerida uma agenda 
suficientemente formal para cobrir todos os pontos importantes, 
porém, suficientemente informal para encorajar o fluxo livre de 
ideias” (PRESSMAN, 2011, p. 133).
Nessas reuniões, identificam-se os problemas, propõem-se 
as soluções e definem-se diferentes abordagens para definir um 
48 Engenharia de Software
conjunto preliminar de requisitos. Um facilitador é escolhido 
para conduzir a reunião e garantir que as regras definidas sejam 
cumpridas.
Por fim, independentemente da técnica utilizada (entrevistas, 
análise de cenários, etnografia e coleta colaborativa), o importante é 
que, por meio dessa aplicação, seja possível a coleta dos requisitos 
funcionais e não funcionais necessários para o desenvolvimento do 
software. A seguir, definimos alguns desses requisitos.
3.2 Classificação de requisitos
Agora que você já sabe o que são requisitos, 
é importante realizar a distinção dos tipos de 
requisitos. Pfleeger(2004) sugere a priorização 
de requisitos em três categorias básicas, conforme 
figura a seguir. Essa priorização é importante para 
que a equipe de desenvolvimento seja melhor direcionada em relação 
aos seus esforços e recursos para as tarefas de desenvolvimento.
Figura 5 – Classificação de requisitos de acordo com Pfleeger (2004)
Requisitos
totalmente 
satisfeitos
altamente 
desejáveis
possíveis, mas 
que podem ser 
eliminados
Fonte: Elaborada pelo autor com base em Pfleeger, 2004.
Dentre os requisitos que devem ser totalmente satisfeitos, 
pode-se citar as funcionalidades básicas de um sistema. Por 
exemplo, um sistema comercial deve possibilitar a emissão de 
notas fiscais, ao passo que um sistema de departamento de pessoal 
(DP) deve possibilitar a exibição da ficha cadastral de determinado 
colaborador.
Vídeo
Engenharia de requisitos 49
Já os requisitos que são desejáveis, mas não necessários, dizem 
respeito a funcionalidades acessórias que seriam muito úteis para o 
usuário desempenhar suas tarefas, mas que podem ser dispensadas 
em uma versão básica do sistema. Por exemplo, o sistema comercial 
poderia emitir um relatório de clientes inadimplentes, e o sistema 
de gerenciamento de pessoal armazenar, além da ficha cadastral, o 
currículo do colaborador.
Por fim, os requisitos que são possíveis, mas poderiam ser 
eliminados, dizem respeito a adições ao sistema que podem 
ser consideradas em determinado momento, porém podem 
ser dispensadas se necessário. Um exemplo desse requisito é a 
formatação dos sistemas empresariais anteriormente mencionados, 
originalmente desenvolvidos para computadores pessoais, para o 
formato de aplicativos de celular.
Já Pressman (2011) estabelece outra classificação para requisitos, 
sob o viés da gestão da qualidade. Para o autor, os requisitos podem 
ser classificados em três modalidades, conforme apresenta a figura 
a seguir.
Figura 6 – Classificação de requisitos de acordo com Pressman 
(2011)
Requisitos
normais esperados fascinantes
Fonte: Elaborada pelo autor com base em Pressman, 2011.
Os requisitos normais são estabelecidos com base em objetivos 
e metas definidos junto às partes interessadas, utilizando técnicas 
de levantamento de requisitos. Já os requisitos esperados, que nem 
sempre são declarados pelas partes interessadas, podem ser tão 
50 Engenharia de Software
fundamentais quanto os requisitos normais, e sua ausência causará 
insatisfações. Por último, se os requisitos fascinantes estiverem 
presentes, ocasionarão, além das expectativas das partes interessadas, 
extrema satisfação, constituindo-se em uma surpresa. Portanto, a 
definição do autor supracitado considera os tipos de requisitos sob a 
perspectiva das partes interessadas no projeto.
Outra classificação possível para requisitos, segundo 
Sommerville (2011), diz respeito à sua funcionalidade. Dessa forma, 
é possível a classificação dos requisitos segundo duas modalidades, 
conforme figura a seguir.
Figura 7 – Requisitos com base na funcionalidade
Requisitos
funcionais
funcionalidades básicas de 
determinado sistema, descrevendo 
o que este deverá executar em cada 
situação. O cumprimento desses 
requisitos garante que o sistema 
funcione conforme o esperado.
restrições do sistema, ou seja, não 
descrevem o que o sistema deverá 
executar, mas sim como ele se 
comportará durante a execução. 
não funcionais
Fonte: Elaborada pelo autor com base em Sommerville, 2011.
Como exemplos de requisitos funcionais, pode-se citar, em um 
jogo, as possíveis ações que o jogador poderá desempenhar, já em 
uma página de internet, é possível mencionar o conteúdo que deverá 
ser apresentado, o layout da página, a disposição dos botões e links, 
dentre outros. No caso de exemplos de requisitos não funcionais, 
pode-se citar, tanto no jogo, como na página de internet, os requisitos 
mínimos de hardware para o funcionamento do sistema.
Tanto os requisitos funcionais quanto os não funcionais podem 
ser, também, classificados conforme os componentes do sistema e 
seus processos de desenvolvimento. Pfleeger (2004) realiza, dessa 
forma, a seguinte classificação:
Engenharia de requisitos 51
• Requisitos de ambiente físico: dizem respeito ao local físico 
de instalação e funcionamento do sistema ou hardware, 
bem como possíveis restrições de funcionamento, como 
temperatura, ruídos, vibrações, interferência magnética, 
dentre outras.
• Requisitos de interface: tratam da interação de um sistema 
com outros sistemas, abrangendo aspectos como a formatação 
de dados, entradas e saídas, dentre outros.
• Requisitos de usuários e fatores humanos: abrangem a 
forma com a qual o usuário interage com o sistema e sua 
interface, e consideram diferentes níveis de competências 
– conhecimentos, habilidades e atitudes, bem como a 
necessidade de treinamento para o seu melhoramento. Ainda, 
consideram a intuitividade, as facilidades e as dificuldades de 
compreensão do usuário, e analisam o perfil do usuário do 
sistema e quantos o utilizarão.
• Requisitos de funcionalidade: dizem respeito às funções 
do sistema, seus modos de operação, necessidades de 
aprimoramento e limitações.
• Requisitos de documentação: tratam da necessidade de 
documentação para o sistema, bem como do formato – se é 
on-line, em papel (físico) ou ambos. Também dizem respeito 
aos públicos aos quais se destina cada documentação e quais 
usuários devem ter acesso à documentação.
• Requisitos de dados: tratam da formatação dos dados, da 
frequência de envio e recebimento, da precisão, do fluxo e da 
forma de armazenagem e manutenção desses dados no sistema.
• Requisitos de recursos: dizem respeito a materiais, pessoas, 
tecnologias, dentre outros, necessários para o adequado 
funcionamento do sistema. Também tratam de questões 
relacionadas às tecnologias da informação necessárias, como 
52 Engenharia de Software
hardware, telecomunicações, infraestrutura (edificações, 
estrutura física, dentre outros) e custos de desenvolvimento.
• Requisitos de segurança: dizem respeito às políticas de 
acesso ao sistema, bem como à gestão de dados e informações, 
principalmente, dos usuários e demais stakeholders. Também, 
dizem respeito às políticas de backup (sendo que se sugere 
que as cópias sejam armazenadas em local distinto ao do 
sistema) e prevenções contra desastres naturais ou acidentes.
• Requisitos de garantia da qualidade: abrangem, por sua vez, 
questões básicas de qualidade do sistema, como confiabilidade, 
disponibilidade, manutenibilidade, capacidade, prevenção a 
falhas e defeitos, correção de erros, indicadores de desempenho, 
dentre outros.
Desse modo, é possível compreender que se pode classificar 
requisitos pela funcionalidade, conforme os componentes do 
sistema ou pela ótica da gestão da qualidade. O importante é que o 
software, ao cumprir esses requisitos, esteja adequado às necessidades 
do usuário e das demais partes interessadas pelo sistema.
3.3 Especificação e 
apresentação de requisitos
Agora que estudamos os requisitos e suas 
características, chegou a vez de definirmos como 
apresentá-los às partes interessadas, bem como a 
melhor forma de documentá-los.
Conforme afirma Sommerville (2011), especificar requisitos 
para o desenvolvimento de um sistema consiste em documentá-los. 
Uma forma de se documentar os requisitos, tanto do usuário quanto 
do sistema, é por meio da especificação de requisitos de software 
(SRS). Esse documento detalha todos os aspectos do software que 
deverão ser considerados no processo de construção. Pressman 
(2011) sugere o seguinte conteúdo para esse documento:
Vídeo
Engenharia de requisitos 53
Figura 8 – Conteúdos sugeridos para se documentar os requisitos
Introdução
Requisitos não 
funcionais
Requisitos de 
interfaces externas
Outros requisitos
Descrição geral
Validação
Características 
do sistema
Gestão
Fonte: Elaborada pelo autor com base em Pressman, 2011.
Na introdução, apresentam-se o documento, suas convenções, 
seu público-alvo,sugestões de leitura, o escopo do projeto de 
software e as referências utilizadas. Já na descrição geral, detalha-
se o software a ser desenvolvido, contemplando características, 
restrições de projeto, ambiente operacional, dentre outros. Em 
características do sistema, detalham-se os requisitos funcionais do 
sistema e suas características essenciais. Em seguida, em requisitos 
de interfaces externas, detalham-se os requisitos referentes às 
interfaces de usuário, software, hardware e comunicação. Depois, em 
requisitos não funcionais, apresentam-se requisitos considerados 
não funcionais, como de desempenho, segurança, proteção e 
qualidade. Por fim, em outros requisitos, descrevem-se requisitos 
não mencionados nos itens anteriores, porém, importantes para o 
projeto.
Essa especificação de requisitos pode ser feita de diferentes 
formas. Sommerville (2011) descreve algumas:
• Sentenças em linguagem natural: os requisitos são escritos na 
linguagem natural – sugere-se uma frase para expressar cada 
requisito.
• Linguagem natural estruturada: descrevem-se os requisitos 
em linguagem natural, porém em um formulário estruturado 
(template).
54 Engenharia de Software
• Linguagem de descrição de projeto: os requisitos são escritos 
com o uso de uma linguagem similar à de programação, mas 
com características mais abstratas.
• Notações gráficas: utilizam-se notações gráficas para a 
descrição dos requisitos, como a linguagem UML.
• Especificações matemáticas: utilizam-se notações matemáticas 
para a expressão dos requisitos (conjuntos, por exemplo) – deve-
se observar que a maioria das pessoas pode não compreender 
os requisitos escritos dessa maneira.
Sommerville (2011) ainda sugere aspectos a serem considerados 
no momento de escrever requisitos. Primeiramente, ele propõe a 
padronização do formato de escrita, por exemplo, com a escrita dos 
requisitos em uma única frase e uma justificativa para cada requisito.
Além disso, é necessária uma linguagem consistente para a 
distinção dos requisitos obrigatórios e desejáveis ou possíveis – por 
exemplo, utilizando o termo deve para os requisitos obrigatórios 
e pode para os requisitos desejáveis e possíveis. O autor sugere, 
também, o uso de alguma forma para destacar os elementos 
fundamentais do requisito – itálico, negrito ou o uso de cores.
Adicionalmente, é preciso considerar que nem todas as pessoas 
conhecem os termos técnicos utilizados na engenharia de software. 
Assim, deve-se evitar, na descrição dos requisitos, o uso de jargões, 
siglas e acrônimos que possam causar interpretações equivocadas ou 
não entendimentos.
Para melhor compreensão por parte do usuário e do 
desenvolvedor, a escrita pode ser associada ao desenvolvimento 
de protótipos para se analisar e visualizar melhor cada requisito. 
Paula Filho (2009, p. 170) sugere a utilização de um protótipo 
evolucionário, “que é uma versão parcial do produto que satisfaz a 
um subconjunto de requisitos do produto final”, ou de um protótipo 
descartável, “construído com a única finalidade de demonstrar o que 
Engenharia de requisitos 55
foi entendido ou resolvido em relação a algum aspecto da análise ou 
desenho do produto”. O autor cita os seguintes tipos de protótipos:
• Protótipo visual: adequado para expressar funções e interfaces 
de usuário, bem como relatórios gráficos, permitindo a 
visualização das interfaces e a navegação entre estas – ele pode 
ser construído com ferramentas de desenho ou em ambiente 
de programação rápida.
• Processador de textos: pode ser utilizado para prototipar 
relatórios textuais – neste caso, a amostra do relatório que o 
software deverá produzir.
• Planilhas eletrônicas: adequadas para a simulação de cálculos 
ou algoritmos complexos.
• Programas de teste: para simular a execução de partes de um 
sistema ou novas tecnologias.
Uma vez apresentados às partes interessadas, os requisitos 
podem sofrer alterações ao longo do desenvolvimento do software. 
Recomenda-se que as mudanças sejam gerenciadas e justificadas com 
base em aspectos operacionais e financeiros (custos). Sommerville 
(2011) recomenda alguns estágios para se promover mudanças em 
requisitos:
Figura 9 – Estágios para as mudanças em requisitos
Estágios
Análise de problema 
e especificação de 
mudanças
Análise de 
mudanças e custos
Implementação
de mudanças
1
2
3
56 Engenharia de Software
Fonte: Elaborada pelo autor com base em Sommerville, 2011.
Em 1, analisa-se o problema ou proposta de mudança com o 
intuito de verificar a sua validade e viabilidade. Em 2, analisam-se 
os efeitos e impactos da mudança, bem como a necessidade de 
mudanças no documento de requisitos, em que se deve aprovar a 
mudança antes de realizá-la. Por último, em 3, implementa-se a 
mudança e efetuam-se as alterações no documento de requisitos.
Por fim, vale ressaltar que, durante o desenvolvimento do 
software e no processo de apresentação dos requisitos, estes podem 
ser negociados entre as partes. Sugere-se, com base em Pressman 
(2011), que a negociação dos requisitos seja feita no sistema 
“ganha-ganha”. Ainda recomenda-se identificar os principais 
interessados na negociação, definir as condições de ganho de 
cada parte e negociar as condições, buscando-se garantir esses 
ganhos tanto para as partes interessadas quanto para a equipe de 
desenvolvimento de software.
Considerações finais
A engenharia de requisitos é uma atividade que não deve 
acontecer apenas na fase inicial de desenvolvimento de software, 
mas deve permear todo o processo de desenvolvimento de modo 
que, conforme o software é desenvolvido, os desenvolvedores 
estejam constantemente atentos às necessidades do usuário.
Os requisitos das partes interessadas, dos usuários e do 
sistema encontram-se em constante mudança, principalmente se 
considerarmos o fato de que as organizações estão inseridas em 
mercados cada vez mais dinâmicos.
Desse modo, cabe ao engenheiro de software perceber 
essas mudanças e aplicar, sempre que possível, os métodos de 
levantamento de requisitos estudados neste capítulo, com o intuito 
de manter sempre atualizados os requisitos do sistema, facilitando, 
assim, o trabalho da equipe de desenvolvimento.
Engenharia de requisitos 57
Ampliando seus conhecimentos
• VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: 
software orientado ao negócio. Rio de Janeiro: Brasport, 2016.
Esse livro descreve de modo didático, os processos 
de definição, coleta, análise e gestão de requisitos, 
relacionando-os a processos de negócio.
• FERNANDES, J. M.; MACHADO, R. J. Requisitos em projetos de 
software e de sistemas de informação. São Paulo: Novatec, 2017.
Esse livro descreve os principais processos da engenharia de 
requisitos, dando ênfase à modelagem de requisitos.
Atividades
1. Escolha um software que você utilize – pode ser um aplicativo 
de celular, um jogo, o sistema da empresa onde você trabalha 
ou outro de sua preferência. Defina, no mínimo, três 
requisitos funcionais e três requisitos não funcionais para 
esse sistema.
2. Baixe um aplicativo de celular qualquer pela internet e 
peça a uma pessoa (amigo, familiar etc.) que o utilize. Faça 
anotações e, se possível, uma gravação de vídeo de cada 
atividade ou interação dessa pessoa com o aplicativo. Defina, 
com base nessa utilização, três requisitos funcionais e três 
requisitos não funcionais para esse aplicativo.
3. Escolha um jogo digital de sua preferência. Imagine que você 
desenvolverá a continuação desse jogo e elabore um modelo 
de especificação de requisitos de software para ele.
Referências
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e 
padrões. Rio de Janeiro: LTC, 2009.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo: 
Pearson, 2004.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 
Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011.
4
Modelagem de software com a UML
Neste capítulo, vamos estudar a UML