Livro - Engenharia de Requisitos

Prévia do material em texto

29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 1/22
Imprimir
INTRODUÇÃO
Começaremos os estudos apresentando a você a de�nição de Engenharia de Requisitos. Este é um processo
que se concentra, basicamente, em avaliar se o sistema é útil para o negócio (estudo de viabilidade), descobrir
requisitos (elicitação e análise), converter esses requisitos em algum formato padrão (especi�cação) e veri�car
se os requisitos de�nem o sistema que o cliente deseja (validação). Em seguida, você verá que a Engenharia de
Requisitos é o ramo da Engenharia de Software preocupado com o objetivo do mundo real para as funções e
restrições dos sistemas. Para �nalizar, você conhecerá a delimitação do escopo, que tende a ser uma atividade
iterativa à medida que os limites se tornam mais claros com o aumento da compreensão do domínio
compartilhado por todas as partes interessadas. Estes estudos iniciais serão muito importantes para você, pois
te darão toda a base para os próximos assuntos, então bons estudos!
COMPREENSÃO DE REQUISITOS DE SOFTWARE
A Engenharia de Requisitos é um processo de coleta e de�nição de quais serviços devem ser fornecidos pelo
sistema. Concentra-se, basicamente, em avaliar se o sistema é útil para o negócio (estudo de viabilidade),
descobrir requisitos (elicitação e análise), converter esses requisitos em algum formato padrão (especi�cação) e
veri�car se os requisitos de�nem o sistema que o cliente deseja (validação).
Na prática, a Engenharia de Requisitos não é um processo sequencial, e sim iterativo, no qual as atividades são
intercaladas. Por exemplo, você itera, primeiro, nos requisitos do usuário; elicitação, especi�cação e validação, e
repete as mesmas etapas para os requisitos do sistema, como podemos ver na Figura 1.
Aula 1
FUNDAMENTOS DA ENGENHARIA DE REQUISITOS
A  Engenharia de Requisitos é um processo que se concentra, basicamente, em avaliar se o
sistema é útil para o negócio (estudo de viabilidade), descobrir requisitos (elicitação e análise),
converter esses requisitos em algum formato padrão (especi�cação) e veri�car se os requisitos
de�nem o sistema que o cliente deseja (validação).
26 minutos
DEFINIÇÕES DE REQUISITOS DE SOFTWARE
 Aula 1 - Fundamentos da engenharia de requisitos
 Aula 2 - Elicitação de requisitos
 Aula 3 - Domínio do problema, restrições e premissas de requisitos
 Aula 4 - Negociação de requisitos
 Referências
104 minutos
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 2/22
Figura 1 | Processo de Engenharia de Requisitos por Ian Sommerville
Fonte: adaptada de Sommerville (2011).
No início do processo, a maior parte do esforço será consumido na compreensão dos requisitos de negócios e
do usuário de alto nível. Mais tarde, mais esforços serão gastos na elicitação e compreensão dos requisitos
detalhados do sistema (ELGABRY, 2016).
Requisitos do usuário e do sistema
Normalmente, os requisitos são apresentados em dois níveis de detalhes:
Requisitos do usuário: descreve os serviços que o sistema deve fornecer e as restrições sob as quais deve
operar. Não esperamos ver nenhum nível de detalhe, ou o que exatamente o sistema fará, são mais
requisitos genéricos. Geralmente, é escrito em linguagem natural e fornecido por diagramas.
Requisitos do sistema: signi�cam uma descrição mais detalhada dos serviços do sistema e das restrições
operacionais, como o sistema será usado e as restrições de desenvolvimento, como as linguagens de
programação. Este nível de detalhe é necessário para aqueles que estão envolvidos no desenvolvimento do
sistema, como engenheiros, arquitetos de sistemas, testadores etc.
Assim, os requisitos do usuário e do sistema referem-se apenas a diferentes níveis de detalhes. Ter diferentes
níveis de detalhes é útil porque comunica informações sobre o sistema que está sendo desenvolvido para
diferentes tipos de leitores, conforme apresentado na Figura 2.
Figura 2 | Leitores de diferentes tipos de especi�cação de requisitos
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 3/22
Fonte: adaptada de Sommerville (2011).
Assim, os usuários �nais não se preocuparão com os detalhes, eles precisam de um requisito escrito genérico e
abstrato, enquanto as pessoas envolvidas no desenvolvimento precisam saber exatamente o que o sistema
deve fazer. Você, provavelmente, acabará com muitos problemas e mal-entendidos se não tiver uma separação
clara entre os diferentes níveis de detalhes (ELGABRY, 2016).
Requisitos funcionais e não funcionais
Os requisitos de software são classi�cados em requisitos funcionais e requisitos não funcionais:
Requisitos funcionais: abrangem as principais funções que devem ser fornecidas pelo sistema. Quando
expressos como requisitos do usuário, geralmente, são descritos de forma abstrata. Entretanto, requisitos
de sistema funcionais mais especí�cos descrevem as funções do sistema, suas entradas, seu
processamento, como ele reagirá a uma entrada especí�ca e qual é a saída esperada (ELGABRY, 2016).
Requisitos não funcionais: são as restrições sobre as funções fornecidas pelo sistema, como quantos
processos o sistema pode manipular (desempenho), quais são os problemas (de segurança) que o sistema
precisa cuidar, a taxa de insucesso (con�abilidade), quais são as linguagens e ferramentas que serão
utilizadas (desenvolvimento), quais são as regras que precisa seguir para garantir que o sistema funcione
dentro da lei da organização (legislativa), como na Figura 3 (ELGABRY, 2016).
Figura 3 | Requisitos não funcionais
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 4/22
Fonte: adaptada de Sommerville (2011).
Os requisitos não funcionais são mais críticos, e os usuários, geralmente, podem encontrar maneiras de
contornar uma função do sistema que realmente não atende às suas necessidades, porém não atender a um
requisito não funcional pode signi�car que todo o sistema �ca inutilizável.
ENGENHARIA DE REQUISITOS NA ENGENHARIA DE SOFTWARE
Você já parou para observar que o mundo da tecnologia não pode funcionar sem software? As indústrias são
controladas por sistemas de software, como sistemas �nanceiros, laboratórios cientí�cos, infraestruturas e
utilitários, jogos, cinema, televisão... E a lista continua. Mas, antes de tudo, o que é um software?
Um software é um programa de computador junto aos documentos associados e aos dados de con�guração
que fazem com que esses programas funcionem corretamente. E um programa é um conjunto de instruções
(escritas em forma de código legível por humanos) que executa uma tarefa especí�ca (ELGABRY, 2016).
Tipos de sistemas de software
Existem muitos tipos diferentes de sistemas de software, de simples a complexos. Esses sistemas podem ser
desenvolvidos para um cliente especí�co, como para dar suporte a um processo de negócios especí�co, ou
desenvolvidos para �ns gerais, como qualquer software para nossos computadores, como processadores de
texto (ELGABRY, 2016).
Engenharia de Software
A Engenharia de Software é uma disciplina de engenharia aplicada ao desenvolvimento de software em uma
abordagem sistemática (chamada de processo de software). Basicamente, é a aplicação de teorias, métodos e
ferramentas para projetar e construir um software que atenda às especi�cações de forma e�ciente, econômica
e garanta qualidade.
Não se preocupa apenas com o processotécnico de construção de um software mas também inclui atividades
para gerenciar o projeto e desenvolver ferramentas, métodos e teorias que dão suporte à produção de
software.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 5/22
A não aplicação de métodos de Engenharia de Software resulta em um software mais caro e menos con�ável e
pode ser vital a longo prazo, pois, à medida que as mudanças chegam, os custos aumentam drasticamente
(ELGABRY, 2016).
Engenharia de Requisitos (ER)
Conforme de�nido por Zave (1997), a Engenharia de Requisitos é o ramo da Engenharia de Software
preocupado com o objetivo do mundo real para as funções e restrições dos sistemas. Preocupa-se também com
a relação desses fatores com a especi�cação do comportamento do software e com sua evolução ao longo do
tempo em famílias de software.
O processo de Engenharia de Requisitos inclui elicitação, modelagem, análise, veri�cação e validação e
gerenciamento de requisitos. Dentre esses subprocessos, a elicitação de requisitos desempenha um papel
importante na extração das necessidades dos stakeholders, pois é o primeiro subprocesso da engenharia de
requisitos e tem efeito cascata. Isso signi�ca que erros que ocorrem durante a elicitação afetarão os processos
de ER restantes. A compreensão inadequada dos processos pode levar ao fracasso de projetos de software. O
processo ocorre em quatro etapas, que incluem:
1. Estudo de viabilidade.
2. Levantamento e análise de requisitos.
3. Especi�cação de requisitos de software.
4. Validação de requisitos de software.
5. Gerenciamento de requisitos de software.
Brooks e Bullet (1987, p. 12) já a�rmavam que “a parte mais difícil de um sistema de software é decidir
precisamente o que construir. Portanto, a função máxima que o construtor de software executa para o cliente é
o re�namento de extração iterativo dos requisitos do produto”. A maioria dos softwares falha devido aos
requisitos inconsistentes e ambíguos, logo a compreensão clara da Engenharia de Requisitos ajuda a
desenvolver um sistema de software bem-sucedido.
DELIMITAÇÃO DE ESCOPO
O escopo do projeto é a parte do planejamento do projeto que envolve determinar e documentar uma lista de
objetivos, entregas, tarefas, custos e prazos especí�cos do projeto. E refere-se ao trabalho necessário para
entregar um produto. Requisitos e entregas de�nem o escopo do projeto, e é fundamental que a parte
interessada esteja de acordo com as informações discutidas no plano proposto.
O aumento do escopo (também chamado de aumento de requisitos, aumento de função, aumento de recursos)
no gerenciamento de projetos refere-se a mudanças, crescimento contínuo ou descontrolado no escopo de um
projeto em qualquer ponto após o início do projeto. Isso pode ocorrer quando o escopo de um projeto não é
de�nido, documentado ou controlado adequadamente.
Os requisitos, geralmente, começam com uma vaga declaração de intenção. O primeiro problema é estabelecer
o limite da investigação e, entre outros, o escopo do sistema pretendido. Infelizmente, isso raramente é um
processo fácil, pois os clientes, normalmente, não sabem exatamente o que querem, e o conhecimento sobre o
sistema pretendido é vago. O escopo tende a ser uma atividade iterativa à medida que os limites se tornam
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 6/22
mais claros com o aumento da compreensão do domínio compartilhado por todas as partes interessadas. No
entanto, o processo é pouco compreendido e poucas pesquisas abordaram diretamente esse difícil problema
(SUTCLIFFE, 2017).
Tomemos, por exemplo, um sistema para ajudar epidemiologistas em suas pesquisas. As partes interessadas
podem incluir analistas de saúde pública com interesses em epidemiologia, bem como pesquisadores médicos.
A gama de possíveis ferramentas de apoio à decisão pode incluir coleta de dados, preparação de dados, análise
estatística, visualizações, grá�cos, mapas, bem como um suporte de trabalho em grupo para discussão
colaborativa de resultados. O proprietário e o escopo do sistema não estavam claros, pois o projeto foi iniciado
como parte do programa de pesquisa em ciência, com usuários que eram pesquisadores acadêmicos em
epidemiologia e que colaboravam com analistas de saúde pública que trabalhavam em hospitais locais.
A de�nição do escopo é mais bem alcançada a partir da discussão com todas as partes interessadas e pela
documentação dos objetivos de alto nível do sistema como termos de referência. Anotar o escopo tende a focar
a atenção dos usuários em onde os limites da investigação do sistema devem estar e ajuda a identi�car pelo
menos um escopo inicial para o sistema.
A norma internacional que trata das ferramentas e dos métodos de Engenharia de Requisitos para linha de
produtos de software e sistemas é a ISO/IEC 26551:2016. O escopo dela é:
Fornecer os termos e as de�nições especí�cos para Engenharia de Requisitos para linhas de produtos de
software e sistemas e produtos membros associados.
De�nir grupos de processos e seus processos executados durante a engenharia de requisitos de linha de
produto (esses processos são descritos em termos de propósito, entradas, tarefas e resultados).
De�nir as capacidades do método para suportar as tarefas de�nidas de cada processo.
De�nir os recursos da ferramenta para automatizar/semiautomatizar tarefas ou recursos de métodos
de�nidos.
VIDEOAULA
Para que seus estudos �quem mais completos, saiba que é importante entender que a especi�cação de
requisitos é o processo de escrever os requisitos do usuário e do sistema em um documento. Os requisitos
devem ser claros, fáceis de entender, completos e consistentes. Apresentamos neste vídeo um pouco das
especi�cações de requisitos, então não perca. Te espero lá!
 Saiba mais
Para entender melhor Engenharia de Requisitos, disponibilizamos alguns links a seguir, que abordam com
mais detalhes esse assunto. Vale a pena conferir!
1. Engenharia de requisitos: quais as etapas e como funciona?:
https://blog.betrybe.com/tecnologia/engenharia-de-requisitos-tudo-sobre/. 
Videoaula
Para visualizar o objeto, acesse seu material digital.
https://blog.betrybe.com/tecnologia/engenharia-de-requisitos-tudo-sobre/
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 7/22
2. O Processo de Engenharia de Requisitos:
https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula05.pdf. 
3. Análise de Requisitos: https://www.infoescola.com/engenharia-de-software/analise-de-requisitos/.
4. Engenharia de Requisitos: software orientado ao negócio: https://books.google.com.br/books?hl=pt-
BR&lr=&id=gA7kDAAAQBAJ&oi=fnd&pg=PA74&dq=engenharia+de+requisitos&ots=sObt6P__pY&sig=zK
_lGHpZFdeZBda0PFEXD6xZVHI#v=onepage&q=engenharia%20de%20requisitos&f=false. 
5. Apostila de Engenharia de requisitos: https://www.maxwell.vrac.puc-rio.br/6954/6954_3.PDF . 
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá a realizar o re�namento dos requisitos de software, de modo a aumentar a
compreensão das necessidades do cliente quanto à aplicação que será construída. Além disso, serão
apresentadas técnicas que podem ser utilizadas no processo do levantamento de requisitos, auxiliando tanto o
cliente quanto o membro da equipe de desenvolvimento responsável pela escrita das funcionalidades que
devem ser providas pelo programa.
Você também aprenderá sobre a importância do analista de requisitos e do engenheiro de software no
processo da construção de uma aplicação.
Lembre-se de que você éresponsável pelo seu aprendizado. Bons estudos! 
ANÁLISE E REFINAMENTO DO ESCOPO
No início do processo de desenvolvimento de uma nova aplicação, as primeiras entrevistas com o cliente darão
apenas uma vaga ideia dos requisitos necessários para o software, de modo que, com o passar do tempo e as
constantes validações e esclarecimentos de dúvidas acerca do negócio com o cliente, a maior compreensão do
domínio da aplicação facilitará para que o requisito se adeque cada vez mais às reais necessidades do cliente.
A este processo de “descoberta” das regras de negócio e, por consequência, dos requisitos em si, denominamos
de re�namento dos requisitos. Esta fase é de extrema importância para o sucesso do projeto, já que o
re�namento transformará um requisito que estava em um nível de detalhamento macro, sem detalhes técnicos
e apenas focado no funcionamento geral, em um requisito com o detalhamento técnico necessário para que a
equipe de desenvolvimento possa implementá-lo na aplicação.
Os requisitos, após serem re�nados com o auxílio do cliente, precisam ser validados, para que se tenha a
garantia de que o que está escrito confere com o que é esperado pelo cliente (e partes interessadas) como
resposta esperada da funcionalidade.
Aula 2
ELICITAÇÃO DE REQUISITOS
Nesta aula, você aprenderá a realizar o re�namento dos requisitos de software, de modo a
aumentar a compreensão das necessidades do cliente quanto à aplicação que será construída. 
24 minutos
https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula05.pdf
https://www.infoescola.com/engenharia-de-software/analise-de-requisitos/
https://books.google.com.br/books?hl=pt-BR&lr=&id=gA7kDAAAQBAJ&oi=fnd&pg=PA74&dq=engenharia+de+requisitos&ots=sObt6P__pY&sig=zK_lGHpZFdeZBda0PFEXD6xZVHI#v=onepage&q=engenharia%20de%20requisitos&f=false
https://www.maxwell.vrac.puc-rio.br/6954/6954_3.PDF
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 8/22
Após o processo de re�namento das funcionalidades ter sido concluído e acordado com o cliente, deverá haver
o planejamento dos recursos necessários (quantidade e per�l de pro�ssionais, con�guração das máquinas
necessárias e outros recursos, como impressoras etc.) e a estimativa de conclusão do projeto, com entrega do
produto ao cliente. Este planejamento está se referindo ao escopo do projeto, delimitando-o conforme os
requisitos necessários para a aplicação.
O escopo do projeto representa tudo o que precisa ser feito para atender às necessidades do cliente ao �nal do
projeto (ENAP, 2014). Com isso, contempla todo o trabalho necessário para a conclusão do projeto com sucesso.
A delimitação do escopo, por sua vez, criará uma fronteira entre o que está incluso no projeto e o que não
estará englobado na aplicação.
Após o processo de re�namento do escopo ter sido �nalizado, é importante garantir que nenhuma variável
acordada será modi�cada, tendo em vista o impacto negativo no planejamento do projeto, tendo por
consequência o aumento do custo, já que os recursos alocados precisarão permanecer assim por mais tempo,
além do aumento no prazo da entrega �nal.
Qualquer imprevisto no projeto, como inclusão de novas funcionalidades não mapeadas inicialmente ou
alteração das já existentes no projeto, precisará de uma nova rodada de negociação com o cliente, garantindo
que este �cará ciente dos efeitos colaterais de tal alteração.
Outra variável importante para o re�namento do escopo são os riscos envolvidos no projeto. Com a análise dos
riscos feita de forma adequada, é possível prever e se precaver de eventualidades que possam impactar
negativamente o projeto, através de planos de contorno para cada risco mapeado. A estimativa de prazo �nal
para a entrega e conclusão do projeto, por sua vez, deverá considerar uma folga para tais eventualidades,
evitando que prejuízos de tempo e custos aconteçam.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
TÉCNICAS DE LEVANTAMENTO DE REQUISITOS
Para realizar o processo de levantamento de requisitos, você terá que entender o negócio que está sendo
mapeado, suas regras e seus detalhes técnicos. Muitas vezes, o passo inicial para esta fase é a realização de
entrevistas com o cliente (ou as partes interessadas), de modo a compreender sua expectativa com relação ao
produto que será construído.
Um problema, no entanto, é a di�culdade encontrada por muitos clientes para conseguir expressar seus
anseios da melhor forma possível, de modo a deixar claras todas as regras de negócio inerentes ao domínio que
englobará a aplicação. Para conseguir obter o nível de detalhamento dos requisitos necessário para que a
equipe de desenvolvimento possa atuar (programando o software), técnicas podem ser aplicadas em conjunto
com as entrevistas.
Sommerville (2011) apresenta as técnicas mais utilizadas para este processo, tais quais:
Levantamento orientado a ponto de vista.
Etnogra�a.
Workshops.
Prototipagem.
Entrevistas.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 9/22
Questionários.
Brainstorming.
JAD.
Levantamento orientado a ponto de vista
Também conhecida como VORD, sigla em inglês para de�nição de requisitos baseados em pontos de vista,
será possível analisar as funcionalidades que deverão ser providas pelo sistema a partir da visão dos mais
diferentes interessados no produto. Desta forma, procura-se de�nir as necessidades de cada interessado e
mapear as regras de negócio de acordo com o per�l de cada interessado.
Uma característica importante da utilização desta técnica é a detecção dos con�itos existentes nos diferentes
pontos de vista dos diversos interessados, mapeando estes con�itos para que possam ser resolvidos em um
consenso entre os diferentes stakeholders (interessados).
Etnogra�a
Esta técnica consiste em mapear as funcionalidades de uma aplicação de acordo com a observação da estrutura
organizacional e sua hierarquia, assim como a cultura empresarial, de modo que o analista responsável pelo
levantamento das funcionalidades deverá se inserir no dia a dia do ambiente de trabalho no qual o sistema será
utilizado.
Workshops
Para a aplicação desta técnica, você deverá montar uma equipe de desenvolvedores e uma equipe com os
principais interessados no projeto (os que mais sabem do negócio e melhor representam o ambiente no qual o
sistema será utilizado), com a �nalidade de fomentar o trabalho em grupo e a interação entre os participantes.
Prototipagem
A criação de protótipos é importante para que os stakeholders possam validar, de forma visual, os requisitos
que estão sendo mapeados e ajustar (ou não) às suas reais necessidades. É possível adicionar validações de
campos e �uxo entre as diferentes páginas da aplicação, assim como a disposição dos campos nas telas do
sistema.
Entrevistas
A realização de entrevistas acontece, principalmente, nas etapas iniciais do projeto, através das quais se
procura entender as necessidades do cliente e o domínio da aplicação.
Questionários
A elaboração de questionários a respeito de como deve ser o comportamento do sistema com os requisitos
desejados é uma boa forma de se entender o �uxo da aplicação e as regras de negócio especí�cas do domínio.
Brainstorming
Tempestade de ideias é uma técnica indicada para que todos os interessados possam expor seus anseios em
relação ao projeto, sendo possível armazenar as ideias que não forem contempladas em um primeiro momento
do projeto para evoluções futuras.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade…10/22
JAD
Joint Application Design, ou Projeto de Aplicação Conjunta, tem o objetivo de criar uma visão única da aplicação,
para que todos os interessados possam avaliar e apresentar suas contribuições.
PAPEL DO ANALISTA DE SISTEMAS E ENGENHEIRO DE SOFTWARE NA
ENGENHARIA DE REQUISITOS
A Engenharia de Software, conforme explica Sommerville (2011), objetiva fornecer ferramentas e técnicas para o
processo de construção pro�ssional de uma aplicação, indo além da mera codi�cação amadora.
O papel do engenheiro de software é, então, seguir um processo de construção de softwares baseado em
metodologias bem validadas, que gerarão produtos, os quais, por sua vez, poderão ser vendidos para clientes.
Estes produtos podem estar em diferentes categorias, tais como:
Produtos genéricos: aplicações construídas de forma a englobar as principais funcionalidades de um
domínio, sem se preocupar com regras de negócio especí�cas de cada cliente.
Produtos sob encomenda: aplicações que são especí�cas para atender às necessidades do cliente que fez
a encomenda, de modo a atender às suas regras de negócio particulares.
Quando uma aplicação é construída de forma genérica, também conhecida como software de prateleira, ela
não atenderá às necessidades especí�cas de uma organização, da mesma forma que os ajustes e as eventuais
modi�cações na aplicação são feitos pela equipe que construiu o produto. Por outro lado, quando uma
aplicação é encomendada, seus ajustes e sua manutenção serão solicitados pelo cliente que realizou a
encomenda, de modo que a aplicação se mantenha sempre ajustada à sua dinâmica organizacional.
O papel do engenheiro de software é realizar todo o processo de construção e manutenção da aplicação,
estando mais focado na parte da codi�cação e nas questões que estão envoltas a ela. É responsável pelas fases
do levantamento de requisitos (elicitação, validação e re�namento das funcionalidades), de�nindo quais as
técnicas que serão utilizadas pela equipe de desenvolvimento para a execução desta fase, além da de�nição da
metodologia de desenvolvimento que será utilizada pela equipe e da orquestração das cerimônias e fases que
precisam ser seguidas, conforme a metodologia escolhida.
Ao �nal do processo de construção da aplicação, o fato de se ter seguido uma metodologia bem fundamentada,
gerida pelo engenheiro de software, garantirá um produto com boa qualidade e de fácil manutenção, que
deverá estar bem documentado, de modo a facilitar o entendimento dos membros da equipe de
desenvolvimento e servir de manual de utilização para o usuário �nal.
Também cabe ao engenheiro de software aplicar técnicas que garantam a qualidade do produto desenvolvido,
que podem ser utilizadas para a validação dos requisitos, por parte do cliente, ou nos testes funcionais da
aplicação, a �m de garantir que as respostas obtidas com as funcionalidades do software estão de acordo com
as esperadas, conforme o mapeamento das necessidades do cliente.
O analista de sistemas, por sua vez, trabalhará em conjunto com o engenheiro de software para garantir o
sucesso do projeto e, consequentemente, do produto gerado por ele. O analista desempenhará o papel de se
aprofundar nas atividades processuais do projeto de desenvolvimento, como a modelagem da estrutura que
será implementada no banco de dados, a modelagem do negócio a ser trabalhado no projeto, a arquitetura das
camadas da aplicação, os padrões de projeto que deverão ser utilizados, entre outras questões técnicas
voltadas a processos.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 11/22
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá sobre como fazer o re�namento dos requisitos para a construção
de uma nova aplicação, vendo um exemplo prático de re�namento. Além disso, serão apresentadas as técnicas
utilizadas para o levantamento de requisitos e qual o papel do analista de requisitos e do engenheiro de
software neste processo.
 Saiba mais
