ENGENHARIA DE REQUISITOS

Prévia do material em texto

PROFESSORA
Esp. Janaina Aparecida de Freitas
Engenharia de 
Requisitos
ACESSE AQUI O SEU 
LIVRO NA VERSÃO 
DIGITAL!
EXPEDIENTE
Coordenador(a) de Conteúdo 
Flavia Lumi Matuzawa
Projeto Gráfico e Capa
André Morais, Arthur Cantareli e 
Matheus Silva
Editoração
Nivaldo Vilela de Oliveira Junior
Design Educacional
Rodrigo Cabrini Dall Ago
Curadoria
Carla Fernanda Marek
Revisão Textual
Ariane Andrade Fabreti
Ilustração
Geison Ferreira da Silva e Eduardo 
Aparecido Alves 
Fotos
Shutterstock
DIREÇÃO UNICESUMAR
NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Graduação e Pós-graduação Kátia 
Coelho Diretoria de Cursos Híbridos Fabricio Ricardo Lazilha Diretoria de Permanência Leonardo Spaine Diretoria de 
Design Educacional Paula R. dos Santos Ferreira Head de Graduação Marcia de Souza Head de Metodologias Ativas 
Thuinie M.Vilela Daros Head de Recursos Digitais e Multimídia Fernanda S. de Oliveira Mello Gerência de 
Planejamento Jislaine C. da Silva Gerência de Design Educacional Guilherme G. Leal Clauman Gerência de Tecnologia 
Educacional Marcio A. Wecker Gerência de Produção Digital e Recursos Educacionais Digitais Diogo R. Garcia 
Supervisora de Produção Digital Daniele Correia Supervisora de Design Educacional e Curadoria Indiara Beltrame
Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de 
Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino 
de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Av. Guedner, 1610, Bloco 4 Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360 
Impresso por: 
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. 
Núcleo de Educação a Distância. FREITAS, Janaina Aparecida 
de.
Engenharia de Requisitos. Janaina Aparecida de Freitas. 
Maringá - PR: Unicesumar, 2022. 
184 p.
ISBN 978-85-459-2124-0 
“Graduação - EaD”. 
1. Engenharia 2. Requisitos 3. Software. 4. EaD. I. Título. 
CDD - 22 ed. 620 
FICHA CATALOGRÁFICA
Reitor 
Wilson de Matos Silva
A UniCesumar celebra os seus 30 anos de história 
avançando a cada dia. Agora, enquanto Universidade, 
ampliamos a nossa autonomia e trabalhamos diaria-
mente para que nossa educação à distância continue 
como uma das melhores do Brasil. Atuamos sobre 
quatro pilares que consolidam a visão abrangente 
do que é o conhecimento para nós: o intelectual, o 
profissional, o emocional e o espiritual.
A nossa missão é a de “Promover a educação de 
qualidade nas diferentes áreas do conhecimento, for-
mando profissionais cidadãos que contribuam para o 
desenvolvimento de uma sociedade justa e solidária”. 
Neste sentido, a UniCesumar tem um gênio impor-
tante para o cumprimento integral desta missão: o 
coletivo. São os nossos professores e equipe que 
produzem a cada dia uma inovação, uma transforma-
ção na forma de pensar e de aprender. É assim que 
fazemos juntos um novo conhecimento diariamente.
São mais de 800 títulos de livros didáticos como este 
produzidos anualmente, com a distribuição de mais 
de 2 milhões de exemplares gratuitamente para nos-
sos acadêmicos. Estamos presentes em mais de 700 
polos EAD e cinco campi: Maringá, Curitiba, Londrina, 
Ponta Grossa e Corumbá, o que nos posiciona entre 
os 10 maiores grupos educacionais do país.
Aprendemos e escrevemos juntos esta belíssima 
história da jornada do conhecimento. Mário Quin-
tana diz que “Livros não mudam o mundo, quem 
muda o mundo são as pessoas. Os livros só 
mudam as pessoas”. Seja bem-vindo à oportu-
nidade de fazer a sua mudança!
Tudo isso para honrarmos a 
nossa missão, que é promover 
a educação de qualidade nas 
diferentes áreas do conhecimento, 
formando profissionais 
cidadãos que contribuam para 
o desenvolvimento de uma 
sociedade justa e solidária.
Janaina Aparecida de Freitas
Possui graduação em Informática pela Universidade 
Estadual de Maringá (2010) e especialização em MBA em 
Teste de Software pela Uniceuma (2012). Atualmente, cur-
sa o Programa de Mestrado em Ciência da Computação 
na Universidade Estadual de Maringá (UEM), também é 
graduanda em Letras Português/Inglês na Unicesumar. 
Atua como professora mediadora, professora conteudis-
ta em gravação de aulas ao vivo e em gravação de aulas 
conceituais nos cursos do NEAD – Núcleo de Educação a 
Distância da Unicesumar, para os cursos de graduação de 
Sistemas para Internet, Análise e Desenvolvimento de Sis-
temas, Gestão da Tecnologia da Informação e Engenharia 
de Software, nas disciplinas de Engenharia de Software, 
Design Gráfico, Tópicos Especiais, Gerenciamento de Soft-
ware, Design de Interação Humano-Computador, Projeto 
Implementação e Teste de Software, há três anos. Além 
disso, tem experiência na iniciativa privada, na área de 
Análise de Sistemas e Testes de Software.
https://apigame.unicesumar.edu.br/qrcode/12909
Prezado(a) aluno(a), seja bem-vindo(a) à disciplina de Engenharia de Requisitos. Este li-
vro foi desenvolvido para você, que fica encantado(a) com as inúmeras funcionalidades 
que os softwares oferecem aos usuários. Com base nisso, quero te convidar a pensar 
sobre algumas provocações fundamentais:
 ■ Por que entender os requisitos de um problema ou de uma necessidade de um 
cliente, está dentre uma das tarefas mais difíceis que o engenheiro de software 
enfrenta no mercado de trabalho?
 ■ Conhecer os conceitos fundamentais da nossa área — os tipos de requisitos 
