Livro_Completo

Prévia do material em texto

Fundamentos da engenharia de 
requisitos
APRESENTAÇÃO
Você já percebeu como a vida de todos é rodeada de produtos de software, mesmo que poucas 
pessoas se deem conta disto? Utilizamos smartphones diariamente para ouvir música, assistir 
filmes, jogar, chamar uma condução, pedir uma pizza, pagar uma conta ou fazer uma reserva de 
viagem. Isso sem falar do bate-papo virtual com os amigos ou daquela espiadinha nas redes 
sociais. Nossos hábitos do dia a dia são constantemente alterados pela introdução de novas 
tecnologias que passam a oferecer serviços que antes não eram possíveis.
Qualquer que seja o ramo de atuação de uma empresa, sua existência hoje só é possível pela 
presença maciça de produtos de software, seja para gerenciar o negócio, seja para viabilizar sua 
operação. Tente imaginar, por exemplo, como seria o funcionamento de um banco hoje sem a 
presença de software? E de um supermercado? E de uma indústria de manufatura?
Os meios de transporte, como automóveis, aviões e navios, nada mais são do que uma carcaça 
metálica e um emaranhado de componentes mecânicos e eletrônicos, operados e gerenciados por 
software, muito software. Você sabia que um carro de luxo possui mais de um milhão de linhas 
de código?
Como garantir que tudo isto funcione adequadamente e que os serviços sejam prestados de 
acordo com as necessidades? Tudo começa com a compreensão do que precisa ser construído, 
ou seja, começa com o entendimento dos requisitos! Se os profissionais da área de computação, 
não conseguirem identificar, analisar, especificar e gerenciar adequadamente os requisitos que 
devem estar presentes no produto de software, ele pode não atender às suas necessidades e, em 
última instância, não servir para nada. Pode ainda causar grandes prejuízos financeiros ou até 
mesmo custar a vida de alguém, como no caso da operação de veículos autônomos, por 
exemplo, ou de equipamentos médicos.
Nesta Unidade de Aprendizagem você aprenderá sobre a importância das atividades de 
Engenharia de Requisitos no ciclo de desenvolvimento de software e como requisitos mal 
compreendidos e mal definidos podem afetar a qualidade do produto final. Além disto, 
aprenderá sobre as atividades da Engenharia de Requisitos e como elas podem contribuir para 
que os problemas provenientes dos requisitos possam ser eliminados, ou pelo menos 
minimizados.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Discutir os problemas advindos dos requisitos em projetos de software.•
Reconhecer a importância da Engenharia de Requisitos no ciclo de vida de um software.•
Identificar as etapas da Engenharia de Requisitos.•
DESAFIO
A Engenharia de Requisitos, quando mal executada em projetos de software, pode ser a causa de 
diversos problemas, como, por exemplo, atrasos nas entregas, retrabalho, insatisfação do cliente, 
desgaste da imagem da empresa e erros que podem gerar prejuízos financeiros ou até mesmo a 
perda de vidas.
Conteúdo interativo disponível na plataforma de ensino!
Você, como novo contratado, precisa ajudar Paul na solução das questões levantadas. Para isso:
Encontre pelo menos 3 problemas que foram observados e as suas possíveis soluções.
 
INFOGRÁFICO
A Engenharia de Requisitos pode ser considerada como um conjunto de práticas necessárias ao 
tratamento de requisitos ao longo de todo o ciclo de vida de um produto de software, desde a sua 
concepção até a sua descontinuação. 
Acompanhe as atividades envolvidas na Engenharia de Requisitos no Infográfico a seguir. Nele, 
você poderá ver o fluxo das solicitações, desde a captura dos requisitos a partir das fontes de 
informação, até a validação, passando pelas etapas de gerenciamento de solicitações de 
mudanças.
CONTEÚDO DO LIVRO
Requisitos representam um dos pontos mais cruciais da produção de software. Requisitos mal 
compreendidos, mal especificados e mal gerenciados são uma das maiores causas de fracassos 
em projetos de Tecnologia da Informação. A Engenharia de Requisitos é a área da Engenharia 
de Software que oferece ferramentas para que o profissional de computação possa lidar 
adequadamente com os requisitos nas diversas fases do ciclo de vida de um produto de software.
No capítulo Fundamentos da Engenharia de Requisitos, do livro Engenharia de Requisitos, base 
teórica desta Unidade de Aprendizagem, você vai ler sobre os problemas causados em 
decorrência das deficiências no tratamento dos requisitos, bem como compreender a importância 
da Engenharia de Requisitos no ciclo de vida de um produto de software. Ao final, vai tratar das 
atividades que compõem a Engenharia de Requisitos.
Boa leitura.
ENGENHARIA DE 
REQUISITOS
Sheila Reinehr
Fundamentos da 
engenharia de requisitos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Discutir os problemas advindos dos requisitos em projetos de software.
 � Reconhecer a importância da engenharia de requisitos no ciclo de 
vida de um software.
 � Identificar as etapas da engenharia de requisitos.
Introdução
É inquestionável a presença da tecnologia em nosso dia a dia. Produtos 
de software fazem parte de praticamente todas as atividades humanas, 
sejam elas pessoais, sejam profissionais. Quando um software não funciona 
de forma adequada, sentimos o impacto por meio de transtornos, como 
a falta de sincronização de semáforos nas grandes cidades, o atraso e o 
cancelamento de voos, a impossibilidade de fazer uma compra on-line, 
a indisponibilidade de serviços bancários, e mais uma infinidade de con-
tratempos. Falhas em software também podem tirar vidas.
Uma das principais fontes de problemas em produtos de software 
está relacionada aos requisitos. Requisitos mal compreendidos, mal 
especificados e mal gerenciados podem comprometer o desempenho de 
produtos de software e representam uma das maiores causas de fracasso 
em projetos de tecnologia da informação. 
Neste capítulo, você vai ler sobre a importância do software na socie-
dade moderna e os impactos provenientes de problemas relacionados 
a requisitos de software. Verá também a importância da engenharia de 
requisitos no ciclo de desenvolvimento de software e sua influência nas 
atividades de desenvolvimento. Por fim, você vai saber como a enge-
nharia de requisitos pode ajudar a eliminar, ou pelo menos minimizar, 
os problemas relacionados a requisitos. 
1 Problemas advindos dos requisitos 
de software
Produtos de software estão presentes em todos os momentos de nossas vidas. 
Diariamente, mesmo sem nos darmos conta, entramos em contato com dife-
rentes tipos de software. Acordamos despertados por uma funcionalidade de 
nossos smartphones e olhamos a previsão do tempo disponibilizada por outro 
aplicativo. Saímos para o exercício matinal acompanhados do smartwatch, 
que registra todo o nosso desempenho, incluindo o tempo, o percurso e até 
mesmo os batimentos cardíacos. Retornamos e aquecemos o café da manhã no 
micro-ondas, cuja programação automática é feita por um software embarcado 
no eletrodoméstico. Em seguida pedimos o transporte, utilizando mais um 
aplicativo no celular. 
Ao chegar no trabalho, um mundo de diferentes sistemas de software nos 
apoia no dia a dia da empresa (email, mensagens instantâneas, programas 
de gestão, de controle de produção, de marketing, de vendas e por aí vai). 
Ao final do dia, cansados, voltamos do trabalho ouvindo uma música para 
relaxar usando o streamer de músicas e aproveitamos para, no caminho, pedir 
uma refeição no sistema de entrega de comida e acionar o ar condicionado 
de casa, para que esteja na temperatura ideal quando chegarmos. Ainda dá 
para marcar aquele encontro com os amigos para o final de semana, usando 
o aplicativo de troca de mensagens. Checamos nosso saldo no banco e veri-
ficamos se o débito automático da conta de luz foi realizado. Após o jantar, 
que pagamos com a máquina de cartão de crédito por aproximação docelular, 
encerramos o dia assistindo nossa série preferida no programa de streaming 
de vídeo e damos uma espiadinha nas redes sociais. O despertador já está 
programado para o próximo dia.
Praticamente nada disso seria possível sem o uso da tecnologia e dos 
sistemas de software que viabilizam esses serviços. Atualmente, todos os 
segmentos da atividade humana são permeados por software — e serão cada 
vez mais. Imagine, por um momento, se todo software do planeta parasse de 
funcionar. Quais seriam os impactos? Que atividades você realiza hoje que 
não poderia realizar? Que serviços essenciais deixariam de ser prestados? 
Algumas dessas facilidades estão tão enraizadas em nossas vidas que parece 
que elas sempre estiveram lá.
Com tantas novas tecnologias a cada dia, construir software se tornou 
uma atividade cada vez mais complexa. Se, por um lado, não temos mais as 
restrições de memória e de poder de processamento que tínhamos na década 
de 1960, a variedade e a complexidade dos elementos envolvidos atualmente 
Fundamentos da engenharia de requisitos2
trazem novos desafios para o desenvolvimento de software. Além disso, 
os ambientes de negócios se tornaram mais sofisticados e complexos. O re-
sultado é que desenvolver projetos de software não é uma atividade trivial, e 
os desafios começam na parte inicial do ciclo de vida: os requisitos.
Primeiramente, vamos definir requisitos. O Glossário padrão de termi-
nologia de engenharia de software do Institute of Electrical and Electronic 
Engineers (IEEE, 1990) define requisito como:
1. Uma condição ou capacidade necessária para um usuário resolver um 
problema ou alcançar um objetivo.
2. Uma condição ou capacidade que deve ser atendida ou tida por um 
sistema ou componente do sistema para satisfazer a um contrato, padrão, 
especificação ou outro documento formalmente imposto.
3. Uma representação documentada de uma condição ou capacidade con-
forme estabelecido em 1 e 2.
Independentemente de a empresa ter processos mais burocráticos e formais 
de desenvolvimento ou utilizar métodos ágeis, requisitos mal compreendidos 
e mal gerenciados são causa frequente de inúmeros prejuízos e insatisfações. 
Diversos são os exemplos de falhas de software que podem ser ligadas a 
problemas relacionados a requisitos e levar a milhões em prejuízos. Vamos 
dar uma olhadinha em algumas delas?
 � Na década de 1990, o Aeroporto de Denver, no Colorado, havia 
sido projetado para ser o maior hub de aviação dos Estados Unidos. 
Um dos pontos mais críticos estava relacionado aos requisitos que 
o sistema de gerenciamento de bagagens deveria atender para que o 
tempo em solo das aeronaves pudesse ser limitado a apenas 30 minutos. 
A complexidade técnica para implementar esse requisito foi subes-
timada, uma vez que o algoritmo de roteamento das bagagens não 
era trivial. Isso levou a um atraso de 16 meses na inauguração e a 
um prejuízo de 1,1 milhão de dólares ao dia para a cidade de Denver 
(CALLEAM CONSULTING, 2008).
 � Em 1996, o foguete europeu Ariane 5 explodiu em pleno ar apenas 
66 segundos após ter sido lançado. A causa principal foi o requisito de 
reutilizar o software de seu antecessor, o Ariane 4, que tinha alguns 
campos internos com tamanhos diferentes do Ariane 5. O requisito de 
compatibilidade entre os modelos não foi corretamente analisado e o 
prejuízo estimado foi de 370 milhões de dólares (HINKEL, [201-?]).
3Fundamentos da engenharia de requisitos
 � Em 1999, a sonda espacial climática da NASA que iria para Marte 
errou o ponto de inserção orbital no planeta, realizando a manobra 
com um erro de 100 km, o que ocasionou a destruição do equipamento 
e gerou um prejuízo estimado de 125 milhões de dólares. A causa foi 
um problema no sistema de conversão de medidas — enquanto uma 
equipe estava usando o sistema métrico decimal, a outra estava usando 
o sistema imperial (ISBELL; SAVAGE, 1999). 
 � Em 2019, a Boeing foi obrigada a suspender toda a frota de 387 aviões 
do modelo Boeing 737 Max, que voavam para 59 companhias aéreas em 
todo o mundo. O fato ocorreu depois que dois acidentes aéreos tiraram 
a vida de 346 pessoas em menos de 5 meses. A causa foi atribuída a 
problemas encontrados no novo software de controle de voo que havia 
sido implantado (BOEING…, 2019).
Esses são apenas alguns dos inúmeros exemplos ocorridos, cuja conse-
quência pode ser a perda de vidas ou o prejuízo financeiro, ou ambos. No dia a 
dia das empresas de software, a consequência mais comum dos problemas em 
requisitos é o aumento do retrabalho, ou seja, a necessidade de refazer coisas 
que já estavam prontas, levando a custos não previstos inicialmente. Quanto 
mais longe do início do projeto ou da sprint se percebe o problema, mais caro é 
para consertar. Quanto mais atividade já tiver sido realizada sobre o requisito 
(especificação, implementação, testes, entrega), mais difícil e trabalhoso é 
consertar e maiores são os impactos negativos para o projeto ou para a sprint. 
Sprint é o termo que denomina um ciclo de desenvolvimento em uma empresa que 
utiliza o método ágil Scrum. Uma sprint tem uma duração de duas a quatro semanas 
e visa à entrega de um item possivelmente liberável e que agrega valor ao cliente 
(SCHWABER; SUTHERLAND, 2018).
Fundamentos da engenharia de requisitos4
Os problemas estão relacionados ao fato de que um requisito pode:
 � estar incompleto;
 � estar em um nível de detalhe insuficiente para as etapas seguintes do 
ciclo de desenvolvimento;
 � conter ambiguidades ou imprecisões que levem os membros da equipe 
a interpretá-lo de forma diferente do que o esperado, levando a erros 
nas fases seguintes do ciclo de desenvolvimento;
 � ser incompatível com outro requisito;
 � ser tecnicamente inviável;
 � ser difícil de testar e validar;
 � ter priorização conflitante sob a ótica dos diversos stakeholders.
E por que esses problemas acontecem com os requisitos? Existem diversos 
motivos pelos quais esses problemas podem acontecer, e isso varia de acordo 
com o tipo de projeto, com o contexto de negócio, com as características da 
equipe e das tecnologias envolvidas. Um projeto simples, cujo contexto de 
negócios é dominado pela equipe técnica, vai ter menos riscos associados a 
requisitos do que um projeto que envolva uma equipe menos experiente ou 
um negócio muito inovador e sem histórico anterior. 
Existem projetos que têm um cliente bem definido e usuários com perfis 
conhecidos. Nesse contexto, os requisitos podem ser obtidos pelo contato 
direto com o cliente ou com os próprios usuários. Os requisitos, nesse caso, 
podem falhar por problemas de comunicação entre as partes, nos quais cada 
uma tem uma perspectiva diferente e até mesmo um vocabulário diferente. 
É comum ouvir que os usuários não sabem o que querem, mas, na verdade, 
por mais que eles saibam, sua perspectiva pode mudar pelo simples fato de 
entrarem em contato com a equipe, por experimentar a primeira versão de 
um protótipo ou mesmo pelo fato de que suas necessidades mudam ao longo 
do tempo. Os efeitos da mudança vão depender de diversos fatores, mas o 
seu tratamento vai depender fortemente do grau de confiança entre as partes. 
Quanto maior o grau de confiança, mas fácil é de se gerenciar as mudanças 
nos requisitos e suas consequências para o projeto, para o produto e para o 
relacionamento entre as partes.
Há projetos que são inovadores e visam a criar um produto de software que 
não existe ainda, como é o caso das startups de tecnologia. Nesse cenário, de 
onde podem vir os requisitos? Eles podem ser resultantes da própria equipe 
que está criando o produto, com base no que elas enxergam que o mercado 
5Fundamentos da engenharia de requisitos
precisa. Por esse motivo, para esses casos, um MVP (minimum viable product 
ou produto mínimo viável) é criado para analisar se a ideia pode ou não ir 
adiante. Quanto mais cedo surge falha, mais cedo a ideia é pivotada e um novo 
ciclo de desenvolvimento é iniciado, com novos requisitos. 
Quanto maiora capacidade da equipe de perceber os requisitos que o mercado deseja 
para o produto, maiores são as chances de sucesso da startup.
Há casos ainda em que o projeto visa a uma atualização tecnológica de 
um produto, na qual a própria versão anterior do produto pode ser a fonte de 
requisitos. Nesses casos, a qualidade dos requisitos obtidos depende fortemente 
da qualidade do sistema anterior e da habilidade da equipe em extrair esses 
requisitos.
Algumas das causas mais frequentes dos problemas relacionados a requi-
sitos, de acordo com Wiegers e Beatty (2013), são:
 � os objetivos de negócio, a visão e o escopo do projeto nunca foram 
definidos claramente;
 � os clientes estavam muito ocupados para dedicar mais tempo trabalhando 
com os analistas ou os desenvolvedores nos requisitos;
 � o time não pode interagir diretamente com usuários representativos 
para entender suas necessidades;
 � os clientes argumentaram que todos os requisitos eram críticos, por 
isso eles não estabeleceram prioridades;
 � os desenvolvedores encontraram ambiguidades e informações faltan-
tes quando foram codificar, então, eles precisaram adivinhar certas 
informações;
 � as comunicações entre o cliente e os desenvolvedores focaram na apa-
rência da interface do usuário e não no que os usuários necessitavam 
alcançar com o software;
 � os clientes nunca aprovaram os requisitos;
 � os usuários aprovaram os requisitos para um release ou iteração e então 
mudaram eles continuamente; 
Fundamentos da engenharia de requisitos6
 � o escopo do projeto aumentou à medida que as mudanças de requisitos 
foram aceitas, mas o cronograma se desviou porque nenhum recurso 
adicional foi fornecido e nenhuma funcionalidade foi removida;
 � as mudanças solicitadas nos requisitos foram perdidas; ninguém sabia 
o status de solicitações de mudanças específicas;
 � os clientes requisitaram certa funcionalidade e os desenvolvedores a 
desenvolveram, mas ninguém nunca utilizou;
 � ao final do projeto, a especificação foi satisfeita, mas o usuário e os 
objetivos de negócio não.
Relembrando o que Frederick Brooks já nos alertava em 1987 (BROOKS, 
1987, p. 13):
A parte mais difícil ao se construir um sistema de software é decidir precisa-
mente o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil 
quanto estabelecer os requisitos técnicos detalhados, incluindo a interface 
com as pessoas, máquinas e outros sistemas de software. Nenhuma outra 
parte afeta tanto o sistema resultante se for feita de forma errada. Nenhuma 
outra parte é tão difícil de consertar depois.
2 Ciclo de vida de software e engenharia 
de requisitos
O ciclo de vida de um produto de software pode ser compreendido como um 
conjunto de etapas pelas quais o produto passa ao longo de sua existência, 
conforme ilustra, de forma simplificada, a Figura 1.
Figura 1. Ciclo de vida de um produto de software.
CONCEPÇÃO
DESENVOLVIMENTO
MANUTENÇÃO
DESCONTINUAÇÃO
Identi�cação da ideia
inicial e análise da
viabilidade de se
construir o produto
Especi�cação,
implementação e
implantação do 
produto de software
Manutenção corretiva 
e adaptativa do 
produto de software
ao longo de sua vida
útil em atividade
Desativação do produto
de software quando ele 
se torna obsoleto e
não é mais necessário
7Fundamentos da engenharia de requisitos
Concepção
Inicialmente, a necessidade de um novo produto de software é identificada e 
a viabilidade de sua construção é analisada. Como produtos de software podem 
ter diversas naturezas, a fonte dessa necessidade pode variar enormemente, 
especialmente hoje, quando a tecnologia permeia todas as nossas atividades, 
como vimos no início deste capítulo.
Na fase de concepção, os primeiros requisitos aparecem na forma de 
objetivos de negócio de alto nível, do tipo: “Precisamos de um software para 
apoiar o gerenciamento do fluxo de solicitações”. Às vezes esse objetivo vem 
atrelado a uma meta: “(…) de modo a reduzir o tempo de prestação do serviço 
a 6 horas”. Ainda assim, não sabemos exatamente o que precisa ser construído, 
até que sejam detalhados os requisitos que representam as funcionalidades do 
produto, conhecidos como requisitos funcionais de produto. Então evoluímos 
para algo do tipo: “O sistema deve ter uma função que emita alertas toda vez 
que uma solicitação estiver parada por mais de 2 horas”.
Nesse momento é também comum que surjam os requisitos de projeto 
e de processo. Os requisitos de projeto podem impor restrições ao projeto 
em si, e podem ser relacionados com os prazos, os recursos e o orçamento. 
Já os requisitos de processo podem imprimir restrições relacionadas à forma 
como o projeto será desenvolvido, como, por exemplo, um método específico 
de desenvolvimento.
De posse dessas informações iniciais, é possível avaliar a viabilidade de 
se dar início ou não ao Desenvolvimento. Um projeto pode ser cancelado 
antes mesmo de ter sido iniciado. Isso pode ocorrer por diversos motivos, 
entre eles o fato de o escopo não estar suficientemente claro para que se possa 
comprometer recursos para a sua execução.
Desenvolvimento
A fase de desenvolvimento compreende todas as atividades necessárias para 
a produção do software. Isso inclui aquelas relacionadas a requisitos, análise 
e design, implementação, testes, homologação e implantação, além de todas 
as atividades de suporte ao desenvolvimento e à gestão do desenvolvimento, 
conforme ilustra a Figura 2.
Fundamentos da engenharia de requisitos8
Figura 2. Etapas do desenvolvimento de software.
Embora o termo “etapas do desenvolvimento” esteja sendo utilizado, aqui ele não 
se refere a um modelo de ciclo de vida sequencial ou cascata. Essas etapas são mais 
parecidas com disciplinas, que podem se intercalar e se repetir à medida que o projeto 
avança, de forma iterativa e incremental. A Figura 2 ilustra essas etapas.
Quando um projeto de desenvolvimento de software tem início, é comum 
que um escopo esteja estabelecido, mesmo que esse escopo ainda esteja em um 
nível alto de granularidade. A partir daí, as atividades relacionadas a requisitos, 
que tiveram início na etapa de concepção, são intensificadas. Os detalhes 
referentes à engenharia de requisitos serão explorados na próxima seção.
Dependendo do tipo e criticidade do projeto, uma vez estabelecidos os 
requisitos, têm início as atividades de design. Essa etapa consiste em projetar a 
solução que implementará os requisitos. Esses modelos ajudam a aprofundar a 
compreensão do contexto e a delinear a solução que será implementada. Mesmo 
empresas que utilizam métodos ágeis costumam ter uma sprint zero, que se 
dedica a conceber a arquitetura da aplicação. Nesse momento é estabelecida 
a arquitetura do sistema, os componentes e como eles se relacionam.
9Fundamentos da engenharia de requisitos
Durante a etapa de análise e design podem emergir novos requisitos, 
derivados ou não daqueles que foram inicialmente elicitados. Isso pode ocorrer 
porque, ao modelar a solução, o analista de sistemas pode:
 � identificar requisitos técnicos adicionais, advindos da arquitetura 
escolhida;
 � perceber que determinados requisitos não têm viabilidade técnica de 
execução;
 � identificar requisitos conflitantes;
 � identificar requisitos incompletos ou imaturos para a implementação
Uma vez definidos os componentes no nível de detalhe compatível com 
as necessidades do projeto, iniciam as atividades de Implementação. Note 
que aqui pode haver um paralelismo de atividades, pois os componentes 
podem ir sendo especificados ao mesmo tempo em que outros já estão sendo 
implementados. Nessa etapa o desenvolvedor ainda pode detectar problemas 
nos requisitos, devido à inviabilidade técnica de implementar.
Ao concluir a codificação, o desenvolvedor realiza os testes individuais 
nas unidades pelas quais foi responsável pela implementação. Nesse momento 
são realizadas as atividades de verificação, usando os casos de teste manuais 
ou automatizados.
Há empresas que utilizam a abordagemDevOps, integrando o ciclo de 
desenvolvimento ao ciclo de operação em produção. Isso é feito utilizando 
os conceitos de integração contínua (CI, continuous integration) e entrega 
contínua (CD, continuous delivery) e implantação contínua (CD, continuous 
deployment). Entende-se por CI o fato de haver uma integração automática 
à medida que o desenvolvedor sobe o seu código para o repositório e este se 
integra a outras partes do código que foram desenvolvidas por outros desenvol-
vedores. Já a entrega contínua (CD) se refere a entregar uma solução integrada 
para o pessoal de implantação poder realizar a passagem para o ambiente de 
produção, e a implantação contínua (utiliza-se a sigla CD também) se refere 
à passagem automática para o ambiente de produção.
Quer conhecer mais sobre DevOps? Consulte o livro Jornada DevOps: unindo cultura ágil, 
Lean e tecnologia para entrega de software de qualidade, organizado por Muniz et al. (2019).
Fundamentos da engenharia de requisitos10
Manutenção
A maior parte do tempo de vida de um produto de software se passa na etapa 
de Manutenção. A partir do momento que a primeira funcionalidade entra 
em produção e o produto começa a ser utilizado, já começam as requisições 
de mudanças, sejam elas por bugs encontrados pelos usuários, sejam por 
demandas de ordem legal/fiscal ou por melhorias e novas funcionalidades.
Na etapa de Manutenção, ocorre a maior parte das atividades de gerencia-
mento dos requisitos. Isso significa que a rastreabilidade é a ferramenta mais 
importante para a análise do impacto das solicitações de mudanças.
Descontinuação
Quando o produto de software não atende mais aos seus propósitos ele é 
descontinuado, ou seja, ele é retirado do ambiente de produção. Em alguns 
casos, basta solicitar a desinstalação do produto, como é o caso dos aplicativos 
que temos em nosso celular. Mas, na maioria das vezes, a descontinuação não 
é uma atividade tão simples.
Para descontinuar, por exemplo, um software de gestão do tipo ERP (en-
terprise resource planning, ou sistema de gestão empresarial), são necessários 
muitos anos, pois a transição para outro produto/fornecedor não é tão simples. 
Muitas vezes é necessário construir outro sistema para que se possa fazer a 
migração de dados e processos para o novo produto. Nesses casos, é importante 
compreender os requisitos da desativação. 
O negócio no qual o software está inserido pode ter requisitos específicos relacionados 
a questões de ordem legal e/ou fiscal, como o arquivamento de dados e documentos 
por um longo período. Por exemplo, contratos de trabalho precisam ser guardados 
por tempo indeterminado, enquanto outros documentos requerem prazos de 5, 
10, 20 e até 30 anos. Além disso, é preciso planejar a forma como esses dados serão 
recuperados em caso de necessidade. Esses são requisitos que podem estar presentes 
no projeto de desativação de um produto de software.
11Fundamentos da engenharia de requisitos
3 Etapas da engenharia de requisitos
Agora que já entendemos quais problemas podem vir dos requisitos e com-
preendemos a importância da engenharia de requisitos para lidar com essas 
questões, vamos conhecer quais são as atividades a serem realizadas nessa 
etapa do desenvolvimento de software.
Falar em etapas da engenharia de requisitos pode sugerir que estamos 
nos referindo a um modelo de desenvolvimento cascata, cheio de burocracias 
e distante da realidade atual das empresas. Na verdade, no contexto deste 
capítulo, estamos considerando que as etapas da engenharia de requisitos 
são atividades que devem ser realizadas no desenvolvimento de produtos 
de software, independentemente do modelo de ciclo de vida que está sendo 
utilizado. O momento de realização dessas atividades e os artefatos envolvidos 
poderão variar, mas a essência é a mesma — o que varia é a forma. O objetivo 
é um só: construir produtos de software melhores e mais confiáveis!
Como você pode observar na Figura 3, a engenharia de requisitos compre-
ende duas grandes etapas: o desenvolvimento e o gerenciamento. No desen-
volvimento de requisitos estão englobadas as atividades de elicitação, análise, 
especificação e validação, as quais veremos em mais detalhes a seguir.
Figura 3. Etapas da engenharia de requisitos.
Fundamentos da engenharia de requisitos12
Elicitação de requisitos
A elicitação se refere à etapa de investigação dos requisitos. É o momento em 
que a equipe técnica precisa compreender o que deve ser feito. Antigamente, 
o termo utilizado era “levantamento de dados”, no entanto, essa expressão 
está em desuso e, em seu lugar, usamos a expressão “elicitação de requisitos” 
para denotar algo mais forte, que remete a uma busca ativa pelos requisitos. 
Isso significa que o analista de requisitos ou papel similar (analista de 
negócios, analista de sistemas, product owner ou equivalente) deve adotar 
uma postura proativa para a descoberta e o entendimento dos requisitos. Isso 
implica em utilizar diversas formas de elicitação, de acordo com o contexto 
em que o sistema está sendo desenvolvido. Outros termos associados a esta 
etapa podem ser: captura de requisitos, descoberta de requisitos ou aquisição 
de requisitos (BOURQUE; FAIRLEY, 2014).
Quando falamos da Elicitação de requisitos não estamos enfatizando que 
é necessário ter todos os requisitos extensivamente detalhados no início do 
projeto, ou que esta etapa ocorra uma única vez no início do projeto. Em pro-
jetos ágeis, os requisitos podem emergir em diversos momentos, compondo o 
product backlog. No entanto, é importante ter em mente que alguns requisitos, 
quando descobertos muito tardiamente no ciclo de vida de um projeto, podem 
implicar em grande quantidade de retrabalho e custos adicionais. Esse é o caso, 
por exemplo, dos requisitos que impactam fortemente sobre a arquitetura do 
produto — esses são mais difíceis de serem alterados posteriormente.
Product backlog (ou “backlog do produto”) é o termo utilizado para denominar um 
conjunto de itens conhecidos que devem ser desenvolvidos para determinado produto. 
Quando itens do product backlog são priorizados para serem desenvolvidos em uma 
sprint, então, esse subconjunto é chamado de sprint backlog. O termo é comum em 
empresas que utilizam o método ágil Scrum (SCHWABER; SUTHERLAND, 2018).
13Fundamentos da engenharia de requisitos
O processo de elicitação exige uma intensa comunicação com os stakehol-
ders do projeto. É no processo de comunicação que o analista de requisitos 
identifica o que realmente é imprescindível para o desenvolvimento do produto 
e não perde tempo detalhando o que não é importante ou que não precisa 
de detalhamento naquele momento. A comunicação ineficaz pode levar a 
requisitos incompletos e incorretos.
Há casos em que a comunicação com os stakeholders é direta e é possível 
aplicar técnicas como entrevistas e reuniões, pois existem fontes de infor-
mação humanas que compreendem o contexto de negócio e podem prover as 
informações necessárias para a definição dos requisitos. Delinear histórias 
do usuário ou mapear a jornada do usuário pode ajudar. Ambos se baseiam 
na narrativa de uma história de uso do sistema por um usuário.
No caso dos produtos inovadores, que estão sendo criados sem uma ex-
periência anterior, ou que tenham um propósito disruptivo, é necessário que 
sejam utilizadas técnicas com o propósito de despertar a criatividade. Isto 
pode ser feito utilizando sessões de cocriação, como o brainstorming ou o 
design thinking.
Há ainda os momentos em que os requisitos são obtidos a partir de do-
cumentações como editais de licitação (no caso de contratação advinda do 
setor público), de normas e leis (no caso de sistemas que precisam atender a 
legislações específicas e órgãos regulamentadores), de documentação de outros 
sistemas anteriores e, até mesmo, no pior caso, do próprio código-fonte anterior.
O importante nas atividades de elicitação de requisitos é que o analista 
de requisitos seja capaz de compreender o contexto emque o projeto está 
inserido e que possa planejar de que forma irá realizar sua atividade de elicitar 
os requisitos. Pode ser empregando uma única técnica, pode ser empregando 
uma combinação de técnicas. 
O papel do analista de requisitos é mergulhar no ambiente de negócio. O usuário 
não precisa de um software, ele precisa do serviço que o software presta, precisa de 
algo que resolva o seu problema de negócio. O mais importante é que o analista de 
requisitos tenha feito todos os esforços para engajar os stakeholders e fazer emergir 
os requisitos que farão do projeto um sucesso.
Fundamentos da engenharia de requisitos14
Análise de requisitos
A análise de requisitos é a etapa na qual nos concentramos em aprofundar o 
entendimento acerca dos requisitos, buscando possíveis conflitos que podem 
ser advindos das diferentes visões que os stakeholders possam ter sobre o 
requisito e sua prioridade no projeto de desenvolvimento. Entretanto, os pro-
blemas podem vir também de requisitos conflitantes entre si, especialmente 
no que se refere a requisitos de qualidade, também chamados de requisitos 
não funcionais. A complexidade de um requisito funcional, por exemplo, pode 
ser incompatível com a necessidade de desempenho exigida. 
Faz parte da análise a decomposição de requisitos de alto nível em níveis 
apropriados de detalhe. Muitas vezes o requisito está expresso como um 
objetivo de negócio de alto nível e isso não é suficiente para as próximas 
etapas do desenvolvimento de software, sendo necessário decompô-lo em 
níveis mais detalhados.
Outro aspecto importante da análise dos requisitos diz respeito à defini-
ção dos atributos a ele associados, como o tipo do requisito, a volatilidade, 
o impacto sobre a arquitetura e o risco. Se um requisito, por exemplo, é volátil, 
ou seja, está mais sujeito a mudanças do que outros, pode ser que se decida 
por implementá-lo posteriormente, quando o seu entendimento esteja mais 
estabilizado. Da mesma forma, requisitos que tenham um grande impacto sobre 
a arquitetura da aplicação devem ser tratados com um cuidado redobrado, pois 
podem implicar em consequências para todos os demais requisitos, incluindo 
os requisitos de qualidade, como o desempenho da aplicação.
É 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. Sistemas complexos, envolvendo, por exemplo hardware 
e software, como sistemas de software para a direção autônoma de veículos, 
precisam de uma etapa de análise de requisitos mais aprofundada, que pode 
até mesmo se confundir com o design e com as especificações arquiteturais 
do produto (o que envolve o sistema como um todo). Nos exemplos que vimos 
no início deste capítulo, pudemos observar como alguns requisitos técnicos 
podem levar sondas espaciais a se desintegrarem em pleno ar e aeronaves a 
serem retiradas de circulação após desastres aéreos provenientes do software. 
Em ambos os casos, com extensivos prejuízos materiais, mas, principalmente, 
com a perda de vidas humanas.
15Fundamentos da engenharia de requisitos
Especificação de requisitos
A especificação de requisitos é a etapa dedicada a representar os requisitos de 
uma forma que eles possam perdurar ao longo do tempo e possam ser verifi-
cados e validados posteriormente. Isso pode implicar em formatos diferentes 
de especificação que envolvem textos, diagramas e tabelas. Aqui cabe uma 
pequena discussão acerca do que é exatamente representar os requisitos e de 
que forma deveríamos realizar essa atividade. 
Os métodos tradicionais de desenvolvimento, especialmente o cascata, 
com ciclos extensivos e exaustivos de especificação antes da codificação, 
já se mostraram ineficientes no passado e foram, gradualmente, substituídos. 
Há alguns anos que os métodos ágeis estão sendo mais amplamente adotados 
pela indústria, e muitos entendem que usar um método ágil significa não 
realizar qualquer tipo de “documentação”. A palavra aqui vem entre aspas para 
denotar que o termo é de uso pejorativo no ambiente ágil, estando relacionado 
a uma ação que agrega pouco ou nenhum valor ao produto final. Agilistas 
mais radicais defendem que a única documentação fiel de um produto é o seu 
código. São dois extremos que, em geral, se antagonizam.
Vamos refletir por um instante: imagine que você estivesse no hospital 
e sua vida dependesse da precisão de um equipamento cirúrgico, operado, 
em grande parte, por um software. Será que você iria preferir que os projetistas 
tivessem documentado adequadamente os requisitos técnicos, para garantir 
que os envolvidos nas fases seguintes desenvolvessem o produto de forma 
precisa? Ou você estaria confortável em ter apenas uma história de usuário 
de alto nível como documentação desses requisitos? 
A questão aqui é quanto de especificação é necessário antes de se dar início 
à implementação? A resposta é depende. Depende da complexidade do produto 
que está sendo desenvolvido, da criticidade de cada requisito, dos riscos de 
se ter um erro advindo de uma má compreensão, da experiência da equipe 
envolvida e até mesmo da fase em que o produto e a empresa se encontram.
É comum que empresas disruptivas de tecnologia, como as startups, iniciem 
suas atividades a partir de versões iniciais e pouco elaboradas do produto, 
o chamado MVP (em inglês, minimum viable product, isto é, produto mínimo 
viável). Nessa fase de sua existência, a empresa não se preocupa em especificar 
detalhadamente, pois seu foco é testar a viabilidade do negócio. Nesse momento 
a equipe é pequena, composta de duas a três pessoas, e a comunicação é direta 
e simples. No entanto, à medida que essa startup cresce e se torna uma grande 
empresa, não é mais possível continuar a desenvolver sem a preocupação 
com a especificação, pois a equipe também aumenta e a comunicação entre 
Fundamentos da engenharia de requisitos16
os membros se torna mais complexa. Um erro no ambiente de produção pode 
afetar milhares de pessoas.
É preciso especificar os requisitos na medida certa para a situação. Nunca teremos 
os requisitos de forma perfeita. Precisamos ter os requisitos na forma necessária e 
suficiente para os objetivos do projeto e para prosseguir com as demais etapas do 
desenvolvimento, sejam elas denominadas de fases, sejam de etapas, iterações, estágios 
ou sprints.
Validação de requisitos
A especificação dos requisitos precisa ser validada entre os stakeholders e 
a equipe de desenvolvimento para garantir que existe uma compreensão correta 
e comum sobre os requisitos e que a equipe de desenvolvimento possui as 
condições de implementar um produto que irá satisfazer as necessidades do 
negócio (WIEGERS; BEATTY, 2013).
A validação pode ser realizada por meio de uma revisão sobre as espe-
cificações, que é feita por revisores designados para tal, com o apoio de um 
checklist, por exemplo. Há casos em que se conduzem workshops de validação, 
nos quais os diversos tipos de stakeholders são envolvidos.
Podem ainda ser usados protótipos funcionais que visam a confirmar os 
requisitos e até mesmo a apoiar a elicitação de novos requisitos. Nesse caso, 
é importante destacar a finalidade dessa validação. Existe o risco do processo 
de validação de um protótipo se resumir a analisar requisitos da interface com 
o usuário. Isso não será um problema se a interface com o usuário for um 
ponto crítico e que precise de muita atenção. Entretanto, não se pode perder 
de vista a validação das regras de negócio e dos demais tipos de requisitos, 
como os requisitos de qualidade.
Especificar um conjunto de casos de teste que possam ser utilizados para 
testar o produto também faz parte desta etapa. Esses casos de teste podem 
ser documentos ou casos automatizados, dependendo do nível de maturidade 
da organização. Testes podem ser utilizados posteriormente para verificar se 
o produto final cumpre o que estava na especificação (verificação) ou para 
validar se oproduto faz aquilo que deveria fazer (validação).
17Fundamentos da engenharia de requisitos
Gerenciamento de requisitos
Permeando todo o ciclo dos requisitos, encontram-se as atividades relacionadas 
à fase de gerenciamento dos requisitos, que trata do estabelecimento de formas 
de rastrear os requisitos e facilitar a análise do impacto de uma solicitação de 
mudança para a tomada de decisão. 
Pesquisa do PMI (Project Management Institute) aponta problemas no 
gerenciamento de requisitos (LARSON, 2014):
 � Somente 49% das organizações têm recursos alocados adequadamente 
para o gerenciamento de requisitos.
 � Somente 33% dos líderes das organizações valorizam o gerenciamento 
de requisitos como uma competência crítica.
 � Somente 47% das organizações têm um processo formal de validação 
de requisitos.
 � Dos recursos financeiros gastos em projetos e programas, 51% são 
desperdiçados devido ao gerenciamento de requisitos ineficiente.
 � Dos objetivos não atendidos de projetos, 47% foram devido ao geren-
ciamento de requisitos ineficiente.
Para que os impactos de uma solicitação de mudança possam ser analisados 
de forma precisa, é necessário que se tenha conhecimento da fonte do requisito, 
de como os requisitos se relacionam entre si e de como eles se relacionam com 
os artefatos seguintes, como o código, por exemplo. Essa análise permite que 
tenhamos uma estimativa dos recursos e do tempo necessários para realizar 
a mudança solicitada, bem como para identificar quais artefatos precisam 
ser alterados. Isso permite que seja tomada uma decisão embasada sobre a 
solicitação de mudança.
Manter essa rastreabilidade entre os elementos não é uma atividade sim-
ples, especialmente em grandes produtos. Esta é uma atividade que permeia 
todo o ciclo de vida do produto e nasce quando os primeiros requisitos são 
identificados e especificados. Não é viável construir matrizes que precisem 
ser mantidas de forma manual, usando planilhas ou outro tipo de tabela; isso 
só é possível por meio de ferramentas automatizadas. Pior que não ter uma 
matriz de rastreabilidade é ter uma matriz desatualizada.
Fundamentos da engenharia de requisitos18
BOEING 737 Max Lion Air crash caused by series of failures. BBC, Estados Unidos, 1990. 
Disponível em: https://www.bbc.com/news/business-50177788. Acesso em: 30 dez. 
2019.
BOURQUE, P.; FAIRLEY, R. (ed.). SWEBOK: guide to the software engineering body of 
knowledge version 3. Washington: IEEE Computer Society, 2014.
BROOKS, F. No silver bullet: essence and accidents of software engineering. Computer, 
v. 20, n. 4, p. 10–19, 1987.
CALLEAM CONSULTING. Denver airport baggage handling system case study. [S. l.], 2008. 
Disponível em: http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.
pdf. Acesso em: 30 dez. 2019.
HINKEL, J. N. Ariane 5: um erro numérico (overflow) levou à falha no primeiro lançamento. 
São José dos Campos, [201-?]. Disponível em: https://www.ime.uerj.br/~demoura/
Especializ/Ariane/. Acesso em: 30 dez. 2019.
IEEE. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. 
Los Alamitos: IEEE Computer Society Press, 1990.
ISBELL, D.; SAVAGE, D. Mars climate orbiter failure board releases report, numerous NASA 
actions underway in response. In: MARS POLAR LANDDER. Washington, 1999. Disponível 
em: https://mars.jpl.nasa.gov/msp98/news/mco991110.html. Acesso em: 30 dez. 2019.
LARSON, E. I still don”t have time to manage requirements: my project is later than ever. 
In: PMI® GLOBAL CONGRESS, 2014, Phoenix, AZ. Proceedings… Newtown Square, PA: 
Project Management Institute, 2014. Disponível em: https://www.pmi.org/learning/
library/poor-requirements-management-source-failed-projects-9341. Acesso em: 
30 dez. 2019.
MUNIZ, A. et al. Jornada DevOps: unindo cultura ágil, Lean e tecnologia para entrega 
de software de qualidade. Rio de Janeiro: Brasport, 2019. 
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM: um guia definitivo para o SCRUM: 
as regras do jogo. [S. l.], 2018. Disponível em: https://www.scrumguides.org/index.
html. Acesso em: 30 dez. 2019.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
19Fundamentos da engenharia de requisitos
DICA DO PROFESSOR
O Analista de Requisitos é o profissional responsável pelas atividades relacionadas à elicitação, 
análise, especificação, validação e gerenciamento de requisitos de projetos que envolvem 
software. Sua importância é estratégica para o sucesso do projeto, pois ele é o elo que une o 
contexto do negócio à equipe de tecnologia da informação.
Diversas são as habilidades técnicas e pessoais necessárias ao desempenho dessas atividades. 
Assista à Dica do Professor a seguir e conheça um pouco mais sobre o papel do Analista de 
Requisitos no ciclo de desenvolvimento de software.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) Um software de contabilidade foi desenvolvido e implantado em diversas empresas da 
cidade de São Paulo. Como o negócio estava prosperando, o produto estava 
estabilizado e os clientes estavam satisfeitos, a empresa decidiu abrir a venda para 
outros estados. No primeiro dia de operação do software na cidade de Blumenau, o 
cliente ligou furioso avisando que: “este software não funciona! Os impostos estão 
sendo calculados de forma incorreta!”
Esse é um problema que ocorre com frequência e sua causa raiz pode ser atribuída a 
quê?
A) O Desenvolvedor não codificou corretamente a fórmula para calcular os impostos.
B) O Projetista de Interface não previu um campo para a alíquota correta do imposto na 
interface do usuário. 
O Analista de Testes não testou adequadamente o produto, deixando passar o erro no 
cálculo do imposto para a cidade de Blumenau. 
C) 
 
D) O Analista de Integração deixou passar a integração de um componente implementado de 
forma incorreta. 
E) O Analista de Requisitos não analisou corretamente o impacto da mudança de contexto. 
2) Como você sabe, a Engenharia de Requisitos é composta por diversas etapas, entre 
elas a Especificação de Requisitos.
Com relação a essa etapa, é correto afirmar que:
A) os requisitos são sempre especificados de forma detalhada, pois serão a base para realizar 
o planejamento do projeto.
B) o foco é apenas nos requisitos funcionais do projeto, de modo que se possa ter o escopo 
rapidamente definido antes que o programador comece a codificar.
C) não deve haver nenhum tipo de documentação, pois isso sempre atrasa o início da 
programação, que é a etapa onde o produto é realmente produzido.
D) devem ser especificados os requisitos em nível de detalhe compatível com as necessidades 
do projeto, o que pode variar de acordo com o contexto.
E) os requisitos de qualidade não são considerados ainda, pois eles só vão ser tratados na 
etapa de testes de qualidade.
3) Para que o impacto de uma Solicitação de Mudança possa ser analisado 
adequadamente, é importante que o Analista de Requisitos disponha da matriz de 
rastreabilidade.
Sobre esse artefato, é correto afirmar que:
A) a matriz de rastreabilidade documenta os relacionamentos entre os diversos tipos de 
requisitos e entre os requisitos e outros elementos do produto de software.
B) a matriz de rastreabilidade deve ser construída manualmente no formato de uma planilha.
 
C) a matriz de rastreabilidade precisa apenas relacionar os requisitos com as suas fontes de 
informação, de modo que se possa identificar rapidamente quem pediu o requisito.
D) a matriz de rastreabilidade é uma ferramenta criada na etapa de Gerenciamento de 
Requisitos.
E) a matriz de rastreabilidade é uma planilha que deve ser criada quando os desenvolvedores 
terminaram a codificação, de modo a relacionar os requisitos e os códigos implementados.
4) Jones é um Desenvolvedor que acaba de ser promovido a Analista de Requisitos.Sua 
primeira atividade na nova função é realizar as atividades de requisitos para o novo 
sistema de avaliação de desempenho dos funcionários da empresa. A equipe usa 
métodos ágeis de desenvolvimento. As regras para a avaliação ainda não estão 
definidas, mas há diversos aspectos legais que devem ser levados em consideração. 
Você é Analista de Requisitos há mais tempo e Jones pede a sua ajuda para 
identificar por onde ele deveria começar. O que você recomendaria para Jones.
I. Como a empresa utiliza métodos ágeis, você recomenda que Jones converse com a 
equipe de desenvolvimento e já comece a implementação das primeiras 
funcionalidades.
II. Como o sistema possui aspectos legais a serem considerados, você recomenda que 
Jones inicie identificando as fontes de informação e as técnicas que ele poderá aplicar 
para elicitar os requisitos.
III. Como a empresa trabalha em um ambiente mais descontraído, utilizando 
métodos ágeis, você recomenda que ele aplique a técnica de brainstorming.
A) As alternativas I, II e III estão corretas. 
 
B) Apenas as alternativas I e II estão corretas.
 
C) Apenas as alternativas I e III estão corretas. 
D) Apenas as alternativas II e III estão corretas. 
E) A única alternativa correta é a II. 
5) Como você sabe, a Engenharia de Requisitos possui diversas etapas. Entre elas, a 
Validação de Requisitos.
Sobre essa etapa, é correto afirmar que:
A) ela é realizada pelo cliente apenas ao final do projeto, quando o produto final está 
entregue.
B) ela é realizada pelo próprio Analista de Requisitos, quando termina sua atividade de 
Especificação de Requisitos.
 
C) ela é realizada pelo cliente ao final da Especificação de Requisitos, para validar que a 
equipe técnica entendeu o que foi solicitado.
D) ela é realizada pelo testador da equipe de desenvolvimento, quando os programadores 
terminaram a programação.
E) ela é realizada pelo gerente do projeto, para validar que o trabalho do Analista de 
Requisitos foi realizado com sucesso.
NA PRÁTICA
O Analista de Requisitos é o profissional responsável pelas atividades relacionadas à Engenharia 
de Requisitos, que vão desde a elicitação dos requisitos até a sua validação. Seu papel é muito 
importante para os projetos de software, uma vez que erros provenientes dessa etapa podem se 
propagar para as demais etapas do desenvolvimento com consequências que podem ser 
desastrosas para o projeto e para o produto final.
Judy é uma Analista de Requisitos que tem um novo projeto pela frente. Nesse Na Prática, você 
irá acompanhar os desafios de Judy e como ela organizou o seu trabalho desde o início para 
concluí-lo com sucesso.
Conteúdo interativo disponível na plataforma de ensino!
 
 
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Um dia feito de vidro (em inglês)
A Day Made of Glass é um vídeo que mostra a tecnologia presente em todos os momentos do 
cotidiano, desde o instante em que duas crianças despertam para a ir à escola, até o momento em 
que retornam para casa, compartilhando suas experiências do dia. Paralelamente, o pai, após 
deixar as meninas na escola, utiliza a tecnologia como apoio para o seu trabalho como médico. 
Procure refletir como é o seu dia a dia e como seria se, de uma hora para outra, toda a tecnologia 
que você utiliza ficasse indisponível. O vídeo está em inglês, mas as imagens falam por si só!
Conteúdo interativo disponível na plataforma de ensino!
Testando a loja Amazon Go em São Francisco, Califórnia
Neste vídeo, o autor mostra como funciona a loja automatizada da Amazon Go, na qual basta 
pegar os produtos e sair da loja. Eles são automaticamente debitados do seu cartão de crédito. 
Procure refletir quais requisitos estão envolvidos nessa solução tecnológica.
Conteúdo interativo disponível na plataforma de ensino!
A natureza do software
Este material vai ajudar você a compreender e refletir sobre a natureza do software e suas 
particularidades. O capítulo inicia com um diálogo entre um dos autores e um desenvolvedor de 
jogos digitais. Em seguida, explica os diferentes tipos de software e suas implicações.
Gerenciamento de Requisitos
Neste vídeo, o autor Fabrício Laguna explica, em cerca de 5 minutos, a importância dos 
requisitos e ressalta o papel fundamental do gerenciamento de requisitos com um exemplo 
simples do dia a dia.
Conteúdo interativo disponível na plataforma de ensino!
Requisitos de software
APRESENTAÇÃO
A maior parte das atividades do dia a dia é apoiada por tecnologias que não existiam há pouco 
tempo ou que eram muito caras e inacessíveis. O poder de processamento de um celular é maior 
que o poder dos computadores da NASA na década de 60. Vive-se em um mundo onde o 
software desempenha um papel fundamental.
Para que os softwares sejam úteis, executem as funções da forma como se deve, a primeira etapa 
é saber qual é o seu objetivo e que atividades o software deverá apoiar, ou seja, quais são os 
seus requisitos, que funções ele deve ter, com quem e como ele deve interagir e como deve se 
comportar em cada situação.
Requisitos bem definidos são fundamentais para um produto de qualidade. São a base para o 
planejamento do projeto de software e para todas as demais atividades técnicas do 
desenvolvimento. Requisitos mal compreendidos e mal definidos levam, no mínimo, ao 
retrabalho e ao aumento de custos de produção. Mas, geralmente, as consequências são bem 
maiores, como a frustração dos clientes, o desgaste da imagem da empresa e até mesmo a perda 
de vidas, como no caso de softwares de missão crítica.
Nesta Unidade de Aprendizagem, você aprenderá sobre os diferentes tipos de classificação de 
requisitos e quais os seus desdobramentos. Aprenderá como aplicar critérios de qualidade para 
analisar se os seus requisitos estão descritos de forma adequada, de modo a servirem de base 
para as etapas seguintes do ciclo de desenvolvimento de software.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Classificar os requisitos de um projeto de software.•
Priorizar os requisitos em um projeto de software.•
Aplicar critérios de qualidade para avaliar a qualidade dos requisitos de software.•
DESAFIO
Os requisitos são a base para as demais etapas do desenvolvimento de software. Requisitos 
ambíguos e mal especificados podem ocasionar a compreensão incorreta dos seus objetivos e, 
portanto, ao retrabalho nas fases posteriores.
INFOGRÁFICO
Requisitos podem ser compreendidos como declarações que expressam uma necessidade ou 
uma restrição. No desenvolvimento de software, existem diversos tipos de requisitos com os 
quais a equipe de desenvolvimento precisa lidar. Esse processo tem início na compreensão do 
porquê o produto está sendo desenvolvido, ou seja, no entendimento dos requisitos de negócio. 
Com isso, iniciam os refinamentos, até que se consiga identificar exatamente o que a equipe de 
desenvolvimento precisa implementar.
Acompanhe o relacionamento entre os diversos níveis de requisitos neste Infográfico. Você 
poderá ver a relação entre os requisitos de mais alto nível, se são funcionais ou não funcionais.
CONTEÚDO DO LIVRO
Um dos pontos mais cruciais para o desenvolvimento de software com qualidade se refere as 
atividades relacionadas aos requisitos.Exigências mal compreendidas e mal especificadas são a 
causa de diversos problemas nos projetos de software, desde o não cumprimento de prazos e 
orçamentos, até a entrega de produtos que não atingem os objetivos inicialmente pretendidos. 
Milhares de dólares são desperdiçados no mundo em projetos que falham em entregar um 
produto que agregue efetivamente valor ao negócio.
No capítulo Requisitos de software, do livro Engenharia de requisitos, base teórica desta 
Unidade de Aprendizagem, você compreenderá de forma mais aprofundada os requisitos e como 
eles são categorizados. Conhecerá os critériospara um bom requisito e para um bom conjunto 
de requisitos, contribuindo para produtos de software cada vez melhores. Também aprenderá 
questões importantes na priorização dos requisitos.
Boa leitura.
ENGENHARIA DE 
REQUISITOS
Sheila Reinehr
Requisitos de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Classificar os requisitos de um projeto de software.
 � Priorizar os requisitos em um projeto de software.
 � Aplicar critérios de qualidade para avaliar a qualidade dos requisitos 
de software.
Introdução
Produtos de software fazem parte do nosso dia a dia em praticamente 
todas as atividades que realizamos, desde as mais simples até as mais 
sofisticadas. Empresas de todos os setores também dependem fortemente 
de produtos de software, que são utilizados tanto para a realização de 
atividades produtivas quanto para as de controle e gestão. Quando um 
software falha, seus transtornos são sentidos imediatamente e impactam 
na forma como as atividades cotidianas de empresas e indivíduos são 
realizadas.
Uma das etapas do ciclo de desenvolvimento de software que tem 
o maior potencial de causar danos futuros ao projeto e ao produto final 
em si é a engenharia de requisitos. Quando não compreendemos ade-
quadamente o que deve ser construído, falhamos para estimar prazos e 
recursos, gerando prejuízos financeiros para o projeto. Mais importante 
do que isso, uma falha na compreensão dos requisitos pode se propagar 
para o restante das atividades do desenvolvimento, gerando produtos 
que não satisfazem as necessidades e que podem, inclusive, gerar danos 
físicos ou levar à perda de vidas.
Sabemos, no entanto, que os recursos para o desenvolvimento não 
são infinitos e a velocidade do mercado exige que novos produtos ou 
funcionalidades sejam lançados cada vez mais rápido. Então como fazer 
para equilibrar o tempo disponível para o desenvolvimento com a quali-
dade exigida do produto final? O primeiro passo é garantir bons requisitos, 
de modo que a agilidade possa ser acompanhada de qualidade.
Neste capítulo você vai estudar os diferentes tipos de requisito e quais 
os desdobramentos dessas categorias. Verá também como os requisitos 
podem ser priorizados em função de suas características e das caracterís-
ticas do contexto. Por fim, vai ler sobre como aplicar critérios para analisar 
a qualidade dos requisitos, para que possam contribuir de forma efetiva 
para a qualidade das próximas etapas do desenvolvimento de software.
1 Tipos de requisitos de software
Inicialmente, precisamos definir o que é requisito. Inúmeras definições podem 
ser encontradas e optamos, neste livro, por aderir ao Glossário padrão de ter-
minologia de engenharia de software do Institute of Electrical and Electronic 
Engineers (IEEE, 1990) que define requisito como:
1. Uma condição ou capacidade necessária para um usuário resolver um 
problema ou alcançar um objetivo.
2. Uma condição ou capacidade que deve ser atendida ou tida por um 
sistema ou componente do sistema para satisfazer a um contrato, padrão, 
especificação ou outro documento formalmente imposto.
3. Uma representação documentada de uma condição ou capacidade con-
forme estabelecido em 1 e 2.
Ao olhar mais detidamente os termos envolvidos nessa definição, você 
percebe que os principais aspectos dos requisitos estão cobertos: foco no 
problema que a solução deve resolver; foco na satisfação a uma imposição 
(que pode, por exemplo, ser uma legislação); e, finalmente, foco na represen-
tação documentada. Note ainda que essa definição não direciona para um 
método específico de desenvolvimento, uma vez que não especifica “como”, 
mas sim “o quê”.
Outra forma de entender o que é requisito é se apoiar na definição de 
Sommerville e Sawyer (1997), que estabelecem que requisitos são a especifi-
cação do que precisa ser implementado, são descrições de como o sistema deve 
se comportar, ou são uma propriedade ou atributo do sistema. Os requisitos 
podem, por exemplo, ser uma restrição no processo de desenvolvimento do 
sistema. Aqui temos o conceito de requisito do processo, que será tratado 
posteriormente neste capítulo.
Requisitos de software2
O termo requisito tem diversas interpretações diferentes na engenharia de 
software. Cada autor apresenta uma forma diferente de classificar os requisitos. Pohl 
e Rupp (2015) classificam os requisitos de acordo com as definições do Quadro 1.
Fonte: Adaptado de Pohl e Rupp (2015).
Tipo do requisito Definição
Requisito funcional É um requisito que se refere a um resultado de 
comportamento que deve ser provido por uma 
funcionalidade do sistema.
Requisito de 
qualidade
É um requisito que pertence a uma preocupação com a 
qualidade que não é coberta pelos requisitos funcionais.
Restrição É um requisito que limita o espaço da solução além do 
que é necessário para atender aos requisitos funcionais e 
requisitos de qualidade.
Quadro 1. Tipos de requisitos de acordo com Pohl e Rupp (2015)
Um requisito funcional é, como o próprio nome diz, uma funcionalidade 
requerida pelos stakeholders para cumprir algum objetivo de negócio. Repre-
senta o que os desenvolvedores deverão implementar para que os usuários 
possam realizar as suas atividades. Geralmente, os requisitos funcionais são 
expressos em frases do tipo “o sistema deve”. Por exemplo: “O sistema deve 
permitir que o usuário pague com cartão de débito ou crédito”. 
Os requisitos de qualidade se referem a como o software vai operar sob 
determinadas circunstâncias e, geralmente, estão relacionados a questões como 
desempenho, disponibilidade, usabilidade, portabilidade, escalabilidade etc. 
Eles também são chamados de requisitos não funcionais.
É comum que os requisitos não funcionais sejam negligenciados no início 
do projeto — e aí reside um grande problema, pois eles, geralmente, têm forte 
impacto sobre a arquitetura da aplicação, e são os requisitos mais difíceis 
de se retificar posteriormente. Para conseguirmos atender a um requisito 
específico de desempenho, por exemplo, é necessário fazer escolhas arquite-
turais que darão suporte a esse requisito. Se isso não for planejado em tempo 
de projeto (design), será muito difícil corrigir depois que a implementação 
estiver avançada.
3Requisitos de software
As restrições são consideradas como os requisitos sobre os quais a equipe 
de desenvolvimento não tem gestão. Eles não são implementados no produto 
de software, mas influenciam a forma como o produto será implementado. 
Geralmente, relacionam-se com as escolhas sobre tecnologias (hardware, 
ambientes, linguagens de programação etc.) e processos de desenvolvimento 
(ciclo de vida, métodos, procedimentos de gestão etc.), além de restrições do 
próprio projeto que gera o produto (prazos, custos, recursos etc.). As restrições 
são também comumente chamadas de requisitos de processo e requisitos 
de projeto.
Wiegers e Beatty (2013) utilizam uma visão um pouco diferente, incluindo, 
além dos tipos em si, o nível de abstração dos requisitos, conforme você pode 
ver no Quadro 2.
Termo Definição
Requisito de 
negócio
Um objetivo de alto nível de negócio da organização que 
constrói um produto ou de um cliente que o adquire.
Regra de 
negócio
Uma política, um guia, um padrão, uma regulamentação 
que define ou restringe algum aspecto de negócio. 
Não é um requisito do software em si, mas a origem 
de diversos tipos de requisitos de software.
Restrição Uma restrição que é imposta sobre as escolhas 
disponíveis para o desenvolvedor para o projeto 
(design) e construção de um produto.
Requisito 
de interface 
externa
Uma descrição de uma conexão entre um 
sistema de software e um usuário, outro sistema 
de software ou um dispositivo de hardware.
Característica 
(feature)
Uma ou mais capacidades do sistema logicamente 
relacionadas que fornecem valor para um usuário e são 
descritas por um conjunto de requisitos funcionais.
Requisito 
funcional
Uma descrição de um comportamentoque o 
sistema deve exibir sob condições específicas.
Requisito não 
funcional
Uma descrição de uma propriedade ou característica que o 
sistema deve exibir ou uma restrição que ele deve respeitar.
Quadro 2. Tipos de requisitos de acordo com Wiegers e Beatty (2013)
(Continua)
Requisitos de software4
Fonte: Adaptado de Wiegers e Beatty (2013).
Termo Definição
Atributo de 
qualidade
Um tipo de requisito não funcional que descreve um 
serviço ou característica de desempenho de um produto.
Requisito de 
sistema
Um requisito de alto nível para um produto que 
contém múltiplos subsistemas, que pode ser 
todo de software ou de software e hardware.
Requisito 
de usuário
Um objetivo ou tarefa que classes específicas de 
usuários devem ser capazes de executar com um 
sistema ou um atributo de produto desejado.
Quadro 2. Tipos de requisitos de acordo com Wiegers e Beatty (2013)
(Continuação)
De acordo com a visão de Wiegers e Beatty (2013), os requisitos de negó-
cio estão mais diretamente ligados aos motivos pelos quais um software está 
sendo desenvolvido, ou seja, quais são os objetivos de negócio que se deseja 
atingir e qual o valor que esse produto agregará ao negócio. Geralmente, são 
providos pelo patrocinador, executivos da organização ou pelo pessoal de 
produto (gerência de marketing, por exemplo). Os requisitos de negócio são 
como grandes objetivos que todos precisam estar de acordo, pois serão a base 
da maioria das decisões futuras sobre o projeto e até mesmo a priorização das 
entregas. Com base nos requisitos de negócio também serão avaliadas as soli-
citações de mudanças que certamente surgirão ao longo do desenvolvimento.
Embora pareça bastante óbvio que um projeto deva ser iniciado de forma 
alinhada aos objetivos de negócio, nem sempre isso acontece, pois, muitas 
vezes, a visão sobre esse relacionamento não é muito clara. Como consequência, 
a equipe técnica pode ter que lidar com visões conflitantes entre os diversos 
stakeholders, o que pode ter impacto nas atividades de desenvolvimento e no 
resultado final. Outro efeito colateral possível é que a equipe tente abranger as 
visões de todos os possíveis stakeholders, deixando de focar naqueles que são 
mais relevantes, levando o produto a abranger um escopo muito maior do que 
o inicialmente previsto. Discutiremos mais esse tópico nas próximas seções.
5Requisitos de software
Exemplos de benefícios quantificáveis financeiramente sob a ótica do negócio:
 � incrementar as vendas em 25% em 6 meses;
 � aumentar a quantidade de engajamentos na página da marca em 15% nos pró-
ximos 3 meses;
 � reduzir os gastos com vendedores presenciais em 40% até o final do próximo ano.
Exemplos de benefícios não financeiros podem incluir:
 � aumentar o índice de satisfação dos clientes em 10% no próximo trimestre;
 � receber no máximo 10 chamados por mês no service desk após 3 meses da im-
plantação do produto.
Como se pode observar nos quadros anteriores, existem formas diferen-
tes de classificar os requisitos, mas, basicamente, podemos considerar que 
existem requisitos que são do produto de software em si, ou seja, que serão 
construídos pela equipe de desenvolvimento e farão parte do produto entregue; 
e existem requisitos que não são do produto, ou seja, fazem parte do projeto 
ou do processo. Os requisitos que são do produto, podem ser funcionais 
(o que o software deve fazer) ou não funcionais (como o software deve fazer). 
Os requisitos de projeto e de processo são sempre não funcionais. 
Outro conceito importante é o de requisito de sistema. Embora, na maio-
ria das empresas, o termo sistema seja usado para designar um produto de 
software, seu conceito é mais amplo do que isso. Entende-se por sistema, 
a composição de hardware, software e processos. Portanto, requisitos de sis-
tema são requisitos de mais alto nível, que devem ser atendidos pelo produto 
como um todo, e o requisito de software se refere ao requisito do sistema que é 
alocado ao componente de software. Isso se torna particularmente importante 
quando falamos de sistemas ciberfísicos (CPS, cyber-phisical systems), cuja 
composição envolve a parte física (ambiente, sensores, atuadores) e a parte 
ciber (software). Esse é o caso, por exemplo, das funcionalidades de park 
assist (estacionamento automático) nos automóveis de luxo. Um requisito 
de sistema poderia ser: “O sistema deve buscar uma vaga para estacionar o 
veículo”. Esse requisito do sistema envolve elementos físicos (sensores para 
detectar espaços vazios) e elementos de software (para identificar se o carro 
cabe naquele espaço).
Requisitos de software6
As normas da ISO oferecem um bom suporte para todos os processos relacionados 
a requisitos:
 � Para mais detalhes sobre processos relacionados a requisitos de sistema, uma 
boa dica é olhar a norma internacional ISO/IEC 15288:2015, Systems and Software 
Engineering — Systems Lyfe Cycle Processes. Nela é possível identificar o processo de 
definição de requisitos de sistema, que estabelece as atividades e os resultados 
esperados quando se executa o processo.
 � Para mais detalhes sobre processos relacionados aos requisitos de software, você 
pode usar a norma internacional ISO/IEC/IEEE 12207:2017, Systems and Software 
Engineering — Software Lyfe Cycle Processes. Procure pelos processos de definição de 
requisitos de sistema/software. Embora essa norma seja dedicada aos processos de 
software, ela trata os requisitos de forma mais ampla, incluindo requisitos de sistema.
 � Para mais detalhes sobre requisitos de forma mais ampla, consulte a norma interna-
cional ISO/IEC 29148:2018, Systems and Software Engineering — Lyfe Cycle Processes 
— Requirements Engineering. Ela inclui mais detalhes sobre como implementar os 
processos que estão descritos nas duas normas anteriores.
É importante compreendermos adequadamente esses diferentes tipos de 
requisitos, pois cada um deles será desdobrado em um artefato diferente do 
ciclo de vida. Os requisitos relacionados ao produto farão parte de um docu-
mento de especificação de requisitos (ou artefato similar, como cartões com 
histórias de usuário nos métodos ágeis), enquanto os requisitos de processo e de 
projeto serão parte do plano de projeto (ou artefato que tenha função similar). 
Já requisitos de sistema se desdobrarão em requisitos relacionados à parte física 
(hardware) e requisitos relacionados à parte de software, que podem estar em 
um mesmo artefato, mas que se desdobrarão em implementações distintas.
2 Priorização de requisitos
Uma das maiores causas de fracassos em projetos está relacionada ao seu 
tamanho. Quanto maior o projeto, maiores são as chances de ele não atingir 
suas metas de prazo, custo, escopo e qualidade. Uma forma de minimizar 
esses efeitos é dividi-lo em partes menores e mais facilmente gerenciáveis. 
Esse é o princípio que foi adotado pelos modelos de ciclo de vida iterativos 
e incrementais e, mais recentemente, pelas metodologias ágeis, que preveem 
a divisão de trabalho em sprints ou iterações, com durações curtas, de, 
7Requisitos de software
no máximo, um mês. Dessa forma, os requisitos podem ser conhecidos logo 
no início, mas eles serão detalhados à medida que forem sendo priorizados 
para a alocação em uma entrega.
A forma de priorizar os requisitos vai depender do contexto em que o 
projeto está inserido e das próprias características do produto e da tecnologia 
envolvida. Alguns dos fatores que podem ser usados na priorização envolvem, 
mas não estão restritos a:
 � Potencial de valor a ser agregado ao negócio pelo requisito: requi-
sitos que agregam mais valor ao negócio geralmente são alocados às 
primeiras entregas, enquanto requisitos de menor valor são alocados 
a versões posteriores.
 � Dependência do requisito em relação a outros requisitos: muitas vezes 
um requisito não pode ser implementado isoladamente, requerendo que 
sejam priorizados outros requisitos que dão suporte a ele, na mesma 
versão do produto.
 � Análise de requisitosimplícitos que podem estar invisíveis: no mo-
mento da priorização de requisitos, pode ser que requisitos implícitos 
que estavam invisíveis em um primeiro momento sejam identificados 
e precisem ser priorizados juntamente com o requisito principal. Isso 
é muito comum, por exemplo, nos requisitos de segurança de acesso, 
que podem implicar em uma série de requisitos de apoio (que podem 
até mesmo virar um subsistema).
 � Experiência com a tecnologia por parte da equipe do projeto: a falta 
de experiência da equipe de desenvolvimento com a tecnologia pode 
levar à priorização de requisitos que não sejam exatamente os que geram 
mais valor ao cliente, mas sim aqueles que possibilitam o aprendizado 
mais rápido e com menor risco para o projeto como um todo. 
 � Experiência no domínio de aplicação por parte da equipe: analoga-
mente ao anterior, a falta de experiência da equipe com o domínio de 
aplicação requer cuidados redobrados na priorização, especialmente, 
quando houver o risco de a equipe subestimar a complexidade de um 
requisito em função de sua falta de experiência com o domínio de 
negócio. Nesses casos, a proximidade com o usuário, cliente ou seus 
representantes é fundamental.
 � Relacionamentos com outros sistemas (hardware ou software): quando 
o software implicar em relacionamentos com outros softwares ou com 
hardware, na forma de um sistema, é necessário que as dependências 
Requisitos de software8
entre os requisitos sejam claramente explicitadas, de modo que o de-
senvolvimento de requisitos dependentes possa ser realizado de forma 
síncrona e não isolada.
 � Demandas de implementações para atender a determinações de 
ordem legal ou regulatória: é comum que demandas de ordem legal 
ou que sejam demandadas por órgãos regulamentadores tenham datas 
específicas para entrar em vigor. Requisitos que implementam essas 
necessidades precisam ser priorizados em versões compatíveis com as 
datas demandadas.
 � Requisitos que não possuem alternativas manuais aceitáveis: 
há casos em que o procedimento manual para a realização da atividade 
de negócio é oneroso e sujeito a falhas. Nesses casos, requisitos que 
substituem esses processos são priorizados em detrimento de outros, 
cujos procedimentos manuais sejam menos onerosos ou representem 
menos riscos ao negócio.
A priorização pode ser feita por um único representante do usuário, como 
um product owner (PO) do método Scrum, ou por um grupo de stakeholders. 
Isso pode acontecer virtualmente, usando ferramentas de colaboração, ou em 
workshops de priorização presenciais. A forma vai depender da quantidade 
de stakeholders envolvidos e do nível de conflito que possa haver entre os 
requisitos de produto a serem priorizados e as restrições do projeto/processo. 
Quanto mais críticos forem esses conflitos, maior a necessidade de se utilizar 
procedimentos colaborativos de decisão.
3 Critérios de qualidade de um bom requisito
Não importa o modelo de ciclo de vida ou o processo de desenvolvimento 
utilizado, um requisito mal compreendido e mal documentado será sempre 
um problema para o projeto que envolve software. Por esse motivo, é im-
prescindível que os requisitos, independentemente de sua categoria, estejam 
claramente identificados, de modo que as atividades que dependem deles 
possam ser realizadas com sucesso. Como podemos estimar adequadamente 
o esforço para a implementação de um requisito se sua descrição está ambígua 
e imprecisa? Como evitar o retrabalho no desenvolvimento se o requisito não 
foi detalhado de forma suficiente? Como prever os testes necessários se não 
houver detalhes para isso?
9Requisitos de software
Primeiramente, é importante não confundir um requisito bem especificado 
com uma etapa de requisitos infinita, que se perde nos mínimos detalhes e que 
não avança na entrega de valor para o cliente. Aqui é ressaltada a importância de 
termos o requisito especificado de forma clara e em nível de detalhe compatível 
com o contexto. Por contexto entendemos as variáveis que podem afetar essa 
decisão, como experiência da equipe de desenvolvimento com a tecnologia e 
com a área de negócio, criticidade do produto em desenvolvimento, impacto 
dos possíveis erros que possam ser derivados (software de missão crítica, 
por exemplo) e nível de envolvimento dos stakeholders.
É comum achar que, ao utilizar métodos ágeis, não é necessário gastar muito tempo 
com os requisitos, pois eles vão, invariavelmente, mudar. Na verdade, temos sim que 
dispender todo o esforço necessário para termos certeza de que compreendemos 
adequadamente cada demanda que vai para desenvolvimento, do contrário con-
tribuiremos, entre outras coisas, para o aumento da insatisfação do cliente com o 
produto entregue.
O que acontece em métodos ágeis como o Scrum é que o product backlog tem 
itens em níveis diferentes de maturidade. Os itens que já estão sendo priorizados 
para serem produzidos na próxima sprint devem estar maduros o suficiente para 
serem estimados, alocados à sprint e implementados. Haverá, por outro lado, itens 
menos maduros no product backlog, que serão detalhados no momento oportuno, 
conforme a sua prioridade.
De acordo com Schwaber e Sutherland (2018), itens de alta prioridade no product 
backlog costumam ser mais claros e detalhados do que itens de prioridade mais baixa. 
Estimativas mais precisas são feitas com base na maior clareza e no maior nível de 
detalhe; quanto menos prioritário, menos detalhado. Note que os criadores do Scrum 
ressaltam que os itens menos prioritários estarão menos detalhados, mas no momento 
em que se tornarem prioritários, terão que estar claros e detalhados. 
De acordo com a Norma Internacional ISO/IEC/IEEE 29148 (ISO/IEC/
IEEE, 2018), um requisito bem especificado contém um ou mais destes itens:
 � deve ser atendido ou tido por um sistema para resolver um problema, 
atingir um objetivo ou tratar de uma preocupação de um stakeholder;
 � é qualificado por condições mensuráveis;
Requisitos de software10
 � é limitado por restrições;
 � define o desempenho do sistema quando usado por um stakeholder 
específico ou é a capacidade correspondente de um sistema, mas não 
a capacidade de um usuário, operador ou outro stakeholder;
 � pode ser verificado (isto é, a realização de um requisito no sistema 
pode ser demonstrada).
Como documentar um requisito
Diversas são as formas de documentar um requisito, incluindo linguagem 
natural, tabelas, planilhas, diagramas, vídeos, áudios, fotos etc. Neste capí-
tulo, vamos nos concentrar na forma escrita, usando a linguagem natural. 
Ela pode ser utilizada tanto para os requisitos funcionais quanto para os não 
funcionais, sejam eles de produto, sejam de projeto ou processo. Serve também 
para especificar os requisitos ou objetivos de negócio, que vão nortear todo 
o desenvolvimento. As demais formas podem funcionar como um apoio ou 
complemento ao que está descrito em linguagem natural.
A primeira preocupação é que a linguagem natural apresenta ambiguidades 
que podem comprometer a precisão dos requisitos e a sua compreensão pelo 
público-alvo. Escrever requisitos não é como escrever qualquer outro tipo 
de texto, de ficção ou não. Não há uma forma de ensinar a escrever um bom 
requisito, pois isso vem com a experiência, mas, algumas dicas podem ajudar 
a começar:
 � Ótica da escrita: lembre-se que um requisito tem que ser visto sob 
a ótica de quem lê o documento, e não sob a ótica de quem escreve. 
Muitas vezes o requisito está completamente claro para quem escreveu, 
mas gera dúvidas para quem lê. Nesse caso, ele precisa ser revisado.
 � Tamanho das frases: frases longas dificultam a leitura e podem levar 
a interpretações incorretas. Dê preferência a frases curtas e diretas. 
Releia algumas vezes e elimine qualquer palavra que não agregue 
compreensão ao conteúdo.
 � Correção na escrita: os requisitos constituem um documento técnico 
e devem, portanto, seguir as normas da língua portuguesa escrita. Isso 
quer dizer que devem estarcorretos gramaticalmente e sem erros de 
digitação. Inclua aí uma preocupação extra com a pontuação (que pode 
modificar completamente o sentido da frase).
11Requisitos de software
 � Uso da voz ativa: dê preferência para frases usando a voz ativa (por 
exemplo, “o sistema deve prover uma função de cálculo do imposto”) 
em vez da voz passiva (por exemplo “uma função de cálculo do imposto 
deve ser provida”). Misturar voz passiva e ativa também torna o texto 
difícil de ler.
 � Uso da forma positiva: também é preferível usar a forma positiva e 
evitar a negativa do tipo “não deve”. Alguns chamam essa forma de 
requisito inverso, mas ela deve ser evitada. Frases com muitas negativas 
também geram complexidade no entendimento. Tudo o que precisamos 
ler duas vezes para entender não está bem escrito. 
 � Termos ambíguos: há termos que, naturalmente, levam a ambiguidades 
e indeterminações, e devem ser removidos de qualquer especificação 
de requisitos, como alguns, muitos, poucos, melhor, pior, robusto, 
adequado, rápido, amigável. Também há expressões que dificultam a 
precisão, como quando apropriado, quando possível, quando aplicável, 
se possível, se necessário.
 � Tempo verbal: o tempo verbal empregado pode trazer um signifi-
cado adicional implícito ao requisito, e isso nem sempre é desejável. 
Por exemplo: “o sistema deve” sugere que é um requisito obrigatório, 
mas o “sistema deveria” sugere uma interpretação de que o sistema 
poderia não fazer, implicando em um requisito menos prioritário. Ques-
tões de prioridade não devem ser tratadas pelo tempo verbal, mas sim 
por atributos de prioridade específicos, uma vez que podem mudar ao 
longo do tempo.
 � Acrônimos e jargões: acrônimos (siglas) e jargões também consti-
tuem um ponto frágil na especificação de requisitos. O recomendado é 
manter um glossário compartilhado entre todos os membros do projeto 
(internos e externos), de modo que não sejam usados termos de forma 
inconsistente. 
 � O que e não como: lembre-se de que, idealmente, os requisitos devem 
definir o que deve ser feito, e não como deve ser implementado. 
Requisitos de software12
As normas internacionais da ISO (International Organization for Standardization), no 
Brasil editadas pela ABNT (Associação Brasileira de Normas Técnicas), fazem uma clara 
distinção entre os itens que são escritos com o tempo verbal deve (shall) e com o tempo 
verbal deveria (should). As cláusulas de uma norma que possuem o verbo deve são 
obrigatórias e, no caso de normas certificadoras, serão requeridas pelo auditor como 
parte do processo de auditoria para concessão do certificado. Já as cláusulas que estão 
descritas com o verbo deveria não são exigidas, e a empresa pode opcionalmente 
não implementá-las (ISO/IEC/IEEE, 2018).
Uma forma para a escrita dos requisitos é fazê-la em três etapas: 
1. Escrever a primeira versão. 
2. Realizar a leitura crítica dessa versão se colocando no lugar do leitor.
3. Solicitar a revisão de um colega, a chamada revisão por pares.
Com o tempo, a escrita vai se tornando mais natural e os primeiros erros 
não serão mais cometidos, especialmente se eles, anteriormente, levaram a 
alguma consequência indesejada, como o retrabalho de implementação por 
ambiguidade nos requisitos. Leve a sério os feedbacks recebidos dos seus 
pares e elabore seu próprio checklist para autorrevisão dos requisitos — isso 
vai ajudá-lo a aprimorar essa habilidade ao longo do tempo.
Características de um bom requisito
Alguns critérios de qualidade que podem ser utilizados para nortear a escrita 
e a verificação dos requisitos estão listados a seguir, baseados nas recomen-
dações de Wiegers e Beatty (2013) e da Norma Internacional ISO/IEC/IEEE 
29148 (ISO/IEC/IEEE, 2018). Eles podem ser organizados no formato de um 
checklist, a ser aplicado para analisar cada requisito antes de sua liberação 
para a equipe de implementação, ou mesmo antes de liberá-los para a revisão 
por pares. O Quadro 3 apresenta as características de um bom requisito.
13Requisitos de software
Fonte: Adaptado de Wiegers e Beatty (2013) e ISO/IEC/IEEE (2018).
Atributo Definição
Completo O requisito está especificado de forma completa e possibilita 
que o desenvolvedor o implemente.
Correto O requisito reflete o que o usuário, cliente ou seus 
representantes desejam.
Único O requisito descreve uma única capacidade, característica, 
restrição ou atributo de qualidade.
Viável O requisito é viável técnica e financeiramente para ser 
implementado, de acordo com as restrições do projeto.
Necessário O requisito tem um motivo de existir, que é representado 
pelo seu relacionamento com uma fonte de informação e 
com um objetivo de negócio.
Priorizado O requisito tem uma prioridade atribuída para que possa ser 
alocado a uma versão do software.
Não ambíguo O requisito não contém ambiguidades que levem os 
stakeholders a interpretá-lo de forma diferente.
Verificável O requisito pode ser verificado posteriormente à sua 
implementação.
Conforme O requisito está em conformidade com os padrões de 
especificação estabelecidos, se houver.
Quadro 3. Características de um bom requisito
Características de um bom conjunto de requisitos
Como você pode observar no quadro anterior, cada requisito, individual-
mente, deveria atender às características listadas para ser considerado um 
bom requisito, apto a servir de base para as atividades seguintes do ciclo 
de desenvolvimento. Adicionalmente, existem características que precisam 
ser consideradas para o conjunto de requisitos de modo que a solução possa 
entregar o valor esperado pelos stakeholders, respeitando as suas restrições. 
Entende-se por solução não necessariamente o produto completo, mas uma 
versão entregue do produto.
Requisitos de software14
No Quadro 4, compilado a partir das definições de Wiegers e Beatty (2013) e 
da Norma Internacional ISO/IEC/IEEE 29148 (ISO/IEC/IEEE, 2018), podemos 
observar as características de um bom conjunto de requisitos. Diferentemente 
do quadro anterior, vemos que aqui aparecem atributos que são analisados 
para um ou mais requisitos. Por exemplo, analisar se o conjunto de requisitos 
está completo se refere a buscar pelos requisitos implícitos ou invisíveis, por 
exemplo. Pode ser que determinado requisito só possa ser implementado com 
a preparação de algum tipo de infraestrutura, como a existência de cadastros 
prévios, por exemplo. Muitas vezes, esses cadastros não são explicitamente 
identificados pelos stakeholders, por acharem que já estavam subentendidos.
Outro aspecto importante é a viabilidade de um requisito, quando anali-
sado em conjunto com os demais. Podemos ter, por exemplo, um requisito de 
desempenho (tempo de resposta) que seja incompatível com um requisito de 
processo (utilizar os equipamentos disponíveis atualmente).
Fonte: Adaptado de Wiegers e Beatty (2013) e ISO/IEC/IEEE (2018).
Atributo Definição
Completo O conjunto de requisitos está completo.
Consistente Os requisitos são consistentes entre si e com os requisitos de mais 
alto nível dos quais são originários, não apresentando conflitos.
Modificável Cada requisito tem uma identificação única que permite que ele 
seja modificado quando necessário.
Compre-
ensível
O conjunto de requisitos está escrito de forma que é possível 
identificar claramente o que é esperado do software no ambiente 
do qual ele faz parte.
Viável O conjunto de requisitos pode ser executado dentro das restri-
ções estabelecidas (técnicas, de custo e prazo), dentro de riscos 
aceitáveis.
Capaz 
de ser 
validado
O conjunto de requisitos pode ser validado quanto às necessi-
dades dos stakeholders dentro das restrições (como custo, prazo, 
técnica, conformidade com regulamentações e legislações).
Rastreável O conjunto de requisitos pode ser rastreado às suas origens 
(backward) e também aos demais elementos, como requisitos 
derivados, elementos de design, código e casos de teste (forward).
Quadro 4. Características de um bom conjunto de requisitos
15Requisitosde software
Nível de detalhamento dos requisitos
Uma pergunta difícil de responder é sobre quão detalhados devem ser os 
requisitos. Isso vai depender de alguns fatores relacionados ao produto de 
software em si e ao contexto em que ele está sendo desenvolvido, conforme 
você pode acompanhar a seguir (WIEGERS; BEATLY, 2013).
 � Mais detalhes:
 ■ o trabalho está sendo executado para um cliente externo;
 ■ o desenvolvimento e/ou o teste serão terceirizados;
 ■ os membros do projeto estão geograficamente dispersos;
 ■ os testes de sistema serão realizados com base nos requisitos;
 ■ estimativas precisas são necessárias;
 ■ a rastreabilidade entre os requisitos é necessária.
 � Menos detalhes:
 ■ o trabalho está sendo realizado internamente para a sua empresa;
 ■ os clientes estão bastante envolvidos;
 ■ os desenvolvedores possuem uma grande experiência no domínio;
 ■ existem precedentes, como no caso em que uma aplicação está sendo 
substituída;
 ■ um pacote de solução será utilizado.
Em resumo, se a equipe é experiente no domínio do negócio e os clientes 
estão próximos e acessíveis, o nível de detalhamento dos requisitos pode ser 
menor, pois os riscos envolvidos também serão menores. No entanto, quando 
a equipe não é tão experiente no domínio do negócio, os riscos são maiores e, 
portanto, um nível maior de detalhamento dos requisitos é necessário.
IEEE. IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. 
Los Alamitos: IEEE Computer Society Press, 1990.
ISO/IEC/IEEE. ISO/IEC/IEEE 12207:2017: systems and software engineering: software life 
cycle processes. Switzerland: ISO, 2017.
ISO/IEC/IEEE. ISO/IEC/IEEE 15288:2015: systems and software engineering: systems life 
cycle processes. Switzerland: ISO, 2015.
Requisitos de software16
ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018: systems and software engineering: life cycle 
processes: requirements engineering. Switzerland: ISO, 2018.
POHL, K.; RUPP, C. Requirements engineering fundamentals: a study guide for the certified 
professional for requirements engineering exam, foundation level, IREB Compliant. 
2. ed. Santa Barbara: Rock Nook, 2015. 
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM: um guia definitivo para o SCRUM: 
as regras do jogo. [S. l.], 2018. Disponível em: https://www.scrumguides.org/index.
html. Acesso em: 30 dez. 2019.
SOMMERVILLE, I.; SAWYER, P. Requirements engineering: a good practice guide. 
Chichester: John Wiley & Sons, 1997.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leituras recomendadas
BOURQUE, P.; FAIRLEY, R. (ed.). SWEBOK: guide to the software engineering body of 
knowledge version 3. Washington: IEEE Computer Society, 2014.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
WIEGERS, K. More about software requirements: thorny issues and practical advices. 
Redmond: Microsoft Press, 2006.
17Requisitos de software
DICA DO PROFESSOR
Os requisitos constituem uma parte crucial do desenvolvimento de um produto de software, pois 
é partir deles que todas as demais atividades são desdobradas. Requisitos incompletos, 
ambíguos, inconsistentes ou ausentes são a principal causa do retrabalho em projetos de 
software.
A declaração do requisito, escrita em linguagem natural, pode trazer ambiguidades, que levam à 
interpretação incorreta do requisito, o que pode gerar falhas na classificação e, principalmente, 
nas etapas posteriores do desenvolvimento, como a implementação e os testes.
Veja, nesta Dica do Professor, o que é a ambiguidade nos requisitos de software e como evitá-la.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
Frank é um analista de requisitos que acabou de coletar as definições com os stakeholders 
do projeto e está com dúvidas sobre a classificação correta:
1) 
Selecione a alternativa que representa as categorias dos requisitos:
A) Processo, processo, projeto, produto, produto, processo.
B) Projeto, processo, projeto, produto, produto, processo.
C) Processo, projeto, produto, produto, produto, processo.
D) Projeto, processo, processo, produto, produto, projeto.
E) Processo, projeto, processo, produto, produto, projeto.
Manuela é analista de requisitos de um projeto para desenvolvimento de um sistema de 
apoio para a venda de enfeites de Natal pela Internet. O seu cliente mandou a seguinte 
mensagem:
2) 
Com base no texto, ela extraiu os seguintes requisitos:
Sobre esses requisitos, é correto afirmar que:
A) O conjunto de requisitos listado está completo e correto, portanto, os requisitos podem 
seguir para a próxima fase do processo de desenvolvimento.
B) O conjunto de requisitos listado está completo, mas há alguns requisitos ambíguos, e por 
isso os requisitos não podem seguir para a próxima fase do processo de desenvolvimento.
C) o conjunto de requisitos listado não está completo e por isso não pode seguir para a 
próxima fase do processo de desenvolvimento
D) O conjunto de requisitos não está completo e os requisitos estão todos ambíguos, por isso 
não podem seguir para a próxima fase do processo de desenvolvimento.
E) O conjunto de requisitos listado não está completo, mas os requisitos corretos podem 
seguir para a próxima fase do processo de desenvolvimento.
3) Uma das principais medidas do sucesso de um software é o grau no qual ele atende 
aos objetivos e requisitos para os quais foi construído. De forma geral, a engenharia 
de requisitos de software é o processo de identificar todos os envolvidos, descobrir 
seus objetivos e necessidades e documentá-los de forma apropriada para análise, 
comunicação e posterior implementação. Com relação à engenharia de requisitos de 
software, analise as seguintes afirmativas:
I) As descrições das funções que um sistema deve incorporar e das restrições que 
devem ser satisfeitas constituem os requisitos para o sistema.
II) Requisitos funcionais descrevem restrições sobre as funções oferecidas, tais como 
restrições de tempo e de uso de recursos.
III) Os requisitos não funcionais apontam as funções que o sistema deve fornecer e 
como o sistema deve se comportar em determinadas situações.
A) As alternativas I, II e III estão corretas.
B) As alternativas I e III estão corretas.
C) As alternativas II e III estão corretas.
D) Apenas a alternativa I está correta. 
E) Apenas a alternativa II está correta. 
4) Analise os requisitos apresentados a seguir:
I) Todas as opções do sistema de vendas pela Web devem ser acessadas com no 
máximo 3 cliques do mouse.
II) O sistema de log de transações deverá listar todos os usuários logados 
simultaneamente nas aplicações SWIT e DERT.
III) O orçamento máximo a ser gasto para o desenvolvimento do sistema de controle 
estatístico de qualidade deverá ser de R$ 20.000,00.
IV) O relatório de bons clientes deverá apresentar todos os clientes com compras 
mensais superiores a R$ 5.000,00.
V) A atualização de 100 mil registros de vendas não deverá consumir mais do que 5 
segundos de CPU.
A) Os requisitos I e V são não funcionais; os requisitos II e IV são funcionais; o requisito III é 
de projeto.
B) Os requisitos I e V são funcionais; os requisitos II e IV são não funcionais; o requisito III é 
de projeto.
C) Os requisitos I e V são funcionais; os requisitos II e IV são nãofuncionais; o requisito III é 
de processo.
D) Os requisitos I e II são não funcionais; os requisitos III e IV são de projeto; o requisito V é 
funcional.
E) Os requisitos I, II, III, IV e V são funcionais.
5) Sobre as categorias de requisitos, avalie as três afirmações abaixo e selecione a 
alternativa correta:
I) A forma de gerenciamento que deve ser utilizada ao desenvolver um software faz 
referência a um requisito de processo.
II) Todos os requisitos de software da categoria produto são do tipo funcional, pois 
são funcionalidades implementadas.
III) Todos os requisitos de software da categoria projeto sãodo tipo funcional, pois 
são funcionalidades implementadas.
A) As alternativas I, II e III estão corretas.
B) Apenas a afirmativa I está correta.
C) Apenas a afirmativa III está correta.
D) Apenas as afirmativas II e III estão corretas.
E) Apenas as afirmativas I e III estão corretas.
NA PRÁTICA
A qualidade dos requisitos é um fator determinante para a qualidade do software que será 
produzido. Quanto mais tarde se descobrem problemas nos requisitos, mais caro é para 
consertar. Uma das formas de melhorar a qualidade dos requisitos é conduzir revisões por pares 
ou reuniões de inspeção formal.
Em ambos os casos, os requisitos produzidos por um analista de requisitos ou por uma equipe, 
são analisados por um ou mais pares, que são também analistas de requisitos, mas que não 
participaram da especificação. No caso da reunião de inspeção, podem ser envolvidos usuários, 
clientes ou representantes.
Neste Na Prática, você verá como se dá uma inspeção de requisitos em uma equipe.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Inside a warehouse where thousands of robots pack groceries (dentro de um armazém onde 
milhares de robôs empacotam mercadorias)
Este vídeo apresenta um armazém britânico totalmente automatizado, onde milhares de robôs 
processam mais de 65.000 pedidos de clientes por semana. Os robôs circulam por um grid 
automatizado, no qual alguns robôs pegam as mercadorias de dentro de compartimentos para 
montar o pedido do cliente, enquanto outros abastecem os produtos que vão acabando nos 
compartimentos.
Conteúdo interativo disponível na plataforma de ensino!
Diferenças entre requisitos e regras de negócio
Neste vídeo, o autor Fabrício Laguna explica, em cerca de 3 minutos, a diferença entre 
requisitos e regras de negócio.
Conteúdo interativo disponível na plataforma de ensino!
Entendendo os requisitos
Este material vai ajudar você a compreender os principais conceitos envolvidos em requisitos de 
software. Foque sua atenção nas páginas 131-148, do livro de Roger Pressman e Bruce Maxim, 
intitulado Engenharia de software – uma abordagem profissional.
Verificação de requisitos de software
APRESENTAÇÃO
Produtos de software fazem parte do cotidiano de todas as pessoas, seja em seu ambiente 
profissional, seja na sua vida particular. Todos estão tão acostumados com a tecnologia que, na 
maioria das vezes, nem se dão mais conta da sua presença. Só que essa presença maciça e cada 
vez mais integrada ao dia a dia impõe diversos desafios para a equipe de desenvolvimento, e um 
desses desafios diz respeito aos requisitos, que se tornam cada vez mais complexos, à medida 
que os sistemas também se tornam mais complexos.
Para assegurar que o produto entregue atenderá às expectativas dos usuários, as boas práticas da 
engenharia de requisitos precisam ser utilizadas. Não basta apenas usar a melhor técnica de 
elicitação de requisitos ou a melhor ferramenta de especificação; é necessário também aplicar as 
boas práticas de verificação e validação de requisitos.
Nesta Unidade de Aprendizagem, você aprenderá a reconhecer a importância da verificação de 
requisitos de software para o ciclo de desenvolvimento, utilizará checklists de verificação de 
requisitos funcionais e não funcionais e verá também como criar casos de teste para a 
verificação de requisitos funcionais e não funcionais.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Reconhecer a importância da verificação de requisitos de software.•
Aplicar checklists de verificação de requisitos funcionais e não funcionais de software.•
Criar casos de teste para a verificação de requisitos funcionais e não funcionais de 
software.
•
DESAFIO
Elicitar e representar os requisitos de um produto de software são atividades críticas no processo 
de desenvolvimento. Se falhas forem cometidas nessa etapa, irão se propagar para o restante das 
fases e podem ser percebidas apenas quando já for tarde demais e o produto estiver entregue.
Erros sempre serão cometidos, pois as atividades de desenvolvimento de software são de 
natureza cognitiva e, portanto, dependem de pessoas, e pessoas cometem erros. Já que é possível 
minimizar, mas não eliminar, a introdução de erros, pode-se investir em atividades que evitem a 
sua propagação. Estas são as atividades de verificação.
Você está se tornando um analista de requisitos experiente, e seu gerente pediu sua ajuda para 
apoiar um colega que está iniciando. O colega definiu a lista de requisitos funcionais e não 
funcionais para um software que apoiará reuniões remotas, uma demanda que cresceu no 
mercado devido ao trabalho remoto originado em decorrência da COVID-19.
Foram repassados os seguintes requisitos funcionais e não funcionais:
Seu gerente lhe pediu que conduza uma revisão por pares usando um checklist
que contém três perguntas e que decida se os requisitos podem ser encaminhados para a próxima 
fase:
- Todos os requisitos estão livres de ambiguidade?
- Todos os requisitos são verificáveis?
- Todos os requisitos são determinísticos?
INFOGRÁFICO
Uma das formas de garantir a qualidade de um produto de software é inserir procedimentos de 
verificação em pontos críticos do processo de desenvolvimento. Isso pode ser feito por meio de 
filtros que são colocados em determinados pontos do ciclo e que ajudam a identificar erros, 
falhas e omissões antes que eles se propaguem para o restante das fases.
Diversas técnicas podem ser utilizadas para isso, como a revisão realizada pelo próprio produtor 
do artefato, a revisão por pares, as inspeções formais e os testes.
Acompanhe, no Infográfico, as etapas para a realização das atividades de verificação que são 
estabelecidas pela Norma Internacional ISO/IEC 12207:2017(E), que trata dos processos do 
ciclo de vida de software.
CONTEÚDO DO LIVRO
Requisitos bem definidos e especificados são a chave para o sucesso de projetos de software. É 
a partir deles que os desenvolvedores farão o código e os testadores farão os testes. Para garantir 
que os requisitos estejam adequados para essas fases seguintes, é preciso inserir atividades de 
verificação, que funcionam como filtros para que os possíveis erros cometidos na etapa de 
requisitos sejam detectados antes que cheguem ao usuário final.
A verificação pode ser compreendida como a atividade que é realizada com o intuito de 
descobrir defeitos. Elas podem ser realizadas no formato de revisões por pares, que podem ser 
mais ou menos formais. Revisões mais formais são chamadas de inspeções e têm um formato 
próprio para acontecer.
No capítulo Verificação de requisitos de software, da obra Engenharia de requisitos, você vai 
aprender a identificar a importância da verificação de requisitos como um instrumento da 
qualidade de software. Ainda, você vai ver como utilizar um checklist para realizar as atividades 
de verificação e, por fim, vai aprender a criar um caso de uso a partir dos requisitos.
Boa leitura.
ENGENHARIA 
DE 
REQUISITOS 
Sheila Reinehr
Verificação de requisitos 
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer a importância da verificação de requisitos de software.
 � Aplicar checklists de verificação de requisitos funcionais e não fun-
cionais de software.
 � Criar casos de teste para a verificação de requisitos funcionais e não 
funcionais de software.
Introdução
Todos sabemos que o mercado tem se tornado cada vez mais exigente 
com relação à qualidade dos produtos de software. Isso se dá em parte 
porque existe uma grande quantidade de softwares disponíveis para 
resolver diferentes tipos de problemas do cotidiano. As lojas virtuais 
oferecem uma infinidade de aplicativos para celular, tanto para iOS quanto 
para Android, que estão disponíveis a apenas um toque de distância. 
Assim como é fácil baixare começar a usar, também é fácil desinstalar e 
escolher outro aplicativo para substituí-lo.
Essa intensa exposição à tecnologia na vida pessoal torna os usuários 
mais exigentes inclusive com os softwares que ele utiliza no trabalho. 
Nesse ambiente, entretanto, não é tão simples substituir um produto 
por outro. Não se instala e desinstala um software corporativo, como, 
por exemplo, um sistema de gestão integrada, com a mesma facilidade 
com que se substitui um aplicativo para acompanhar exercícios físicos 
pelo smartwatch.
E como garantir que os produtos de software tenham a qualidade 
esperada e proporcionem uma experiência extraordinária ao usuário? 
A resposta não é trivial e envolve todas as etapas do ciclo de desenvol-
vimento de software, desde as primeiras conversas sobre o escopo do 
projeto até a entrega de uma versão ou do produto final ao usuário. Não 
importa que tipo de método estejamos utilizando para desenvolver, 
o objetivo é o mesmo: fazer uma entrega de qualidade.
Diferentemente da manufatura, que emprega muitas etapas automa-
tizadas, o desenvolvimento de software é uma atividade essencialmente 
cognitiva, que apresenta desafios muito mais complexos, pois erros hu-
manos podem ser cometidos durante todas as fases. E o que podemos 
fazer para reduzir os efeitos nocivos desses erros? Utilizar técnicas de 
verificação e validação ao longo das atividades de todo o ciclo de vida. 
E isto começa pela etapa de requisitos.
Neste capítulo você vai estudar a verificação de requisitos de software 
e sua importância para o ciclo de desenvolvimento. Vai ver como utilizar 
checklists de verificação de requisitos funcionais e não funcionais e tam-
bém como criar casos de teste para a verificação de requisitos funcionais 
e não funcionais.
1 Importância da verificação de requisitos 
de software
A engenharia de requisitos é a especialidade da engenharia de software que 
trata de todos os temas relacionados aos requisitos. Podemos compreender, 
de acordo com o SWEBOK (Software Engineering Body of Knowledge), que 
a engenharia de requisitos é “uma forma sistemática de tratar os requisitos” 
(BOURQUE; FAIRLEY, 2014, documento on-line).
Etapas da engenharia de requisitos
Ainda de acordo com o SWEBOK (BOURQUE; FAIRLEY, 2014, documento 
on-line): “A área de conhecimento de Requisitos de Software (KA) preocupa-se 
com a obtenção, análise, especificação, e validação de requisitos de software 
bem como o gerenciamento de requisitos durante todo o ciclo de vida do 
produto de software”.
Verificação de requisitos de software2
Vamos relembrar essas etapas referentes à engenharia de requisitos por 
meio da Figura 1. Considere o semicírculo mais externo como as atividades 
da engenharia de requisitos e o semicírculo interno como o desenvolvimento 
em si, ou seja, a implementação. Permeando todo o processo está o gerencia-
mento de requisitos.
Figura 1. Etapas da engenharia de requisitos.
Conforme você pode observar na Figura 1, a primeira etapa se refere à eli-
citação de requisitos. A elicitação de requisitos é “[…] o primeiro estágio para 
construir uma compreensão sobre o problema que o software deve resolver” 
(BOURQUE; FAIRLEY, 2014, documento on-line). Nela são identificadas 
as fontes de informação e são selecionadas as técnicas de elicitação mais 
adequadas, de acordo com o contexto do projeto. Após a seleção, é possível 
aplicar essas técnicas para obter os requisitos, sejam eles funcionais ou não 
funcionais.
Embora estejamos utilizando a expressão “etapa de elicitação”, é bom 
lembrar que isso não significa que é necessário que elicitar o conjunto com-
pleto de requisitos em um mesmo momento e nem que seja preciso chegar 
a níveis similares de detalhamento para cada requisito. Pode-se trabalhar de 
forma iterativa e incremental, como nas sprints dos métodos ágeis, nas quais 
os requisitos do product backlog vão sendo detalhados à medida que são 
necessários para alocação à sprint.
3Verificação de requisitos de software
A segunda etapa se refere à análise de requisitos, que é o momento em 
que nos aprofundamos nos requisitos e buscamos identificar inconsistências 
e conflitos entre os requisitos. Identificamos também as fronteiras do sistema 
e com quem ele deve interagir. Segundo Vazquez e Simões (2016), o objetivo 
da elicitação é encontrar as peças do quebra-cabeças e o objetivo da análise 
é montá-lo.
A terceira etapa é a especificação de requisitos. Como o próprio nome 
sugere é o momento em que nos dedicamos a documentar os requisitos de 
modo que possam ser utilizados pelas etapas seguintes do desenvolvimento, 
evitando ambiguidades e retrabalho. O nível necessário de especificação 
varia de acordo com a criticidade do software para o ambiente onde ele será 
utilizado, da experiência da equipe desenvolvedora, dos riscos envolvidos etc. 
Níveis diferentes de especificação podem ser necessários para cada requisito 
do produto. Em sistemas nos quais o software é apenas um componente da 
solução, é comum que as especificações sejam mais robustas e complexas, 
envolvendo diversos tipos de documentos: definição do sistema, especificação 
de requisitos do sistema e especificação de requisitos do software.
Finalmente, a quarta etapa é chamada genericamente de validação de 
requisitos, embora, na verdade, ela englobe tanto a validação quanto a veri-
ficação de requisitos.
Verificação e validação são termos diferentes! De acordo com a norma internacional 
ISO/IEC/IEEE 12207 (ISO/IEC/IEEE, 2017, p. 10–11):
 � Validação é “a confirmação, por meio do fornecimento de evidência objetiva, 
que o requisito foi atendido para um uso ou aplicação pretendidos específicos”. 
 � Verificação é a “confirmação, por meio do fornecimento de evidência objetiva, 
que os requisitos especificados foram atendidos”.
Ainda, de acordo com o CMMI-DEV 2.0 (CMMI INSTITUTE, 2018, p. 525), a diferença 
entre os termos é a seguinte:
 � Validação “demonstra que a solução vai atender seu uso pretendido no ambiente 
alvo, isto é, ‘você está construindo a coisa certa’”. 
 � Verificação “endereça que o produto de trabalho ou a solução refletem adequa-
damente os requisitos especificados, isto é, ‘você está construindo certo’”.
Verificação de requisitos de software4
De acordo com Bourque e Fairley (2014, p. 1-11), 
[...] os requisitos podem ser validados para assegurar que o engenheiro de 
software compreendeu os requisitos; é também importante verificar que o 
documento de requisitos está em conformidade com os padrões da empresa 
e que ele é compreensível, consistente e completo.
É comum dizermos que a verificação analisa se o produto foi construído 
certo, ou seja, de forma correta; e que a validação analisa se foi construído 
o produto certo, ou seja, aquele que os stakeholders desejavam (CMMI INS-
TITUTE, 2018).
De acordo com o modelo CMMI-DEV 2.0 (CMMI INSTITUTE, 2018), a verificação e a 
validação na engenharia de software envolvem simulação, estudos de rastreabilidade, 
revisões ou auditorias funcionais, revisões ou auditorias físicas, revisões por pares, 
demonstrações, protótipos, revisões formais, testes de módulo, regressão e integração 
de sistema.
Finalmente, a próxima etapa se refere ao gerenciamento de requisitos. 
Nesta etapa vamos nos preocupar com como tratar os requisitos ao longo do 
seu ciclo de vida e como analisar e gerenciar as solicitações de mudanças que, 
inevitavelmente, ocorrerão.
Neste capítulo vamos nos concentrar na etapa de validação de requisitos, 
mais especificamente nas atividades de verificação de requisitos. Atividades 
de validação propriamente ditas não serão tratadas neste capítulo.
Importância da verificação de requisitos
À medida que os softwares foram se tornando mais complexos, mais inte-
grados e mais críticos para todas as atividades cotidianas, mais importante 
ficou a garantia do seu correto funcionamento. Essa maior proximidade com 
a tecnologia vem tornando os usuários cada vez mais exigentes.
5Verificação de requisitos de software
A grandequestão é que há muitos pontos no ciclo de desenvolvimento 
nos quais erros que podem levar a falhas gigantescas de software. Isso ocorre 
porque as atividades envolvidas são de ordem cognitiva. A cada troca de mãos 
do requisito, ou seja, a cada troca de responsabilidade, um novo defeito pode 
estar sendo introduzido, como naquela brincadeira infantil do telefone sem fio.
Se no início do projeto o analista de requisitos não envolver todos os 
stakeholders relevantes para atuar como fonte de informação de requisitos, 
pode ser que um requisito muito importante não seja descoberto e permaneça 
invisível até as fases mais avançadas, levando ao retrabalho e a custos adicio-
nais de desenvolvimento. Esta é a primeira passagem de bastão do requisito, 
ou seja, é a primeira transição. Ele sai do ambiente dos stakeholders e passa 
para o ambiente do projeto, via processo de elicitação de requisitos conduzido 
pelo analista de requisitos.
Caso os requisitos, uma vez elicitados, não estejam descritos de forma 
clara e não ambígua, eles podem ser implementados de forma incorreta. Esta 
é a segunda passagem de bastão do requisito. Ele sai das mãos do analista de 
requisitos e passa para as mãos da equipe técnica, que pode ser composta por 
arquitetos, projetistas e desenvolvedores, que irão projetar a arquitetura da 
aplicação, as interfaces e desenvolver o código.
Por fim, uma terceira passagem de bastão, ou seja, troca de responsabi-
lidade, acontece quando a equipe de testes define os casos de teste que irão 
avaliar se o produto foi construído de acordo com o que estava especificado. 
Nesse caso o requisito sai das mãos do analista de requisitos e da equipe 
técnica e vai para as mãos dos testadores. Aqui podem acontecer problemas 
de interpretação que levam à construção de casos de teste ineficazes para o 
teste do produto.
Não podemos nos esquecer da última troca de bastão, que irá ocorrer quando 
o produto for implantado no ambiente-alvo e utilizado pelos seus usuários 
para cumprir as funções para as quais ele foi especificado.
Todas essas diversas trocas de responsabilidade podem levar a erros que 
se refletirão no ambiente de operação e podem trazer consequências diversas, 
como o retrabalho e seus custos associados ou falhas na operação, que podem 
gerar riscos de ferimentos ou de prejuízos financeiros. Ao longo da história 
da computação, diversos foram os casos de problemas não detectados em 
fases iniciais do desenvolvimento e que foram propagados até gerar grandes 
desastres. Vários deles você certamente já ouviu falar.
Verificação de requisitos de software6
Diversos são os exemplos de falhas de grande impacto ocasionadas por problemas 
em software, muitos deles oriundos da etapa de requisitos. Vamos relembrar alguns 
exemplos famosos:
 � O projeto de construção do aeroporto de Denver, nos Estados Unidos, subestimou 
a complexidade do algoritmo de controle das esteiras de bagagem, gerando dificul-
dade de integração entre o hardware e o software, e levando a prejuízos na ordem 
de U$ 1,1 milhão ao dia para a cidade de Denver (CALLEAM CONSULTING, 2008).
 � Em 2019, a Boeing teve que recolher toda a sua frota de 387 aviões do modelo 
Boeing 737 MAX, que estava em 59 companhias áreas, devido a um problema 
no novo software (BOEING..., 2019).
 � O foguete Ariane 5 explodiu em pleno ar devido a uma diferença de tamanho 
de campos de dados entre ele e o seu antecessor, cujo software foi reaproveitado. 
O prejuízo foi de US$ 370 milhões (HINKEL, [201-?]).
Muitas dessas falhas poderiam ter sido evitadas se procedimentos adequa-
dos de qualidade tivessem sido adotados ao longo do ciclo de vida, conforme 
ilustra a Figura 2, por meio das atividades de Verificação 1 a 5, representadas 
pelos triângulos. Note que está representado apenas um ciclo de vida genérico 
e bastante simplificado, que pode ser uma sprint, por exemplo.
Figura 2. Defeitos inseridos e removidos ao longo do ciclo de desenvolvimento.
Defeitos
Atividades de veri�cação
REQUISITOS
1 2 3 4 5
ANÁLISE CODIFICAÇÃO TESTES HOMOLOGAÇÃO
7Verificação de requisitos de software
Como você pode observar, os defeitos estão presentes desde o início. Se não 
tivéssemos introduzido as atividades de verificação intermediárias, teríamos 
chegado à fase de testes com a quantidade inicial de defeitos (início do cone 
na figura). Possivelmente, esses defeitos ainda teriam sido amplificados, 
considerando que um defeito em um requisito pode implicar em defeitos em 
outros requisitos também.
Quando introduzimos a atividade de Verificação 1, os defeitos provenientes 
da etapa de requisitos são reduzidos. Note que não estamos aqui falando que 
todos os requisitos do produto deveriam estar definidos, ou seja, não estamos 
nos referindo a um ciclo cascata. Estamos nos referindo ao conjunto de requi-
sitos que deveriam estar esclarecidos para uma versão ou sprint. 
Ao encerrarmos a fase de análise, é inserida a atividade de Verificação 2 
e, novamente, os defeitos são reduzidos, de modo a passar para a codificação 
um requisito que já esteja adequado para implementar. Se as atividades de 
Verificação 1 e Verificação 2 não tivessem sido realizadas, a codificação 
receberia todos os defeitos provenientes das fases anteriores.
Ao encerrarmos a codificação, esperamos que o desenvolvedor tenha rea-
lizado os testes de unidade ou testes unitários, que também são uma atividade 
de verificação. Ao final dessa fase, a atividade de Verificação 4 pode ser 
instituída tanto por meio de revisões de código quanto por meio de atividades 
de teste integrado.
Ao chegarmos na homologação, que é realizada pelo usuário, é esperado 
que esses defeitos tenham sido significantemente reduzidos. Note que, neste 
modelo fictício, se as atividades intermediárias não tivessem sido inseridas, 
a homologação receberia a quantidade inicial de defeitos, possivelmente ainda 
ampliada por outros inseridos como decorrência destes.
Diversas técnicas podem ser aplicadas para evitar que os erros se propaguem 
ao longo das fases, funcionando como uma espécie de filtro, como vimos na 
Figura 2. Quanto maior a quantidade de filtros e quanto mais finos eles forem, 
menos erros de propagarão. O problema é que esses filtros têm um custo, 
o chamado custo da qualidade, que deve ser cuidadosamente analisado para 
determinar o ponto de equilíbrio ideal.
Verificação de requisitos de software8
Cada ponto de verificação precisa prover insumos para que o processo de desen-
volvimento como um todo possa ser melhorado e a causa raiz dos erros possa ser 
identificada, de modo que no futuro os defeitos possam ser prevenidos.
Quando um defeito é detectado, ele precisa retornar para ser consertado, e isso é um 
retrabalho. Por isso é tão importante analisar os resultados provenientes das atividades 
de verificação. Portanto, insights sobre como melhorar o processo para evitar os erros 
constituem uma das saídas mais valiosas da análise de um processo de verificação.
A definição dos pontos onde essas intervenções são necessárias dependerá, 
primeiramente, da criticidade que uma falha representa para determinado 
sistema. Se a consequência for a perda de vidas, certamente os investimentos 
em qualidade serão todos compensados. Se a consequência for apenas uma 
pequena parada de um sistema que não tenha consequências críticas, então é 
possível que não se invista tanto nessas atividades de qualidade, priorizando 
esforços em outros pontos mais críticos.
Como realizar a verificação de requisitos
Os requisitos podem ser verificados de diversas formas. A primeira delas, 
naturalmente, é a leitura crítica dos artefatos, que é realizada pelo próprio 
autor, ou seja, o analista de requisitos, analisando pontos de ambiguidade, de 
inconsistência e de falta de completude nas definições. Para isso, ele pode ou 
não se apoiar em um checklist, que é um instrumento que funciona como uma 
espécie de lembrete, para que nenhum ponto seja esquecido.
Outras formas envolvem a revisão por pares, ou seja,a revisão que é rea-
lizada, como o próprio nome diz, pelos pares do analista de requisitos. Esses 
pares podem ser outros analistas de requisitos ou pessoas técnicas da equipe. 
São consideradas revisões por pares as listadas a seguir (CMMI PRODUCT 
TEAM, 2010):
 � inspeções;
 � walkthroughs estruturados;
 � refatoração deliberada;
 � programação em pares (pair programming).
9Verificação de requisitos de software
Da mesma forma que a autoavaliação, a avaliação por pares pode ou não 
ser apoiada por um checklist. Na próxima seção veremos como elaborar e 
utilizar um checklist.
Outra forma, e a mais utilizada, são os testes de software. Testes são realiza-
dos para identificar erros que já estão materializados no código. Abordaremos 
esse assunto mais adiante neste capítulo.
2 Checklists de verificação de requisitos 
de software
Conforme apresentado anteriormente, a norma internacional ISO/IEC/IEEE 
12207:2017(E) (ISO/IEC/IEEE, 2017, p. 82) define a finalidade do processo de 
verificação como “[…] prover evidência objetiva que o sistema ou elemento do 
sistema atende completamente seus requisitos e características especificados”.
A mesma norma define que:
[…] o processo de verificação identifica anomalias (erros, defeitos e falhas) em 
qualquer item de informação (requisitos de sistema/software ou descrição de 
arquitetura), elementos implementados, ou processos de ciclo de vida usando 
métodos, técnicas, padrões e regras apropriados (ISO/IEC/IEEE, 2017, p. 76).
Existem diversas formas de fazer a verificação dos requisitos. Uma delas 
é a revisão por pares, que nada mais é do que um par realizando a revisão 
sobre o trabalho do colega, com o objetivo de identificar inconsistências ou 
anomalias. Um par é um profissional de expertise equivalente ou superior a 
do(s) autor(es) do artefato, que pode contribuir tecnicamente, fazendo uma 
avaliação objetiva do artefato.
Artefato é o resultado da realização de uma atividade, podendo ser um 
documento, um diagrama ou o próprio código. Revisões por pares podem ser 
aplicadas a qualquer artefato do projeto. Vamos aqui discutir a sua aplicação 
para a verificação dos artefatos relacionados às etapas de requisitos, mas o 
raciocínio utilizado se aplica a qualquer outro tipo de artefato do ciclo de vida 
de desenvolvimento, incluindo o código.
As revisões por pares podem acontecer no formato de inspeções, walk-
throughs estruturados, auditorias ou outras formas de revisão. Sua aplicação 
vai depender do grau de formalismo desejado para a revisão. Inspeções são 
consideradas revisões mais formais e têm um formato próprio para acontecer. 
Verificação de requisitos de software10
As revisões também podem ser feitas seguindo diferentes abordagens. 
Podem ser baseadas em checklists, em cenários de execução, com foco na 
perspectiva de algum usuário, com foco em uma funcionalidade específica 
ou ser feita até mesmo de forma ad hoc.
Um dos requisitos não funcionais importantes referentes à qualidade interna de 
um produto de software é a verificabilidade. Verificabilidade se refere a “[...] quão 
bem os componentes de software ou o produto integrado podem ser avaliados para 
demonstrar se as funções do sistema funcionam conforme o esperado” (WIEGERS; 
BEATTY, 2013, p. 286).
Para identificar esses requisitos, você pode utilizar como dica as seguintes perguntas:
 � Como nós poderemos confirmar que cálculos específicos estão fornecendo os 
resultados esperados?
 � Existe alguma parte do sistema que não leva a resultados determinísticos, de forma 
que poderia ser difícil de determinar se está funcionando corretamente?
 � É possível ter conjuntos de dados de teste que tenham uma alta probabilidade de 
revelar quaisquer erros nos requisitos e sua implementação?
 � Que relatórios de referência ou outras saídas podem ser utilizadas para verificar se 
o sistema está produzindo os resultados corretamente?
Artefatos de requisitos
Se estamos focando em revisões dos requisitos, a pergunta é: que artefatos 
devem ser revisados? Os requisitos, uma vez elicitados, podem ser represen-
tados de diversas formas, dependendo do contexto do projeto, da organização 
desenvolvedora, das exigências do contratante, da experiência da equipe 
desenvolvedora e outros.
Vamos considerar neste capítulo duas formas de especificar requisitos: 
a abordagem orientada a casos de uso e a abordagem orientada e histórias de 
usuário. Além disso, vamos considerar também a lista de requisitos, que pode 
ser utilizada nas duas abordagens. Dessa forma, os seguintes artefatos serão 
considerados neste capítulo:
11Verificação de requisitos de software
 � Lista de requisitos funcionais e não funcionais.
 � Casos de uso:
 ■ Diagrama de casos de uso.
 ■ Especificação de casos de uso.
 � Histórias de usuário:
 ■ Cartão da história de usuário.
 ■ Critérios de aceitação das histórias de usuário.
Checklist para revisão de artefatos de requisitos
Um checklist pode ser considerado como uma lista contendo pontos de atenção 
para apoiar os revisores. Geralmente, ela é constituída dos itens que ante-
riormente já foram considerados problemáticos e que a equipe deseja evitar. 
O ideal é que cada artefato tenha seu checklist com itens próprios.
Vamos começar com alguns critérios que podem ser usados para analisar 
a lista de requisitos, que pode conter tanto os requisitos funcionais quanto 
os requisitos não funcionais. O Quadro 1 apresenta uma sugestão para este 
checklist. Itens identificados como “não” representam pontos de atenção que 
deverão ser priorizados e tratados pelo analista de requisitos. É sugerido que 
o revisor complemente as informações dos itens assinalados como “não”, 
de modo a facilitar as correções. 
Atributo Definição Sim Não Não se aplica
Completo O requisito está especificado 
de forma completa e que 
possibilita que o desenvolve-
dor o implemente?
Correto O requisito reflete o que 
o usuário, cliente ou seus 
representantes desejam?
Único O requisito descreve 
uma única capacidade, 
característica, restrição ou 
atributo de qualidade? 
Quadro 1. Checklist para a lista de requisitos
(Continua)
Verificação de requisitos de software12
Fonte: Adaptado de Wiegers e Beatty (2013) e ISO/IEC/IEEE (2018).
Atributo Definição Sim Não Não se aplica
Viável O requisito é viável técnica 
e financeiramente de ser 
implementado, de acordo 
com as restrições do projeto?
Necessário O requisito tem um motivo 
de existir, que é representado 
pelo seu relacionamento a 
uma fonte de informação e 
a um objetivo de negócio?
Priorizado O requisito tem uma 
prioridade atribuída para 
que possa ser alocado a 
uma versão do software?
Não 
ambíguo
O requisito não contém 
ambiguidades que levem os 
stakeholders a interpretá-lo 
de forma diferente?
Verificável O requisito é possível de ser 
verificado posteriormente 
quanto à sua implementação?
Conforme O requisito está em 
conformidade com os 
padrões de especificação 
estabelecidos, se houver?
Quadro 1. Checklistt para a lista de requisitos
(Continuação)
O diagrama de casos de uso é um diagrama que ajuda o analista de requi-
sitos a se comunicar com os usuários. Embora seja composto por elementos 
simples, o diagrama tem um grande poder de comunicação. O Quadro 2 
apresenta uma sugestão de checklist para verificação do diagrama de casos 
de uso. Itens identificados como “não” representam pontos de atenção que 
deverão ser priorizados e tratados pelo analista de requisitos.
13Verificação de requisitos de software
Atributo Definição Sim Não Não se aplica
Atores (escopo) Todos os atores estão 
representados no 
diagrama?
Atores (formato) Todos os atores estão 
representados por 
um boneco palito 
e um texto com a 
identificação do ator?
Relacionamentos 
de generalização 
entre atores 
(representação)
O relacionamento de 
generalização entre os 
atores é representado 
por uma seta vazada 
que aponta do ator filho 
para o ator pai?
Relacionamentos 
de generalização 
entre atores 
(significado)
O relacionamento degeneralização expressa 
corretamente a intenção 
de herança entre os 
atores envolvidos?
Casos de uso 
(representação)
Todos os casos de uso 
são representados por 
elipses e identificados 
por meio de um verbo 
no infinitivo seguido de 
um complemento?
Casos de uso 
(escopo)
Todos os casos de uso 
que representam as 
funcionalidades que os 
stakeholders desejam 
estão representados?
Relacionamentos 
dos casos de 
uso com atores
Todos os casos de uso 
estão ligados a pelo 
menos um ator?
Quadro 2. Checklist para o diagrama de casos de uso
(Continua)
Verificação de requisitos de software14
Atributo Definição Sim Não Não se aplica
Relacionamentos 
de <include> 
entre casos 
de uso
Os relacionamentos 
de <include> estão 
representados por setas 
pontilhadas que partem 
do caso de uso principal 
para o caso de uso 
incluído?
Relacionamentos 
de <extend> 
entre casos 
de uso
Os relacionamentos 
de <extend> estão 
representados por setas 
pontilhadas que partem 
do caso de uso que 
estende para o caso de 
uso principal?
Relacionamentos 
de generalização 
entre casos 
de uso 
(representação)
O relacionamento de 
generalização entre 
os casos de uso é 
representado por uma 
seta vazada que aponta 
do caso de uso filho 
para o caso de uso pai?
Relacionamentos 
de generalização 
entre casos de 
uso (significado)
O relacionamento de 
generalização expressa 
corretamente a intenção 
de herança entre os ca-
sos de uso envolvidos?
Quadro 2. Checklist para o diagrama de casos de uso
(Continuação)
O diagrama de casos de uso sozinho não é suficiente como especificação de 
requisitos funcionais, portanto é necessário complementar com um documento 
de especificação de casos de uso (que pode também ser feito dentro de uma 
ferramenta de modelagem).
15Verificação de requisitos de software
O Quadro 3 apresenta uma sugestão de checklist para verificação das 
especificações de casos de uso. Alguns itens se referem à especificação e 
outros se referem à consistência entre o diagrama de casos de uso e as suas 
especificações correspondentes. Itens identificados como “não” representam 
pontos de atenção que deverão ser priorizados e tratados pelo analista de 
requisitos.
Atributo Definição Sim Não Não se aplica
Identificação 
do caso 
de uso
O caso de uso tem um 
identificador único e um 
texto contendo um verbo no 
infinitivo e um complemento?
Ator principal O ator principal está 
identificado corretamente?
Ator 
secundário
O ator secundário (se houver) 
está identificado corretamente 
e participa do caso de uso jun-
tamente com o ator principal?
Pré-condição As pré-condições (se houver) 
estão descritas corretamente?
Fluxo 
principal
Todos os passos do fluxo 
principal estão numerados 
sequencialmente e descrevem 
claramente o diálogo 
entre o ator e o sistema?
Fluxos 
alternativos 
(descrição)
Todos os fluxos alternativos 
(se houver) estão numerados 
sequencialmente e descrevem 
claramente o diálogo 
entre o ator e o sistema?
Fluxos 
alternativos 
(retorno)
Todos os fluxos alternativos 
(se houver) definem qual 
é o próximo passo a ser 
executado ao seu término?
Quadro 3. Checklist para a especificação de casos de uso
(Continua)
Verificação de requisitos de software16
Atributo Definição Sim Não Não se aplica
Fluxos 
alternativos 
(chamadas)
Para todos os fluxos 
alternativos (se houver) estão 
identificados os pontos de 
chamada no fluxo básico?
Fluxos de 
exceção 
(descrição)
Todos os fluxos de exceção 
(se houver) estão numerados 
sequencialmente e descrevem 
claramente o diálogo entre 
o ator e o sistema em uma 
condição de exceção?
Fluxos de 
exceção 
(retorno)
Todos os fluxos de exceção 
definem qual é o próximo 
passo a ser executado ao seu 
término?
Fluxos de 
exceção 
(chamadas)
Para todos os fluxos de 
exceção estão identificados os 
pontos de chamada, seja no 
fluxo básico, seja nos fluxos 
alternativos?
Pós- 
-condições
As pós-condições (se houver) 
estão descritas corretamente?
Quadro 3. Checklist para a especificação de casos de uso
(Continuação)
Quando a equipe de desenvolvimento utiliza métodos ágeis, é comum que os 
requisitos funcionais sejam expressos como histórias de usuário. As histórias 
de usuário são compostas por cartões, com uma declaração da necessidade 
do usuário e por critérios de aceitação que normalmente detalham a história 
ou especificam os requisitos não funcionais. O responsável pelos itens que 
compõem o product backlog, e que irão gerar as histórias, é o product owner 
(PO). Cabe a ele representar os interesses do cliente ou do usuário junto à 
equipe de desenvolvimento. As histórias de usuário geralmente são escritas 
de forma conjunta, entre o PO e a equipe de desenvolvimento.
17Verificação de requisitos de software
A principal característica dos times ágeis é a comunicação. Os integrantes 
são estimulados a se reunir em workshops de esclarecimento de histórias e 
seguem a máxima dos 3 Cs: cartão + conversa + confirmação (critérios de 
aceitação). Portanto, é comum que as revisões já aconteçam ao longo do desen-
volvimento das próprias histórias, durante esses workshops (PATTON, 2014).
No entanto, nem todos os ambientes ágeis funcionam tão bem. É bastante 
comum que as histórias de usuário sejam, na verdade, chamados que chegaram 
pelo Help Desk, foram sendo armazenados em um backlog de solicitações de 
mudança e foram alocados à sprint sem antes terem passado por uma conversa 
para aprofundar o seu entendimento. Nesses casos, a aplicação de um checklist 
pode apoiar a equipe na melhoria da qualidade da compreensão dessas histórias.
O Quadro 4 apresenta uma sugestão para o checklist de histórias de usuário. 
Note que esses critérios são muito similares aos critérios da lista de requisitos. 
É sugerido que o revisor complemente as informações dos itens assinalados como 
“não”, de modo a facilitar as correções a serem realizadas pelo autor do artefato.
Atributo Definição Sim Não Não se aplica
Formato A história de usuário está escrita 
no padrão: “Como (nome do 
papel), eu quero (…) de modo 
que (…)”?
Completa A história de usuário está 
especificada de forma completa 
e que possibilita que o 
desenvolvedor o implemente?
Correta A história de usuário reflete o 
que o usuário, cliente ou seus 
representantes desejam?
Única A história de usuário descreve 
uma única capacidade, 
característica, restrição ou 
atributo de qualidade? 
Quadro 4. Checklist para histórias de usuário
(Continua)
Verificação de requisitos de software18
Atributo Definição Sim Não Não se aplica
Viável A história de usuário é viável 
técnica e financeiramente de ser 
implementada, de acordo com 
as restrições do projeto ou da 
sprint?
Neces-
sária
A história de usuário tem um 
motivo de existir, que é repre-
sentado pelo seu relaciona-
mento a uma fonte de informa-
ção e a um objetivo de negócio?
Priorizada A história de usuário tem uma 
prioridade atribuída para que 
possa ser alocada a uma sprint?
Não 
ambígua
A história de usuário não 
contém ambiguidades que 
levem os stakeholders a 
interpretá-la de forma diferente?
Verificável A história de usuário é possível 
de ser verificada posteriormente 
quanto à sua implementação?
Quadro 4. Checklist para histórias de usuário
(Continuação)
Melhoria da qualidade das revisões
As revisões por pares são momentos preciosos para promover a melhoria na 
qualidade das especificações de requisitos. Para que as revisões sejam provei-
tosas e se ganhe em produtividade, Wiegers (2006) apresenta as dicas a seguir.
 � Eduque os revisores: explique para os revisores o que é esperado deles 
e qual será o processo usado na revisão. Aprender a dar feedback faz 
parte desse aprendizado. O foco da revisão deve estar sobre o artefato, 
e não sobre a pessoa.
 � Não sobrecarregue os revisores: não espere que o documento esteja 
100% completo. Ele pode ir sendo revisado aos poucos. É mais fácil 
conseguir 30 minutos de uma pessoa do que uma tarde toda.
19Verificação de requisitos de software
 � Construaparcerias colaborativas com os representantes dos usuá-
rios e com outros membros da equipe do projeto: a voz do cliente 
é muito importante na revisão dos requisitos, embora esta seja uma 
atividade de validação e não de verificação. Envolva o usuário ou 
representantes do usuário.
 � Convide os revisores certos: envolva desenvolvedores e testadores 
também no processo de revisão, pois eles podem ter insights que os 
analistas de requisitos não têm. São visões diferentes que contribuem 
para a revisão. Eles podem usar a técnica de perspective based reading, 
ou leitura baseada em perspectiva (é uma leitura orientada sob a ótica 
específica daquele papel).
 � Faça os revisores analisarem os entregáveis apropriados: nem todos 
os revisores terão que avaliar todos os artefatos de requisitos. Encaminhe 
o artefato para o revisor que mais pode contribuir com aquele artefato 
especificamente.
 � Projete para facilitar a revisão: represente os requisitos de forma a 
facilitar a revisão.
 � Inspecione todos os entregáveis de requisitos: embora as revisões 
informais sejam úteis, as inspeções formais são mais profundas e 
descobrem mais detalhes, uma vez que fazem com que os inspetores 
realmente analisem os artefatos.
 � Enfatize encontrar os maiores erros: os requisitos faltantes são os mais 
difíceis de serem detectados. Invista tempo para este tipo de requisito.
3 Casos de teste de requisitos de software
A técnica mais utilizada para realizar a verificação de artefatos de desenvol-
vimento de software é o teste. Testes de software são utilizados para avaliar 
o código implementado, seja ele no formato de um componente isolado, seja 
no formato de um produto integrado.
Não é nosso objetivo neste capítulo o aprofundamento nas diversas técnicas 
de teste de software, mas apresentar os casos de teste como forma de refi-
namento e verificação de requisitos, tanto em ambientes tradicionais quanto 
em ambientes ágeis.
Verificação de requisitos de software20
Testes em ambientes tradicionais
Geralmente, os casos de teste são escritos como apoio para que a equipe de 
testes possa realizar o seu trabalho. Existe uma variedade de formatos de escrita 
de casos de teste, que vão desde templates no formato de planilhas eletrônicas 
até ferramentas automatizadas, com robôs programados para executar os testes.
Independentemente da forma como o teste seja implementado, é importante 
compreender o que está envolvido no planejamento dos testes. Se voltarmos 
à Figura 2, veremos que existe uma etapa de testes representada logo após a 
codificação. Esse é um exemplo apenas didático e simplificado. Na realidade, 
os testes são realizados desde a fase de codificação, como forma do próprio 
desenvolvedor avaliar o seu trabalho. Em seguida, o produto segue para a 
equipe de testes, quando a empresa tem uma. E, finalmente, passa para o 
ambiente de homologação, onde iniciam os testes que envolvem o usuário ou 
um representante do usuário. Nesse caso, passamos a chamar de validação, 
e não mais de verificação, conforme as definições que já foram apresentadas 
anteriormente neste capítulo.
O grande benefício do desenvolvimento dos testes concomitantemente aos requisitos, 
ou logo após esses, é que os testes ajudam a esclarecer pontos obscuros dos requisitos. 
Refinamentos são possíveis sobre os requisitos, uma vez que se busca as formas para 
testá-lo. Visão similar foi incorporada pelos métodos ágeis, como se verá adiante.
Para a especificação dos casos de teste, o template apresentado no Quadro 5 
pode ajudar. Inicialmente, deve ser identificada a origem do requisito. Neste 
caso, temos um exemplo usando casos de uso. Em seguida deve vir o identi-
ficador único do caso de teste, depois temos uma coluna onde são registrados 
os passos que o testador deve executar e qual é o resultado esperado.
Se tudo der certo e o sistema prover a resposta esperada, ele indica isto 
marcando um X na coluna ✔. Caso a execução não tenha ocorrido com su-
cesso, então ele marcará um X na coluna que aparece como ✗ na planilha. 
Nesse segundo caso, ou seja, o sistema não apresentou o resultado esperado, 
o testador deve reportar os detalhes para que o desenvolvedor possa corrigir.
21Verificação de requisitos de software
ID do caso 
de uso
ID do 
caso de 
teste
Passos
Resultado 
esperado
✔ ✗ N/A
<inserir o 
id do caso 
de uso>
<inserir o 
id do caso 
de teste>
<inserir 
os passos 
detalhados 
para a 
realização do 
caso de teste>
<inserir o 
resultado 
esperado 
ao final da 
execução 
do passo>
EXEMPLO
UC-CAD-001 CT-
CAD-001
1 – Selecionar 
função 
Cadastrar 
Cliente
Tela de 
Cadastro 
de Cliente 
aberta
×
2 – Preencher 
CPF incorreto
Msg de erro 
exibida: “CPF 
inválido”
×
(…)
Quadro 5. Template para casos de teste
Casos de teste são considerados ativos do processo de desenvolvimento 
e fazem parte do produto. A cada nova alteração em uma funcionalidade, os 
casos de teste precisam ser revisados para que continuem coerentes com as 
implementações. No caso de testes automatizados, é necessário que o código 
do teste seja refeito.
Testes em ambientes ágeis
Em ambientes ágeis de desenvolvimento de software, de acordo com Leffin-
gwell (2011), é comum pensar de forma mais holística e sistemática, em que 
histórias (requisitos), implementação (código) e validação (testes de aceitação, 
testes unitários e outros) estejam juntos. Leffingwell (2011) apresenta uma 
matriz que descreve os tipos de teste em ambientes ágeis, ilustrada na Figura 3.
Verificação de requisitos de software22
No quadrante Q1 estão os testes realizados pelo desenvolvedor, geralmente 
automatizados e em grande volume. São os testes unitários e de componentes. 
No quadrante Q2 estão os testes funcionais, que testam o funcionamento 
das histórias de usuário. Esses testes podem ser automatizados ou manuais. 
No quadrante Q3 se encontram os testes de aceitação ou testes de sistema; 
geralmente são testes manuais, que envolvem usuários e testadores em am-
bientes que simulam o ambiente real. No quadrante Q4 estão os testes de 
qualidade do sistema; geralmente envolvem o uso de ferramentas para os 
testes de desempenho e de carga.
Figura 3. A matriz de testes ágeis.
Fonte: Adaptada de Leffingwell (2011).
Os testes de aceitação de histórias, representados no quadrante Q2 da 
Figura 3, são testes realizados pelos desenvolvedores. Trata-se de testes fun-
cionais para garantir que as histórias de usuário entregam o que era pretendido. 
Geralmente, o time ágil passa grande parte do tempo definindo esses testes, 
pois esta é uma forma de refinar o comportamento esperado da história. 
23Verificação de requisitos de software
É comum, nestes ambientes, que a história seja uma afirmação curta, escrita 
no formato padronizado que expressa quem + o que + porquê. Para que ela 
possa ser adequadamente compreendida, os testes de aceitação da história 
são escritos e devem conter todos os detalhes para que o desenvolvedor possa 
implementá-la.
Considere a seguinte história de usuário (LEFFINGWEL, 2011):
Como cliente, eu sempre vejo o preço atual da energia refletido no meu portal e nos meus 
dispositivos de modo que eu sei que os meus custos de uso da energia são precisos e 
refletem qualquer mudança de preço.
Os seguintes testes de aceitação da história serão derivados:
1. Verificar que o preço atual é sempre usado e que os números calculados são exibidos 
corretamente no portal e em cada dispositivo (ver anexos).
2. Verificar que o preço e os números calculados são atualizados corretamente quando 
o preço muda.
3. Verificar que o campo “preço atual“ em si é atualizado de acordo com a agenda.
4. Verificar as mensagens de informação/erro quando houver erro na precificação (ver 
mensagens de erro aprovadas no anexo)
Para se aprofundar nos temas relacionados a teste de software, o capítulo 22 do livro 
Engenharia de Software: uma abordagem profissional, de Pressman e Maxim (2016), que 
apresenta estratégias e teste de software, é uma leitura que valea pena.
Verificação de requisitos de software24
BOEING 737 Max Lion Air crash caused by series of failures. BBC, 2019. Disponível em: 
https://www.bbc.com/news/business-50177788. Acesso em: 29 abr. 2020.
BOURQUE, P.; FAIRLEY, R. SWEBOK: guide to the software engineering body of knowledge: 
version 3. USA: IEEE Computer Society, 2014. Disponível em: https://www.computer.
org/education/bodies-of-knowledge/software-engineering. Acesso em: 29 abr. 2020.
CALLEAM CONSULTING. Denver Airport baggage handling system case study. [S. l.], 2008. 
Disponível em: http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.
pdf. Acesso em: 29 abr. 2020.
CMMI INSTITUTE. CMMI model V2.0. Pittsburgh: CMMI Institute, 2018.
CMMI PRDUCT TEAM. CMMI® for Development, Version 1.3. Hascom AFB: Software En-
gineering Institute, 2010. Disponível em: https://resources.sei.cmu.edu/asset_files/
TechnicalReport/2010_005_001_15287.pdf. Acesso em: 29 abr. 2020.
HINKEL, J. N. Ariane 5: um erro numérico (overflow) levou à falha no primeiro lançamento. 
São José dos Campos, [201-?]. Disponível em: https://www.ime.uerj.br/~demoura/
Especializ/Ariane/. Acesso em: 29 abr. 2020.
ISO/IEC/IEEE. ISO/IEC/IEEE 12207:2017(E): systems and software engineering: software 
life cycle processes. Switzerland: ISO, 2017.
ISO/IEC/IEEE. ISO/IEC/IEEE 29148:2018: systems and software engineering: life cycle 
processes: requirements engineering. Switzerland: ISO, 2018.
LEFFINGWELL, D. Agile software requirements: lean requirements practices for teams, 
programs, and enterprises. Upper Saddle River: Adisson-Wesley, 2011. 
PATTON, J. User story mapping: discover the whole story, build the right product. Se-
bastopol: O´Reilly, 2014.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado ao negócio. 
Rio de Janeiro: Brasport, 2016.
WIEGERS, K. E. More about software requirements: thorny issues and practical advice. 3. 
ed. Redmond: Microsoft Press, 2006.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
PRESSMANN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: AMGH, 2016.
25Verificação de requisitos de software
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
Verificação de requisitos de software26
DICA DO PROFESSOR
Quando um defeito referente a requisitos é encontrado em uma fase muito adiantada do 
desenvolvimento, as consequências para o projeto podem ser desastrosas, a começar pelo 
retrabalho gerado para consertar o problema. Se esse defeito só aparecer no ambiente do cliente, 
então, é pior ainda!
Uma forma de minimizar defeitos dessa natureza é executando atividades de qualidade desde o 
início do ciclo de vida. Isso pode ser feito pela introdução de revisões nos artefatos gerados na 
fase de requisitos. Essas revisões podem ser pessoais, dos pares, mais formais ou menos 
formais. O importante é que sejam realizadas.
Acompanhe, nesta Dica do Professor, diretrizes para a condução de revisões formais de software 
ou inspeções.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
Checklists são instrumentos que apoiam o processo de revisão de artefatos de software. 
Eduardo realizou uma revisão dos requisitos usando um checklist de critérios de qualidade 
para apoiar sua colega Maria Luiza.
Com o aumento da demanda por suprimentos médicos devido à COVID-19, Maria Luiza, 
que é analista de requisitos, foi chamada para o desenvolvimento de um software de vendas 
pela Internet e recebeu a seguinte mensagem de seu cliente:
“Quero um sistema bem fácil de usar, em que qualquer pessoa possa pedir suprimentos 
básicos de proteção. Os clientes podem escolher os produtos a partir de um catálogo que 
deverá ser exibido por categoria: máscaras, álcool em gel ou equipamentos de proteção. Os 
produtos podem ser pagos com cartão de crédito ou boleto bancário. A entrega será via 
correio, liberada quando o pagamento for confirmado. Todos os visitantes podem pesquisar 
os produtos, mas apenas os clientes logados podem fazer uma compra.”
Com base nesse texto, ela extraiu os seguintes requisitos:
1) 
 
Com base nas informações fornecidas, qual foi a decisão de Eduardo?
A) O conjunto de requisitos listado está completo e correto; portanto, os requisitos podem 
seguir para a próxima fase do processo de desenvolvimento.
B) O conjunto de requisitos listado está completo, mas há alguns requisitos ambíguos, e, por 
isso, os requisitos não podem seguir para a próxima fase do processo de desenvolvimento.
C) O conjunto de requisitos listado não está completo e, por isso, não pode seguir para a 
próxima fase do processo de desenvolvimento.
D) O conjunto de requisitos não está completo, e os requisitos estão todos ambíguos; por isso, 
não podem seguir para a próxima fase do processo de desenvolvimento.
E) O conjunto de requisitos listado não está completo, mas os requisitos corretos podem 
seguir para a próxima fase do processo de desenvolvimento. 
2) 
A inspeção é uma técnica de revisão por pares mais formal, que tem o objetivo de 
identificar defeitos antes que se propaguem no ciclo de vida. Marcela é analista de 
requisitos e foi chamada para participar de uma inspeção de requisitos de um projeto de 
software para apoiar a venda de produtos artesanais de moradores da Serra do Mar. Ela 
recebeu a lista de requisitos e um checklist para apoiar a revisão:
Considerando o checklist, identifique a situação do requisito R1 e assinale a alternativa 
correta:
A) São atendidos os itens 1, 2 e 3 do checklist. 
B) São atendidos os itens 1 e 2 do checklist. 
C) São atendidos os itens 2 e 3 do checklist. 
D) Apenas o item 1 do checklist é atendido. 
E) Apenas o item 2 do checklist é atendido. 
3) A revisão por pares é uma técnica que auxilia na identificação de defeitos em artefatos de 
software antes que eles se propaguem para outras etapas do desenvolvimento. Giovanna 
elaborou o diagrama de casos de uso a seguir, e Fernanda foi chamada para realizar a 
revisão por pares.
Descrição dos stakeholders: “O sistema deverá permitir que o professor insira, revise e 
consulte as notas. O aluno poderá consultar as notas. Todos os usuários deverão estar 
logados para executar as operações. O sistema deverá suportar até 30.000 usuários 
simultâneos sem degradar o desempenho.”
Fernanda analisou o diagrama e a descrição fornecida pelos stakeholders e concluiu que:
A) O diagrama pode ser aprovado porque contém todos os elementos descritos na fala dos 
stakeholders. 
B) O diagrama está incorreto porque diz que o aluno também pode revisar notas por causa do 
relacionamento de generalização.
C) O diagrama está incorreto porque faltou representar os atores secundários que também 
participam do sistema. 
D) O diagrama está incorreto porque não contempla o requisito de desempenho referente à 
quantidade de usuários. 
E) O diagrama está incorreto porque está representando que apenas o ator usuário pode 
consultar notas.
4) No desenvolvimento ágil de software, critérios de aceitação são especificados como base 
para o teste das histórias do usuário. Marco Antonio é o product owner de um projeto que 
visa a implementar um software para realizar reserva de mesas em bares e restaurantes. 
Ele escreveu uma história de usuário e os critérios de aceitação.
Com base nas informações apresentadas, assinale a alternativa correta:
A) A história do usuário está correta e completa, e todos os critérios de aceitação estão 
adequados.
B) A história do usuário está correta e completa, mas apenas os critérios de aceitação 1 e 2estão adequados. 
C) A história do usuário não está correta e completa, mas todos os critérios de aceitação estão 
adequados. 
D) A história do usuário não está correta e completa, e apenas os critérios de aceitação 1 e 2 
estão corretos.
E) A história do usuário não está correta e completa, e apenas os critérios 2 e 3 estão corretos.
5) Não é possível verificar posteriormente um requisito não funcional se ele não estiver 
especificado por meio de um atributo mensurável. Você foi chamado para inspecionar a 
lista de requisitos não funcionais de um software para gerenciar a escala de plantão de 
médicos e enfermeiros em um hospital de campanha montado para emergências 
relacionadas ao Corona Vírus. Considere os atributos definidos a seguir:
Assinale a alternativa que representa adequadamente a sua decisão como inspetor desses 
requisitos:
A) Os requisitos não funcionais RNF1, RNF2 e RNF3 estão corretos e completos e podem ser 
encaminhados para a implementação. 
B) Os requisitos não funcionais RNF1 e RNF2 estão corretos e completos e podem ser 
encaminhados para a implementação. O RNF3 precisa de ajustes. 
C) Os requisitos não funcionais RNF2 e RNF3 estão corretos e completos e podem ser 
encaminhados para a implementação. O RNF 1 precisa de ajustes. 
D) Os requisitos não funcionais RNF1 e RNF3 estão corretos e completos e podem ser 
encaminhados para a implementação. O RNF2 precisa de ajustes. 
E) Os requisitos RNF1, RNF2 e RNF3 precisam voltar ao analista de requisitos para ajustes. 
NA PRÁTICA
Os processos de verificação de requisitos contribuem para que os requisitos estejam em grau de 
detalhe e qualidade suficiente para prosseguirem para as próximas etapas do projeto. Existem 
diversas formas pelas quais se pode realizar essa atividade. Uma delas é o emprego de revisões 
por pares, ou seja, receber a contribuição dos pares para identificar falhas, ambiguidades e falta 
de completude.
As revisões por pares podem ser informais, realizadas por algum colega que faz uma leitura 
crítica do material, ou mais formais, no formato de inspeções.
Judy é uma analista de requisitos que recebeu a atividade de organizar e conduzir uma inspeção 
nas histórias de usuário de uma sprint crítica de um projeto que seu colega Mark está 
desenvolvendo.
Acompanhe, neste Na Prática, os desafios de Judy e como ela tratou essa questão.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Inspeção de documentos de requisitos de software
Neste vídeo, você vai ver o que é a inspeção na área de software e como essa técnica pode ser 
utilizada para a inspeção de qualquer artefato de software, incluindo os artefatos de requisitos. 
São discutidos também os custos das inspeções e seus benefícios.
Conteúdo interativo disponível na plataforma de ensino!
Uso de revisões
Leia o capítulo 20 do livro de Roger Pressman e Bruce Maxim, que trata das revisões na 
produção de software, sua importância, como medir a sua eficácia e como se preparar para as 
revisões.
Verificação e validação em software aeronáutico
Neste vídeo, o palestrante, que trabalha no software de comando de voo, explica um pouco a 
respeito na Norma DO-178C, aplicada para sistemas embutidos no segmento da aviação. Vale a 
pena conferir essa perspectiva do desenvolvimento de um software em um segmento crítico.
Conteúdo interativo disponível na plataforma de ensino!
Conhecer requisitos
APRESENTAÇÃO
Você sabia que o levantamento de requisitos pode ajudar a evitar a frustração de clientes ao final 
de um projeto de software? Muitas vezes, o cliente não sabe muito bem do que precisa, tornando 
mais difícil criar um projeto que satisfaça às suas necessidades. A identificação de requisitos no 
início do projeto é muito importante para o bom desenvolvimento do sistema. Um requisito 
pode ser uma condição, capacidade, função, objetivo, propriedade ou restrição que caracterize 
um sistema e satisfaça uma regra de negócio ou contrato. 
Nesta Unidade de Aprendizagem, você irá conhecer os conceitos básicos de requisitos e as 
diferenças entre requisitos funcionais e não funcionais. Também irá estudar o que são regras de 
negócio e quais os principais problemas enfrentados pelos engenheiros de software ao coletar os 
requisitos. 
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Listar as técnicas de coleta de dados.•
Diferenciar requisitos funcionais e não funcionais.•
Identificar as regras de negócio.•
DESAFIO
A companhia aérea YXZ está com aumento de vendas de bilhetes aéreos e precisa que você 
projete e implemente um sistema de controle de reservas e vendas de bilhetes.
 
Você deve listar e descrever, de forma clara, quais são os requisitos funcionais e não funcionais 
que este sistema pode ter (informe no mínimo 2 de cada tipo).
INFOGRÁFICO
Veja, no infográfico a seguir, o conceito de requisitos de software e entenda a diferença entre os 
requisitos funcionais e não funcionais.
 
CONTEÚDO DO LIVRO
A coleta e identificação de requisitos de software pode ser considerada uma das tarefas mais 
importantes no processo de criação de um sistema. Um levantamento de requisitos mal feito 
gera um risco muito alto para qualquer projeto, podendo levá-lo ao fracasso. Por isso, é muito 
importante entender como é feito o levantamento de requisitos, seus tipos e características.
Acompanhe a leitura do capítulo Conhecer requisitos, da obra Engenharia de Software e 
conheça os conceitos básicos de requisitos e as diferenças entre requisitos funcionais e não 
funcionais, além de saber o que são regras de negócio e os problemas enfrentados pelos 
Engenheiros de software ao coletar os requisitos.
Boa leitura!
Conteúdo:
ENGENHARIA 
DE SOFTWARE
Aline Zanin
Izabelly Soares 
de Morais
Revisão técnica:
Jeferson Faleiro Leon
Desenvolvimento de Sistemas 
Especialista em Formação Pedagógica de Professores
Catalogação na publicação: Karin Lorien Menoncin CRB-10/2147
M827e Morais, Izabelly Soares de.
 Engenharia de software [recurso eletrônico] / Izabelly
 Soares de Morais, Aline Zanin ; revisão técnica : Jeferson
 Faleiro Leon. – Porto Alegre : SAGAH, 2017.
 
 ISBN 978-85-9502-253-9
 Engenharia. 2. Engenharia de software auxiliada por 
 computador. I. Zanin, Aline. II. Título.
 
CDU 004.41
Conhecer requisitos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Listar as técnicas de coleta de dados. 
 � Diferenciar requisitos funcionais e não funcionais. 
 � Identificar as regras de negócio.
Introdução
Você sabia que o levantamento de requisitos pode ajudar a evitar a frus-
tração de clientes ao final de um projeto de software? Muitas vezes, o 
cliente não sabe muito bem do que precisa, tornando mais difícil criar um 
projeto que satisfaça às suas necessidades. A identificação de requisitos 
no início do projeto é muito importante para o bom desenvolvimento 
do sistema. Um requisito pode ser uma condição, uma capacidade, uma 
função, um objetivo, uma propriedade ou uma restrição que caracterize 
um sistema e satisfaça uma regra de negócio ou contrato. 
Neste capítulo, você vai conhecer os conceitos básicos de requisitos 
e as diferenças entre requisitos funcionais e não funcionais. Também vai 
estudar o que são regras de negócio e quais os principais problemas 
enfrentados pelos Engenheiros de software ao coletar os requisitos.
Técnicas para coleta de dados
A complexidade de um software está associada a todas as suas particularidades, 
que vão desde as suas funcionalidades até os recursos que este necessita para 
desempenhar sua função com eficácia. O desenvolvimento de um sistema exige 
que algumas etapas sejam seguidas e executadas com lógica. Dessa forma, um 
planejamento de um software tem como uma desuas principais atividades a 
obtenção dos requisitos, ou seja, todas as funcionalidades do software. Porém, 
apesar de aparentemente ser fácil definir o que um sistema irá fazer, não é, 
pois dependemos diretamente do cliente, ou seja, daquele que está contratando 
nosso serviço para desenvolver um software que irá suprir suas necessidades.
Este primeiro momento é crucial para todas as demais etapas, pois ima-
gine se a equipe desenvolve todo o software e, no final, ele não atende às 
necessidades do cliente? É por isso que essa etapa tem também cunho inves-
tigativo, no qual a equipe, além de ter que desenvolver o software, deve saber 
extrair do cliente tudo que ele precisa, ou seja, os requisitos do software. Um 
fato importante, e que merece ser citado, é o de que nem sempre o cliente 
compreende o que é desenvolver um software, dessa forma, provavelmente 
ele não terá noção de como deve expor suas ideias, de forma organizada e 
coerente, e muito menos saberá relacionar o trabalho que será empenhado em 
seu projeto com os custos e os prazos finais. Para ele, é tudo muito simples, 
como inserir uma janela, mudar uma funcionalidade de um botão, ou até 
mesmo acrescentar uma lista de produtos, por exemplo. Mal sabe ele que, na 
verdade, tudo requer investimento de tempo e trabalho de uma equipe com 
diversas expertises diferentes.
Algumas técnicas acabaram sendo desenvolvidas para auxiliar a equipe de 
desenvolvimento neste processo. Conforme Pressman e Maxim (2016, p. 143), 
muitas abordagens para a coleta colaborativa de requisitos foram propostas. 
Cada uma faz uso de um cenário ligeiramente diferente, porém todas aplicam 
alguma variação das seguintes diretrizes básicas:
 � As reuniões (reais ou virtuais) são conduzidas com a participação tanto 
dos Engenheiros de software quanto de outros envolvidos.
 � São estabelecidas regras para a preparação e a participação.
 � É sugerida uma agenda suficientemente formal para cobrir todos os 
pontos importantes; porém, suficientemente informal para estimular 
o fluxo livre de ideias.
 � Um “facilitador” (pode ser um cliente, um desenvolvedor ou uma pessoa 
de fora) dirige a reunião.
 � É utilizado um “mecanismo de definições” (planilhas, flip charts, 
adesivos de parede ou um boletim eletrônico, salas de bate-papo ou 
fóruns virtuais).
O momento em que os requisitos estão sendo coletados é nomeado como 
descoberta de requisitos, que, segundo Sommerville (2011, p. 72-76), é o pro-
cesso de reunir informações sobre o sistema requerido e os sistemas existentes 
e separar dessas informações os requisitos de usuário e de sistema. Para isso, 
o autor lista algumas formas de executar tal ação:
Conhecer requisitos2
1. Entrevistas. Podem ser de dois tipos: 
 ■ Entrevistas fechadas, em que um conjunto predefinido de perguntas 
é respondido pelo cliente.
 ■ Entrevistas abertas, em que não existe uma agenda predefinida, e a 
equipe desenvolve uma série de questões com o intuito de compre-
ender melhor as necessidades do cliente.
2. Cenários. Podem ser úteis para a obtenção de mais detalhes na visão 
geral dos requisitos, em que cada cenário cobre determinados números 
de interações. Um cenário começa por meio de um esboço da interação. 
Durante o processo de elicitação, são adicionados detalhes ao esboço, 
para criar uma descrição completa dessa interação. Um cenário pode 
incluir:
 ■ Uma descrição do que o sistema e os usuários esperam quando o 
cenário se iniciar.
 ■ Uma descrição do fluxo normal de eventos no cenário.
 ■ Uma descrição do que pode dar errado e como isso é tratado.
 ■ Informações sobre outras atividades que podem acontecer ao mesmo 
tempo.
 ■ Uma descrição do estado do sistema quando o cenário acaba. 
3. Casos de uso. Trazem definições estabelecidas pela linguagem de 
modelagem unificada (UML, do inglês Unified Modeling Language). 
São documentados por um diagrama de casos de uso de alto nível. 
Identificam as interações individuais entre o sistema e seus usuários 
ou outros sistemas.
4. Etnografia. É uma técnica de observação que pode ser usada para 
compreender os processos operacionais e ajudar a extrair os requisitos 
de apoio para esses processos, em que um analista faz uma imersão no 
ambiente de trabalho em que o sistema será usado. O trabalho diário 
passa por diversas observações, nas quais contêm anotações sobre as 
tarefas em que os participantes estão envolvidos são realizadas.
As técnicas são definidas conforme o contexto em que o projeto será 
inserido, até mesmo porque não podemos definir qual método de coleta de 
dados é o mais adequado, tendo em vista que as possibilidades são infinitas.
3Conhecer requisitos
Ao utilizarmos o termo stakeholder, estamos nos referindo a qualquer pessoa que 
possa estar diretamente ou indiretamente envolvida no projeto, podendo ser desde 
o cliente até o gerente de projeto. É importante compreendermos que cada um trará 
um ponto de vista diferente ao projeto, tendo em vista que cada um trará, também, 
toda a sua bagagem de conhecimentos e experiências. Pode, muitas vezes, ser uma 
boa contribuição para a excelência do produto final, que será o software.
Requisitos funcionais e não funcionais 
Um software necessita de recursos computacionais para que possa desempenhar 
suas funções, ou seja, ele precisa de dispositivos físicos para operar. Para isso, 
precisamos definir quais restrições e qual poderá ser o limite de alcance que o 
software que está sendo desenvolvido poderá vir a ter. Um requisito não lista 
apenas uma funcionalidade, ele traz especificações também, de como deve 
agir para que o objetivo de sua função seja atingido.
Dessa forma, separamos as necessidades do cliente, ou seja, de seu software, 
em duas modalidades, que chamamos de requisitos funcionais e não funcionais:
1. Requisitos funcionais (RF ou, em inglês, FR, de functional requirement): 
“São declarações de serviços que o sistema deve fornecer, de como o 
sistema deve reagir a entradas específicas e de como o sistema deve 
se comportar em determinadas situações. Em alguns casos, também 
podem explicitar o que o sistema não deve fazer” (SOMMERVILLE, 
2011, p. 59). 
2. Outros aspectos que norteiam os requisitos funcionais estão ligados à 
completude, ou seja, se todos as funcionalidades estão definidas, ao 
realismo quanto à definição das funcionalidades e à consistência, na 
qual os requisitos não devem trazer ambiguidade ao projeto.
3. Requisitos não funcionais (RNF ou, em inglês, NFR, de non functional 
requirement): “Pode ser descrito como um atributo de qualidade, de 
desempenho, de segurança ou como uma restrição geral em um sistema” 
(PRESSMAN; MAXIM, 2016, p. 141). Esses requisitos abrangem muito 
mais atributos, que podem estar associados a outras áreas do software.
Conhecer requisitos4
4. Para Sommerville (2011, p. 60), esses requisitos podem “estar relaciona-
dos às propriedades emergentes do sistema, como confiabilidade, tempo 
de resposta, e ocupação de área. [...] Os requisitos não funcionais, como 
desempenho, proteção ou disponibilidade, normalmente especificam 
ou restringem as características do sistema como um todo. [...] Esses 
requisitos podem afetar a arquitetura geral de um sistema em vez de 
apenas componentes individuais”. A Figura 1 a seguir traz um diagrama 
com alguns dos requisitos não funcionais.
Figura 1. Tipos de requisitos não funcionais.
Fonte: Sommerville (2011, p. 61)
Requisitos
não funcionais
Requisitos
de produto
Requisitos
organizacionais
Requisitos
externos
Requisitos
de e�ciência
Requisitos de
con�abilidade
Requisitos de
portabilidade
Requisitos de
interoperabilidade
Requisitos
éticos
Requisitos de
facilidade de uso
Requisitos
de entrega
Requisitos de
implementação
Requisitos
de padrões
Requisitos
legais
Requisitos de
desempenho
Requisitos
de espaço
Requisitos
de privacidade
Requisitos
de segurança
O diagrama desenvolvido por Sommerville (2011, p. 61) expõe requisitos 
não funcionais que podem ser provenientes das característicasrequeridas para 
o software (requisitos do produto), da organização que desenvolve o software 
(requisitos organizacionais) ou de fontes externas:
 � Requisitos do produto: “Requisitos que especificam ou restringem o 
comportamento do software. Exemplos incluem os requisitos de de-
sempenho quanto à rapidez com que o sistema deve executar e quanta 
memória ele requer, os requisitos de confiabilidade que estabelecem 
5Conhecer requisitos
a taxa aceitável de falhas, os requisitos de proteção e os requisitos de 
usabilidade”.
 � Requisitos organizacionais: “São os requisitos gerais de sistemas de-
rivados das políticas e procedimentos da organização do cliente e do 
desenvolvedor. Exemplos incluem requisitos do processo operacional, 
que definem como o sistema será utilizado, dentre outros”.
 � Requisitos externos: “Abrangem todos os requisitos que derivam de fa-
tores externos ao sistema e seu processo de desenvolvimento. Exemplos 
incluem requisitos reguladores, que definem o que deve ser feito para 
que o sistema seja aprovado para uso, dentre outros”.
O detalhamento e as demais especificações acerca de cada vertente de um 
requisito, seja ele funcional ou não funcional, são descritos em uma docu-
mentação, que deve ser bastante detalhada e concisa. É nessa documentação 
que todas as práticas de levantamento de requisitos que foram utilizadas irão 
mostrar presteza para todo o processo. Outro fator importante é o de conhe-
cermos também as regras de negócio que devem ser inseridas no sistema.
Este link traz um vídeo desenvolvido por Fabrício Laguna 
(2016), que apresenta um breve resumo sobre os requisitos, 
assunto em destaque neste capítulo.
https://goo.gl/mh8orc
Identificação das regras de negócio
A identificação das regras de negócio que fazem parte do contexto do projeto 
compartilham das mesmas técnicas da coleta de dados, até mesmo porque é 
o momento em que os dados estão sendo coletados e as restrições do sistema 
estão sendo impostas, automaticamente, em que é necessário se ter conheci-
mento, também, das regras de negócio do cliente.
Conhecer requisitos6
O entendimento dessas regras deve ser exposto em um modelo de negócio, 
pois “é ele que gera um entendimento do negócio do cliente como um todo. 
Com esse conhecimento, os desenvolvedores poderão aconselhá-lo sobre 
quais partes de seu negócio eles deveriam informatizar. De modo alternativo, 
se a tarefa for estender um produto de software existente, os desenvolvedores 
terão de entender o negócio existente como um todo para determinar como 
incorporar a extensão e aprender quais partes, se realmente alguma, do pro-
duto existente precisam ser modificadas para acrescentar o novo trecho” 
(SCHACH, 2010, p. 288).
Ainda sob o ponto de vista de Schach (2010, p. 288), “para construir um 
modelo de negócio, o desenvolvedor precisa ter um entendimento detalhado 
dos diversos processos de negócio. Tais processos serão refinados, isto é, 
analisados de forma mais detalhada. Podem ser usadas várias técnicas dife-
rentes para obter as informações necessárias para criar o modelo de negócio, 
principalmente entrevistas”.
Além das possibilidades citadas no início deste capítulo, podemos acres-
centar o uso de formulários e questionários no processo de levantamento de 
requisitos e, consequentemente, das regras de negócio. De acordo com Morgan 
(2001 apud ALVARENGA, 2007), a definição de uma regra de negócio requer 
a especificação de alguns detalhes operacionais, dentre os quais podemos 
destacar:
 � Quem invoca uma regra: esta informação geralmente é descrita em um 
caso de uso ou em uma descrição de processo do negócio.
 � Quando a regra é executada: normalmente isto é descrito por um evento, 
caso de uso ou descrição de processo do negócio.
 � Onde a regra é executada: esta decisão é pertinente ao design do sistema 
e, mais especificamente, ao empacotamento do software.
 � Como a regra é implementada: também é uma decisão da fase de projeto.
Conforme Alvarenga (2007, p.21), uma característica comum às regras de 
negócio é que elas fazem uso dos chamados “parâmetros do negócio”. Tais 
parâmetros podem ser definidos e gerenciados da mesma forma que as regras 
de negócio (MORGAN, 2001, apud ALVARENGA, 2007). O Quadro 1 traz 
características das Regras de Negócios encontradas na prática em muitas 
organizações, de acordo com Morgan (2001).
7Conhecer requisitos
Fonte: Alvarenga (2007, p. 21)
Característica: 
Uma RN deve ser ... Justificativa
Atômica Caso uma regra seja definida em termos de subunidades, 
estas subunidades não serão a mesma RN original. Isto 
quer dizer que a tentativa de dividir um RN em outras 
regras mais simples resultará em perda de informação e 
também em perda semântica.
Declaração do 
negócio
RN deveriam descrever a lógica do negócio e não a 
tecnologia que irá implementar a regra.
Declarativa RN devem contribuir para um objetivo do negócio, ao 
invés de descrever como o objetivo do negócio será 
alcançado.
Restritiva RN limitam as ações que podem ser aplicadas no contexto 
do negócio.
Representada em 
linguagem natural
RN devem ser expressas através de idioma natural, pois 
isto dispensa qualquer tipo de treinamento específico ou 
uso de ferramentas. Em contrapartida, podem ocorrer 
expressões ambíguas. Em consequência disso, torna-se 
necessário mapear as regras escritas em linguagem 
natural para uma expressão matemática for mal, como 
uma linguagem de programação, por exemplo.
Rastreável É precisa saber com as RN se encaixa dentro de um SI, 
e rastreá-las desde a origem até as suas realizações para 
manter o acompanhamento de todo o ciclo de vida do SI.
Estruturada As regras devem ser escritas de tal maneira que facilitem 
a leitura e o entendimento. Porém, é necessário restringir 
o número de opções para se escrever a regra, isto é, 
determinar padrões estruturais para representação 
de regras. Esta prática pode apoiar o processo de 
automatização da regra, ou seja, o mapeamento da regra 
para implementação desejada.
Quadro 1. Características das Regras de Negócio.
Conhecer requisitos8
Podemos notar que cada detalhe é descrito juntamente com suas par-
ticularidades e pode ser inserida a documentação do projeto por um meio 
específico, seja por um diagrama, ou por uma descrição textual. As regras de 
negócio, assim como as demais informações de um software, visam a trazer 
o desenvolvimento correto de um sistema de informação.
ALVARENGA, G. G. Uma abordagem para tratamento de regras de negócio em sistemas 
de informação. 149 f., 2007,. Dissertação (Mestrado em Informática) - Universidade 
Federal de Goiás, Goiânia, 2007. Disponível em: <http://www.inf.ufg.br/sites/portal.
inf.ufg.br.mestrado/files/ds_Geoflavia.pdf>. Acesso em: 27 ago. 2017.
LAGUNA, F. Gerenciamento de requisitos sem mistério. YouTube, 2016. Disponível 
em: <https://www.youtube.com/watch?v=jajQyzOpLaE>. Acesso em: 27 ago. 2017.
MORGAN, T. Business Rules and Information Systems: aligning IT with Business Goals. 
Boston: Addison Wesley, 2001.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
SCHACH, S. R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 
7. ed. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
9Conhecer requisitos
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra.
 
Conteúdo:
DICA DO PROFESSOR
Neste vídeo você irá conhecer o conceito de requisitos de software, seus tipos e características. 
Você também irá conhecer os principais problemas enfrentados durante a coleta de requisitos.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) O que é um requisito de software? 
A) Um requisito pode ser definido como uma condição ou uma capacidade com a qual o 
sistema deve estar de acordo.
B) É uma declaração sobre políticas oucondições que devem ser satisfeitas.
C) É uma técnica para a medição de projetos de desenvolvimento de software, visando 
estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a 
funcionalidade implementada, sob o ponto de vista do usuário.
D) É uma técnica de desenvolvimento de software em que se utiliza camadas.
E) É um conjunto de elementos que um software entrega, podendo ser dados ou valores.
2) Qual é a característica de um requisito funcional? 
A) Definem propriedades e restrições do sistema.
B) Descrevem explicitamente as funcionalidades e serviços do sistema.
C) É mais voltado para características que podem ser mensuradas e testadas facilmente.
D) Expressam informações relacionadas com a segurança do sistema.
E) Expressam informações relacionadas com a arquitetura do sistema.
3) Qual é a característica de um requisito não funcional? 
A) É um tipo de requisito que o usuário geralmente conhece bem.
B) É um tipo de requisito fácil de estimar.
C) É um tipo de requisito que define propriedades e restrições do sistema. É mais voltado para 
características que podem ser mensuradas e testadas facilmente.
D) É um tipo de requisito que geralmente descreve explicitamente as funcionalidades e 
serviços do sistema.
E) É um tipo de requisito que é flexível e não impacta no desenvolvimento.
4) O que é uma regra de negócio? 
A) Regras de negócio são premissas e restrições aplicadas a uma operação comercial de uma 
empresa, que precisam ser atendidas para que o negócio funcione da maneira esperada.
B) Definem propriedades e restrições do sistema.
C) É um tipo de requisito que geralmente descreve explicitamente as funcionalidades e 
serviços do sistema.
D) É um requisito que o usuário não conhece muito bem durante a criação de um sistema.
E) É um tipo de requisito difícil de estimar.
5) Na engenharia de software, existe um processo genérico de levantamento e análise 
que contém as seguintes atividades: compreensão do domínio, coleta de requisitos, 
classificação, resolução de conflitos, definição das prioridades e verificação de 
requisitos. Uma das atividades mais importantes deste processo é a coleta de 
requisitos. Informe quais das descrições a seguir melhor descrevem esta atividade: 
A) Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em 
grupos coerentes.
B) Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa 
atividade tem por objetivo solucionar esses conflitos.
C) Nesta atividade, os requisitos são verificados para descobrir se estão completos e 
consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
D) Em qualquer definição de requisitos, alguns serão mais importantes do que outros. Esse 
estágio envolve interação com os stakeholders para a definição dos requisitos mais 
importantes.
E) É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos.
NA PRÁTICA
Ao reconhecer um requisito de software, devemos ter atenção para descrevê-lo de maneira clara. 
Lembre-se que um bom requisito especifica claramente algo que é necessário, verificável ou 
atingível no sistema.
Observe a seguinte descrição de um sistema:
Conteúdo interativo disponível na plataforma de ensino!
 
Este é um exemplo de descrição do negócio de uma farmácia e seu escopo, e também os 
requisitos funcionais e não funcionais coletados para criar este sistema. Com esta lista de 
requisitos, o engenheiro de software pode documentá-los e detalhar melhor o que cada um 
significa e como será trabalhado durante o desenvolvimento do sistema.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Os requisitos de software podem ser divididos em requisitos funcionais, não funcionais e 
regra de negócio. Para saber mais sobre requisitos de software, acesse a próxima dica de 
leitura.
Conteúdo interativo disponível na plataforma de ensino!
Seleção de técnicas de elicitação de 
requisitos de software
APRESENTAÇÃO
Muitos projetos da área de Tecnologia da Informação falham devido a requisitos mal 
identificados ou mal compreendidos. Mas quais são as consequências destas falhas? É possível 
comparar os requisitos de software aos alicerces de uma casa. Quando a estrutura de uma casa é 
malfeita, todo o resto da construção fica comprometida, podendo, inclusive, levar à queda da 
edificação.
No desenvolvimento de software isso não é diferente. Os requisitos são a base para todas as 
demais etapas do desenvolvimento. Se forem mal compreendidos e mal definidos, estes 
problemas se propagarão para todas as atividades, levando, no mínimo, ao retrabalho. Além do 
retrabalho, o não cumprimento dos requisitos pode acarretar prejuízos ainda mais significativos, 
como a perda da credibilidade da empresa no mercado, prejuízos financeiros e, em alguns casos, 
até mesmo a perda de vidas humanas.
Por este motivo, é importante focar grande parte dos esforços de desenvolvimento em elicitar 
adequadamente os requisitos para que estes possam constituir uma base sólida para o 
desenvolvimento de software.
Nesta Unidade de Aprendizagem, você aprenderá a identificar a fonte dos requisitos, ou seja, de 
onde o Analista de Requisitos obtém as informações para que possa gerar os requisitos de 
software. Aprenderá, ainda, as características das principais técnicas que podem ser utilizadas 
para elicitar os requisitos. Por fim, irá compreender como selecionar a técnica de acordo com as 
características do contexto.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Identificar as fontes de informação de requisitos dos projetos de software.•
Reconhecer as características das técnicas de elicitação de requisitos dos projetos de 
software.
•
Selecionar a técnica de elicitação de requisitos de acordo com as características do projeto.•
DESAFIO
Elicitar requisitos é uma atividade essencial para o sucesso de qualquer projeto que envolve 
software. De acordo com as características do contexto, uma técnica pode ser mais adequada do 
que outra. Saber selecionar e combinar as melhores técnicas de elicitação de requisitos pode 
reduzir significativamente a quantidade de problemas relacionados a eles, como requisitos 
incompletos, inconsistentes e invisíveis.
Imagine que você é Analista de Requisitos na área de Tecnologia da Informação de uma 
empresa que comercializa planos de saúde.
Conteúdo interativo disponível na plataforma de ensino!
Com base nas informações fornecidas pela empresa, decida quais técnicas de elicitação de 
requisitos você irá adotar, levando em consideração as características do contexto e os 
problemas apontados.
INFOGRÁFICO
A etapa de elicitação dos requisitos é uma das mais críticas no processo de desenvolvimento de 
software, independentemente se a equipe está utilizando métodos tradicionais ou inovadores. 
Compreender os serviços e funções que o software deve disponibilizar é a base para todas as 
demais atividades, inclusive para a etapa de implementação.
A elicitação tem início a partir da compreensão do cenário de negócio no qual o software está 
inserido e da identificação das fontes que servirão de base para a coleta de informações. Dessa 
forma, a seleção e correta aplicação da técnica minimizarão os riscos de surgimento tardio de 
requisitos invisíveis ou esquecidos.
Confira neste Infográfico as etapas para a realização da elicitação de requisitos em projetos de 
software.
CONTEÚDO DO LIVRO
As consequências da condução inadequada da etapa de elicitação de requisitos em projetos de 
software são inquestionáveis e bem conhecidas. Muitas pessoas que trabalham com 
desenvolvimento de software já passaram pela frustração de verem seus projetos atrasarem, 
serem replanejados e até mesmo cancelados por conta de requisitos que não foram 
adequadamente identificados, compreendidose documentados. Muitas vezes isto ocorre porque 
a pessoa responsável pela etapa de elicitação de requisitos esqueceu algum stakeholder 
importante, não sabia que existia alguma regulamentação à qual o software deveria ser aderente 
ou mesmo porque desconhecia a melhor técnica de elicitação a ser aplicada naquela situação.
No capítulo Seleção de Técnicas de Elicitação de Requisitos, do livro Engenharia de Requisitos, 
base teórica desta Unidade de Aprendizagem, você irá aprender a identificar as fontes de 
informação a partir das quais pode-se obter os requisitos de um projeto de software. Você 
também vai conhecer as técnicas de elicitação de requisitos e suas principais características e , 
por fim, aprenderá a selecionar a técnica mais adequada para elicitar requisitos, de acordo com 
as características da técnica e do contexto.
Boa leitura.
ENGENHARIA DE 
REQUISITOS
Sheila Reinehr
Seleção de técnicas de 
elicitação de requisitos 
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar fontes de informação de requisitos de projetos de software.
 � Reconhecer as características das técnicas de elicitação de requisitos 
de projetos de software.
 � Selecionar a técnica de elicitação de requisitos de acordo com as 
características do projeto.
Introdução
À medida que a tecnologia faz cada vez mais parte de nossas atividades 
cotidianas, cresce nossa dependência do correto funcionamento de 
dispositivos e softwares neles contidos. Utilizamos nossos smartphones 
para apoiar a maioria das nossas atividades pessoais e profissionais, desde 
consultar como está o trânsito no caminho para a faculdade ou o trabalho 
até checar a temperatura para escolher a roupa adequada ou consultar a 
conta para ver se o pagamento entrou. Não admitimos mais que os bancos 
não tenham todos os serviços on-line ou que tenhamos que nos deslocar 
até a pizzaria para buscar o lanche. Temos tudo na ponta dos dedos!
Para que essas facilidades nos alcancem na forma de funcionalidades 
nos aplicativos do celular ou nos sites na internet, muita coisa precisa 
acontecer antes. São necessários profissionais com diversas habilidades 
e competências, esforço conjunto e horas de desenvolvimento e testes. 
Em algum momento, pessoas criaram esses serviços. 
De onde saem as ideias para essas funcionalidades? Quem define 
o que um sistema deve executar e como deve executar? Como se faz 
para obter essas definições? A resposta é: depende! Depende do tipo 
de software, do contexto em que o projeto está sendo desenvolvido, 
da tecnologia e dos recursos disponíveis. Há casos em que é possível 
conversar com alguém responsável por essas definições e há casos em 
que é a lei que determina o que o software deve fazer. Para cada produto 
existem também diversos olhares e perspectivas vindos das partes en-
volvidas. Para cada caso existe uma forma mais adequada de descobrir 
os requisitos de um produto de software.
Neste capítulo você vai estudar a identificação das fontes de infor-
mação dos requisitos de um projeto de software em função do tipo de 
projeto e seu contexto. Vai também conhecer as diversas técnicas para 
a elicitação de requisitos e quando elas melhor se aplicam, de modo a 
escolher a melhor técnica para cada contexto de desenvolvimento de 
software.
1 Quais são as fontes de informação 
dos requisitos?
Existem diferentes tipos de produtos de software; cada um implica dife-
rentes tipos de requisitos e, portanto, diferentes fontes de informação para 
a obtenção desses requisitos. Sistemas de informação que apoiam as áreas 
administrativas de uma empresa são diferentes de jogos de celular, que, por 
sua vez, são diferentes de um sistema de controle de tráfego aéreo, que são 
diferentes de um sistema de troca de mensagens. As particularidades de cada 
tipo de produto e de cada contexto de projeto influenciarão na identificação 
das fontes de informação.
Quando falhamos em identificar adequadamente as fontes de informação, 
podemos ter, como consequência, usuários esquecidos e, portanto, não ouvidos, 
ou requisitos que surgem quando a entrega do produto está sendo realizada. 
Portanto, quanto melhor for a nossa capacidade de envolver todas as fontes, 
maior será a chance de sucesso do projeto.
No início de um projeto, diversos stakeholders têm um papel importante 
para determinar variáveis que influenciarão o seu desenvolvimento. Alguns 
poderão definir requisitos de projeto, como orçamento, prazos, premissas, 
Seleção de técnicas de elicitação de requisitos de software2
restrições e escopo. Geralmente, esses são os clientes, investidores, gestores 
ou o próprio gerente do projeto. Outros, serão responsáveis por determinar 
requisitos de processo, que influenciarão a forma como a equipe de desenvol-
vimento irá trabalhar. Esses podem ser externos à organização desenvolvedora, 
como o próprio cliente ou investidor, ou podem ser internos à organização, 
como a área de processos ou de compliance. E haverá um conjunto deles 
que definirá efetivamente os requisitos do produto de software, sejam os 
funcionais (“o que” o sistema deve fazer), sejam os não funcionais (“como” 
o sistema deve fazer). Esses stakeholders são provenientes das mais variadas 
áreas, como veremos a seguir.
Tipos de fonte de informação
Existem diversas classificações para os tipos de fonte de informação, como 
veremos a seguir. Pohl e Rupp (2015) definem basicamente os três tipos lis-
tados a seguir.
 � Stakeholders: são pessoas ou organizações que influenciam direta ou 
indiretamente nos requisitos do sistema, como usuários, operadores do 
sistema, desenvolvedores, arquitetos, clientes e testadores. 
 � Documentos: contêm informações importantes que podem se tornar 
requisitos, como documentos de ordem legal ou regulatória, normas e 
padrões, documentos específicos do domínio de negócio ou da própria 
empresa, como documentos de requisitos de mais alto nível ou docu-
mentos de erros em sistemas legados, por exemplo.
 � Sistemas em operação: sistemas legados, predecessores ou mesmo 
concorrentes. Os sistemas podem ser a fonte de informações sobre 
novas funcionalidades desejadas pelos clientes.
Outra forma de compreender as fontes de informação é a proposta por 
Wiegers e Beatty (2013), que utilizam o conceito de classes de usuários 
para designar um subconjunto de usuários que utilizam as mesmas funções 
ou serviços do sistema. Essas classes representam também um indicativo da 
prioridade que será dada aos requisitos. Eles apresentam uma hierarquia para 
favorecer o entendimento dos conceitos, conforme ilustra a Figura 1.
3Seleção de técnicas de elicitação de requisitos de software
Figura 1. Hierarquia de stakeholders, clientes, usuários e classes de usuários.
Fonte: Adaptada de Wiegers e Beatty (2013).
Stakeholders
Clientes
Usuários diretos 
e indiretos
Classes de
usuários
favorecidos
Classes de
usuários não
favorecidos
Classes de
usuários
ignorados
Outras classes
de usuários
Outros clientes
Outros 
stakeholders
Como se pode observar nessa proposta, os autores utilizam as seguintes 
definições:
 � Classes de usuários favorecidos: são aqueles usuários que estão mais 
diretamente relacionados com a satisfação dos objetivos de negócio 
do sistema e, portanto, seus requisitos terão maior prioridade do que 
outros requisitos.
 � Classes de usuários não favorecidos: são usuários que não devem 
utilizar o produto, por razões legais, de segurança ou proteção, e que, 
portanto, devem ser impedidos de fazê-lo por meio de funcionalidades 
implementadas com essa finalidade (como hackers, por exemplo).
 � Classes de usuários ignorados: são usuários que podem utilizar o 
produto, porém não são a razão de existir do produto e os seus requisitos 
terão menor prioridade.
 � Outras classes de usuários: outros usuários que não sejam os ante-
riormente mencionados e que terão igual prioridade na definição de 
requisitos.
Seleção de técnicas de elicitação derequisitos de software4
É importante lembrar que, no momento da identificação das fontes de in-
formação, todos os potenciais stakeholders precisam ser considerados, mesmo 
aqueles que não utilizarão diretamente as funcionalidades do produto. Por 
exemplo, há usos indiretos, como aqueles representados por outros softwares, 
que podem receber informações a partir do software que está sendo desenvol-
vido, ou mesmo aqueles softwares que realizam funções de forma automática, 
representando humanos, como os bots. A equipe de desenvolvimento também 
pode ter requisitos não funcionais relacionados, especialmente, à parte interna 
do sistema, como portabilidade, manutenibilidade, reusabilidade etc. O usuário 
que utiliza uma funcionalidade do sistema provavelmente não se preocupa 
com a sua arquitetura interna, mas, para a equipe que será responsável pela 
manutenção do produto, esses requisitos são relevantes e influenciarão na 
forma como o produto será concebido e desenvolvido.
Em métodos ágeis como o SCRUM, adota-se o papel do product owner (dono do 
produto), que é responsável por gerenciar o product backlog (backlog do produto). 
Suas principais atribuições relacionam-se à responsabilidade pelo gerenciamento 
das prioridades do backlog, bem como garantir que a equipe de desenvolvimento 
tenha compreendido adequadamente o significado de cada item do backlog (SCHWA-
BER; SUTHERLAND, 2013). Nesses casos, é função do product owner convergir para 
uma visão consolidada dos requisitos entre os interesses dos múltiplos stakeholders 
(LEFFINGWELL, 2011).
O grau de envolvimento dos stakeholders pode variar de acordo com as 
diferentes necessidades em relação ao projeto e aos requisitos. Leffingwell 
(2011) classifica esse envolvimento da seguinte forma:
 � Stakeholders que devem ser mantidos informados: são aqueles que 
precisam saber do status do projeto e precisam ser mantidos informados 
acerca das decisões, embora nem sempre tomem parte dessas decisões.
 � Stakeholders que devem ser consultados: são aqueles que precisam 
ser envolvidos devido às suas áreas de expertise, como arquitetos, 
projetistas de interface, marketing e especialistas do domínio. Eles 
devem ser incluídos nas decisões que envolvem a sua área de expertise. 
5Seleção de técnicas de elicitação de requisitos de software
 � Stakeholders que serão parceiros no desenvolvimento: são aqueles 
que precisam ser envolvidos por serem parceiros no processo, como os 
product owners de outros projetos, outras equipes de desenvolvimento, 
analistas de negócios ou requisitos e provedores de soluções com as 
quais o sistema deve interagir.
 � Stakeholders que controlam os resultados: são aqueles que tomam 
as decisões sobre a solução, como executivos, gerentes de liberação, 
usuários-chave que vão utilizar a solução e business owners.
Independentemente de como os stakeholders são classificados, é importante 
que a origem dos requisitos esteja clara e que os potenciais stakeholders sejam 
envolvidos logo no início do processo de elicitação de requisitos. Segundo 
Wiegers e Beatty (2013), a voz do cliente precisa chegar aos ouvidos dos de-
senvolvedores. Para que isso seja possível, é necessário que seja identificado 
corretamente quem precisa ter voz no projeto. Todas as classes de usuários 
precisam ter alguém que fale por elas.
Pohl e Rupp (2015) sugerem que seja mantida uma lista sempre atualizada com esses 
envolvidos. Eles argumentam que, caso a lista esteja incompleta ou exista algum 
stakeholder que seja identificado tardiamente, as consequências negativas para 
o projeto são certas: aspectos importantes podem permanecer não detectados, 
o objetivo do projeto pode se perder ou custos adicionais podem surgir para a correção 
dos problemas (retrabalho).
Como descobrir as fontes de informação
Para descobrir quais são as fontes de informação dos requisitos, um bom 
começo é conversar com o patrocinador do projeto para que ele identifique as 
áreas de negócios que terão alguma interface com o negócio que está sendo 
tratado pelo software, bem como identifique possíveis leis ou regulamentações 
que precisam ser atendidas. A partir daí podem surgir inúmeras potenciais 
fontes de informação que, posteriormente, serão agrupadas dentro de uma 
mesma classe, uma vez que tenham os mesmos interesses ou que utilizem as 
mesmas funcionalidades.
Seleção de técnicas de elicitação de requisitos de software6
Para apoiar a identificação dos stakeholders externos e internos, Leffin-
gwell (2011) recomenda que sejam feitas perguntas como as apresentadas no 
Quadro 1.
Fonte: Adaptado de Leffingwell (2011).
Stakeholders externos Stakeholders internos
 � Quem utilizará diretamente o 
sistema?
 � Quem utilizará os resultados 
daqueles que usam o sistema?
 � Quem será responsável por dar 
suporte ao sistema?
 � Com quais outros sistemas o nosso 
sistema irá interagir?
 � Que interfaces devem ser 
fornecidas?
 � Quem pode fornecer orientações 
sobre as funcionalidades e os 
itens de qualidade do sistema 
(usabilidade, confiabilidade, 
desempenho e manutenibilidade)?
 � Quem precisa ser consultado sobre 
o escopo do projeto?
 � Quem contribuiu para o 
orçamento e o cronograma?
 � Quem gerencia o relacionamento 
de negócios entre as equipes e o 
cliente?
 � Quem irá determinar como 
e quando o sistema deve ser 
entregue para os clientes?
 � Quem pode afetar ou apoiar 
politicamente o projeto?
 � Que parceiros dependem do 
sistema?
 � Quem se preocupa com o 
processo que será usado no 
desenvolvimento do sistema?
Quadro 1. Questões de apoio para identificar fontes de informação
Leffingwell (2011) sugere que, para determinados casos, seja utilizado o 
mapeamento de personas. Uma persona primária pode ser entendida como 
alguém que interage com o software e que necessita de uma interface projetada 
especificamente para ela. Uma persona secundária é um usuário que utiliza o 
software com uma interface projetada para outro tipo de usuário. Mapear uma 
persona significa caracterizar um representante hipotético, genérico, de uma 
classe de usuários. Personas devem ser caracterizadas considerando caracte-
rísticas e comportamentos sociais e demográficos, preferências, preocupações 
e informações similares (WIEGERS; BEATTY, 2013).
7Seleção de técnicas de elicitação de requisitos de software
2 Técnicas de elicitação de requisitos
O ponto mais crítico da engenharia de requisitos é a elicitação. Podemos 
dizer que ela é o coração do desenvolvimento de requisitos (WIEGERS; 
BEATTY, 2013). Não se trata apenas de perguntar o que um grupo de usuários 
deseja, mas, sim, de investigar, instigar, questionar, descobrir, explorar — 
em resumo, extrair. Não se trata de apenas transcrever o que o usuário relata em 
uma conversa, mas sim de explorar, de forma colaborativa, todos os aspectos 
necessários para o entendimento correto do requisito. É um constante exercício 
de: “e se…”, traduzido como: “e se acontecer tal coisa, como o sistema deve 
reagir?”; “e se não acontecer tal coisa, como o sistema deve tratar?”.
Lembre-se, no entanto, de que a tarefa de elicitação de requisitos não é 
trivial. Os usuários nem sempre sabem explicar as suas tarefas, podem es-
quecer ou deixar informações importantes de lado ou podem simplesmente 
não estar disponíveis ou não quererem prestar informações (BOURQUE; 
FAIRLEY, 2014). É função do analista de requisitos obter o engajamento 
necessário para que essa atividade ocorra adequadamente, gerando a base para 
as demais atividades do ciclo de desenvolvimento de software. Para que isso 
seja possível, é necessário selecionar a técnica de elicitação mais apropriada 
para cada situação específica.
Uma técnica de elicitação de requisitos pode ser compreendida como 
uma ferramenta para auxiliar o analista de requisitos na condução da etapa 
de elicitação e compreensão dos requisitos do software. Existem diversas 
técnicas disponíveis; algumas implicam a interação direta com um stakeholder 
humano, enquanto outras se aplicama outros tipos de fontes de informação.
Independentemente da técnica selecionada, as seguintes etapas de prepa-
ração são necessárias:
 � Identificação das fontes de informação: identificação das pessoas com 
competência para prestar a informação, bem como das demais fontes 
de informação, como documentos, elementos multimídia, softwares 
etc., conforme detalhado na seção anterior.
 � Familiarização com o assunto: buscar conhecer, antecipadamente, 
as terminologias e os jargões da área de negócio que está sendo tratada, 
bem como os conceitos-chave do negócio. Pesquisas em documentos 
do domínio ou uma busca rápida na web podem ajudar.
Seleção de técnicas de elicitação de requisitos de software8
 � Identificação dos objetivos: identificar claramente os objetivos da 
elicitação, o nível de informação, os tópicos principais, a relevância, 
a precedência e as prioridades.
 � Elaboração do cronograma: elaborar com antecedência o cronograma 
de atividades necessárias, visando à divulgação dos objetivos e infor-
mações logísticas (local, data, horário, materiais necessários).
 � Identificação dos riscos na elicitação: identificar e documentar os 
possíveis riscos envolvidos na elicitação de requisitos e as ações que 
serão adotadas para preveni-los ou mitigá-los.
Neste capítulo, iremos abordar as seguintes técnicas, que envolvem a 
interação direta ou indireta com fontes de informação humanas:
 � entrevista;
 � reunião;
 � brainstorming;
 � observação;
 � questionário.
Ao final da seção, também abordaremos outras técnicas de elicitação que 
não envolvem stakeholders humanos.
Entrevista
Uma das formas mais usuais de se realizar a elicitação de requisitos a partir de 
fontes humanas é a entrevista. Trata-se de uma conversa entre duas pessoas, 
provocada por uma delas, com um objetivo definido. A entrevista proporciona 
o contato pessoal, que faz com que o entrevistado se sinta parte do processo 
de construção da solução.
A entrevista facilita a obtenção de informações que, muitas vezes, estão 
apenas na memória das pessoas, além de informações a respeito dos integrantes 
da unidade, como suas qualificações, atribuições, utilização de processos, bem 
como opiniões sobre a unidade e o trabalho. Se uma boa relação é estabelecida 
com o entrevistado ou com um pequeno grupo de entrevistados, eles podem 
se sentir mais seguros para falar sobre questões mais delicadas do que em um 
grupo maior (WIEGERS; BEATTY, 2013).
9Seleção de técnicas de elicitação de requisitos de software
Como qualquer outra técnica, a entrevista exige uma preparação por 
parte do entrevistador. É recomendado que ele prepare uma lista de questões 
mais abrangentes no início e que, progressivamente, ficam mais detalhadas. 
As questões devem seguir uma ordem lógica e abordar um assunto de cada vez. 
O roteiro com as questões deve servir apenas para guiar e orientar o processo 
de entrevista, ele não deve ser usado de forma restritiva, pois a riqueza do 
processo de entrevista está justamente no oposto. O entrevistador tem que 
dar espaço para que o entrevistado possa se manifestar livremente sobre seus 
anseios em relação à solução que está sendo desenvolvida.
A entrevista pode não obter os resultados desejados, caso ocorra uma das 
seguintes situações:
 � falta de preparo do condutor da entrevista;
 � falta de preparo do entrevistado;
 � tendência do entrevistado em dar respostas agradáveis;
 � tendência do entrevistado em focar em palpites ou em respostas falsas;
 � resistência do entrevistado com declarações do tipo “não sei”, “não 
conheço”.
Veja aqui algumas dicas adicionais para a condução de entrevistas para a elicitação 
de requisitos:
 � conquiste a confiança do entrevistado se apresentando e explicando claramente 
a finalidade do encontro;
 � tome notas durante a entrevista ou grave-a (se o entrevistado permitir);
 � se possível, utilize o papel do redator (liberando você para focar na conversa com 
o entrevistado);
 � deixe para analisar criticamente depois (não corrija falhas, faça críticas ou discuta);
 � inicie com questões mais abertas, tipo “como é o trabalho que você realiza?”;
 � evite termos muito técnicos e tente se aproximar do jargão da área;
 � evite perguntas com respostas apenas do tipo “sim” ou “não”, que podem limitar 
a participação do entrevistado;
 � se a entrevista se desviar, reconduza, com habilidade, para o fim programado;
 � se o entrevistado se recusar a fornecer dados, obtenha a cooperação de outros 
colegas em papel similar ou, em último caso, do superior hierárquico do entrevistado;
 � esclareça as possíveis preocupações por parte do entrevistado;
 � dê abertura para novos contatos, da sua parte e da parte do entrevistado;
 � valide as informações obtidas com relação ao objetivo previamente estipulado.
Seleção de técnicas de elicitação de requisitos de software10
Embora a entrevista geralmente seja conduzida de forma presencial, hoje 
já é muito comum que ela também seja realizada on-line, usando ferramentas 
de comunicação. O único cuidado é garantir que a tecnologia de suporte 
(ferramenta, rede, internet) funcione adequadamente, evitando as interrupções, 
que prejudicam o andamento da conversa. Interrupções por falha na tecnologia 
fazem com que se perca o ritmo da conversa e se gaste tempo para retomar 
ao ponto anterior.
Wiegers e Beatty (2013) ressaltam a importância de praticar a escuta ativa 
em todas as interações com os usuários. Isso significa manter uma postura 
corporal receptiva, ter paciência, dar feedback verbal e questionar pontos que 
não ficaram claros. Além disso, outra forma de demonstrar a escuta ativa é pa-
rafrasear o que o entrevistado disse, demonstrando que entendeu a mensagem.
Reunião
Outra forma bastante comum de elicitação de requisitos é a reunião. Uma 
reunião é o intercâmbio de ideias, sugestões e opiniões entre determinados 
indivíduos, visando à aceitação de um ponto de vista (esclarecimento, con-
clusão, decisão, linha de ação etc.) por parte dos participantes.
A reunião é uma comunicação direta entre os participantes e permite a 
integração do grupo em torno do mesmo assunto, formando uma equipe de 
trabalho. Ela é usada para a coleta de sugestões e críticas dos participantes 
(discussões, acertos, acordos e busca de consenso e alternativas); aglutinação e 
intercâmbio de experiências; e definição de problemas que devem ser tratados 
pela solução, explorando as suas causas e efeitos. Ela permite o envolvimento 
das pessoas para a tomada de decisão em grupo.
Assim como a entrevista, a reunião exige uma preparação por parte de quem 
vai conduzi-la. É preciso organizar a agenda dos tópicos que serão tratados, 
bem como o tempo estimado para discutir cada item. O ambiente no qual a 
reunião ocorrerá deve ser amplo, ventilado e iluminado. O espaço deve ser 
suficiente para acomodar todos os participantes. Material de apoio deve ser 
providenciado, como quadro branco e canetas para anotações, computador, 
projetor, tela de projeção e demais materiais de escritório.
11Seleção de técnicas de elicitação de requisitos de software
A reunião tem estes três momentos:
 � Abertura: apresentação dos participantes, dos objetivos da reunião, 
das regras de condução e da duração prevista, bem como definição 
do redator da ata de reunião. Caso seja uma reunião de continuidade, 
a ata da reunião anterior deve ser lida e os pontos pendentes, tratados.
 � Abordagem dos tópicos: exposição dos problemas e/ou questões que 
se deseja resolver no decorrer da reunião; abertura da discussão e 
ponderação até a seleção da alternativa mais adequada; busca pela 
decisão consensual, evitando os conflitos.
 � Conclusão: definição de quem é responsável pelas ações decorrentes 
da reunião e como será retornado o feedback para os participantes.
Para que uma reunião com o objetivo de elicitação de requisitos seja bem-
-sucedida, é importante que o analista de requisitos que vai conduzi-la seja 
cuidadoso ao se preparar. Existem algumas recomendações quepodem ajudar:
 � encaminhe a agenda para os participantes com antecedência, para que 
possam se planejar (assunto, participantes, horário, local);
 � o término deve ocorrer exatamente na hora marcada, pois as pessoas 
têm outros compromissos profissionais e, principalmente, pessoais;
 � se necessário, faça a reunião em outro local, afastado do ambiente de 
trabalho, para evitar interrupções;
 � não defenda ao extremo os seus dados, prefira levar o grupo a deduzir 
que eles estão corretos a partir das informações objetivas;
 � não mostre contrariedade quando o grupo rejeitar suas ideias;
 � evite impasses, pois, em uma discussão, não devem existir vencedores 
nem derrotados — isso é péssimo para a continuidade do projeto;
 � não mude de opinião apenas para impedir o conflito, siga os seus ob-
jetivos com coerência;
 � encaminhe as decisões por meio de consenso, nunca por votação ou 
barganha;
 � ao concluir a reunião, agende data, horário e local da próxima, 
se necessário;
 � se possível, procure registrar os acontecimentos diretamente em uma 
ata ou memória da reunião e obtenha as assinaturas ao final da reunião, 
evitando assim questionamentos posteriores quanto ao seu conteúdo.
Seleção de técnicas de elicitação de requisitos de software12
Embora tudo tenha sido preparado com antecedência, alguns imprevistos 
podem acontecer e a reunião pode não ser bem-sucedida caso ocorra uma 
das seguintes situações:
 � se houver uma possível dominação da reunião por um só indivíduo, cujo 
talento, personalidade ou conhecimento inibem os demais participantes;
 � se houver conformidade de alguns participantes, aceitando a opinião 
da maioria para se sentirem parte do grupo ou para evitar o conflito 
(isso pode inibir soluções novas, arrojadas e diferentes);
 � se houver faltas, atrasos e saídas antecipadas;
 � se o ambiente físico for inadequado, levando ao desconforto ou distra-
ções (ambiente com muito barulho, por exemplo);
 � se houver participação de pessoas não relacionadas ao assunto, que não 
contribuem e ainda podem atrapalhar os resultados.
Veja aqui algumas dicas de perguntas para a condução de reuniões para a elicitação 
de requisitos:
 � Pergunta dirigida: pergunta dirigida especificamente a um participante. Ideal 
para lidar com pessoas tímidas. Por exemplo: “Gostaríamos de ouvir a opinião de 
Fulano sobre o assunto”; “Por favor, Sr. Fulano, poderia nos dizer alguma coisa?”. 
 � Pergunta geral: pergunta dirigida a todos os participantes, com a finalidade de 
estimular a discussão. É um meio de reanimar discussões que, repentinamente, 
esfriaram. Por exemplo: “Que mais poderíamos considerar a respeito do que foi 
exposto?”; “Que outras medidas poderiam ser tomadas nesse caso?”; “Que alter-
nativas vocês sugerem?”.
 � Pergunta redistribuída: pergunta que é retornada por quem a recebeu para um 
dos demais participantes ou a todo o grupo. Por exemplo: “É uma boa pergunta, 
como os senhores responderiam?”; “Ninguém melhor do que Fulano, que entende 
desse assunto, para responder a essa pergunta”.
 � Reversa: pergunta endereçada ao condutor, que a devolve a quem a formulou. 
Esse processo exige certo tato, porque pode gerar antagonismo ou embaraço no 
participante, que pode, receando que isso se repita, optar por não mais se manifestar.
13Seleção de técnicas de elicitação de requisitos de software
Brainstorming
O brainstorming consiste em uma “tempestade de ideias”, sem julgamentos 
ou análises, que ocorre em um ambiente descontraído e informal. Sentar-se 
sozinho ou com um amigo para pensar em uma nova ideia não é exatamente 
um brainstorming. A aplicação da técnica requer preparação e envolvimento 
de mais pessoas.
Inicialmente, deve ser selecionada uma dinâmica para o entrosamento 
dos participantes, que permita que o ambiente fique descontraído e propício 
à criatividade. É comum que seja alguma brincadeira simples, com cunho 
divertido, realizada em pé ou se movimentando. Esse aquecimento não deve 
tomar muito tempo do evento.
O material necessário para o brainstorming também deve ser providenciado 
com antecedência e pode ser constituído de notinhas adesivas coloridas (tipo 
Post-it) e canetas coloridas. A quantidade vai depender da quantidade de 
pessoas e dos objetivos do brainstorming. Lembre-se de que a base é a geração 
de muitas ideias, e cada uma deve ser escrita em uma notinha.
A seção de brainstorming é composta por três fases: aquecimento (com 
a dinâmica selecionada), ideação (com a geração das ideias) e encerramento 
(com o agrupamento das ideias). Opcionalmente, pode ser realizada, na última 
etapa, uma breve análise ou votação das melhores ideias.
Algumas questões devem ser observadas para que o brainstorming seja realizado 
com sucesso:
 � o brainstorming não se aplica a grupos muito fechados e formais;
 � o clima precisa ser descontraído e não pode haver críticas, julgamentos e gozações, 
pois isso inibe o fluxo de ideias;
 � quando o grupo for muito grande, o ideal é dividi-lo em subgrupos com não mais 
do que 8 pessoas cada (o número depende do contexto e dos perfis).
Seleção de técnicas de elicitação de requisitos de software14
Observação
Como o próprio nome sugere, esta é uma técnica na qual o analista de requi-
sitos vai a campo para poder observar como o trabalho ocorre. Esta técnica 
utiliza os sentidos na obtenção de determinados aspectos da realidade. Não 
consiste apenas em ver e ouvir, mas em examinar fatos ou fenômenos que se 
deseja estudar. 
A observação pode ser usada para confirmar informações obtidas das 
entrevistas, questionários ou documentos, comparando-as com a realidade. 
Pode-se levantar volumes, acessar outras fontes de informações (manuais de 
procedimentos etc.) e levantar o fluxo de documentos ao longo das tarefas. 
Ela é capaz ainda de ajudar a ter ideias sobre pontos nos quais o novo software 
pode reduzir gargalos e minimizar trabalhos realizados de forma manual.
A principal limitação da observação é a interferência, mesmo que não 
intencional, no ambiente de trabalho. A presença de um observador sempre 
provoca perturbações nas pessoas, o que pode alterar as condições reais em que 
o trabalho é realizado, por mais discreto que seja o observador. Outra questão 
importante é que o observador tem seu próprio ponto de vista, ou seja, a sua 
ótica pessoal, e pode tender a criar impressões favoráveis ou desfavoráveis. 
Pode haver eventos que ocorrem ocasionalmente e sua ocorrência espontânea 
não pode ser prevista, o que impede, muitas vezes, o observador de presenciar 
o fato. E, uma última limitação, é que a observação consome tempo e certa-
mente não será viável para ser utilizada em cada tarefa que o usuário realiza.
O tempo de duração de uma observação pode variar, de acordo com o que 
se pretende observar. É importante certificar-se que o fenômeno que se deseja 
observar irá ocorrer durante o período da observação. Se a necessidade for 
de observar algo que ocorre apenas em momentos de pico, por exemplo, é 
necessário que sejam identificados os períodos em que esses picos tendem a 
acontecer, para que o observador possa estar presente.
O observador deve tomar notas de forma discreta, buscando não despertar 
nas pessoas a sensação de estarem sendo vigiadas. Gravações de áudio e vídeo 
só podem ser realizadas com autorização.
Há casos em que é possível realizar uma observação menos passiva e mais 
ativa, na qual uma interação com o executor da tarefa é possível. Isso pode ser 
útil para compreender por que ele tomou aquela decisão naquele momento e 
com base em que informações a decisão foi tomada.
15Seleção de técnicas de elicitação de requisitos de software
A observação requer um olhar atento e muita discrição. Eis o que você deve observar 
no ambiente:
 � Como ocorre o fluxo de atividades entre os participantes do processo?
 � Existem momentos de pico de atividades?
 � Existem problemas causados pela tecnologia ou pela ausência dela?
 � O que acontece quando a tecnologia falha (cai a rede, porexemplo)?
 � Quais são os fluxos alternativos e casos que requerem um tratamento especial?
Questionário
A técnica de questionário, também conhecida como survey ou pesquisa de 
opinião, nada mais é do que a aplicação de um instrumento na forma de ques-
tionário, que tem por objetivo coletar informações de fontes, que podem ser em 
grande volume e estar distantes fisicamente. O questionário pode ser a porta 
de entrada para outras técnicas, por exemplo, levantando as principais dores 
dos usuários com o processo ou o sistema atual (WIEGERS; BEATTY, 2013).
O questionário é composto por um conjunto de perguntas com respostas 
objetivas ou abertas, dispostas em sequência lógica e progressiva. O objetivo 
do questionário é obter informações que servirão de base para tratamentos 
estatísticos. Lembre-se de que, se forem poucas pessoas, talvez seja melhor 
realizar uma entrevista. Tenha em mente também que os questionários são 
frios e impessoais e não permitem a mesma riqueza de outras técnicas.
Embora, à primeira vista, possa parecer que utilizar um questionário seja 
uma atividade simples, na realidade, não é. Elaborar questões é uma tarefa que 
exige conhecimento e experiência. Primeiro, porque as pessoas não gostam 
de responder questionários e, portanto, ele deve ser curto e fácil de responder. 
Segundo, porque exige habilidade para não introduzir viés e nem direcionar 
as respostas. E, por fim, as perguntas devem permitir que sejam obtidas as 
informações que o analista de requisitos necessita efetivamente. 
A preparação do questionário envolve elaborar as questões, estimar o tempo 
de resposta, simular previamente as análises e realizar um teste piloto. Esse 
teste piloto deve permitir identificar se as pessoas conseguem compreender 
adequadamente o que está sendo perguntado e se o tempo de preenchimento 
está compatível com o estimado. Ajustes podem ser feitos após o teste piloto.
Seleção de técnicas de elicitação de requisitos de software16
Depois da etapa de preparação é que o questionário pode ser distribuído 
para o público-alvo, estipulando-se a data esperada para retorno. Lembretes 
para resposta podem ser enviados no período.
Para aumentar as chances de sucesso do seu questionário, fique atento a estas dicas:
 � adicione uma breve introdução, que esclareça os pontos principais;
 � utilize uma linguagem clara e simples para elaborar as perguntas;
 � utilize frases concisas, sem prejudicar o entendimento da questão;
 � utilize termos que evitem a dupla interpretação;
 � dê preferência para as questões objetivas e que possam ser facilmente tabuladas, 
fornecendo conclusões objetivas sobre o trabalho em andamento;
 � revise se as alternativas cobrem todas as possibilidades que deseja investigar;
 � não deixe um espaço muito grande para as respostas das questões abertas, 
de modo a evitar longos discursos do respondente;
 � utilize perguntas encadeadas (para testar a coerência das respostas) e perguntas 
complementares (fará esgotar o assunto).
Outras técnicas
As técnicas descritas até aqui se aplicam à elicitação de requisitos realizada 
quando existem classes de stakeholders que podem ser representadas por uma 
pessoa, com a qual se pode fazer contato direto (como entrevistas e reuniões) 
ou indireto (como no caso do questionário). Existem ainda outras técnicas 
derivadas do design thinking que podem ser utilizadas quando as fontes são 
humanas, mas elas não serão objeto deste capítulo.
Existem alguns tipos de requisitos que são provenientes de outras fontes não 
humanas, como, por exemplo, leis ou normativas de órgãos regulamentado-
res. No segmento bancário, por exemplo, temos as normativas provenientes 
do Banco Central, do Conselho Monetário Nacional, da Comissão de Valores 
Mobiliários (CVM) etc. Temos ainda órgãos que regulamentam outros setores 
como a Agência Nacional de Saúde (ANS), a Agência Nacional de Teleco-
municações (ANATEL), a Agência Nacional de Energia Elétrica (ANEEL) e 
diversos outros. Essas leis ou normativas precisam ser lidas e interpretadas pelo 
17Seleção de técnicas de elicitação de requisitos de software
analista de requisitos junto com os especialistas do negócio. As regras impostas 
tornam-se requisitos que devem ser atendidos pelo produto de software.
Algumas vezes, o produto está sendo desenvolvido para substituir um 
software anterior, que pode não ter documentação associada e, portanto, a única 
fonte dos requisitos é o próprio software que está sendo substituído. Nesses casos, 
os requisitos podem ter que ser extraídos por meio da execução simulada 
de tarefas (funcionalidades) ou da leitura do código-fonte. Além disto, 
pode ainda haver um backlog de sugestões de melhoria pendentes do sistema 
anterior, que pode servir de base para as funcionalidades do novo produto. 
Abordagem similar é utilizada quando se quer obter requisitos a partir do 
produto dos concorrentes, com a diferença de que, normalmente, não se 
tem acesso ao código-fonte.
3 Seleção da técnica de elicitação de requisitos
Na fase de elicitação de requisitos nunca se utiliza apenas uma técnica e nem 
somente aquela que se conhece, mas todas as que forem necessárias ou apro-
priadas para cada caso. Algumas dicas para aplicar a técnica mais adequada 
e obter os melhores resultados de seu uso são descritas no Quadro 2.
Técnica Quando usar
Entrevista � Quando existem pessoas que têm o conhecimento 
necessário sobre o negócio e que estão disponíveis para 
serem entrevistadas.
 � Para captar as informações subjetivas (desabafos, 
sentimentos, pontos de vista) que podem ser úteis para a 
definição de requisitos do sistema.
 � Para identificar o fluxo de trabalho e de documentos.
Quadro 2. Seleção das técnicas de elicitação de requisitos
(Continua)
Seleção de técnicas de elicitação de requisitos de software18
Técnica Quando usar
Reunião � Para obter uma resposta rápida de várias pessoas sobre 
determinado assunto.
 � Quando existem problemas ou questões a serem 
esclarecidos, compartilhados e expostos com os demais 
participantes.
 � Para envolver o grupo da tomada de decisão.
 � Para resolver situações de conflito (busca de consenso).
 � Para fazer levantamento de alternativas e soluções para 
determinado problema.
 � Para analisar, avaliar e resolver problemas que envolvam 
pessoas de áreas ou empresas distintas.
 � Por exigência legal da empresa ou do governo.
Brainstorming � Quando o ambiente da empresa é informal e propício para 
o desenvolvimento de atividades criativas.
 � Quando se deseja encontrar soluções inovadoras e criativas.
 � Quando se deseja lançar novos produtos no mercado.
Observação � Quando o fluxo de papéis e de trabalho é relevante.
 � Quando problemas de desempenho estão relacionados à 
forma de executar o trabalho.
 � Quando a influência do ambiente real é importante.
Questionário � Se não houver tempo suficiente para entrevistar todas as 
pessoas relevantes.
 � Se as informações puderem ser adequadamente 
trabalhadas para fins estatísticos.
 � Se as pessoas estão situadas em pontos geográficos muito 
distantes.
 � Se, para prestar informações, houver necessidade de 
consultar arquivos físicos.
Quadro 2. Seleção das técnicas de elicitação de requisitos
(Continuação)
Wiegers e Beatty (2013) compilaram diversas informações e recomendações 
para a seleção da melhor técnica de elicitação de requisitos de acordo com as 
características dos projetos. Elas estão representadas no Quadro 3.
19Seleção de técnicas de elicitação de requisitos de software
Fonte: Adaptado de Wiegers e Beatty (2013).
 E
nt
re
vi
st
a
W
or
ks
ho
p
G
ru
po
 F
oc
al
O
bs
er
va
çã
o
Q
ue
st
io
ná
ri
o
A
ná
lis
e 
de
 in
te
rf
ac
e 
de
 s
is
te
m
as
A
ná
lis
e 
de
 in
te
rf
ac
e 
de
 u
su
ár
io
A
ná
lis
e 
de
 d
oc
um
en
to
s
Software para o mercado × × ×
Software interno para 
a organização
× × × × × ×
Software para substituir outro × × × × × ×
Melhorias em sistemas 
existentes
× × × × ×
Novo software × ××
Implementação de 
pacote de software
× × × × ×
Sistemas embarcados × × × ×
Stakeholders distribuídos 
geograficamente
× × ×
Quadro 3. Seleção das técnicas de elicitação de requisitos de acordo com Wiegers e 
Beatty (2013)
Como se pode observar no Quadro 3, os autores consideram duas formas 
de elicitação que não foram abordadas neste capítulo: grupo focal e workshop. 
Mais informações sobre essas formas de elicitar requisitos podem ser obtidas 
em Wiegers e Beatty (2013). Não considere esta lista como definitiva e exaus-
tiva. As técnicas podem ser combinadas de acordo com suas necessidades 
em cada projeto.
Seleção de técnicas de elicitação de requisitos de software20
BOURQUE, P.; FAIRLEY, R. SWEBOK: guide to the software engineering body of knowledge 
version 3. [S. l.]: IEEE Computer Society, 2014.
LEFFINGWELL, D. Agile software requirements: lean requirements practices for teams, 
programs, and the enterprise. Upper Saddle River: Pearson Education, 2011.
POHL, K.; RUPP, C. Requirements engineering fundamentals: a study guide for the certified 
professional for requirements engineering exam, foundation level, IREB Compliant. 2. 
ed. Santa Barbara: Rock Nook, 2015. 
SCHWABER, K.; SUTHERLAND, J. Guia do SCRUM: um guia definitivo para o SCRUM: 
as regras do jogo. [S. l.], 2013. Disponível em: https://www.scrumguides.org/docs/
scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf. Acesso em: 31 jan. 2020.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
21Seleção de técnicas de elicitação de requisitos de software
DICA DO PROFESSOR
Uma das maiores causas de fracasso em projetos de software é a condução indevida das 
atividades relacionadas à Engenharia de Requisitos. A mais crítica destas etapas é, certamente, a 
elicitação de requisitos. Diversas são as técnicas que podem ser utilizadas para descobrir os 
requisitos de um produto de software. O JAD (Joint Application Design ou Joint Application 
Development) é uma destas técnicas. Ela visa reunir os stakeholders relevantes do projeto em 
torno de um mesmo objetivo: elicitar os requisitos do projeto, reduzindo as possíveis falhas de 
comunicação e interpretação.
Nesta Dica do Professor, você irá conhecer um pouco mais sobre o JAD e compreenderá sua 
importância em projetos de software.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) Pedro foi alocado para realizar a elicitação de requisitos de um sistema no qual 
o cliente é uma grande empresa de seguros. O objetivo é desenvolver uma nova 
versão para um sistema já existente. Diversos usuários teriam que ser envolvidos e 
um possível conflito de prioridades poderia ocorrer. O gerente de Pedro aconselhou 
que ele utilizasse terno e gravata, de acordo com as características da empresa.
Que técnica de elicitação de requisitos Pedro deveria aplicar?
A) Brainstorming.
B) Entrevista.
C) Reunião tradicional.
D) Observação.
E) JAD.
2) Raquel deve preparar a elicitação de requisitos para um novo sistema de apoio a uma 
agência de publicidade. O gerente de Raquel a orientou a se vestir de maneira mais 
informal, pois os clientes são pessoas jovens e o ambiente da empresa é descontraído e 
criativo.
Que técnica de elicitação de requisitos Raquel deveria aplicar?
A) Brainstorming.
B) Entrevista.
C) Observação.
D) Reunião tradicional.
E) JAD.
3) Eduardo foi contratado como Analista de Requisitos de um sistema de bonificação de 
pesquisadores por resultado. A principal característica deste sistema é a variedade de 
perfis que o utilizarão. Todos os usuários possuem necessidades que devem ser 
levantadas, mas eles se encontram dispersos em universidades nos 5 continentes. 
Serão considerados os requisitos que a maioria das Universidades apontarem como 
críticos ou imprescindíveis.
Qual técnica de elicitação de requisitos Eduardo deve utilizar?
A) Brainstorming.
B) JAD.
C) Questionário.
D) Reunião tradicional.
E) Entrevista.
4) Um produto de software não existe de forma isolada, ele está inserido em um contexto 
social e organizacional.
A técnica que ajuda um analista de requisitos a identificar este contexto, suas 
interações e possíveis requisitos que possam estar implícitos ou invisíveis é:
A) Brainstorming.
B) JAD.
C) Reunião tradicional.
D) Observação.
E) Entrevista.
Um novo modelo de carro está sendo lançado no mercado e você vai ser o responsável 
pelos requisitos da central multimídia que vai fazer parte do projeto. O diretor 
executivo anunciou que quer um produto inovador que conquiste o público jovem e 
que você tem autonomia para as decisões. Decida quais técnicas de elicitação de 
requisitos serão utilizadas de acordo com as características do projeto.
I – Você irá realizar um brainstorming, uma vez que se trata de um produto 
inovador.
5) 
II – Você irá realizar entrevistas com os engenheiros do projeto para entender as 
interfaces necessárias ao novo carro.
III – Você irá realizar uma observação para analisar como os motoristas dirigem os 
carros atuais.
IV – Você irá realizar um JAD para projetar o software e gerenciar os conflitos.
Assinale a alternativa abaixo que contém apenas as assertivas corretas.
A) As assertivas I, II, III e IV estão corretas.
B) As assertivas I, II e IV estão corretas.
C) As assertivas I, III e IV estão corretas.
D) As assertivas I e II estão corretas.
E) Apenas a assertiva I está correta.
NA PRÁTICA
Um dos cuidados que um Analista de Requisitos deve ter para elicitar os requisitos de um 
projeto de software é selecionar adequadamente a técnica que será utilizada. Isso depende das 
características do projeto e do contexto no qual ele será desenvolvido. Quando o projeto é 
inovador e se busca por soluções criativas, uma boa ideia é utilizar o brainstorming.
A técnica é adequada a ambientes mais informais e descontraídos. Geralmente, se evita o 
brainstorming em ambientes muito formais ou muito hierarquizados. Também não se 
recomenda misturar níveis hierárquicos quando se deseja explorar as ideias sem críticas 
e inibições.
Confira, Na Prática, alguns dos desafios que envolvem a atividade de conduzir uma sessão 
de brainstorming.
Conteúdo interativo disponível na plataforma de ensino!
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
O que é uma persona?
Neste vídeo, Daniel Furtado apresenta os conceitos sobre o que é uma persona e ressalta a 
importância de colocar o usuário como o protagonista do processo.
Conteúdo interativo disponível na plataforma de ensino!
Como criar personas?
Neste vídeo, Daniel Furtado apresenta formas de criar uma persona e inicia sua fala com uma 
metáfora utilizando Lego. O foco é a análise inicial para verificar se o mercado tem necessidade 
do produto que você está desenvolvendo.
Conteúdo interativo disponível na plataforma de ensino!
5 passos para um brainstorming perfeito
Neste vídeo da DreamU, são explicadas as regras para a condução de um brainstorming, uma 
das técnicas mais usadas para a criação de novos produtos ou soluções inovadoras. O autor 
explica os conceitos de pensamento divergente e pensamento convergente.
Conteúdo interativo disponível na plataforma de ensino!
Engenharia de software: uma abordagem profissional
Este material vai ajudar você a compreender os principais conceitos envolvidos na elicitação de 
requisitos de software. Foque sua atenção nas páginas 138-149 do livro de Roger Pressman e 
Bruce Maxim.
Especificação de requisitos funcionais 
utilizando casos de uso
APRESENTAÇÃO
Satisfazer às necessidades dos usuários de um produto de software não é uma tarefa simples. Em 
primeiro lugar, o software é um produto intangível, diferente de outros bens de consumo 
produzidos pela indústria. Segundo, o que o cliente necessita não é exatamenteo software em si, 
mas o valor que esse software vai agregar, seja para as suas atividades profissionais, seja na sua 
vida pessoal. Terceiro, a mudança é uma constante, e o que faz sentido hoje pode não ser mais 
necessário daqui a três meses.
Para que um produto de software possa cumprir o seu propósito, ou seja, entregar o valor 
esperado pelo cliente, é imprescindível que o analista de requisitos (ou papel equivalente) 
execute bem o seu papel. Isso quer dizer que é função dele realizar as articulação do diversos 
stakeholders para que possam ser extraídos os requisitos do produto e que, uma vez 
identificados, possam ser especificados no nível de detalhe necessário para que a equipe de 
desenvolvimento possa produzir o produto desejado.
Esse nível de detalhe pode variar de acordo com as características do contexto, ou seja, não 
existe uma fórmula única para todas as situações. Haverá situações em que um nível muito 
grande de detalhe será necessário e outras em que apenas um desenho será suficiente.
Nesta Unidade de Aprendizagem, você aprenderá a identificar os elementos que compõem uma 
especificação de casos de uso. Irá aprender também como elaborar o fluxo principal de um 
cenário de caso de uso, além dos fluxos alternativos e de exceção.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Identificar os elementos que compõem uma especificação de caso de uso.•
Criar o fluxo principal de um cenário de caso de uso.•
Projetar fluxos alternativos e de exceção em cenários de caso de uso.•
DESAFIO
 Uma das formas de realizar a especificação de requisitos funcionais é utilizar a abordagem de 
casos de uso. Essa abordagem é composta por um diagrama e uma especificação. Ambos têm 
uma função importante na comunicação entre a equipe de desenvolvimento e os usuários. Para 
que possam ser utilizados de forma efetiva, ambos os instrumentos precisam estar alinhados e 
coerentes entre si. Caso ocorra um desalinhamento, ele pode gerar inconsistências na 
implementação.
A empresa onde você trabalha foi contratada por uma universidade para desenvolver diversos 
aplicativos para apoio às suas novas demandas. Você foi alocado para ser o analista de 
requisitos do primeiro aplicativo: um software de apoio para os estudantes intercambistas 
estrangeiros que chegam para estudar na universidade.
INFOGRÁFICO
Ao se adotar a abordagem de casos de uso para especificar os requisitos funcionais de um 
projeto de software, dois artefatos devem ser desenvolvidos: o diagrama de casos de uso e as 
especificações de caso de uso.
É comum que se comece desenhando o diagrama e utilizando-o como instrumento de 
comunicação com os usuários para a elicitação mais aprofundada desses requisitos. Esses 
detalhes de como o caso de uso vai se comportar compõem as especificações de caso de uso.
Acompanhe, no Infográfico a seguir, os passos para criar a especificação de casos de uso.
CONTEÚDO DO LIVRO
Identificar e especificar adequadamente os requisitos de um projeto de software são importantes 
passos rumo à qualidade da entrega. Requisitos mal compreendidos e mal especificados são as 
causas mais frequentes de problemas em projetos.
Existem diversas formas de realizar essa especificação, mas o mais importante é utilizar uma 
abordagem centrada no usuário, ou seja, aquela que valoriza e coloca o usuário no centro do 
processo. Afinal, quem vai utilizar o produto é ele.
A abordagem de casos de uso se baseia no desenho de um diagrama, com formas simples e de 
fácil compreensão, e uma especificação, que detalha o funcionamento de um caso de uso.
No capítulo Especificação de requisitos funcionais usando casos de uso, da obra Engenharia de 
requisitos, você vai aprender a identificar os elementos que compõem uma especificação de 
casos de uso e como elaborar o fluxo principal e os fluxos alternativos e de exceção.
Boa leitura.
ENGENHARIA 
DE REQUISITOS
Sheila Reinehr
Especificação de 
requisitos funcionais 
utilizando casos de uso
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os elementos que compõem uma especificação de caso 
de uso.
 � Criar o fluxo principal de um cenário de caso de uso.
 � Projetar fluxos alternativos e de exceção em cenários de caso de uso.
Introdução
Há várias formas de expressar os requisitos funcionais de um projeto. 
Podemos fazer isso por meio de desenhos, diagramas, textos escritos 
em linguagem natural, cartões, Post-it® ou qualquer outro meio que 
a equipe considere eficiente. O mais importante é a essência, ou seja, 
que tenha sido estabelecida a conexão, o alinhamento, entre a equipe 
de desenvolvimento e o cliente. A forma como isso será registrado vai 
depender de diversas variáveis de contexto.
Independentemente de o ambiente no qual o projeto está sendo 
desenvolvido ser gerenciado de forma mais tradicional ou de forma ágil, 
requisitos sempre serão o ponto fundamental do sucesso do projeto. 
Compreender a real necessidade do negócio e projetar a forma como o 
software pode agregar valor nesse contexto já é meio caminho andado.
Casos de uso têm sido uma forma pela qual as organizações desen-
volvedoras de software têm especificado requisitos funcionais. Isso é feito 
utilizando-se tanto o diagrama de casos de uso, proveniente da UML (em 
inglês, Unified Modeling Language), quanto a especificação de casos de 
uso, que tem origens e formatos diversos.
Neste capítulo você vai estudar os elementos que compõem a es-
pecificação de casos de uso, uma importante ferramenta de apoio ao 
diagrama de casos de uso. Vai ver também como identificar os passos 
que compõem o fluxo principal de um caso de uso, os fluxos alternativos 
e de exceção.
1 Elementos da especificação de casos de uso
Especificar requisitos funcionais utilizando a abordagem de casos de uso 
requer duas etapas, uma se refere à construção do diagrama de casos de uso 
e outra, à especificação que acompanha o diagrama. Pensar em casos de uso 
significa colocar o usuário no centro do processo e definir funcionalidades 
que agreguem valor para esse usuário.
Diagrama de casos de uso
O diagrama de casos de uso é uma ferramenta visual que representa o com-
portamento do sistema sob a ótica do usuário (SEIDL et al., 2012). Ele oferece 
uma visão geral das funcionalidades de um sistema que envolve software. 
Qualquer stakeholder, mesmo leigo, consegue fazer a leitura de um diagrama 
de casos de uso e compreender o seu significado, bastando conhecer a sua 
simbologia, que é bastante simples. O diagrama de casos de uso não oferece 
uma visão interna da implementação. Para isso existem outros diagramas da 
UML que podem ajudar.
Vamos relembrar o diagrama de casos de uso, tomando como base o contexto 
mapeado na Figura 1. Suponha que você acaba de entrar em uma empresa 
e que o seu novo gerente lhe passa este diagrama e pede que você vá se 
familiarizando com ele para que vocês possam conversar no final da manhã. 
Mesmo sem conhecer os detalhes deste software, você já consegue rapidamente 
identificar quem são os atores que fazem parte do contexto, bem como quais 
são as principais funcionalidades envolvidas. A partir desta representação, 
já é possível inferir também algumas regras de funcionamento do sistema. 
Se você tiver alguma experiência, vai até conseguir descobrir que há coisas 
faltando no diagrama e identificar questões que você poderá esclarecer com 
o seu gerente quando vocês se reunirem.
Ao observar este diagrama, é possível identificar que se trata de um Sistema 
de Compras On-line, uma vez que existe um retângulo que define a fronteira da 
aplicação e um título no canto superior esquerdo que indica o nome do sistema.
Especificação de requisitos funcionais utilizando casos de uso2
Figura 1. Diagrama de casos de uso.
É possível ainda identificar que qualquer pessoa pode acessar o sistema 
como visitante e pesquisar produtos, mas, para comprar umproduto, é preciso 
estar logado. Um Comprador Logado poderá realizar todas as funções que um 
Visitante executa, mas o contrário não é verdadeiro. Você sabe disso porque 
viu que há um relacionamento de Generalização, que denota a herança entre 
esses dois atores (a seta sai do Comprador e aponta para o Visitante). 
Neste momento você percebe que existe uma diferença entre os com-
pradores, pois há a figura do Comprador Ouro, e se pergunta: “Mas o que 
este Comprador Ouro tem de especial? Ele tem algum benefício adicional? 
Não consigo ver isto no diagrama. Vou perguntar para o gerente”. É possível 
identificar a mesma situação com o papel do vendedor, ou seja, existe um 
Vendedor Ouro, mas ainda não sabemos qual é a diferença dele em relação 
ao ator Vendedor.
3Especificação de requisitos funcionais utilizando casos de uso
Você percebe que ao realizar uma compra existem dois tipos de pagamento 
diferentes, o que é demostrado pelos relacionamentos de extend existentes 
entre o caso de uso UC4 – Realizar Pagamento e os casos de uso UC5 – Pagar 
com Boleto e UC6 – Pagar com Cartão de Crédito. Note ainda que, quando for 
feito o pagamento com cartão de crédito, outro ator terá que ser envolvido, a 
Operadora de Cartão, uma vez que há uma associação entre eles. Aqui você 
também já anota que esta situação poderia também ter sido representada por 
uma relação de Generalização entre UC4 – Realizar Pagamento e os seus 
possíveis herdeiros UC5 e UC6.
Você percebe que a liberação da entrega depende da confirmação do 
pagamento. No caso do pagamento com cartão de crédito, a confirmação é 
on-line com a Operadora de Cartão. No caso do pagamento com boleto, isso 
vai acontecer quando o ator Banco confirmar o pagamento. Isso é representado 
pelo relacionamento de include, que indica que, quando o caso de uso UC11 
– Confirmar Pagamento de Boleto for executado, ele chamará o caso de uso 
UC10 – Liberar Compra para ser executado também. 
Você continua sua análise e descobre que existe o caso de uso UC7 – Fazer 
Denúncias, mas nota que não existe um caso de uso para tratar a denúncia e 
responder ao denunciante. Faz então mais uma anotação para perguntar ao 
seu gerente: “Será que a denúncia será tratada manualmente? Teremos que 
nos relacionar com algum outro sistema? Isso não está claro!”.
Lá no final do diagrama você nota que tem um ator chamado Agendador 
de Tarefas e se lembra que esse tipo de ator é usado quando existem casos de 
uso que são disparados automaticamente pelo próprio sistema, em resposta 
a eventos temporais ou de controle. Neste caso, o sistema vai disparar o caso 
de uso UC9 – Emitir Relatório Gerencial. Aí você pensa: “Qual será a perio-
dicidade que isto ocorre? Poderia ter sido adicionada uma nota ao diagrama, 
descrevendo em que condições este relatório será emitido”. Então acrescenta 
mais uma pergunta à sua lista de questões a serem discutidas com o seu gerente.
Para finalizar sua análise você observa que existe um caso de uso UC1 – 
Realizar Login, mas não existe nada para tratar situações de exceção, como 
o esquecimento de senha ou o usuário não estar cadastrado. Você decide 
questionar seu gerente como será tratada essa questão: se for com um sistema 
externo, está faltando representá-lo no diagrama; se for pelo próprio sistema, 
então faltam novos casos de uso, como Realizar Cadastro e Recuperar Senha.
Mesmo você não tendo participado da elicitação de requisitos desse 
software, apenas com essa rápida análise, já foi possível perceber as principais 
funcionalidades, além de levantar algumas dúvidas que ainda precisam ser 
esclarecidas. 
Especificação de requisitos funcionais utilizando casos de uso4
O diagrama de casos de uso realmente é simples e tem um grande poder 
de comunicação. No entanto, apenas o diagrama não é suficiente para dar 
continuidade às demais etapas do ciclo de vida de desenvolvimento, uma vez 
que faltam detalhes para que as funcionalidades possam ser implementadas 
com sucesso pelos desenvolvedores e testadas pelos testadores. Esses detalhes 
fazem parte do que é chamado de especificação de casos de uso.
Como você já percebeu, cada elemento do diagrama tem um significado específico, e 
ele precisa estar coerente com os elementos que compõem a especificação do caso 
de uso. Eles formam um conjunto coerente, no qual o diagrama de casos de uso 
representa a visão geral das funcionalidades de forma gráfica e a especificação de 
casos de uso apresenta os detalhes da execução dessas funcionalidades. Esses dois 
elementos precisam estar alinhados. Se um for alterado, é necessário analisar se o 
outro também não sofrerá modificações.
Especificações de casos de uso
Uma especificação de casos de uso consiste em um detalhamento dos cenários 
de execução dos casos de uso. São acrescentadas informações àquelas que 
foram representadas graficamente no diagrama, de modo que a equipe de de-
senvolvimento tenha mais subsídios para validar e seguir para a implementação.
A primeira dúvida que surge quando se inicia a especificação de casos de 
uso é: até que nível devemos detalhar? E a resposta é: depende. Depende do 
grau de proximidade dos usuários com a equipe de desenvolvimento, depende 
do grau de maturidade da própria equipe de desenvolvimento, depende do 
grau de intimidade que a equipe de desenvolvimento tem com o negócio e 
suas regras. Portanto, para cada caso, esse grau de detalhamento pode variar 
— pode inclusive variar dentro do mesmo sistema. Há partes que, por algum 
motivo, precisam de mais detalhes, enquanto outras não.
5Especificação de requisitos funcionais utilizando casos de uso
Wiegers e Beatty (2013) sugerem que os requisitos sejam especificados 
com mais detalhes nas seguintes situações:
 � o trabalho está sendo desenvolvido para um cliente externo;
 � o desenvolvimento ou o teste serão terceirizados;
 � os membros da equipe do projeto estão geograficamente distribuídos;
 � os testes de sistema serão baseados nos requisitos;
 � estimativas precisas são necessárias;
 � a rastreabilidade dos requisitos é necessária.
Por outro lado, Wiegers e Beatty (2013) sugerem que os detalhes sejam 
evitados quando:
 � o trabalho está sendo desenvolvido internamente para a sua empresa;
 � os clientes estão extensivamente envolvidos;
 � os desenvolvedores têm uma grande experiência no domínio;
 � há experiência anterior, como quando uma aplicação está sendo desen-
volvida para substituir outra;
 � uma solução do tipo pacote será usada.
Existem softwares de modelagem de diagramas UML que permitem não apenas 
o desenho do diagrama, mas também a inclusão da sua especificação, facilitando, 
posteriormente, a rastreabilidade. Caso você tenha acesso a uma dessas ferramentas, 
excelente, mas, se não tiver, sem problemas. Utilize uma ferramenta gratuita para fazer 
o diagrama e um editor de texto para realizar a especificação. Cada um desses artefatos 
cumprirá a sua finalidade: o desenho apoiará o diálogo com os diversos stakeholders, 
especialmente os usuários; e a especificação servirá para apoiar a equipe técnica do 
projeto. Só não esqueça de manter esses dois elementos sempre alinhados! Quando um 
deles for alterado, é importante checar se o outro não precisará também ser ajustado.
Existem diversos modelos para a especificação dos casos de uso, como os 
encontrados em Cockburn (2005), Dennis, Wixon e Roth (2012), Seidl et al., 
(2012) e Guedes (2018). Cockburn (2005) tem preferência por um texto, sem 
formatação de tabela, mas com os títulos em destaque. 
Especificação de requisitos funcionais utilizando casos de uso6
Aqui vamos utilizar uma versão derivada desses que é representada no 
Quadro 1. Cada empresa, no entanto, pode optar por um modelo customizado 
para as suas necessidades, incluindo mais ou menos detalhes. É importante 
apenas ressaltar que todos os elementos precisam ser úteis para alguém. Espe-
cificações desnecessariamente complicadas podem acabar entrando em desuso. 
Identificador único do caso de uso
Descrição 
Atorprincipal
Atores secundários
Pré-condições
Gatilho
Fluxo principal
Ações do ator Ações do sistema
Fluxo alternativo
Ações do ator Ações do sistema
Fluxo de exceção
Ações do ator Ações do sistema
Pós-condição
Quadro 1. Modelo de especificação de casos de uso
Vamos conferir a seguir os elementos envolvidos neste template de espe-
cificação de casos de uso.
7Especificação de requisitos funcionais utilizando casos de uso
O identificador único se refere ao nome do caso de uso. Geralmente se 
utiliza um verbo no infinitivo, que caracteriza a ação que será realizada. 
Se você voltar na Figura 1, vai ver que naquele diagrama colocamos também 
uma sigla UC (advinda de use case), acompanhada de um número sequencial 
(UC1, UC2 etc.). Esse identificador reduzido não é obrigatório, mas pode ser 
útil para fazermos a rastreabilidade posteriormente.
A descrição visa a apresentar uma visão resumida do objetivo do caso de 
uso. Pode ser escrita em uma frase simples. Não é um lugar para especificar 
itens técnicos ou regras de negócio, serve apenas para descrever o objetivo 
geral do caso de uso.
Em seguida temos o ator principal, que é aquele que inicia o caso de 
uso, e os atores secundários, que são aqueles que participam na execução 
do caso de uso ou que fornecem informações para que o caso de uso possa 
ser realizado. Nem todo caso de uso terá atores secundários. 
Vamos relembrar aqui o conceito de ator. De acordo com a UML (OBJECT MANAGEMENT 
GROUP, 2017, documento on-line), “Um ator especifica um papel que é desempenhado 
por um usuário ou qualquer outro sistema que interage com o sujeito”.
Entende-se por sujeito o sistema que está sendo especificado. Alguns autores se 
referem ao sistema como SUD (system under definition ou system under discussion).
Um ator é um elemento externo ao sistema. Ele pode representar uma pessoa, 
um hardware especial ou um outro sistema. Chamamos de hardware especial aquele 
que é importante de ser destacado, como, por exemplo, algum sensor ou atuador 
que desempenhe função relevante para o sistema que está sendo modelado. Não 
precisamos representar a interação com hardwares triviais, como impressoras ou o 
próprio equipamento onde roda o software.
Quando uma funcionalidade é disparada pelo próprio sistema isso é representado 
usando um ator chamado Agendador de Tarefas (scheduler). Há quem represente o 
próprio sistema como sendo o ator que dispara esses casos de uso, mas isso vai contra 
a definição de ator (que é um elemento externo ao sistema).
Especificação de requisitos funcionais utilizando casos de uso8
Uma pré-condição é uma condição que tem que ser verdadeira para que 
o caso de uso tenha início. Ela normalmente é utilizada para estabelecer 
a sequência de casos de uso que realizam uma grande função de negócio 
(DENNIS; WIXON; ROTH, 2012). A pré-condição não é testada quando o 
caso de uso inicia, o caso de uso só inicia se ela for verdadeira. Por exemplo, 
se, para realizar uma compra, o usuário tem que estar logado, então o caso 
de uso que realiza o login já tem que ter sido executado com sucesso antes 
que o caso de uso de compra seja iniciado. Este é um dos casos mais comuns 
de pré-condição.
Uma pós-condição é o status em que o sistema deve ser deixado quando 
for concluído o caso de uso, ou seja, quando encerrar a execução do caso 
de uso o sistema garantirá que a pós-condição seja verdadeira. Quando a 
pós-condição for trivial, não é necessário documentá-la. Por exemplo, para 
o caso de uso Cadastrar Cliente, não é necessário colocar uma pós-condição 
“cliente deverá ter sido cadastrado com sucesso”, pois é uma saída trivial de 
um caso de uso de cadastro.
Um gatilho é um evento que dá início ao caso de uso. Quando o caso de uso 
é chamado por um ator humano, então o gatilho é justamente a chamada feita 
por esse ator. Na prática, isso significa que será disponibilizado, por exemplo, 
um item de menu, um botão, um link, por meio do qual o usuário dá início 
à realização daquele caso de uso. Quando o disparo é automático, de acordo 
com determinadas circunstâncias, então o gatilho pode ser um determinado 
momento do tempo (por exemplo, 22:00h), ou pode ser um evento de controle 
(mudança do estado de algum objeto).
O fluxo principal, também chamado de fluxo básico, refere-se ao cenário 
mais comum de utilização do caso de uso, considerando que tudo deu certo. Ele 
também é conhecido como o “caminho feliz”. O fluxo principal é geralmente 
mapeado como uma conversa entre o que o ator faz e o que o sistema responde, 
por isso as duas colunas no template apresentado no Quadro 1. Pode também 
ser usada uma única coluna, e cada parte do diálogo ser representada em uma 
linha. No fluxo principal se considera que todas as interações entre o ator e 
o sistema foram bem-sucedidas.
9Especificação de requisitos funcionais utilizando casos de uso
É necessário tomar cuidado para que o mapeamento do fluxo principal não caia no 
nível de detalhe de preenchimento de campos da interface. É preciso ter em mente 
que o caso de uso não é um pseudocódigo da implementação. Nunca esqueça de se 
perguntar se você não está especificando detalhes desnecessários.
Os fluxos alternativos, como o próprio nome sugere, são as possibilidades 
de cenários alternativos ao fluxo principal, conforme escolhas do usuário ou 
situações específicas do sistema. Não inclui fluxos para o tratamento de erro, 
mas sim escolhas que podem ser feitas pelo usuário.
Os fluxos de exceção demonstram como o sistema reagirá na presença de 
situações inesperadas. Os fluxos de exceção podem ocorrer dentro do fluxo 
principal ou dentro de um fluxo alternativo.
Não perca tempo especificando todos os detalhes de um caso de uso ou todos os 
casos de uso de um sistema, especialmente se eles não forem ser implementados em 
breve. Especificar casos de uso que só serão implementados em versões muito distantes 
é perda de tempo. Quando chegar o momento da implementação eles podem ter 
mudado ou simplesmente podem não ser mais necessários.
2 Especificação do fluxo principal
Conforme apresentado na seção anterior, o fluxo principal, também chamado 
de fluxo básico, refere-se ao cenário mais comum de utilização do caso de 
uso, considerando que tudo vai dar certo. A finalidade desse mapeamento é 
Especificação de requisitos funcionais utilizando casos de uso10
identificar as interações que precisam ser previstas por parte do usuário e 
como o sistema vai tratar essas entradas. Entretanto, é importante manter certo 
distanciamento dos detalhes da interface, sob pena de ficarmos presos somente 
a cores, campos e botões. Especificar o fluxo básico é mais do que especificar 
interfaces; é expressar um caso de sucesso que entrega valor ao usuário!
Agora vamos ver um exemplo de uma especificação relacionada ao dia-
grama apresentado na Figura 1. Vamos considerar o caso de uso UC3 – Realizar 
Compra. O primeiro passo é compreender o que está desenhado no diagrama. 
Imediatamente identificamos o símbolo do ator principal, neste caso, um 
Comprador Logado. Ele indica que existe uma pré-condição, que é o login já 
ter sido realizado. Não foram identificados atores secundários no diagrama, 
e este é o momento de se perguntar se existe algum que foi esquecido. A 
resposta neste exemplo é “não”, mas, se houver, o digrama de casos de uso 
deve ser atualizado, para refletir essa nova descoberta. Neste exemplo, não 
existe pós-condição.
O gatilho para que este caso de uso tenha início é a ação do usuário, 
solicitando a sua execução. Isso é identificado no diagrama de caso de uso 
pela associação, por meio de uma linha contínua, que liga o ator Comprador 
Logado ao caso de uso. Se fosse uma tarefa disparada automaticamente pelo 
sistema, o ator seria um agendador de tarefas e o gatilho seria a condição de 
guarda desse agendador (por exemplo, a chegada de um momento específico 
no tempo).
O próximo passo é verificar se existe algum tipo de relacionamento com 
outros casos de uso. No diagrama existeum relacionamento de include com o 
caso de uso UC2 – Pesquisar Produtos e outro relacionamento de include com 
o caso de uso UC4 – Realizar Pagamento. Isso significa que esses dois casos 
de uso deverão ser iniciados dentro do caso de uso que está sendo descrito.
A partir dessas informações que foram provenientes do diagrama de casos 
de uso, é preciso determinar como ocorrerá o diálogo entre o ator e o sistema, 
para realizar o objetivo do caso de uso. Essa conversa é descrita nos passos do 
fluxo principal, que são numerados sequencialmente e ordenados na coluna 
Ações do Ator e na coluna Ações do Sistema. 
Acompanhe no Quadro 2 como ficou a especificação deste fluxo principal.
11Especificação de requisitos funcionais utilizando casos de uso
Identificador único do caso de uso UC3 – Realizar Compra
Descrição Permite ao comprador realizar 
a compra de um produto
Ator principal Comprador Logado
Atores secundários ×
Pré-condições O caso de uso UC1 – Realizar Login 
ter sido executado com sucesso 
e o comprador estar logado
Gatilho Comprador Logado seleciona 
Realizar Compra
Fluxo principal
Ações do ator Ações do sistema
2 – Comprador Logado seleciona 
categoria de produto
4 – Comprador Logado seleciona 
produto
6 – Comprador Logado informa a 
quantidade
8 – Comprador Logado seleciona 
opção de entrega
1 – Sistema exibe categorias de 
produtos
3 – Sistema executa UC2 – Pesquisar 
Produtos
5 – Sistema solicita quantidade
7 – Sistema exibe opções de entrega
9 – Sistema executa UC4 – Realizar 
Pagamento
Pós-condição Não se aplica
Quadro 2. Especificação do caso de uso UC3 – Realizar Compra – Fluxo Principal
Especificação de requisitos funcionais utilizando casos de uso12
3 Especificação dos fluxos alternativos 
e de exceção
Conforme definido na primeira seção deste capítulo, os fluxos alternativos 
são as possibilidades de cenários alternativos ao fluxo principal, conforme 
escolhas do usuário ou situações específicas do sistema. Não consiste em 
fluxos para o tratamento de erro, mas sim em escolhas que podem ser feitas 
pelo usuário, para executar um cenário alternativo de sucesso.
Uma vez mapeado o fluxo principal, vem a pergunta: existe alguma coisa 
que possa mudar o fluxo principal? O usuário tem alternativas para algum 
dos passos? Essas alternativas são cenários diferentes e resultam em fluxos 
alternativos.
Suponha que o Comprador Logado possa adicionar um novo endereço de 
entrega quando estiver selecionando a opção de entrega. Observe no Quadro 3 que 
é incluído um fluxo alternativo A8 que permitirá realizar essa tarefa. Este fluxo 
é nomeado com a letra A (alternativo), seguido do número 8, indicando que é a 
partir do passo 8 do fluxo básico que este fluxo é acionado. No fluxo principal, 
este fluxo alternativo A8 também é registrado no passo 8. A forma de numerar 
pode ser diferente desta, à escolha da empresa, desde que forneça interpretação 
similar e que seja utilizada de forma consistente em todas as especificações.
Caso a alteração de endereço fosse realizada por um outro caso de uso, 
então o diagrama teria que ser alterado para inserir esse caso de uso novo 
e também o seu relacionamento de extend com o caso de uso em questão. 
Na especificação seria chamado este novo caso de uso.
Os fluxos de exceção demonstram como o sistema reagirá na presença de 
situações inesperadas, ou seja, ele mapeia caminhos de insucesso. Os fluxos 
de exceção podem ocorrer tanto dentro do fluxo principal quanto dentro de 
um fluxo alternativo.
Para cada passo do fluxo principal deve-se fazer a pergunta: o que pode dar 
errado? Cada resposta a essa pergunta vai determinar um fluxo de exceção. 
Neste exemplo, foram identificadas duas situações: uma em que o produto 
não está disponível (isso ocorre no passo 4 do fluxo básico) e outra em que 
a quantidade não está disponível (isso ocorre no passo 6 do fluxo básico). 
O tratamento para cada uma das exceções será planejado na seção de fluxo 
de exceção correspondente a cada possibilidade.
Assim como fizemos no fluxo principal, precisamos nos questionar o que 
pode dar errado no fluxo alternativo. Neste exemplo foi identificado que o Com-
prador Logado pode ter digitado um CEP inválido (passo A7.2). Isso também 
é mapeado como um fluxo de exceção, que sai de dentro do fluxo alternativo.
13Especificação de requisitos funcionais utilizando casos de uso
Identificador único do caso de uso UC3 – Realizar Compra
Descrição Permite ao comprador realizar 
a compra de um produto
Ator principal Comprador Logado
Atores secundários ×
Pré-condições O caso de uso UC1 – Realizar Login 
ter sido executado com sucesso 
e o comprador estar logado
Fluxo principal
Ações do ator Ações do sistema
2 – Comprador Logado seleciona 
categoria de produto
4 – Comprador Logado seleciona 
produto
6 – Comprador Logado informa a 
quantidade
8 – Comprador Logado seleciona 
opção de entrega (A8)
1 – Sistema exibe categorias de 
produtos
3 – Sistema executa UC2 – Pesquisar 
Produtos
5 – Sistema solicita quantidade
7 – Sistema exibe opções de entrega
9 – Sistema executa UC4 – Realizar 
Pagamento
Fluxo Alternativo A8 – Alterar endereço de entrega
A8.1 – Comprador Logado 
seleciona Alterar Endereço
A8.3- Comprador Logado 
preenche novo endereço
A8.2 – Sistema solicita novo endereço
A8.4 – Sistema salva novo endereço
Pós-condição Não se aplica
Quadro 3. Especificação do caso de uso UC3 – Realizar Compra – Fluxo Alternativo
Especificação de requisitos funcionais utilizando casos de uso14
Identificador único do caso de uso UC3 – Realizar Compra
Descrição Permite ao comprador realizar 
a compra de um produto
Ator principal Comprador Logado
Atores secundários ×
Pré-condições O caso de uso UC1 – Realizar Login 
ter sido executado com sucesso 
e o comprador estar logado
Fluxo principal
Ações do ator Ações do sistema
2 – Comprador Logado seleciona 
categoria de produto
4 – Comprador Logado 
seleciona produto (E4)
6 – Comprador Logado 
informa a quantidade (E6)
8 – Comprador Logado seleciona 
opção de entrega (A8)
1 – Sistema exibe categorias 
de produtos
3 – Sistema executa UC2 
– Pesquisar Produtos
5 – Sistema solicita quantidade
7 – Sistema exibe opções de entrega
9 – Sistema executa UC4 – 
Realizar Pagamento
Quadro 4. Especificação do caso de uso UC3 – Realizar Compra – Fluxos de Exceção
(Continua)
O Quadro 4 ilustra como a especificação do caso de uso ficará a partir 
dessas novas descobertas.
15Especificação de requisitos funcionais utilizando casos de uso
Fluxo Alternativo A8 – Alterar endereço de entrega
A8.1 – Comprador Logado 
seleciona Alterar Endereço
A8.3- Comprador Logado preenche 
novo endereço (E.A8.3)
A8.2 – Sistema solicita novo endereço
A8.4 – Sistema salva novo endereço
Fluxo de Exceção E4 – Produto indisponível
E4.2 - Comprador Logado 
confirma que quer voltar 
para seleção de produtos
E4.1 - Sistema exibe mensagem 
“Produto indisponível no 
momento. Deseja voltar para 
seleção de produtos?”
E4.3 - Sistema retorna para 
a seleção de produtos
Fluxo de Exceção E6 – Quantidade indisponível
E6.2 - Comprador Logado confirma 
que quer reduzir a quantidade
E6.1 - Sistema exibe mensagem 
“Quantidade indisponível. Quer 
reduzir a quantidade?”
E5.3 - Sistema retorna para a 
seleção da quantidade
Fluxo de Exceção E.A8.3 – CEP inválido
E.A8.3.1 - Sistema exibe mensagem 
“CEP inválido. Corrigir CEP.”
E.A8.3.2 - Sistema retorna 
para a entrada do CEP
Pós-condição Não se aplica
Quadro 4. Especificação do caso de uso UC3 – Realizar Compra – Fluxos de Exceção
(Continuação)
Especificação de requisitos funcionais utilizando casos de uso16
Tratamento de casos de uso CRUD
Uma pergunta que sempre surge quando falamos na abordagem orientada 
a casos de uso é como tratar as questões relacionadas aos casos de uso que 
manipulam cadastros, ou seja, as operações CRUD (create, retrieve, update 
e delete). A resposta é: não existe uma forma padrão! Há os que defendem 
que essas operações estejam agrupadasem um caso de uso mais genérico, 
denominado Manter ou Gerenciar, em vez de existir um caso de uso para 
cada uma das operações. O principal argumento a favor dessa abordagem é 
que tanto o diagrama quanto as especificações ficam mais simples. Essa é a 
forma normalmente adotada na prática.
Neste caso, a especificação tratará como fluxo principal o fluxo mais 
frequente, e como fluxos alternativos, os demais fluxos. 
O diagrama de casos de uso a seguir ilustra a representação das operações CRUD 
como um único caso de uso, Manter Produto.
Há, por outro lado, os que defendem que as operações devem ser tratadas 
de forma distinta, uma vez que podem, inclusive, ter níveis de permissão de 
acesso diferentes e serem realizadas por pessoas diferentes (COCKBURN, 
2005). Quando isso ocorrer, é importante ter em mente que deverá existir 
uma boa justificativa, ou será gasto um esforço adicional desnecessário em 
especificações separadas.
17Especificação de requisitos funcionais utilizando casos de uso
O diagrama de casos de uso a seguir ilustra a representação das operações CRUD 
como casos de uso separados: UC1 – Cadastrar Produto, UC2 – Alterar Produto, UC3 
– Deletar Produto e UC4 – Consultar Produto. Imagine que este sistema tenha dezenas 
de cadastros e todos eles com as quatro operações. O diagrama de casos de uso ficaria 
extremamente poluído, dificultando a identificação dos casos de uso mais relevantes.
Os diagramas e as especificações de caso de uso são ferramentas comple-
mentares que podem ser utilizadas em uma variedade grande de situações. 
Eles se aplicam a pequenos projetos e a projetos de grande porte. Eles são 
especialmente úteis em projetos nos quais existe uma interação expressiva 
entre os usuários e o sistema.
Especificação de requisitos funcionais utilizando casos de uso18
Se você ainda tiver dúvidas sobre a relevância das especificações de caso de uso, veja o 
que diz Alistair Cokburn (2005, p. 32), um dos precursores dos métodos ágeis: “Os casos de 
uso são amplamente populares porque eles contam histórias coerentes de como o sistema 
irá se comportar em uso. Os usuários do sistema conseguem ver o que o sistema será.”.
O caso de uso agrega valor em dois momentos (COCKBURN, 2005):
 � o primeiro, quando os casos de uso são nomeados como objetivos do usuário e 
compõem uma lista que revela o escopo do sistema e o seu propósito, apoiando 
atividades de estimativa e priorização;
 � o segundo, quando os autores dos casos de uso precisam questionar o que pode 
dar errado no fluxo básico, identificando como o sistema deve reagir. Neste caso, 
podem ser descobertas coisas surpreendentes que nem a equipe e nem o cliente 
tinham pensado anteriormente.
COCKBURN, A. Escrevendo casos de uso eficazes: um guia prático para desenvolvedores 
de software. Porto Alegre: Bookman, 2005.
DENNIS, A.; WIXON, B.; ROTH, R. System analysis and design. 5. ed. Hoboken: John Wiley 
and Sons, 2012.
GUEDES, G. UML 2: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
OBJECT MANAGEMENT GROUP. Unified Modeling Language®: OMG UML® v2.5.1. [S. l.], 2017. 
Disponível em: https://www.omg.org/spec/UML/About-UML/. Acesso em: 13 mar. 2020.
SEIDL, M. et al. UML@Classroom: an introduction to object-oriented modeling. Cham: 
Springer, 2012.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
19Especificação de requisitos funcionais utilizando casos de uso
DICA DO PROFESSOR
Utilizar casos de uso para a descrever requisitos funcionais é uma abordagem muito útil, pois 
coloca o usuário no centro do processo. Os casos de uso nada mais são do que cenários de 
execução de uma atividade que agrega valor para o usuário.
Veja, nesta Dica do Professor, algumas dicas para escrever as especificações de caso de uso que 
nos dão Dennis, Wixom e Roth (2012).
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
O diagrama de casos de uso representa funcionalidades do sistema com foco nas interações 
dos atores com os casos de uso. Considere o diagrama a seguir e analise as assertivas:
I. Na especificação do Caso de Uso 2, tanto o Ator A quanto o Ator B são considerados 
atores principais.
1) 
II. Na especificação do Caso de Uso 4, tanto o Ator A quanto o Ator B são considerados 
atores principais.
III. Na especificação do Caso de Uso 2, o Ator B é considerado um ator principal, e o Ator 
C é considerado um ator secundário.
IV. Na especificação do Caso de Uso 3, vai haver um ponto de inclusão do Caso de Uso 4.
Com base no diagrama de casos de uso e nas afirmativas apresentadas, é correto afirmar:
A) As assertivas I, II, III e IV estão corretas.
B) As assertivas I, III e IV estão corretas.
C) As assertivas II e III estão corretas.
D) Apenas a assertiva II está correta.
E) Apenas a assertiva IV está correta.
A especificação de casos de uso apoia o detalhamento do que está desenhado no 
diagrama de casos de uso. Leia as seguintes assertivas sobre a especificação de casos 
de uso:
I. Quando uma pré-condição existir, ela deve aparecer na especificação de caso de 
uso no item chamado “pré-condição”, e o caso de uso deve testar se ela é verdadeira 
no primeiro passo do fluxo principal.
II. O fluxo alternativo apresenta todas situações imprevistas e os erros que podem 
ocorrer em um caso de uso e como o sistema irá tratá-los.
III. Quando um caso de uso pode ser executado por mais do que um ator, ambos 
devem ser listados como atores principais do caso de uso.
IV. Quando um relacionamento de extend existir no diagrama de casos de uso, 
2) 
significa que a especificação do caso de uso base deverá conter um ponto de extensão 
que chamará o caso de uso estendido.
Com base nas assertivas, assinale a alternativa correta:
A) As assertivas I, II, III e IV estão corretas.
B) As assertivas I, II e IV estão corretas.
C) As assertivas I e II estão corretas.
D) As assertivas III e IV estão corretas.
E) As assertivas II e III estão corretas.
Em um diagrama de casos de uso, os relacionamentos são representados por linhas que 
apresentam formatos e significados específicos, servindo de base para a interpretação 
semântica da relação. Analise o diagrama a seguir:
3) 
Escolha a alternativa correta no que se refere às especificações de casos de uso derivadas 
desse diagrama:
A) Na especificação de caso de uso de Consultar Notas, o ator principal será o Usuário, e os 
atores secundários serão o Aluno e o Professor.
B) No caso de uso Consultar Notas, haverá uma pré-condição, que é o Usuário estar logado.
C) Quando o caso de uso Realizar Login for realizado, ele obrigatoriamente executará o caso 
de uso Consultar Notas. 
D) O ator Aluno é um ator secundário porque não inicia nenhum caso de uso; portanto, não é 
um ator principal.
E) Tanto o ator Aluno quanto o ator Professor podem iniciar o caso de uso Consultar Notas. 
4) A especificação de casos de uso visa a apoiar o entendimento da equipe de 
desenvolvimento em relação ao que deverá ser construído, e ela é composta por 
diversos elementos que se complementam. Com relação a essa forma de especificação, 
analise as assertivas a seguir.
I. Quando o ator principal de um caso de uso for o agendador de tarefas (scheduler), 
então o gatilho será esse agendador de tarefas dando início à tarefa.
II. Quando o ator principal de um caso de uso for o agendador de tarefas (scheduler), 
então o gatilho será a condição de guarda desse caso de uso.
III. Quando o ator principal de um caso de uso for o agendador de tarefas 
(scheduler), então não poderá haver fluxos alternativos.IV. Quando o ator principal de um caso de uso for o agendador de tarefas 
(scheduler), então os fluxos de exceção deverão ser também agendados.
V. Quando o ator principal de um caso de uso for um humano, sempre deverá ser 
especificado o gatilho que esse ator aciona.
A) As assertivas I, III e IV estão corretas.
B) As assertivas II, III, IV e V estão corretas.
C) Apenas a assertiva I está correta.
D) Apenas a assertiva II está correta.
E) Apenas a assertiva IV está correta.
5) Um diagrama de casos de uso é complementado por uma especificação de caso de 
uso. 
Sobre as especificações de caso de uso, assinale a alternativa correta:
A) Um caso de uso pode conter pontos de inclusão para cada uma das pré-condições que 
estejam especificadas. 
B) Casos de uso do tipo CRUD (create-retrieve-update-delete) devem ter um caso de uso 
para cada uma das operações. 
C) Os fluxos de exceção representam situações imprevistas que o sistema pode enfrentar e são 
associados unicamente aos passos do fluxo principal.
D) Quando o usuário preencher um campo incorretamente, isso será tratado pelo caso de uso 
como um fluxo alternativo.
E) Um fluxo principal é um conjunto de passos que compõem a realização do cenário mais 
frequente de utilização de um caso de uso. 
NA PRÁTICA
Existem diversas formas pelas quais os requisitos podem ser elicitados e descritos. Uma dessas 
formas é a abordagem orientada a casos de uso. Se usada corretamente, esta é uma forma de 
tornar a comunicação entre os usuários e a equipe de desenvolvimento mais eficiente.
A abordagem de casos de uso é composta pelo desenho do diagrama de casos de uso, 
acompanhado das especificações de caso de uso. Embora o diagrama traga a visão geral dos 
requisitos funcionais, ele sozinho não é suficiente, pois não representa todos os detalhes que são 
necessários para que a equipe de desenvolvimento possa realizar o seu trabalho.
Judy é analista de requisitos e recebeu a atividade de conduzir a especificação de casos de uso 
do sistema de compra de material escolar. Acompanhe, Na Prática, os desafios de Judy e como 
ela organizou o seu trabalho desde o início para concluí-lo com sucesso.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Erros comuns das especificações de casos de uso
Leia o capítulo 19 (p. 181-192) do livro Escrevendo casos de uso eficazes: um guia prático para 
desenvolvedores de software, de Alistair Cockburn, sobre os erros mais comuns na escrita de 
casos de uso e como evitá-los. Isso pode ajudar você a melhorar a escrita dos casos de uso, 
evitando esquecer algum elemento importante.
Lembretes para cada caso de uso
Leia o capítulo 20 (p. 195-203) do livro Escrevendo casos de uso eficazes: um guia prático para 
desenvolvedores de software, de Alistair Cockburn, sobre lembretes importantes para escrever 
um caso de uso. São dicas que podem ajudar você a melhorar a sua proficiência com os casos de 
uso.
Lembretes para conjunto de casos de uso
Leia o capítulo 21 (p. 204-208) do livro Escrevendo casos de uso eficazes: um guia prático para 
desenvolvedores de software, de Alistair Cockburn, sobre dicas para o conjunto dos casos de uso 
de um sistema. Essas dicas podem ajudar você a avaliar se o conjunto de casos de uso que você 
definiu está adequado.
Especificação dos requisitos não 
funcionais de software
APRESENTAÇÃO
Um dos principais focos do desenvolvimento de software atualmente é garantir uma boa 
experiência ao usuário. Experiência do usuário é mais do que entregar todas as funcionalidades 
desejadas. É preciso que o produto entregue funcionalidades de forma atrativa, fácil de usar, 
com desempenho excelente, segurança e mais um sem número de outros elementos cognitivos e 
emocionais. Nas décadas passadas, era fácil agradar ao usuário de um sistema de software. 
Bastava entregar algo que funcionasse. No entanto, hoje isso não é mais realidade. A tecnologia 
evoluiu, assim como o grau de exposição das pessoas às tecnologias. Isso fez com que o usuário 
passasse a ser mais exigente. Requisitos funcionais não são, portanto, a única fonte de 
preocupação da equipe de desenvolvimento. É preciso voltar a sua atenção também para os 
requisitos não funcionais, pois são eles que agregam valor à experiência do usuário.
Nesta Unidade de Aprendizagem, você verá como identificar e especificar os requisitos não 
funcionais de um projeto de software. Além disso, você compreenderá como selecionar 
indicadores para avaliar os requisitos não funcionais após a sua implementação.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Identificar os requisitos não funcionais de um projeto de software.•
Especificar os requisitos não funcionais de software.•
Selecionar indicadores para avaliar os requisitos não funcionais de software.•
DESAFIO
Os requisitos não funcionais são muitas vezes difíceis de serem elicitados, pois é comum que os 
stakeholders que servem de fonte de informação se foquem mais nos aspectos funcionais, ou 
seja, no que o software deve fazer, e não se atentem muito para o como o software deve fazer. 
Para que os requisitos não funcionais possam ser tratados adequadamente, independentemente 
do processo de desenvolvimento utilizado, é importante que critérios objetivos de avaliação 
sejam definidos, de modo que possam ser posteriormente validados. 
Suponha que, com o aumento da demanda por trabalho remoto, devido à pandemia de COVID-
19, você tenha sido escalado para desenvolver um software para apoiar reuniões remotas. Existe 
muita reclamação no mercado sobre os softwares proprietários, que são caros, e sobre os 
softwares gratuitos, com vulnerabilidades de segurança. Você precisa desenvolver um software 
para ser utilizado em reuniões de trabalho da sua empresa via Internet.
Acompanhe, a seguir, o que deve ser considerado:
quais são os requisitos não funcionais que deveriam estar presentes, bem como os atributos para 
validá-los.
INFOGRÁFICO
Os requisitos não funcionais de um sistema que envolve software influenciam fortemente a 
aceitação do produto por parte do usuário. Questões como usabilidade, tempo de resposta e 
consumo de recursos são alguns desses atributos que podem fazer com que um usuário deixe de 
utilizar um produto. Essas características são o que se chama de qualidade em uso. No entanto, 
existe um conjunto de atributos que não é perceptível diretamente pelos usuários: os atributos de 
qualidade interna. Estes são requisitos que vão tornar a manutenção do produto mais fácil ou 
mais difícil e que vão influenciar diretamente nos custos de manutenção.
Neste Infográfico, você irá acompanhar os atributos de qualidade interna de produtos de 
software.
CONTEÚDO DO LIVRO
Para o analista de requisitos, é mais fácil obter os requisitos funcionais do que os requisitos não 
funcionais de um produto de software. Isso ocorre primeiramente porque o usuário geralmente 
foca em falar sobre as funcionalidades. Segundo, porque muitas vezes ninguém vai falar sobre 
os requisitos não funcionais, mas vai esperar que eles estejam lá. São os requisitos invisíveis ou 
requisitos implícitos. Para facilitar a identificação de requisitos não funcionais, podem-se 
utilizar diversas abordagens, mas, independentemente da técnica escolhida, um checklist com os 
principais requisitos não funcionais poderá ajudar.
No capítulo Especificação dos requisitos não funcionais de software, do livro Engenharia de 
requisitos, base teórica desta Unidade de Aprendizagem, você vai aprender a identificar os 
requisitos não funcionais de software. Em seguida, vai ver como especificar requisitos não 
funcionais em ambientes tradicionais e ambientes ágeis. Por fim, vai ver como identificar 
indicadores para avaliar requisitos não funcionais.
Boa leitura.
ENGENHARIA DE 
REQUISITOS
Sheila Reinehr
Especificação dos requisitos 
nãofuncionais de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os requisitos não funcionais de um projeto de software.
 � Especificar os requisitos não funcionais de software.
 � Selecionar indicadores para avaliar os requisitos não funcionais de 
software.
Introdução
Com a intensa proliferação de produtos tecnológicos no dia a dia das 
pessoas, as exigências do mercado ficaram mais altas. Todos somos 
rotineiramente expostos a diversos softwares, especialmente na forma 
de aplicativos nos smartphones. Com a mesma facilidade com que são 
baixados novos apps, eles também são deletados. Essa grande exposi-
ção a vários tipos de produto torna o usuário cada vez mais exigente, 
seja com a qualidade da interface, seja com a praticidade do uso, seja 
com a satisfação que as funcionalidades lhe proporcionam. Negligenciar 
esses requisitos de qualidade é deixar de lado um dos maiores fatores 
de conquista do usuário.
Requisitos não funcionais esquecidos ou não implementados ade-
quadamente são uma das maiores causas de abandono de produtos 
de software. Há mais do que um conjunto de funcionalidades em um 
software de sucesso. Quando um software falha em entregar requisitos 
como bom desempenho, facilidade de uso, segurança e mais uma série 
de outros atributos de qualidade, é muito provável que ele tenha vida 
curta no mercado.
Quando determinados requisitos não funcionais são descobertos 
tardiamente no ciclo de desenvolvimento de software, pode não ser 
mais possível resolver o problema, ou pode ser muito caro resolvê-lo. 
Se decisões arquiteturais forem tomadas sem levar em consideração 
os requisitos não funcionais (de escalabilidade, por exemplo), pode ser 
que não seja possível implementar esse requisito sem que uma grande 
mudança seja feita. Isso pode inviabilizar a continuidade de um projeto ou 
de um produto de software, devido aos altos custos. Em casos extremos, 
pode causar até mesmo perda de vidas.
Neste capítulo você vai ver como identificar requisitos não funcionais 
de produtos de software. Vai também ler sobre como descrever esses 
requisitos e, por fim, sobre como definir indicadores que permitam sua 
verificação e validação.
1 Identificação de requisitos não funcionais 
de software
Certamente você já ouviu falar que requisitos não funcionais, também cha-
mados de requisitos de qualidade, são mais difíceis de serem elicitados e 
especificados do que requisitos funcionais. Será que isso é verdade? Na maioria 
das vezes, sim. É comum que os stakeholders responsáveis por fornecer os 
requisitos não enxerguem, pelo menos à primeira vista, os requisitos não 
funcionais, e eles podem permanecer invisíveis por muito tempo.
Além disto, diferentes tipos de software terão diferentes tipos de requisitos 
não funcionais. Softwares com intensa interação com os usuários certamente 
terão requisitos distintos daqueles de softwares que estão embarcados em 
equipamentos. Softwares que desempenham funções críticas também terão 
demandas distintas de softwares que podem falhar. Dessa forma, o contexto 
de negócio e o tipo de aplicação irão influenciar sobremaneira os requisitos 
de qualidade aplicáveis.
Em sistemas interativos, ou seja, que são baseados no diálogo com o usuário, 
alguns requisitos não funcionais são fundamentais, como, por exemplo, requi-
sitos relacionados à usabilidade. Usabilidade depende fortemente do contexto 
e do público-alvo. Se os usuários forem pessoas que têm intimidade com a 
tecnologia, é uma coisa; se os usuários forem pessoas leigas em tecnologia, 
é outra coisa bem diferente.
Especificação dos requisitos não funcionais de software2
Se o software for disponibilizado sem treinamento, os requisitos de usa-
bilidade aumentam. Por exemplo, sites que vendem produtos pela web. Não é 
esperado que as pessoas tenham que fazer um curso para aprender a usá-los, 
é esperado que elas acessem o site e consigam concluir sua compra com 
sucesso. O projeto da interface tem que ajudar o vendedor a não perder uma 
venda por problemas, por exemplo, de navegação no site.
Wiegers e Beatty (2013) citam o exemplo de um novo software com interface gráfica 
que foi instalado em uma equipe de call center em substituição ao sistema anterior, 
que era baseado em caracteres e teclas de atalho. Os usuários tinham uma grande 
produtividade no sistema anterior porque eram experientes e navegavam rapidamente 
com as teclas de atalho. Ao mudar para o novo sistema, o uso do mouse, intercalado 
com o uso do teclado, tirou-lhes a produtividade. Resumindo: o novo sistema teve que 
ser remodelado para contemplar a possibilidade da navegação com teclas de atalho.
Se estivermos falando de um sistema para o segmento bancário, teremos 
uma infinidade de requisitos não funcionais, mas certamente a segurança 
estará entre os de maior prioridade. Oferecer uma interface fácil de operar é 
importante também neste segmento, mas desde que os aspectos de segurança 
tenham sido adequadamente tratados.
Em sistemas de missão crítica relacionados a aspectos que envolvem vidas, 
por exemplo, haverá certamente requisitos não funcionais de os sistemas 
estarem livres de riscos. Este é o caso, por exemplo, de veículos autônomos. 
Uma operação incorreta pode custar a vida de pedestres ou de passageiros 
do próprio veículo. O mesmo ocorre para sistemas que podem oferecer riscos 
financeiros ou ambientais.
Existem os requisitos que não são diretamente visualizados pelos clientes 
e usuários, mas que são uma preocupação da equipe desenvolvedora — são 
os requisitos relacionados à qualidade interna do produto, como manutenibi-
lidade, ou seja, facilidade de dar manutenção. Quantas vezes a equipe recebe 
um chamado relatando um bug que demora dias para ser localizado. Por que 
isto ocorre? Porque a arquitetura da aplicação não favorece a manutenção, 
dificultando a agilidade na solução de problemas ou na implementação de 
melhorias e evoluções.
3Especificação dos requisitos não funcionais de software
Outro contexto específico é o das startups de tecnologia. É comum que 
elas comecem seu negócio baseadas em uma ideia inovadora dos sócios que 
se esforçam para colocar de pé um MVP (minimum viable product ou produto 
mínimo viável). Depois de um tempo, esse protótipo se transforma no pro-
duto que vai para o mercado. Como o tempo exigido pelo mercado é curto, 
a startup evolui o produto sem muito planejamento, afinal ela precisa escalar! 
Se os cuidados com a arquitetura e os requisitos de escalabilidade tiverem 
sido tomados, tudo certo; mas esse não é o cenário mais comum, e o produto 
evoluído tem dificuldade para escalar e para sofrer manutenções (BERG 
et al., 2018). É comum o código estar no formato de monolito e a manutenção 
ser dificultada. O que era fácil, quando a empresa e a equipe eram pequenas, 
se torna insustentável com o crescimento. Neste momento, os requisitos não 
funcionais se tornam críticos e passam a ameaçar a existência da própria 
empresa.
Nem todos os requisitos de qualidade serão viáveis para implementação em 
um produto de software (WIEGERS; BEATTY, 2013). Depois de elicitados, 
certamente haverá uma análise de prioridade, e aqueles que forem identificados 
como mais prioritários irão direcionar as escolhas da equipe, seja em termos de 
alocação de pessoas, seja em termos de escolhas tecnológicas e arquiteturais.
Nem todos os produtos de software são sistemas de informação; vários deles, espe-
cialmente hoje, são sistemas ditos embarcados, ou seja, aqueles em que o software 
está dentro de produtos de hardware, como sistemas mais complexos. Sistemas dessa 
natureza envolvem dispositivos mecânicos, elétricos e eletrônicos, como sensores, 
atuadores, controladores, motores, baterias etc. Nesses casos, requisitos relacionados 
ao desempenho podem se tornar críticos.
Nos sistemas baseados em IoT (Internet of Things, ou Internet das Coisas), por exemplo, 
um ponto crucial é o consumo de energia. Algoritmos paraesses casos devem ser 
otimizados e devem consumir pouca energia para processar.
Especificação dos requisitos não funcionais de software4
Como identificar os requisitos não funcionais
Assim como os requisitos funcionais, os requisitos não funcionais podem 
ser obtidos pelo contato direto com os stakeholders em reuniões, entrevistas, 
brainstormings, ou por meio de questionários. Podem ainda ser descobertos 
quando se conduz uma observação no ambiente de execução. Nesses momentos, 
é possível, para o observador, identificar requisitos não funcionais relacionados 
ao uso do sistema.
Muitas vezes, os requisitos precisam ser obtidos a partir da análise de 
documentos, leis, regulamentações, guias etc. Nesses casos, os requisitos não 
funcionais podem aparecer de forma explícita ou implícita na documentação. 
Com a Lei Geral de Proteção de Dados Pessoais (LGPD), por exemplo, muito 
requisitos não funcionais foram explicitados. A consequência é que funcio-
nalidades adicionais precisam ser implementadas em todos os sistemas do 
mundo. Uma delas, a mais óbvia, é alertar ao usuário, logo na instalação do 
produto, quais são as políticas de segurança e compartilhamento de dados que 
são aplicadas pelo fornecedor, exigindo que ele concorde com elas. 
Para saber mais sobre a Lei nº 13.709, de 14 de agosto de 2018, mais conhecida como 
Lei Geral de Proteção de Dados Pessoais (LGPD), consulte o site da Casa Civil do 
Governo Federal ou o Diário Oficial da União (DOU). Para obter informações sobre a 
lei internacional equivalente, pesquise por General Data Protection Regulation (GDPR).
Não existe uma fórmula mágica para fazer com que os requisitos não 
funcionais surjam, mas as atividades sugeridas por Wiegers e Beatty (2013, 
p. 265), apresentadas na Figura 1, podem ajudar. Elas foram baseadas em um 
documento disponibilizado on-line pela empresa Clarrus (2010).
5Especificação dos requisitos não funcionais de software
Figura 1. Elicitação de requisitos não funcionais.
Fonte: Adaptada de Wiegers e Beatty (2013).
Comece com uma
taxonomia ampla
Reduza a lista junto aos
stakeholders
Traduza em critérios
quanti�cáveis
Priorize os atributos
Especi�que requisitos de
qualidade estruturados
Como se pode observar na Figura 1, os autores sugerem que a descoberta 
dos requisitos não funcionais comece partindo de uma lista abrangente 
de atributos de qualidade. Naturalmente, nem todos os tipos de software 
necessitarão de todos os atributos. Além disso, nem sempre se tem todos os 
recursos disponíveis para implementá-los, mas é melhor começar com uma 
lista maior do que correr o risco de deixar algum atributo importante de lado.
Como sugestão para a elaboração dessa lista, você pode utilizar as carac-
terísticas e subcaracterísticas de qualidade que estão presentes na família de 
normas internacionais ISO/IEC 25000, mais especificamente o modelo de 
qualidade em uso e o modelo de qualidade de produto, que podem ser encon-
trados na norma internacional ISO/IEC 25010 (ISO/IEC, 2011).
É possível também usar a relação compilada por Wiegers e Beatty (2013), 
apresentada no Quadro 1.
Em seguida, deve-se engajar todos os stakeholders relevantes do produto 
para que possam selecionar os atributos de qualidade que são importantes 
para o projeto. Em um primeiro momento, pode ser que eles selecionem todos, 
ou quase todos os atributos da lista. Isso pode gerar uma lista inviável de ser 
implementada, seja pelas restrições de contexto, seja por conflitos entre os 
próprios atributos. Cabe ao analista de requisitos conduzir os stakeholders 
durante essas decisões.
Especificação dos requisitos não funcionais de software6
Fonte: Adaptado de Wiegers e Beatty (2013).
Qualidade 
externa
Breve descrição
Disponibilidade Extensão na qual os serviços do sistema estão disponíveis 
quando e onde são necessários
Instalabilidade Quão fácil é instalar, desinstalar e reinstalar corretamente a 
aplicação
Integridade A extensão na qual o sistema protege contra imprecisão e 
perda de dados
Interopera-
bilidade
Quão fácil o sistema pode interconectar e trocar dados com 
outros sistemas e componentes
Desempenho Quão rápido e previsivelmente o sistema responde às entra-
das do usuário e outros eventos
Confiabilidade Por quanto tempo o sistema roda antes de apresentar uma falha
Robustez Quão bem o sistema responde a uma condição inesperada 
de operação
Proteção Quão bem o sistema protege contra ferimentos e danos
Segurança Quão bem o sistema protege contra acesso não autorizado à 
aplicação e seus dados
Usabilidade Quão fácil é para as pessoas aprenderem, lembrarem e 
utilizarem o sistema
Qualidade 
interna
Breve descrição
Eficiência Quão eficientemente o sistema usa os recursos do computador
Modificabilidade Quão fácil é manter, modificar, melhorar e reestruturar o sistema
Portabilidade Quão facilmente o sistema pode ser colocado em operação 
em outros ambientes operacionais
Reusabilidade Em que extensão os componentes podem ser usados em 
outros sistemas
Escalabilidade Quão facilmente o sistema pode crescer para tratar mais 
usuários, transações, servidores e outras extensões
Verificabilidade Quão prontamente desenvolvedores e testadores podem 
confirmar que o software foi implementado corretamente
Quadro 1. Alguns atributos de qualidade
7Especificação dos requisitos não funcionais de software
O próximo passo é realizar a priorização desses atributos. Uma forma de 
realizar essa atividade é usando uma tabela que combina os diversos atributos 
e faz análise sobre eles, dois a dois. Isso é importante para ajudar o analista de 
requisitos a focar as atividades de elicitação sobre os atributos relevantes, não 
gastando grande esforço em atributos que possam ser descartados. O Quadro 2 
apresenta um exemplo adaptado de Wiegers e Beatty (2013) que reflete o que 
foi proposto por Clarrus (2010).
Fonte: Adaptado de Wiegers e Beatty (2013).
Qualidade 
externa Sc
or
e
D
is
po
ni
bi
lid
ad
e
In
te
gr
id
ad
e
D
es
em
pe
nh
o
Co
nf
ia
bi
lid
ad
e
Ro
bu
st
ez
Se
gu
ra
nç
a
U
sa
bi
lid
ad
e
Ve
ri
fi
ca
bi
lid
ad
e
Disponibilidade 1 ^ < ^ ^ ^ ^ ^
Integridade 7 < < < < < <
Desempenho 1 ^ ^ ^ < ^
Confiabilidade 3 ^ ^ < ^
Robustez 4 ^ ^ <
Segurança 5 ^ <
Usabilidade 3 ^
Verificabilidade 4
Quadro 2. Exemplo de quadro para priorização de atributos de qualidade
A tabela funciona de forma muito simples. Para cada par de atributos 
você faz a seguinte pergunta: se for para escolher um dos dois, qual é o mais 
importante? Ao entrar com um sinal de menor (<) indica que o atributo da 
linha é mais importante. Ao entrar com o sinal circunflexo (̂ ) indica que o 
atributo da coluna é mais importante. 
Especificação dos requisitos não funcionais de software8
O exemplo apresentado no Quadro 2 é fictício. A leitura seria a seguinte: 
entre o atributo “disponibilidade” e “integridade”, o símbolo aponta para cima, 
ou seja, para a “integridade”. Isso significa que o atributo “integridade”, para 
este contexto, é mais importante do que “disponibilidade”. A lista de atributos 
é um recorte da lista abrangente apresentada no passo um e que foi refinada 
no passo dois. Esta matriz é útil para a tomada de decisão em momentos em 
que seja necessário priorizar um requisito em detrimento de outro.
A coluna do score é obtida pela soma de vezes em que o atributo é sele-
cionado como prioridade. No caso do exemplo fictício do Quadro 2, nota-se 
que o atributo “integridade” foi mais importante do que todos os outros sete 
atributos, recebendo o score 7. Em seguida, vem o atributo “segurança”, com 
5 pontos, e assim por diante.
O objetivo do uso dessa tabela é obter uma visão consolidada sobre a 
prioridade dos requisitos não funcionais. É possível que elas sejam conflitantes 
entre os diversos stakeholders, e, nesse momento, cabe ao analista de requisitos 
resolver esses conflitos junto aos stakeholders.
A próxima etapa é traduzir os atributos em critérios quantificáveis. 
Geralmente os stakeholdersusam palavras ambíguas para expressar os re-
quisitos não funcionais, como amigável, rápido, confiável, robusto e assim 
por diante. Entretanto essas expressões geram interpretações imprecisas e, 
geralmente, são impossíveis de validar. Para chegar a critérios mais objetivos, 
será necessário que o analista de requisitos faça perguntas que os stakeholders 
saibam responder e na linguagem que eles entendem. Em vez de perguntar 
quão robusto o sistema deve ser, o analista deveria perguntar quantos usuários 
simultâneos estão previstos, por exemplo.
A última etapa é estruturar os requisitos de qualidade. Wiegers e Beatty 
(2013) recomendam que seja utilizado sempre o mnemônico SMART (specific, 
measurable, attainable, relevant and time-sensitive), ou seja, o requisito deve 
ser específico, mensurável, atingível, relevante e sensível ao tempo. 
Se o testador não puder testar um requisito, então o requisito não está bom o suficiente.
9Especificação dos requisitos não funcionais de software
Identificação de requisitos não funcionais 
em ambientes ágeis
Em ambientes de desenvolvimento ágil de software, a identificação dos requisi-
tos não funcionais geralmente ocorre por meio de um workshop para discussão 
das histórias de usuário. As histórias de usuário vão focar nos requisitos 
funcionais, mas o seu complemento, que são os critérios de aceitação, irão 
incluir critérios referentes aos requisitos funcionais e também aos requisitos 
não funcionais. E é aí que eles, os requisitos não funcionais, entram em cena.
Patton (2014) apresenta algumas dicas para a condução de workshops para 
a discussão das histórias do usuário e dos critérios de aceitação, acompanhe:
 � O workshop é, basicamente, uma conversa apoiada por diversas figuras 
e dados, ao final do qual a equipe deve chegar à conclusão de como 
será validado o que foi decidido construir.
 � Antes do workshop é importante comunicar à equipe quais histórias 
do usuário serão discutidas.
 � O ideal é um workshop pequeno, entre três a cinco pessoas. Patton (2014) 
recomenda que seja “do tamanho de conversa de jantar”.
 � Cerifique-se de ter incluído as pessoas certas: (1) alguém que entenda o 
usuário, geralmente um analista de negócios, o product owner ou alguém 
com conhecimento em experiência do usuário (UX); (2) desenvolvedores que 
entendam de código e que saibam analisar a viabilidade técnica do que está 
sendo proposto; (3) um analista de teste que fará as perguntas difíceis, quando 
a maioria será otimista. Outras pessoas podem ser incluídas, mas lembre-se 
de que muitas pessoas juntas podem tornar o workshop improdutivo.
 � Mergulhe fundo para compreender: exatamente quem é o usuário; 
exatamente como ele vai usar o software; exatamente como ele deve se 
parecer (interface); exatamente como o software deve se comportar por 
trás da interface (regras de negócio e validação de dados); basicamente 
como o software será construído — para permitir estimativas.
 � Entre em acordo sobre o que será construído, respondendo a duas per-
guntas: o que vamos checar para verificar o que foi construído; como 
vamos demonstrar o software quando formos revisar juntos.
 � Converse e documente tudo o que ficou decidido, pode ser com desenhos, 
anotações e fotografias.
 � Fale por meio de exemplos para materializar a história. Seja específico 
sobre situações e dados.
 � Divida ou esvazie histórias, se necessário.
Especificação dos requisitos não funcionais de software10
Utilizar workshops para definir os requisitos não funcionais, ou seja, os 
critérios de aceitação, pode ser uma excelente escolha. No entanto, dependendo 
da característica das pessoas envolvidas, pode não dar muito certo. Saiba 
como reconhecer quando o workshop não está funcionando verificando estes 
pontos (PATTON, 2014):
 � Ninguém participa: alguém descreve o que é requerido e os outros 
escutam.
 � Quando o foco fica apenas nos critérios de aceitação e não se discute 
a história e quem faz o que, e por quê.
 � Quando se falha em identificar opções, sejam funcionais, sejam técnicas.
Identificar os requisitos não funcionais de software não exige uma técnica especial, mas 
sim uma atitude especial. É preciso que o analista de requisitos, ou papel equivalente, 
esteja atento para explorar, junto aos diversos stakeholders, quais são os pontos críticos 
do sistema e para onde a equipe de desenvolvimento deve envidar os seus esforços. 
Um checklist contendo os principais requisitos de qualidade pode ajudar na identificação 
desse tipo de requisito. A família de normas internacionais ISO/IEC 25000 pode ajudar.
2 Especificação de requisitos não funcionais 
de software
Quando falamos de requisitos funcionais logo nos vem à mente a especificação 
utilizando os diagramas de caso de uso e as especificações de caso de uso. 
Embora essas sejam duas ferramentas muito poderosas para a especificação 
de requisitos, elas não se aplicam aos requisitos não funcionais. Elas são boas 
para explicitar as funcionalidades.
Para as especificações de requisitos não funcionais, usamos alguma forma 
de documentação suplementar, que visa a explicitar os detalhes desses requi-
sitos, de modo que possam seguir para as demais fases do desenvolvimento.
O Quadro 3 apresenta alguns exemplos de especificação de requisitos não 
funcionais, extraídos de Wiegers e Beatty (2013). Note que todos eles têm em 
11Especificação dos requisitos não funcionais de software
comum a característica de buscar trazer mais precisão para a declaração do 
requisito.
Fonte: Adaptado de Wiegers e Beatty (2013).
Tipo Identificador Descrição
Disponibilidade AVL-1 O sistema deve estar pelo menos 95% dis-
ponível nos dias de semana das 6:00 h às 
24:00 h e pelo menos 99% disponível nos 
dias de semana entre 15:00 h e 17:00 h.
Instalabilidade INS-1 Um usuário sem treinamento deve ser 
capaz de executar com sucesso a instala-
ção inicial da aplicação em 10 minutos.
Integridade INT-1 Depois de executar o backup de 
arquivos, o sistema deve verificar a cópia 
do backup em relação ao original e 
relatar qualquer discrepância.
Desempenho PER-1 A autorização de um saque no caixa 
eletrônico não deve demorar mais do 
que 2 segundos.
Segurança SEC-1 O sistema deve bloquear a conta do 
usuário depois da quarta tentativa de 
login sem sucesso consecutiva em um 
período de 5 minutos.
Usabilidade USE-1 Todas as funções do menu Arquivo 
devem ser teclas de atalho definidas que 
usam a tecla Ctrl pressionada simulta-
neamente com outra tecla. Comandos 
do menu que também aparecerem no 
MS-Word devem usar as mesmas teclas 
de atalho default que o MS-Word usa.
Quadro 3. Exemplos de especificação de requisitos não funcionais
Requisitos não funcionais nos ambientes ágeis
Quando uma empresa utiliza métodos ágeis, os requisitos são especificados no 
formato de histórias de usuário. De acordo com Patton (2014, p.91, tradução 
nossa), “Histórias foram assim nomeadas devido a como é esperado que elas 
Especificação dos requisitos não funcionais de software12
sejam usadas, não devido à forma como você está tentando escrevê-las”. Uma 
história do usuário nada mais é do que um cenário de uso de um produto por 
um tipo específico de usuário.
Segundo Patton (2014), Roy Jeffrey, um dos criadores do XP, estabeleceu 
os 3 Cs da história de usuário: Cartão, Conversa e Confirmação, representa-
dos da Figura 2. O cartão é onde a história do usuário é escrita. A conversa 
refere-se ao fato de que a história nasce da intensa comunicação entre a equipe 
de desenvolvimento e o usuário. E, por fim, a confirmação representa os 
critérios de aceitação da história, que é onde os requisitos não funcionais 
são especificados. Também pode ser que você encontre lugares em que os 
requisitos não funcionais sejam registrados no próprio cartão, como se fosse 
uma história independente.
Figura 2. Os 3 Cs da história de usuário.
Fonte: Adaptada de Patton (2014).
Cartão
Conversa
Con�rmação
Você pode escrever uma
série de cartões ou fazer
uma mapa dahistória
(history map)...
Apoie a conversa com
palavras e �guras
Quando for tempo
de construir, use os
critérios de
aceitação para
registrar os seus
acordos
3 Indicadores para avaliar requisitos 
não funcionais de software
Uma das formas de analisar se chegamos a um resultado é comparar o valor 
obtido com o valor planejado. Isso vale para qualquer aspecto da vida pessoal 
e profissional. Medidas fazem parte de nossa vida desde que nascemos: nasceu 
13Especificação dos requisitos não funcionais de software
dentro da faixa de peso ideal? Cresceu o suficiente no primeiro mês? Está no 
tamanho ideal para a idade? 
Se você quiser saber se foi bem em uma prova, você compara o resultado 
ideal (o 10,0) com o resultado que você obteve — isso vai lhe mostrar o 
quanto você está distante do ideal. Se você quiser comparar o seu desempe-
nho com o dos colegas, vai analisar o que você tirou em relação à média dos 
seus colegas. Se você estiver em um treinamento para fazer uma maratona, 
vai analisar quantos quilômetros consegue correr em determinado tempo. 
Se quiser emagrecer, vai estabelecer um peso ideal e um caminho para chegar lá.
Medições também fazem parte da nossa vida profissional: quanto tempo 
precisamos para entregar esta funcionalidade? Quantas pessoas são necessá-
rias para este projeto? Quanto tempo falta para terminar o projeto? Qual é a 
produtividade média da equipe? Qual é a gravidade deste risco? Quanto tempo 
levaríamos para implementar todo o backlog do produto?
Só é possível controlar aquilo que se consegue medir. Só é possível avaliar 
se houver algum padrão para comparar. Só é possível planejar com certa 
precisão se houver medidas confiáveis nas quais se basear.
E como medir a qualidade de um produto de software? Como garantir se o 
que foi entregue é o que o usuário queria? Se estivermos falando de funciona-
lidades, podemos contar quantas funcionalidades foram entregues em relação 
a quantas funcionalidades foram solicitadas. Mas será que isso é suficiente? 
E se a funcionalidade não apoiar o usuário adequadamente em suas tarefas, 
conta como funcionalidade entregue com qualidade?
A grande questão é: como garantir que aquilo que vamos entregar atenderá 
às expectativas dos usuários do produto? Inicialmente, investindo na elici-
tação de requisitos, com especial atenção para os requisitos não funcionais. 
Em seguida, identificando indicadores que podem ser perseguidos pela equipe 
técnica para garantir que as necessidades dos usuários serão atendidas na 
medida certa.
Conceitos de medição
Existem termos que têm um significado específico quando se trata de medição. 
Vamos adotar aqui os conceitos utilizados na norma internacional ISO/IEC 15939 
(ISO/IEC, 2007), que é a norma da ISO/IEC que descreve o processo de medição. 
Os termos relevantes se encontram no Quadro 4.
Especificação dos requisitos não funcionais de software14
Fonte: Adaptado de ISO/IEC (2007).
Termo Significado
Atributo Propriedade ou característica de uma entidade que 
possa ser distinguida quantitativa ou qualitativamente 
por seres humanos ou meios automatizados
Dados Coleta de valores atribuídos a medidas base, medidas 
derivadas e/ou indicadores
Entidade Objeto que deve ser caracterizado medindo seus 
atributos
Escala Conjunto ordenado de valores, contínuo ou discreto, 
ou um conjunto de categorias para as quais o atributo 
está mapeado
Função de medição Algoritmo ou cálculo realizado para combinar duas ou 
mais medidas básicas
Indicador Medida que fornece uma estimativa ou avaliação de 
atributos especificados derivados de um modelo com 
relação a necessidades de informação definidas
Medição Conjunto de operações com o objetivo de determinar 
uma medida
Medida Variável à qual um valor é atribuído resultante de uma 
medição
Medida básica Medida definida em termos de um atributo e método 
para quantificá-lo
Medida derivada Medida que é definida como uma função de dois ou 
mais valores de medidas básicas
Medir Fazer uma medição
Procedimento 
de medição
Conjunto de operações, descrito especificamente, 
utilizado no desempenho de determinada medição de 
acordo com determinado método
Valor Resultado numérico ou categórico atribuído a uma 
medida básica, medida derivada ou indicador
Quadro 4. Definição de termos para medição
15Especificação dos requisitos não funcionais de software
A Figura 3, adaptada da norma ISO/IEC 15939 (ISO/IEC, 2007), apresenta 
os relacionamentos entre os elementos envolvidos na medição. Para que eles 
possam ser mais bem compreendidos, vamos utilizar um exemplo prático e 
fácil. Vamos supor que a necessidade de informação de um stakeholder seja 
identificar se a produtividade de sua equipe de desenvolvimento está compatível 
com a produtividade média do mercado.
Para atender a essa necessidade de informação vamos começar identifi-
cando as entidades envolvidas e quais são os atributos (características) dessas 
entidades que nós precisamos medir para atender à necessidade de informação. 
Nesse caso, a entidade pode ser a tarefa realizada e os atributos podem ser o 
tamanho da tarefa e o tempo necessário para desenvolver a tarefa.
Em seguida definimos qual é o método de medição envolvido. Neste caso 
precisamos saber como obter o valor do atributo de tamanho da tarefa e o valor 
do atributo do tempo. Se a tarefa for uma história de usuário, podemos utilizar o 
conceito de story points (pontos de história do usuário). Para o atributo tempo, 
podemos assumir que seja o tempo decorrido desde o início até o término da 
história do usuário. Portanto, nossas medidas básicas serão quantidade de 
pontos de história de usuário e tempo de desenvolvimento da história.
Muitas vezes temos que nos valer de métodos de medição mais subjeti-
vos (que envolvem o julgamento humano). Devemos evitá-los e dar sempre 
preferência a métodos mais objetivos, ou seja, que envolvem uma medição 
(contagem) a ser realizada de forma manual ou automatizada.
A função de medição será a forma como vamos combinar as duas me-
didas básicas para gerar a medida derivada. Nesse caso vamos considerar 
que a medida derivada será a produtividade e que a função de medição será 
a razão entre a quantidade de pontos de história de usuário pelo tempo de 
desenvolvimento da história.
Em seguida estabelecemos o modelo de análise, que é a forma como vamos 
analisar a medida derivada que acabamos de obter. Neste nosso exemplo, 
podemos entender que seria a forma como vamos interpretar a produtividade 
obtida. Aqui estão envolvidos os critérios de decisão, que poderiam envolver 
o seguinte: qual é o valor médio da produtividade no mercado para este tipo 
de produto, com esta tecnologia? Essa seria a base para poder interpretar a 
produtividade que foi obtida usando nossa função de medição. 
O que se obtém é um indicador, que pode nos dizer se a produtividade 
está abaixo do mercado, se a produtividade está na média do mercado ou se 
a produtividade está acima do mercado. Isso nos permite realizar a inter-
Especificação dos requisitos não funcionais de software16
pretação da informação, que é a explicação relacionada com a informação 
quantitativa expressa pelo indicador, em uma linguagem que a pessoa que vai 
usar a medição compreenda.
Figura 3. Modelo de Informação de Medição da ISO/IEC 15939.
Fonte: Adaptada de ISO/IEC (2007).
Necessidades
de informação
Entidade
Produto da informação
Interpretação
Indicador
Modelo de
análise
Medidas derivadas
Função de
medição
Medidas básicas
Método de
medição
Atributo Atributo
Método de
medição
Medidas básicas
A norma internacional ISO/IEC 15939 ISO/IEC (2007) apresenta mais detalhes sobre o 
processo de medição. Exemplos são fornecidos no Anexo A da norma, como forma 
de esclarecer os conceitos em contextos diferentes.
17Especificação dos requisitos não funcionais de software
Como definir indicadores de qualidade de produto
Na seção anterior vimos os conceitos de medição, vimos como esses conceitos 
se relacionam e vimos também umexemplo aplicado a uma medição do coti-
diano das empresas — a produtividade. Agora vamos ver como aplicar isso à 
qualidade do produto de software, ou seja, aos atributos que estão envolvidos 
em determinar se os requisitos não funcionais foram atendidos.
A família de normas internacionais da ISO/IEC que trata da qualidade dos 
produtos de software é a família 25000 (ISO/IEC, 2014). Entre esse conjunto 
abrangente de normas, podemos destacar as seguintes:
 � ISO/IEC 25022: Medição da qualidade em uso.
 � ISO/IEC 25023: Medição da qualidade de produto de sistemas e software.
 � ISO/IEC 25024: Medição da qualidade de dados.
A ISO/IEC 25022 (ISO/IEC, 2016a) trata da medição de aspectos rela-
cionados à qualidade em uso, ou seja, aqueles aspectos que são percebidos 
pelo usuário, quando ele usa o produto no ambiente-alvo. Seria, por exemplo, 
quando você utiliza um aplicativo no seu celular para pedir comida. Neste 
caso, haverá dois aspectos envolvidos na sua percepção de qualidade: um 
está relacionado ao serviço prestado e o outro, ao produto de software em si. 
E é bem comum confundir os dois!
Vamos imaginar que você queira pedir uma pizza individual e o aplicativo só mostre 
pizzas grandes. Esse certamente será um problema que vai deixar você muito insatis-
feito, mas esse não é um problema do app que você está usando, mas sim do serviço 
que está sendo prestado via app. O problema é da pizzaria, que não oferece a pizza 
do tamanho que você precisa.
Agora, se na hora que você for fechar o pedido, tiver dificuldade para conseguir 
localizar onde pode trocar o endereço de entrega, mesmo essa funcionalidade existindo 
no app, então esse é um problema de usabilidade do aplicativo. Ele provavelmente 
não tem uma interface intuitiva, uma vez que você não consegue localizar uma fun-
cionalidade. Esse sim é um requisito não funcional relacionado à usabilidade do 
produto e não ao serviço.
Especificação dos requisitos não funcionais de software18
Mas há limites menos óbvios para o usuário entre o que é um problema 
do produto e o que é um problema do serviço. Vamos continuar no exemplo 
da pizza: imagine que só é oferecida a forma de pagamento com cartão de 
crédito. Este é um problema do serviço ou do produto de software? Na verdade, 
depende. Pode ser que o aplicativo ofereça diversas formas de pagamento e 
o estabelecimento comercial optou por configurar apenas a opção de paga-
mento em cartão de crédito. Neste caso, é uma limitação do negócio e não do 
aplicativo. Já se o aplicativo não permitir o cadastramento de outra forma de 
pagamento, por mais que o estabelecimento permita, então é uma limitação 
do aplicativo, que causa desconforto ao usuário.
Certamente você já deve ter experimentado diversos aplicativos no seu 
celular. Alguns você achou fáceis e agradáveis de utilizar e outros você aban-
donou o uso porque não gostou deles. Às vezes os motivos de não ter gostado 
são fáceis de identificar, por exemplo: achei a tela muito poluída e ruim de 
navegar, os controles não estavam fáceis de localizar, o aplicativo vivia tra-
vando, não me sentia seguro em informar meus dados bancários etc. Mas, às 
vezes, você não consegue saber com certeza porque não gosta deste ou daquele 
aplicativo, e é aí que está o problema: utilizar um software é uma experiência 
que envolve diversas percepções, muitas delas difíceis de precisar, pois são 
mais sutis e subjetivas.
O que tentamos fazer ao definir medidas para avaliar os requisitos não 
funcionais é retirar o máximo que conseguimos das subjetividades e tornar a 
avaliação mais precisa. A ISO/IEC 25022 (ISO/IEC, 2016a) nos ajuda apre-
sentando as medidas que podem ser utilizadas para avaliar, de forma objetiva, 
a qualidade em uso de produtos de software.
A Figura 4 apresenta as características relacionadas à qualidade em uso, 
para as quais a norma apresenta as propostas de medidas.
19Especificação dos requisitos não funcionais de software
Figura 4. Características de qualidade em uso tratadas na ISO/IEC 25022.
Fonte: Adaptada de ISO/IEC (2016a).
E�ciência
Efetividade
Cobertura de
contexto
Livre de riscoSatisfação
A norma propõe um grupo de medidas referentes à efetividade, que são 
aquelas que avaliam a precisão e a completude com que o produto apoia as 
atividades do usuário. A norma sugere que podem ser usadas medidas como 
as seguintes:
 � percentual de tarefas que foram completadas sem ajuda, em relação ao 
total de tarefas que se tentou realizar;
 � percentual de objetivos que foram atingidos sem ajuda;
 � quantidade de erros cometidos pelo usuário ao realizar uma tarefa;
 � percentual de tarefas que tiveram erros cometidos pelo usuário;
 � proporção de usuários cometendo erros em tarefas.
É fácil imaginar que se o usuário comete erros realizando a tarefa no 
software, significa que o software não está ajudando o usuário a evitar esses 
erros. Se utilizarmos as medidas definidas acima, podemos identificar o 
tamanho do impacto que isso pode acarretar à experiência do usuário.
E como evitamos erros cometidos pelo usuário? Por exemplo, quando 
colocamos uma mensagem do tipo “Confirma a operação?”, estamos dando 
ao usuário a oportunidade de conferir o que ele realizou e de voltar atrás. 
É uma forma de chamar a atenção do usuário em pontos críticos, onde um erro 
Especificação dos requisitos não funcionais de software20
pode ter consequências mais graves. Esse é um recurso muito usado quando 
estamos finalizando uma operação bancária, por exemplo.
Medidas de eficiência também são propostas pela norma. Essas são as 
medidas que avaliam o uso dos recursos para que o usuário atinja os seus 
objetivos: podemos usar medidas simples, como o tempo que o usuário leva 
para fazer uma tarefa, ou podemos usar medidas mais complexas, como as 
listadas a seguir:
 � Eficiência em relação ao tempo — quantidade de tarefas que ele faz 
em determinado tempo (por exemplo, quantos novos cadastros ele 
consegue fazer por hora).
 � Eficiência em relação ao custo — custo para realizar as tarefas.
 � Proporção de tempo que o usuário está executando uma tarefa útil — 
tempo que o usuário realiza a tarefa real, em comparação ao tempo que 
ele gasta esperando o sistema se recuperar de um erro, por exemplo, ou 
o tempo que ele gasta pedindo ajuda.
 � Ações desnecessárias.
 � Consequências da fadiga — como a produtividade cai com o uso 
prolongado.
Uma medida muito interessante que pode ajudar em dois aspectos diferentes 
é a quantidade de ações desnecessárias que um usuário realiza para completar 
uma tarefa. Por exemplo, a quantidade de cliques errados que ele deu antes 
de conseguir chegar no item correto que ele precisava. Isso pode apontar 
uma ineficiência (tempo gasto em tarefas não úteis) e também um problema 
na usabilidade — se ele tem que clicar em diversos itens incorretos antes de 
achar o item correto, a interface não está intuitiva.
Um terceiro aspecto da qualidade em uso para o qual a norma define 
medidas é a satisfação. Ela visa a medir o grau de satisfação do usuário 
quando utiliza o software. Na norma, as medidas de satisfação estão dividi-
das em subcaracterísticas, que são as seguintes: utilidade, confiança, prazer 
(experiência do usuário), conforto (ergonomia).
Utilidade pode ser medida da seguinte forma:
 � medida de satisfação geral;
 � medida de satisfação com uma funcionalidade específica;
 � percentual de usuários que usa uma função em relação ao total que 
poderia utilizá-la;
21Especificação dos requisitos não funcionais de software
 � percentual de usuários reclamando do software;
 � percentual de reclamações dos usuários em relação a uma funcionalidade 
específica em relação às reclamações totais.
As subcaracterísticas de confiança, prazer (experiência do usuário) 
e conforto (ergonomia) podem ser medidas por meio de uma pesquisa de 
satisfação junto aos usuários do produto.
A quarta característica que a norma nos ajuda a gerar medidas em relação 
à qualidade em uso é o fato de o software ser livre deriscos (do original, em 
inglês freedom from risk). Riscos podem estar relacionados às subcaracterís-
ticas de riscos econômicos, riscos de saúde e segurança e riscos ambientais.
 � Os riscos econômicos estão mais relacionados a aspectos de negócio, 
como o retorno sobre o investimento (ROI), o momento para iniciar 
o ROI, a lucratividade com o uso do produto e o nível de serviço dos 
usuários, quantos visitantes de um website se tornam clientes, vendas 
para um cliente e prejuízos decorrentes do produto.
 � Os riscos de saúde e segurança se referem, como o próprio nome 
sugere, aos relatos de problemas de saúde ou de segurança decorrentes 
do uso do software. Esses indicadores são especialmente importantes 
quando estamos desenvolvendo sistemas de missão crítica que podem 
ocasionar perdas de vidas ou danos à sua segurança e saúde.
 � Finalmente, os riscos ambientais se referem a possíveis danos ao 
ambiente que o produto de software possa ocasionar. Dependendo do 
tipo de sistema, isso pode estar relacionado à poluição, poluição auditiva 
ou aquecimento global, por exemplo. 
A quinta e última característica que a norma aborda é referente à cobertura 
do contexto. Neste caso, são abordados dois aspectos: completude do contexto 
e flexibilidade. A medida de completude do contexto é mais específica e se 
refere ao quanto o contexto é coberto pelo software. Já as medidas sugeridas 
para a flexibilidade incluem o seguinte: 
 � contexto de uso flexível;
 � flexibilidade do produto;
 � independência de proficiência.
Especificação dos requisitos não funcionais de software22
Apresentamos nesta seção um resumo de algumas das sugestões realizadas pela 
norma internacional ISO/IEC 25022 (ISO/IEC, 2016a). Para maiores detalhes, a norma 
deverá ser consultada. 
BERG, V. et al. Software startup engineering: a systematic mapping study. Journal 
of Systems and Software, v. 144, p. 255–274, out. 2018. Disponível em: https://www.
researchgate.net/profile/Ilias_Pappas/publication/325858070_Software_Startup_
Engineering_A_Systematic_Mapping_Study/links/5c3dbfb3458515a4c726f927/Sof-
tware-Startup-Engineering-A-Systematic-Mapping-Study.pdf. Acesso em: 24 abr. 2020.
CLARRUS. Software quality attribute: following all the steps. [S. l.], 2010. Disponível em: 
https://www.clarrus.com/documents/Software%20Quality%20Attributes.pdf. Acesso 
em: 24 abr. 2020.
ISO/IEC. ISO/IEC 25000:2014: systems and software engineering, systems and software 
quality requirements and evaluation (SQuaRE), guide to SQuaRE. Switezland: ISO, 2014.
ISO/IEC. ISO/IEC 25022:2016: systems and software engineering, systems and soft-
ware quality requirements and evaluation (SQuaRE), measurement of quality in use. 
Switezland: ISO, 2016a.
ISO/IEC. ISO/IEC 25023:2016: systems and software engineering, systems and software 
quality requirements and evaluation (SQuaRE), measurement of system and software 
product quality. Switezland: ISO, 2016b.
ISO/IEC. ISO/IEC 25024:2015: systems and software engineering, systems and software 
quality requirements and evaluation (SQuaRE), measurement of data quality. Swite-
zland: ISO, 2015.
ISO/IEC. ISO/IEC/IEEE 15939:2017: systems and software engineering, measurement 
process. Switzerland: ISO, 2007.
PATTON, J. User story mapping: discover the whole story, build the right product. 
Sebastopol: O’Reilly, 2014.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3rd ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
23Especificação dos requisitos não funcionais de software
DICA DO PROFESSOR
Nem sempre é fácil realizar a elicitação de requisitos não funcionais de software. É comum que 
os stakeholders foquem a sua atenção sobre o que o software deve fazer, ou seja, sobre os 
requisitos funcionais, mas não em como o software deve fazer, ou seja, os requisitos não 
funcionais, também chamados de requisitos de qualidade. Frequentemente os requisitos não 
funcionais são esquecidos ou especificados em nível de detalhe insuficiente para poderem ser 
implementados e posteriormente validados. Muitas vezes, isso ocorre pela inexperiência do 
analista de requisitos em aprofundar esse tipo de requisito.
Nesta Dica do Professor, acompanhe algumas questões que podem apoiar o analista de 
requisitos na elicitação de requisitos não funcionais.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
1) Requisitos não funcionais estabelecem como o sistema deve funcionar e 
complementam os requisitos funcionais que dizem o que o sistema deve fazer. Um 
produto de software está sendo desenvolvido para apoiar a distribuição de doações 
arrecadadas e repassadas por uma ONG. O software será posteriormente usado para 
apoiar uma pequena empresa que vende produtos de artesãos locais. Para esse 
segundo negócio, espera-se haver adaptação de no máximo 30% do código.
Assinale a alternativa que indica que produto de software é esse.
A) Trata-se de um requisito de adaptabilidade.
B) Trata-se de um requisito de usabilidade.
C) Trata-se de um requisito de compatibilidade.
D) Trata-se de um requisito de operacionalidade.
E) Trata-se de um requisito de reusabilidade.
2) Requisitos não funcionais podem afetar sobremaneira a forma como os usuários 
aceitam o produto. Analise as afirmativas a seguir a respeito dos requisitos não 
funcionais de um software referentes à qualidade externa do produto:
I. “Um usuário sem treinamento deve ser capaz de instalar o produto em até 10 
minutos” é um requisito de instalabilidade.
II. “Apenas usuários com login e senha válidos terão acesso ao sistema” é um 
requisito de proteção.
III. “Um usuário sem treinamento deve ser capaz de localizar qualquer função sem 
clicar em nenhuma opção incorreta” é um requisito de eficiência.
Com base nas afirmações, assinale a alternativa correta:
A) I, II e III estão corretas.
B) I e II estão corretas. 
C) I e III estão corretas. 
D) II e III estão corretas. 
E) Apenas a alternativa II está correta. 
3) Um sistema está sendo desenvolvido para ser utilizado por qualquer cidadão comum 
para reportar problemas na rede elétrica. Ele será oferecido na forma de aplicativo 
para celular.
Considerando essas informações, identifique a alternativa que descreve o requisito 
não funcional mais importante sob a ótica do usuário:
A) Usabilidade.
B) Disponibilidade. 
C) Segurança. 
D) Proteção. 
E) Eficiência. 
4) Uma equipe de desenvolvimento foi contratada para desenvolver um software para 
monitoramento de pacientes transplantados. O produto será constituído de um 
avatar de um médico, que fará perguntas ao paciente, e, conforme as respostas, serão 
exibidas orientações para o paciente. Se as informações apontarem para uma 
emergência, o sistema deverá ser conectar automaticamente à central para que um 
médico real converse com o paciente. 
Nesse caso, que requisito seria mais importante?
A) Usabilidade.
B) Analisabilidade.
C) Integridade.
D) Autenticidade.
E) Interoperabilidade.
Não é possível avaliar um requisito não funcional se ele não estiver especificado por 
meio de um atributo mensurável. Considere os atributos definidos a seguir:
5) 
I. O software não poderá exceder o tempo de resposta de até 15 milissegundos em 
todas as suas funções de consulta ao banco de dados.
II. Um programador experiente deve localizar qualquer bug em, no máximo, 6 horas.
III. Períodos de não operação dentro do horário normal de trabalho (8:00-18:00h) 
não podem exceder 5 minutos no mês.
Assinale a alternativa que representa adequadamente o atributo de qualidade que 
esses indicadores podem medir:
A) Confiabilidade – capacidade –desempenho.
B) Desempenho – modificabilidade –disponibilidade.
C) Desempenho – desempenho –confiabilidade.
D) Confiabilidade – integridade –disponibilidade.
E) Robustez – integridade – disponibilidade.
NA PRÁTICA
É comum que o foco da elicitação de requisitosde produtos de software seja nos seus usuários. 
É raro que sejam considerados requisitos que afetam a equipe de desenvolvimento e 
manutenção. No entanto, uma vez implantado o produto, o restante de sua vida útil será 
dedicado à sustentação, ou seja, à realização de manutenções corretivas e para promover 
melhorias. Portanto, atributos relacionados à qualidade interna do produto passam a ter 
relevância. Para garantir que a estrutura interna do sistema seja robusta o suficiente para evoluir, 
os requisitos não funcionais relacionados à qualidade interna do produto devem ser levados em 
consideração desde o início.
Confira, Na Prática, o caso de Judy, uma analista de requisitos que recebeu a atividade de 
especificar os requisitos relacionados à qualidade interna de um sistema para revenda de 
produtos eletrônicos. Acompanhe os desafios de Judy e como ela tratou essa questão.
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Engenharia de software — uma abordagem profissional
Na obra de Roger Pressman e Bruce Maxim, leia o trecho sobre requisitos não funcionais 
usando FURPS+. Trata-se de uma abordagem para identificar requisitos não funcionais em 
projetos de software. Ela foi desenvolvida pela HP e hoje é usada em diversas empresas.
Desenvolvimento de software II [Série Tekne — IFRS]
Um dos requisitos não funcionais mais sensíveis ao usuário final de um sistema interativo é a 
qualidade da interface. Leia sobre esse assunto no Capítulo 3 de Desenvolvimento de software 
II, de Marcelo Soares Pimenta, Evandro Manara Pimenta e Karen Selbach Borges.
Os requisitos não funcionais agregam valor para as histórias de usuário
Os requisitos não funcionais agregam valor às histórias de usuário desde que sejam mensuráveis 
e que possam ser validados posteriormente. Veja como especificar os requisitos não funcionais 
em um cartão de história de usuário e acompanhe este exemplo divertido do dia a dia sobre a 
falta de parâmetros nas especificações de requisitos. Ative a legenda e assista!
Conteúdo interativo disponível na plataforma de ensino!
Como fazer uma interface mais fácil
Usabilidade é uma das propriedades que mais impactam na aceitação do sistema pelo usuário. E 
a questão é: como fazer uma interface fácil? Veja as dicas apresentadas neste vídeo, cheio de 
exemplos do dia a dia, incluindo interfaces que não são de software.
Conteúdo interativo disponível na plataforma de ensino!
Aplicação do diagrama de casos de uso
APRESENTAÇÃO
É inquestionável que a parte mais importante para o cliente de um projeto de software é receber 
o produto de que ele necessita e que ele tinha em mente quando o projeto começou. Nada 
importa mais para ele do que poder usufruir dos serviços providos pelo software da forma como 
ele imaginou, mesmo que ele não tivesse muita certeza sobre o que isso significava no início. O 
que ele deseja é uma boa experiência de utilização.
Cabe ao analista de requisitos providenciar que não haja diferença entre aquilo que o cliente 
imaginava e aquilo que ele está recebendo. Para isso, ambos têm à disposição as diversas 
ferramentas da engenharia de software, mais especificamente as ferramentas da engenharia de 
requisitos. E uma delas é o diagrama de casos de uso.
Nesta Unidade de Aprendizagem, você vai aprender a identificar a intenção dos atores que 
fazem parte de um cenário de negócios e como extrair, a partir daí, os requisitos funcionais. 
Além disso, vai aprender a projetar o diagrama de casos, uma importante ferramenta de 
comunicação entre os usuários e a equipe de desenvolvimento.
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Identificar a intenção dos atores primários em um cenário de negócio. •
Descobrir os requisitos funcionais de um software.•
Projetar um diagrama de casos de uso. •
DESAFIO
Uma das ferramentas que podem ser utilizadas para facilitar a comunicação entre a equipe de 
desenvolvimento e os usuários é o diagrama de casos de uso. Esse diagrama utiliza elementos 
gráficos simples, como o boneco palito (representando os atores), a elipse (representando os 
casos de uso) e setas (representando os relacionamentos).
A empresa onde você trabalha foi contratada por uma universidade para desenvolver diversos 
aplicativos para apoio às suas novas demandas. Você foi alocado para ser o analista de 
requisitos do primeiro aplicativo: um software de apoio para os estudantes intercambistas 
estrangeiros que chegam para estudar na universidade.
O analista de requisitos anterior elaborou o diagrama de casos de uso apresentado a seguir:
Seu gerente lhe pediu para verificar se esse diagrama está correto. Seu desafio é analisá-lo e emi
INFOGRÁFICO
O diagrama de casos de uso é um dos diagramas mais simples da UML e justamente por isso 
possui um grande poder de comunicação com o usuário. É fácil compreender os seus elementos 
e o que eles significam.
Se for adotado o diagrama de casos de uso combinado com o mapeamento de personas e com o 
Canvas da proposta de valor, é possível ter resultados bem mais eficientes para identificar os 
requisitos funcionais de um produto de software.
Confira, no Infográfico a seguir, as dicas para desenvolver um bom diagrama de casos de uso 
integrando essas ferramentas.
CONTEÚDO DO LIVRO
É frustrante para o usuário quando ele recebe um produto que não satisfaz as suas necessidades. 
Reconhecer as necessidades dos usuários não é uma tarefa trivial. Muitas vezes são discutidas 
funcionalidades que o sistema deve conter, mas não se discute por que elas devem estar lá, ou 
seja, quais dores do usuário serão tratadas com o software que está sendo desenvolvido. Muitas 
vezes se explora o espaço da solução e se deixa de lado o espaço do problema.
Abordagens centradas no usuário têm sido a forma que as empresas vêm utilizando para 
aproximar o mundo da tecnologia do mundo do usuário. Não adianta utilizar a tecnologia mais 
moderna se o que está implementado não atende aos anseios de quem vai utilizar. O diagrama 
de casos de uso é uma das formas de buscar o entendimento comum entre o mundo do cliente e 
o mundo da tecnologia, apoiando a elicitação dos requisitos funcionais do projeto.
No capítulo Aplicação do diagrama de casos de uso, da obra Engenharia de requisitos, você vai 
aprender a identificar as intenções dos atores que interagem com o sistema, utilizando para isso 
o Canvas de proposta de valor. Também vai discutir os requisitos funcionais e aprender a 
projetar um diagrama de casos de uso.
Boa leitura.
ENGENHARIA 
DE REQUISITOS
Sheila Reinehr
Aplicação do diagrama 
de casos de uso
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar a intenção dos atores primários em um cenário de negócio.
 � Descobrir os requisitos funcionais de um software.
 � Projetar um diagrama de casos de uso.
Introdução
Quando nos aproximamos de uma roda de desenvolvedores na hora do 
café, é comum que as conversas girem em torno da última tecnologia 
lançada, das tendências em frameworks e das ferramentas de desenvol-
vimento, se esta ou aquela linguagem de programação vai continuar 
fazendo sucesso, se é melhor usar este ou aquele padrão e assim por 
diante. Tecnologia é o que motiva o desenvolvedor! 
No entanto, embora a tecnologia seja um aspecto muito relevante, se 
a equipe de desenvolvimento não conseguir capturar adequadamente 
as necessidades e os desejos do usuário, não importa o quão proficiente 
e experiente ela seja com a tecnologia, o sucesso do projeto estará com-
prometido. Compreender o que deve ser entregue sempre foi, e continua 
sendo, um grande desafio. Identificar requisitos de software não é uma 
atividade trivial. Elicitar requisitos exige um conjunto de habilidades téc-
nicas e interpessoais que transcendem as habilidades com a tecnologia.
Diversos são os motivospelos quais essa tarefa é tão desafiadora. Um 
deles é que não existe uma receita mágica que funcione em todas as 
situações. A quantidade de variáveis envolvidas é muito grande, como, por 
exemplo: tipo do software que está sendo desenvolvido, complexidade 
do software, experiência da equipe de desenvolvimento com a área de 
negócio, grau de inovação do produto ou serviço, perenidade da solução 
e habilidades interpessoais (os chamados soft skills) da equipe. 
Essa dificuldade pode ser ainda maior quando o usuário já teve uma 
experiência ruim com um produto anterior ou, pior ainda, com o produto 
que está sendo desenvolvido ou modificado. Quando as suas expectativas 
já foram frustradas anteriormente, pode ser um desafio adicional para a 
equipe reverter a situação e curar as feridas.
Abordagens centradas no usuário têm sido a forma pela qual as or-
ganizações de tecnologia da informação (TI) têm buscado resolver essa 
questão. Entende-se por abordagem centrada no usuário aquela que 
coloca o usuário no centro do processo de desenvolvimento e foca na 
busca de valor agregado para ele. Este é um dos princípios das metodo-
logias ágeis: entrega rápida de valor ao cliente.
Uma das primeiras abordagens desse tipo na área de TI, foi a utilização 
dos diagramas de casos de uso propostos por Ivar Jacobson. Por meio 
de elementos gráficos simples, o diagrama apoia a comunicação entre 
a equipe de desenvolvimento e o usuário na descoberta dos requisitos 
funcionais. 
Mais recentemente, ferramentas desenvolvidas pela área de design 
têm sido também incorporadas como forma de apoiar o projeto de pro-
dutos e serviços que têm o usuário no centro do processo. Entre elas está 
o mapeamento da jornada do usuário, que busca identificar, não apenas 
as atividades que esse usuário realiza no processo, mas a forma como ele 
pensa e se sente ao realizar essas atividades, facilitando a identificação 
de elementos imprescindíveis no projeto de uma nova solução.
Neste capítulo você vai trabalhar com a aplicação do diagrama de 
casos de uso. Para isso vai ver como identificar as intenções dos atores ao 
utilizar o produto de software que está sendo desenvolvido, identificar 
os requisitos funcionais e por fim, projetar o diagrama de casos de uso. 
Também vai rever os conceitos envolvidos no diagrama de casos de uso 
e utilizar o mapeamento de personas e o canvas da proposta de valor 
para apoiar a sua construção.
1 Identificação da intenção dos atores
Vamos iniciar relembrando os conceitos do diagrama de casos de uso. 
O diagrama de casos de uso é um dos diagramas de comportamento da UML 
(GUEDES, 2018). Ele é usado para representar as funcionalidades do sistema, 
no formato de cenários ou casos de uso, conforme ilustrado na Figura 1:
Aplicação do diagrama de casos de uso2
 � a fronteira do sistema, representada pelo retângulo que separa o meio 
externo e o meio interno do sistema;
 � os atores, representados em forma de um boneco palito (stick man);
 � os casos de uso, representados em forma de elipse;
 � os relacionamentos entre os diversos elementos, representados pelas 
linhas.
Figura 1. Diagrama de casos de uso.
O diagrama de casos de uso é útil para representar os requisitos funcionais 
sob a ótica dos usuários do produto de software. Compreender quais são as 
intenções dos usuários com o produto que está sendo construído é o primeiro 
passo para iniciar uma descoberta efetiva de requisitos. O que o usuário 
deseja não é o produto em si, mas os efeitos do uso do produto no seu dia a 
dia. O que ele quer é uma experiência de uso satisfatória e que atenda às suas 
necessidades, sejam elas no campo dos negócios, sejam para a vida pessoal 
e o lazer. O que o usuário deseja é a transformação que o software traz à sua 
realidade (PATTON, 2014).
3Aplicação do diagrama de casos de uso
Usar a nova solução proposta deve trazer mais satisfação ao usuário do que 
a solução que ele tem atualmente. Isso vale para qualquer situação, seja quando 
estamos desenvolvendo um produto para substituição de um produto existente, 
seja para uma solução inovadora e que irá prover um serviço ainda inexistente. 
Naturalmente, nenhuma equipe de desenvolvimento tem o objetivo de 
criar uma solução que cause desapontamento e frustração ao cliente. Quando 
isso ocorre, não foi causado por uma ação deliberada ou premeditada pela 
equipe. Ninguém deseja entregar uma solução que não atenda ao cliente. Isso 
acontece porque um ou mais processos da equipe de desenvolvimento estão 
desalinhados. Frequentemente, esse processo é o de elicitação de requisitos. 
Kalbach (2016) ressalta que os desalinhamentos, em um sentido mais amplo, 
impactam toda a organização: as equipes não têm um propósito comum; as 
soluções são construídas desconectadas da realidade; o foco maior está na 
tecnologia em vez de na experiência; e as estratégias são desenvolvidas com 
uma visão muito curta. Em contraste, organizações alinhadas têm um modelo 
mental compartilhado que aponta para onde querem chegar e são obcecadas 
pela entrega de experiências extraordinárias para os seus clientes.
Colocar o usuário no centro do processo é uma das formas de evitar o desgaste 
de entregas insatisfatórias. Compreender as intenções das classes de usuários e 
mapeá-las como intenções dos atores que irão interagir com o software é uma 
das formas de reduzir a distância entre as expectativas e as entregas.
Fique atento ao que Jim Kalbach (2016) sugere sobre os pontos imperativos para que 
o alinhamento possa ocorrer:
 � foque as suas ofertas de fora para dentro em vez de dentro para fora — todos 
devem ter empatia com aqueles e quem servem; os indivíduos da organização 
devem se importar profundamente com os clientes e suas experiências, devem 
internalizar os desejos e as motivações das pessoas e devem ser defensores dos 
interesses delas em todas as suas atividades.
 � alinhe todas as funções internas em todos os níveis — os processos internos 
da organização estão tão relacionados com a experiência do usuário quanto os 
pontos visíveis da interação. Organizações alinhadas não focam em partes da 
experiência, mas sim na experiência como um todo.
 � crie visualizações como visão compartilhada — artefatos visuais ajudam a 
criar uma visão compartilhada. Eles não garantem o alinhamento, mas provocam 
discussões que promovem o alinhamento. Representações visuais são o must have 
(precisa ter) do alinhamento estratégico.
Aplicação do diagrama de casos de uso4
O mapeamento visual ajuda a compreender sistemas complexos de in-
teração, especialmente quando conceitos abstratos como experiência estão 
envolvidos. Mapear as experiências não é uma atividade que está limitada a 
um único diagrama, existem muitas perspectivas e abordagens (KALBACH, 
2016). Neste capítulo optamos por abordar o diagrama de casos de uso (Figura 
1) como ferramenta de representação das funcionalidades do sistema e da 
interação entre os atores e essas funcionalidades e o canvas da proposta de 
valor como forma de identificar as expectativas e experiências do usuário, 
de modo a obter as intenções dos atores. Juntas, essas ferramentas visam a 
apoiar o desenvolvimento centrado no usuário.
Definição da proposta de valor
De acordo com a UML (OBJECT MANAGEMENT GROUP, 2017, documento 
on-line), “Um ator especifica um papel que é desempenhado por um usuário 
ou qualquer outro sistema que interage com o sujeito”. Sujeito, neste caso, é 
o sistema que está sendo desenvolvido. Ator, portanto, pode ser um agente 
humano, que interage com o sistema, ou também outro sistema (que pode ser 
um hardware, outro software ou uma combinação deles). Para projetar um 
diagrama de casos de uso, inicialmente é preciso descobrir quem são os atores 
e que intenção eles têm com o sistema.
O primeiro passo para a definição da intenção dos atores é começar iden-
tificando a proposta de valor. Valor é aquilo que o cliente percebe como 
importante para ele e pelo qual está disposto a pagar. Valor não é o preço queo produto vai custar, valor é a relevância, a importância que o produto terá 
na vida do cliente.
Uma das formas de se mapear o valor é utilizando o modelo canvas de 
proposta de valor. A definição da proposta de valor é um dos elementos que 
fazem parte do canvas do modelo de negócios, proposto originalmente por 
Osterwalder (2004). Posteriormente, a proposta de valor foi destacada pelo 
mesmo autor em um diagrama próprio, conforme ilustrado na Figura 2.
5Aplicação do diagrama de casos de uso
Figura 2. Canvas de proposta de valor.
Do lado direito do diagrama fica a parte relacionada ao perfil do cliente 
e, do lado esquerdo, a parte relacionada à solução, ou seja, à proposta de 
valor. Como se pode observar, o objetivo é promover o alinhamento entre as 
expectativas do cliente, os produtos e serviços providos pela organização. 
Esse objetivo de alinhamento é representado pelas setas que saem de uma 
figura em direção à outra.
Esse modelo é muito versátil e pode ser utilizado em diversos tipos de 
situação, desde a modelagem do negócio de uma organização em si até a 
modelagem para a construção de um produto de software, como é o caso que 
utilizaremos neste capítulo. Esse diagrama também tem sido muito empregado 
nas fases iniciais de concepção e criação de startups. Nossa proposta é que ele 
sirva como um passo inicial antes da construção do diagrama de casos de uso.
E como esse diagrama é construído? Essencialmente em parceria com os 
stakeholders relevantes do projeto, em especial os usuários do produto que 
está sendo construído. Isto pode acontecer em uma seção de brainstorming ou 
workshop de requisitos. A forma mais prática é imprimir uma versão grande 
do diagrama (formato A0, por exemplo), que possa ser colada em uma parede 
e que permita que todos tenham acesso a ela para escrever suas contribuições 
em notinhas adesivas tipo Post-it®, que são fáceis de serem removidas, descar-
tadas, alteradas ou realocadas entre as seções do mapa. É comum que uma cor 
de Post-it seja utilizada para cada item do diagrama, facilitando a sua leitura.
Aplicação do diagrama de casos de uso6
O objetivo é que os participantes possam gerar o canvas de proposta de valor 
de forma participativa e colaborativa, de modo a estreitar o seu entendimento 
sobre as dores dos usuários e como a solução desenhada poderá trazer alívio 
para essas dores, concretizando os ganhos esperados.
O lado direito do diagrama diz respeito ao espaço do problema, ou seja, 
o perfil do cliente. Esse espaço é subdividido nas três seções, apresentadas 
a seguir,
 � Tarefas do cliente ( jobs): quais são as tarefas funcionais, sociais ou 
emocionais do lado do cliente.
 � Dores (pains): são aspectos adversos das tarefas do cliente que ele 
espera poder evitar — resultados indesejados, obstáculos e riscos.
 � Ganhos (gains): quais são os benefícios que o cliente deseja alcançar, 
quais são os ganhos financeiros, sociais, emocionais obtidos por meio 
da realização das tarefas.
O lado esquerdo do diagrama diz respeito ao espaço da solução, ou seja, 
o mapa de valor, que é subdividido em três seções também, listadas a seguir.
 � Produtos e serviços (products and services): a solução que está sendo 
construída.
 � Aliviadores de dores ou analgésicos (pain relievers): como resolver 
a dor do cliente? O que elimina a dor do cliente, seu estresse ou suas 
emoções negativas sobre o produto ou serviço?
 � Criadores de ganho (gain creators): o que o produto ou serviço oferece 
de ganho para o cliente, seja em termos de redução de custos, seja em 
emoções positivas ou ganho social?
Gerar o canvas da proposta de valor é mais que fazer um diagrama, é 
favorecer a comunicação entre os stakeholders e a equipe de desenvolvimento 
por meio de uma ferramenta gráfica simples, em uma interação que visa à 
cocriação para atingir um entendimento comum sobre o produto.
7Aplicação do diagrama de casos de uso
Veja aqui um exemplo do modelo canvas de proposta de valor, considerando o caso 
da Netflix. O cliente, do lado direito, deseja uma forma de assistir filmes e séries em 
diversas localidades, com qualidade e baixo custo. O provedor oferece serviço de 
streaming de vídeo on demand.
Infra de TI 
robusta para
não travar
Serviços de
streaming on
demand Pacotes compreços
acessíveis
Filmes sem
propaganda
no meio
Assistir em
qualquer lugar
e hora
Catálogo 
sempre
atualizado
Pacotes com
preços 
acessíveis
Conforto para
assistir séries 
e filmes
Custo mais 
baixo do que
ir ao cinema
Segurança de
não precisar
sair de casa
Maior 
integração
da família
Filmes com
propaganda
na TV a cabo
Catálogo
desatualizado
na TV a cabo
Ter horário
destinado na
TV a cabo
Lazer em casa
com a família
Caro ir no 
cinema com a 
família toda
Longas esperas
em aeroporto
Criadores de ganhos
Ganhos
Tarefas 
do cliente
Dores
Produtos e
serviços
Aliviadores de dor
Algumas dicas podem ajudar na construção do canvas da proposta de 
valor. Veja a seguir.
 � Comece identificando as personas que utilizarão o seu produto (per-
sonagens que representam uma classe real de usuários do sistema).
 � É possível, na mesma sessão, criar mais que um canvas de proposta de 
valor, cada um sob a perspectiva de uma persona. Pode-se, inclusive, 
ter grupos distintos trabalhando simultaneamente, cada um com um 
tipo de persona.
 � Prepare a sessão presencial com antecedência para que todas os stakehol-
ders essenciais para o seu produto possam estar presentes.
 � Prepare uma lista de perguntas que possam apoiar as reflexões dos 
participantes, para o caso de eles não conseguirem evoluir sozinhos.
Aplicação do diagrama de casos de uso8
 � Incentive fortemente que todos participem e coloquem sua opinião no 
quadro — especialmente suas dores e sua percepção sobre os ganhos 
que desejam.
 � Assim como em uma sessão de brainstorming, desestimule as críticas às 
colocações dos colegas para que todos possam se expressar livremente, 
sem o receio de serem criticados ou ridicularizados.
 � Ao final, faça uma rodada para a leitura e esclarecimento de todos os 
Post-it e para garantir o entendimento comum do que está registrado.
 � Se os participantes permitirem, a rodada final de leitura dos Post-
-it poderá ser gravada, de forma a facilitar a compilação e análise 
posteriormente.
 � Tenha em mente que o objetivo não é a construção do mapa em si, mas 
chegar a um entendimento comum sobre o que está sendo desenvolvido, 
por que está sendo desenvolvido e o que se espera como efeitos do uso 
do produto.
Para elaborar o canvas de modelo de negócios, acesse o link a seguir e utilize a cartilha 
elaborada pelo SEBRAE especialmente para explicar o uso dessa ferramenta.
https://qrgo.page.link/pWvX1
Intenção dos atores primários
Apresentamos, nas subseções anteriores, uma das ferramentas que vem sendo 
muito utilizada para ajudar a aprofundar o entendimento das necessidades 
de quem utilizará o produto que está sendo desenvolvido, ou seja, os atores 
humanos. Mas não esqueça que existem também os atores não humanos, como 
hardware e software com os quais o nosso sistema irá interagir. Vivemos em 
um mundo tecnologicamente integrado e é pouco provável que você venha a 
desenvolver um produto de software que não precise conversar com outro para 
realizar as suas funções de forma completa. Em tempos de internet das coisas 
(IoT, do inglês, internet of things) e equipamentos e serviços distribuídos, é 
importante identificar e compreender as necessidades dessas interfaces logo 
no início do projeto.
9Aplicação do diagrama de casos de uso
2 Descoberta dos requisitos funcionais
Como você observou na seção anterior, definir a intenção dos atores é um 
dos primeiros passos para chegar aos requisitos funcionais, ou seja, às fun-
cionalidades que devem ser providas pelo produto de software para atender 
a essas intenções. 
Existem diversas formas de elicitar os requisitos, e a escolha da técnica 
mais adequada vai depender do contexto do projeto, ou seja, do tipo de produto,do negócio, da disponibilidade de informações, da disponibilidade de fontes 
para obter essas informações, da experiência da equipe de desenvolvimento 
e mais uma dezena de aspectos particulares de cada projeto.
Algumas das técnicas mais utilizadas são:
 � entrevista;
 � reunião tradicional;
 � reunião no formato de JAD ( joint application design);
 � brainstorming;
 � questionário;
 � observação;
 � análise de sistemas anteriores;
 � análise de leis e regulamentações.
Não vamos discutir as técnicas de elicitação de requisitos neste capítulo, 
mas tenha em mente que você pode combiná-las para chegar ao melhor resul-
tado. Wiegers e Beatty (2013) oferecem boas dicas para apoiar essa seleção.
Ao elicitar os requisitos, é comum que eles venham em diferentes tipos e 
níveis de abstração. Alguns estarão relacionados ao produto de software em 
si, enquanto outros trarão informações em relação a restrições de projeto ou 
de processo, como data esperada de conclusão do projeto, uso de determi-
nada tecnologia, uso de determinado processo e desenvolvimento e assim 
por diante. Mesmo os requisitos de produto podem vir misturados entre os 
requisitos funcionais e os não funcionais (como desempenho, usabilidade, 
manutenibilidade, etc.)
O diagrama de casos de uso é excelente para elicitar os requisitos fun-
cionais, ou seja, as funções que o usuário necessita e que realizará por meio 
do produto de software. Histórias do usuário, utilizadas nos métodos ágeis, 
assemelham-se muito aos casos de uso, exceto que não têm uma forma gráfica 
de representação.
Aplicação do diagrama de casos de uso10
3 Como projetar o diagrama de casos de uso
O diagrama de casos de uso utiliza uma linguagem gráfica simples, composta 
por símbolos fáceis de rabiscar à mão livre, conforme vimos na Figura 1 no 
início deste capítulo. Apesar desta simplicidade, e talvez até por causa dela, 
ele possui um alto poder de comunicação. É fácil para um usuário leigo se ver 
realizando as tarefas representadas pelos casos de uso e apoiar a sua construção.
O diagrama de casos de uso se aplica aos requisitos funcionais, mas não 
foi criado para tratar os requisitos não funcionais.
Nível de abstração
Uma das primeiras dúvidas que surgem quando se começa a trabalhar com 
casos de uso é sobre o nível de abstração de um caso de uso. Até que nível 
se deve chegar no detalhamento de um caso de uso? E a resposta é: depende! 
À medida que você for usando essa ferramenta, vai sentir se detalhou de 
menos ou demais, e vai promovendo os ajustes para os próximos projetos ou 
as próximas sprints.
Para começar, você pode se basear na dica de um dos precursores dos 
métodos ágeis, Alistair Cockburn (2005). Ele considera três níveis de abstração 
para os objetivos de uma tarefa, utilizando uma metáfora da altitude, conforme 
ilustrado na Figura 3.
Um objetivo está no nível do mar quando se refere a uma tarefa que você vai 
realizar sem interrupção, ou seja, aquela que você “realiza em uma sentada”. 
Por exemplo, comprar um produto pela internet. Patton (2014) exemplifica 
dizendo que é o equivalente a uma tarefa do tipo tomar banho: você não para 
no meio do banho para tomar um cafezinho e voltar depois. Então essa é 
uma tarefa que está no nível do mar, ou seja, uma tarefa no nível do usuário. 
Cockburn (2005) diz que esse é um objetivo azul (blue goal), chama essas 
tarefas de tarefas em nível funcional e as representa como uma onda do mar. 
Todo o restante ou está acima ou abaixo do nível do mar.
11Aplicação do diagrama de casos de uso
Figura 3. Níveis de abstração dos casos de uso. 
Fonte: Adaptada de Cockburn (2005).
Cockburn (2005) considera que um objetivo está acima do nível do mar 
quando tem diversos objetivos no nível do mar a ele relacionados. Isso ocorre 
em três situações:
 � mostrar o contexto no qual o objetivo opera;
 � mostrar o ciclo de vida que os objetivos relacionados operam;
 � servir como uma espécie de índice para os objetivos abaixo dele.
Ele ainda divide esse nível em dois tipos: super sumário (nível bem abs-
trato) e sumário (nível abstrato). O primeiro é representado por uma nuvem e 
considerado como super branco (very white goal). O segundo é representado 
por uma pipa e considerado como branco (white goal).
Por fim, Cockburn (2005) considera que os objetivos que estão abaixo no 
nível do mar são as subfunções (indigo goals). Geralmente não precisamos 
listá-los, a menos que seja absolutamente necessário em termos de clareza e 
compreensão do escopo. A esses objetivos ele atribui a cor índigo e os compara 
com peixes. Ele brinca que existem casos de uso que são tão detalhados que 
estão no fundo do mar, como mariscos ou ostras, e são da cor preta (black 
goals). Estes não deveriam nem existir.
Aplicação do diagrama de casos de uso12
Diagrama de caso de uso na prática
A melhor forma de discutirmos as peculiaridades deste diagrama é por meio 
de um exemplo. Vamos ver um deles para ajudar a tirar as dúvidas sobre a sua 
construção. A Figura 4 apresenta o diagrama de casos de uso do aplicativo 
Livros On-line, que funcionará para a compra e leitura de livros de forma 
digital, como faz o aplicativo Kindle, por exemplo. Trataremos aqui apenas 
da parte que oferece as funcionalidades para o leitor e que será usada em 
dispositivos móveis (celulares e tablets). A parte de backoffice, que administra 
o negócio, não será tratada neste exemplo.
Figura 4. Diagrama de casos de uso do aplicativo Livros On-line.
Vamos começar pela fronteira do sistema. Um retângulo separa a parte 
interna do sistema da parte externa. O nome do sistema é colocado na parte 
superior desse retângulo. Os atores ficam do lado de fora, uma vez que são 
agentes externos ao sistema.
13Aplicação do diagrama de casos de uso
Inicialmente, identificamos três atores: o Leitor (que é o ator principal 
desse aplicativo), a Operadora de Cartão de Crédito (por meio da qual serão 
feitos os pagamentos) e o Dicionário (que é um sistema externo que, como 
o próprio nome diz, provê as funções de dicionário, incluindo a tradução de 
termos). Tanto a Operadora de Cartão de Crédito quanto o Dicionário são 
considerados atores secundários. Geralmente, colocam-se os atores principais 
do lado esquerdo do diagrama e os atores secundários do lado direito.
Note que não chamamos o Leitor de Cliente ou de Usuário, pois esses são 
nomes genéricos e pouco significativos. É recomendado optar por nomear os 
atores com um substantivo mais significativo para o contexto. Neste caso, o 
leitor.
Para que os requisitos desse Leitor possam ser adequadamente definidos 
podemos iniciar mapeando o perfil de leitores que, possivelmente, vão se 
interessar pelo aplicativo. Isso pode ser feito com o mapeamento das personas.
Vamos pensar em dois perfis distintos:
 � leitores que buscam por leitura técnica (não ficção);
 � leitores que buscam por leitura não técnica (ficção).
No primeiro perfil podemos pensar em professores, universitários, pesqui-
sadores e profissionais. Esse perfil pode desejar funcionalidades que facilitem 
suas pesquisas, como copiar uma citação e carregar junto com ela a referência 
do livro.
Já um perfil de uso doméstico, por exemplo, que utiliza o livro para leituras 
de lazer (livros de ficção), não necessita de uma função como essa, mas pode 
desejar compartilhar suas preferências com listas de leitores de um mesmo 
gênero, por exemplo, ou até mesmo montar um clube de leitura.
Pensar nos diferentes perfis nos ajuda a identificar requisitos funcionais 
ou não funcionais para essas classes específicas de usuários. Se quisermos 
atingir, por exemplo, um público com alguma deficiência visual, teremos que 
contemplar elementos na interface que facilitem a leitura para esse público, 
como aumento das letras ou até mesmo a leitura em áudio. Uma persona com 
essas características precisa ser então projetada.
Em seguida, identificamos três casos de uso principais que o Leitor pode 
realizar: ele pode Pesquisar Livros, Comprar Livros e Ler Livros. Noteque 
todos eles estão diretamente ligados ao ator principal, o Leitor. Esses casos 
de uso podem ser considerados, na visão de Cockburn (2005), como os do 
nível do mar.
Aplicação do diagrama de casos de uso14
Essas funcionalidades podem ser provenientes de diversas fontes, como já 
discutimos anteriormente neste capítulo. Uma delas pode ser o workshop para 
o mapeamento do canvas da proposta de valor. Geralmente diversas técnicas 
combinadas são usadas para essa finalidade.
Quando o Leitor estiver pesquisando um livro, ele pode, opcionalmente, 
solicitar uma amostra grátis. Isso é representado pelo relacionamento extend 
entre o caso de uso Pesquisar Livro e Solicitar Amostra Grátis. Neste mesmo 
ponto temos um relacionamento include entre Pesquisar Livro e Exibir Re-
comendações. Isso significa que toda vez que uma pesquisa for feita, serão 
exibidas recomendações similares à pesquisa. 
Qualquer Leitor pode Pesquisar Livros, mas, para comprar, esse Leitor 
deverá estar logado. Isso é representado pelo relacionamento include que existe 
entre Comprar Livro e Realizar Login. Se ele não tiver um cadastro, terá que 
Realizar Cadastro (relacionamento de extend). Se ele esqueceu a senha, pode 
acionar o Recuperar Senha (outro relacionamento de extend). 
A compra do livro é paga com cartão de crédito e dois atores são necessários 
para concluir essa transação: o Leitor e a Operadora de Cartão de Crédito. Caso 
houvesse mais que uma forma de pagamento, então seria possível utilizar o 
relacionamento de generalização para contemplar as demais formas.
O terceiro caso de uso principal que o ator Leitor pode executar é Ler 
Livro. Essa é a funcionalidade principal do aplicativo e a ela precisa ser dedi-
cada toda a atenção no momento de elicitação dos requisitos, para que sejam 
incorporadas funcionalidades que agreguem valor a cada um dos perfis que 
definimos (personas). Todos os relacionamentos com os casos de uso Ler Livro 
são do tipo extend, uma vez que não são obrigatórios, ou seja, o usuário pode 
ou não executar aquelas subfunções. Estão listados, neste caso: Recomendar 
Livro, Escrever Anotação, Compartilhar Citação, Copiar Trecho, Consultar 
Destaques Populares, Marcar Trecho e Pesquisar Termo.
Note que, para que o caso de uso Pesquisar Termo possa ser realizado, ele 
precisa do sistema externo Dicionário. Portanto, não se trata de uma funcio-
nalidade implementada internamente, mas de uma interface com um sistema 
externo. Isso é bastante comum no desenvolvimento de software, uma vez que 
é difícil termos sistemas isolados e que não se integram com outros.
Neste exemplo específico não tivemos a necessidade de mapear um ator 
do tipo hardware porque não temos nenhum hardware especial envolvido. Se 
tivéssemos, ele seria mapeado como um ator, utilizando a mesma simbologia 
(boneco palito), ou poderia usar um ícone (SEIDL et al., 2012). Utilizar ícones 
não é muito comum em diagramas de caso de uso na prática, mas é permitido 
pela UML (OBJECT MANAGEMENT GROUP, 2017).
15Aplicação do diagrama de casos de uso
Caso o nosso exemplo tivesse uma distinção entre um Leitor comum e 
um Leitor VIP, no qual houvesse algum tipo de privilégio para o Leitor VIP, 
então, a forma adequada de representar seria por meio do relacionamento de 
generalização, conforme demonstrado na Figura 5.
Figura 5. Diagrama de casos de uso do aplicativo Livros On-line com Cliente VIP.
Como se pode observar pela Figura 5, o Cliente VIP pode fazer tudo o que 
o Cliente faz. Ele herda todos os relacionamentos do Cliente normal e pode 
realizar um caso de uso adicional, que só ele pode realizar, que é Receber 
Benefícios. Essa é uma das formas de se representar este tipo de situação.
Esta situação aqui foi implementada no diagrama criando um novo tipo de 
ator, o Cliente VIP e um novo caso de uso, Receber Benefícios. Outra forma 
de fazer esta representação seria não inserir o ator adicional Cliente VIP, mas 
adicionar o caso de uso Receber Benefícios como um extend de outro caso de 
uso, em que o benefício fosse ser associado. Por exemplo, se ele tem direito a 
baixar alguns livros gratuitamente, esse caso de uso poderia estar relacionado 
com o caso de uso Pagar Livro. 
Aplicação do diagrama de casos de uso16
COCKBURN, A. Escrevendo casos de uso eficazes: um guia prático para desenvolvedores 
de software. Porto Alegre: Bookman, 2005.
GUEDES, G. UML2: uma abordagem prática. 3. ed. São Paulo: Novatec, 2018.
KALBACH, J. Mapping experiences: a guide to creating value through journeys, blueprints, 
and diagrams. Beijin: O´Reilly, 2016.
OBJECT MANAGEMENT GROUP. Unified Modeling Language®: OMG UML® v2.5.1. [S. l.], 2017. 
Disponível em: https://www.omg.org/spec/UML/About-UML/. Acesso em: 2 mar. 2020.
OSTERWALDER, A. The business model ontology: a proposition in a design science ap-
proach. 2004. Tese (Doutorado)- Université de Luasanne, Lausanne, 2004. Disponível 
em: http://www.hec.unil.ch/aosterwa/PhD/Osterwalder_PhD_BM_Ontology.pdf. 
Acesso em: 2 mar. 2020.
PATTON, J. User story mapping: discover the whole story, build the right product. Se-
bastopol: O´Reilly, 2014.
SEIDL, M. et al. UML@Classroom: an introduction to object-oriented modeling. Cham: 
Springer, 2012.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Redmond: Microsoft Press, 2013.
Leitura recomendada
SEBRAE. Cartilha O quadro de modelo de negócios: um caminho para criar, recriar e inovar 
em modelos de negócios. Brasília, DF: SEBRAE, 2013. Disponível em: www.sebrae.com.br/
Sebrae/Portal%20Sebrae/UFs/ES/Anexos/ES_QUADROMODELODENEGOCIOS_16_PDF.
pdf. Acesso em: 02 mar. 2020.
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
17Aplicação do diagrama de casos de uso
DICA DO PROFESSOR
O diagrama de casos de uso apresenta as funcionalidades que serão desenvolvidas para atender 
às necessidades dos stakeholders. Ele é um diagrama de comportamento da UML que se baseia 
em três elementos principais: ator, caso de uso e relacionamentos.
Embora seus elementos sejam simples, eles são ricos em semântica, ou seja, em significado. Por 
isso é importante prestar atenção aos detalhes de sua construção, para que você consiga 
efetivamente se comunicar de forma precisa.
Nesta Dica do Professor, você vai ver o exemplo de um aplicativo para uma seguradora e como 
os elementos do diagrama de caso de uso foram utilizados.
Conteúdo interativo disponível na plataforma de ensino!
EXERCÍCIOS
O diagrama de casos de uso representa funcionalidades do sistema com foco nas interações 
dos atores com os casos de uso. Considere o diagrama a seguir e analise as alternativas.
1) 
I – O ator A herda todos os casos de uso do ator B por meio do relacionamento de 
generalização, portanto ele pode executar todos os casos de uso do diagrama.
II – Toda vez que o caso de uso 5 for executado, o caso de uso 1 também será executado.
III – O ator A pode executar o caso de uso 4, que por sua vez chama o caso de uso 1 se uma 
determinada condição for satisfeita.
IV – O caso de uso 2 precisa do ator B e do ator C para ser executado.
Com base no diagrama de casos de uso e nas afirmativas acima, é correto afirmar que:
A) as alternativas I, II, III e IV estão corretas.
B) as alternativas I, II e IV estão corretas.
C) as alternativas III e IV estão corretas.
D) apenas a alternativa III está correta.
E) apenas a alternativa IV está correta.
2) Um analista de requisitos está modelando os requisitos de um sistema de compra de 
passagens aéreas utilizando o diagrama de casos de uso e levantou as seguintes 
informações:
I – Quando um passageiro comprar uma passagem, ele pode pontuar no programa de 
fidelidadese ele participar do programa de fidelidade da companhia aérea.
II – Quando um passageiro comprar uma passagem, ele pode ou não reservar um 
assento.
III – Quando um passageiro reservar um assento, ele deverá pagar uma tarifa 
adicional se não for passageiro VIP.
IV – Para comprar uma passagem, o passageiro deve estar logado.
A) I – Extend, II – Extend, III – Extend, IV – Extend.
B) I – Extend, II – Extend, III – Generalização, IV – Extend.
C) I – Include, II – Include, III – Generalização, IV – Include.
D) I – Extend, II – Extend, III – Extend, IV – Include.
E) I – Include, II – Include, III – Generalização, IV – Generalização.
3) Em um diagrama de casos de uso, os relacionamentos são representados por linhas que têm 
formatos e significados específicos, servindo de base para a interpretação semântica da 
relação.
O cliente pediu que o aluno possa entrar com um pedido de revisão de notas para o 
professor, via sistema, sempre que ele não concordar com a nota atribuída a uma avaliação.
Analise o diagrama a seguir e selecione a melhor forma de modelar essa nova situação:
A) Inserir um novo caso de uso Pedir revisão de notas e ligá-lo ao caso de uso Consultar notas 
usando um relacionamento de <<include>>.
B) Inserir um novo caso de uso Pedir revisão de notas e ligá-lo ao caso de uso Consultar notas 
por meio de um relacionamento de <<extend>>.
C) Inserir um relacionamento de <<extend>> entre o caso de uso Consultar notas e caso de 
uso Revisar notas.
D) Inserir um novo caso de uso Pedir revisão de notas e ligá-lo ao ator Aluno usando uma 
associação.
E) Inserir um caso de uso Pedir revisão de notas e ligá-lo ao ator Aluno e ao ator Professor 
usando associação.
4) Diversas ferramentas podem ser utilizadas para apoiar a modelagem do diagrama de 
casos de uso. Sobre essas ferramentas, analise as afirmações a seguir:
I. Para mapear as intenções dos atores de um sistema, pode-se utilizar o Canvas da 
proposta de valor.
II. Para mapear classes de usuários, pode-se utilizar a definição de personas.
III. Ao mapear as personas, todas as classes de usuários de um sistema estarão 
cobertas.
IV. As tarefas do cliente em um Canvas de proposta de valor serão os casos de uso do 
diagrama de casos de uso.
Assinale a alternativa correta:
A) I, II, III e IV estão corretas. 
B) I e II estão corretas. 
C) I, II e III estão corretas. 
D) I e IV estão corretas. 
E) I, II e IV estão corretas. 
5) O diagrama de casos de uso é uma importante ferramenta para ajudar a modelar os 
requisitos de um produto de software.
Analise as definições a seguir e assinale a alternativa correta sobre esse diagrama:
A) Um ator é um ser humano que executa os casos de uso do sistema. 
B) O diagrama de casos de uso representa requisitos funcionais e não funcionais. 
C) Cada caso de uso representa um requisito funcional. 
D) Um relacionamento de generalização só existe entre atores. 
E) Um sistema externo pode ser representado como um ator. 
NA PRÁTICA
Não basta um produto de software utilizar as tecnologias mais modernas e integradas, seja ele 
um aplicativo ou um site, se ele não for capaz de resolver a dor do usuário. Dores mal 
compreendidas se transformam em requisitos mal definidos e, portanto, podem levar à 
frustração no uso do produto ou até mesmo ao abandono de sua utilização.
O diagrama de casos de uso é uma ferramenta de fácil utilização para a comunicação entre a 
equipe de desenvolvimento e os clientes/usuários, na busca pela definição adequada dos 
requisitos. Ele é um dos diagramas de comportamento da UML e foi concebido utilizando 
elementos gráficos simples e de fácil compreensão e aplicação. Para apoiar a identificação dos 
atores envolvidos e suas dores, o Canvas da proposta de valor é outra ferramenta que pode 
ajudar a identificar o que agrega efetivamente valor sob a ótica do cliente.
Judy é uma analista de requisitos que irá atuar no desenvolvimento de um sistema de venda e 
entrega de material escolar. A missão dela é reverter a imagem ruim que o cliente tem da 
empresa. Para isso, ela precisa começar entendendo as intenções dos atores para, então, fazer o 
diagrama de casos de uso.
Acompanhe, Na Prática, os desafios de Judy e como ela organizou o seu trabalho desde o início 
para concluí-lo com sucesso.
Conteúdo interativo disponível na plataforma de ensino!
SAIBA MAIS
Para ampliar o seu conhecimento a respeito desse assunto, veja abaixo as sugestões do 
professor:
Personas
Este vídeo apresenta de forma prática e rápida o mapeamento de personas, o primeiro passo 
para identificar as intenções dos usuários. A ideia é criar empatia com os diversos tipos de perfis 
que utilizarão o sistema. Aproveite as ideias do vídeo e tente imaginar as personas envolvidas 
em um aplicativo como o Uber ou o 99Taxi.
Conteúdo interativo disponível na plataforma de ensino!
4 formas de descobrir a principal dor do cliente
O ponto de dor do cliente é basicamente o motivo pelo qual ele está buscando ajuda na sua 
solução. No mercado B2B, identificar essa dor significa fazer uma abordagem consultiva e 
oferecer uma solução que resolverá o problema do lead, correspondendo de imediato às 
expectativas dele.
Conteúdo interativo disponível na plataforma de ensino!
Como fazer um mapa da empatia
Neste vídeo Michel Winkler aborda o mapa da empatia, uma outra forma de compreender as 
necessidades do usuário, detalhando seu perfil e seu contexto. Confira as dicas que podem 
ajudar na elicitação de requisitos e definição da intenção dos atores dos casos de uso.
Conteúdo interativo disponível na plataforma de ensino!
Mapa da jornada do cliente (em inglês)
Este vídeo mostra de forma lúdica como compreender as jornadas de cada um dos tipos de 
usuários de uma cafeteria. Mostra cada persona (tipo de usuário) e como esse usuário gostaria 
de utilizar a cafeteria. É uma excelente maneira de você repensar a forma como enxerga os seus 
usuários e o que eles pretendem com o produto. Ative as legendas e confira.
Conteúdo interativo disponível na plataforma de ensino!
Modelagem de Processos
APRESENTAÇÃO
Você sabia que é possível prever como um processo vai funcionar antes mesmo de colocá-lo em 
prática? Isso é possível por meio da modelagem do processo, ou seja, por meio da criação de um 
modelo, que é uma representação da realidade e que pode ser avaliado e testado, prevendo seu 
funcionamento. Para isso, são utilizadas ferramentas e técnicas específicas. Nesta Unidade de 
Aprendizagem, você vai estudar os conceitos relacionados à modelagem de processos e 
diferenciar os conceitos de gestão por processos e gestão de processos. Além disso, vai estudar 
uma simbologia própria para modelar processos, o Business Process Model and Notation 
(BPMN).
Bons estudos.
Ao final desta Unidade de Aprendizagem, você deve apresentar os seguintes aprendizados:
Expressar os conceitos envolvidos na metodologia de modelagem de processos.•
Diferenciar os conceitos de gestão de processos e gestão por processos.•
Construir modelos utilizando a simbologia do Business Process Model and Notation 
(BPMN).
•
DESAFIO
Você é responsável pela gestão de uma empresa de prestação de serviços de tecnologia que atua 
em 30 grandes cidades do Brasil, tendo uma carteira com quase 1.000 clientes e um faturamento 
milionário.
A gestão de tantas unidades e de seus diferentes processos sempre foi um desafio e, para manter 
a competitividade da organização e identificar oportunidades de melhoria, você decidiu, junto 
com seu staff, criar um processo seletivo para trainees, que teriam como missão atuar na revisão 
dos processos de trabalho da organização e suas unidades. 
uniformização e a clareza das respostas, garantindo que sejam melhor compreendidas e 
avaliadas por você e seu staff, evitando o problema ocorrido na fase anterior, e como viabilizar o 
início imediato das ações de melhoria logo após encerrado o processo seletivo?
INFOGRÁFICO
A construção de produtose o desenvolvimento de processos são necessidades constantes das 
organizações que querem se manter no mercado e permanecer competitivas. No entanto, criar 
novos processos ou redesenhar os existentes para torná-los mais eficientes, eficazes e confiáveis 
exige tempo e utilização significativa de diversos recursos. Assim, modelar os processos é uma 
forma de verificar como eles funcionarão na vida real de uma forma mais rápida, barata e 
eficiente.
Veja no Infográfico como a criação de um modelo de processo de negócio pode ser útil para as 
organizações, bem como a simbologia Business Process Model and Notation (BPMN) pode ser 
utilizada para tal finalidade. 
 
CONTEÚDO DO LIVRO
Desenvolver novos processos ou modificar os existentes é uma atividade que envolve grande 
responsabilidade pelas implicações, pois todos os trabalhos que são executados nas organizações 
ocorrem por meio de processos. Dessa forma, um processo inadequado vai fazer com que a 
organização sofra severas consequências, colocando em risco sua competitividade.
É importante, então, "testar" os processos antes de sua efetiva implementação, o que pode ser 
feito mediante a modelagem dos processos. A modelagem permite que você possa estudar e 
prever o comportamento de determinado fenômeno sem a necessidade de produzi-lo de fato, o 
que seria complexo, caro e demorado.
Para saber mais sobre o tema, leia o capítulo Modelagem de processos, da obra Mapeamento e 
modelagem de processos, que serve como base teórica desta Unidade de Aprendizagem.
Boa leitura! 
MAPEAMENTO 
E MODELAGEM 
DE PROCESSOS 
Henrique Martins Rocha 
Modelagem de processos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Expressar os conceitos envolvidos na metodologia de modelagem 
de processos.
 � Diferenciar os conceitos de gestão de processos e gestão por processos.
 � Construir modelos utilizando a simbologia BPMN.
Introdução
Você sabia que é possível prever como um processo vai funcionar antes 
mesmo de colocá-lo em prática? Isso é possível por meio da modelagem 
do processo, ou seja, por meio da criação de um modelo que representa 
da realidade e que pode ser avaliado e testado, prevendo o funcionamento 
do processo. Para isso, são utilizadas ferramentas e técnicas específicas.
Neste capítulo, você vai ler a respeito dos conceitos relacionados à mo-
delagem de processos e diferenciar os conceitos de gestão por processos 
e de gestão de processos. Além disso, vai analisar uma simbologia própria 
para modelar processos: a Business Process Modeling Notation (BPMN).
Metodologia de modelagem de processos
A acirrada competição no mundo atual exige que as organizações estejam cons-
tantemente reformulando os seus produtos, serviços, as suas estratégias e, em 
especial, todos os processos relacionados. Antigamente, barreiras geográficas, 
limitações logísticas e de comunicação criavam barreiras mercadológicas que 
protegiam organizações instaladas em determinadas regiões.
Por exemplo, obter bens e serviços de um fornecedor mais distante re-
presentava um prazo muito mais longo para aquisição e recebimento, bem 
como severos impactos no custo, devido à distância a ser percorrida, ao 
frete, entre outros.
O cenário atual, porém, é completamente diferente: modernos sistemas 
produtivos, aliados a avançados métodos de logística e distribuição, fazem 
a competição deixar de ser local para se tornar global. Um exemplo claro 
está no fato de encontrarmos tantos produtos fabricados em países asiáticos 
comercializados no Brasil a preços tão baixos.
Além disso, os avanços em tecnologias de informação e comunicação, com 
destaque para a massificação do uso da internet, permitiram que houvesse 
uma mudança substancial na dinâmica de mercado: empresas, fornecedores e 
clientes têm acesso instantâneo a bens e serviços. Dessa forma, a velocidade 
exigida para as organizações se adaptarem às novas situações e oportunidades 
é cada vez maior. 
Porém, criar novos produtos, serviços e processos reais em um ambiente 
tão mutável é algo bastante desafiador e, em muitos casos, praticamente invi-
ável, devido aos custos envolvidos e ao alto risco de perdas substanciais pela 
quantidade de variáveis envolvidas. Surge, assim, como estratégia, a modela-
gem, caracterizada como uma representação total ou parcial de um elemento, 
conjunto ou sistema físico e real, que pode ser utilizada para descrever, testar 
ou predizer o comportamento do sistema físico em situações específicas.
Como destaca Ferreira (2013a, p. 47):
As organizações do século XXI para permanecerem ativas precisam estar em 
constante mudança. Tais mudanças acontecem por meio de implementação 
de novos conceitos, os quais surgem geralmente na forma de modelos, que 
são bastante diversificados e incluem um conjunto de técnicas aplicadas à 
melhoria das atividades organizacionais sempre buscando retratar a realidade 
do que se deseja modelar.
A modelagem seria o ato de criar tal representação: maquete, modelo eletrô-
nico, equação ou algoritmo, modelos matemáticos, gráficos ou textuais, entre 
outros. Especificamente abordando o contexto de processos, Baldam, Valle 
e Rozenfeld (2014) definem um modelo como uma representação (com maior 
ou menor grau de formalidade) abstrata da realidade, em um dado contexto.
De acordo com a Associação dos Profissionais de Gerenciamento de Pro-
cessos de Negócios (ABPMP) (2013), a modelagem de processos compõe (junto 
à análise, ao desenho, ao gerenciamento de desempenho e à transformação 
de processos) as atividades-chave e o conjunto de habilidades necessárias ao 
gerenciamento de processos do negócio, como mostrado na Figura 1. 
85Modelagem de processos
Figura 1. Ciclo de gerenciamento de processos.
Fonte: ABPMP (2013, p. 52).
Com essa representação simplificada da realidade (o modelo), é possível 
suportar o estudo da atual situação (conhecida como AS–IS), analisá-la, 
redesenhá-la, medir seu desempenho e prover as transformações necessárias 
para a sua melhoria, levando a novos patamares de desempenho dos processos 
(conhecido como TO–BE) e, por conseguinte, das organizações (ABPMP, 
2013). De acordo com Ferreira (2013a, p. 77), a modelagem TO–BE “[...] 
consiste na representação gráfica de um processo a ser implementado ou a 
proposição de um novo [...]. Nesta etapa, as interações com os clientes, as 
diferentes oportunidades de melhorias identificadas na situação atual do 
processo, e a da caixa-preta devem ser observadas”. 
A expressão caixa-preta se refere ao não detalhamento de um processo (ou de um 
grupo de processos), por se tratar de participantes externos ao processo estudado. 
Por exemplo, os processos de um cliente externo que receba determinado serviço ou 
produto provavelmente não serão detalhados no modelo que representa a realidade 
da empresa que os fornece.
Modelagem de processos86
Mais do que um exercício de construção de um modelo, a modelagem deve 
considerar o detalhamento da representação e a padronização na sua constru-
ção, de forma que o modelo possa ser compreendido por todos os envolvidos. 
Para isso, há associações que estabeleceram simbologias específicas para 
mapeamento e modelagem de processos, além de serem fóruns de discussão 
e troca de experiências e práticas sobre o gerenciamento de processos: a 
ABPMP, a American Productivity & Quality Center (APQC) e a Business 
Process Management Group (BPMG). 
Para saber mais sobre gerenciamento e modelagem de processos, explore o site da 
ABPM Brasil:
http://www.abpmp-br.org/
A ABPMP é uma associação internacional de profissionais de business process manage-
ment (BPM), sem fins lucrativos, independente de fornecedores e dedicada à promoção 
de conceitos e práticas de gerenciamento de processos de negócio.
Pavani Junior e Scucuglia (2011, p. 49) destacam que “um modelo nunca será 
uma representação integral e completa do processo real, mas se concentrará em 
focalizar atributos que suportem uma análisecontinuada”. Da mesma forma, 
Baldam, Valle e Rozenfeld (2014, p. 248) defendem que “Nenhum modelo 
corresponde exatamente à realidade, com todas as facetas e complexidade 
que o mundo real pode apresentar; todos apenas a representam, de um modo 
que parecerá mais adequado ou menos adequado, de acordo com o contexto, 
os atores e as finalidades da modelagem”.
Assim, a modelagem permite que possamos estudar e prever o comporta-
mento de determinado fenômeno sem a necessidade de produzi-lo de fato, o 
que seria complexo, caro e demorado. No lugar disso, a criação de um modelo, 
configurado conforme a necessidade da análise, podendo ser bastante simples 
ou mais completo e sofisticado, torna-se uma escolha sensata. 
A modelagem do processo é, dessa forma, uma parte importante da gestão 
de processos, que, na opinião de Ferreira (2013b, p. 22), “[...] é uma aborda-
gem administrativa e se apresenta com uma abrangência muito reduzida em 
87Modelagem de processos
comparação com a gestão por processos, que é um estilo de gerenciamento 
da própria organização”.
Gestão de processos e gestão por processos
Ferreira (2013b, p. 18) define a gestão (ou gerência) de processos como “o 
conjunto de ações sistemáticas, baseadas em métodos, técnicas e ferramentas 
de análise, modelação e controle, que permitem manter estável a rotina e 
implantar melhorias na qualidade dos processos”. 
A noção de estabilidade da rotina está relacionada a processos previsíveis, 
ou seja, processos que gerem continuamente as saídas esperadas e previstas, 
sem desvios acentuados. Por exemplo, se o processo de controle da tempera-
tura do ambiente de trabalho foi desenvolvido para garantir temperaturas por 
volta dos 23°C, adequado ao conforto das pessoas e à manutenção do bom 
funcionamento dos equipamentos instalados no local, a entrada e saída de 
pessoas do ambiente, o ato de ligar e desligar determinados equipamentos, 
as limitações nas vedações, as perdas térmicas e as próprias variações nos 
equipamentos de controle de temperatura farão com que ocorram variações 
da temperatura do ambiente, por exemplo, para mais ou menos 2°C.
No entanto, ainda que compreendamos que ocorram variações, elas não 
podem ser excessivas. Por exemplo, não seria aceitável uma variação, para 
mais ou para menos, de 10°C, visto que, se há uma temperatura ideal, o afas-
tamento excessivo comprometeria o conforto, por tornar o ambiente muito 
frio ou muito quente, podendo, também, comprometer o funcionamento de 
computadores e outros equipamentos eletrônicos.
Ou seja, se a temperatura ideal é 23°C, afastamentos começam a compro-
meter o bom andamento e os resultados dos processos, gerando insatisfação 
crescente dos envolvidos quanto maior for tal afastamento. Genichi Taguchi 
(1924–2012) caracterizou tal aspecto com o conceito de perdas para a socie-
dade (COLLIN; PAMPLONA, 1997), visto que os desvios do ideal compro-
metem processos, que comprometem o desempenho de produtos, serviços, 
instalações, pessoas e sistemas, gerando perdas para todos. Tais perdas podem 
ser calculadas pela denominada função perda, que representaria, por exemplo, 
insatisfação, reclamações, gastos com devoluções ou assistência técnica, perdas 
de vendas, entre outros, como observado na Figura 2.
Modelagem de processos88
Figura 2. Variação da insatisfação em função da temperatura.
Fonte: Adaptada de Fowlkes e Creveling (1995, p. 35).
Repare que ficar dentro dos limites considerados normais e aceitáveis, 
como, por exemplo, mais ou menos 2°C (ou seja, entre 21 e 25°C), não garante a 
plena satisfação (o que só acontece quando estamos no valor nominal, referente 
à temperatura de 23°C). Na realidade, intuitivamente, é fácil perceber que a 
satisfação/insatisfação não ocorre em degraus ou saltos súbitos: se assim fosse, 
a temperatura de 25°C seria geradora de 100% de satisfação, por estar dentro 
dos limites, enquanto um décimo de grau acima disso, ou seja, a temperatura 
de 25,1°C, traria total insatisfação por estar fora dos limites.
Observamos que, conforme a Figura 2, o grau de insatisfação começa a 
subir conforme nos afastamos dos 23°C: inicialmente, há pouca insatisfação, 
mas ela cresce muito rapidamente conforme nos afastamos mais. Além disso, 
os limites (21 e 25°C) representam algo como 50% de satisfação, o que faz 
sentido, por estar justamente no limite do aceitável: uma situação limítrofe. 
Afastamentos maiores fazem a insatisfação crescer fortemente, chegando ao 
limite de total recusa/inaceitação das condições.
89Modelagem de processos
Para saber mais sobre Taguchi e a sua função perda, leia o texto Taguchi: conheça a 
função perda de Taguchi (FM2S, 2016).
Note que alcançar e manter a estabilidade, citada por Ferreira (2013b), não 
deve ser o único foco: para se manter competitiva, a organização deve buscar a 
constante melhoria dos seus processos, afinal, como defendido por Baldam, 
Valle e Rozenfeld (2014), o processo excelente de ontem torna-se bom hoje e 
obsoleto amanhã. Ou seja, a organização deve implantar melhorias na quali-
dade dos processos, as quais podem estar relacionadas à redução da variação: 
por exemplo, ainda utilizando o exemplo da temperatura, um processo mais 
robusto poderia garantir que a temperatura variasse somente um grau para 
cima ou para baixo. Pelo conceito explorado pela função perda, isso garante 
maior satisfação dos envolvidos.
Plan, Do, Check, Act (PDCA), Kaizen, benchmarking, Método de Análise e 
Solução de Problemas (MASP), Desdobramento de Função Qualidade (QFD), 
Método Taguchi, Análise dos Modos de Falha e seus Efeitos (FMEA) e Define, 
Measure, Analyse, Improve e Control (DMAIC) são algumas ferramentas e 
métodos utilizados para melhoria contínua de processos.
Para saber mais sobre essas ferramentas, leia os artigos de Abreu (1997), Carvalho, Ho 
e Pinto (2007), Fernandes e Rebelato (2006), Fernandes e colaboradores (2012), Pessoa 
e colaboradores (2010), Vasconcellos, Canen e Lins (2006) e Vivian, Ortiz e Paliari (2016).
A gestão de processos corresponde, então, conforme Ferreira (2013b, p. 
21), ao “esforço de estabelecer sistemas de trabalho submetidos a descrições, 
mensurações e controles das atividades em função do que foi planejado”, ou 
seja, conforme o autor, monitorar os processos para manter a conformidade e 
os resultados pretendidos. Assim, conforme Pavani Junior e Scucuglia (2011, 
p. 61), o gerenciamento de processos engloba:
Modelagem de processos90
Estudo do trabalho — processo de observação e levantamento de informações 
de um fenômeno, com o objetivo de detalhar sua lógica (mapeamento).
Entendimento do trabalho — observar o fenômeno após o levantamento de 
informações obtidas no estudo do trabalho, com o objetivo de compreender 
suas particularidades e entender sua lógica.
Otimização do trabalho — procedimento contínuo de aperfeiçoamento 
sistêmico e sistemático da estrutura de trabalho, com base nos conhecimentos 
obtidos no entendimento do mesmo; 
Manutenção do trabalho — manter o trabalho dentro dos padrões de eficácia 
e eficiência previstos, bem como a melhoria contínua.
Por outro lado, segundo Ferreira (2013b, p. 21), a gestão por processo se aplica a 
algo bem mais abrangente: “gerir a organização, considerando a interação entre os 
processos e entre esses e o ambiente”. Para tanto, passamos a ter organizações orien-
tadas (ou estruturadas) por processos, nas quais suas estruturas organizacionais 
são pensadas, desenhadas e aplicadas com base nos seus processos estratégicos. 
“A lógica é a dinâmica da organização em prol de resultados efetivos e não mais a 
visão compartimentada de uma abordagem funcional” (FERREIRA, 2013b, p. 20), 
na qual as organizações constituem unidades funcionais verticalizadas, isoladas, 
porém organizadas de forma hierárquica, operando com pouquíssima interação.
Ferreira (2013b, p. 22) destaca que, apesar das diferenças entre os conceitos 
de gestão de processos e gestão por processos, há forte vínculo entre eles, uma 
vez que “A organizaçãoorientada por processos precisa, necessariamente, de 
processos bem monitorados, caso contrário inviabiliza a possibilidade de tê-los 
funcionando eficientemente em rede ou de forma sistêmica”.
Características e vantagens da gestão por processos
De acordo com Ferreira (2013a), a gestão por processos exige que a organi-
zação atenda a alguns requisitos, quais sejam:
1. clareza de missão e objetivos;
2. identificação e definição dos processos críticos (relacionados aos fatores 
críticos de sucesso da organização e aos seus objetivos estratégicos);
3. definição dos serviços e/ou produtos que pretendem oferecer em função 
de um público determinado (cliente ou usuários);
91Modelagem de processos
4. disponibilidade dos recursos necessários para gerar os serviços ou 
produtos pretendidos;
5. capacidade para gerenciar o fluxo de informações e as atividades 
necessárias para atingir os resultados pretendidos e a satisfação dos 
clientes ou usuários.
A aderência da organização a tais características e a sua decisão de se 
redesenhar para se tornar uma organização de gerenciamento por processos 
trazem as seguintes vantagens para a organização (FERREIRA, 2013b):
 � inserir-se em um contexto de organizações mais versáteis e dinâmicas;
 � a organização se desenvolve além do seu desempenho básico;
 � direciona os esforços para resultados, por meio da melhoria efetiva dos 
processos essenciais;
 � mudança cultural (de visão por função para visão do todo, holística e 
integradora);
 � facilita a gestão do conhecimento organizacional;
 � permite a compreensão de como funciona a organização, revelando 
problemas, estrangulamento e ineficiências;
 � redução de custos (retrabalho e problemas logísticos, por exemplo) e 
conflitos;
 � aumento da satisfação dos clientes ou usuários (cidadãos e colaboradores);
 � concentra o foco no que realmente interessa;
 � facilita a gestão das competências;
 � proporciona flexibilidade organizacional (descentralização, organização 
em rede, alianças estratégicas entre organizações).
Simbologia BPMN
Ainda que existam inúmeras metodologias para modelar processos, a BPMN 
(também conhecida como Business Process Model and Notation, que cor-
responde respectivamente à notação de modelagem de processos de negócio, 
à notação e ao modelo de processos de negócio) é dominante (BALDAM, 
VALLE, ROZENFELD, 2014), por resolver uma série de lacunas existentes 
em outros métodos de modelagem (PAVANI JUNIOR. SCUCUGLIA, 2011). 
BPMN (Business Process Modeling Notation) é uma notação que permite 
representar todas as atividades internas de um processo de forma que o mes-
Modelagem de processos92
mo possa ser analisado e simulado. A notação é formada por um conjunto de 
imagens que são dispostas na forma de diagrama para representar os proces-
sos, e dessa forma, demonstrar o seu real funcionamento (UNIVERSIDADE 
FEDERAL DE MATO GROSSO, 2017, p. 16).
Ao escolher uma notação, devemos considerar as especificidades da orga-
nização, uma vez que os símbolos podem ser utilizados para modelagem de 
diferentes aspectos de processos de negócios, descrevendo relacionamentos cla-
ramente definidos. O BPMN utiliza os seguintes grupos de notações (ABPMP, 
2013; UNIVERSIDADE FEDERAL DE MATO GROSSO, 2017, p. 17-24):
Eventos — podem ser de início, término ou intermediários em um processo.
A Figura 3 apresenta os eventos de início.
Figura 3. Eventos de início.
Fonte: Universidade Federal de Mato Grosso (2017).
93Modelagem de processos
A Figura 4 apresenta os eventos intermediários.
Figura 4. Eventos intermediários.
Fonte: Universidade Federal de Mato Grosso (2017).
Modelagem de processos94
A Figura 5 apresenta os eventos de término.
Figura 5. Eventos de término.
Fonte: Universidade Federal de Mato Grosso (2017).
95Modelagem de processos
Desvios de fluxo — indicam razões para as tomadas de decisões em fluxos 
de processos (Figura 6).
Figura 6. Desvios de fluxo.
Fonte: Universidade Federal de Mato Grosso (2017).
Modelagem de processos96
Tarefas — unidade de trabalho a ser executada por uma pessoa ou sistema 
(Figura 7).
Figura 7. Tarefas.
Fonte: Universidade Federal de Mato Grosso (2017).
97Modelagem de processos
Subprocessos — conjuntos de atividades executadas dentro de um processo 
de negócio (Figura 8).
Figura 8. Subprocessos.
Fonte: Universidade Federal de Mato Grosso (2017).
Modelagem de processos98
Conectores — elos lógicos entre outros elementos (Figura 9).
Figura 9. Conectores.
Fonte: Universidade Federal de Mato Grosso (2017).
Piscinas — organizam os processos em um diagrama, com cada piscina 
contendo um único processo de negócio. Cada piscina deve ter um evento 
de início (seu primeiro elemento) e pelo menos um evento de fim (seu último 
elemento, mesmo que o processo continue em outra piscina). Na comunicação 
entre piscinas, deve-se usar fluxo de mensagem (seta pontilhada) e evento de 
mensagem na piscina que recebe a informação. O fluxo da piscina deve ser 
totalmente relacionado pelas setas (Figura 10).
Figura 10. Piscinas.
Fonte: Universidade Federal de Mato Grosso (2017).
Raias — não representam uma notação específica, mas uma construção útil, 
pois separam os participantes internos de uma piscina (áreas funcionais, 
99Modelagem de processos
papel ou organizações externas), ou seja, cada raia é definida como um papel 
desempenhado por um ator na realização do trabalho (Figura 11).
Figura 11. Raias.
Fonte: Universidade Federal de Mato Grosso (2017).
Milestones — linhas tracejadas utilizadas para separar o processo em diferentes 
partes ou em sequência (início, meio e fim) (Figura 12).
Figura 12. Milestones.
Fonte: Universidade Federal de Mato Grosso (2017).
Modelagem de processos100
Um fluxo simples, como o mostrado na Figura 13, não necessita de piscinas 
ou raias.
Figura 13. Processo simples.
Fonte: ABPMP (2013, p. 93).
No entanto, se você deseja mapear ou modelar processos mais complexos ou 
quer detalhá-los, outros elementos começam a ser utilizados, como podemos 
ver nas Figuras 14 a 17.
Figura 14. Processo com mais detalhes.
Fonte: ABPMP (2013, p. 93).
101Modelagem de processos
Figura 15. Processo com piscinas.
Fonte: Universidade Federal de Mato Grosso (2017, p. 25).
Figura 16. Processo com raias.
Fonte: ABPMP (2013, p. 104).
Modelagem de processos102
Figura 17. Processo com raias.
Fonte: ABPMP (2013, p. 94).
Os símbolos de subprocessos contraídos podem ser utilizados, também, 
para simplificar o fluxo e facilitar a visualização e compreensão dos processos, 
como mostrado na Figura 18.
Figura 18. Processo em alto nível.
Fonte: ABPMP (2013, p. 93).
103Modelagem de processos
ABPMP. BPM CBOK Guia para o gerenciamento de processos de negócio corpo comum 
de conhecimento. V3.0. [São Paulo]: BPM, 2013. Disponível em: <http://c.ymcdn.com/
sites/www.abpmp.org/resource/resmgr/Docs/ABPMP_CBOK_Guide__Portuguese.
pdf>. Acesso em: 21 set. 2017.
BALDAM, R.; VALLE, R.; ROZENFELD, H. Gerenciamento de processos de negócio — BPM: 
uma referência para implantação prática. Rio de Janeiro: Elsevier, 2014.
COLLIN, L. R. O; PAMPLONA, E. O. A utilização da função perda de Taguchi na prática 
do controle estatístico de processo. ENEGEP, 32. Bento Gonçalves, 1997. Anais... Rio 
de Janeiro: Abepro, 1997. Disponível em: <http://www.abepro.org.br/biblioteca/
enegep1997_t4410.pdf>. Acesso em: 21 set. 2017.
FERREIRA, E. A. Modelo para condução de mapeamento de processo organizacional: uma 
abordagem BPM com base no MAIA. 233f. 2013. Dissertação (Mestrado em Ciência 
da Informação) – Universidade de Brasília, Brasília, 2013a.
FERREIRA, A. R. Gestão de processos; módulo 3. Apostila do programa de desenvolvi-
mento de gerentes operacionais – DGO. Brasília: ENAP / DDG, 2013b.
FM2S. Taguchi: conheça a função perda de Taguchi. 2016. Disponível em: <http://www.
fm2s.com.br/taguchi-conheca-funcao-perda-de-taguchi/>. Acesso em: 21 set. 2017.
FOWLKES, W. Y.; CREVELING, C. M. Engineering methods for robust product design: using 
taguchi methods