A ferramenta Creately, gratuita, auxilia na criação de ferramentas visuais para colaboração nas reuniões de
levantamento de requisitos, como mapas mentais, diagramas de casos de uso, diagramas de
sequência, entre outras. Basta clicar no botão “Ir para App” que uma sessão gratuita e sem necessidade de
cadastro será iniciada.
A ferramenta gratuita Miro poderá te auxiliar na escrita dos requisitos e no processo de detalhamento. As
funcionalidades poderão ser compartilhadas com os membros da equipe de desenvolvimento.
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá a importância do correto entendimento acerca do domínio do problema de uma
nova aplicação e como isso in�uencia a especi�cação de requisitos. Aprenderá também quais são os processos
necessários para a especi�cação de requisitos e como identi�car e mapear as restrições e premissas iniciais do
projeto.
As funcionalidades de uma aplicação, para que satisfaçam às reais necessidades do cliente, precisam ser bem
compreendidas e descritas, conforme as premissas e restrições de cada projeto.
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas
esteja sempre buscando novas formas de se atualizar.
Bons estudos! 
Aula 3
DOMÍNIO DO PROBLEMA, RESTRIÇÕES E PREMISSAS DE
REQUISITOS
Nesta aula, você aprenderá a importância do correto entendimento acerca do domínio do
problema de uma nova aplicação e como isso in�uencia a especi�cação de requisitos, e também
quais são os processos necessários para a especi�cação de requisitos e como identi�car e
mapear as restrições e premissas iniciais do projeto.
28 minutos
https://creately.com/pt/home/
https://miro.com/app/dashboard/
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 12/22
DOMÍNIO DO PROBLEMA E OS TIPOS DE REQUISITOS
Para que uma nova aplicação tenha seu processo de construção iniciado, é preciso, em primeiro lugar, entender
em qual domínio de aplicação este novo software se encaixa. Essa característica poderá ser percebida pela
descrição inicial do cliente a respeito do propósito para qual aplicação será desenvolvida.
O domínio da aplicação se caracteriza por ser o ambiente macro no qual a aplicação está inserida, ou seja, se
um software que se destine ao cadastramento de consultas médicas for construído, seu domínio será o
ambiente médico (clínico, hospitalar ou ambos). A partir da identi�cação deste domínio, termos e regras
especí�cas, pertencentes ao domínio, serão considerados no momento da elicitação de requisitos de uma nova
aplicação.
Conforme explica Sommerville (2011), o domínio é utilizado para auxiliar na identi�cação de objetos, atributos e
serviços que serão utilizados pela nova aplicação a ser desenvolvida. Sendo assim, antes que o processo de
desenvolvimento de fato aconteça, é importante conhecer quais são estes objetos, atributos e serviços
intrínsecos ao domínio, o relacionamento entre eles e como interagirão com as funcionalidades mapeadas para
a sua aplicação.
Muitas vezes, identi�car requisitos que são próprios do domínio da nova aplicação requer atenção e experiência
do analista responsável. Quando uma pessoa que está muito ambientada ao domínio é entrevistada, por
exemplo, ela pode estar tão familiarizada com os termos, jargões e conceitos que ache desnecessário explicar
para quem está fazendo o levantamento de requisitos da aplicação, ou até mesmo acredite que é tão “óbvio”
que a pessoa já conheça tal assunto.
Então, para que se consiga obter o máximo de informações possíveis acerca de um domínio e dos requisitos
implícitos que uma nova aplicação precisará atender, é necessário,muitas vezes, utilizar mais de uma técnica de
levantamento de requisitos para conseguir entender e mapear tais funcionalidades. As técnicas de tempestade
de ideias (brainstorming) e entrevistas com o cliente poderão ser utilizadas em conjunto para esta �nalidade.
A depender do domínio do problema, os requisitos funcionais e não funcionais de sua aplicação poderão ser
in�uenciados por ele. Um exemplo é a questão de marcação de consultas: imagine que a sua nova aplicação
pertença ao domínio médico e que terá, como uma de suas funcionalidades, o agendamento de consultas
médicas. Caso uma consulta já tenha sido agendada para um determinado horário e paciente, outro paciente
não poderá ser agendado para este mesmo horário e médico. Isso representa uma característica do domínio,
uma vez que não é possível que duas pessoas sejam atendidas pelo mesmo pro�ssional simultaneamente.
Os requisitos não funcionais, como questões de segurança, performance, auditoria, entre outros, também
poderão ser de�nidos conforme a necessidade do domínio, tendo em vista que serão as características deste
domínio que ditarão qual o comportamento implícito da sua aplicação. Como exemplo, podemos mencionar a
anonimização de dados sensíveis dos pacientes atendidos pela nossa aplicação exemplo que mencionamos no
parágrafo anterior. Dados, como nome, data de nascimento, histórico médico e documentos pessoais, precisam
ser mantidos sob sigilo, conforme a Lei Geral de Proteção de Dados (LGPD), em vigor desde 2020.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos! 
PROCESSOS DE ESPECIFICAÇÃO DE REQUISITOS
Após o entendimento inicial do domínio da aplicação, será necessário realizar um levantamento de quais
funcionalidades que esta nova aplicação deverá prover, suas regras de negócio e os requisitos não funcionais
envolvidos, considerando o domínio no qual a aplicação está inserido.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 13/22
Segundo Turine e Masiero (1996), o processo de especi�cação de requisitos deverá englobar as fases de
aquisição, re�namento (detalhamento técnico dos requisitos) e validação destes com as necessidades reais do
usuário. Os requisitos precisam estar livres de ambiguidades, com uma linguagem clara e objetiva,
destrinchando como deverá ser o comportamento do sistema após a sua implementação.
Para a fase de elicitação de requisitos, o domínio da aplicação poderá fornecer um conjunto grande de
funcionalidades disponíveis para serem implementadas na aplicação que será construída, sendo necessário
conhecer o escopo acordado para os requisitos do novo programa. Esta limitação se faz necessária para que os
balizadores do projeto, como a limitação de tempo e orçamento, não sejam infringidos pela adição de
funcionalidades extras durante o andamento do projeto.
Figura 1 | Metodologia cascata de desenvolvimento de software
Fonte: elaborada pela autora.
Em metodologias tradicionais de desenvolvimento de softwares, como a cascata, apresentada pela Figura 1,
cada fase do processo de especi�cação de requisitos precisa estar totalmente pronta para que a fase seguinte
se inicie. Desta forma, caso o cliente necessite realizar algum ajuste em uma das funcionalidades já levantadas
para a aplicação, não será possível após a fase de especi�cação de requisitos ter sido concluída. Este fato
ocasiona, muitas vezes, o descontentamento do cliente ao �nal do projeto, já que o produto entregue poderá
não mais atender às suas reais expectativas.
Para ajustar o processo de levantamento de requisitos de modo a atender com mais e�ciência e e�cácia os
anseios das partes interessadas, novas metodologias para o desenvolvimento de aplicações foram
desenvolvidas, como a espiral (ou incremental) e as metodologias ágeis.
Figura 2 | Exemplo de modelo incremental de desenvolvimento de software
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 14/22
Fonte: elaborada pela autora.
A Figura 2 apresenta as etapas da metodologia incremental, em que cada entrega incrementará um pacote de
funcionalidades ao produto, que estará pronto ao �nal do último incremento.
A metodologia espiral busca desenvolver uma implementação inicial da aplicação, apresentar ao cliente para
obtenção de feedbacks, realizar os ajustes necessários e retomar o processo de desenvolvimento, de modo que
as fases do processo de especi�cação de requisitos acontecem todas de forma simultânea (especi�cação de
requisitos, implementação da aplicação e validação desta junto ao cliente). Cada versão que é apresentada ao
cliente para validação é denominada versão intermediária, enquanto a aplicação validada se denomina versão
�nal.
Em comparação com a metodologia tradicional cascata, a metodologia incremental apresenta algumas
vantagens, tais quais apresentadas no Quadro 1.
Quadro 1 | Vantagens da metodologia incremental em relação à metodologia cascata
Característica Metodologia cascata Metodologia incremental
Inserção de novas funcionalidades Custo alto, não suporta Suporta
Feedback do cliente
Não tem a possibilidade durante o
processo de desenvolvimento
Cliente tem a possibilidade de
fornecer feedback constante sobre
o que está sendo construído
Rapidez na entrega e
implementação do produto
Cliente esperará longo tempo até
que todo o produto seja concluído
e entregue
É possível realizar entregas parciais,
reduzindo o tempo de espera do
cliente
Fonte: elaborado pela autora.
As metodologias ágeis, por sua vez, se inspiraram na metodologia incremental para otimizar ainda mais as fases
do processo de desenvolvimento de aplicações, buscando aproximar o cliente das fases de levantamento de
requisitos, validação e implementação. Desta forma, o cliente poderá efetuar ajustes nos requisitos levantados
inicialmente, inserir novos requisitos durante o andamento do projeto (desde que acordados e os impactos de
custo e prazo analisados) e obter versões parciais já prontas para serem utilizadas em produção.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
RESTRIÇÕES E PREMISSAS DE REQUISITOS
Todo projeto terá restrições e premissas que precisam ser levadas em consideração durante o processo de
construção da nova aplicação. Essas premissas e restrições podem ser originadas tanto do domínio da aplicação
(como nos casos com relação ao negócio da aplicação) como das necessidades das partes interessadas (como a
restrição de orçamento disponível, por exemplo).
Quando nos referimos às restrições, estamos falando em limitações que o negócio poderá impor, como
restrições de acesso a determinadas partes da aplicação para per�s de acesso especí�cos e restrições de
usabilidade (limitação de usuários simultâneos ou apenas um usuário poderá estar logado na aplicação com um
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 15/22
determinado usuário ao mesmo tempo). Estas restrições são traduzidas para a aplicação como requisitos não
funcionais, ligados a um ou mais requisitos funcionais da aplicação.
Por outro lado, quando mencionamos o termo “premissas”, estamos nos referindo às pré-condições do projeto
que precisarão ser consideradas verdadeiras. Um exemplo é a de�nição de parâmetros de inicialização com
valores �xos, já que se assume que os valores esperados pela aplicação serão informados pelos parâmetros (e
que estes parâmetros estarão preenchidos).
A compreensão do negócio da aplicação pelo analista de requisitosresponsável pelas fases de levantamento
das funcionalidades do novo sistema é importante para que as restrições de negócio e as premissas iniciais da
aplicação sejam identi�cadas corretamente, o que nem sempre é uma tarefa fácil, tendo em vista que a grande
familiaridade do cliente com o negócio e os termos envolvidos poderão di�cultar este processo de descoberta,
por parecer óbvio.
Quando uma restrição do sistema é infringida, a depender da gravidade e do tipo de restrição (se está
relacionada com um requisito funcional ou não funcional), poderá trazer sérios prejuízos para o sistema, como
inconsistências (em caso de englobarem requisitos funcionais), e, caso a restrição seja relacionada a um
requisito não funcional, a inutilização do sistema não está descartada. Por isso, é de extrema importância
observar se todas as restrições estão sendo consideradas na implementação da aplicação, através dos testes
funcionais e não funcionais da aplicação.
O prejuízo causado por uma quebra de premissa, por sua vez, poderá ser uma falha no funcionamento da
aplicação, sendo percebida pelo usuário �nal, sendo menos grave do que o não atendimento a uma restrição.
As restrições também podem ser mapeadas diretamente no banco de dados, quando estão relacionadas com
os dados e o relacionamento entre eles, conforme apresentada na Figura 3. Neste caso, o próprio Sistema
Gerenciador de Banco de Dados (SGBD) �cará responsável por garantir que todas as regras de�nidas pelos
desenvolvedores sejam cumpridas, evitando que inconsistências aconteçam.
Figura 3 | Exemplo de restrições implementadas diretamente no banco de dados
Fonte: elaborada pela autora.
A Figura 3 apresenta algumas formas de implementação de restrições do negócio em banco de dados, como a
checagem de valores únicos em determinados campos, o preenchimento de campos obrigatórios ou a validação
dos relacionamentos entre campos de diferentes tabelas.
Quando as restrições existem apenas a nível de aplicação, cabe à equipe de desenvolvimento garantir, através
das regras de negócio implementadas e da documentação elaborada sobre estas regras, que as informações
geridas pela aplicação se manterão consistentes. Quando uma equipe é formada por diversos membros, com
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 16/22
alta rotatividade e sem uma boa documentação atualizada, pode ser mais difícil manter as restrições em
consonância com o que é especi�cado na documentação.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
VIDEOAULA
Olá, estudante! Neste vídeo, você complementará seus conhecimentos sobre a importância do domínio da
aplicação no levantamento de requisitos de um novo projeto, como as restrições iniciais e as premissas de
projeto poderão in�uenciar no andamento e no sucesso de um novo software e quais os processos para a
especi�cação de seus requisitos. 
 Saiba mais
Para saber mais sobre as premissas e restrições de um projeto e seu relacionamento com o escopo da
aplicação, você poderá acessar o documento disponível em:
https://repositorio.enap.gov.br/bitstream/1/1109/1/GerenciaDeProjeos_modulo_2_�nal_.pdf.
O guia do conhecimento em gerenciamento de projetos PMBOK, no item 1.2.6.2, de�ne os conceitos sobre
premissas, restrições e riscos do projeto e é de leitura essencial para quem deseja conhecer melhor o
processo de gerenciamento de projetos. Você poderá acessar este guia neste link:
https://dicasliderancagp.com.br/wp-content/uploads/2018/04/Guia-PMBOK-6%C2%AA-
Edi%C3%A7%C3%A3o.pdf. 
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá como acontece o processo de negociação de requisitos, como técnicas para
negociação podem ser aplicadas, quais as consequências de ter requisitos mal especi�cados em um projeto e
como evitá-las. 
O sucesso de um projeto dependerá da qualidade da fase de especi�cação de requisitos, então é de
fundamental importância que o analista responsável consiga extrair do cliente todas as informações relevantes
para o projeto.
Aula 4
NEGOCIAÇÃO DE REQUISITOS
Nesta aula, você aprenderá como acontece o processo de negociação de requisitos, como
técnicas para negociação podem ser aplicadas, quais as consequências de ter requisitos mal
especi�cados em um projeto e como evitá-las. 
24 minutos
https://repositorio.enap.gov.br/bitstream/1/1109/1/GerenciaDeProjeos_modulo_2_final_.pdf
https://dicasliderancagp.com.br/wp-content/uploads/2018/04/Guia-PMBOK-6%C2%AA-Edi%C3%A7%C3%A3o.pdf
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 17/22
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas
esteja sempre buscando novas formas de se atualizar. Bons estudos! 
PROCESSOS DE NEGOCIAÇÃO DE REQUISITOS
Quando um projeto possui diversos stakeholders, cada um terá suas próprias expectativas quanto ao produto e
às suas funcionalidades. Desta forma, é comum que con�itos de interesses aconteçam, sendo necessária uma
intermediação para que se chegue a um consenso.
O processo de resolução de con�itos, em um projeto de software, tem por objetivo se chegar a um consenso no
que diz respeito a quais funcionalidades são importantes para todos, ou grande parte dos interessados
(patrocinadores), priorizando-as para a fase de implementação.
Para iniciar o processo de negociação, o analista de requisitos responsável deverá reunir todos os interessados
no projeto, que deverão expor quais as suas principais expectativas com o produto. A partir deste ponto, pode-
se, por exemplo, atribuir um número a cada requisito, simbolizando um peso em termos de importância para
cada stakeholder para aquela funcionalidade especí�ca. Ao �nal do processo, as funcionalidades que tiverem
um maior peso deverão ser as mais importantes para todos (ou a maioria), compondo o conjunto prioritário de
implementação.
Nem sempre o processo de negociação e priorização é fácil e de rápida resolução. Sendo assim, tornam-se
necessárias algumas etapas de reunião entre os interessados, de modo que cada um possa apresentar seu
ponto de vista e o motivo pelo qual um determinado conjunto de funcionalidades é mais importante que as
demais funcionalidades.
A Figura 1 apresenta um resumo do ciclo de negociação e priorização dos requisitos de um projeto, quando há
con�itos de interesses entre os patrocinadores do projeto.
Figura 1 | Fases do ciclo de negociação e priorização de requisitos
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 18/22
Fonte: elaborada pela autora.
As rodadas de negociação, quando não se consegue chegar a um consenso, precisam de técnicas que você,
como analista de requisitos ou um papel equivalente, deverá aplicar para que se consiga obter um
direcionamento acerca de quais funcionalidades deverão ser priorizadas. Muitas vezes, os con�itos começam
ainda no processo de levantamento dos requisitos, sendo necessário um consenso sobre quais requisitos farão
(ou não) parte do projeto.
As reuniões para negociação de requisitos precisam ter o objetivo de apresentar quais con�itos de interesse
existem no projeto, a �m de obter possíveis soluções das partes interessadas e quais ações poderão ser
tomadas para a resolução dos con�itos. É possível, por exemplo, que a alteração em uma funcionalidade
consiga solucionar um con�ito de interesse existente, ajustando este requisito ao melhor para todas as partes.
É importante que, durantea fase de elicitação de requisitos de um projeto, seja dedicado um tempo
relativamente longo para este processo de negociação de requisitos, tendo em vista que é um processo
interativo e que podem ser necessárias diversas rodadas de negociação até que se chegue a um denominador
comum.
O resultado do processo de negociação é um compromisso �rmado entre as partes interessadas no projeto,
quanto ao conjunto de requisitos que deverão ser codi�cados de forma prioritária. Desta forma, utilize nossos
materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
TÉCNICAS DE NEGOCIAÇÃO DE REQUISITOS
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 19/22
Para que o processo de negociação de requisitos aconteça de forma satisfatória, é necessário que o analista de
requisitos ou líder técnico responsável faça uso de algumas técnicas. A concordância entre as partes dirá
quantas e quais técnicas devem ser utilizadas ao longo das reuniões de negociação.
Conforme explica Ramires (2004), o processo de negociação de requisitos pode seguir por duas vertentes: a
integrativa, na qual o acordo entre as partes é feito de forma colaborativa e inventiva, e a distributiva, que se
mostra mais in�exível, buscando convencer as partes sobre os interesses de outros interessados, sem se
preocupar com as necessidades globais.
Estratégia integrativa
Com a estratégia integrativa, o objetivo será agregar valor ao produto através da solução de impasses entre os
interessados de forma colaborativa, na qual todos os interesses são ouvidos e busca-se alcançar um ponto de
equilíbrio, no qual todos podem ter suas necessidades atendidas.
Nesta estratégia, um interessado pode, por exemplo, renunciar aos seus interesses de forma voluntária,
cedendo aos demais interessados, criando um relacionamento positivo no futuro, ou pode-se utilizar técnicas
de ganha-ganha (win-win), a partir das quais todos serão bene�ciados e nenhum prejudicado.
Uma técnica que pode ser utilizada é a win-win, como apresentado por Ramires (2004), na qual se busca a
concordância na negociação, bene�ciando a todos as partes ou, pelo menos, mantendo um bom
relacionamento entre os interessados e não causando perdas para nenhum deles.
Nesta técnica, a utilização de ferramentas de comunicação claras e que não ocultem interesses são
incentivadas, assim como a busca por acordos amigáveis e relações duradouras entre os stakeholders.
A justiça em atender da melhor forma possível todos os anseios é sempre buscada com a estratégia integrativa.
Estratégia distributiva
Nesta estratégia, segundo Ramires (2004), não existe processo de negociação diplomático, mas, sim, in�exível,
na qual as partes interessadas visam impor seus próprios interesses aos demais, sem se preocupar com as
necessidades e os interesses alheios.
Diferente da técnica integrativa, esta técnica utiliza estratégias de ganha-perde, que dependerá das habilidades
de convencimento acerca dos interesses de um em detrimento dos demais.
Pode-se utilizar a técnica de negociação �rme, sem receio de negociar e pedir concessões. Ganhará o jogo
aquele interessado que conseguir ocultar informações importantes sobre seus anseios, que possam prejudicar
outras partes, fazer concessões lentamente e analisando todos os pormenores, além de utilizar o tempo a seu
favor.
Dilema estratégico
As duas estratégias anteriormente descritas, a distributiva e a integrativa, se mostram con�ituosas, uma vez que
o objetivo da última é buscar um consenso de forma amigável e agradando a todas as partes, enquanto a
primeira busca apenas reclamar valor.
Sendo assim, as técnicas integrativas sempre serão vulneráveis às distributivas, uma vez que, mesmo que se
busque uma amistosidade entre as partes durante o processo de negociação de requisitos, é possível que, em
alguns momentos, os interessados apenas queiram reclamar o valor de seus interesses, negociando seus
interesses em prol de concessões de outras partes.
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 20/22
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática.
Bons estudos!
REQUISITOS MAL ESPECIFICADOS: CAUSAS E EFEITOS
O processo de elicitação de requisitos é o momento no qual o cliente deverá apresentar o negócio ao analista
de requisitos responsável, explicando as regras especí�cas do domínio envolvidas e suas necessidades e
expectativas para a aplicação que será construída.
Para projetos que se baseiam na metodologia tradicional cascata para a construção do software, esta fase será
a única na qual o cliente e o analista de requisitos terão a oportunidade de conversar, negociar requisitos e
compreender como o sistema deverá se comportar após a sua codi�cação. Desta forma, uma falha no
entendimento de uma funcionalidade ou do contexto no qual a aplicação está inserida poderá comprometer, de
forma negativa, todo o sucesso do projeto.
Muitas vezes, o cliente tem um grande conhecimento e ambientação com o domínio do negócio da aplicação, o
que o leva a crer que todas as demais pessoas também conhecem as regras de negócio intrínsecas a este
domínio e, por conta disso, não é necessária nenhuma explicação. Quando o projeto tem a fase de codi�cação
iniciada, após a elicitação de requisitos, estas regras de negócio omitidas podem ocasionar falhas na
implementação, gerando descontentamento ao usuário e a inutilização do sistema criado.
Quando a metodologia de desenvolvimento de softwares adotada pela equipe é ágil, em contraste com o que
acontece com a metodologia cascata, é possível ajustar o entendimento e alterar a escrita do detalhamento dos
requisitos ao longo do processo de codi�cação, antes que a funcionalidade tenha sido implementada, sem
prejuízos para o processo. Essas dúvidas podem surgir a partir da própria equipe de desenvolvimento, que irá
saná-las junto ao cliente.
Para minimizar os riscos de retrabalho e insucesso do projeto, é necessário que a escrita dos requisitos re�ita a
real necessidade do cliente e que o entendimento das regras de negócio consiga ser claro e sólido o su�ciente
pelo analista de requisitos responsável pela elaboração do documento de especi�cação de requisitos.
Uma outra causa da má elaboração das especi�cações de requisitos é a falta de experiência do analista na
aplicação das técnicas necessárias para a fase de elicitação dos requisitos do projeto, ou até o desconhecimento
das técnicas utilizadas. Di�cilmente, apenas com entrevistas, um cliente destrinchará todas as funcionalidades e
suas nuances de maneira desejável, de forma que, através da utilização das técnicas corretas nos momentos
corretos da fase de elicitação, será possível obter informações importantes que não foram mencionadas em um
primeiro momento.
Quando um projeto possui diferentes partes interessadas, com eventuais con�itos de interesses, saber ouvir
todas as partes e chegar à etapa de concordância dos requisitos e à priorização destes de maneira adequada
evitará que o projeto, no momento de sua �nalização, seja invalidado, já que atenderá às necessidades de todos
(ou pelo menos da maioria) dos stakeholders de forma satisfatória.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 21/22
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá quais são as causas e consequências de uma compreensão
insu�ciente do negócio, por parte do analista de requisitos, ocasionandorequisitos mal elaborados. Aprender
também sobre o processo de negociação de requisitos, suas técnicas e como aplicá-las de forma e�ciente e
e�caz.
Bons estudos!
 Saiba mais
Para saber mais detalhes sobre o processo de especi�cação de requisitos e sua importância para a
metodologia tradicional cascata, recomendo a leitura do artigo disponível em:
http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf.
Para metodologias ágeis, você poderá saber mais sobre o processo de engenharia de requisitos através do
artigo disponível em:
https://conteudo.catolica.edu.br/conteudos/nbt_cursos/engenharia_requisitos/tema_04/leituras/Tema_4_-
_Saiba_mais_-_Engenharia_de_Requisitos_em_Metodologia_%C3%81geis.pdf. 
Videoaula
Para visualizar o objeto, acesse seu material digital.
Aula 1
BROOKS, F. P.; BULLET, N. S. Essence and accidents of software engineering. IEEE computer, v. 20, n. 4, p. 10-19,
1987.
ELGABRY, O. Requirements Engineering – Introduction (Part 1). Medium, 2016. Disponível em:
https://medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3. Acesso
em: 19 jul. 2022.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 26551:2016. Engenharia de software e
sistemas – Ferramentas e métodos para engenharia de requisitos de linha de produto. [S. l.]: ISO, 2016.
Disponível em: https://www.iso.org/standard/69530.html. Acesso em: 19 jul. 2022.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo, SP: Pearson, 2011.
SUTCLIFFE, A. G. Requirements Engineering. Interaction Design Foundation, 2017. Disponível em:
https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-
ed/requirements-engineering. Acesso em: 19 jul. 2022.
ZAVE, P. Classi�cation of research e�orts in requirements engineering. ACM Computing Surveys (CSUR), v. 29,
n. 4, p. 315-321, 1997.
Aula 2
REFERÊNCIAS
2 minutos
http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf
https://conteudo.catolica.edu.br/conteudos/nbt_cursos/engenharia_requisitos/tema_04/leituras/Tema_4_-_Saiba_mais_-_Engenharia_de_Requisitos_em_Metodologia_%C3%81geis.pdf
https://medium.com/omarelgabrys-blog/requirements-engineering-introduction-part-1-6d49001526d3
https://www.iso.org/standard/69530.html
https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/requirements-engineering
29/03/2023, 15:24 wlldd_222_u1_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 22/22
Imagem de capa: Storyset e ShutterStock.
ESCOLA NACIONAL DE ADMINISTRAÇÃO PÚBLICA. Gerência de Projetos – Teoria e Prática. Módulo 2:
Gerenciamento de Escopo, Tempo e Custos do Projeto. Brasília, DF: ENAP, 2014. Disponível em:
https://repositorio.enap.gov.br/bitstream/1/1109/1/GerenciaDeProjeos_modulo_2_�nal_.pdf. Acesso em: 8 ago.
2022.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
Aula 3
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
TURINE, M. A. S.; MASIERO, P. C. Especi�cação de Requisitos: uma introdução. São Carlos, SP: Universidade de
São Carlos, 1996. Disponível em: http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf.
Acesso em: 15 ago. 2022. 
Aula 4
RAMIRES, J. J. da C. V. Negociação de Requisitos no Processo de Desenvolvimento de Software. 2004.
Dissertação (Mestrado em Informática) – Universidade de Lisboa, Lisboa, 2004. Disponível em:
https://repositorio.ul.pt/handle/10451/13961. Acesso em: 19 ago. 2022.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
https://storyset.com/
https://www.shutterstock.com/pt/
https://repositorio.enap.gov.br/bitstream/1/1109/1/GerenciaDeProjeos_modulo_2_final_.pdf
http://www2.unemat.br/rhycardo/download/engenharia_de_requisitos.pdf
https://repositorio.ul.pt/handle/10451/13961
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 1/22
Imprimir
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá como realizar a especi�cação dos requisitos de software, classi�cando os requisitos
em funcionais e não funcionais e identi�cando-os de forma correta.
Apresentaremos métodos de levantamento destes requisitos e como você poderá de�nir os requisitos
necessários para a sua aplicação de forma assertiva. É preciso ter em mente que esta fase é a mais importante
em todo processo de desenvolvimento de uma aplicação, de modo que um requisito não especi�cado
corretamente poderá levar a graves consequências para o seu projeto, até mesmo podendo não satisfazer
corretamente às necessidades dos patrocinadores (clientes), culminando no fracasso do produto criado.
Bons estudos! 
PROCESSOS DE ESPECIFICAÇÃO DE REQUISITOS
A primeira parte de um projeto de software é o processo de especi�cação dos requisitos de um sistema,
independentemente da metodologia de desenvolvimento adotada pela equipe.
Todo o processo de especi�cação de requisitos requer entrevistas com o cliente (ou seus representantes, que
denominamos de parte interessada no produto), com o intuito de escrever um artefato descrevendo o
requisito, sua importância para o sistema e a sua prioridade no desenvolvimento do produto. Porém, nem
sempre o cliente consegue descrever com clareza como a aplicação que será construída deverá funcionar, ou
seja, como os requisitos da aplicação precisarão estar especi�cados e construídos e como será a interação entre
eles.
Aula 1
ESPECIFICAÇÃO DE REQUISITOS
Nesta aula, você aprenderá como realizar a especi�cação dos requisitos de software,
classi�cando os requisitos em funcionais e não funcionais e identi�cando-os de forma correta.
26 minutos
CLASSIFICAÇÃO DE REQUISITOS DE SOFTWARE
 Aula 1 - Especi�cação de requisitos
 Aula 2 - Atividades da engenharia de requisitos
 Aula 3 - Análise de requisitos
 Aula 4 - Modelagem de requisitos
 Referências