de software, a priorização e, depois, a maneira de organizar os requisitos em 
um documento de requisitos de software — torna mais fácil a solução para 
resolver este problema?
Com o objetivo de te auxiliar na busca por estas respostas a essas provocações 
fundamentais que, aliás, julgo necessárias para você entender a nossa disciplina, pro-
curei abordar assuntos interessantes e importantes que te ajudarão a entender como 
a Engenharia de Software é importante e como ela está presente no nosso dia a dia, em 
tudo o que usamos. Afinal, é tão difícil entender, claramente, o que o cliente deseja? E 
este questionamento nos faz pensar: por que o cliente não sabe o que é necessário, a 
partir do momento que é ele quem está solicitando o sistema?
A resposta é: muitos usuários finais não têm bom entendimento das características 
e funcionalidades necessárias ao sistema, dificultando o entendimento, por parte do 
engenheiro de software, do que o cliente, realmente, deseja que seja desenvolvimento.
Então, para resolver esta dificuldade, recomendo entender os conceitos e definições 
sobre a Engenharia de Requisitos. Desse modo, o ideal é compreender como ela está 
inserida dentro da Engenharia de Software bem como entender os processos do ciclo 
de vida do software e aprofundar-se no conhecimento da atividade de especificação 
de software. Por quê? Pelo fato de esta atividade ser, também, conhecida como Enge-
nharia de Requisitos, a qual é o processo de descobrir, analisar, documentar e verificar.
Dentro deste aprofundamento, te convido a ler a primeira unidade, onde abordei os 
conceitos introdutórios da Engenharia de Requisitos e a sua importância no processo de 
ENGENHARIA DE REQUISITOS
desenvolvimento de software. É importante que você compreenda este início, entenda 
que temos tipos de requisitos e que eles devem ser priorizados, depois, organizados 
dentro de um Documento de Requisitos de Software.
Sabe por que isso é importante? Porque esse documento de requisitos será utiliza-
do por outras equipes dentro da empresa, como: desenvolvedores, programadores, 
arquitetos de software, testadores, implantadores e o pessoal do suporte. Eles depen-
dem da clareza e do suficiente detalhamento, para cumprir com a sua função, a qual 
é desenvolver o software solicitado pelo cliente.A fim de continuarmos na nossa jornada de busca pelas respostas, te instigo 
a partir para a segunda unidade, na qual abordei os processos e as atividades respon-
sáveis por garantir a especificação de bons requisitos de software. É aqui que você 
aprenderá a respeito dos processos da Engenharia de Requisitos, a como realizar o 
levantamento e a análise de Requisitos de Software. É importante estar a par de todo 
esse processo, para que você não tenha sustos com o cliente falando: “você não en-
tendeu o que eu disse, pois o que eu disse não era o que eu quis dizer”. Além disso, 
é necessário compreender como são a verificação e a validação dos Requisitos de 
Software e, também, como realizar a especificação desses requisitos. 
Preparado(a) para continuar na busca por respostas? Seguindo: na terceira unidade, 
você aprenderá sobre as fontes de informação usadas na realização do levantamento 
dos requisitos de software. Fontes de informação? Sim, entender de onde vem as infor-
mações, a fim de realizar uma coleta de requisitos, durante o desenvolvimento de um 
software, e a coleta inicia-se pela identificação de quais fontes de informação podem 
ser usadas, para compreender as necessidades dos clientes e a forma de interagir com 
eles. O processo de coleta dos requisitos tem, como objetivo, definir e documentar as 
características dos produtos e serviços do projeto que satisfarão às necessidades e às 
expectativas dos usuários do sistema. Com o intuito tanto de compreender quanto 
interagir com o cliente e usuário, você precisa conhecer algumas técnicas de coleta de 
requisitos de software e como as selecionar de acordo com o contexto do que será 
desenvolvido. 
Em seguida, o que fazer com esse levantamento de requisitos? É necessário que 
você especifique os requisitos de software. Na quarta unidade, você aprenderá como 
realizar uma especificação de requisitos funcionais, utilizando os Casos de Uso e His-
tórias de Usuário, além de realizar a especificação de requisitos para um cenário de 
negócios e, depois, aplicar indicadores a fim de avaliar esses requisitos, por meio de 
critérios de qualidade de requisitos de software.
Espero que você esteja conseguindo chegar a alguma resposta às aprovações ge-
radas! Bem, desenvolver um sistema é algo que exige a interpretação bem como a de-
dução do que o cliente quer, e você viu que isso nem sempre é fácil. Agora, te provoco 
mais: como resolver isso? Você aprendeu várias formas e técnicas de levantamento de 
requisitos e como os documentar. E se eu te falar que esses requisitos podem mudar 
ao longo do desenvolvimento do sistema? Mais assustador ainda, concorda? 
E tenha uma certeza: os requisitos mudam por várias razões, por exemplo: o clien-
te, às vezes, não sabe o que deseja, pois, leis e normas do negócio se alteram ou o 
cliente quer algum recurso tecnológico novo no sistema. Desse modo, como ficam os 
requisitos coletados e aprovados? A resposta é que eles precisam ser gerenciados. 
Aqui, incentivo você a fazer uma imersão na Unidade 5, para entender como funciona 
o gerenciamento de requisitos e como realizar a rastreabilidade de requisitos e o con-
trole de mudanças, além de como construir uma matriz de rastreabilidade. No final, 
você entenderá a maneira de preencher um template da matriz de rastreabilidade de 
requisitos de software. 
Assim, convido você, caro(a) aluno(a), a entrar nesta jornada com empenho, dedi-
cação e muita sede de conhecimento. Boa leitura e ótimos estudos!
IMERSÃO
RECURSOS DE
Ao longo do livro, você será convida-
do(a) a refletir, questionar e trans-
formar. Aproveite este momento.
PENSANDO JUNTOS
NOVAS DESCOBERTAS
Enquanto estuda, você pode aces-
sar conteúdos online que amplia-
ram a discussão sobre os assuntos 
de maneira interativa usando a tec-
nologia a seu favor.
Sempre que encontrar esse ícone, 
esteja conectado à internet e inicie 
o aplicativo Unicesumar Experien-
ce. Aproxime seu dispositivo móvel 
da página indicada e veja os recur-
sos em Realidade Aumentada. Ex-
plore as ferramentas do App para 
saber das possibilidades de intera-
ção de cada objeto.
REALIDADE AUMENTADA
Uma dose extra de conhecimento 
é sempre bem-vinda. Posicionando 
seu leitor de QRCode sobre o códi-
go, você terá acesso aos vídeos que 
complementam o assunto discutido.
PÍLULA DE APRENDIZAGEM
OLHAR CONCEITUAL
Neste elemento, você encontrará di-
versas informações que serão apre-
sentadas na forma de infográficos, 
esquemas e fluxogramas os quais te 
ajudarão no entendimento do con-
teúdo de forma rápida e clara
Professores especialistas e convi-
dados, ampliando as discussões 
sobre os temas.
RODA DE CONVERSA
EXPLORANDO IDEIAS
Com este elemento, você terá a 
oportunidade de explorar termos 
e palavras-chave do assunto discu-
tido, de forma mais objetiva.
Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar 
Experience para ter acesso aos conteúdos on-line. O download do 
aplicativo está disponível nas plataformas: Google Play App Store
https://apigame.unicesumar.edu.br/qrcode/3881
APRENDIZAGEM
CAMINHOS DE
1 2
3 4
5
FUNDAMENTOS 
DA 
ENGENHARIA 
DE REQUISITOS
11
PROCESSOS DA 
ENGENHARIA 
DE REQUISITOS
51
81
TÉCNICAS DE 
ELICITAÇÃO DE 
REQUISITOS DE 
SOFTWARE
117
ESPECIFICAÇÃO 
DE REQUISITOS 
DE SOFTWARE
149
GERENCIAMENTO 
DE REQUISITOS 
DE SOFTWARE
1Fundamentos da Engenharia de 
Requisitos
Esp. Janaina Aparecida de Freitas
Nesta unidade, você conhecerá os conceitos introdutórios da Engenha-
ria de Requisitos e a sua importância no processo de desenvolvimen-
to de software, além disso, detalharemos os conceitos fundamentais 
e as etapas para compreender esta área. Também conheceremos e 
compreenderemos os tipos de Requisitos de Software e como reali-
zar a priorização, depois, como os organizar em um Documento de 
Requisitos de Software.
UNIDADE 1
12
Você já parou para pensar por que é tão difícil entender, claramente, o que o 
cliente deseja? Uma das situações tidas como o pior pesadelo de um engenheiro 
de software é quando o cliente fala: “você não entendeu o que eu disse, pois o que 
eu disse não era o que eu quis dizer” e, ainda, isso acontecer no final do projeto. 
 Mas, afinal de contas, o cliente não sabe o que é necessário? Os usuários 
finais não deveriam ter bom entendimento das características e funcionalidades 
que o sistema deveria possuir? Surpreendentemente, em muitos casos, a resposta 
a estas perguntas é “não”. Porque, mesmo se os clientes e usuários finais fossem 
explícitos quanto às suas necessidades em relação a um sistema, elas mudariam 
ao longo do projeto e, muitas vezes, eles não têm o conhecimento técnico para 
estabelecer a melhor solução ao problema que querem resolver.
 Entender os requisitos de um problema ou de uma necessidade de um cliente 
é uma das tarefas mais difíceis enfrentadas pelo engenheiro de software, pois 
há muitas dificuldades para fazer o levantamento das necessidades do cliente e 
para entender as informações por ele transmitidas. Devido a essas dificuldades, 
os requisitos são registrados de forma desorganizada e pouco tempo é investido 
na organização ou gerenciamento dessas informações, portanto, quando as mu-
danças vêm, o cenário torna-se mais assustador, mesmo entre gerentes e desen-
volvedores experientes.
A fim de entender melhor como este panorama pode ser assustador, contarei 
uma situação que aconteceu comigo. Na época, estava trabalhando como analista 
de sistemas em uma empresa que desenvolvia sistemas para autopeças, os quais 
eram customizados de acordo com as necessidades de seus clientes, com isso, 
ocorriam muitas mudanças, em função de alterações tributárias ou por causa 
da inclusão de novas tecnologias que estavam surgindo ou de novas funciona-
lidades. Um dos clientes de uma empresa de autopeças importadas solicitou a 
inclusão de uma nova funcionalidade no módulo financeiro do sistema, na tela 
do Contas a Receber. 
Realizamos uma reunião com o cliente, paraque ele explicasse a nova fun-
cionalidade a ser implementada. Ele explicou que queria um cálculo de juros 
simples em cima de cheques emitidos pelos clientes para pagamento das contas e 
dívidas. Essa reunião foi gravada e, no final, escrevemos uma ata, a qual o cliente 
leu e assinou, estando de acordo e autorizando a implementação.
Após a implementação da nova funcionalidade no módulo financeiro, foram 
realizados os testes de aceite pelo cliente, mas, para a nossa surpresa, o cálculo 
13
de juros estava errado. Como a reunião havia sido gravada, ela foi revisada, jun-
tamente, com o cliente, então, ele disse: “vocês entenderam errado, pois não era 
o que eu quis dizer, pois o que eu disse não era o que eu queria que fosse feito”. 
Como assim? Na tentativa de entender o que o cliente queria e não soube explicar, 
pedimos que ele exemplificasse, no papel, como calculava os juros. Surpreenden-
temente, era cálculo de juros composto e não simples, neste caso, o cliente não 
tinha conhecimento técnico para estabelecer a melhor solução ao problema o 
qual ele desejava resolver.
Agora, imagine que você é novo(a) em uma empresa de desenvolvimento de 
software e não conhece nem a empresa, nem os produtos que ela desenvolve. Você 
foi contratado(a) para substituir o analista de sistemas, porém esta pessoa, além 
de não ter cumprido o aviso prévio, sequer se preocupou em deixar explicadas a 
rotina e as atividades da função. 
Eis que surge uma reunião de emergência para a verificação de problemas ocor-
ridos com a última atualização do sistema de um cliente, então, você percebe o 
seguinte: o seu gerente pensa que você e o antigo colaborador são a mesma pessoa! 
Ele começa a te fazer várias perguntas sobre os requisitos alterados na última versão.
UNICESUMAR
UNIDADE 1
14
O que você faria diante de um cenário assustador como este? Registre, em seu 
Diário de Bordo, quais atitudes você tomaria nesta situação. Pegue, como exem-
plos, situações as quais você já viveu em sua vida profissional ou aquelas viven-
ciadas por seus amigos. 
A princípio, o cenário apresentado parece preocupante, mas, se você conhece 
os conceitos fundamentais sobre a Engenharia de Requisitos — os tipos de requi-
sitos de software, a priorização e como realizar a organização dos requisitos em 
um documento próprio para isso — a solução começa a surgir. 
Se a empresa e o antigo colaborador elaboraram uma documentação voltada 
às funcionalidades incluídas, utilize-a junto com o seu conhecimento, então, você 
conseguirá resolver a situação!
15
Para você entender o quanto a Engenharia de Requisitos é relevante durante o 
desenvolvimento de um software, é necessário identificar em qual momento ela 
se encaixa no contexto da Engenharia de Software. Portanto, refrescarei a sua 
memória relembrando, rapidamente, alguns conceitos fundamentais do processo 
de software e, depois, contextualizarei a Engenharia de Requisitos.
Atividades fundamentais do processo de software
Durante a produção de um software, são necessárias diversas fases/etapas, as quais 
são compostas por várias tarefas. Este conjunto de fases/etapas chama-se processo 
de software. Ele deve, sempre, cumprir todas os estágios estabelecidos para ele.
Mas, o que é um processo de software? Ele é considerado um conjunto 
de atividades/tarefas necessárias para definir, desenvolver, testar e manter um 
produto de software de alta qualidade. É uma abordagem adaptável cuja intenção 
é, sempre, entregar um software, com qualidade, dentro do prazo e seguindo o 
orçamento estipulado.
Atividade: é considerada um esforço para atingir um objetivo amplo. É uti-
lizada independentemente do campo de aplicação, do tamanho do projeto 
ou da sua complexidade.
Ação: envolve um conjunto de tarefas que resultam em um artefato.
Tarefa: concentra-se em um objetivo bem definido, produzindo um re-
sultado tangível.
Segundo Pressman e Maxim (2021, p. 20), o processo de software é definido como 
“uma metodologia para as atividades, ações e tarefas necessárias para desenvolver 
um software de alta qualidade”. Os objetivos desse processo são: (i) definir quais 
atividades serão executadas ao longo do projeto; (ii) quando, como e por quem 
tais atividades serão executadas (Figura 1). 
UNICESUMAR
UNIDADE 1
16
A Figura 2, a seguir, mostra a representação de um processo geral.
Quais ou o que Quando Como Quem
Descrição da Imagem: ilustração que mostra a representação dos objetivos do processo de software. 
A imagem do notebook representa “quais” atividades ou “o que” será realizado; a imagem do relógio 
representa “quando” as atividades serão executadas; a imagem da engrenagem representa “como” serão 
desenvolvidas; a imagem de “personas” representa “quem” as realizará.
Figura 1 - Representação dos objetivos do processo de software / Fonte: a autora 
Melhore
Pergunte
Imagine
Planeje
Crie
Descrição da Imagem: ilustração que mostra a representação de um processo geral, onde temos cinco 
etapas indicadas por retângulos, em sentido horário. A primeira etapa é “Pergunte”, seguida por “Imagine”, 
depois, “Planeje”, em seguida, “Crie”, fechando com a etapa “Melhore”. 
Figura 2 - Representação de um processo geral / Fonte: a autora.
17
Temos, na Figura 2, a representação de um processo geral com cinco etapas, 
nesta ordem: 
1. Pergunte: etapa a qual busca identificar qual o problema ou a necessidade 
do cliente. 
2. Imagine: aqui, são criadas algumas soluções, algumas alternativas à ne-
cessidade.
3. Planeje: corresponde ao momento de projetar ou modelar o que é ne-
cessário para a próxima etapa.
4. Crie: nesta etapa, a solução planejada é produzida.
5. Melhore: a solução é validada e testada. 
Para um processo ser considerado eficaz, segundo Pressman e Maxim (2021), 
devemos considerar: (i) as relações entre as atividades a serem desenvolvidas; (ii) 
os artefatos que serão produzidos durante o desenvolvimento; (iii) as ferramentas 
as quais, durante o desenvolvimento, poderão ser úteis; (iv) os procedimentos 
que serão necessários; (v) a habilidade, o treinamento e a motivação da equipe 
do projeto. 
Os processos devem ser definidos caso a caso, considerando as especificações 
da aplicação a ser desenvolvida, a tecnologia a ser adotada na sua construção, a 
organização de onde o produto será desenvolvido e as características da equipe 
de desenvolvimento. Além disso, temos alguns fatores passíveis de influenciar a 
definição de um processo, como: o tipo de software a ser desenvolvido, o para-
digma adotado, qual o domínio da aplicação e quais os tamanho e complexidade 
da aplicação. 
UNICESUMAR
UNIDADE 1
18
A Figura 3, a seguir, apresenta a visão das fases de um projeto. 
Domínio do
problema
MUNDO
REAL
Análise e
especi
cação
de requisitos
(o quê?)
Domínio da
solução
MUNDO
COMPUTACIONAL
Projeto (como?)
Implementação e
Validação
Descrição da Imagem: a ilustração representa as fases de um projeto, onde estão o mundo real e o 
mundo computacional. No mundo real, há o domínio do problema, no qual são realizadas a análise e 
a especificação de requisitos, ou seja, a pergunta: o quê? No mundo computacional, há o domínio da 
solução, no qual são realizadas a implementação e a validação. A ligação entre eles é a fase do projeto.
Figura 3 - Fases do projeto / Fonte: a autora.
 Então, como identificamos o domínio do problema? A seguir, algumas perguntas 
que podem ajudar o engenheiro de software a identificar esse domínio:
1. Que informação deve ser processada?
2. Quais função e desempenho são desejados?
3. Que comportamento deve ser esperado do sistema?
4. Quais interfaces devem ser estabelecidas?
19
5. Quais são as restrições de projeto?
6. Quais critérios de validação serão usados?
Depois de ter identificado o domínio do problema, precisamos pensar em como 
identificar o domínio da solução a ser desenvolvida. A seguir, apresentamos al-
gumas perguntas para ajudar o engenheiro de software a identificar o domínio 
da solução:
1. Como os dados devem ser?2. Como a função deve ser implementada dentro da arquitetura do software? 
3. Como os detalhes dos procedimentais devem ser implementados?
4. Como as interfaces devem ser caracterizadas?
5. Como o projeto deve ser traduzido em linguagem de programação?
Existe, na literatura, uma variação de atividades/tarefas do processo de software, 
mas todos envolvem cinco atividades fundamentais (Figura 4). 
UNICESUMAR
UNIDADE 1
20
 A seguir, apresentamos a descrição das atividades fundamentais do processo 
de software. 
Especificação de software: fase em que são definidas as funcionalidades 
do software e as restrições sobre as suas operações.
Projeto e implementação de software: nesta fase, são definidas quais 
funcionalidades serão desenvolvidas/implementadas para obter um pro-
duto final executável e de acordo com as especificações fornecidas pelo 
cliente.
Especi�cação
Projeto
Implementação
Validação
Evolução
Descrição da Imagem: a ilustração representa as atividades fundamentais do processo do software, por 
meio de retângulos, deles saem setas que apontam para os retângulos seguintes. No primeiro retângulo, 
há a fase de especificação, em seguida, o segundo retângulo, correspondente à fase de projeto, depois, o 
terceiro retângulo, que é a fase de implementação, a seguir, o quarto e quinto retângulo, respectivamente, 
as fases de validação e de evolução.
Figura 4 - Atividades fundamentais do processo de software / Fonte: a autora. 
21
Validação de software: fase na qual o software passa por validações e 
verificações com o objetivo de garantir que ele faça o que o cliente solicitou.
Evolução de software: fase em que são atendidas as mudanças possíveis 
de ocorrer durante o ciclo de vida do software, por exemplo, novos requi-
sitos, correções de erros ou atendimento às regulamentações do negócio. 
Todas estas atividades são a base sobre a qual o processo de desenvolvimento deve 
ser construído. Para Sommerville (2018), processos de software são complexos 
e criativos, pois dependem de pessoas para tomar decisões, fazer julgamentos e 
planejamento. 
Você deve estar pensando: qual o processo ideal e como o usar? Ele não existe, 
por isso, muitas empresas realizam adaptações e desenvolvem os seus próprios pro-
cessos de desenvolvimento de software. Processos possuem uma abordagem adap-
tável e vão evoluindo com vistas a tirar o melhor proveito da capacidade da equipe 
bem como das características específicas do sistema que está sendo desenvolvido. 
Embora não exista um modelo “ideal”, os processos de software têm a capa-
cidade de serem melhorados pela padronização, o que auxilia na comunicação 
mais efetiva e na redução no período de treinamento, além de abrir possibilidades 
à implantação de processos automatizados.
Nesta disciplina, o objetivo é aprofundar o conhecimento da atividade de 
especificação de software, a qual estabelece quais funções são requeridas pelo 
software e quais são as restrições sobre a operação e o desenvolvimento dele, 
ou seja, o processo de descobrir, analisar, documentar e verificar é chamado de 
Engenharia de Requisitos. 
A Engenharia de Requisitos, de acordo com Pressman e Maxim (2021, p. 
102): “fornece a todas as partes um entendimento escrito do problema. Os arte-
fatos podem incluir: cenários de uso, listas de funções e características e modelos 
de análise”. A Engenharia de Requisitos constrói uma ponte entre o projeto e a 
elaboração do software, porém, como construímos essa ponte? 
É possível que essa construção se inicie quando conversamos com os envol-
vidos no projeto — gerentes, clientes e usuário — pois são definidas, junto com 
eles, as necessidades do negócio, a descrição dos cenários de usuários, a definição 
das funções bem como os recursos e restrições do projeto.
UNICESUMAR
UNIDADE 1
22
 “ Porém, independentemente do ponto de partida, a jornada pela ponte nos leva bem à frente no projeto, permitindo que examine-mos o contexto do trabalho de software a ser realizado; as neces-
sidades específicas a que o projeto e a construção devem atender; 
as prioridades que orientam a ordem na qual o trabalho deve ser 
concluído; e as informações, funções e comportamentos que terão 
um impacto profundo no projeto resultante (PRESSMAN; MA-
XIM, 2021, p. 103).
Com o intuito de compreender a Engenharia de Requisitos, precisamos, antes, 
entender o que são os requisitos: eles são descrições das funções e restrições 
geradas durante o processo de Engenharia de Requisitos. Um requisito com-
preende uma característica ou funcionalidade cujo sistema deve possuir ou 
uma restrição que deve atender a uma necessidade do usuário. É a parte mais 
crítica e propensa a erros no desenvolvimento de software. 
Os requisitos de um sistema, para Sommerville (2018, p. 57), “são as des-
crições do que o sistema deve fazer, os serviços que oferece e as restrições a seu 
funcionamento. Esses requisitos refletem as necessidades dos clientes para um 
sistema que serve a uma finalidade determinada”.
No podcast desta unidade, destaco a importância da En-
genharia de Requisitos no processo de desenvolvimento 
de software. Acesse já!
Por que é tão difícil entender os requisitos? Porque temos diferentes níveis de des-
crição. Vamos a um exemplo? Analise os Quadros 1, a seguir. Ele mostra a visão do 
usuário, quando esse mesmo usuário descreve a sua necessidade, e mostra, também, 
a visão do analista de sistemas, quando ele pensa na necessidade que foi descrita. 
https://apigame.unicesumar.edu.br/qrcode/12902
23
(a)
Visão do usuário
O sistema deve gerar relatórios mensais que mostram o custo dos medica-
mentos prescritos por clínica, durante cada mês.
 
(b)
Visão do analista
No último dia de cada mês, deve ser gerado um resumo dos medicamentos 
prescritos por clínica.
Um relatório por clínica deve ser gerado, listando o nome dos medicamen-
tos, o total de prescrições e o custo total. 
Quadro 1 (a) - Visões do usuário; Quadro 1 (b) - Visões do analista / Fonte: a autora. 
Você conseguiu perceber as diferenças? Sommerville (2018, p. 58) descreve que 
os requisitos “precisam ser escritos em diferentes níveis de detalhamento para 
que diferentes leitores possam usá-los de diversas maneiras”. Por isso, quando os 
requisitos não são declarados de forma precisa, costumam surgir vários proble-
mas, inclusive requisitos ambíguos que podem ser interpretados de diferentes 
maneiras pelos desenvolvedores e usuários do sistema. 
 Quem são os interessados no sistema? São os clientes, o público, os patroci-