107 minutos
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 2/22
O objetivo do processo de levantamento de requisitos é auxiliar a equipe de desenvolvimento na construção da
aplicação. Portanto, precisará conter as regras de negócio, as regras de validação (aceitação) e as respostas
esperadas para a ação (requisito ou funcionalidade) realizada no sistema.
Requisitos podem ser classi�cados como sendo de usuário ou de sistema. Requisitos de usuário são
especi�cados em linguagem natural, sem muito detalhamento (ou seja, nível macro), muitas vezes utilizando
diagramas auxiliares para representação da funcionalidade aos usuários �nais. Requisitos de sistema, por sua
vez, são descrições detalhadas de como os requisitos do usuário devem funcionar e interagir entre si,
representando o nível de entendimento necessário para a equipe de desenvolvimento poder implementar o
produto desejado.
É importante que você tenha mais de uma visão de um mesmo requisito (a macro e a detalhada), tendo em
vista que cada visão será apresentada a pessoas diferentes (cliente ou desenvolvedor) e precisará ter o
entendimento comum para todas elas.
A escrita de um requisito pode ser feita, a princípio, em linguagem natural, ou seja, em linguagem simples e
concisa, que expresse a necessidade do usuário. Cada requisito precisa especi�car apenas uma função do
sistema ou produto que será desenvolvido.
A linguagem natural estruturada, conforme menciona Sommerville (2011), também pode ser utilizada, na qual
um formulário padrão pode ser preenchido com os campos que estarão envolvidos no requisito e suas
respectivas descrições, fornecendo informações técnicas sobre a funcionalidadeque está sendo especi�cada.
Para auxiliar no processo de especi�cação de um requisito, alguns diagramas ou documentos podem ser
construídos, como os diagramas de caso de uso ou o documento da história (ou estória) de usuário.
Caso de uso
Um caso de uso terá, por objetivo, descrever, de forma visual, um cenário que represente a interação do
usuário com o sistema. Desse modo, é possível conhecer quais os atores que estarão envolvidos em cada
interação e quais funcionalidades o sistema provê.
A Figura 1 apresenta um exemplo de como um caso de uso pode ser elaborado.
Figura 1 | Exemplo de caso de uso para manipulação de livros em um sistema
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 3/22
Fonte: elaborada pela autora.
A Figura 1 apresenta, para um exemplo de manipulação de livros através de um sistema, as operações básicas
que um usuário externo poderá fazer, como a inserção de um novo livro, a alteração de um livro já cadastrado e
a consulta a livros.
História (ou estória) de usuário
Em times que adotaram metodologias ágeis para o desenvolvimento de novos produtos, como a SCRUM, as
histórias de usuário são escritas como documentos que substituirão o documento de especi�cação de
requisitos e diagramas auxiliares (como os casos de uso), apresentando como a interação acontecerá entre o
usuário �nal e a funcionalidade do sistema, qual a resposta esperada e quais os critérios de aceitação para que
o requisito possa ser dado como pronto (ou seja, que satisfaça a necessidade do usuário).
Um exemplo de história de usuário para o cenário de inclusão de novo livro, apresentado na Figura 1, �caria
como exibido no Quadro 1.
Quadro 1 | Exemplo de história de usuário
Eu, funcionário da biblioteca, preciso inserir um novo livro no sistema
Para que o livro �que disponível para consulta e locação aos alunos.
Critérios de validação:
[01] – Livro não pode ser cadastrado duas vezes
Dado que – o funcionário da biblioteca já cadastrou um livro anteriormente
Quando – estiver cadastrando um novo livro
Então – o sistema deve apresentar a mensagem “Este livro já foi cadastrado” e não permitir o cadastro do
livro de forma repetida.
Fonte: elaborado pela autora.
REQUISITOS FUNCIONAIS
Os requisitos funcionais representam as ações do sistema que serão utilizadas pelo usuário �nal, ou seja, como
o sistema (ou aplicação) deverá reagir às interações do usuário. Em suma, será toda função disponível ao
usuário �nal e que se espera que o sistema forneça (seu propósito).
É importante que, ao realizar o mapeamento das funcionalidades que o sistema deve prover, a escrita englobe
apenas um único requisito por vez. Além de facilitar o desenvolvimento pela equipe de programação, facilitará o
entendimento do usuário �nal e a validação dos requisitos com as reais necessidades das partes interessadas
(stakeholders).
Estes requisitos precisam estar mapeados no documento de especi�cação de requisitos, elaborado pela equipe
de levantamento das especi�cações do produto, e precisam estar em linguagem clara e com o detalhamento
adequado para que os desenvolvedores possam realizar a codi�cação.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 4/22
Quando os requisitos de um sistema são mapeados, é fundamental que o cliente de�na quais devem ser
priorizados, ou seja, quais agregarão mais valor ao produto que será entregue ao �nal do projeto. Essa
priorização, caso o time esteja trabalhando em cima de metodologias ágeis para desenvolvimento de sistemas,
poderá ser alterada ao longo do projeto. Para metodologias tradicionais, como a cascata, é fundamental que
todo o processo de especi�cação de requisitos seja totalmente de�nido antes do projeto começar de fato, sem
a possibilidade de alteração após o início da construção.
Alguns exemplos de requisitos funcionais são:
Cadastro de dados de entidades mapeadas (livro, carro, pessoa, jogo etc.).
Alterações de dados.
Consultas.
Extração de relatórios.
Remoção de dados.
Muitas vezes, o cliente que está auxiliando a equipe de desenvolvimento a mapear os requisitos funcionais não
tem total clareza sobre como a funcionalidade deve ser provida pelo sistema, deixando dubiedades ou até
detalhes técnicos do negócio (como as regras de validação) ocultos até o momento da implementação.
Para sanar qualquer eventual dúvida ou falta de clareza na especi�cação de requisitos, é importante a utilização
de recursos que auxiliem a parte interessada na validação deles, como a prototipação. Protótipos funcionais,
que apresentarão o layout da tela e uma funcionalidade simulada através de linguagens voltadas para a camada
de apresentação (como a Javascript), darão uma maior clareza ao usuário �nal, o qual, por sua vez, poderá
realizar ajustes para atender às suas expectativas.
Todos os protótipos construídos na fase do levantamento de requisitos e da validação dos requisitos funcionais
serão reaproveitados na fase de implementação do sistema pela equipe de desenvolvedores.
Uma questão importante, quando se trata de requisitos funcionais, é que eles precisam estar de�nidos de
forma completa e consistente, ou seja, o usuário precisa de�nir todas as funcionalidades necessárias para o
sistema, e estas funcionalidades não podem ter critérios contraditórios. Como critérios contraditórios, entende-
se que uma funcionalidade não pode ter um critério que é desfeito por outra funcionalidade. 
REQUISITOS NÃO FUNCIONAIS
Requisitos não funcionais, por sua vez, são aqueles que servem como suporte aos funcionais, mas que não são
percebidos (ou visíveis) ao usuário �nal. Exemplo desta categoria de requisito são os requisitos de performance,
segurança, auditoria de informações (logs) e os demais requisitos que servem de suporte para o correto
funcionamento dos requisitos visíveis (funcionais).
Esta categoria de requisitos é mais crítica para o sistema que os requisitos funcionais, tendo em vista que, caso
aconteça alguma ação indevida do usuário �nal, como conseguir entrar no sistema sem ter passado pelas
etapas de validação de autenticação, todo o sistema estará comprometido, podendo até mesmo ser invalidado.
É comum que requisitos não funcionais estejam espalhados por várias partes do sistema, englobando, inclusive,
mais de um requisito funcional, até mesmo pela sua natureza (performance, segurança etc.).
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 5/22
O mapeamento dos requisitos não funcionais acontece através do entendimento de quais são as necessidades
de restrição das partes interessadas, como restrição de segurança, orçamento, interoperabilidade com outros
sistemas, políticas organizacionais, legislação de privacidade e segurança ou normas de segurança interna.
Conforme apresentado por Sommerville (2011) e Pressman e Maxim (2021), a origem dos requisitos não
funcionais podem ser:
Requisitos de produto: restringem o comportamento da aplicação, como questões de desempenho, taxa
aceitável de falhas, proteção e usabilidade do sistema.
Requisitos organizacionais: originados de políticas empresariais ou do cliente, como os processos
operacionais, processo de desenvolvimento (como a de�nição de uma linguagem de programação
especí�ca), ambiente de desenvolvimento ou normas de processo que precisam ser utilizadas.
Requisitos externos: abrangendo todo requisito externo ao sistema e seu desenvolvimento, como leis,
interoperabilidade com sistemas externos, ética etc.
Figura 2 | Tipos de requisitos não funcionais
29/03/2023, 15:25wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 6/22
Fonte: adaptada de Sommerville (2011).
A Figura 2 apresenta um resumo dos tipos de requisitos não funcionais, de acordo com as categorias
anteriormente apresentadas.
É relativamente comum que as partes interessadas ditem os requisitos não funcionais como metas ou objetivos
do sistema, como a facilidade de uso ou performance. Um ponto importante é que, caso sejam especi�cados
desta forma, os requisitos não funcionais podem ser difíceis de serem testados, tornando-se um ponto
subjetivo do sistema e abrindo brechas para diversos entendimentos.
A forma ideal para que um requisito não funcional seja especi�cado é quantitativamente, ou seja, da forma
mais objetiva possível (de preferência com números), a �m de que possam ser validados ou mensurados.
Porém, nem todo requisito não funcional poderá ser medido quantitativamente, o que indica que métricas
precisam ser adotadas para justi�car ou validar a implementação correta destes requisitos.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 7/22
Outro ponto importante de ser destacado é que, no documento de especi�cação de requisitos, é difícil realizar a
separação entre os requisitos funcionais dos não funcionais, tendo em vista que, em muitos casos, requisitos
não funcionais podem englobar um ou mais dos requisitos funcionais. Caso não se deixe clara a delimitação
entre a funcionalidade provida pelo sistema e os requisitos não funcionais que estão envolvidos nesta
funcionalidade, o entendimento poderá �car confuso para a equipe de desenvolvimento. Portanto, quando se
tem um requisito não funcional interligado a um requisito funcional, você deverá fazer o destaque na parte que
engloba o requisito não funcional. 
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá técnicas para levantamento e especi�cação de requisitos
funcionais e não funcionais, como montar o documento de especi�cação de requisitos e um modelo de como
escrever histórias de usuário. Por ser a fase mais importante para o desenvolvimento de um software, é muito
importante que você entenda e conheça as diversas abordagens para escrita e apresentação de requisitos, que
serão importantes para os mais diversos stakeholders (ou seja, partes interessadas no projeto).
 Saiba mais
Este artigo apresenta como especi�car requisitos de uma aplicação de forma simpli�cada, minimizando os
erros.
A ferramenta OpenReq é gratuita e voltada para o gerenciamento de requisitos.
A ferramenta SIGERAR também é gratuita e voltada para o gerenciamento e a rastreabilidade dos
requisitos durante todo o ciclo de vida da aplicação.
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá quais critérios podem ser levados em consideração no momento de priorizar os
requisitos de uma aplicação para seu desenvolvimento, assim como as técnicas que podem ser utilizadas para
auxiliar o processo de priorização e as ferramentas que podem auxiliar no processo de priorização.
Aula 2
ATIVIDADES DA ENGENHARIA DE REQUISITOS
Nesta aula, você aprenderá quais critérios podem ser levados em consideração no momento de
priorizar os requisitos de uma aplicação para seu desenvolvimento, assim como as técnicas que
podem ser utilizadas para auxiliar o processo de priorização e as ferramentas que podem auxiliar
no processo de priorização.
25 minutos
https://medium.com/lfdev-blog/como-escrever-requisitos-de-software-de-forma-simples-e-garantir-o-m%C3%ADnimo-de-erros-no-sistema-app-74df2ee241cc
https://openreq.eu/
https://github.com/francojmf/SIGERAR
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 8/22
A priorização dos requisitos especi�cados é fundamental para que as funcionalidades mais importantes, ou
seja, aquelas que agregam mais valor ao negócio do cliente e, consequentemente, ao produto construído, sejam
antecipadas em relação àquelas menos prioritárias (que agregam menos valor ao produto).
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas
esteja sempre buscando novas formas de se atualizar.
Bons estudos! 
CRITÉRIOS DE PRIORIZAÇÃO E NEGOCIAÇÃO DE REQUISITOS
Após a fase de entrevistas para o levantamento de requisitos junto ao cliente, é preciso priorizar os requisitos,
de modo a começar a construção do produto pelos requisitos que agregam mais valor ao produto, ou seja, que
sejam mais importantes ao usuário �nal.
Esta priorização dos requisitos levantados deve acontecer após os requisitos terem sido agrupados em grupos
com requisitos similares. A conclusão desta etapa resulta num modelo de arquitetura do produto que será
desenvolvido, apresentando onde cada requisito se encaixa no modelo.
Quando um produto envolve diferentes áreas e, consequentemente, possui diferentes patrocinadores, cada
qual com seus respectivos requisitos, é comum ocorrerem con�itos de interesses. Estes con�itos podem ser
resolvidos com a priorização dos requisitos, após reuniões de alinhamento entre estas diferentes partes
interessadas e analisando a relação entre benefício do desenvolvimento versus custo para implementação.
Muitas vezes, algumas funcionalidades dependem da implementação de outras, o que ocasiona na priorização
destes pré-requisitos, para que as demais funções dependentes possam ser codi�cadas.
Quando um consenso não é alcançado, através de reuniões com os stakeholders (partes interessadas), �ca
muito difícil para o analista de requisitos ou o líder de projetos indicar para a equipe de desenvolvimento quais
funcionalidades agregam mais valor, tendo em vista que isso dependerá do negócio do cliente e de todas as
questões que envolvem o projeto, como prazo e limitação de orçamento.
Quando nos referimos às metodologias tradicionais de desenvolvimento de projetos, como a cascata, a
priorização dos requisitos deverá estar concluída antes que a fase de implementação do produto seja iniciada e
não poderá ser alterada após este início. Sendo assim, um erro no planejamento desta priorização poderá
ocasionar em invalidação do produto pelo cliente, no momento da entrega e validação, causando prejuízo tanto
para o cliente quanto para a empresa que desenvolveu o produto.
Em equipes que seguem as metodologias de desenvolvimento ágeis, como a SCRUM, para cada ciclo de entrega
deverá ser feita a priorização dos requisitos que serão detalhados e implementados pela equipe. Estes
requisitos detalhados são provenientes de uma lista com os requisitos macros, priorizados de acordo com a
necessidade do cliente. Ao longo do processo de desenvolvimento, é possível alterar a prioridade dos requisitos,
conforme as necessidades forem mudando, de modo a sempre adequar o que será entregue ao cliente com a
sua real necessidade do momento.
A priorização não dependerá do detalhamento dos requisitos para acontecer, de modo que tornar o processo
mais simples, até mesmo ainda utilizando o nível macro de especi�cação, poderá facilitar o entendimento das
partes interessadas e, consequentemente, o processo como um todo.
Uma outra questão importante a ser levada em consideração no momento da priorização dos requisitos é a
complexidade técnica e a di�culdade de implementação. Esta percepção é tida pela equipe de desenvolvimento,
que pode, junto ao cliente, auxiliar a resolução de con�itos de interesses das partes interessadas e de�nir quais
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI…9/22
funcionalidades estarão presentes na próxima entrega do produto.
TÉCNICAS DE PRIORIZAÇÃO DE REQUISITOS
Para realizar o processo de priorização de requisitos, é fundamental a utilização de técnicas de priorização,
tendo em vista que muitos con�itos de interesses podem existir entre os patrocinadores, resultando em
diferentes pontos de vista em termos de quais requisitos devem ser antecipados em sua implementação.
Nem sempre é algo trivial para a equipe de desenvolvimento, principalmente ao analista de requisitos, ao líder
técnico ou ao product owner (dono do produto, na metodologia SCRUM) inferir quais as funcionalidades que
mais agregam valor ao sistema que está sendo desenvolvido e atendem às principais necessidades do cliente.
Sendo assim, é imprescindível a participação do cliente neste processo de priorização, mas este, por sua vez,
pode também ter di�culdades em de�nir o grau de importância dos requisitos levantados.
Para auxiliar na classi�cação dos requisitos, em termos de priorização, existem as técnicas de priorização, como
a utilização de escalas de priorização, similares às apresentadas na Tabela 1. Conhecida como Nominal Scale,
esta técnica considera que requisitos que estejam organizados dentro do mesmo grupo possuem o mesmo
nível de importância e, consequentemente, a mesma prioridade.
Quadro 1 | Modelo de priorização de requisitos baseado em criticidade
Priorização do requisito
Signi�cado
Alto Compõe o coração do sistema, agrega valor à próxima entrega.
Médio Apesar de implementar operações importantes, pode aguardar.
Baixo Ajustes e melhorias funcionais. É desejável, mas não obrigatório.
Fonte: adaptado de Generoso (2019).
O Quadro 1 apresenta a classi�cação pelo nível de criticidade do requisito, agrupado na escala alto, médio ou
baixo. A partir desta priorização, busca-se entrar em consenso com as partes interessadas sobre quais
requisitos serão implementados em cada entrega do produto.
Requisitos que sejam mandatários para a implementação de outras funcionalidades tendem a ser classi�cados
como de maior prioridade, tendo em vista que a interdependência com outros requisitos é alta.
Uma escala semelhante, que agrupa os requisitos em termos de quão essencial este o é para agregar valor ao
produto, é apresentada no Quadro 2.
Quadro 2 | Priorização dos requisitos baseado em obrigatoriedade
Priorização do requisito Signi�cado
Essencial Sua ausência invalida o produto.
Condicional Agrega melhorias, mas a falta não invalida o produto.
Opcional Sua implementação pode ser feita ou não, mas não é algo mandatório.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 10/22
Fonte: adaptado de Generoso (2019).
O Quadro 2 apresenta uma classi�cação por obrigatoriedade dos requisitos para o produto, de modo que se
tem como essencial aquele requisito obrigatório no sistema/aplicação; condicional para os requisitos que
agregam melhorias, mas que a falta não implica invalidação do produto; por último, os requisitos tidos como
opcionais, que podem ou não ser implementados, não fazendo falta caso não estejam presentes.
Uma técnica amplamente utilizada para priorização dos requisitos junto aos stakeholders se baseia na
quantidade de dependências de uma funcionalidade em relação às demais e na preferência das partes
interessadas em termos do que pode estar agregando mais valor ao produto. Essa técnica depende muito do
fator humano para sua aplicação, tendo em vista que as dependências são informadas pela equipe de
desenvolvimento, com base em experiências anteriores dos membros da equipe.
A técnica Ordinal Scale, por sua vez, realiza a comparação entre dois requisitos para avaliar qual dos dois será
mais importante ao produto. O objetivo será montar uma lista ordenada com as funcionalidades listadas por
ordem de implementação.
Existe também a técnica Ratio Scale, que utiliza uma escala de decisão para decidir pela priorização dos
requisitos de forma mais precisa que as outras duas técnicas (ordinal e nominal), já que identi�ca a diferença
relativa entre os requisitos. As técnicas ordinal e nominal auxiliarão apenas na classi�cação dos requisitos.
FERRAMENTAS NA ENGENHARIA DE REQUISITOS
Não somente técnicas de priorização de requisitos são importantes para ordenar, de forma coerente com as
necessidades do usuário �nal, as funcionalidades especi�cadas para o produto. Existem também ferramentas
que podem auxiliar no processo de priorização.
Com as ferramentas, é possível enxergar com mais precisão os relacionamentos entre os requisitos, assim
como fatores que podem classi�cá-los como mais ou menos prioritários, em relação às outras funcionalidades.
A primeira ferramenta que apresentaremos é a Matriz de Priorização. Com ela, é possível estabelecer quais
funcionalidades precisam ser implementadas em qual ordem, de acordo com critérios claros e bem de�nidos,
evitando descumprimento de prazos e garantindo foco naquilo que realmente precisa estar pronto. Ela é
construída em formato de tabela, grá�co ou quadrante, �cando a cargo da equipe qual a melhor forma de
representação.
Um benefício da utilização da Matriz de Priorização é que as partes interessadas estarão cientes dos prazos
estabelecidos para construção de cada funcionalidade, se acontecerá algum atraso ou imprevisto, sendo
possível renegociar prazos ou alterar a ordem de prioridade de algum requisito de forma mais consciente.
Para montar sua tabela, os seguintes passos precisam ser seguidos:
1. Listagem das funcionalidades que precisarão ser priorizadas.
2. Estabelecimento de critérios de seleção, representando quais condições serão levadas em consideração
para a seleção dos requisitos. Podem ser considerados critérios a urgência, gravidade, tendência, benefício,
satisfação do cliente etc.
3. Atribuir uma pontuação para cada critério especi�cado, utilizando-se uma escala (como de 1 a 5), onde 1
representa pouco importância para o critério e 5 muita importância para o critério. Esta escala deverá ser
utilizada para todos os requisitos envolvidos.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 11/22
4. Montar uma tabela com as informações levantadas, na qual as linhas conterão as funcionalidades
(requisitos), e as colunas, os critérios especi�cados, preenchendo qual a “nota” atribuída para cada critério,
conforme a funcionalidade.
5. Associar as pontuações para cada funcionalidade, executando operações, como soma, multiplicação ou
divisão, que serão aplicadas conforme o método de matriz escolhido. O resultado desta etapa será o
ranqueamento de cada demanda, que expressará a ordem de prioridade que deverá ser seguida pela
equipe de desenvolvimento.
Matrizes de Priorização podem ser, conforme apresenta Justo (2019), dos seguintes tipos:
GUT: considerará critérios, como a urgência, a gravidade e a tendência, realizando a operação de
multiplicação ao �nal do processo de atribuição de pesos (na escala de 1 a 5 para cada critério).
BASICO: considera os seguintes critérios: benefícios para a empresa, abrangência dos resultados,
satisfação do cliente, investimento requerido, cliente externo satisfeito e operacionalidade simples. Cada
critério receberá uma pontuação, obedecendo à escala de 1 a 5, aplicando a operação de soma em vez da
multiplicação.
RICE: considera os critérios reach (quantidade de pessoas impactadas pela funcionalidade); impact
(impacto da demanda, que pode ser classi�cado em massivo (3 pontos), grande (2 pontos), médio (1
ponto), baixo (0,5 ponto) e mínimo (0,25 ponto)); con�dence (nível de con�ança no resultado, também
classi�cado em escala, que pode ser alto (100%), médio (80%), baixo (50%) e mínimo (20%));e�ort
(esforço ou tempo necessário para implementar a demanda). O resultado é feito através da operação de
multiplicação das pontuações atribuídas para os critérios de reach, impact e con�dence, dividindo o
resultado pelo e�ort.
4X4: considera dois critérios, que podem ser escolhidos como os mais importantes por quem estiver
montando a matriz. A partir daí, um grá�co cartesiano pode ser construído com notas atribuídas aos dois
critérios, variando na escala de 1 a 4.
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá a importância da priorização dos requisitos especi�cados para uma
aplicação, como utilizar técnicas de negociação de con�itos de interesses, por parte dos stakeholders
envolvidos, além de quais as técnicas mais adequadas para a realização desta priorização, tão importante ao
produto que será construído. Aprenderá também quais ferramentas poderão ser utilizadas para auxiliar este
processo.
 Saiba mais
Para exemplos de utilização de Matriz de Priorização, recomendo a explicação neste link, que também
possui um modelo para construção da Matriz de Priorização GUT.
Videoaula
Para visualizar o objeto, acesse seu material digital.
https://ferramentasdaqualidade.org/matriz-gut-matriz-de-priorizacao/
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 12/22
Outros tipos de Matriz de Priorização podem ser encontrados em: https://dnc.group/blog/projetos/matriz-
eisenhower/?utm_source={{search}}&utm_medium=cpc&utm_campaign=blog-4-1-
1&gclid=CjwKCAjwkMeUBhBuEiwA4hpqEGsAL5OKpN6o_qs17GurHodeaIUEIkJtZFSIkP1mMyoBAkKkOlS80ho
CT1sQAvD_BwE. 
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá como um requisito é mantido e gerenciado ao longo do ciclo de vida de um projeto,
assim como sobre os cenários de uso dos requisitos e como elaborar casos de uso para os requisitos
elucidados.
Você verá exemplos práticos de elaboração do diagrama de casos de uso e o nível de abordagem que deverá
adotar para escrever seus requisitos funcionais e não funcionais.
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas
esteja sempre buscando novas formas de se atualizar.
Bons estudos! 
REQUISITOS NO CICLO DE VIDA DO PROJETO
Após a fase de coleta inicial dos requisitos funcionais e não funcionais de um sistema, do processo de validação
dos requisitos junto ao cliente e, por �m, da priorização conforme a necessidade das partes interessadas, é
chegada a hora da implementação do produto.
Ao dar início à fase de codi�cação, a equipe de desenvolvimento poderá ter dúvidas quanto ao que está escrito
no documento de especi�cação de requisitos, ou história de usuário, sendo necessário perguntar ao analista
que realizou as entrevistas com o cliente, evitando retrabalhos e codi�cação errada pela falha no entendimento.
Muitas vezes, durante o processo de construção da aplicação, o cliente se dá conta de que o que está sendo
desenvolvido não irá, de fato, satisfazer suas expectativas com o produto, solicitando mudanças nos requisitos
previamente levantados. Em metodologia tradicional de desenvolvimento, como a cascata, que os requisitos
precisam estar totalmente levantados e validados antes do início da fase de construção da aplicação, uma
alteração posterior de qualquer requisito pode representar a invalidação do projeto ou, em casos menos
drásticos, causar atraso no prazo de entrega acordado, com re�exos no orçamento, que será maior.
Já para projetos que utilizem metodologias ágeis ou que permitam modi�cações após a fase de especi�cação de
requisitos inicial, é possível alterar o documento de especi�cação e/ou história de usuário, para que se adeque
às novas necessidades apontadas pelo cliente. O time de desenvolvedores, por sua vez, precisará adequar a
Aula 3
ANÁLISE DE REQUISITOS
Nesta aula, você aprenderá como um requisito é mantido e gerenciado ao longo do ciclo de vida
de um projeto, assim como sobre os cenários de uso dos requisitos e como elaborar casos de
uso para os requisitos elucidados.
26 minutos
https://dnc.group/blog/projetos/matriz-eisenhower/?utm_source=%7b%7bsearch%7d%7d&utm_medium=cpc&utm_campaign=blog-4-1-1&gclid=CjwKCAjwkMeUBhBuEiwA4hpqEGsAL5OKpN6o_qs17GurHodeaIUEIkJtZFSIkP1mMyoBAkKkOlS80hoCT1sQAvD_BwE
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 13/22
aplicação que está sendo construída ao que foi solicitado como ajustes, garantindo que a entrega de valor ao
usuário será feita.
A priorização dos requisitos é um outro fator que também pode ser alterado a qualquer momento do ciclo de
vida do projeto, sempre buscando respeitar o nível de importância de cada requisito, de�nido pelas partes
interessadas.
Durante as fases de testes e entrega, após a apresentação ao cliente do que foi construído, ainda podem ser
solicitados ajustes, que precisarão ser negociados com o analista de requisitos (ou product owner, em caso de
utilização da metodologia ágil SCRUM), para que o time de desenvolvedores possa fazer o melhor para atender
às solicitações, respeitando o orçamento e o prazo acordados.
Uma vez que a aplicação seja entregue ao cliente �nal, novos requisitos e necessidades ainda podem surgir, o
que precisará realizar um gerenciamento de mudanças, por parte do analista responsável pela fase de
levantamento de requisitos iniciais, para garantir que, mesmo após a solicitação das alterações nos requisitos já
levantados (e, muitas vezes, até já implementados), o histórico das alterações possa ser mantido.
Garantir que o documento de requisitos esteja de acordo com a realidade do código construído auxiliará o
entendimento de novos integrantes da equipe de desenvolvedores, da mesma forma que dirimir eventuais
dúvidas futuras sobre as regras de negócio pelos membros da equipe de desenvolvimento e/ou manutenção
(sustentação).
Alguns fatores podem desencadear alterações ou surgimento de novas funcionalidades. Sommerville (2011) e
Pressman e Maxim (2021) destacam, como sendo os principais, os seguintes:
Alteração nos equipamentos de hardware disponíveis, em legislações ou prioridades do negócio.
Diferença de interesses entre os patrocinadores e os usuários �nais do sistema que está em
desenvolvimento.
Con�ito de interesses em sistemas com muitos interessados, gerando necessidades e prioridades
diferentes e, em muitos casos, até contraditórias.
CENÁRIOS DE USO DE REQUISITOS
A especi�cação de um requisito se inicia pela sua forma macro, ou seja, pela descrição simples da
funcionalidade que deve ser provida pela aplicação. Deste modo, em um primeiro momento, o cliente não
especi�cará detalhes de quais regras de negócio a funcionalidade implementará, nem quais os tipos de campos
existentes que serão manipulados ou até quais os per�s que terão acesso e quais não terão.
Para garantir que a equipe de desenvolvimento possa entender, de forma técnica, o que está sendo solicitado
pelo cliente, é preciso que ocorra um detalhamento de como o requisito deverá funcionar, com suas regras de
negócio, interações com outras telas (ou módulos do sistema e até de outros sistemas, caso ocorra), permissões
de acesso ou utilização da funcionalidade, mensagens de erro que devem ser apresentadas, em caso de alguma
inconsistência na entrada de dados, entre outras questões técnicas.
A este detalhamento de um requisito damos o nome de cenários de caso de uso. Os tipos de cenários de caso
de uso existentes podem ser classi�cados como:
Principal: �uxo considerado esperado para a funcionalidade mapeada, ou seja, o “caminho feliz” com as
entradas esperadas e a resposta esperada para o requisito.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade…14/22
Alternativos: �uxos que podem estar mapeando ações adversas que o usuário pode estar executado, que
foge do caminho principal a ser percorrido, como ausência de preenchimento de campos obrigatórios,
escolhas de opções que não sejam a opção para o �uxo principal etc. São ações que alteram o
comportamento da aplicação, ao ponto de desviar as respostas fornecidas como padrão.
Exceção: um �uxo de exceção compreende erros ou bugs que podem acontecer durante a execução de
uma funcionalidade. Por exemplo: se você está executando uma funcionalidade de pagamento de uma
compra e a máquina do cartão não consegue estabelecer uma conexão com o banco responsável pelo
cartão que está sendo utilizado, então aconteceu um �uxo de exceção.
Os cenários de caso de uso se aplicam somente aos requisitos funcionais do sistema, já que estes representam
as ações que devem ser implementadas e providas ao usuário �nal. Os requisitos não funcionais acabam
fazendo parte do detalhamento dos casos de uso funcionais, tendo em vista que são considerados transversais
e acabam englobando uma ou mais funcionalidades do sistema.
Quanto mais �uxos alternativos forem levantados e documentados, assim como as possíveis exceções que
podem acontecer, melhor será a resposta do sistema ao comportamento do usuário e mais “blindada” sua
aplicação estará contra os mais variados tipos de comportamento de seus usuários �nais. As exceções serão
úteis para apresentar mensagens amigáveis ao usuário �nal, em caso de alguma falha acontecer.
Um �uxo alternativo aparece no diagrama de caso de uso como uma ação estendida, utilizando a indicação
<<extend>>. Um exemplo está apresentado na Figura 1.
Figura 1 | Exemplo de �uxo alternativo em diagrama de caso de uso
Fonte: elaborada pela autora.
Conforme ilustrado na Figura 1, o ator Usuário RH poderá utilizar a funcionalidade Cadastrar aluno, que
deverá ter, como �uxo alternativo, a situação na qual um aluno já está cadastrado. Então, Aluno já cadastrado
estende da funcionalidade Cadastrar aluno.
CASO DE USO DE REQUISITOS
Para escrever um requisito, de forma que seja validado pelo cliente e possa, posteriormente, ser implementado
pela equipe de desenvolvimento, é preciso que haja uma concordância em relação a como o sistema deve se
comportar entre todos os envolvidos (stakeholders) como patrocinadores.
É preciso, para que a validação do requisito possa ocorrer, que várias visões de um mesmo requisito sejam
elaboradas, iniciando-se pela especi�cação em linguagem natural, que se converterá em diagramas de casos de
uso, para traduzir, visualmente, as interações entre os diferentes papéis na aplicação e as funcionalidades por
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 15/22
ela providas.
Um diagrama de caso de uso apresentará, segundo Larman (2000), de forma visual e clara, todas as interações
entre um determinado ator (usuário �nal, por exemplo) e as funções por ele usadas, conforme apresentado na
Figura 2.
Figura 2 | Exemplo de diagrama de caso de uso
Fonte: elaborada pela autora.
A Figura 2 apresenta um exemplo de diagrama de caso de uso para uma aplicação de cadastro de alunos. Neste
caso, o ator (usuário do RH) poderá executar as funções de cadastrar aluno, alterar cadastro de aluno e
desativar cadastro de aluno. Para outros atores, outras funcionalidades podem ser associadas, deixando claro
para os stakeholders envolvidos quais papéis de usuário poderão fazer que tipo de ação no sistema.
Um caso de uso possui alguns elementos visuais básicos para sua construção:
Ator: usuário ou sistema que realizará uma funcionalidade na aplicação.
Casos de uso: ações que representarão os requisitos funcionais e que serão executadas pelo ator.
Relacionamentos: setas que indicam o �uxo de quem executará qual ação. Poderão representar uma
resposta (quando o sistema fornece um retorno para o ator ou outra funcionalidade) ou uma requisição
(quando o ator executa alguma ação).
Um ator pode ser também um outro sistema ou módulo, que possua algum tipo de interação com a aplicação
que será construída. Um bom exemplo é a integração entre diferentes sistemas, em uma mesma organização,
para compartilhamento de informações e/ou utilização de APIs, tanto para realização de consultas como
cadastros de dados.
Após a construção de todos os casos de uso, mapeando a interação entre os diferentes atores e as
funcionalidades providas pela aplicação, será necessário detalhar os casos de uso mapeados, ou seja,
especi�car os �uxos do caso de uso, seja um �uxo principal (entradas e respostas esperadas) ou �uxos
alternativos (entradas faltantes, com caracteres não permitidos, sequência de comandos inadequada etc.).
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 16/22
Os �uxos alternativos servirão como critérios de validação da correta implementação do caso de uso, da mesma
forma que acontece com o �uxo principal. Caso algum problema seja encontrado pela equipe que está
realizando os testes na funcionalidade, o �uxo no qual o desvio de comportamento foi notado será apontado
para que a equipe de desenvolvimento possa realizar as devidas correções.
Além dos diagramas de casos de uso, outros diagramas UML podem ser utilizados para dar mais clareza aos
interessados, em termos de entendimento das funcionalidades especi�cadas, como os diagramas de
sequência. 
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá a importância do gerenciamento dos requisitos ao longo de um
projeto, como escrever um caso de uso e qual o nível de abordagem adequado para as visões macro e
detalhada de um requisito, seja ele funcional ou não funcional. Serão apresentados exemplos práticos, para que
você possa compreender toda a teoria abordada.
Bons estudos!
 Saiba mais
Uma boa ferramenta gratuita para gerenciamento de requisitos e acompanhamento do trabalho do time
de desenvolvimento é a Trello ou a Ummense.
Para criar seus diagramas de caso de uso gratuitamente, você poderá utilizar a Yuml, a Ceately ou a Visual
Paradigm. 
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá quais são os artefatos gerados no processo de levantamento de requisitos, além da
forma como o levantamento de requisitos acontece com metodologias ágeis e quais artefatos são construídos e
mantidos com estas metodologias. Abordaremos também os requisitos voltados para sistemas autoadaptativos,
voltados para sistemas que podem alterar seu comportamento em tempo de execução, conforme sua
necessidade, re�etida pelo ambiente no qual estão inseridos, sem nenhuma intervenção humana.
Aula 4
MODELAGEM DE REQUISITOS
Nesta aula, você aprenderá quais são os artefatos gerados no processo de levantamento de
requisitos, além da forma como o levantamento de requisitos acontece com metodologias ágeis e
quais artefatos são construídos e mantidos com estas metodologias.
28 minutos
https://trello.com/
https://www.ummense.com/
https://yuml.me/diagram/scruffy/class/draw
https://creately.com/
https://online.visual-paradigm.com/pt/diagrams/features/uml-tool/
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 17/22
Lembre-se de que o seu conhecimento só dependerá de você, então não se limite apenas ao visto na aula, mas
esteja sempre buscando novas formas de se atualizar.
Bons estudos! 
ARTEFATOS DO LEVANTAMENTO DE REQUISITOS
Artefatos são produtos gerados como resultados de uma fase (ou processo). Quando nos referimos à fase da
especi�caçãode requisitos, os artefatos gerados são elaborados como resultado das entrevistas com o cliente,
para levantamento das funcionalidades da aplicação que será desenvolvida, assim como do re�namento destes
requisitos e das eventuais mudanças que, eventualmente, podem ocorrer nos requisitos já especi�cados.
O documento de especi�cação de requisitos é tido como o principal documento que conterá os requisitos
(funcionais e não funcionais) necessários para que a equipe de desenvolvimento possa construir a aplicação.
Este documento precisa ser criado e mantido, com as devidas atualizações, ao longo de todo projeto, tendo em
vista que é por ele que os desenvolvedores se basearão e, em caso de dúvidas em regras de negócio, consultar.
Ainda neste documento, é importante constar os diagramas que foram construídos para as diferentes visões
dos requisitos, facilitando o processo de validação pelo cliente (e demais partes interessadas). Então,
diagramas de caso de uso e diagramas de sequência podem fazer parte do texto que precede os requisitos
especi�cados.
A Figura 1 apresenta um exemplo de um diagrama de sequência para o cadastro de um paciente no sistema.
Figura 1 | Exemplo de diagrama de sequência para cadastro de pacientes no sistema
Fonte: elaborada pela autora.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 18/22
Conforme apresentado na Figura 1, o ator usuário interagirá com a tela de cadastro de pacientes para que um
paciente seja inserido no banco de dados da aplicação. O objetivo deste diagrama é apresentar uma sequência
de passos que serão executados e/ou retornados pelo/ao cliente. O cliente, então, iniciará a interação com o
sistema a partir do preenchimento dos dados da tela do cadastro de paciente que terão os dados validados (ou
não) pela classe paciente. Caso os dados não sejam validados corretamente, seguindo as regras de negócio,
mensagens de dados inválidos ou paciente já cadastrado poderão ser retornadas ao ator (usuário),
interrompendo o �uxo. Se o processo de validação for concluído com sucesso, então os dados serão inseridos
no banco de dados e uma mensagem de paciente cadastrado com sucesso será retornada ao usuário que
criou a requisição.
Os diagramas de caso de uso apresentarão as interações entre os atores e as funcionalidades do sistema,
enquanto os diagramas de sequência apresentarão a sequência de passos para uma determinada
funcionalidade, desde a criação da requisição pelo usuário �nal até a resposta entregue pelo sistema, após o
processamento da requisição, numerando a ordem dos passos.
Outro artefato importante são as requisições de mudança, geradas sempre que um requisito já especi�cado
precisa sofrer alterações (apenas para se adequar à necessidade do usuário �nal) ou quando uma nova
funcionalidade será implementada no sistema (caracterizando a manutenção evolutiva).
Quando se utiliza a prototipação como ferramenta auxiliar para validação das funcionalidades pelo cliente, os
protótipos construídos também são considerados artefatos de saída desta fase, já que serão repassados à
equipe de desenvolvimento para que o design já acordado para o sistema possa ser mantido.
A Figura 2 apresenta um exemplo de diagrama de caso de uso para o cenário apresentado na Figura 1.
Figura 2 | Exemplo de caso de uso para pacientes
Fonte: elaborada pela autora.
Conforme apresentado na Figura 2, a visão do caso de uso tende a ser mais macro que a visão apresentada no
diagrama de sequência, que detalhará, para cada item de caso de uso, os passos necessários para executar a
ação. Sendo assim, o diagrama de caso de uso visa apresentar, de forma resumida, todas as interações
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 19/22
possíveis de um ator no sistema.
Outro ponto importante, que também gera um artefato da fase de especi�cação de requisitos, é o documento
contendo o glossário dos termos do negócio, que serão aplicados ao longo da construção do sistema. Muitas
vezes, um mesmo termo pode ter diferentes signi�cados, dependendo do contexto no qual é utilizado. O
glossário servirá como nivelamento para que todos, independentemente de qual setor pertençam, possam ter o
mesmo entendimento a respeito dos conceitos utilizados pelo negócio.
Após o acordo a respeito do design do sistema e dos demais documentos já mencionados, é importante que
você especi�que o modelo de arquitetura que servirá de base para a construção do sistema, com os
elementos de rede que serão utilizados, suas interconexões, a conexão com outros sistemas (caso ocorra),
entre outros pontos importantes para que, tanto os componentes de hardware sejam visíveis quanto, em
termos de sistema, a disposição das camadas da aplicação e suas respectivas classes possam ser especi�cadas.
O modelo de arquitetura de classes do sistema servirá como base para a equipe de desenvolvimento, enquanto
o modelo de arquitetura de hardware poderá ser apresentado e validado pelos stakeholders.
LEVANTAMENTO ÁGIL DE REQUISITOS
As metodologias ágeis de desenvolvimento têm por objetivo simpli�car o processo de construção de software,
de modo a atender de forma efetiva às necessidades do cliente. Isso é possível devido às constantes entregas
parciais do produto, o que faz com que o cliente dê feedbacks constantes e não precise esperar tanto tempo
(meses até) para utilizar o produto, uma vez que as partes entregues já podem ser implantadas em produção e
já podem ser utilizadas pelo usuário �nal.
Conforme Beck et al. (2001), é mais importante uma aplicação em funcionamento que manter uma
documentação abrangente e detalhada, o que implica a necessidade de simpli�car o processo de
documentação da aplicação somente ao essencial. Comentários de código e o documento contendo as
histórias ou estórias (�ca a cargo do time escolher a melhor denominação) de usuário serão, talvez, as únicas
documentações disponíveis em um projeto que seja construído através destas metodologias.
Diferente do processo tradicional, no qual todos os requisitos (funcionais e não funcionais) precisam ser
especi�cados antes do início do processo de codi�cação, com a metodologia ágil é possível especi�car apenas
um conjunto de requisitos logo no começo, tidos como os mais importantes para o negócio e para a
necessidade dos patrocinadores, porém essa lista pode crescer ao longo do andamento do projeto.
Para times que utilizam o framework SCRUM, um dos mais adotados pelas equipes de desenvolvimento na
atualidade para desenvolvimento de projetos ágeis, os requisitos podem ter níveis de especi�cação e
detalhamento diferentes, conforme apresenta Schwaber e Sutherland (2013), a depender da fase na qual eles
se encontram:
Backlog do produto: nesta fase, os requisitos estão especi�cados em sua forma macro, sem nenhum tipo
de detalhamento, ainda não se encontrando prontos para que a equipe de desenvolvimento possa
codi�cá-los. Antes do início do projeto, os requisitos levantados se encontram nesse estágio, podendo ser
inseridos novos requisitos à medida que se dá o andamento do projeto.
Backlog da sprint: nesta fase, um conjunto de requisitos macro, retirados do conjunto que compõe o
backlog do produto, serão re�nados junto ao cliente e, após todos os detalhes de suas regras de negócio,
serão julgados pela equipe de desenvolvedores, conforme suas experiências passadas e o tempo
disponível para o próximo ciclo de desenvolvimento (sprint), que de�nirão quais tarefas serão entregues ao
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade…20/22
�nal da próxima sprint. Tudo que tiver de�nido como compondo o conjunto do backlog da sprint deverá
ser entregue ao cliente para homologação ao �nal do ciclo.
O re�namento de um requisito retirado do conjunto do backlog do produto é feito através de um documento
denominado história (ou estória) de usuário, que deverá conter todas as regras de negócio envolvidas na
implementação do requisito, os papéis que utilizarão a funcionalidade, assim como as regras de validação
(chamadas de critérios de aceitação).
É importante que um membro da equipe de desenvolvimento esteja com sólidos conhecimentos do negócio e
tenha contato direto com o cliente, sendo sua “voz” dentro da equipe, sanando qualquer dúvida que,
eventualmente, os desenvolvedores possam ter acerca dos detalhes de implementação do requisito. Este papel,
dentro de uma equipe ágil, é denominado product owner (ou dono do produto). Deverá ser a primeira pessoa
a quem os desenvolvedores deverão recorrer em caso de dúvidas. Caso este não saiba ou precise esclarecer
algo sobre o negócio com o cliente, de forma direta, então somente esta pessoa realizará este contato.
REQUISITOS AUTOADAPTATIVAS
Conforme Batista (2022), aplicações autoadaptáveis são aquelas capazes de moldar seu comportamento,
alterando-o conforme necessário, para se adequar ao meio que está inserido. Sendo assim, é possível realizar
avaliações que, como resultado, podem acarretar melhoria de desempenho da aplicação ou até modi�car um
comportamento tido como errado (ou que esteja causando falhas), sem que ocorra intervenção humana para
esta adaptação.
O intuito pelo qual existem aplicações autoadaptáveis é a necessidade de se gerenciar aplicações complexas,
necessidade de tratamento de condições inesperadas e, inclusive, a incerteza acerca dos requisitos da
aplicação.
Aplicações com as características de adaptação possuem propriedades, dentro de conjuntos bem de�nidos e
conhecidos, caracterizadas por self-*. Cada categoria de propriedade self-* de�nirá um tipo de comportamento
adaptável, como apresenta Batista (2022):
Autocon�guração: capacidade de responder a mudanças através da autocon�guração, podendo instalar,
atualizar, integrar, compor e decompor entidades de software.
Autocura: capacidade de se recuperar de interrupções, podendo, inclusive, se antecipar a problemas,
tomando as medidas necessárias para evitar uma falha.
Auto-otimização: capacidade de gerenciamento de desempenho e alocação de recursos, satisfazendo os
requisitos não funcionais dos diversos stakeholders da aplicação.
Autoproteção: capacidade de detectar problemas com segurança e se recuperar de possíveis falhas. Tanto
pode defender a aplicação contra-ataques maliciosos como pode mitigar os efeitos de um ataque e tomar
as precauções necessárias para proteção.
Requisitos autoadaptáveis, por comporem aplicações que podem ajustar seu comportamento em tempo de
execução, conforme as diversas variáveis que são analisadas, passam a ser analisadas em tempo de execução.
Quando nos referimos ao processo de levantamento de requisitos para aplicações autoadaptáveis, é
importante mencionar o nível de incerteza destes requisitos, o que torna o processo de elucidação das
funcionalidades parcialmente incompleto. Em uma aplicação tradicional, sem a característica de adaptação, as
funcionalidades precisam ser mapeadas logo no princípio do projeto, com um alto grau de certeza, ou seja, para
cada requisição de entrada, uma resposta esperada já é conhecida ainda na fase de especi�cação.
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 21/22
Uma forma apresentada por Batista (2022) para a elucidação de requisitos para aplicações autoadaptáveis é a
utilização do método de perguntas para os requisitos essenciais de autoadaptação:
Onde: perguntas relacionadas com pontos onde ocorrem a necessidade de mudança. O que será alterado
e em qual camada? Auxilia na localização do problema a ser resolvido com a adaptação.
Quando: perguntas relacionadas ao tempo no qual adaptações precisam ocorrer, como a decisão de
quando uma mudança será possível ser realizada, se existe algum momento especí�co para aplicação,
conforme necessidade do sistema, e qual a frequência de alteração.
O quê: de�nem quais atributos ou artefatos do sistema serão alterados por conta da adaptação.
Por quê: apresenta a motivação para a construção do sistema adaptativo.
Quem: de�nem o nível de integração humana e automação da aplicação.
Como: de�ne como os requisitos adaptáveis serão con�gurados e quais as condições mais adequadas para
a adaptação. 
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá, de forma prática, exemplos de artefatos resultantes da fase de
levantamento de requisitos utilizando metodologia tradicional em cascata, assim como um exemplo de escrita
de uma história de usuário na metodologia ágil. Por último, você verá os requisitos voltados para aplicações
autoadaptativas e como podem ser especi�cados.
Bons estudos! 
 Saiba mais
O guia para o SCRUM foi atualizado em 2020. Para conferir as atualizações e conhecer mais sobre o
framework ágil SCRUM, acesse este link: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-
Guide-PortugueseBR-3.0.pdf.
Uma ferramenta gratuita para auxiliar na escrita de histórias de usuário é a Miro. Você poderá também
contar com a ferramenta Trello, gratuita, para a escrita das histórias de usuário e o acompanhamento do
progresso do time de desenvolvimento.
Videoaula
Para visualizar o objeto, acesse seu material digital.
Aula 1
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill Education, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011. 
REFERÊNCIAS
2 minutos
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR-3.0.pdf
https://miro.com/pt/modelos/user-story-mapping/
https://trello.com/pt-BR
29/03/2023, 15:25 wlldd_222_u2_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 22/22
Imagem de capa: Storyset e ShutterStock.
Aula 2
GENEROSO, M. A. P. Dependency Rank: método de priorização de requisitos baseado nas relações de
dependência identi�cadas por PLN. 2019. Dissertação (Mestrado em Informática) – Universidade Federal do
Paraná, Curitiba, 2019. Disponível em: https://www.prppg.ufpr.br/siga/visitante/trabalhoConclusaoWS?
idpessoal=54589&idprograma=40001016034P5&anobase=2019&idtc=1424. Acesso em: 28 maio 2022.
JUSTO, A. S. Matriz de Priorização: Como organizar e selecionar projetos, processos e chamados em 6 passos.
Euax, 2019. Disponível em: https://www.euax.com.br/2019/06/matriz-de-priorizacao/. Acesso em: 28 maio 2022.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.  
Aula 3
LARMAN, C. Utilizando UML e Padrões: uma introdução à análise e ao projeto orientado a objetos. Porto
Alegre, RS: Bookman, 2000.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: Mc Graw Hill Education, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
Aula 4
BATISTA, A. P. Decomposição de requisitos de con�abilidade para sistemas autodaptativos utilizando o
NFR framework. 2022. Trabalho de Conclusão de Curso (Graduação em Engenharia de Software) –
Universidade Federal do Ceará, Quixadá, 2022. Disponível em:
https://repositorio.ufc.br/bitstream/riufc/65416/1/2021_tcc_apbatista.pdf. Acesso em: 6 jun. 2022002E
BECK, K. et al. Manifesto para desenvolvimento ágil de software. [S. l.]: [s. n.], 2001. Disponível em:
https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 6 jun. 2022.
SCHWABER, K.; SUTHERLAND, J. Um guia de�nitivo para o SCRUM: as regras do jogo. Scrum, 2013.Disponível
em: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf. Acesso em: 6 jun. 2022.
https://storyset.com/
https://www.shutterstock.com/pt/
https://www.prppg.ufpr.br/siga/visitante/trabalhoConclusaoWS?idpessoal=54589&idprograma=40001016034P5&anobase=2019&idtc=1424
https://www.euax.com.br/2019/06/matriz-de-priorizacao/
https://repositorio.ufc.br/bitstream/riufc/65416/1/2021_tcc_apbatista.pdf
https://agilemanifesto.org/iso/ptbr/manifesto.html
https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 1/24
Imprimir
INTRODUÇÃO
Por décadas, acreditava-se que o escopo de um sistema seria o único norte para o sucesso no desenvolvimento
de software. Compreendia-se por escopo todas as funcionalidades mapeadas de um sistema e que não
sofressem alterações até que o projeto fosse concluído e entregue.
Atualmente, a lista de funções de um software faz parte de requisitos de sistema, junto a outras especi�cações,
que podem alterar inúmeras vezes ao longo da vida útil do sistema.
Você perceberá que nesse cenário volátil é que se faz tão necessário o gerenciamento, o controle de mudança e
a revisão de requisitos para manter a disponibilidade de um software que atenda aos negócios de uma
organização, da sociedade ou de um indivíduo. Conforme Reinehr (2020, p. 33), “a velocidade do mercado exige
que novos produtos ou funcionalidades sejam lançados cada vez mais rápido”. Desta forma, utilize nossos
materiais e aprofunde seu conhecimento sobre a temática.
Bons estudos!
REQUISITOS EVOLUEM RAPIDAMENTE
Estar com o sistema sempre em funcionamento, sendo útil aos negócios e aos usuários, com uma boa
qualidade, seria considerado um bom nível de satisfação para muitos. Porém, ainda pode ter alguém que diria
que não �cou da forma que havia sido combinado. A�nal, o desa�o é enorme para quem quer gerenciar um
projeto de desenvolvimento de software e atender a todos os critérios ou a todas as pessoas envolvidas.
Processos de qualidade na Engenharia de Requisitos
Aula 1
PROCESSOS DE GERENCIAMENTO DE REQUISITOS
Atualmente, a lista de funções de um software faz parte de requisitos de sistema, junto a outras
especi�cações, que podem alterar inúmeras vezes ao longo da vida útil do sistema.
28 minutos
GERENCIAMENTO DE REQUISITOS
 Aula 1 - Processos de gerenciamento de requisitos
 Aula 2 - Gestão de requisitos
 Aula 3 - Monitoramento de requisitos
 Aula 4 - Rastreabilidade de requisitos
 Referências