nadores e as organizações executoras, ou seja, quaisquer pessoas ou organizações 
que executam ou sofrem alguma ação relacionada ao projeto a ser desenvolvido. 
São os chamados stakeholders, aqueles envolvidos, ativamente, no projeto ou 
cujos interesses são afetados, de forma positiva ou negativa, pela execução ou 
pelo término dele. Você deverá ouvi-los e interpretá-los, principalmente, durante 
a fase de levantamento de requisitos (SOMMERVILLE, 2018). Cada um deles 
tem uma visão diferente do sistema e cada um obtém diferentes benefícios (se o 
sistema é desenvolvido com êxito, ou, caso venha a fracassar, com riscos). 
UNICESUMAR
UNIDADE 1
24
Níveis de Requisito 
 De que maneira identificar os interessados? Esta tarefa é um pouco complexa, 
mas, a seguir, temos uma lista de classificação dos stakeholders.
Favoráveis: contribuem ao sucesso do projeto, demonstram interesse e 
responsabilidade. 
Neutros: não possuem influência e não estão interessados nos resultados 
do projeto.
Contrários: acreditam que o projeto prejudica os seus interesses, então, 
criam empecilhos para o andamento dele.
Sabotadores: de difícil identificação. Geralmente, são espiões e/ou concor-
rentes.
Quadro 2 - Lista de classificação dos stakeholders / Fonte: adaptado de Sommerville (2018 
Níveis de Requisito 
25
Níveis de Requisito 
Níveis de Requisito 
Agora, você aprenderá a respeito dos níveis de requisitos, isto é, a maneira como 
eles serão escritos no documento ea quem se destinam, conforme o Quadro 3. 
Níveis de requisitos
Requisitos do usuário
Destinam-se às pessoas envolvidas no 
uso e na aquisição do sistema. Devem 
ser escritos usando linguagem natural, 
tabelas e diagramas, de modo que sejam 
compreensíveis.
Requisitos do sistema
Destinam-se a comunicar, de modo 
preciso, as funções que o sistema deve 
fornecer. São escritos em linguagem 
estruturada ou em linguagem baseada 
em alguma linguagem de programação. 
São divididos em dois tipos: requisitos 
funcionais (descrevem as maneiras como 
um produto deve se comportar) e requi-
sitos não funcionais (também conhecidos 
como atributos de qualidade, descrevem 
as características gerais do software).
Regra de negócio 
São declarações, orientações e restrições 
relacionadas à maneira como a empresa 
conduz ou opera o seu negócio. São os 
requisitos de domínio. 
Níveis de Requisitos 
Quadro 3 - Níveis de requisitos / Fonte: adaptado de Sommerville (2018).
UNICESUMAR
UNIDADE 1
26
 Depois de conhecer os níveis de requisitos, veremos como eles costumam ser 
classificados. Os requisitos de software são, frequentemente, classificados como 
Requisitos Funcionais (RFs), Requisitos Não Funcionais (RNFs) e Requisitos de 
Domínio/Negócio (RDs). 
Começarei a falar sobre os Requisitos Funcionais (RFs), os quais dizem 
respeito à definição das funções que um sistema ou um componente de sistema 
deve fazer (entradas e saídas). Os Requisitos Funcionais referem-se a uma re-
quisição — por parte do cliente — de uma funcionalidade que o software deverá 
atender ou realizar, isto é, a exigência, a solicitação, o desejo, a necessidade do 
cliente, cujo software a ser desenvolvido precisará materializar. De acordo com 
Sommerville (2018, p. 59), os RFs são:
 “ Os requisitos funcionais de um sistema descrevem o que ele deve fazer. Eles dependem do tipo de software a ser desenvolvido, de quem são seus possíveis usuários e da abordagem geral adotada 
OLHAR CONCEITUAL
Nível de Generalização
Alto
Detalhamento Especí�co
Regra
de Negócio
Requisitos
do Usuário
Requisitos de Sistema
Escopo do Projeto
Objetivos de Negócio
(Requisitos de Domínio)
Solicitações do Cliente
Necessidades dos usuário
("dores" e Processos do usuário)
Requisitos Funcionais
e Não Funcionais
27
pela organização ao escrever os requisitos. Quando expressos como 
requisitos de usuário, os requisitos funcionais são normalmente 
descritos de forma abstrata, para serem compreendidos pelos usuá-
rios do sistema. No entanto, requisitos de sistema funcionais mais 
específicos descrevem em detalhes as funções do sistema, suas en-
tradas e saídas, exceções etc.
Para entender, listaremos alguns exemplos de Requisitos Funcionais (RFs):
[RF001] O sistema deve cadastrar médicos profissionais (entrada).
[RF002] O sistema deve emitir um relatório de clientes (saída).
[RF003] O sistema deve transferir um cliente da situação “em consulta” 
para “consultado”, quando esse cliente terminar de ser atendido (mudança 
de estado).
[RF004] O cliente pode consultar os seus dados no sistema.
Neste momento, você conhecerá Requisitos Não Funcionais (RNFs). Eles di-
zem respeito a restrições, aspectos de desempenho, interfaces com o usuário, 
confiabilidade, segurança, manutenibilidade, portabilidade e padrões.
Sempre que possível, os Requisitos Não Funcionais devem ser escritos, quan-
titativamente, a fim de serem, objetivamente, validados e testados. Os RNFs ex-
pressam as condições ou as especialidades cujo software deverá atender e, segun-
do Sommerville (2018, p. 62): 
 “ São requisitos que não estão diretamente relacionados com os servi-ços específicos oferecidos pelo sistema a seus usuários. Eles podem estar relacionados às propriedades emergentes do sistema, como con-
fiabilidade, tempo de resposta e ocupação de área. Uma alternativa a 
esse cenário seria os requisitos definirem as restrições sobre a imple-
mentação do sistema, como as capacidades dos dispositivos de E/S ou 
as representações de dados usadas nas interfaces com outros sistemas.
UNICESUMAR
UNIDADE 1
28
A seguir, alguns exemplos de Requisitos Não Funcionais (RNFs):
[RNF001] O sistema deve imprimir o relatório em até cinco segundos.
[RNF002] Todos os relatórios devem seguir o padrão de relatórios espe-
cificado pelo setor XYZ.
[RNF003] O sistema deve ser implementado em Java.
[RNF004] O sistema deve ser protegido para o acesso de usuários.
Os RNFs são, de modo geral, provenientes de características requeridas para o 
software, por exemplo, da organização que desenvolve o software ou de fontes 
externas. A Figura 5 mostra os tipos de Requisitos Não Funcionais, de acordo 
com Sommerville (2018).
29
A seguir, a descrição dos RNFs (Figura 5): 
 ■ Requisitos do produto: especificam ou restringem o comportamento do 
software. Exemplo: requisitos de desempenho (rapidez com que o sistema 
deve executar e quanta memória ele requer); requisitos de confiabilidade 
(estabelecem a taxa aceitável de falhas); requisitos de proteção e os requi-
sitos de usabilidade.
 ■ Requisitos organizacionais: são requisitos gerais de sistemas derivados 
das políticas e procedimentos da organização do cliente e do desenvol-
vedor. Exemplos: requisitos do processo operacional (definem como o 
sistema será usado); requisitos do processo de desenvolvimento (especi-
Requisitos
não funcionais
Requisitos
do produto
Requisitos
organizacionais
Requisitos
extremos
Requisitos
de usabilidade
Requisitos
de e�ciência
Requisitos de
dependabilidade
Requisitos de
segurança da
informação
(security)
Requisitos
regulatórios
Requisitos
éticos
Requisitos
ambientais
Requisitos
operacionais
Requisitos de
desenvolvimento
Requisitos
legislativos
Requisitos de
desempenho
Requisitos
de espaço Requisitos
contábeis
Requisitos de segurança (safety)
/segurança da informação (security)
Descrição da Imagem: a ilustração representa, no formato de um organograma com retângulos, a divisão 
dos tipos de Requisitos Não Funcionais, iniciando com os seguintes requisitos: do produto, organizacionais 
e externos. Ligados aos “Requisitos do produto” estão os requisitos de eficiência, usabilidade, dependabi-
lidade e de segurança da informação. Estão ligados aos “Requisitos externos” os requisitos regulatórios 
e éticos. Associados aos “Requisitos organizacionais” estão os requisitos ambientais, operacionais e de 
desenvolvimento. Aos “Requisitos de eficiência” estão ligados os requisitos de desempenho e espaço. 
Associados aos “Requisitos legislativos” estão os requisitos contábeis e de segurança da informação.
Figura 5 - Divisão dos tipos de Requisitos Não Funcionais / Fonte: adaptada de Sommerville (2018). 
UNICESUMAR
UNIDADE 1
30
ficam a linguagem de programação, o ambiente de desenvolvimento ou as 
normas de processo a serem usadas); requisitos ambientais (especificam 
o ambiente operacional do sistema).
 ■ Requisitos externos: são todos os requisitos derivados de fatores exter-
nos ao sistema e ao seu processo de desenvolvimento. Exemplos: requi-
sitos reguladores (definem o que deve ser feito para o sistema ser apro-
vado ao uso por um regulador, tal como um banco central); requisitos 
legais (devem ser seguidos para garantir que o sistema opere dentro da 
lei); requisitos éticos (asseguram que o sistema seja aceitável para os seus 
usuários e o público em geral).
Geralmente, os RNFs são mensuráveis, ou seja, para cada Requisito Não Funcio-
nal, devemos associar uma medida ou referência. 
A seguir, no Quadro 4, temos exemplos de métricas que são usadas para 
especificar os RNFs.
31
PROPRIEDADE EXEMPLO DE MÉTRICAS
Velocidade
 ■ Transações processadas/segundo
 ■ Tempo de resposta de usuário/evento
 ■ Tempo de atualização de tela
Facilidade de uso
 ■ Tempo de treinamento
 ■ Número de frames (telas) de ajuda
Confiabilidade
 ■ Tempo médio para falha
 ■ Probabilidade de indisponibilidade
 ■ Taxa de ocorrência de falhas
 ■ Disponibilidade
Robustez
 ■ Tempo de reinício após falha
 ■ Percentual de eventosque causam falhas
 ■ Probabilidade de corrupção de dados em 
caso de falha
Portabilidade
 ■ Percentual de declarações dependentes do 
sistema-alvo
 ■ Número de sistemas-alvo
Quadro 4 - Exemplos de métricas para especificar Requisitos Não Funcionais 
Fonte: Sommerville (2018, p. 63).
Você deve ter percebido que os Requisitos Funcionais descrevem as funcionalidades (o 
que o sistema faz), e os Requisitos Não Funcionais relacionam as especialidades ou restri-
ções do software (como o sistema é).
PENSANDO JUNTOS
Agora, você aprenderá sobre os Requisitos de Domínio/Negócio (RDs): são 
os requisitos derivados do domínio da aplicação. Descrevem as características do 
sistema e as qualidades que refletem a regra de negócio do cliente. Tais requisitos 
UNICESUMAR
UNIDADE 1
32
são derivados da especialidade na qual o software será implantado e podem ser 
novos Requisitos Funcionais ou alguma restrição de algum requisito existente 
ou algum cálculo específico, por exemplo, o cálculo de impostos ou de taxas 
específicas. 
Em uma empresa, o setor de RH possui incrementos e descontos específicos 
do seu domínio, por exemplo, férias, horas extras etc. Se a empresa tiver impos-
tos tributários, há cálculos e porcentagens específicas inerentes à sua aplicação: 
IPI, substituição tributária, ICMS, IPTU, ISS, entre outros (PIS, COFINS etc.). 
Devem ser expressos usando uma linguagem específica do domínio da aplicação.
Seguem alguns exemplos de Requisitos de Domínio (RDs):
[RD001] O cálculo da média final de cada aluno é dado pela fórmula: (Nota1 
* 2 + Nota2 * 3)/5.
[RD002] O valor do IPI é calculado em relação ao valor da nota fiscal da 
mercadoria despachada e pode, eventualmente, incluir valores sobre o 
frete e despesas acessórias (juros, taxas etc.).
[RD003] O cálculo de comissão dos vendedores é de 15% sobre o total 
líquido das vendas no mês.
 Na especificação de software, a imprecisão é a causa de muitos problemas da 
engenharia de software. Muitas vezes, ocorre a interpretação ambígua de um 
requisito de forma, para, de alguma maneira, simplifique-se a sua implementação 
ou pode ocorrer, também, de o requisito não ser a preferência do cliente, neste 
caso, é necessário estabelecer novos requisitos e fazer mudanças no sistema. Com 
isso, acontecem os atrasos de entrega, gerando aumentos nos custos.
33
Depois de ter aprendido sobre os requisitos, você deve estar pensando: qual a 
importância deles no projeto de software? A fim de te fazer entender, falarei, 
primeiro, da importância dos Requisitos Funcionais. 
Primeiramente, as funcionalidades do sistema existem, somente, para realizar 
Requisitos Funcionais, logo, sem eles, não há funcionalidades e, sem funciona-
OLHAR CONCEITUAL
Para entender a relação entre os requisitos, temos, a seguir, um infográfico do 
ciclo dos requisitos de software.
Requisitos do Software
Requisitos 
funcionais
Descrevem o 
que o software 
deve fazer
Requisitos não-funcionaisTarefas do 
usuário 
transferidas 
para o software
Restrições gerais
 que afetam como
 o software deve
 ser feito
Estabelecem níveis 
de serviço que 
se esperam para
 o software
Descrição da Imagem: a ilustração representa a relação entre os requisitos, mostrando, por meio de 
setas, o ciclo dos requisitos de software. É possível ver os Requisitos Funcionais, os quais são as tarefas 
do usuário transferidas para o software e descrevem o que o software deve fazer. Em seguida, estão os 
Requisitos Não Funcionais: estes são as restrições gerais que afetam como o software deve ser feito e 
estabelecem níveis de serviços esperados para o software.
Figura 6 - Requisitos do software / Fonte: adaptada de Sommerville (2018).
UNICESUMAR
UNIDADE 1
34
lidades, não há sistema, por isso, os RFs precisam ser bem detalhados, claros e 
com qualidade. 
Você deve estar pensando: “o que devemos entender como qualidade de 
um requisito?”. Pois bem, Requisitos Funcionais de qualidade precisam aten-
der a alguns atributos qualitativos específicos, tais como: unidade, completude, 
consistência, atomicidade, não ambiguidade, ser verificável e rastreável, possuir 
prioridade e tempo verbal. 
A seguir, o Quadro 5 mostra os atributos e exemplos de cada um. 
Atributos Descrição dos atributos
Unidade
O Requisito Funcional deve propor, apenas, uma 
única coisa, ou seja, não deve atender a mais de 
uma necessidade. 
Exemplo: o Requisito Funcional “cadastrar clien-
te” não é requisito unitário, pois, podemos ter 
vários tipos de clientes (pessoa física e pessoa 
jurídica). 
Completude
O Requisito Funcional deve ser autocontido, ou 
seja, deve ter um início, um meio e um fim. 
Exemplo: o Requisito Funcional “pagar fatu-
ra” não está completo, faltam partes. Agora, o 
Requisito Funcional “pagar fatura com cartão de 
débito para cliente pessoa jurídica” está comple-
to, com início, meio e fim.
Consistência
O Requisito Funcional não deve contradizer ou-
tro Requisito Funcional, isto é, se propõe a fazer 
a mesma coisa, mas cada um fazendo de forma 
diferente.
Atomicidade
O Requisito Funcional deve assumir, apenas, 
uma responsabilidade e, também, deve ser algo 
indivisível, não pode ser decomposto.
35
Atributos Descrição dos atributos
Não ambiguidade
O Requisito Funcional não pode ser ambíguo, ou 
seja, não pode propor algo que não é claro no 
que faz. 
Exemplo: o Requisito Funcional “imprimir relató-
rio” não diz muita coisa, pois imprimirá relatório 
do que e para quê? Agora, o Requisito Funcional 
“imprimir relatório de saldo da conta poupança 
do cliente pessoa física” já está completo e claro.
Verificável
O Requisito Funcional deve ser testável, isto é, 
validado, para saber se ele atende à necessida-
de do cliente. 
Rastreável
O Requisito Funcional é passível de ser rastreá-
vel no sistema, quando estiver funcionando e 
executável. 
Tempo verbal
O requisito deve fazer uso do tempo verbal no 
próprio nome, ou seja, ele refere-se a algo que 
será feito, uma ação a ser realizada pelo siste-
ma.
Exemplo: realizar, comprar, emitir, consultar, 
validar, acessar etc.
Quadro 5 - Lista de atributos de qualidade dos Requisitos Funcionais
Fonte: adaptado de Sommerville (2018). 
Mas, e a importância dos Requisitos Não Funcionais para o sistema? Com o 
objetivo de tornar tal assunto compreensível, descreverei um cenário hipotético. 
Exemplo 1
 ■ A empresa de transportes XYZ possui uma frota de 600 caminhões, mas 
eles não podem ficar esperando muito tempo no pátio, mesmo para saí-
rem dos armazéns de carga. A empresa solicitou que, no módulo de logís-
tica, todas as cargas devem ser liberadas em, no máximo, 15 minutos. Para 
isso, é emitido um documento de solicitação de liberação de carga, nele 
é anexado a nota fiscal eletrônica dos produtos contidos no caminhão.
UNICESUMAR
UNIDADE 1
36
Após a leitura do cenário hipotético, identifique os Requisitos Não Funcionais. 
Imagine que você tenha chegado ao seguinte RFN:
[RNF01] Requisito de Desempenho: tempo limite de, no máximo, 20 mi-
nutos para o processamento de solicitação de liberação de carga.
Depois da identificação do Requisito Não Funcional, você descobriu que os 
desenvolvedores responsáveis pela implementação do módulo de logística não 
deram a devida importância ao requisito não funcional (RNF01) e que esta ne-
cessidade de tempo de resposta da emissão da nota fiscal eletrônica será imple-
mentada, somente, no fim do projeto. 
Quando o módulo de logística da empresa de transporte ficou pronto, ini-
ciou-se a homologação das funcionalidades. E o que aconteceu? Quando ocorreu 
a primeira bateria de testes com o módulo, o sistema foi reprovado pelos usuários 
da área de logística da empresa, pois estava demorando 1 hora, em média, apenas 
para que o sistema processasse a solicitação de liberação de carga. Resultado? 
Sistema considerado inviável à produção, sendo necessário reestruturar toda a 
sua arquitetura, porque a performance do módulo de logística ficou muito ruim, 
não atendendo ao Requisito Não Funcional (RNF01).“Muitas empresas estão dispostas a trocar a qualidade e o compromisso com requisitos do 
software por uma implantação mais rápida do software de que necessitam. Essas empresas 
operam em um ambiente de mudanças rápidas, por isso, muitas vezes, é, praticamente, im-
possível obter um conjunto completo de requisitos de software estável. 
Os requisitos iniciais, inevitavelmente, serão alterados, pois os clientes acham impossível 
prever como um sistema afetará as práticas de trabalho, como interagirá com outros siste-
mas e quais operações do usuário devem ser automatizadas. Pode ser que os requisitos se 
tornem claros apenas após a entrega do sistema e à medida que os usuários ganhem expe-
riência. Mesmo assim, devido a fatores externos, os requisitos são suscetíveis a mudanças 
rápidas e imprevisíveis. Por exemplo, quando for entregue, o software poderá estar desatua-
lizado”. 
Fonte: Sommerville (2018, p. 38).
EXPLORANDO IDEIAS
37
Depois do fragmento de texto exposto no explorando ideias, você deve estar se 
perguntando: E os requisitos nas metodologias ágeis? Quando usamos meto-
dologia ágil, nos processos ágeis, os requisitos são considerados um “objetivo” 
ao invés de ser uma solicitação ou necessidade sobre o que deve ser feito. 
Conforme Pressman e Maxim (2021, p. 38), “[uma] das características mais 
convincentes da metodologia ágil é sua habilidade de reduzir os custos da mu-
dança no processo de software”, ou seja, as mudanças nos requisitos são consi-
deradas bem-vindas, mesmo que elas venham, tardiamente, durante o desen-
volvimento do software. Tal metodologia é passível de ser aplicada a qualquer 
processo de software, e a sua especificação ocorre durante todo ciclo de vida do 
desenvolvimento dele, inclusive há a participação efetiva do stakeholder. Este 
promove esclarecimentos imediatos, em caso de dúvidas. 
Existe uma filosofia por trás dos métodos ágeis e refletida no Manifesto Ágil, 
o qual, segundo Pressman e Maxim (2021), foi acordado, em uma reunião, por 
muitos dos principais desenvolvedores dessa metodologia. 
A seguir, veremos, na Figura 7, os valores do Manifesto Ágil.
VALORES DO MANIFESTO ÁGIL
Indivíduos e interações mais que processos e ferramentas
Softwares em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos 
Responder a mudanças mais que seguir um plano
Descrição da Imagem: a ilustração representa os valores do Manifesto Ágil, por meio de cinco retângulos 
que apresentam os textos mostrados, aqui, a seguir. O texto “Valores do Manifesto Ágil” funciona como 
título e dele sai uma seta apontando para baixo, em direção ao retângulo cujo texto é: “Mais indivíduos 
e interações do que processos e ferramentas”, seguido pelo retângulo com o texto “Mais softwares em 
funcionamento do que documentação abrangente”, seguido pelo retângulo com o texto “Mais colaboração 
com o cliente do que negociação de contratos”, depois, vê-se o retângulo com o texto “Mais respostas a 
mudanças do que seguir um plano”.
Figura 7 - Valores do Manifesto Ágil / Fonte: adaptada de Sommerville (2018).
UNICESUMAR
UNIDADE 1
38
Quando se usa um processo ágil, não é comum fazer um planejamen-
to completo de tudo o que precisa ser desenvolvido antes de iniciar 
a implementação do sistema. É feito o planejamento de incrementos 
— pedaços do software que são desenvolvidos aos poucos e entregues, 
constantemente, ao cliente —, afinal, o foco está no valor do produto 
de alta qualidade que será entregue e que, também, fornecerá valor de 
negócio.
E o time ágil? Para Sommerville (2018), os métodos ágeis dependem 
do fato de o time compreender os aspectos do sistema, sem a necessi-
dade de consultar a documentação. Mas, tem um problema: e se o time 
ágil for alterado? Ou se algum dos desenvolvedores sair do time? Sig-
nifica que todo o conhecimento implícito sobre os aspectos do sistema 
é perdido. Para os novos membros do time, é difícil construir/alterar 
sem ter uma documentação viável do sistema e dos seus componentes. 
Como especificar os requisitos na metodologia ágil? A especifica-
ção de Requisitos Funcionais é feita por meio da utilização de histórias 
de usuário (user stories), cujo objetivo principal é garantir ao time a 
capacidade de entender e responder, rapidamente, às necessidades do 
usuário. Quando histórias de usuário são utilizadas, produz-se menos 
documentação e, também, é mostrada, de forma mais rápida e eficiente, 
a evolução das necessidades do usuário, além de haver mais ajuda na 
descoberta de novos requisitos que possam ocorrer durante o desen-
volvimento do sistema. 
Neste momento, quero que você pense: qual a diferença entre as 
histórias de usuário e a descrição tradicional dos requisitos? A diferen-
ça entre elas está na comunicação verbal, porque a linguagem escrita 
pode ser, muitas vezes, imprecisa, e a interpretação do usuário e do 
desenvolvedor costumam não ser as mesmas. A especificação de um 
requisito usando histórias de usuário segue as mesmas recomendações 
de especificação das metodologias tradicionais, vistas anteriormente. 
Na Unidade 4, será explicada a especificação de requisitos utilizan-
do histórias de usuário. Não se preocupe, logo você chega lá.
39
“Os requisitos relacionados ao produto farão parte de um documento de especificação de 
requisitos ou artefato similar, como cartões com histórias de usuário nos métodos ágeis, 
enquanto os requisitos de processo e de projeto serão parte do plano de projeto ou artefa-
to que tenha função similar. Já requisitos de sistema se desdobrarão em requisitos relacio-
nados à parte física (hardware) e requisitos relacionados à parte de software, os quais po-
dem estar em um mesmo artefato, mas que se desdobrarão em implementações distintas”. 
Fonte: Reinehr (2020, p. 39)..
EXPLORANDO IDEIAS
Agora, pense na seguinte frase: “o que é mais importante e o que deve ser feito 
primeiro”. Então, como saber quais requisitos são mais importantes, isto é, qual 
dos requisitos deve ser implementado primeiro? A recomendação é analisar o 
que, realmente, é essencial ou urgente a ser implementado e, para isso, usa-se a 
Priorização de Requisitos de Software.
 Uma das melhores formas para decidir o que deve ser feito com os recursos 
em mãos é priorizar os requisitos. Em termos de método aplicado, a “grosso 
modo”, estamos falando de criar uma lista com os requisitos, definir uma priori-
UNICESUMAR
UNIDADE 1
40
dade para cada um, e os mais prioritários vão ao início da lista, os menos prio-
ritários, para o fim.
Imagine a situação: você desenvolveu um sistema cujo objetivo é controlar 
a venda de produtos. Nele, a emissão de Nota Fiscal Eletrônica ou de Cupom 
Fiscal está pronta, mas o módulo que realiza a venda, ou seja, o Pedido de Venda, 
ainda não. Após a priorização, é importante definir, com a mesma prioridade, 
uma ordem de execução aos requisitos. 
Como definir essa ordem de execução? De acordo com a literatura pesquisa-
da, a atribuição de prioridade dos requisitos é de três tipos: essencial, importante 
e desejável. 
 ■ Essencial: requisito sem o qual o sistema não entra em funcionamento. 
São os requisitos imprescindíveis, os quais devem ser disponibilizados na 
implantação do sistema.
 ■ Importante: requisito sem o qual o sistema entra em funcionamento, 
ainda de forma satisfatória. Não impedem a implantação do sistema, mas 
devem ser implementados o mais breve possível. 
 ■ Desejável: requisito que, embora não implementado, permite que o siste-
ma funcione de modo satisfatório, sem comprometer as funcionalidades 
básicas. É um requisito com a possibilidade de ser entregue em qualquer 
momento, sem prejuízo para os serviços oferecidos pelo sistema.
 Quando devemos priorizar os requisitos? A priorização acontece durante a de-
finição do escopo do sistema. Imagine que você tenha o escopo definido do seu 
projeto e começa o desenvolvimento, porém não priorizou nenhum requisito. 
Isso gera problemas no projeto bem como possíveis atrasosna entrega. 
Não priorize os requisitos, somente, no início do projeto, procure fazer isso 
quando ocorrer mudanças nos requisitos. Mas, para isso, o documento de re-
quisitos precisa ser bem elaborado e detalhado, além de atualizado, sempre que 
necessário. 
Talvez, você esteja se perguntando como registrar o que aprendeu, até aqui, 
sobre requisitos. Este registro é feito por meio de um documento chamado Do-
cumento de Requisitos de Software, cuja função é documentar o que foi acor-
dado entre quem solicita e quem desenvolve, estabelecendo, também, o escopo 
do software, ou seja, o conjunto de funcionalidades que ele deverá oferecer. Além 
de servir de referência a desenvolvimento, testes, manutenção e evolução do 
41
sistema (mudanças), esse documento garante, ainda, a rastreabilidade mínima 
dos requisitos, ao longo do ciclo de vida do software. 
O Quadro 6 mostra a lista de usuários do Documento de Requisitos de Software. 
Clientes do sistema: especificam os requisitos e os leem, para conferir 
se satisfazem às suas necessidades. Os clientes especificam mudanças nos 
requisitos.
Gerentes: usam o documento de requisitos para planejar uma proposta ao 
sistema e planejar o seu processo de desenvolvimento.
Engenheiros de sistema: usam os requisitos a fim de compreender qual 
sistema deve ser desenvolvido.
Engenheiros de testes: usam os requisitos com o intuito de desenvolver 
testes de validação do sistema.
Engenheiros de manutenção: usam os requisitos para entender o sistema 
e as relações entre as suas partes.
Quadro 6 - Lista de usuários do Documento de Requisitos de Software 
Fonte: Sommerville (2018, p. 110) 
Segundo Sommerville (2018, p. 109), os documentos de requisito “são essenciais 
quando: os sistemas têm o seu desenvolvimento terceirizado, times diferentes 
desenvolvem partes diferentes do sistema ou uma análise detalhada dos requisitos 
é obrigatória”. 
Mas, afinal, como documentar? Te convido a fazer uma busca pela internet, 
usando as palavras “documento de requisitos”, então, visualize o que aparece. 
Além de inúmeras páginas de conceitos, você se deparará com inúmeros modelos 
e templates sugeridos para a documentação. Qual escolher? O desafio entre os 
modelos sugeridos é decidir qual o modelo que melhor se adapta ao seu projeto, 
às suas empresa e equipe. 
Com tantos modelos, qual o nível certo para realizar a documentação? Em 
primeiro lugar, o documento deve ser capaz de garantir o entendimento dos 
stakeholders. Em segundo lugar, a equipe técnica precisa estar ciente de que esse 
documento é a única garantia que atende às solicitações do cliente, portanto, 
ele necessita estar, sempre, atualizado. Qual modelo ou padrão usar? Há vários 
modelos os quais são, também, adaptáveis. O ideal é você definir, junto com a 
UNICESUMAR
UNIDADE 1
42
equipe, qual o modelo ou padrão que utilizarão à documentação dos requisitos 
do projeto. O documento de requisitos deve ter: 
1. Escopo do software: a descrição do conjunto de funcionalidades que ele 
deverá ter e os atributos de qualidade que o sistema suportará bem como o con-
junto de características técnicas, ou seja, a descrição completa dos Requisitos 
Funcionais e Não Funcionais e de Domínio.
 2. O documento deve ser elaborado de maneira precisa, detalhada, consis-
tente e de acordo com as necessidades do cliente, além de ser compreensível por 
todos stakeholders, isto é, os interessados no sistema. 
3. Guia de referência para validação, verificação e testes, além de manutenção 
e evolução do sistema. 
O Quadro 7 mostra os itens para organizar o documento de requisitos, com 
base em um padrão IEEE genérico. No entanto as empresas podem adaptá-lo a 
usos específicos, de acordo com os seus processos. 
Itens Descrição
Prefácio
Define os possíveis leitores do docu-
mento e descreve o histórico de versões, 
incluindo uma justificativa à criação de 
uma nova versão e um resumo das mu-
danças feitas em cada versão.
Introdução 
Descreve as necessidades para o siste-
ma, em suma, as funções, e como ele 
funcionará com outros sistemas, além de 
descrever os objetivos gerais de negócio 
ou estratégicos da empresa. 
Glossário 
Define os termos técnicos usados no 
documento.
Definição de requisitos de 
usuário
Descreve os serviços fornecidos ao usuá-
rio. Esta descrição pode usar linguagem 
natural, diagramas ou outras notações 
compreensíveis para os clientes. 
43
Itens Descrição
Arquitetura do sistema
Apresenta a visão geral em alto nível da 
arquitetura do sistema previsto, mos-
trando a distribuição de funções entre os 
módulos do sistema. Componentes de 
arquitetura reusados devem ser desta-
cados.
Especificação de requisitos do 
sistema
Descreve, em detalhes, os Requisitos 
Funcionais e Não Funcionais. As inter-
faces com outros sistemas podem ser 
definidas.
Modelagem do sistema
Incluem modelos gráficos do sistema 
que mostram os relacionamentos entre 
os componentes do sistema, o sistema e 
o seu ambiente.
Evolução do sistema
Descreve quaisquer mudanças previstas, 
em decorrência da evolução de hardwa-
re e de mudanças nas necessidades do 
usuário etc. 
Apêndices 
Fornece informações detalhadas e 
específicas relacionadas à aplicação em 
desenvolvimento, além de descrições de 
hardware e banco de dados, por exem-
plo. Os requisitos de hardware definem 
as configurações mínimas ideais para o 
sistema. Requisitos de banco de dados 
definem a organização lógica dos dados 
usados pelo sistema bem como os rela-
cionamentos entre esses dados.
Índice 
Vários índices podem incluídos no do-
cumento. É possível haver, além de um 
índice alfabético normal, um índice de 
diagramas e de funções, entre outros 
pertinentes. 
Quadro 7 - Estrutura de um documento de requisitos / Fonte: Sommerville (2018, p. 111). 
UNICESUMAR
UNIDADE 1
44
As informações contidas em um documento de requisitos dependerão do tipo 
de software a ser desenvolvido e da metodologia que está sendo usada para o 
processo de desenvolvimento. O importante, independentemente do tipo de 
software, é incluir, no documento, conteúdo para todos os leitores e interessados 
serem capazes de encontrar e entender, facilmente, todas as informações acerca 
do sistema. 
“O nível de detalhes que você deve incluir em um documento de requisitos depende do 
tipo de sistema em desenvolvimento e do processo usado. Os sistemas críticos precisam 
ter requisitos detalhados, porque a segurança e a proteção devem ser analisadas em 
detalhes. Quando o sistema está sendo desenvolvido por uma companhia separada (por 
exemplo, através de outsourcing (terceirização), as especificações de sistema devem ser 
detalhadas e precisas. Se um processo interno de desenvolvimento iterativo é usado, o 
documento de requisitos pode ser muito menos detalhado e quaisquer ambiguidades 
podem ser resolvidas durante o desenvolvimento do sistema”. 
Fonte: Sommerville (2018, p. 110-111).
EXPLORANDO IDEIAS
A fim de concluir a nossa unidade, segue um exemplo prático de um template 
para o documento de requisitos, a ser utilizado na disciplina. Esse documento de 
requisitos é direcionado a um sistema online de gerenciamento de uma fictícia 
casa de apoio social (SGCA). 
NOVAS DESCOBERTAS
Minha recomendação de leitura é a obra Engenharia de Requisitos, o 
qual pode ser encontrado na Biblioteca Digital Unicesumar (BDU). 
Neste livro, a autora Sheila Reinehr aborda os elementos e as etapas 
do ciclo de vida da Engenharia de Requisitos. Por meio desta leitura, 
você aprofundará os conceitos aprendidos nesta unidade, por exem-
plo, a compreensão da diferença entre Requisitos Funcionais e Não Funcio-
nais, assim como os Requisitos de Domínio. 
45
DOCUMENTO DE REQUISITOS
SISTEMA SGCA
Histórico de revisões
Data Versão Descrição Responsável
10/01/2022 1.0
Especificação 
dos objetivos do 
documento
Janaina Freitas
15/01/2020 1.1
Especificação 
dos Requisitos 
Funcionais e 
Não Funcionais
Rafael Florindo
20/01/2022 2.0
Modificação do 
escopo geral 
Janaina Freitas1. Objetivos
O SGCA é um sistema online de gerenciamento de casas de apoio social. O ob-
jetivo dele é cadastrar, listar e relacionar as casas de apoio, visando a facilitar as 
contribuições e doações. 
 1.1. Objetivos do documento
Este documento tem, por objetivo, descrever e especificar os requisitos de um sis-
tema online de gerenciamento de casas de apoio social. Os seus leitores (usuários 
desse documento) são profissionais envolvidos no desenvolvimento e pessoas 
que tenham interesse em usar o sistema.
2. Escopo geral do produto
O SGCA é um sistema online que visa a possibilitar o cadastro de casas de apoio 
social da cidade, onde será possível visualizar qual tipo de público elas atendem, 
os projetos que desenvolvem e a de que modo fazer contribuições e doações. 
UNICESUMAR
UNIDADE 1
46
3. Convenções, termos e abreviações
 3.1 Termos e abreviações: 
 ■ SGCA – Sistema de gerenciamento online de casas de apoio social.
 ■ RF – Requisitos Funcionais.
 ■ RNF – Requisitos Não Funcionais.
 3.2 Convenções:
 A seguinte convenção foi adotada neste documento: 
 ■ Casas de apoio social: referem-se ao indivíduo/empresa cadastrado(a) ou 
não no sistema e que faz uso das funcionalidades oferecidas pelo sistema. 
4. Requisitos
 Descrever, de maneira geral, todas as funcionalidades do sistema.
4.1. Requisitos Funcionais
Preencher a tabela, a seguir, com as informações pertinentes a cada um dos requisitos:
RF: RF001 Efetuar login de usuário no sistema. UC: 001
PR: 
alta
Descrição/Ação: o sistema deve permitir a autenticação de usuário, por meio de nome 
de usuário e senha. Caso o usuário não se lembre de seu login ou senha, ele poderá 
recuperar os dados pelo botão “Esqueci a minha senha”. A partir disso, será pedido ao 
usuário que digite o e-mail, em seguida, serão encaminhados os dados para login. 
Entrada: informações de nome de usuário e senha.
Saída: login efetuado com sucesso.
Pré-condição: ter cadastro de usuário realizado, com sucesso, no sistema.
Pós-condição: autenticação de usuário efetuado, com sucesso, no sistema.
Stakeholder: usuário administrador do sistema.
47
 4.2 Requisitos Não Funcionais
RNF: RNF001 Usuários simultâneos. UC: 
PR: 
média
Descrição/Ação: o sistema deverá suportar o processamento multiusuário, ou seja, 
vários usuários poderão utilizar, ao mesmo tempo, o sistema. 
Entrada: informações de vários nomes de usuários e senhas.
Saída: login de vários usuários efetuados com sucesso.
Pré-condição: usuário com cadastro no sistema.
Pós-condição: não se aplica.
Stakeholder: usuário administrador do sistema.
5. Escopo não contemplado
No momento, não será desenvolvido: 
 ■ Os relatórios com as casas de apoio social cadastradas no sistema.
 ■ Atendimento a consultas de informações por meio de e-mail.
6. Aprovação
_______________________
Juscelino Kubitschek de Oliveira
Gerente de projeto
_______________________
Marechal Cândido Rondon
Analista de Requisitos
_______________________
Tancredo Neves
Cliente/Solicitante
 
Maringá, 2 de Dezembro de 2021
UNICESUMAR
UNIDADE 1
48
Convido você a assistir o vídeo, para aprender a criar um 
documento de requisitos, na prática, visando a absorver o 
conteúdo visto nesta unidade. O documento de requisitos 
que criaremos tem o objetivo de descrever e especificar 
os requisitos de um sistema online de gerenciamento de 
casas de apoio social. Acesse e aprenda na prática.
NOVAS DESCOBERTAS
Título: Engenharia de Software: Uma Abordagem Profissional
Autores: Roger S. Pressman e Bruce R. Maxim
Editora: AMGH
Sinopse: o objetivo deste livro é ser um guia para uma disciplina de 
Engenharia em fase de amadurecimento. Assim como as edições que a pre-
cederam, esta é voltada tanto a estudantes quanto a praticantes, servindo, 
também, como guia para profissionais da área e como introdução abran-
gente para estudantes no final do curso de graduação ou no primeiro ano 
de pós-graduação.
https://apigame.unicesumar.edu.br/qrcode/13147
Crie um Mapa Mental sobre os conceitos fundamentais da Engenharia de Requi-
sitos. O seu mapa deve conter as seguintes palavras-chaves:
 ■ Processo de Software
 ■ Engenharia de Requisitos
 ■ O que é um requisito
 ■ Requisitos de sistema
 ■ Requisitos de usuário
 ■ Requisitos de Domínio
 ■ Requisitos Funcionais 
 ■ Requisitos Não funcionais
 ■ Documento de Requisitos
Organize a ideia do seu Mapa Mental a partir das palavras-chaves propostas. É 
uma forma de você absorver bem como sintetizar os conceitos vistos nesta uni-
dade. Recomendo o uso da ferramenta gratuita GoConqr (www.goconqr.com).
http://www.goconqr.com
2Processos da Engenharia de 
Requisitos
Esp. Janaína Aparecida de Freitas
Caro(a) estudante, após ter aprendido sobre os fundamentos da En-
genharia de Requisitos e a sua importância no processo de desenvol-
vimento de software, agora, nesta unidade, você conhecerá os pro-
cessos e as atividades responsáveis por garantir a especificação de 
bons requisitos de software. Você aprenderá acerca dos processos da 
Engenharia de Requisitos e, também, como realizar o levantamento e 
a análise de Requisitos de Software, além disso, entenderá a verifica-
ção e a validação desses requisitos. Por último, compreenderá como 
realizar a especificação dos mesmos.
UNIDADE 2
52
Na unidade anterior, iniciamos a nossa jornada de estudos sobre a Engenharia 
de Requisitos e a sua importância no processo de desenvolvimento de software. 
Você conheceu os conceitos fundamentais bem como as etapas para compreen-
der essa engenharia. 
Para verificar se você absorveu o conteúdo, te faço uma pergunta: o quanto a 
Engenharia de Requisitos é relevante no processo de desenvolvimento de softwa-
re? E qual o objetivo dela? São questionamentos importantes a um(a) futuro(a) 
engenheiro(a) de software, pois ele(a) precisa lidar com várias situações que en-
volvem tanto os processos quanto a equipe. 
Na unidade anterior, você aprendeu que o processo de descobrir, analisar, 
documentar e verificar é chamado de Engenharia de Requisitos e que ela cons-
trói uma ponte entre o projeto e a construção do software. Aprendeu, também, 
que essa engenharia fornece todos os artefatos que promovam o entendimento 
do que se deseja produzir a todos os envolvidos no projeto de desenvolvimento 
de software. 
Mas, como ter a certeza de que esses artefatos reproduzem, de fato, a solução 
final desejada? Para responder a esta pergunta, lembre-se que os eles podem 
incluir: cenários de uso, modelos de análise, listas de funções e características, 
também devem ser revisados e validados junto com o cliente, os usuários ou os 
patrocinadores, ou seja, com os stakeholders integrantes do projeto. 
Em suma, são vários os artefatos, afinal, eles são produzidos durante as etapas 
da Engenharia de Requisitos, isto é, durante os processos que envolvem a Enge-
nharia de Requisitos de Software. 
53
Achou complicado? Falamos em processos de software que são compostos 
por várias tarefas, agora, citamos os processos da Engenharia de Requisitos. Bem, 
para descomplicar, te convido a fazer uma busca pela palavra “processo”, de for-
ma geral. Deixe de lado o aspecto técnico, abra o seu navegador na internet, digite 
“processo” ou “o que é um processo”. Em seguida, veja as definições apresentadas 
nos links, com os resultados. 
Registre, em seu Diário de Bordo, as definições do que é um processo, então, 
descreva a sua análise dessas definições. 
Agora, pesquise a definição de “processo” em um dicionário, anote e compare. 
Depois, pense: de forma geral, as definições mostradas nos remetem a uma ativida-
de continuada, em algo desenvolvido, passo a passo, ou a uma forma adotada para 
se desenvolver algo, concorda? Espero que após estas pesquisas, fique mais claro 
quando falamos em processos de software e processo da Engenharia de Requisitos. 
UNIDADE 2
UNIDADE 2
54
 Processos da Engenharia de Requisitos de Software
Você aprendeu, na unidade anterior, que, durante a produção de um software,são 
necessárias diversas fases/etapas compostas por várias tarefas e este conjunto de 
fases/etapas chama-se processo de software. Um processo de Engenharia de Re-
quisitos é, também, um conjunto estruturado de atividades/etapas/fases que são se-
guidas para derivar, validar e manter um documento de requisitos de um sistema. 
O processo usado nessa engenharia pode variar bastante, em função das ca-
racterísticas dos projetos ou do domínio da aplicação, das pessoas envolvidas e da 
organização. Para Pressman e Maxim (2021), as atividades de Engenharia de Requi-
sitos são divididas em Especificação de Requisitos e Gestão de Requisitos (Figura 1). 
Engenharia de Requisitos
Especi�cação de Requisitos
Levantamento e Análise
Negociação
Documentação
validação
Veri�cação
Gestão de Requisitos
Controle de Mudanças
Versionamento
Con�guração
Rastreabilidade
Gerência de Qualidade
Descrição da Imagem: a ilustração mostra as atividades de Engenharia de Requisitos, as quais são divi-
didas em especificação de requisitos e gestão de requisitos. Em especificação de requisitos, temos outras 
atividades, que são, respectivamente: levantamento e análise, negociação, documentação, validação e ve-
rificação. Em gestão de requisitos, estão as respectivas atividades: controle de mudanças, versionamento, 
configuração, rastreabilidade e gerência de qualidade. 
Figura 1 - Atividades da Engenharia de Requisitos / Fonte: a autora. 
Para entender cada uma das atividades, leia as definições a seguir:
 ■ Especificação de requisitos: representa todas as atividades realizadas 
para identificar, analisar, especificar e definir as necessidades do sistema, 
55
as quais veremos, com mais detalhes, a seguir: levantamento/elicitação e 
análise, negociação, documentação, validação e verificação. 
 ■ Gestão de requisitos: atividades responsáveis pela documentação, ver-
sionamento, controle de mudanças e qualidade dos requisitos levantados 
na fase de especificação. Tais atividades serão estudadas na Unidade 5. 
Sommerville (2018) afirma que a Engenharia de Requisitos envolve três ativida-
des fundamentais: 
 ■ Elicitação e análise: ocorre a descoberta dos requisitos, por meio da 
interação com os stakeholders. 
 ■ Especificação: ocorre a conversão dos requisitos em uma forma padrão.
 ■ Validação: ocorre a averiguação de que os requisitos, realmente, definem 
o sistema desejado pelo cliente.
Esse processo da Engenharia de Requisitos, na prática, é um processo iterativo 
cujas atividades são intercaladas, conforme apresentado na Figura 2. Elas são 
organizadas em torno de uma espiral, e o resultado do processo é um documento 
de requisitos de sistema (SOMMERVILLE, 2018).
UNIDADE 2
UNIDADE 2
56
Quando se inicia o processo de Engenharia de Requisitos, dedicamos a maior 
parte do esforço a compreender os requisitos do negócio, seguindo para um estudo 
de viabilidade, em seguida, os requisitos do usuário do sistema. Em etapas mais 
avançadas do processo, Sommerville (2018, p. 96) destaca, nos anéis mais externos 
da espiral, o seguinte: “mais esforço será dedicado à elicitação e à compreensão dos 
requisitos não funcionais e dos requisitos de sistema mais detalhados”. 
Início
Especi�cação de
requisitos de negócio
Especi�cação de
requisitos de usuário
Elicitação de
requisitos de
usuário
Estudo de
viabilidade
Elicitação
de requisitos
de sistema
Especi�cação e
modelagem dos
requisitos de sistema
Revisões
Elicitação
de requisitos
Especi�cações
de Requisitos
Validação
de requisitos
Documentos de
requisitos de sistema
Prototipação
Descrição da Imagem: a ilustração mostra as atividades fundamentais: elicitação de requisitos, especi-
ficação de requisitos, validação de requisitos e documentação de requisitos de sistema, intercaladas em 
torno de uma espiral. Na atividade de elicitação, há o início, com a elicitação de requisitos de usuário e 
requisitos de sistema. Em especificação de requisitos, há as especificações de requisitos de negócio, de 
requisitos de usuário e a especificação e modelagem dos requisitos de sistema. Na atividade de validação 
de requisitos, estão o estudo de viabilidade, a prototipação e as revisões. O ciclo encerra na atividade de 
documento de requisitos de sistema.
Figura 2 - Visão em espiral do processo de Engenharia de Requisitos 
Fonte: Sommerville (2018, p. 95). 
57
Qual a quantidade de iterações em torno da espiral? O número pode variar de 
acordo com os níveis de detalhes, conforme os requisitos são desenvolvidos, e ela 
pode ser encerrada após alguns requisitos ou todos eles terem sido levantados ou 
elicitados. Em vez da prototipação, há a possibilidade de se utilizar desenvolvimen-
to ágil, para que os requisitos e a implementação sejam desenvolvidos em conjunto. 
Durante o processo de Engenharia de Requisitos, entendemos as necessida-
des do cliente, por isso, é importante analisar o que foi especificado e corrigir, caso 
seja necessário ou caso não se tenha entendido, exatamente, o que era esperado. 
Em todos os sistemas, os requisitos mudam e, como estudamos na unidade ante-
rior, entender o que o cliente almeja está entre as tarefas mais difíceis enfrentadas 
por um engenheiro de software. 
Por este motivo, as mudanças devem ser gerenciadas. Ao longo da unidade, 
você perceberá que as atividades do processo de Engenharia de Requisitos pre-
cisam andar juntas e permanecerem durante todo o ciclo de vida do projeto do 
software, o que dará garantias da elaboração de um bom documento de requisitos 
do sistema. 
Para o nosso estudo, seguiremos as atividades do processo de requisitos de 
software: levantamento e análise, verificação, validação e especificação.
UNIDADE 2
UNIDADE 2
58
 Levantamento e Análise de Requisitos de Software
Também conhecida como elicitação e análise de requisitos, esta atividade inicia 
o processo de Engenharia de Requisitos bem como a atividade de desenvolvi-
mento de software. É quando compreendemos o que o cliente quer e como será 
desenhada a sua proposta para atender às expectativas dele. O objetivo do le-
vantamento de requisitos é compreender as tarefas que os usuários realizam, 
além de procurar entender como eles usariam um novo sistema para ajudar na 
realização dessas tarefas.
Durante o levantamento de requisitos, o engenheiro de software trabalha 
com os usuários, a fim de saber sobre o domínio e as regras do negócio, quais 
atividades devem ser envolvidas, os serviços, as ferramentas, as características da 
aplicação que eles desejam, assim como o desempenho esperado e as limitações 
de hardware, entre outros (SOMMERVILLE, 2018).
O levantamento de requisitos exige a compreensão dos requisitos dos sta-
keholders. Isso é considerado um processo difícil, por várias razões, como 
verificaremos, a seguir:
1. Os usuários, muitas vezes, não sabem, exatamente, o que querem no 
sistema, exceto em aspectos gerais, portanto, costumam fazer exigências 
irreais, pois não sabem o que é viável ou não.
2. Os usuários expressam os requisitos em seus próprios termos devido 
ao conhecimento de suas tarefas, com isso, os engenheiros de software, 
sem experiência no domínio de negócio do cliente, talvez não entendam, 
claramente, tais requisitos.
3. Diferentes usuários, com requisitos distintos, podem expressá-los de 
maneiras variadas. 
4. Fatores políticos e tributários costumam influenciar os requisitos de 
um sistema.
59
5. O ambiente econômico e de negócios é dinâmico, então, inevitavelmen-
te, ocorrem mudanças durante o processo de análise. 
6. Novos requisitos surgem, muitas vezes, devido a mudanças de novos 
usuários que não foram, originalmente, consultados.
Fonte: Sommerville, 2018, p. 96 
A atividade levantamento e análise de requisitos de software possui um modelo 
de processo (Figura 3) com um conjunto de etapas/atividade. É um modelo com 
processos iterativos e um feedback contínuo de cada atividade, o qual é transmi-
tido para as demais. 
1. Descoberta e
compreensão dos
requisitos
2. Classi�cação e
organização