114 minutos
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 2/24
Adotar atividades adequadamente ajustadas ao nível de conhecimento do time de desenvolvimento favorece
obter requisitos com qualidade. Para tanto, é importante conhecer processos de qualidade na Engenharia de
Requisitos. As principais atividades para obter a qualidade dos requisitos, segundo MPS.BR (2021), é de�nir,
gerenciar e manter atualizados os requisitos das partes interessadas e do produto, conforme ilustrado na Figura
1.
Figura 1 | Processo da qualidade na Engenharia de Requisitos
Fonte: elaborada pelo autor.
Ao de�nir um requisito, deve-se concebê-lo visando à clareza necessária para a compreensão de todos os
envolvidos, em especial, o usuário �nal e os responsáveis pelo desenvolvimento do software. O uso de técnicas
adequadas para elicitar requisitos é fundamental nesta fase do projeto, tanto para garantir que uma regra de
negócio será implementada por uma funcionalidade quanto para a validação na etapa da entrega do aplicativo.
Ao gerenciar requisitos, o responsável deverá ter a certeza de que suas funções previstas estão planejadas para
serem incorporadas no aplicativo; ao longo do ciclo de desenvolvimento, monitorar para que o requisito seja
�elmente implementado e que, ao �nal, o produto contenha integralmente o requisito com a qualidade
desejada pelo cliente ou usuário, validando a efetividade de uso em operação. No curso do desenvolvimento,
caso tenha sido necessária a implementação parcial, outro requisito deverá ser descrito com o devido vínculo
para garantir que será complementado em outra versão futura do aplicativo.
Sabe-se que o requisito poderá sofrer modi�cações naturalmente pela demanda dos negócios, portanto as
funcionalidades do aplicativo devem sofrer modi�cações, o que corresponde à fase de manter o requisito.
Controle de mudanças de requisitos
As mudanças de requisitos requerem um cuidado especial para que o software seja devidamente alterado
mesmo após inúmeras manutenções terem sido aplicadas em outras funcionalidades relacionadas. Portanto, o
controle de mudanças de requisitos se faz necessário para analisar o impacto antes mesmo da implementação
da alteração no software.
Partindo do princípio de que as regras de negócio sofrem alterações constantes, os princípios do DevOps
(Desenvolvimento e Operações) têm sido aplicados com sucesso em organizações que adotam o CI/CD
(Continuous Integration/Continuous Delivery) para entregar as funcionalidades requeridas pela operação do
sistema com maior brevidade possível. Neste caso, segundo Pressman e Maxim (2021), praticando uma
abordagem com ciclos contínuo, foco em qualidade no processo de construção e entrega de software. Dentre as
soluções do DevOps, constata-se o TDD (Test Driven Development) e XP (eXtreme Programming).
Revisão de requisitos
Para que uma equipe possa aumentar a qualidade de requisitos, deve-se efetuar a revisão de requisitos. Para
tanto, conheça a proposta de Veri�cação & Validação, segundo Hirama (2012, p. 105):
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 3/24
Você percebeu que com atenção e a metodologia adequada é possível gerenciar as mudanças constantes de
requisitos, então continue aprofundando e colocando em prática o que conheceu por aqui.
Bons estudos!
DOS PROCESSOS AOS FATORES DA QUALIDADE EM REQUISITOS
Ao se deparar com uma dúvida de como os processos da Engenharia de Requisitos poderão aprimorar a
qualidade dos requisitos e, consequentemente, a qualidade do software, lembre-se de que a melhor maneira de
obter o máximo em qualidade nos requisitos de software é conhecer as diversas características que eles
possuem, compreender o que pode in�uenciar na criação ou na mudança de um requisito de sistema e ter
habilidade em processos e ferramentas que auxiliarão no gerenciamento de todas essas variáveis. Em seguida,
colocar em prática os processos, usando ou não ferramentas que contribuirão na gestão de mudanças de
requisitos.
Se o usuário de um sistema está solicitando um novo requisito, por exemplo, “ao alterar o horário da agenda da
consulta para o paciente, o médico ou o laboratório deve receber uma mensagem e um e-mail com a nova
informação, bem como o paciente também receberá um comunicado pelo sistema de mensagem”, deverá
proceder a de�nição dele de forma completa e obter a comprovação do entendimento por parte de quem
solicitou o novo requisito.
Sentindo a necessidade de conhecer melhor a solicitação do usuário, deve-se marcar um encontro presencial
com a participação de especialista para elicitar os detalhes técnicos ou métodos adequados ao processo a ser
implementado, conforme ilustrado na Figura 2.
Figura 2 | Detalhamento do requisito
Fonte: elaborada pelo autor.
Através desta providência, amplia-se o grau de con�abilidade do time de desenvolvimento para implementar o
novo requisito funcional. Assim, colocará em prática a sua evolução em competência e habilidade,com base no
conhecimento vivenciado de pesquisadores experientes em diversos setores da economia e da sociedade.
Pressman e Maxim (2021, p. 312) destacam fatores relevantes sobre processos de desenvolvimento de
software, em que a “gestão de qualidade efetiva estabelece a infraestrutura que dá suporte a qualquer tentativa
de construir um produto de software de alta qualidade”. Os autores ainda complementam sobre o requisito:
[...] determinar se os requisitos de um sistema ou componente estão completos e
corretos, os produtos de cada fase de desenvolvimento atendem aos requisitos e às
condições impostas pela fase anterior e o sistema ou componente �nal está aderente
com os requisitos especi�cados.
— (HIRAMA, 2012, p. 105)
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 4/24
“ele satisfaz a um conjunto de requisitos implícitos que se espera de todo software de alta qualidade”. E por
consequência, dentre os pontos da qualidade, “permite que os engenheiros de software despendam mais
tempo criando aplicações novas e menos tempo em manutenções”.
Quando se obtém o requisito detalhado, torna-se mais apropriado e seguro para a elaboração dos cenários de
teste quanto na massa de dados que utilizará para validar o aplicativo, dando continuidade ao processo do
desenvolvimento, assim que o código-fonte estiver liberado para a fase de Continuous Deployment e revisão de
requisitos.
Durante a revisão do requisito, deve-se convocar o especialista que auxiliou na complementação do requisito
para a devida validação da funcionalidade implementada e que será entregue ao cliente. Com essa providência,
evidenciará que a correlação entre a qualidade de um software é diretamente associada às funcionalidades.
Para Pressman e Maxim (2021, p. 311), as funções especi�cadas no modelo de requisitos são essenciais para
elevar a qualidade do projeto de software. Os autores ainda complementam que a qualidade de software
depende da conformidade entre os requisitos do produto e a satisfação do cliente.
Chegando ao �nal deste bloco, você viu que vale a pena manter o foco na qualidade e no detalhamento do
requisito, então coloque esses conhecimentos em prática em suas atividades.
Bons estudos!
NOVO REQUISITO NA CLINIREQ
Você deve estar pensando em como manter as boas práticas dos processos da qualidade, do controle de
mudanças de requisitos e da revisão de requisitos. Então, analisaremos como aplicar os conceitos conhecidos.
Na clínica médica CLINIREQ, os dados são controlados por um aplicativo, instalado em nuvem, sendo possível
acessar pelos funcionários, médicos associados e clientes/pacientes com login. O sistema possui grandes
vantagens reconhecidas pelos usuários pela con�ança, pela assistência, pelo poder de decisão e pela
simplicidade, sendo que os fatores de qualidade foram conquistados ao longo de décadas no segmento de
negócios. Dentre esses fatores para o time de desenvolvimento, estão: equilíbrio da documentação,
proporcionando a localização de requisitos e módulos, a facilidade de manutenção das funcionalidades e o
conforto para refatoração dos itens de software. Por outro lado, para a equipe de operação (usuários e time da
infraestrutura), aponta-se a rapidez na implantação, a fácil assimilação, a con�ança na utilização e a evolução
constante, conforme exige o negócio da saúde, entre outras.
O desa�o dos times de desenvolvimento e de operações está em escolher as melhores alternativas durante a
execução das novas demandas, corrigir bugs que nunca pararam de ser encontrados pelos usuários e atender
ao exigente segmento de médicos e pacientes em clínicas que dependem de aplicações de alto valor agregado.
Imagine-se aceitando a implementação de novas funcionalidades e as mudanças em outras com metas de
curtíssimo prazo. Dentre os novos requisitos, estão: RF (requisito funcional), inserção de fotogra�a e
reconhecimento por impressão digital do paciente e controle de con�rmações de consultas através de e-mails e
sistema de mensagens. Pelas modi�cações, solicitaram nos RFs agenda de compromissos e exames e
procedimentos na Sala Virtual de Espera (SVE).
Faça uma demonstração da funcionalidade durante a validação da aplicação utilizando dados reais acessando
um cadastro já existente, agora incluindo uma fotogra�a diretamente da webcam, validando a operação de
acordo com o requisito funcional descrito. Para complementar a validação da nova implementação, deve-se
repetir o processo, porém, durante a inclusão de um novo paciente, associar a fotogra�a dele.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 5/24
A implementação da nova funcionalidade é relativamente pequena para um sistema que gerencia todos os
departamentos de uma clínica, e não foram percebidas di�culdades técnicas para a codi�cação e a integração
dos métodos e/ou das funções. Contudo, a análise de impacto deve ser realizada antes do início da efetiva
construção. Como exemplo, pode-se analisar o aspecto do design, se existe implementação com tratamento de
imagem e que poderia ser reutilizada, assim aumentaria a qualidade dos artefatos ao �nal do processo. Outro
exemplo que se poderia analisar é o impacto em espaço a ser ocupado pelas imagens das fotogra�as em
função da quantidade de pacientes existentes e os novos esperados nos próximos meses, inclusive, seria o caso
de conferir qual a resolução/qualidade da imagem a ser armazenada. 
Através dessa análise de pouco esforço, sem perder os propósitos da Engenharia de Requisitos, pode-se evitar
chances de futuros riscos, principalmente se tratando do procedimento CI/CD, no qual a participação de
desenvolvedores e de responsáveis da infraestrutura de operações está atuando ao longo do ciclo de vida nas
atividades do projeto.
Com isso, encerramos esse terceiro bloco, no qual você veri�cou que é importante estar preparado para se
comunicar com os responsáveis pela operação do sistema, conhecer as regras de negócio e acompanhar as
mudanças de requisitos. Sendo assim, continue se dedicando nas competências e colocando suas habilidades
em prática no gerenciamento de requisitos.
Bons estudos! 
VIDEOAULA
Ao assistir ao vídeo, você perceberá a importância da competência no processo da qualidade na Engenharia de
Requisitos, através de exemplos vivenciados pro�ssionalmente, trazendo você para bem próximo da habilidade
necessária para o controle de mudanças de requisitos e da revisão de requisitos. Perceberá que a participação
do time de operações ou usuários no processo de desenvolvimento aumentará as chances de entregar software
com qualidade. 
 Saiba mais
As validações das implementações entre requisito e funcionalidade no software estão cada vez mais
e�cientes com o ambiente de desenvolvimento em nuvem, o que facilitou também o gerenciamento da
integração e entrega contínua. O processo de validação acrescentará mais valor ao software, pois é uma
oportunidade para um feedback dos usuários em tempo real.
Visite e leia o artigo sobre este assunto: itens 7.8, 12.5 e 12.7 do livro de Pressman e Maxim (2021).
Videoaula
Para visualizar o objeto, acesse seu material digital.
Aula 2
GESTÃO DE REQUISITOS
Com o envolvimento de muitas pessoas e inserido em um ambiente altamente competitivo, em
que as necessidades mudam diariamente, nesse mundo moderno e interconectado, ter o
requisito devidamente documentado ao modelo tradicional já não atende à realidade tão
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 6/24
INTRODUÇÃO
Havia umentendimento de que requisito era apenas usado para documentar o que seria desenvolvido no
aplicativo e que esta documentação seria a única fonte ao longo do projeto de software, da análise à validação
do sistema.
Com o envolvimento de muitas pessoas e inserido em um ambiente altamente competitivo, em que as
necessidades mudam diariamente, nesse mundo moderno e interconectado, ter o requisito devidamente
documentado ao modelo tradicional já não atende à realidade tão dinâmica.
Para tanto, um padrão tem sido praticado na gestão de requisitos concomitante aos processos da engenharia
de software visando estar com requisitos constantemente aderentes aos negócios do ambiente onde ocorre as
operações do sistema.
Assim, é possível garantir aos usuários a manutenção do sistema através do gerenciamento dos
relacionamentos entre os requisitos e da organização dos requisitos.
Compreenderemos melhor e aprenderemos a aplicar esses conceitos. Bons estudos!
REQUISITOS ORGANIZADOS
Visando manter os requisitos com bom nível de qualidade para o uso pelos desenvolvedores, algumas
atividades devem partir da gestão de requisitos. Neste caso, o time de desenvolvedores, com a participação
direta dos usuários responsáveis pela operação, deve adotar processos padronizados para a correta
especi�cação e �nalidade. Para Vazquez (2016), os processos que intercalam atividades da Engenharia de
Requisitos na exploração da profundidade do produto, detalhando o seu comportamento esperado, alcançam
maior aderência das funcionalidades do software aos negócios da organização operadora do sistema.
A cada iteração do ciclo do desenvolvimento de um software, é fundamental que aconteça a interação entre os
responsáveis pela operação e o time de desenvolvimento, a �m de explorar com profundidade o
comportamento esperado do sistema, para requisitos novos ou em mudanças, conforme ilustra a Figura 1.
Figura 1 | Interação para exploração de requisitos
dinâmica.
29 minutos
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 7/24
Fonte: elaborada pelo autor.
Com foco na e�ciência da gestão de requisitos, é imprescindível implantar um processo padronizado para o
devido tratamento dos requisitos, sendo que a metodologia para especi�cação do requisito é menos
importante para Vasquez (2016), seja por descrição da história do usuário ou por diagrama de caso de uso, mas
que tenha o aprofundamento necessário para compreender o relacionamento que existe entre eles.
A atividade de organização dos requisitos é de grande importância para que os interessados se localizem entre
os requisitos relacionados e sua prioridade de implementação, entendendo que o mapeamento completo entre
requisitos e seus relacionamentos deve preceder o estabelecimento da priorização para escolha na ordem de
implementação. Previsto também em processos de padrão de qualidade. Conforme MPS.BR (2021, p. 27),
“atividades e produtos de trabalho relacionados são revisados visando identi�car e tratar inconsistência em
relação aos requisitos”.
O que não pode �car de fora deste detalhamento é a percepção quanto aos requisitos ditos não funcionais,
tendo em vista que estes podem proporcionar aumento em segurança, produtividade e escala para muitos
negócios superconectados. Hirama (2012, p. 170) entende que deve ter um entendimento claro do
relacionamento entre os requisitos e que “os interesses podem ser divididos em interesses centrais (requisitos
funcionais) e interesses transversais (requisitos não funcionais). Os interesses transversais causam o
espalhamento, enquanto o entrelaçamento é uma consequência desse espalhamento”.
Para melhor compreender algumas das atividades, a Figura 2 ilustra um processo padrão para a gestão de
requisitos de qualidade.
Figura 2 | Processos da gestão de requisitos
Fonte: elaborada pelo autor.
Assim, considera-se que, quanto maior a profundidade dos requisitos e dos relacionamentos entre eles, maior é
a necessidade de procedimentos adequados para revisão e organização dos requisitos para submeter ao
desenvolvimento de software. O relacionamento entre requisitos pode ser pela dependência funcional em
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 8/24
função dos resultados em que determinará a priorização no desenvolvimento das funcionalidades. Para tanto, a
classi�cação dos requisitos é fundamental para que eles possam ser identi�cados corretamente quanto à
volatilidade, ao impacto sobre a arquitetura e ao risco.
Você chegou ao �nal do primeiro bloco e viu que, através da adequada classi�cação, se torna possível a tão
desejada organização dos requisitos para facilitar o acesso, a compreensão e a implementação, bem como
mantê-lo atualizado ao longo do projeto e da vida útil do sistema. Agora, comece colocar em prática essa
competência. Bons estudos!
ORGANIZANDO REQUISITOS
Partindo do princípio de que você está em contato direto com as pessoas interessadas no sistema, essa será a
base para manter os requisitos atualizados e as organizações competitivas. Você perceberá que é possível
manter os requisitos como fonte segura no desenvolvimento de software, desde que se executem
procedimentos que colaboram com a manutenção deles: padrões, organização e gerenciamento dos
relacionamentos entre os requisitos.
Se um requisito implementa uma regra que altera quando um fator externo impõe mudanças, por exemplo,
alteração de taxas do governo (municipal, estadual, federal ou internacional) tem impacto direto na aplicação
que se utiliza desta regra para desempenhar os seus negócios, re�ita sobre mudanças no processo tarifário da
importação de produtos em que a sua organização atua.
Numa situação em que se recebe a comunicação de que a alteração será realizada e há um prazo para realizar a
adaptação, as primeiras atividades devem estar associadas ao entendimento da nova regra, a �m de
compreender se haverá impacto na aplicação e qual a extensão dela. Assim, entenda como proceder as
atividades padronizadas para manter os requisitos devidamente organizados, com os relacionamentos entre
eles, conforme ilustra a Figura 3.
Figura 3 | Processos da gestão de requisitos
Fonte: elaborada pelo autor.
Se é uma mudança de requisito, deve-se executar a atividade “De�nir”, conferindo se realmente essa nova regra
de negócio não fere as existentes, ou talvez necessite criar um requisito relacionado a outro existente.
Enquanto “Explorar com aprofundamento” é considerada uma atividade altamente importante em função do
detalhamento necessário em impacto às necessidades reais para o funcionamento dos negócios. Muitas vezes,
é recomendável a participação de especialistas no assunto (podendo ser das áreas de contabilidade, economia,
analista de comércio exterior, relações internacionais, entre outras). 
Tratando-se de um requisito complexo, este poderá ter de alto risco em sua implementação. Conforme
declarado por Reinehr (2020, p. 27), “é importante lembrar que a extensão da análise de requisitos vai variar de
acordo com a criticidade do software e qual o seu papel dentro do contexto no qual está inserido”.
Portanto, identi�car as reais características do requisito durante essa etapa é imprescindível, inclusive para
efetuar a correta classi�cação dele, o que tornará muito favorável na execução da atividade “Revisar
relacionamentos” entre os demais requisitos que podem ou não estar em operação.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 9/24
As opiniões e considerações feitas pelos especialistassão fundamentais para determinar o relacionamento
entre os requisitos, bem como entender e determinar a prioridade dele para a implementação quando estiver
executando a atividade “Organizar”, em que estará com os requisitos prontos para serem utilizados pelos
interessados para cumprir as próximas fases da construção ou integração do software.
Uma característica bastante marcante que os líderes e gestores priorizam está relacionada aos requisitos
(funcional ou não funcional) que agregam valor aos negócios, ou seja, esta é uma das classi�cações que se deve
considerar ao priorizar e organizar. Segundo Pressman e Maxim (2021, p. 40), a “abordagem iterativa capacita o
cliente a avaliar o incremento de software regularmente, fornecer o feedback necessário para a equipe de
software”, facilitando desenvolvedores e responsáveis pela operação do sistema na organização adequada dos
requisitos.
Muito bom saber que você concluiu o segundo bloco e percebeu que é fácil organizar os requisitos. Agora,
“mãos à obra”, pratique e amplie suas habilidades com esses conhecimentos.
Bons estudos!
REQUISITOS NO AGRONEGÓCIO
Na agricultura, cada vez mais a Tecnologia da Informação (TI) tem dado um tom diferente e moderno,
principalmente no que se refere ao mapeamento e ao manejo de lavouras de grande escala. Você está
participando de uma realidade no campo, em que será implementada uma função especializada para informar
a situação do solo durante os dois próximos anos.
Com o foco em praticar a organização, o gerenciamento do relacionamento entre requisitos e os processos da
gestão de requisitos, compreenda como as atividades poderão ser executadas neste desa�o de uma situação da
realidade no campo. Para saber mais sobre o assunto, leia um artigo sobre as tecnologias no campo disponível
em: https://bit.ly/youargro_tecnologia_campo (Acesso em: 16 jun. 2022).
A empresa REQAgro inicia a transição do processo manual para o automatizado via IoT (Internet of Things) para
a nova funcionalidade do seu sistema: a leitura e o registro da situação do solo em vários pontos ao longo de
sete mil hectares (7.000 ha). Os pontos foram estrategicamente escolhidos em função de um histórico de
medições (até então feitas manualmente), mas que sofrerá uma ampliação em função dessa facilidade que a TI
proporciona. Esta funcionalidade tem o objetivo de aumentar consideravelmente a quantidade de pontos de
coleta.
Figura 4 | Ilustrando o plantio em solo fértil
https://bit.ly/youargro_tecnologia_campo
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 10/24
Fonte: Unsplash.
Numa rápida projeção com a nova funcionalidade, hipoteticamente, os agrônomos estão prevendo aumentar
em 10% a produção agrícola e gastar cerca de 12% a menos em insumos, especi�camente para correção do
solo. Esse é um excelente panorama para classi�cação do requisito quanto ao valor que agregará aos negócios.
Ao se aprofundar no requisito, poderá perceber se o equipamento (hardware e software) a ser instalado na
captura dos dados tem acesso à internet e qual será o protocolo de comunicação, frequência e dados a serem
transmitidos, entre outros detalhes. Conforme comentado por Reinehr (2020), sistemas complexos, envolvendo
hardware e software, precisam de uma etapa de análise de requisitos mais aprofundada.
Quanto ao relacionamento entre outros requisitos funcionais (em operação e outros planejados para serem
implementados), você veri�cará que tem relação com o plano de aplicação de insumos para correção do solo e
o plano de plantios, o qual, por sua vez, poderá se diferenciar pela cultura (milho, soja, trigo ou milheto) a ser
desenvolvida na próxima safra.
Agora que está vencendo o desa�o para a organização do novo requisito através de processos da gestão de
requisitos, compreende-se que a participação dos gestores e dos agrônomos foi fundamental para se
aprofundar no requisito e identi�car os principais requisitos relacionados. Aqui, �ca claro que as partes
interessadas devem ser convocadas na fase do gerenciamento das relações entre requisitos.
Quadro 1 | Requisitos relacionados e organizados
#Requisito Relacionamento
I - Implementado/
P - Planejado
Prioridade
#1 Coleta de dados do solo #8, #2 P 1
#2 Coleta de dados da pluviometria #8 I -
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 11/24
#3 Apuração dos insumos para correção do
solo
#1, #2 I 2
#4 Geração da produtividade da safra #1, #3, #6 I 2
#5 Geração da qualidade da safra #1, #2, #7 P 3
#6 Coleta da medição da produção #8 P 4
#7 Coleta da medição da qualidade #8 P 4
#8 Mapeamento do plantio/safra/cultura - I -
Fonte: elaborado pelo autor.
No Quadro 1, percebe-se que o #3 Apuração dos insumos para correção do solo e #4 Geração da produtividade
da safra deverão sofrer modi�cações (manutenção evolutiva) para atender à nova funcionalidade a ser
desenvolvida. Enquanto o requisito #5 Geração da qualidade da safra requer atenção em função de estar
planejado para ser implementado.
O resultado esperado pela organização dos requisitos pode variar de acordo com a metodologia ou as
restrições que o projeto poderá impor, porém é imprescindível que obtenha a segurança dos dados analisados
até o presente momento e do próximo passo no desenvolvimento de um software.
Com isso, encerramos o terceiro bloco, mas você pode continuar se atualizando sobre a gestão de requisitos e
colocar em prática as habilidades na de�nição, exploração, revisão e organização de requisitos.
Bons estudos! 
VIDEOAULA
No vídeo, será explanado o quanto é importante efetuar o detalhamento e o aprofundamento sobre o requisito
para compreender o máximo das relações que existem com outras regras de negócio, mesmo aquelas que
ainda não foram implementadas em software. Uma documentação extensa pode trazer problemas na
atualização, porém o mínimo de artefato é fundamental para a gestão de requisitos e na organização deles.
 Saiba mais
Compreender como explorar com aprofundamento os requisitos de um sistema estudando os itens 7.2.1
(Identi�cação de envolvidos), 7.2.3 (Trabalho em busca da colaboração) e 7.2.5 (Requisitos não funcionais),
publicados em Pressman e Maxim (2021, p. 107-109).
Disponível em:
https://integrada.minhabiblioteca.com.br/reader/books/9786558040118/epubc�/6/34[%3Bvnd.vst.idref%3
DC7.xhtml]!/4[PRESSMAN_Completo-13]/2/94/1:44[as%20%2Cnec. Acesso em: 16 jun. 2022.
Videoaula
Para visualizar o objeto, acesse seu material digital.
https://integrada.minhabiblioteca.com.br/reader/books/9786558040118/epubcfi/6/34%5b%3Bvnd.vst.idref%3DC7.xhtml%5d!/4%5bPRESSMAN_Completo-13%5d/2/94/1:44%5bas%20%2Cnec
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 12/24
INTRODUÇÃO
Sabe-se que os requisitos são condições com as quais o sistema deve estar de acordo. Ao falarmos de
gerenciamento de requisitos, referimo-nos a uma abordagem sistemática, da qual se extraem, organizam e
documentam-se requisitos de um sistema. Estes requisitos podem sofrer alterações durante o
desenvolvimento, portanto eles devem ser mantidos em um processo controlado, visando garantir a qualidade
do sistema.
Toda mudança deve ser analisada e avaliada dentro de um processo de monitoramento dos requisitos, em que
a evolução deles segue tipicamente gerenciada por modelos de natureza incremental.
Segundo Pressman e Maxim (2021, p. 122), "o desenvolvimento incremental implica a necessidade de validação
incremental. O monitoramento de requisitos dá suporte à validação contínua por analisar modelos demeta do
usuário em relação ao sistema em uso", ou seja, além de outros diversos fatores agentes de alterações,
podemos citar a avaliação contínua da satisfação do usuário utilizada como feedback para aprimoramentos de
requisito.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
MONITORAMENTO E GERENCIAMENTO DAS MUDANÇAS DE REQUISITOS
Por mais que você seja acurado durante a de�nição e especi�cação dos seus requisitos, sempre haverá
mudanças neles. A mudança dos requisitos é inerente ao processo de gerenciamento deles, mas toda e
qualquer alteração deve sempre ser analisada, avaliada e justi�cada, procurando encontrar formas de
implementação e�cientes e que acarretem o mínimo de custo, impacto e esforço possível.
Processo de monitoramento de requisitos 
Durante o processo de monitoramento de requisitos, deve-se estar capacitado a re�nar as características do
sistema identi�cando a ordem de prioridade de suas funcionalidades, bem como o caráter de urgência e a
volatilidade de cada uma delas. O gerenciamento dos requisitos, principalmente aqueles que tendem à
volatilidade, é uma tarefa complexa: um requisito alterado não implicará somente mais ou menos tempo gasto
na implementação da funcionalidade de um determinado recurso mas também poderá impactar outros
requisitos. Fatos importantes no monitoramento é saber as causas que motivam a mudança do requisito, sendo
uma tarefa que poderá auxiliar no seu monitoramento e nas decisões das ações. Como citado por Reinehr
(2020, p. 261), podendo ser “um erro, ele terá, obrigatoriamente, que ser corrigido antes que prossiga para a
implementação” de novos requisitos; ou ainda, “quando se tratar de uma melhoria ou de um novo requisito,
pode ser que a opção seja pela não implementação ou pelo adiamento da alteração para versões posteriores do
produto”.
Aula 3
MONITORAMENTO DE REQUISITOS
Toda mudança deve ser analisada e avaliada dentro de um processo de monitoramento dos
requisitos, em que a evolução deles segue tipicamente gerenciada por modelos de natureza
incremental.
26 minutos
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 13/24
Gerenciamento de mudanças de requisitos
Dentro da metodologia ágil, em particular o Scrum (um framework da metodologia ágil), as mudanças de
requisitos são discutidas e priorizadas para constituírem o Backlog da Sprint (lista principal de um projeto de
desenvolvimento), dentro de uma Sprint ao invés, não são aceitas mudanças (HIRAMA, 2012, p. 54). É comum
serem realizadas reuniões de demonstração das atividades realizadas e uma retrospectiva dos principais
pontos a serem considerados no �nal de cada Sprint, seguidos de uma reunião de planejamento para a próxima
Sprint, em que poderão ser consideradas as mudanças de requisitos, bem como seu impacto em posteriores
características do sistema. Tais passos são realizados iterativamente, ou seja, são repetidos em ciclos de 1 a 4
semanas, como ilustrado na Figura 1.
Figura 1 | Gerenciamento de requisitos no processo ágil
Fonte: elaborada pelo autor.
Segundo o IEEE (1998), a Engenharia de Requisitos, que comporta a atividade de gerenciamento de requisitos,
integra a aquisição, o processo de re�namento e a veri�cação das exigências de negócio por meio de técnicas
bem de�nidas, organizadas e de aspecto iterativo. Essas são usadas para assegurar que os requisitos sejam
consistentes, substanciais e que atendam às necessidades do cliente em ordem de preeminência.
Boas práticas de gerenciamento de requisitos
É necessário constatar que a de�nição detalhada dos requisitos do sistema seja pouco propensa a alterações e
que sejam utilizados links de rastreabilidade para caracterizar as dependências entre os requisitos e outras
atividades presentes durante o processo de desenvolvimento. Pensando mais a longo prazo, a consolidação das
estruturas nos obriga à análise das direções preferenciais no sentido do progresso. A nível organizacional, a
determinação clara de objetivos causa impacto indireto na reavaliação dos métodos utilizados na avaliação de
resultados.
O gerenciamento de mudanças se torna, portanto, altamente recomendável e inclui atividades, como
estabelecer uma linha de base do projeto, determinar quais dependências devem ser estabelecidas, determinar
as relações entre os itens e, por �m, o controle de mudanças. Em todo surgimento de mudança, faz-se
necessário avaliar o impacto causado por esta.
Segundo Pressman e Maxim (2021, p. 442), a gestão do impacto envolve dois aspectos principais: garantir que
sejam utilizadas estratégias que diminuam o impacto de ações de outros desenvolvedores em seu próprio
trabalho e utilizar técnicas que minimizem o impacto de suas atividades em trabalhos de outros colegas. Tais
ações são fundamentais e se complementam, garantindo, assim, uma boa prática no gerenciamento de
mudanças e na própria gestão dos requisitos em si.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 14/24
Concluindo o primeiro bloco, já foi possível ver que o monitoramento de requisitos é contínuo em qualquer
metodologia, seja tradicional ou ágil, portanto, é imprescindível que faça bom uso do monitoramento para
manter os requisitos prontos para o desenvolvimento.
Bons estudos!
PROCESSOS E BOAS PRÁTICAS NO GERENCIAMENTO DE REQUISITOS
São diversas as causas que contribuem para falhas em projetos de software, e todas estão inter-relacionadas,
devendo-se dar igual importância, porém é nítido perceber que a má gestão dos requisitos está entre as
motivações mais críticas de um projeto que apresentou defeito. A consequência de uma má gestão de
requisitos implica a de�nição de funcionalidades ao sistema que não traduzem a real necessidade dos usuários
ou dos negócios, gerando retrabalho, retardando as entregas e aumentando os custos e, principalmente, a
insatisfação do usuário com a aplicação.
Um bom gerenciamento de requisitos abrange as atividades e os processos de mudança de requisitos,
controlando a evolução destes dentro de um sistema de informação. A alteração de um requisito se dá tanto
pela constatação de uma nova necessidade quanto pela descoberta de falta de e�ciência em um requisito já
registrado. O gestor responsável pela de�nição do requisito deve ter em mente que a ligação entre os requisitos
através da rastreabilidade desses é um fator crítico, e estes devem estar corretamente correlacionados.
Supondo que um software, em desenvolvimento, recebe uma requisição para mudança de idioma do sistema,
ou seja, inicialmente, esteja previsto num requisito que será disponibilizado nas línguas portuguesa e inglesa.
Durante o seu desenvolvimento foi constatado que, para atender às necessidades de atuação no mercado
italiano, além dos idiomas em implementação, será necessário incluir a tradução automática do conteúdo
existente para a língua italiana também.
Lembrando que a análise do impacto faz parte de uma boa prática para a gestão de requisitos voláteis, portanto
se demonstra necessário fazer uma avaliação do impacto causado pela solicitação de tal mudança, conforme
exempli�cado no Quadro 1:
Quadro 1 | Análise de impacto
Análise de Impacto Detalhes da análise
Esforço
Desenvolvimento: 100h
Testes e implantação: 45h
Total: 145h
Custo R$ 5.500,00
Prazo 5 semanas adicionais
Fonte: elaborado pelo autor.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 15/24
A adoção da boa prática de veri�cação do menor impacto incluída no processo formal degerenciamento de
mudanças faz com que todas as alterações propostas sejam tratadas de forma consistente e controlada. Todo
sistema deve ser desenvolvido de modo que seja possível controlar as alterações, visando ao menor impacto
resultante do processo de mudança.
Sugerem-se, então, as seguintes etapas:
Análise do problema: identi�cação do problema, qual seu impacto em outros requisitos no projeto e
detalhamento de suas características.
Análise do custo: estimativa do custo da mudança e viabilidade.
Atualização dos documentos necessários: atualizam-se os documentos de forma a re�etir as mudanças
que foram solicitadas.
Em particular, no que se refere ao custo de uma alteração, Pressman e Maxim (2021) argumentam que, com a
adoção de um processo ágil bem elaborado é possível reduzir os custos e esforços signi�cativamente em um
projeto de software, devido às entregas incrementais propostas nestes. 
Deve �car atento ao que as metodologias ágeis propõem, não confundindo evitar documentações extensas com
negligenciar as técnicas de levantamento e análise de requisitos por meio de ferramentas, processos,
planejamentos e documentações. Estes, por sua vez, não são rejeitados, mas, sim, colocados em segundo plano
no que diz respeito às interações com o cliente, a �m de entregar um software funcional com resposta rápida às
mudanças. Em virtude do curto intervalo de tempo para as entregas, as documentações devem atender apenas
ao que está sendo entregue, evitando documentações extensas e desatualizadas.
Muito bom saber que concluiu o segundo bloco, agora já percebeu que é possível gerenciar os requisitos e
quanto será útil para o desenvolvimento de software de qualidade. Se ainda não está aplicando na prática, está
pronto para começar esta experiência. Bons estudos!
GERENCIANDO MUDANÇAS NA PRÁTICA – ORTO EH
Vivencie nesse bloco uma dinâmica em mudanças de requisitos no ambiente de operações de sistemas de
informações no setor de saúde, em especial, no departamento de pronto atendimento de uma unidade
hospitalar. Assim, pode-se perceber o uso do gerenciamento das mudanças de requisitos e as boas práticas de
processos de mudanças de requisitos, principalmente em sequência de constantes modi�cações.
Ao receber a mudança de requisitos de uma regra de negócios do atendimento de pacientes na clínica
ortopédica Orto EH, o Product Owner veri�ca que esse requisito foi alterado recentemente. Neste caso, veri�ca-
se que é a quinta vez que está sendo modi�cado em um mês. O requisito trata da prioridade no atendimento
em função da modalidade do paciente, do diagnóstico no pré-atendimento, na ocupação atual das posições do
atendimento e da disponibilidade de pro�ssionais na especialidade.
Entenda aqui o que se passa na Orto EH, as mudanças na estrutura organizacional e as peculiaridades do setor,
num cenário em que mais de 1.200 atendimentos são realizados diariamente, nada pode sair do controle e tudo
deve estar bem ajustado aos operadores do sistema e aos pacientes. Inclusive, outros interessados, como a
Agência Nacional da Saúde e os planos particulares de saúde, aos quais o estabelecimento deve apresentar
relatórios rotineiros.
As especi�cidades de cada atendimento são inerentes às dependências de cada parte interessada. Desde os
tipos de atendimento, datas de histórico de atendimento, dados de acompanhantes, valores e dados dos
procedimentos, entidades de regulamentação, entre outros. Sendo assim, num processo de atendimento a
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 16/24
pacientes, podem existir inúmeras diferentes regras para serem operacionalizadas em um curto espaço de
tempo (durante a recepção do paciente) e antes do início da consulta pelo médico.
O monitoramento �ca evidente quando se percebe a modi�cação de um requisito que foi desenvolvido e
entregue (que esteja em plena operação), e até mesmo aquele que fora desenvolvido, mas que ainda não tenha
sido entregue. Outra característica detectada no monitoramento é a identi�cação de que o mesmo requisito
tenha sofrido outras modi�cações.
No cenário apresentado, a modi�cação do requisito no atendimento do paciente está no registro de um tipo de
diagnóstico que fora exigido por um convênio particular, o que pode levar a ter necessidade de adaptação em
outros requisitos. As atividades de veri�cação dos requisitos relacionados são imprescindíveis para garantir que
a modi�cação num requisito terá impacto a vários outros, o que pode ser percebido pela Figura 2.
Figura 2 | Monitoramento das mudanças de requisitos
Fonte: Lorem ipsum dolor sit amet.
A limitação na capacidade de desenvolvimento é natural em qualquer organização, pois os recursos são
determinados por pessoas e pelo orçamento, o que leva à necessidade de escolher quais modi�cações
(requisitos alterados) serão planejadas ao longo de um período, ou seja, apesar de terem sido identi�cados
todos os requisitos que serão afetados, não são todos que serão modi�cados para a próxima entrega (próxima
versão).
Ao �nal do terceiro bloco, você percebeu a identi�cação das modi�cações dos requisitos e das relações entre
eles e como o foco em monitoramento proporciona habilidades ao responsável pelo gerenciamento de
requisitos para decidir, junto aos responsáveis pela operação, quais modi�cações são prioritárias.
Bons estudos!
VIDEOAULA
Ao assistir ao vídeo, você perceberá a importância da gestão e do controle de mudanças de requisitos no
processo de desenvolvimento de um software, como construir as boas práticas em mudanças e como monitorar
as atividades através interação entre os times de desenvolvimento e os responsáveis pela operação no
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 17/24
gerenciamento de requisitos, comumente utilizadas em projetos ágeis. 
 Saiba mais
Entre as principais causas de falha de projeto, é comum observar que a maioria dessas falhas estão
relacionadas a aspectos diretamente ligados aos requisitos. Sendo assim, o gerenciamento dos requisitos
constitui um fator de extrema importância para estabelecer o sucesso ou a falha de um projeto.
Uma poderosa ferramenta que auxilia a gestão dos requisitos é a prototipação do software. Através dela,
os envolvidos em um projeto podem veri�car as funcionalidades de um software e conferir se todos os
recursos estão atendendo aos requisitos estabelecidos.
Visite e leia o artigo sobre este assunto no livro de Reinehr (2020, p. 17-18).
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Atualmente, há uma procura incansável por meios e�cientes para a resolução de problemas relacionados às
falhas de gestão em projetos de software, seja em termos de atrasos, alteração de requisitos ou acréscimo de
custos. O responsável pelo projeto deve buscar otimizar o tempo de entrega baseando-se em diferentes
variáveis, como qualidade, requisitos, esforço e custo.
Por meio das metodologias ágeis, é possível ter alcance a uma gama de perspectivas que auxiliam os gestores
na resolução de problemas corriqueiros, preservando o cronograma, evitando a má qualidade das entregas. A
gestão das mudanças é imprescindível para garantir que o produto a ser entregue esteja de acordo com os
objetivos de negócio do sistema.
Desta forma, para atestar que ela ocorra de forma �uida e que seja possível avaliar todas as variáveis
fundamentais para o sucesso do projeto, estabelece-se e monitora-se uma Matriz de Rastreabilidade, que
estudaremos a seguir.
Desta forma, utilize nossos materiais e aprofunde seu conhecimento sobre a temática. Bons estudos!
ASPECTOS E GERENCIAMENTO DE MATRIZES DE RASTREABILIDADE
Aula 4
RASTREABILIDADE DEREQUISITOS
Atualmente, há uma procura incansável por meios e�cientes para a resolução de problemas
relacionados às falhas de gestão em projetos de software, seja em termos de atrasos, alteração
de requisitos ou acréscimo de custos. O responsável pelo projeto deve buscar otimizar o tempo
de entrega baseando-se em diferentes variáveis, como qualidade, requisitos, esforço e custo.
28 minutos
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 18/24
Diante do cenário atual, é altamente recomendável que todo projeto de software tenha um plano de
gerenciamento, em que se faz necessária a interação entre as diferentes equipes envolvidas, com foco principal
na redução dos custos e esforços e na entrega contínua. Na prática, todos os projetos de software são
agrupamentos de requisitos implementados, incluindo os mais diversos tipos.
Com a crescente exploração dos métodos ágeis, é comum nos depararmos com projetos de grande porte que
contêm ciclos de desenvolvimento mais curtos que os convencionais, fazendo com que o rastreamento de
requisitos se torne um grande desa�o atualmente. Através de um conjunto de requisitos bem de�nidos e um
método con�ável para o rastreamento destes é possível se assegurar que o projeto será bem-sucedido. Assim, a
Matriz de Rastreabilidade (RTM – Requirement Traceability Matrix) se trata de um método bem estabelecido
para este intuito.
Finalidade e elaboração de uma RTM
A rastreabilidade de requisitos consiste na manutenção de vínculos entre as propriedades dos requisitos e os
requisitos propriamente ditos, podendo compreender também outros artefatos. Uma Matriz de Rastreabilidade
de Requisitos pode ser vista como uma tabela onde as funcionalidades de um sistema (requisitos) são
representadas de forma relacional. Tal matriz é utilizada com a �nalidade de ter uma forma de rastrear as
relações entre os requisitos do sistema, com o intuito de minimizar os riscos do projeto, aumentar a
produtividade, identi�car possíveis impedimentos e bloqueios e minimizar pontos de contingência.
De fato, a rastreabilidade permite a elaboração de uma análise de impacto mais e�ciente na progressão do
sistema. Segundo Hirama (2012, p. 57), o rastreamento é fundamental para a análise de impactos quando os
requisitos mudam. A elaboração da Matriz de Rastreabilidade de Requisitos compreende alguns pontos
importantes que serão elencados a seguir.
Investigação inicial: este é o momento de diferenciar as principais necessidades e pormenores do
projeto; tal análise é crucial para que os envolvidos saibam quais são as perspectivas com relação ao
projeto e que possam assegurar que este seja homologado pelas partes interessadas.
Documentação de requisitos: etapa para fundamentar os requisitos. Tudo que é relativo aos requisitos
deve ser bem documentado e de�nido, podendo fazer uso de ferramentas e meios já utilizados na
empresa para facilitar o processo.
Especi�cação dos requisitos: este é o momento de fazer a junção das informações adquiridas nos pontos
anteriores para agregar informação a esta etapa que essencialmente classi�ca os requisitos
adequadamente. Estes podem ser funcionais ou não funcionais, por exemplo.
Composição da Matriz de Rastreabilidade de Requisitos: união das informações em uma matriz,
especi�cando os requisitos que pertencerão a ela, seus respectivos detalhes e categorizações por ordem
de precedência e prioridade. É importante também elencar os requisitos de acordo com o seu estado de
implementação, ou seja, "em re�namento", "em desenvolvimento", "ativo" ou "cancelado".
Tipos de Rastreabilidade (RTM)
Segundo Paula Filho (2019), podem ser observados dois tipos de rastreabilidade:
Rastreabilidade para trás: permite que seja identi�cada a origem do requisito, a razão, quem e o que
originou ele. Desta forma, é possível avaliar o impacto de uma possível mudança nele.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 19/24
Rastreabilidade para a frente: permite localizar os pontos que serão afetados por este requisito. Este
aspecto permite que os itens de análise, código e testes cubram todos os requisitos.
Ao �nal desse bloco, foi possível perceber que a rastreabilidade produzirá muitos benefícios no gerenciamento
das mudanças de requisitos, e você pode colocar em prática já o seu próximo projeto. Bons estudos!
PROCESSO DE ELABORAÇÃO DE UMA MATRIZ DE RASTREABILIDADE
As matrizes de rastreabilidade (RTM) são a base para diversas atividades de desenvolvimento na engenharia de
requisitos. Conforme apresentado em Pressman e Maxim (2021), a RTM pode propiciar continuidade para os
desenvolvedores à medida que um projeto muda de fase, independentemente do modelo utilizado, podendo,
inclusive, ser utilizada para certi�car-se de que os itens do projeto estejam em conformidade com todos os
requisitos e com o escopo do projeto. Ademais, uma RTM permite:
Gerenciar e avaliar o impacto das alterações no projeto.
Avaliar o impacto na falha de testes das funcionalidades relacionadas aos requisitos.
Avaliar o status em que se encontram os requisitos e determinar posteriores ações que devem ser
realizadas.
Fornecer a visibilidade de ponta a ponta para as atividades.
Validar se os requisitos do projeto foram atendidos.
Como elaborar uma Matriz de Rastreabilidade de Requisitos (RTM)?
Uma RTM é uma tabela, na qual as linhas são rotuladas com os nomes dos requisitos, e as colunas, com o nome
de um artefato de engenharia (PRESSMAN; MAXIM, 2021). Suponhamos que devemos criar uma RTM (Quadro 1)
com o artefato "objetivos de negócios" para uma loja de venda de produtos on-line. As linhas representarão os
requisitos, e as colunas, os itens que compõem os objetivos de negócio daquele produto.
Quadro 1 | RTM
Id Categoria Status Prioridade Fonte Objetivo de Negócio
REQ001 Mandatório Em desenvolvimento Alta Xxxxx
Permitir que o usuário
faça pesquisas por
produtos na loja.
REQ002 Deve existir Em re�namento Média Yyyyy
Permitir que o usuário
coloque produtos na lista
de desejos.
Fonte: elaborado pelo autor.
Existem dois tipos de rastreamento de requisito, que estão relacionados à possibilidade de distinguir a origem e
o destino de um requisito:
Rastreabilidade para trás.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 20/24
Rastreabilidade para frente.
A rastreabilidade para trás possibilita a identi�cação do contexto a partir do qual os requisitos foram originados,
enquanto a rastreabilidade para frente permite identi�car quais componentes implementam um determinado
requisito. A Figura 1 representa um exemplo de elementos da rastreabilidade.
Figura 1 | Ciclo entre elementos dos tipos de rastreabilidade
Fonte: elaborada pelo autor.
Percebe-se, cada vez mais, que o entendimento das necessidades dos clientes é transformado em requisitos e,
por �m, em artefatos de projeto, e deve estar devidamente relacionado e possibilitar a localização das regras de
negócio.
Se o patrocinador do projeto consultar o custo de um requisito modi�cado, ele pode obter os recursos usados
na modi�cação de um determinado requisito em consequência das atividades realizadas. Além disso, ele pode
ter a posse do montante dos esforços, compreendendo todos os artefatos modi�cados rastreados pela RTM.
Pelo ponto de vista da tecnologia, é possível relacionar todos os demais recursos envolvidos na modi�cação
realizada, tais como: módulos de integração (API) com terceiros, sistemas de banco de dados envolvidos,
linguagem de programação, dados para a realizaçãodos testes automatizados, entre outros
Conclui-se, ao �nal do segundo bloco, que as instituições e empresas devem estabelecer as suas políticas de
rastreabilidade com base nos processos de produção e gerência de requisitos. Tais políticas referenciam quais
aspectos e informações de rastreabilidade podem ser sustentados e como devem ser mantidos. Que tal você
também adotar a Matriz de Rastreabilidade no seu próximo projeto? Bons estudos!
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 21/24
MATRIZ DE FUNCIONALIDADES NA ORTO EH
Encare um desa�o para a elaboração de uma Matriz de Rastreabilidade que seja extremamente útil aos
interessados na administração do sistema que possui regras de negócio altamente complexo e crítico pelo
impacto causado quando os resultados não são alcançados. Antes da elaboração da Matriz de Rastreabilidade,
entenda alguns dos fatores que levaram a Orto EH a decidir pela informatização do sistema de atendimento no
seu pronto-socorro.
O grande volume de pacientes, um grau acima da média em rotatividade de funcionários, estava causando
alguns problemas na operacionalização das atividades consideradas básicas, tais como: desorganização das
�chas de pacientes, con�ito na agenda de pacientes, consulta rápidas demais para tentar realizar todos os
atendimentos, alto índice da relação quantidade de pacientes em espera e quantidade de atendentes da
enfermagem.
Você é o responsável pelo gerenciamento de requisitos do sistema de atendimento da Orto EH, fase em que se
necessita analisar os requisitos e seus relacionamentos, contudo a organização resolveu adotar a matriz de
rastreabilidade vertical para proporcionar maior segurança. Até a release (compõe uma versão parcial de um
software) da semana anterior, os requisitos eram mapeados numa matriz horizontal, conforme o Quadro 2.
Percebe-se que o preenchimento desse relacionamento entre requisitos e funcionalidades tem como base a
análise do entendimento das operações realizadas pelo operador do sistema.
Quadro 2 | Matriz de rastreabilidade horizontal
Requisitos e
História do
usuário
#01
Atualizar o
status do
atendimento
#02 Designar
os
responsáveis
pelo
procedimento
realizado
#03
Adicionar
sintoma
do
paciente
#04
Cancelar o
atendimento
#05 Incluir
ocorrência
no
prontuário
#06
Manter
cadastro
do
paciente
#07 Finalizar
o
atendimento
#08
Incluir
presc
médic
H#01
Registro de
sintomas do
paciente
X X X X
H#02
Registro de
diagnóstico
X X X
H#03
Apontamento
de exames
investigativos
X X
H#04
Registro do
prontuário
�nal
X X X X
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 22/24
H#N Demais
histórias
Fonte: elaborado pelo autor.
Embora o quadro não re�ita �elmente as funcionalidades do sistema de atendimento da Orto EH
completamente, é possível perceber como se constrói uma Matriz de Rastreabilidade. Agora, deve dedicar
esforços para a elaboração da Matriz de Rastreabilidade vertical, com a disponibilidade para usar nas duas
maneiras de tipo de rastreabilidade: pré-rastreabilidade e pós-rastreabilidade. Pré-rastreabilidade é encontrar
todos os artefatos identi�cados a partir do código-fonte até encontrar a sua origem quando foi de�nido pelo
usuário do sistema, e pós-rastreabilidade é partir das de�nições do requisito (ou da história do usuário) e
localizar todos os artefatos desenvolvidos até encontrar o código que implementa o requisito, conforme
demonstrado no Quadro 3.
Quadro 3 | Matriz de rastreabilidade de requisitos
Requisitos
e
Programas
do
software
#01
Atualizar o
status do
atendimento
#02 Designar
os
responsáveis
pelo
procedimento
realizado
#03
Adicionar
sintoma
do
paciente
#04
Cancelar o
atendimento
#05 Incluir
ocorrência
no
prontuário
#06
Manter
cadastro
paciente
#07 Finalizar
o
atendimento
#08
Incluir
prescriç
médica
@cf_prog01 X
@cf_prog02 X X
@cf_prog03 X X X
@cf_prog04 X X
@cf_progN
Fonte: elaborado pelo autor.
As representações nos quadros 2 e 3 são ilustrativas para uma explanação didática, pois, num processo real, é
necessário elaborar as planilhas usando um software especí�co para otimizar o gerenciamento de requisitos de
forma e�ciente. Compreendendo melhor essas matrizes de rastreabilidade, é possível simular uma modi�cação
na história do usuário H#03, quando se constata que serão alterados dois requisitos e que, por sua vez, é
obrigatório analisar dois códigos-fonte (@cf_prog01 e @cf_prog03).
Portanto, o gerenciamento indicará e analisará todos os itens envolvidos para elaborar o planejamento das
atividades, a estimativa do esforço necessário e, consequentemente, os casos de testes, entre outros fatores
desejáveis para o monitoramento do projeto.
Agora que chegou ao �nal do terceiro bloco, você viu os benefícios da Matriz de Rastreabilidade, então é só
começar a elaborar a sua matriz no seu próximo projeto.
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 23/24
Bons estudos! 
VIDEOAULA
Ao assistir ao vídeo, você será capaz de compreender a relevância de uma Matriz de Rastreabilidade e como
gerenciá-la dentro de um projeto de software. A partir do uso de uma RTM em conjunto com boas práticas de
gestão, sobretudo dentro de projetos ágeis, é possível que os tipos de falha mais comuns no desenvolvimento
de um sistema sejam evitados. 
 Saiba mais
A identi�cação das relações entre os requisitos é importante tanto para aspectos gerenciais quanto
aspectos técnicos em um projeto. É comum veri�car que a prática da rastreabilidade, utilizando casos de
teste, permite identi�car as ligações entre os requisitos, bem como identi�car aqueles que não têm casos
de teste. Quando a Matriz de Rastreabilidade (RTM) é bem elaborada, ela garante que o sistema seja
seguro e que cumpra os níveis de qualidade adequados.
Leia um artigo sobre processo de teste ligado à RTM no livro de Pressman e Maxim (2021, p. 383), no item
19.3.2 – Rastreabilidade.
Videoaula
Para visualizar o objeto, acesse seu material digital.
Aula 1
HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro, RJ: Elsevier Editora, 2012. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 28 maio 2022.
MPS.BR. Melhoria de Processo do Software Brasileiro Guia Geral MPS de Software. Softex, 2021. Disponível em:
https://softex.br/download/guia-geral-de-software-2021/. Acesso em: 28 maio 2022.
PAULA FILHO, W. de P. Engenharia de Software – Produtos – Vol. 1. Rio de Janeiro, RJ: LTC, 2019. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 28 maio 2022.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH Editora, 2021. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 26 maio 2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 26 maio 2022.
Aula 2
HIRAMA, Kechi. Engenharia de Software. Rio de Janeiro, RJ: Elsevier Editora, 2012. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 28 maio 2022.
REFERÊNCIAS
3 minutos
https://integrada.minhabiblioteca.com.br/#/books/9788595155404/
https://softex.br/download/guia-geral-de-software-2021/
https://integrada.minhabiblioteca.com.br/%23/books/9788521636724/
https://integrada.minhabiblioteca.com.br/%23/books/9786558040118/
https://integrada.minhabiblioteca.com.br/%23/books/9786556900674/https://integrada.minhabiblioteca.com.br/#/books/9788595155404/
29/03/2023, 15:26 wlldd_222_u3_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 24/24
Imagem de capa: Storyset e ShutterStock.
MPS.BR. Melhoria de Processo do Software Brasileiro. Guia Geral MPS de Software. Softex, 2021. Disponível em:
https://softex.br/download/guia-geral-de-software-2021/. Acesso em: 28 maio 2022.
PAULA FILHO, W. de P. Engenharia de Software - Produtos - Vol. 1. Rio de Janeiro, RJ: LTC, 2019. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 28 maio 2022.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH Editora, 2021. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 26 maio 2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível em:
https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 26 maio 2022.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de Requisitos. Rio de Janeiro, RJ: Brasport, 2016. Disponível em:
https://plataforma.bvirtual.com.br/Leitor/Publicacao/160193/epub/0. Acesso em: 08 jun. 2022.
Aula 3
HIRAMA, K. Engenharia de Software. Rio de Janeiro, RJ: Elsevier, 2012. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 15 jun. 2022.
IEEE. Recommended Practice for Software Requirements Speci�cations. [S. l.: s. n.], 1998.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH, 2021. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 jun. 2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 19 jun. 2022.
Aula 4
HIRAMA, K. Engenharia de Software. Rio de Janeiro, RJ: Elsevier, 2012. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9788595155404/. Acesso em: 15 jun. 2022.
PAULA FILHO, W. de P. Engenharia de Software – Produtos – Vol.1. Rio de Janeiro, RJ: LTC, 2019. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9788521636724/. Acesso em: 19 jun. 2022.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre, RS: AMGH, 2021. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9786558040118/. Acesso em: 14 jun. 2022.
REINEHR, S. Engenharia de Requisitos. Porto Alegre, RS: SAGAH, 2020. Disponível
em: https://integrada.minhabiblioteca.com.br/#/books/9786556900674/. Acesso em: 19 jun. 2022.
https://storyset.com/
https://www.shutterstock.com/pt/
https://softex.br/download/guia-geral-de-software-2021/
https://integrada.minhabiblioteca.com.br/%23/books/9788521636724/
https://integrada.minhabiblioteca.com.br/%23/books/9786558040118/
https://integrada.minhabiblioteca.com.br/%23/books/9786556900674/
https://plataforma.bvirtual.com.br/Leitor/Publicacao/160193/epub/0
https://integrada.minhabiblioteca.com.br/%23/books/9788595155404/
https://integrada.minhabiblioteca.com.br/%23/books/9786558040118/
https://integrada.minhabiblioteca.com.br/%23/books/9786556900674/
https://integrada.minhabiblioteca.com.br/%23/books/9788595155404/
https://integrada.minhabiblioteca.com.br/%23/books/9788521636724/
https://integrada.minhabiblioteca.com.br/%23/books/9786558040118/
https://integrada.minhabiblioteca.com.br/%23/books/9786556900674/
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 1/18
Imprimir
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá a validar os requisitos especi�cados, buscando eventuais con�itos e analisando a
consistência das funcionalidades levantadas. Aprenderá também sobre o processo de revisão da elicitação de
requisitos, que garantirá o sucesso entre o resultado desejado para o produto e o que será obtido ao �nal do
projeto. Como última etapa do aprendizado, você aprenderá a identi�car e tratar eventuais ambiguidades
relacionadas às funcionalidades levantadas.
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de
fontes con�áveis e não se limite apenas ao visto em aula.
Bons estudos! 
CONFLITOS E CONSISTÊNCIA DE REQUISITOS
Durante o processo inicial de escrita dos requisitos de uma aplicação, é comum que ocorram inconsistências e
dubiedades, e que, ao longo do tempo, com a realização de novas entrevistas com o cliente, ocorram também
ajustes e/ou correções nestas funcionalidades previamente escritas.
Aula 1
VERIFICAÇÃO DE REQUISITOS
Nesta aula, você aprenderá a validar os requisitos especi�cados, buscando eventuais con�itos e
analisando a consistência das funcionalidades levantadas, e, também, sobre o processo de
revisão da elicitação de requisitos, que garantirá o sucesso entre o resultado desejado para o
produto e o que será obtido ao �nal do projeto.
25 minutos
VERIFICAÇÃO, VALIDAÇÃO E DOCUMENTAÇÃO DE
REQUISITOS
 Aula 1 - Veri�cação de requisitos
 Aula 2 - Validação de requisitos
 Aula 3 - Documentação de requisitos
 Aula 4 - Testes de requisitos
 Referências
101 minutos
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 2/18
Às vezes, pelo prazo curto para a entrega do projeto, que re�etirá diretamente no encurtamento das fases de
desenvolvimento, o analista de requisitos, em projetos que utilizam metodologias tradicionais, como cascata ou
espiral, se preocupa apenas em escrever os documentos (artefatos da fase de especi�cação de requisitos), sem
se preocupar em validar com o cliente se o seu desejo está, de forma e�caz, descrito no texto.
O documento de especi�cação de requisitos, após concluído, será repassado à equipe de desenvolvimento,
para que o processo de construção do produto seja iniciado, de modo que um erro no entendimento da
funcionalidade poderá comprometer todo o sucesso do projeto. Então, a validação prévia deste documento, de
modo a ajustar os pontos necessários e evitar retrabalhos ou o insucesso, é uma etapa crucial.
A existência de diferentes interessados (stakeholders) no projeto, acarretando diferentes expectativas com o
sistema que será desenvolvido, pode ter como consequência requisitos especi�cados de formas con�itantes.
Pense, por exemplo, que um stakeholder visa obter o relatório do demonstrativo �nanceiro do último semestre,
já que isso agregará valor ao produto, em sua visão. Por outro lado, um outro interessado deseja que os
demonstrativos �nanceiros não sejam disponibilizados pelo sistema, por acreditar ser algo que se possa extrair
de outra forma. Caso os dois requisitos (o de extração e o de não extração) sejam especi�cados, serão
contraditórios.
Deve caber, então, ao analista responsável pela fase de elicitação de requisitos, a validação destes em conjunto
com o cliente (ou todas as partes interessadas), de modo a evitar que os requisitos sejam funcionalmente
opostos.
O cenário apresentado nos parágrafos anteriores, com dois requisitos sendo especi�cados de forma
contraditória, representa o conceito de consistência dos requisitos. Quando há um con�ito de interesse entre
diversos interessados, pode acontecer de o quesito consistência ser quebrado, só sendo percebido o problema
após a aplicação já estar em uso pelo cliente.
Um outro ponto em que podem acontecer problemas relacionados à consistência de um requisito são as regras
de validação. Muitas vezes, há a dependência entre requisitos funcionais diferentes no sistema, sendo que o
resultado de uma funcionalidade pode ser pré-requisito para uma segunda funcionalidade. Caso haja remoção
deuma pré-condição de um requisito que estava sendo validada por outro requisito, é importante que esta
validação também seja removida, garantindo a consistência.
Uma forma de identi�car eventuais inconsistências na especi�cação dos requisitos é validando o documento de
especi�cação de requisitos, junto ao detalhamento dos casos de uso do sistema, tendo em vista que a questão
da completude de um requisito está atrelada à necessidade de especi�cação de todas as regras necessárias
para que aquela funcionalidade possa ser codi�cada conforme as regras de negócio do cliente.
REVISÃO DA ESPECIFICAÇÃO DE REQUISITOS
Após as entrevistas de elicitação dos requisitos feitas na presença do cliente, o analista de requisitos terá um
papel importante: validar se tudo que foi escrito está de acordo com as necessidades reais das partes
interessadas pelo produto, da mesma forma que está escrita de forma clara, com todas as regras de validação
necessárias e com o detalhamento técnico su�ciente para a implementação pela equipe de desenvolvimento.
É comum que o cliente, mesmo conhecendo bem seu negócio, tenha di�culdades em expressar, de forma clara
e objetiva, seus interesses. Portanto, muitas vezes, em um primeiro momento, um requisito pode ser escrito de
forma parcial, incompleta, tendo seus ajustes feitos ao longo do processo de validação, que pode contar com
ferramentas visuais, como a prototipação das telas.
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 3/18
Um protótipo é a representação de uma tela ou de todas as telas da aplicação, de modo a comportar seus
campos, interações entre diferentes telas (mesmo de forma simulada), layout de cores e estilização, entre
outros aspectos visuais que servirão de base para a construção do sistema �nal. Essas telas e as interações
existentes (por exemplo, mensagens de validação de cadastros, regras de apresentação de campos etc.) podem
ser validadas ou não pelo cliente, de modo a ajustar o que será implementado com as suas reais necessidades.
Caso ajustes sejam detectados, os requisitos afetados serão reescritos, garantindo que a completude e a
consistência deles se mantenham. É importante que se mantenha o histórico das alterações realizadas, para
que as funcionalidades possam garantir suas rastreabilidades.
Esta etapa deve ser a última antes que o documento de especi�cação de requisitos seja repassado ao time de
desenvolvimento, para que se inicie o processo de construção do software. Dessa forma, a validação precisa
acontecer de forma minuciosa, revisando critério por critério de validação, �uxos alternativos (se não deixou
alguma opção alternativa de fora), se as especi�cações dos campos estão de acordo com o negócio, evitando
que haja retrabalho após a entrega do projeto já pronto ao cliente.
A importância do processo de validação de requisitos está relacionada ao custo de manutenção da aplicação.
Quanto mais cedo no projeto uma falha for detectada, menor será o custo de seu ajuste, �cando o maior custo
com manutenções corretivas feitas quando a aplicação já está em uso (produção).
As etapas da fase de validação dos requisitos, conforme apresenta Sommerville (2011), são:
Veri�cação de validade: análise das funcionalidades em termos de utilidade para os stakeholders, já que
os requisitos levantados podem não ser su�cientes para atender a todas as expectativas e novos requisitos
podem ser elucidados posteriormente.
Veri�cação de consistência: validação em relação às de�nições de cada requisito, que não podem ser
contraditórias.
Veri�cação de completude: requisitos precisam estar completos, ou seja, com todas as regras de negócio
envolvidas especi�cadas e detalhadas, de modo que sua implementação possa ser feita sem dúvidas.
Veri�cação de realismo: validação da viabilidade técnica, para que o requisito possa ser implementado,
utilizando as tecnologias desejadas.
Veri�cabilidade: é a validação de que, após pronto e entregue, os requisitos da aplicação atenderão aos
requisitos solicitados pelos interessados.
Revisões de requisitos: busca por erros de escrita ou inconsistências nas regras de negócio nos requisitos
especi�cados.
Prototipação: desenvolvimento de um protótipo do sistema, para que o cliente possa validar as suas
necessidades.
Geração de casos de teste: elaboração de cenários de testes para os requisitos especi�cados e seus
critérios de validação, a �m de validar se as respostas esperadas são as de fato obtidas para cada
funcionalidade. 
AVERIGUAÇÃO DE REQUISITOS AMBÍGUOS
A escrita, muitas vezes, leva a diferentes entendimentos por diferentes pessoas. Quando se trata de requisitos
de uma aplicação, não é diferente. A depender da forma como um requisito é escrito no documento de
especi�cação de requisitos, pode levar a ambiguidades de entendimento pela equipe de codi�cação e,
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 4/18
consequentemente, o produto poderá apresentar divergências em termos do que era esperado pelo cliente.
A elicitação de requisitos precisa ser feita de forma clara e com entendimento único por todos os envolvidos no
projeto, evitando ambiguidades na escrita tanto do detalhamento dos requisitos quanto dos critérios de
validação destes.
Uma causa comum para a ambiguidade na de�nição de um requisito é a falha do entendimento (ou
desconhecimento) do negócio que está sendo modelado. Se o cliente não tiver pleno conhecimento sobre as
regras do seu negócio, ou tiver alguma di�culdade em expressar estas regras de modo que o analista de
requisitos não consiga entender de forma clara, a ambiguidade poderá acontecer inevitavelmente.
Para a validação dos requisitos, algumas técnicas podem ser utilizadas, tais quais apresentadas por Kawai
(2005):
Checklists: planilhas com perguntas que devem ser direcionadas ao projeto que será analisado e de forma
precisa, para que possam ser respondidas pelos avaliadores.
Leitura baseada em perspectiva: visa validar requisitos que estejam em linguagem natural. Esta técnica
necessita que vários membros da equipe possam ler o documento de especi�cação de requisitos sob uma
determinada perspectiva (testador, usuário �nal etc.), de modo que as funcionalidades possam ser
analisadas em busca de falhas de entendimento ou especi�cação.
Técnica para construção de casos de uso e análise dos requisitos baseados em construção (TUCCA):
através da identi�cação dos atores e de suas respectivas funcionalidades, construindo, assim, os casos de
uso do sistema, será possível validar se os requisitos escritos estão, de fato, corretamente descritos e têm
seus entendimentos plenos e completos. A partir dessa técnica, é possível identi�car discrepâncias em
termos do que é esperado e do que está especi�cado para uma funcionalidade, gerando um relatório de
discrepâncias ao �nal do processo.
As técnicas para validação dos requisitos conseguirão encontrar alguns problemas típicos da escrita das
funcionalidades de uma aplicação, por exemplo:
Problemas relacionados com completude ou consistência dos requisitos.
Requisitos fora dos padrões de escrita adotados pela empresa que fará o desenvolvimento.
Con�itos de interesses e/ou ambiguidades nos requisitos especi�cados.
Erros técnicos no detalhamento das funcionalidades.
É importante salientar que o documento que servirá de entrada para a fase de validação dos requisitos deve ser
a versão �nal da especi�cação de requisitos, tendo em vista que esta versão já passou por uma etapa de
validação inicial e é a que será entregue como artefato para a próxima fase do andamento do projeto.
Os problemas detectados após a conclusão da fase de validação dos requisitos precisarãoser resolvidos
mediante o acordo de ações corretivas, de modo que os documentos sejam ajustados, caso necessário, ou as
funcionalidades já implementadas sejam readequadas, conforme a necessidade identi�cada. 
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá de que forma os requisitos podem ser validados através de
técnicas de validação, como também a resolver con�itos de entendimento dos requisitos especi�cados,
mantendo a consistência destes e ajustando eventuais ambiguidades que sejam detectadas. A fase de validação
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 5/18
dos requisitos será a última antes do início do desenvolvimento. 
 Saiba mais
A ferramenta de código aberto RE-Tools executa todo o processo de especi�cação e gerenciamento de
requisitos, disponível apenas para o sistema operacional Windows.
A ferramenta Spider-CL auxilia no processo de elaboração de checklists para testar as funcionalidades de
uma aplicação.
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá com mais detalhes como funciona o processo de validação dos requisitos, quais os
métodos e as técnicas que poderão ser aplicados para auxiliar no processo de validação e a garantir que o
documento de especi�cação de requisitos estará pronto para a próxima fase do processo de construção da
aplicação: a fase de implementação.
É importante que os requisitos levantados sejam revisados para se adequarem às reais necessidades do cliente,
respeitando o custo e o prazo desejados para o projeto.
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de
fontes con�áveis e não se limite apenas ao visto em aula.
Bons estudos! 
PROCESSOS DE VALIDAÇÃO DE REQUISITOS
Uma etapa crucial para o sucesso de um projeto de software é a validação dos requisitos, que terá por objetivo
principal garantir que os requisitos especi�cados, da forma como estão escritos, atenderão às reais
necessidades do cliente, além de serem tangíveis, ou seja, possíveis de serem codi�cados.
A equipe que está envolvida com a construção do produto, constituída por desenvolvedores, arquitetos de
software, analistas de requisitos, entre outros papéis importantes, deverá ler minuciosamente o documento de
especi�cação de requisitos (ou as histórias de usuário, no caso da utilização de metodologias ágeis) em busca
Aula 2
VALIDAÇÃO DE REQUISITOS
Nesta aula, você aprenderá com mais detalhes como funciona o processo de validação dos
requisitos, quais os métodos e as técnicas que poderão ser aplicados para auxiliar no processo
de validação e a garantir que o documento de especi�cação de requisitos estará pronto para sua
implementação.
25 minutos
https://sourceforge.net/projects/re-tools/
https://sourceforge.net/projects/spider-cl/
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 6/18
de eventuais inconsistências, ambiguidades ou requisitos que não sejam possíveis de serem codi�cados, devido
às limitações técnicas das tecnologias envolvidas.
Todo processo de validação dos requisitos deve contar também com a presença do cliente (ou de uma parte
interessada que tenha sólidos conhecimentos do negócio), para que eventuais dúvidas possam ser sanadas.
Um requisito é considerado validado quando suas regras estão totalmente especi�cadas, sem brechas para
interpretações dúbias, com o detalhamento su�ciente para que a equipe de desenvolvimento possa codi�car o
requisito apenas lendo o documento, sem a necessidade de consultas a fontes externas para esclarecimentos (o
cliente, por exemplo). Todos os critérios de validação de um requisito servirão como base para testes de
aceitação de primeiro nível (feito pelo desenvolvedor que construiu a funcionalidade) e de segundo nível (feito
em conjunto com o cliente), já em ambiente de validação ou homologação (prévio ao ambiente de produção).
Conforme Pressman e Maxim (2021), algumas questões são importantes para garantir o sucesso da fase de
validação dos requisitos:
1. Os requisitos atendem à expectativa quanto ao objetivo global do produto?
2. O nível de abstração está coerente com o esperado para cada requisito, para a fase atual do projeto?
3. A funcionalidade é considerada obrigatória para a aplicação, ou algo não essencial, como um recurso
adicional?
4. Os requisitos estão livres de ambiguidade?
5. Cada requisito tem seu próprio ator, ou seja, quem disparará a funcionalidade?
6. Existe algum con�ito dentro do conjunto de requisitos levantados?
7. Os requisitos são válidos tecnicamente? É possível implementá-los com as tecnologias envolvidas no
produto?
8. É possível testar o requisito após sua implementação?
9. O requisito está descrito de forma a especi�car sua funcionalidade e o comportamento que o sistema deve
ter após a sua execução?
10. O requisito está projetado para detalhar sua funcionalidade de forma progressiva, a depender da fase da
construção do produto?
11. O modelo de requisitos utilizado para escrita segue algum padrão especi�cado? Este padrão foi
previamente validado pela equipe e está de acordo com a necessidade do cliente?
Após responder a estas perguntas e a outras que surjam, eventualmente, ao longo do processo de
levantamento dos requisitos e dos ajustes deles, será mais provável que o documento resultante esteja em
conformidade com a necessidade do cliente, patrocinador do projeto. Sendo assim, a taxa de sucesso com a
construção do produto será alta, o que não ocorreria caso esta fase de validação não acontecesse de forma
su�ciente.
MÉTODOS DE VALIDAÇÃO DE REQUISITOS
Para realizar a fase de validação dos requisitos, é importante que seja utilizado algum método para guiar o
processo.
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 7/18
O processo de validação dos requisitos pode ser quebrado em pequenas fases, para garantir que o resultado do
processo será condizente com o esperado pelo cliente: um documento de especi�cação de requisitos que
re�ita, de fato, os anseios das partes interessadas com a aplicação que será construída.
Cada etapa do processo de validação revisará o documento de especi�cação de requisitos em busca de pontos
de falha especí�cos, que poderão ser ajustados para dar continuidade ao processo de revisão do documento.
Conforme Ayres (2021), existem seis tipos de revisão que compõem a fase de validação dos requisitos:
Revisão de especialista: nesta fase de revisão, uma pessoa especialista lerá os requisitos levantados e
dará seu parecer acerca de inconsistências, ambiguidades e outros possíveis erros encontrados no
documento. Além disso, proporá formas de correção dos problemas encontrados.
Inspeção dos requisitos: consiste em um trabalho cuidadoso em busca de erros nos requisitos
levantados, que podem comprometer a aplicação que será construída. É feita por uma equipe, com
diferentes papéis e funções, tais quais:
Organizador: controlará e planejará como o processo de inspeção acontecerá.
Moderador: moderará as reuniões da equipe, de modo a manter o foco no trabalho de inspeção.
Autor: precisa ter o conhecimento do negócio para explicar como as regras de cada requisito
funcionam aos membros da equipe. Além disso, deverá detectar e corrigir eventuais erros de
entendimento ou escrita que sejam encontrados.
Leitor: realizará a leitura dos requisitos para a equipe, de modo a manter a equipe focada no requisito
em si, sem a necessidade de entendimento do que o autor quis dizer.
Inspetores:membros responsáveis pela detecção e pelo relato de problemas para os demais
membros da equipe.
Secretário: responsável por organizar o resultado de cada reunião, assim como escrever sua ata.
O processo de inspeção dos requisitos acontece em fases, conforme ilustrado na Figura 1.
Figura 1 | Etapas do processo de inspeção de requisitos
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 8/18
Fonte: elaborada pela autora.
A Figura 1 apresenta as fases de um processo de inspeção dos requisitos de uma aplicação. A primeira fase é o
Planejamento, que determinará quais os objetivos a serem atingidos, como o processo será realizado e quais
as funções de cada participante na equipe. Na fase de Visão geral, o autor apresentará, de forma detalhada, os
requisitos à sua equipe, para que dúvidas possam ser esclarecidas. A fase de Detecção de falhas analisará os
requisitos em busca de falhas, a �m de preparar um documento com os pontos encontrados, o qual servirá de
entrada para a próxima fase. Por último, a fase de Coleta de falhas consolidará todos os pontos encontrados
ao longo do processo, eliminando problemas que tenham sido apontados em duplicidade ou falsos positivos
(pontos tidos como problemas, mas que, na verdade, não o são).
TÉCNICAS DE VALIDAÇÃO DE REQUISITOS
Para que as fases do processo de validação de requisitos sejam cumpridas de forma correta, ou que se tenha
um maior proveito do processo como um todo, conseguindo mapear e tratar a maior quantidade de pontos
possíveis de falha, é indicado que se apliquem técnicas.
É importante que você, ao participar de uma equipe de validação de requisitos, tenha conhecimento destas
técnicas, assim como os demais membros do time, pois a garantia de sucesso do produto que será construído e
entregue dependerá de quão bem de�nidos foram seus requisitos.
Uma das técnicas que podem ser utilizadas é a walkthrough, sendo caracterizada como uma inspeção
simpli�cada. Nesta técnica, uma pessoa pode desempenhar diferentes papéis, tendo seu objetivo principal a
identi�cação de falhas na escrita dos requisitos e no entendimento geral do negócio do produto. Ao �nal do
processo, os membros do time devem ter o entendimento nivelado acerca da necessidade do cliente e do que
está especi�cado.
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividadeI… 9/18
Uma outra técnica bastante utilizada é a PBR (validação baseada em perspectiva), na qual o documento de
requisitos é lido com base na visão de uma das partes interessadas ou dos membros do time de
desenvolvimento (como cliente, desenvolvedor, perspectiva de testes, entre outros, a depender do projeto).
A PBR permite, além das perspectivas já mencionadas, a visão a partir de outras perspectivas, como a
perspectiva de qualidade, que pode se dividir, conforme apresenta Ayres (2021), em:
Documentação: a documentação dos requisitos precisa estar seguindo o padrão acordado pelo time.
Conteúdo: traz a visão do conteúdo da funcionalidade, se condiz com o esperado para o requisito em
questão.
Acordo: busca chegar a um acordo a respeito de todos os requisitos levantados com relação a todos os
envolvidos no projeto, assegurando que não existem con�itos de interesses a serem resolvidos.
A prototipação é uma outra técnica muito boa para que o cliente possa realizar a validação dos requisitos de
modo visual, com protótipos funcionais de como o sistema deverá se comportar. Denominamos de protótipos
funcionais as telas da aplicação, construídas de forma simples (como com a linguagem de marcação HTML), com
a estilização necessária e pequenas interações com linguagem de script (como a Javascript). Estas interações
podem incluir apresentação de mensagens após a execução de algum comando (clique em algum botão, por
exemplo), alteração no �uxo das telas, entre outras ações visuais.
Os protótipos, após a fase de validação ter sido concluída, serão repassados para a equipe de desenvolvimento,
para que o sistema possa ser construído tendo as telas já validadas como base.
A utilização de checklists também é uma forma importante de validação, já que a partir da criação de perguntas
objetivas é possível identi�car problemas de ambiguidade (clareza da escrita), falhas na escrita que possam
deixar o requisito incompleto ou até nos critérios de validação, que podem não englobar todas as necessidades
de validação da funcionalidade.
As técnicas apresentadas podem ser utilizadas em conjunto, de modo que são complementares e auxiliam a
identi�car pontos que, eventualmente, possam ter passado desapercebidos pela equipe em alguma fase do
processo de validação.   
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá como aplicar os métodos e as técnicas de validação dos requisitos
e como a equipe poderá auxiliar para que o processo de validação aconteça e se tenha o melhor proveito de
seu resultado.
Você aprenderá também como as fases do processo de validação estão divididas e o que abordar em cada fase,
quem deverá participar do processo e como combinar técnicas de validação para um melhor resultado. 
 Saiba mais
Para criação de protótipos funcionais, é possível utilizar a ferramenta gratuita Just in mind.
Videoaula
Para visualizar o objeto, acesse seu material digital.
https://www.justinmind.com/
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 10/18
A ferramenta gratuita Ninja Mock também é uma boa alternativa para a construção de protótipos para
serem validados pelo cliente.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá como o seu documento de especi�cação de requisitos deve ser escrito e
estruturado, de modo a garantir que todas as informações sobre os requisitos estarão corretamente
documentadas. Aprenderá também quais os documentos resultantes de cada etapa do levantamento de
requisitos, desde as entrevistas iniciais até o documento revisado, pronto para a implementação. Uma boa
documentação deve estar sempre atualizada e condizente com as necessidades do cliente.
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de
fontes con�áveis e não se limite apenas ao visto em aula.
Bons estudos! 
ESTRUTURAÇÃO DO DOCUMENTO DE REQUISITOS
O documento de especi�cação de requisitos conterá toda a estrutura básica das funcionalidades de uma
aplicação que será construída, sendo fundamental que sua escrita seja feita com clareza e objetividade, sem
possibilidade de ambiguidades (todos os envolvidos precisarão ter exatamente o mesmo entendimento daquilo
que está escrito).
Este documento deverá conter um histórico de modi�cações, já que, ao passar do tempo, é comum que
alterações nos requisitos sejam feitas, seja para correção de alguma falha de escrita, inclusão ou exclusão de
alguma regra de negócio ou �uxos alternativos.
Para o primeiro capítulo do documento, é importante que informações básicas a respeito do projeto e da
aplicação que será construída sejam fornecidas, como o propósito da aplicação, as convenções de termos
adotados, a audiência e as sugestões de leitura do documento, o escopo do produto e, caso necessário, alguma
referência técnica a respeito de conceitos e termos que serão utilizados. Toda essa parte dará o embasamento
teórico à equipe envolvida a respeito das regras de negócio e do domínio da aplicação.
O próximo capítulo do documento deve abordar conceitos acerca do produto que será construído, como sua
perspectiva, funcionalidades, per�s de usuário e suas características, qual será o ambiente operacional,restrições de design e implementação, documentação do usuário, dependências e premissas. A documentação
do usuário é um documento em separado, geralmente em formato de manual de utilização da aplicação, tendo
em vista que deve ser escrito em linguagem mais próxima à natural, com a qual o usuário estará mais
familiarizado.
Aula 3
DOCUMENTAÇÃO DE REQUISITOS
Nesta aula, você aprenderá como o seu documento de especi�cação de requisitos deve ser
escrito e estruturado, de modo a garantir que todas as informações sobre os requisitos estarão
corretamente documentadas.
23 minutos
https://ninjamock.com/
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 11/18
Os próximos capítulos deste documento devem abordar eventuais relacionamentos externos com outros
sistemas, interfaces de comunicação (caso existam), requisitos de funcionamento, como performance,
segurança, hardware, entre outras necessidades que a aplicação venha a ter.
Por ser um documento voltado para a equipe técnica, com detalhes de implementação, ele deve ser mantido
sempre atualizado, de modo que qualquer alteração deve ser registrada no documento, com o respectivo autor,
data e conteúdo alterado, da mesma forma que, de preferência, deve ser armazenado em um repositório de
documentos, evitando, assim, a impressão e, consequentemente, a defasagem.
Apesar de ter a necessidade de validação pelos interessados no projeto, é recomendável a elaboração de um
manual de usuário, separado deste documento, para o treinamento e a consulta do usuário �nal (que nem
sempre é o patrocinador que encomendará a aplicação).
Quando o sistema a ser construído envolver poucos interessados, com baixa complexidade e poucas
funcionalidades, em um ambiente técnico bem de�nido e conhecido, o documento formal pode ser substituído
por casos de uso, envolvendo os cenários de uso dos requisitos, seus atores e �uxos alternativos. Apenas o
essencial para a equipe de desenvolvimento conseguir compreender as regras de negócio e implementar a
aplicação, respeitando o prazo e o orçamento acordados com o cliente.
DOCUMENTAÇÃO DA ESPECIFICAÇÃO DE REQUISITOS
O processo de especi�cação de requisitos deve ter sua documentação gerada e mantida, já que toda
documentação gerada nesta fase será repassada para as fases seguintes como artefatos de entrada, dando
subsídios para a construção do produto.
O início do processo é feito através da realização de entrevistas com o cliente, podendo ser representado por
diversas partes interessadas no projeto. Essas entrevistas iniciais servirão para elicitar os requisitos da
aplicação, de modo que o cliente deverá, através delas, expressar como cada função no sistema deverá se
comportar, quais resultados esperar a partir de quais entradas, entre outras questões importantes.
A partir do histórico dos questionários aplicados ao longo das entrevistas, será possível realizar o re�namento
inicial dos requisitos que deverão compor a aplicação, de modo a limitar o escopo, ou seja, a de�nir até que
ponto a aplicação atenderá às necessidades do cliente.
Após todas as funcionalidades terem sido identi�cadas, será necessário se reunir com o cliente mais algumas
vezes, para que a priorização dos requisitos seja de�nida e as funcionalidades que agreguem mais valor ao
cliente (e suas partes interessadas, de modo coletivo) possam receber o nível adequado de prioridade em sua
implementação.
Após o levantamento inicial dos requisitos, o projeto será continuado através da criação do documento de
especi�cação de requisitos, que será uma compilação de todos os requisitos levantados através das entrevistas
e rodadas de negociação com o cliente.
Para que o projeto seja continuado e a aplicação seja construída, é necessário que a equipe elabore um termo
de viabilidade técnica do projeto, que deverá ser assinado tanto pelo cliente quanto pelo analista de requisitos
(ou alguém com per�l técnico), após a análise das funcionalidades solicitadas e da viabilidade técnica para a
implementação utilizando as tecnologias envolvidas (linguagem de programação, ambiente tecnológico etc.).
Com as funcionalidades já de�nidas, será necessário realizar uma validação destas, processo que pode ser feito
através da elaboração de diagramas de caso de uso. Para cada ator do sistema (usuário com um determinado
per�l, que fará interação com o sistema), será necessário mapear todas as funcionalidades com as quais este
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 12/18
ator interagirá. Este passo será importante para o detalhamento, em momento futuro, de cada requisito.
Tendo em vista que um mesmo requisito precise de vários níveis de detalhamento para que todos os
interessados no projeto possam ter o mesmo entendimento a respeito da funcionalidade e seu
comportamento, é necessário que a documentação de cada requisito englobe também diversos níveis de
detalhamento. O diagrama de casos de uso é a visão mais macro, voltada para gestores e usuários não
especialistas em TI. Já a descrição dos cenários de uso de um requisito, com um nível de detalhamento um
pouco maior, será mais adequado para os usuários que dominem o negócio que está sendo modelado e em
cima do qual a aplicação será construída. Para a equipe de desenvolvimento, será necessário um detalhamento
maior do requisito, com detalhes técnicos (como quais campos, tabelas, tipos dos campos, entre outras
informações técnicas relevantes).
Ao �nal de todo o processo, todos os níveis de detalhamento e informações coletados deverão ser centralizados
no documento de especi�cação de requisitos, que será repassado para a equipe de desenvolvimento após a
validação e os ajustes necessários.
DOCUMENTAÇÃO DA ELICITAÇÃO DE REQUISITOS
O processo de elicitação de requisitos deverá gerar, ao seu �nal, uma série de artefatos que comporão a
documentação da aplicação que será construída.
As entrevistas feitas com o cliente (ou seu representante) para detalhar quais as funcionalidades do sistema
constituirão o documento de especi�cação de requisitos, da mesma forma que os diagramas gerados, que
poderão ser de casos de uso e de sequência, para uma validação inicial dos requisitos que deverão compor a
aplicação e, para um maior nível de detalhamento, diagramas de classe e da arquitetura do sistema.
Durante a fase de elicitação dos requisitos, eventuais relacionamentos da aplicação com sistemas externos
devem ser mapeados, o que pode auxiliar na geração de uma diagrama de arquitetura da aplicação,
apresentando cada item da arquitetura física (servidores, equipamentos de rede que serão utilizados pela
aplicação), como também da arquitetura lógica do sistema (como interfaces com outros sistemas e como o
relacionamento com estas interfaces será feito a partir da aplicação que será construída).
Outro documento importante que deverá ser construído como artefato da fase de elicitação dos requisitos é o
modelo de entidade – relacionamento (DER), envolvendo as tabelas do banco de dados e seus relacionamentos.
Nesta fase, os campos de cada tabela devem ser especi�cados pelo cliente, de acordo com seu negócio, assim
como restrições de entrada de dados e outras informações importantes para a construção das tabelas e de toda
a área do banco de dados que será destinada aos objetos da aplicação (o que denominamos esquema do banco
de dados).
Os requisitos não funcionais também precisarão ser especi�cados, de modo que todos os requisitos funcionais
englobados, de forma transversal, por esta categoria de requisitos deverão ter, em suas regras de validação e
em seus detalhamentos, o requisito não funcional envolvido.
Os cenários de uso de cada funcionalidadedeverão ser criados, ainda nesta fase, para que as partes
interessadas (stakeholders) possam descrever, conforme suas percepções, como cada requisito deve se
comportar na aplicação.
Os analistas de sistema e engenheiros de software que estiverem envolvidos na equipe de construção do
sistema devem, ao �nal do processo, analisar se as funcionalidades requisitadas pelo cliente são viáveis,
gerando um termo de viabilidade e necessidade para a aplicação. O escopo da aplicação também precisa ser
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 13/18
delimitado, já que será este marco que determinará quando o projeto chegou à sua conclusão.
Outro artefato importante é a lista dos clientes, usuários e demais pessoas que participem do processo de
levantamento de requisitos, já que estas pessoas serão os stakeholders da aplicação.
Todos os documentos gerados durante a fase de elicitação dos requisitos precisam ser revisados por todos os
envolvidos no projeto, para que encontrem eventuais pontos falhos, conforme suas respectivas percepções
acerca do sistema. Um conceito que pode ter um signi�cado para o setor de marketing, por exemplo, poderá ter
um signi�cado totalmente diferente para os usuários do setor de tecnologia, por isso a importância da validação
por todos os envolvidos.  
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá como elaborar um documento de especi�cação de requisitos,
quais informações colocar no documento e em que ordem. Aprenderá também quais os artefatos que devem
ser gerados após a fase de elicitação de requisitos e como escrever os requisitos funcionais e não funcionais,
para que possam ser repassados à equipe de desenvolvimento. 
 Saiba mais
Pressman e Maxim apresentam um modelo de documento de especi�cação de requisitos, que pode ser
acessado gratuitamente no seguinte link: https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc.
Um exemplo de documento de especi�cação de requisitos com dicas sobre o preenchimento pode ser
encontrado em:
https://docs.google.com/document/d/169gqhewVyVmXnj2AMLRP5IdnjnlcjUyxk4aH_TY0wcY/edit.
Videoaula
Para visualizar o objeto, acesse seu material digital.
INTRODUÇÃO
Olá, estudante!
Nesta aula, você aprenderá como realizar os testes nos requisitos de uma aplicação, através da criação e do
gerenciamento de um plano de testes.
Aprenderá também técnicas que podem ser utilizadas para realizar a testagem de uma aplicação e seus
requisitos, como o teste manual e o automatizado (incluindo algumas ferramentas que auxiliarão a criação de
seus testes), e a como gerenciar os artefatos que possuem dependências entre si.
Aula 4
TESTES DE REQUISITOS
Nesta aula, você aprenderá como realizar os testes nos requisitos de uma aplicação, através da
criação e do gerenciamento de um plano de testes.
26 minutos
https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc
https://docs.google.com/document/d/169gqhewVyVmXnj2AMLRP5IdnjnlcjUyxk4aH_TY0wcY/edit
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 14/18
Lembre-se de que você é o responsável pelo seu aprendizado. Sempre busque o conhecimento através de
fontes con�áveis e não se limite apenas ao visto em aula.
Bons estudos! 
PLANO DE TESTES DE REQUISITOS
Após o processo de elicitação de requisitos ter sido concluído, será necessário realizar testes para garantir que
o resultado obtido com a funcionalidade equivale ao esperado para ela.
A fase de testes é de extrema importância para garantir que o que está sendo entregue (a aplicação) está
condizente com os requisitos acordados com o cliente, sendo necessário se fazer um planejamento do que será
testado e como esses testes ocorrerão.
Ao se criar os cenários de caso de uso para cada funcionalidade, são determinados os critérios de validação e as
regras de negócio. Estes critérios, na fase de testes, servirão para de�nir como o requisito será validado, com
suas premissas e seus resultados esperados.
Todos os �uxos alternativos de um requisito também devem constar no plano de testes, de modo a cobrir todas
as possibilidades previstas na documentação.
O início do processo de testes, conforme apresentado por Sommerville (2011), é feito através dos testes
unitários, realizados pelo próprio desenvolvedor que está responsável por implementar a funcionalidade. Ele
deve executar seu teste local, sempre buscando comparar o resultado obtido (a resposta da aplicação) com o
que se esperava obter.
Após essa fase inicial, será necessário um teste de segundo nível, de preferência feito por outro desenvolvedor
ou membro da equipe, para que sejam evitados vícios de testes, que acontecem quando uma pessoa está
familiarizada demais com um código e uma funcionalidade e sempre utiliza o mesmo caminho para realizar o
teste. Uma pessoa diferente, sem o conhecimento do código e da funcionalidade, realizará os testes de formas
diferentes do desenvolvedor, podendo encontrar problemas que não foram identi�cados pelos testes unitários.
A última etapa, então, será disponibilizar ao cliente um ambiente diferente do que foi feito o desenvolvimento,
denominado ambiente de homologação, para os testes de aceitação. Nesta fase, o cliente deverá utilizar a
funcionalidade, buscando aceitá-la ou rejeitá-la, conforme sua necessidade.
O plano de testes, de forma prática, é composto por uma planilha, na qual devem ser detalhados as
funcionalidades, os seus critérios de aceitação e os cenários para a realização de cada teste destes critérios,
com as respectivas colunas de resultado esperado e resultado obtido, além de uma coluna de conclusão, que
deverá ser preenchida com o resultado global do teste, ou seja, caso o resultado obtido não esteja condizente
com o esperado, deve-se colocar nesta coluna qual foi a falha encontrada.
A ordem dos testes também deve constar no plano de teste, já que uma funcionalidade pode depender de
outras para conseguir ser testada.
Todos os testes feitos com base no plano de testes deverão ter seus resultados documentados e o histórico
armazenado, tendo em vista que, após as devidas correções e ajustes, será necessário executar todo o plano
novamente, já que a correção de um bug pode ter inserido novos bugs em funcionalidades que já estavam
validadas no sistema.
TÉCNICAS DE TESTES DE REQUISITOS
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 15/18
Para realizar os testes nas funcionalidades de uma aplicação, é possível utilizar técnicas que, além de auxiliar na
organização e execução dos testes, serão úteis para registrar que o teste aconteceu e seu resultado.
A primeira técnica é o teste manual, que deverá ser planejado e executado manualmente por um analista de
testes ou pelo desenvolvedor da funcionalidade. Nesta técnica, uma planilha deve ser criada com a
funcionalidade a ser testada, os critérios de validação, as ações (na aplicação) para que o teste possa ser
executado e os resultados esperados e obtidos. Caso algum desvio de comportamento da aplicação seja
percebido, deve-se coletar evidências, através de imagens de capturas de tela ou vídeos do passo a passo
executado, para que uma tarefa de correção possa ser aberta para a equipe de desenvolvimento.
Test Driven Development (TDD)
Uma outra técnica bastante utilizada é a Test Driven Development (TDD – Desenvolvimento Baseado em Testes),
na qual o caso de teste deve ser criado antes mesmo da implementação do requisito. Desta forma, caso alguma
anormalidade no comportamento esperado pelo requisito seja encontrada, poderá serdetectada de forma
rápida, sendo corrigida ainda na fase do desenvolvimento da funcionalidade.
A implementação da funcionalidade, com a utilização desta técnica, também será bene�ciada, já que será
possível planejar o desenvolvimento, atentando-se aos detalhes dos critérios de aceitação e das regras de
negócio.
Um outro benefício desta técnica é que, ao escrever o teste antes do desenvolvimento do código, evita-se que o
teste acabe sendo adaptado ao código, não re�etindo exatamente o que deveria ser testado. O código será
implementado para atender aos testes criados, não o contrário.
Behavior Driven Development (BDD)
Uma outra técnica utilizada para a execução de testes é a BDD (Desenvolvimento Baseado em Comportamento),
que se caracteriza por ser uma evolução da TDD, já que moldará as funcionalidades da aplicação ao domínio do
negócio do cliente. Assim como no TDD, os testes no BDD serão úteis no planejamento do desenvolvimento do
código.
A documentação dos requisitos será feita de forma dinâmica, uma vez que as regras de negócio e os testes
serão escritos de forma antecipada à implementação destes, mantendo-se atualizada à medida que alterações
ou ajustes vão sendo feitos na aplicação. Isso elimina o problema de defasagem na documentação, típico da
utilização de metodologias tradicionais, que apenas documentam a funcionalidade após a sua codi�cação.
Testes automatizados
Equipes de teste de uma organização tendem a executar inúmeros testes diários, em diferentes projetos, dos
mais diferentes domínios de aplicação. Desta forma, realizar todos os testes utilizando o método manual
demandaria muito tempo e esforço, ainda correndo o risco de falhas devido ao esquecimento de determinadas
regras ou à falta de atenção com todos os resultados obtidos nos testes.
Para auxiliar o processo de desenvolvimento e execução dos testes, ferramentas de automação podem ser
utilizadas, de modo que as principais funcionalidades da aplicação podem ter seus scripts de testes criados uma
vez e executados inúmeras vezes. É possível, por exemplo, realizar testes de stress da aplicação, com a
simulação de usuários simultâneos, testes em uma funcionalidade especí�ca ou até em um conjunto de
funcionalidades, o que se denomina suíte de testes.
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 16/18
GERENCIAR AS DEPENDÊNCIAS ENTRE OS DOCUMENTOS DE REQUISITOS
A consistência dos requisitos é uma das características mais importantes no processo de elicitação de requisitos
de uma aplicação. Dessa forma, é importante que não existam con�itos entre diferentes funcionalidades ou que
os critérios de pré-requisitos de uma funcionalidade não sejam contraditórios com critérios de validação de um
outro requisito da aplicação.
Durante a fase de elicitação de requisitos, principalmente nos momentos iniciais, nos quais ainda estão
acontecendo as primeiras entrevistas com o cliente para entendimento do negócio e de suas necessidades, é
comum a geração de diferentes artefatos, sem necessariamente se fazer uma análise em busca de problemas
de ambiguidade ou contradições.
Na fase de validação dos requisitos, após suas diversas etapas em busca de contradições e ambiguidades,
visando manter a consistência e a completude dos requisitos, o documento de especi�cação de requisitos
passará por diversos ajustes, quando inconsistências serão detectadas e corrigidas.
Um exemplo de inconsistência é quando, por exemplo, um caso de uso para um determinado ator no sistema
apresentar uma funcionalidade que, no momento do detalhamento dos requisitos, não é apresentada na
tabela. Então, caso os analistas tenham removido esta funcionalidade da tabela de detalhamento de requisitos,
deverão também remover da apresentação no diagrama de caso de uso. Isso garantirá que a consistência do
documento e dos requisitos será mantida.
Outros artefatos gerados como resultado da fase de elicitação dos requisitos precisarão ser analisados e
alterados, caso necessário, sempre que uma modi�cação seja feita em algum requisito, ou até quando uma
nova funcionalidade é adicionada à aplicação.
Uma forma de manter o controle dos documentos é através de repositórios de documentos, que guardarão
cada versão da documentação gerada, mas é preciso que todos os documentos relacionados ao projeto sejam
alterados, caso uma funcionalidade sofra modi�cações. Por isso, quanto mais documentos um projeto gerar,
maior trabalho e mais probabilidade de falha na atualização existirá.
As metodologias ágeis, por sua vez, prezam pela mínima documentação possível, enxugando todos os artefatos
considerados desnecessários, como o próprio documento de especi�cação de requisitos, que se converte em
histórias de usuário, com seus respectivos critérios de validação. Dessa forma, é necessário que as histórias
sejam mantidas atualizadas, conforme as modi�cações, que são dinâmicas ao longo do projeto, aconteçam.
Caso, por exemplo, uma nova tabela seja acrescentada no banco de dados da aplicação, será necessário
atualizar o modelo de entidade relacionamento da aplicação, assim como os requisitos que se relacionam com a
nova tabela inserida no modelo. Esta frequência de atualização, em projetos reais, não acontece com
frequência, sendo comum a defasagem no modelo de entidade relacionamento do projeto e nos documentos
auxiliares que detalham o atual estado do banco de dados.
Uma questão importante que deve ser tratada ao longo de um projeto é a forma como mudanças acontecem e
são solicitadas pelo cliente. É importante que a solicitação seja formalizada, através da abertura de chamados
em um sistema especí�co para este �m, para que a solicitação seja documentada e atendida, alterando o
comportamento do sistema.
Caso um sistema de abertura de chamados não seja utilizado, será necessário especi�car um modelo
padronizado para requisições de mudança, que servirá de base para a execução do processo.  
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 17/18
VIDEOAULA
Olá, estudante! Neste vídeo, você aprenderá como desenvolver um plano de testes para os requisitos de uma
aplicação, assim como a forma correta de utilizar técnicas para a realização de testes de requisitos. Além disso,
aprenderá como manter os artefatos gerados na fase de elicitação de requisitos que são dependentes entre si,
de modo a não quebrar a consistência dos requisitos.
 Saiba mais
Para utilizar a ferramenta de testes automatizados Katalon, você pode acessar o site o�cial em
https://katalon.com/.
Outra ferramenta de automação de testes, o Cypress, pode ser acessada em https://www.cypress.io/.
Uma ferramenta gratuita para escrever e gerenciar casos de teste é a TestLink.
Videoaula
Para visualizar o objeto, acesse seu material digital.
Aula 1
KAWAI, K. K. Diretrizes para elaboração de documento de requisitos com ênfase nos requisitos funcionais.
2005. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de São Carlos, São Carlos,
2005. Disponível em: https://repositorio.ufscar.br/bitstream/handle/ufscar/352/DissKKK.pdf?
sequence=1&isAllowed=y. Acesso em: 16 jun. 2022.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
Aula 2
AYRES, F. B. Técnicas para Realizar a Validação de Requisitos no Contexto da Internet das Coisas (IoT).
2021. Monogra�a (Graduação em Engenharia da Computação) – Universidade de Brasília, Brasília, 2021.
Disponível em: https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf. Acesso em: 22 jun.
2022.
PRESSMAN, R.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: McGraw Hill Education, 2021.
Aula 3
AYRES, F. B. Técnicas para Realizar aValidação de Requisitos no Contexto da Internet das Coisas (IoT).
2021. Monogra�a (Graduação em Engenharia da Computação) – Universidade de Brasília, Brasília, 2021.
Disponível em: https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf. Acesso em: 22 jun.
2022.
PRESSMAN, R.; MAXIM, B. R. Engenharia de software. 9. ed. Nova Iorque: McGraw Hill Education, 2021.
REFERÊNCIAS
2 minutos
https://katalon.com/
https://www.cypress.io/
https://testlink.org/
https://repositorio.ufscar.br/bitstream/handle/ufscar/352/DissKKK.pdf?sequence=1&isAllowed=y
https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf
https://bdm.unb.br/bitstream/10483/29876/1/2021_FelipeBritoAyres_tcc.pdf
29/03/2023, 15:27 wlldd_222_u4_eng_req
https://colaboraread.com.br/integracaoAlgetec/index?usuarioEmail=jcr_v8%40hotmail.com&usuarioNome=JULIO+CESAR+RODRIGUES+ROSA&disciplinaDescricao=ENGENHARIA+DE+REQUISITOS&atividade… 18/18
Imagem de capa: Storyset e ShutterStock.
Aula 4
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo, SP: Pearson, 2011.
https://storyset.com/
https://www.shutterstock.com/pt/