Engenharia de

Requisitos
PROFESSORA
Esp. Janaina Aparecida de Freitas

ACESSE AQUI O SEU

LIVRO NA VERSÃO
DIGITAL!
 EXPEDIENTE
DIREÇÃO UNICESUMAR
Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de
Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino
de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi

NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA

Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Graduação e Pós-graduação Kátia
Coelho Diretoria de Cursos Híbridos Fabricio Ricardo Lazilha Diretoria de Permanência Leonardo Spaine Diretoria de
Design Educacional Paula R. dos Santos Ferreira Head de Graduação Marcia de Souza Head de Metodologias Ativas
Thuinie M.Vilela Daros Head de Recursos Digitais e Multimídia Fernanda S. de Oliveira Mello Gerência de
Planejamento Jislaine C. da Silva Gerência de Design Educacional Guilherme G. Leal Clauman Gerência de Tecnologia
Educacional Marcio A. Wecker Gerência de Produção Digital e Recursos Educacionais Digitais Diogo R. Garcia
Supervisora de Produção Digital Daniele Correia Supervisora de Design Educacional e Curadoria Indiara Beltrame

FICHA CATALOGRÁFICA

Coordenador(a) de Conteúdo C397 CENTRO UNIVERSITÁRIO DE MARINGÁ.

Flavia Lumi Matuzawa Núcleo de Educação a Distância. FREITAS, Janaina Aparecida
de.
Projeto Gráfico e Capa
André Morais, Arthur Cantareli e Engenharia de Requisitos. Janaina Aparecida de Freitas.
Maringá - PR: Unicesumar, 2022.
Matheus Silva
Editoração 184 p.
Nivaldo Vilela de Oliveira Junior ISBN 978-85-459-2124-0
Design Educacional
“Graduação - EaD”.
Rodrigo Cabrini Dall Ago
1. Engenharia 2. Requisitos 3. Software. 4. EaD. I. Título.
Curadoria
CDD - 22 ed. 620
Carla Fernanda Marek
Revisão Textual
Ariane Andrade Fabreti
Ilustração
Geison Ferreira da Silva e Eduardo Impresso por:
Aparecido Alves
Fotos
Bibliotecário: João Vivaldo de Souza CRB- 9-1679
Shutterstock

NEAD - Núcleo de Educação a Distância

Av. Guedner, 1610, Bloco 4 Jd. Aclimação - Cep 87050-900 | Maringá - Paraná
www.unicesumar.edu.br | 0800 600 6360
A UniCesumar celebra os seus 30 anos de história
avançando a cada dia. Agora, enquanto Universidade,
ampliamos a nossa autonomia e trabalhamos diaria-
mente para que nossa educação à distância continue
Tudo isso para honrarmos a
nossa missão, que é promover
como uma das melhores do Brasil. Atuamos sobre
a educação de qualidade nas
quatro pilares que consolidam a visão abrangente
diferentes áreas do conhecimento,
do que é o conhecimento para nós: o intelectual, o
formando profissionais
profissional, o emocional e o espiritual.
cidadãos que contribuam para
A nossa missão é a de “Promover a educação de o desenvolvimento de uma
qualidade nas diferentes áreas do conhecimento, for- sociedade justa e solidária.
mando profissionais cidadãos que contribuam para o
desenvolvimento de uma sociedade justa e solidária”.
Neste sentido, a UniCesumar tem um gênio impor-
tante para o cumprimento integral desta missão: o
coletivo. São os nossos professores e equipe que
produzem a cada dia uma inovação, uma transforma-
ção na forma de pensar e de aprender. É assim que
fazemos juntos um novo conhecimento diariamente.

São mais de 800 títulos de livros didáticos como este

produzidos anualmente, com a distribuição de mais
de 2 milhões de exemplares gratuitamente para nos-
sos acadêmicos. Estamos presentes em mais de 700
polos EAD e cinco campi: Maringá, Curitiba, Londrina,
Ponta Grossa e Corumbá, o que nos posiciona entre
os 10 maiores grupos educacionais do país.

Aprendemos e escrevemos juntos esta belíssima

história da jornada do conhecimento. Mário Quin-
tana diz que “Livros não mudam o mundo, quem
muda o mundo são as pessoas. Os livros só
mudam as pessoas”. Seja bem-vindo à oportu-
nidade de fazer a sua mudança!

Reitor
Wilson de Matos Silva
Janaina Aparecida de Freitas
Possui graduação em Informática pela Universidade
Estadual de Maringá (2010) e especialização em MBA em
Teste de Software pela Uniceuma (2012). Atualmente, cur-
sa o Programa de Mestrado em Ciência da Computação
na Universidade Estadual de Maringá (UEM), também é
graduanda em Letras Português/Inglês na Unicesumar.
Atua como professora mediadora, professora conteudis-
ta em gravação de aulas ao vivo e em gravação de aulas
conceituais nos cursos do NEAD – Núcleo de Educação a
Distância da Unicesumar, para os cursos de graduação de
Sistemas para Internet, Análise e Desenvolvimento de Sis-
temas, Gestão da Tecnologia da Informação e Engenharia
de Software, nas disciplinas de Engenharia de Software,
Design Gráfico, Tópicos Especiais, Gerenciamento de Soft-
ware, Design de Interação Humano-Computador, Projeto
Implementação e Teste de Software, há três anos. Além
disso, tem experiência na iniciativa privada, na área de
Análise de Sistemas e Testes de Software.
ENGENHARIA DE REQUISITOS

Prezado(a) aluno(a), seja bem-vindo(a) à disciplina de Engenharia de Requisitos. Este li-

vro foi desenvolvido para você, que fica encantado(a) com as inúmeras funcionalidades
que os softwares oferecem aos usuários. Com base nisso, quero te convidar a pensar
sobre algumas provocações fundamentais:
■ Por que entender os requisitos de um problema ou de uma necessidade de um
cliente, está dentre uma das tarefas mais difíceis que o engenheiro de software
enfrenta no mercado de trabalho?
■ Conhecer os conceitos fundamentais da nossa área — os tipos de requisitos
de software, a priorização e, depois, a maneira de organizar os requisitos em
um documento de requisitos de software — torna mais fácil a solução para
resolver este problema?
Com o objetivo de te auxiliar na busca por estas respostas a essas provocações
fundamentais que, aliás, julgo necessárias para você entender a nossa disciplina, pro-
curei abordar assuntos interessantes e importantes que te ajudarão a entender como
a Engenharia de Software é importante e como ela está presente no nosso dia a dia, em
tudo o que usamos. Afinal, é tão difícil entender, claramente, o que o cliente deseja? E
este questionamento nos faz pensar: por que o cliente não sabe o que é necessário, a
partir do momento que é ele quem está solicitando o sistema?
A resposta é: muitos usuários finais não têm bom entendimento das características
e funcionalidades necessárias ao sistema, dificultando o entendimento, por parte do
engenheiro de software, do que o cliente, realmente, deseja que seja desenvolvimento.
Então, para resolver esta dificuldade, recomendo entender os conceitos e definições
sobre a Engenharia de Requisitos. Desse modo, o ideal é compreender como ela está
inserida dentro da Engenharia de Software bem como entender os processos do ciclo
de vida do software e aprofundar-se no conhecimento da atividade de especificação
de software. Por quê? Pelo fato de esta atividade ser, também, conhecida como Enge-
nharia de Requisitos, a qual é o processo de descobrir, analisar, documentar e verificar.
Dentro deste aprofundamento, te convido a ler a primeira unidade, onde abordei os
conceitos introdutórios da Engenharia de Requisitos e a sua importância no processo de
desenvolvimento de software. É importante que você compreenda este início, entenda
que temos tipos de requisitos e que eles devem ser priorizados, depois, organizados
dentro de um Documento de Requisitos de Software.
Sabe por que isso é importante? Porque esse documento de requisitos será utiliza-
do por outras equipes dentro da empresa, como: desenvolvedores, programadores,
arquitetos de software, testadores, implantadores e o pessoal do suporte. Eles depen-
dem da clareza e do suficiente detalhamento, para cumprir com a sua função, a qual
é desenvolver o software solicitado pelo cliente.
A fim de continuarmos na nossa jornada de busca pelas respostas, te instigo
a partir para a segunda unidade, na qual abordei os processos e as atividades respon-
sáveis por garantir a especificação de bons requisitos de software. É aqui que você
aprenderá a respeito dos processos da Engenharia de Requisitos, a como realizar o
levantamento e a análise de Requisitos de Software. É importante estar a par de todo
esse processo, para que você não tenha sustos com o cliente falando: “você não en-
tendeu o que eu disse, pois o que eu disse não era o que eu quis dizer”. Além disso,
é necessário compreender como são a verificação e a validação dos Requisitos de
Software e, também, como realizar a especificação desses requisitos.
Preparado(a) para continuar na busca por respostas? Seguindo: na terceira unidade,
você aprenderá sobre as fontes de informação usadas na realização do levantamento
dos requisitos de software. Fontes de informação? Sim, entender de onde vem as infor-
mações, a fim de realizar uma coleta de requisitos, durante o desenvolvimento de um
software, e a coleta inicia-se pela identificação de quais fontes de informação podem
ser usadas, para compreender as necessidades dos clientes e a forma de interagir com
eles. O processo de coleta dos requisitos tem, como objetivo, definir e documentar as
características dos produtos e serviços do projeto que satisfarão às necessidades e às
expectativas dos usuários do sistema. Com o intuito tanto de compreender quanto
interagir com o cliente e usuário, você precisa conhecer algumas técnicas de coleta de
requisitos de software e como as selecionar de acordo com o contexto do que será
desenvolvido.
Em seguida, o que fazer com esse levantamento de requisitos? É necessário que
você especifique os requisitos de software. Na quarta unidade, você aprenderá como
realizar uma especificação de requisitos funcionais, utilizando os Casos de Uso e His-
tórias de Usuário, além de realizar a especificação de requisitos para um cenário de
negócios e, depois, aplicar indicadores a fim de avaliar esses requisitos, por meio de
critérios de qualidade de requisitos de software.
Espero que você esteja conseguindo chegar a alguma resposta às aprovações ge-
radas! Bem, desenvolver um sistema é algo que exige a interpretação bem como a de-
dução do que o cliente quer, e você viu que isso nem sempre é fácil. Agora, te provoco
mais: como resolver isso? Você aprendeu várias formas e técnicas de levantamento de
requisitos e como os documentar. E se eu te falar que esses requisitos podem mudar
ao longo do desenvolvimento do sistema? Mais assustador ainda, concorda?
E tenha uma certeza: os requisitos mudam por várias razões, por exemplo: o clien-
te, às vezes, não sabe o que deseja, pois, leis e normas do negócio se alteram ou o
cliente quer algum recurso tecnológico novo no sistema. Desse modo, como ficam os
requisitos coletados e aprovados? A resposta é que eles precisam ser gerenciados.
Aqui, incentivo você a fazer uma imersão na Unidade 5, para entender como funciona
o gerenciamento de requisitos e como realizar a rastreabilidade de requisitos e o con-
trole de mudanças, além de como construir uma matriz de rastreabilidade. No final,
você entenderá a maneira de preencher um template da matriz de rastreabilidade de
requisitos de software.
Assim, convido você, caro(a) aluno(a), a entrar nesta jornada com empenho, dedi-
cação e muita sede de conhecimento. Boa leitura e ótimos estudos!
RECURSOS DE
IMERSÃO
REALIDADE AUMENTADA
Sempre que encontrar esse ícone,
esteja conectado à internet e inicie
o aplicativo Unicesumar Experien-
ce. Aproxime seu dispositivo móvel
da página indicada e veja os recur-
sos em Realidade Aumentada. Ex-
plore as ferramentas do App para
saber das possibilidades de intera-
ção de cada objeto.
RODA DE CONVERSA
Professores especialistas e convi-
dados, ampliando as discussões
sobre os temas.
PÍLULA DE APRENDIZAGEM
Uma dose extra de conhecimento
é sempre bem-vinda. Posicionando
seu leitor de QRCode sobre o códi-
go, você terá acesso aos vídeos que
complementam o assunto discutido.
Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar
Experience para ter acesso aos conteúdos on-line. O download do
aplicativo está disponível nas plataformas:
PENSANDO JUNTOS
Ao longo do livro, você será convida-
do(a) a refletir, questionar e trans-
formar. Aproveite este momento.
EXPLORANDO IDEIAS
Com este elemento, você terá a
oportunidade de explorar termos
e palavras-chave do assunto discu-
tido, de forma mais objetiva.
NOVAS DESCOBERTAS
Enquanto estuda, você pode aces-
sar conteúdos online que amplia-
ram a discussão sobre os assuntos
de maneira interativa usando a tec-
nologia a seu favor.
OLHAR CONCEITUAL
Neste elemento, você encontrará di-
versas informações que serão apre-
sentadas na forma de infográficos,
esquemas e fluxogramas os quais te
ajudarão no entendimento do con-
teúdo de forma rápida e clara
Google Play App Store
CAMINHOS DE
APRENDIZAGEM

1
11 2
51
FUNDAMENTOS PROCESSOS DA
DA ENGENHARIA
ENGENHARIA DE REQUISITOS
DE REQUISITOS

3
81 4 117
TÉCNICAS DE ESPECIFICAÇÃO
ELICITAÇÃO DE DE REQUISITOS
REQUISITOS DE DE SOFTWARE
SOFTWARE

5
149
GERENCIAMENTO
DE REQUISITOS
DE SOFTWARE
1
Fundamentos da
Engenharia de
Requisitos
Esp. Janaina Aparecida de Freitas

Nesta unidade, você conhecerá os conceitos introdutórios da Engenha-

ria de Requisitos e a sua importância no processo de desenvolvimen-
to de software, além disso, detalharemos os conceitos fundamentais
e as etapas para compreender esta área. Também conheceremos e
compreenderemos os tipos de Requisitos de Software e como reali-
zar a priorização, depois, como os organizar em um Documento de
Requisitos de Software.
UNIDADE 1

Você já parou para pensar por que é tão difícil entender, claramente, o que o
cliente deseja? Uma das situações tidas como o pior pesadelo de um engenheiro
de software é quando o cliente fala: “você não entendeu o que eu disse, pois o que
eu disse não era o que eu quis dizer” e, ainda, isso acontecer no final do projeto.
Mas, afinal de contas, o cliente não sabe o que é necessário? Os usuários
finais não deveriam ter bom entendimento das características e funcionalidades
que o sistema deveria possuir? Surpreendentemente, em muitos casos, a resposta
a estas perguntas é “não”. Porque, mesmo se os clientes e usuários finais fossem
explícitos quanto às suas necessidades em relação a um sistema, elas mudariam
ao longo do projeto e, muitas vezes, eles não têm o conhecimento técnico para
estabelecer a melhor solução ao problema que querem resolver.
Entender os requisitos de um problema ou de uma necessidade de um cliente
é uma das tarefas mais difíceis enfrentadas pelo engenheiro de software, pois
há muitas dificuldades para fazer o levantamento das necessidades do cliente e
para entender as informações por ele transmitidas. Devido a essas dificuldades,
os requisitos são registrados de forma desorganizada e pouco tempo é investido
na organização ou gerenciamento dessas informações, portanto, quando as mu-
danças vêm, o cenário torna-se mais assustador, mesmo entre gerentes e desen-
volvedores experientes.
A fim de entender melhor como este panorama pode ser assustador, contarei
uma situação que aconteceu comigo. Na época, estava trabalhando como analista
de sistemas em uma empresa que desenvolvia sistemas para autopeças, os quais
eram customizados de acordo com as necessidades de seus clientes, com isso,
ocorriam muitas mudanças, em função de alterações tributárias ou por causa
da inclusão de novas tecnologias que estavam surgindo ou de novas funciona-
lidades. Um dos clientes de uma empresa de autopeças importadas solicitou a
inclusão de uma nova funcionalidade no módulo financeiro do sistema, na tela
do Contas a Receber.
Realizamos uma reunião com o cliente, para que ele explicasse a nova fun-
cionalidade a ser implementada. Ele explicou que queria um cálculo de juros
simples em cima de cheques emitidos pelos clientes para pagamento das contas e
dívidas. Essa reunião foi gravada e, no final, escrevemos uma ata, a qual o cliente
leu e assinou, estando de acordo e autorizando a implementação.
Após a implementação da nova funcionalidade no módulo financeiro, foram
realizados os testes de aceite pelo cliente, mas, para a nossa surpresa, o cálculo

12
 UNICESUMAR

de juros estava errado. Como a reunião havia sido gravada, ela foi revisada, jun-
tamente, com o cliente, então, ele disse: “vocês entenderam errado, pois não era
o que eu quis dizer, pois o que eu disse não era o que eu queria que fosse feito”.
Como assim? Na tentativa de entender o que o cliente queria e não soube explicar,
pedimos que ele exemplificasse, no papel, como calculava os juros. Surpreenden-
temente, era cálculo de juros composto e não simples, neste caso, o cliente não
tinha conhecimento técnico para estabelecer a melhor solução ao problema o
qual ele desejava resolver.
Agora, imagine que você é novo(a) em uma empresa de desenvolvimento de
software e não conhece nem a empresa, nem os produtos que ela desenvolve. Você
foi contratado(a) para substituir o analista de sistemas, porém esta pessoa, além
de não ter cumprido o aviso prévio, sequer se preocupou em deixar explicadas a
rotina e as atividades da função.
Eis que surge uma reunião de emergência para a verificação de problemas ocor-
ridos com a última atualização do sistema de um cliente, então, você percebe o
seguinte: o seu gerente pensa que você e o antigo colaborador são a mesma pessoa!
Ele começa a te fazer várias perguntas sobre os requisitos alterados na última versão.

13
UNIDADE 1

O que você faria diante de um cenário assustador como este? Registre, em seu
Diário de Bordo, quais atitudes você tomaria nesta situação. Pegue, como exem-
plos, situações as quais você já viveu em sua vida profissional ou aquelas viven-
ciadas por seus amigos.
A princípio, o cenário apresentado parece preocupante, mas, se você conhece
os conceitos fundamentais sobre a Engenharia de Requisitos — os tipos de requi-
sitos de software, a priorização e como realizar a organização dos requisitos em
um documento próprio para isso — a solução começa a surgir.
Se a empresa e o antigo colaborador elaboraram uma documentação voltada
às funcionalidades incluídas, utilize-a junto com o seu conhecimento, então, você
conseguirá resolver a situação!

14
 UNICESUMAR

Para você entender o quanto a Engenharia de Requisitos é relevante durante o

desenvolvimento de um software, é necessário identificar em qual momento ela
se encaixa no contexto da Engenharia de Software. Portanto, refrescarei a sua
memória relembrando, rapidamente, alguns conceitos fundamentais do processo
de software e, depois, contextualizarei a Engenharia de Requisitos.

Atividades fundamentais do processo de software

Durante a produção de um software, são necessárias diversas fases/etapas, as quais

são compostas por várias tarefas. Este conjunto de fases/etapas chama-se processo
de software. Ele deve, sempre, cumprir todas os estágios estabelecidos para ele.
Mas, o que é um processo de software? Ele é considerado um conjunto
de atividades/tarefas necessárias para definir, desenvolver, testar e manter um
produto de software de alta qualidade. É uma abordagem adaptável cuja intenção
é, sempre, entregar um software, com qualidade, dentro do prazo e seguindo o
orçamento estipulado.

Atividade: é considerada um esforço para atingir um objetivo amplo. É uti-

lizada independentemente do campo de aplicação, do tamanho do projeto
ou da sua complexidade.

Ação: envolve um conjunto de tarefas que resultam em um artefato.

Tarefa: concentra-se em um objetivo bem definido, produzindo um re-

sultado tangível.

Segundo Pressman e Maxim (2021, p. 20), o processo de software é definido como

“uma metodologia para as atividades, ações e tarefas necessárias para desenvolver
um software de alta qualidade”. Os objetivos desse processo são: (i) definir quais
atividades serão executadas ao longo do projeto; (ii) quando, como e por quem
tais atividades serão executadas (Figura 1).

15
UNIDADE 1

Quais ou o que Quando Como Quem

Figura 1 - Representação dos objetivos do processo de software / Fonte: a autora

Descrição da Imagem: ilustração que mostra a representação dos objetivos do processo de software.
A imagem do notebook representa “quais” atividades ou “o que” será realizado; a imagem do relógio
representa “quando” as atividades serão executadas; a imagem da engrenagem representa “como” serão
desenvolvidas; a imagem de “personas” representa “quem” as realizará.

A Figura 2, a seguir, mostra a representação de um processo geral.

Melhore
Pergunte

Crie

Imagine

Planeje
Figura 2 - Representação de um processo geral / Fonte: a autora.

Descrição da Imagem: ilustração que mostra a representação de um processo geral, onde temos cinco
etapas indicadas por retângulos, em sentido horário. A primeira etapa é “Pergunte”, seguida por “Imagine”,
depois, “Planeje”, em seguida, “Crie”, fechando com a etapa “Melhore”.

16
 UNICESUMAR

Temos, na Figura 2, a representação de um processo geral com cinco etapas,

nesta ordem:
1. Pergunte: etapa a qual busca identificar qual o problema ou a necessidade
do cliente.
2. Imagine: aqui, são criadas algumas soluções, algumas alternativas à ne-
cessidade.
3. Planeje: corresponde ao momento de projetar ou modelar o que é ne-
cessário para a próxima etapa.
4. Crie: nesta etapa, a solução planejada é produzida.
5. Melhore: a solução é validada e testada.

Para um processo ser considerado eficaz, segundo Pressman e Maxim (2021),

devemos considerar: (i) as relações entre as atividades a serem desenvolvidas; (ii)
os artefatos que serão produzidos durante o desenvolvimento; (iii) as ferramentas
as quais, durante o desenvolvimento, poderão ser úteis; (iv) os procedimentos
que serão necessários; (v) a habilidade, o treinamento e a motivação da equipe
do projeto.
Os processos devem ser definidos caso a caso, considerando as especificações
da aplicação a ser desenvolvida, a tecnologia a ser adotada na sua construção, a
organização de onde o produto será desenvolvido e as características da equipe
de desenvolvimento. Além disso, temos alguns fatores passíveis de influenciar a
definição de um processo, como: o tipo de software a ser desenvolvido, o para-
digma adotado, qual o domínio da aplicação e quais os tamanho e complexidade
da aplicação.

17
UNIDADE 1

A Figura 3, a seguir, apresenta a visão das fases de um projeto.

Análise e
especificação
Domínio do MUNDO de requisitos
problema REAL (o quê?)

Domínio da Projeto (como?)

solução

Implementação e
MUNDO Validação
COMPUTACIONAL

Figura 3 - Fases do projeto / Fonte: a autora.

Descrição da Imagem: a ilustração representa as fases de um projeto, onde estão o mundo real e o
mundo computacional. No mundo real, há o domínio do problema, no qual são realizadas a análise e
a especificação de requisitos, ou seja, a pergunta: o quê? No mundo computacional, há o domínio da
solução, no qual são realizadas a implementação e a validação. A ligação entre eles é a fase do projeto.

Então, como identificamos o domínio do problema? A seguir, algumas perguntas

que podem ajudar o engenheiro de software a identificar esse domínio:

1. Que informação deve ser processada?

2. Quais função e desempenho são desejados?

3. Que comportamento deve ser esperado do sistema?

4. Quais interfaces devem ser estabelecidas?

18
 UNICESUMAR

5. Quais são as restrições de projeto?

6. Quais critérios de validação serão usados?

Depois de ter identificado o domínio do problema, precisamos pensar em como

identificar o domínio da solução a ser desenvolvida. A seguir, apresentamos al-
gumas perguntas para ajudar o engenheiro de software a identificar o domínio
da solução:

1. Como os dados devem ser?

2. Como a função deve ser implementada dentro da arquitetura do software?

3. Como os detalhes dos procedimentais devem ser implementados?

4. Como as interfaces devem ser caracterizadas?

5. Como o projeto deve ser traduzido em linguagem de programação?

Existe, na literatura, uma variação de atividades/tarefas do processo de software,

mas todos envolvem cinco atividades fundamentais (Figura 4).

19
UNIDADE 1

Especificação

Projeto

Implementação

Validação

Evolução

Figura 4 - Atividades fundamentais do processo de software / Fonte: a autora.

Descrição da Imagem: a ilustração representa as atividades fundamentais do processo do software, por

meio de retângulos, deles saem setas que apontam para os retângulos seguintes. No primeiro retângulo,
há a fase de especificação, em seguida, o segundo retângulo, correspondente à fase de projeto, depois, o
terceiro retângulo, que é a fase de implementação, a seguir, o quarto e quinto retângulo, respectivamente,
as fases de validação e de evolução.

A seguir, apresentamos a descrição das atividades fundamentais do processo

de software.

Especificação de software: fase em que são definidas as funcionalidades

do software e as restrições sobre as suas operações.

Projeto e implementação de software: nesta fase, são definidas quais

funcionalidades serão desenvolvidas/implementadas para obter um pro-
duto final executável e de acordo com as especificações fornecidas pelo
cliente.

20
 UNICESUMAR

Validação de software: fase na qual o software passa por validações e

verificações com o objetivo de garantir que ele faça o que o cliente solicitou.

Evolução de software: fase em que são atendidas as mudanças possíveis

de ocorrer durante o ciclo de vida do software, por exemplo, novos requi-
sitos, correções de erros ou atendimento às regulamentações do negócio.

Todas estas atividades são a base sobre a qual o processo de desenvolvimento deve
ser construído. Para Sommerville (2018), processos de software são complexos
e criativos, pois dependem de pessoas para tomar decisões, fazer julgamentos e
planejamento.
Você deve estar pensando: qual o processo ideal e como o usar? Ele não existe,
por isso, muitas empresas realizam adaptações e desenvolvem os seus próprios pro-
cessos de desenvolvimento de software. Processos possuem uma abordagem adap-
tável e vão evoluindo com vistas a tirar o melhor proveito da capacidade da equipe
bem como das características específicas do sistema que está sendo desenvolvido.
Embora não exista um modelo “ideal”, os processos de software têm a capa-
cidade de serem melhorados pela padronização, o que auxilia na comunicação
mais efetiva e na redução no período de treinamento, além de abrir possibilidades
à implantação de processos automatizados.
Nesta disciplina, o objetivo é aprofundar o conhecimento da atividade de
especificação de software, a qual estabelece quais funções são requeridas pelo
software e quais são as restrições sobre a operação e o desenvolvimento dele,
ou seja, o processo de descobrir, analisar, documentar e verificar é chamado de
Engenharia de Requisitos.
A Engenharia de Requisitos, de acordo com Pressman e Maxim (2021, p.
102): “fornece a todas as partes um entendimento escrito do problema. Os arte-
fatos podem incluir: cenários de uso, listas de funções e características e modelos
de análise”. A Engenharia de Requisitos constrói uma ponte entre o projeto e a
elaboração do software, porém, como construímos essa ponte?
É possível que essa construção se inicie quando conversamos com os envol-
vidos no projeto — gerentes, clientes e usuário — pois são definidas, junto com
eles, as necessidades do negócio, a descrição dos cenários de usuários, a definição
das funções bem como os recursos e restrições do projeto.

21
UNIDADE 1

“
Porém, independentemente do ponto de partida, a jornada pela
ponte nos leva bem à frente no projeto, permitindo que examine-
mos o contexto do trabalho de software a ser realizado; as neces-
sidades específicas a que o projeto e a construção devem atender;
as prioridades que orientam a ordem na qual o trabalho deve ser
concluído; e as informações, funções e comportamentos que terão
um impacto profundo no projeto resultante (PRESSMAN; MA-
XIM, 2021, p. 103).

Com o intuito de compreender a Engenharia de Requisitos, precisamos, antes,

entender o que são os requisitos: eles são descrições das funções e restrições
geradas durante o processo de Engenharia de Requisitos. Um requisito com-
preende uma característica ou funcionalidade cujo sistema deve possuir ou
uma restrição que deve atender a uma necessidade do usuário. É a parte mais
crítica e propensa a erros no desenvolvimento de software.
Os requisitos de um sistema, para Sommerville (2018, p. 57), “são as des-
crições do que o sistema deve fazer, os serviços que oferece e as restrições a seu
funcionamento. Esses requisitos refletem as necessidades dos clientes para um
sistema que serve a uma finalidade determinada”.

No podcast desta unidade, destaco a importância da En-

genharia de Requisitos no processo de desenvolvimento
de software. Acesse já!

Por que é tão difícil entender os requisitos? Porque temos diferentes níveis de des-
crição. Vamos a um exemplo? Analise os Quadros 1, a seguir. Ele mostra a visão do
usuário, quando esse mesmo usuário descreve a sua necessidade, e mostra, também,
a visão do analista de sistemas, quando ele pensa na necessidade que foi descrita.

22
 UNICESUMAR

(a)

Visão do usuário
O sistema deve gerar relatórios mensais que mostram o custo dos medica-
mentos prescritos por clínica, durante cada mês.

(b)

Visão do analista
No último dia de cada mês, deve ser gerado um resumo dos medicamentos
prescritos por clínica.
Um relatório por clínica deve ser gerado, listando o nome dos medicamen-
tos, o total de prescrições e o custo total.

Quadro 1 (a) - Visões do usuário; Quadro 1 (b) - Visões do analista / Fonte: a autora.

Você conseguiu perceber as diferenças? Sommerville (2018, p. 58) descreve que

os requisitos “precisam ser escritos em diferentes níveis de detalhamento para
que diferentes leitores possam usá-los de diversas maneiras”. Por isso, quando os
requisitos não são declarados de forma precisa, costumam surgir vários proble-
mas, inclusive requisitos ambíguos que podem ser interpretados de diferentes
maneiras pelos desenvolvedores e usuários do sistema.
Quem são os interessados no sistema? São os clientes, o público, os patroci-
nadores e as organizações executoras, ou seja, quaisquer pessoas ou organizações
que executam ou sofrem alguma ação relacionada ao projeto a ser desenvolvido.
São os chamados stakeholders, aqueles envolvidos, ativamente, no projeto ou
cujos interesses são afetados, de forma positiva ou negativa, pela execução ou
pelo término dele. Você deverá ouvi-los e interpretá-los, principalmente, durante
a fase de levantamento de requisitos (SOMMERVILLE, 2018). Cada um deles
tem uma visão diferente do sistema e cada um obtém diferentes benefícios (se o
sistema é desenvolvido com êxito, ou, caso venha a fracassar, com riscos).

23
UNIDADE 1

Níveis de Requisito

Níveis de Requ

De que maneira identificar os interessados? Esta tarefa é um pouco complexa,

mas, a seguir, temos uma lista de classificação dos stakeholders.

Favoráveis: contribuem ao sucesso do projeto, demonstram interesse e

responsabilidade.

Neutros: não possuem influência e não estão interessados nos resultados

do projeto.

Contrários: acreditam que o projeto prejudica os seus interesses, então,

criam empecilhos para o andamento dele.

Sabotadores: de difícil identificação. Geralmente, são espiões e/ou concor-

rentes.

Quadro 2 - Lista de classificação dos stakeholders / Fonte: adaptado de Sommerville (2018

24
 UNICESUMAR

Níveis de Requisitos

Agora, você aprenderá a respeito dos níveis de requisitos, isto é, a maneira como
eles serão escritos no documento e a quem se destinam, conforme o Quadro 3.

Níveis de requisitos

Destinam-se às pessoas envolvidas no

Requisitos do usuário
uisito
Requisitos do sistema
uso e na aquisição do sistema. Devem
ser escritos usando linguagem natural,
tabelas e diagramas, de modo que sejam
compreensíveis.
Destinam-se a comunicar, de modo
preciso, as funções que o sistema deve
fornecer. São escritos em linguagem
estruturada ou em linguagem baseada
em alguma linguagem de programação.
São divididos em dois tipos: requisitos
funcionais (descrevem as maneiras como
um produto deve se comportar) e requi-
sitos não funcionais (também conhecidos
como atributos de qualidade, descrevem
as características gerais do software).

São declarações, orientações e restrições

relacionadas à maneira como a empresa
Regra de negócio
conduz ou opera o seu negócio. São os
requisitos de domínio.

Quadro 3 - Níveis de requisitos / Fonte: adaptado de Sommerville (2018).

Níveis de Requisito

25
UNIDADE 1

OLHAR CONCEITUAL

Nível de Generalização
Alto
Escopo do Projeto
Objetivos de Negócio
Regra (Requisitos de Domínio)
de Negócio Solicitações do Cliente

Requisitos Necessidades dos usuário

do Usuário ("dores" e Processos do usuário)

Requisitos Funcionais
Requisitos de Sistema e Não Funcionais

Detalhamento Específico

Depois de conhecer os níveis de requisitos, veremos como eles costumam ser

classificados. Os requisitos de software são, frequentemente, classificados como
Requisitos Funcionais (RFs), Requisitos Não Funcionais (RNFs) e Requisitos de
Domínio/Negócio (RDs).
Começarei a falar sobre os Requisitos Funcionais (RFs), os quais dizem
respeito à definição das funções que um sistema ou um componente de sistema
deve fazer (entradas e saídas). Os Requisitos Funcionais referem-se a uma re-
quisição — por parte do cliente — de uma funcionalidade que o software deverá
atender ou realizar, isto é, a exigência, a solicitação, o desejo, a necessidade do
cliente, cujo software a ser desenvolvido precisará materializar. De acordo com
Sommerville (2018, p. 59), os RFs são:

“
Os requisitos funcionais de um sistema descrevem o que ele deve
fazer. Eles dependem do tipo de software a ser desenvolvido, de
quem são seus possíveis usuários e da abordagem geral adotada

26
 UNICESUMAR

pela organização ao escrever os requisitos. Quando expressos como

requisitos de usuário, os requisitos funcionais são normalmente
descritos de forma abstrata, para serem compreendidos pelos usuá-
rios do sistema. No entanto, requisitos de sistema funcionais mais
específicos descrevem em detalhes as funções do sistema, suas en-
tradas e saídas, exceções etc.

Para entender, listaremos alguns exemplos de Requisitos Funcionais (RFs):

[RF001] O sistema deve cadastrar médicos profissionais (entrada).

[RF002] O sistema deve emitir um relatório de clientes (saída).

[RF003] O sistema deve transferir um cliente da situação “em consulta”

para “consultado”, quando esse cliente terminar de ser atendido (mudança
de estado).

[RF004] O cliente pode consultar os seus dados no sistema.

Neste momento, você conhecerá Requisitos Não Funcionais (RNFs). Eles di-
zem respeito a restrições, aspectos de desempenho, interfaces com o usuário,
confiabilidade, segurança, manutenibilidade, portabilidade e padrões.
Sempre que possível, os Requisitos Não Funcionais devem ser escritos, quan-
titativamente, a fim de serem, objetivamente, validados e testados. Os RNFs ex-
pressam as condições ou as especialidades cujo software deverá atender e, segun-
do Sommerville (2018, p. 62):

“
São requisitos que não estão diretamente relacionados com os servi-
ços específicos oferecidos pelo sistema a seus usuários. Eles podem
estar relacionados às propriedades emergentes do sistema, como con-
fiabilidade, tempo de resposta e ocupação de área. Uma alternativa a
esse cenário seria os requisitos definirem as restrições sobre a imple-
mentação do sistema, como as capacidades dos dispositivos de E/S ou
as representações de dados usadas nas interfaces com outros sistemas.

27
UNIDADE 1

A seguir, alguns exemplos de Requisitos Não Funcionais (RNFs):

[RNF001] O sistema deve imprimir o relatório em até cinco segundos.

[RNF002] Todos os relatórios devem seguir o padrão de relatórios espe-

cificado pelo setor XYZ.

[RNF003] O sistema deve ser implementado em Java.

[RNF004] O sistema deve ser protegido para o acesso de usuários.

Os RNFs são, de modo geral, provenientes de características requeridas para o

software, por exemplo, da organização que desenvolve o software ou de fontes
externas. A Figura 5 mostra os tipos de Requisitos Não Funcionais, de acordo
com Sommerville (2018).

28
 UNICESUMAR

Requisitos
não funcionais

Requisitos Requisitos Requisitos

do produto organizacionais extremos

Requisitos Requisitos de Requisitos de Requisitos Requisitos

de eficiência dependabilidade segurança da regulatórios éticos
informação
(security)

Requisitos
de usabilidade Requisitos Requisitos de Requisitos
Requisitos
ambientais operacionais desenvolvimento legislativos

Requisitos de Requisitos
desempenho de espaço Requisitos de segurança (safety)
Requisitos
contábeis /segurança da informação (security)

Figura 5 - Divisão dos tipos de Requisitos Não Funcionais / Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: a ilustração representa, no formato de um organograma com retângulos, a divisão

dos tipos de Requisitos Não Funcionais, iniciando com os seguintes requisitos: do produto, organizacionais
e externos. Ligados aos “Requisitos do produto” estão os requisitos de eficiência, usabilidade, dependabi-
lidade e de segurança da informação. Estão ligados aos “Requisitos externos” os requisitos regulatórios
e éticos. Associados aos “Requisitos organizacionais” estão os requisitos ambientais, operacionais e de
desenvolvimento. Aos “Requisitos de eficiência” estão ligados os requisitos de desempenho e espaço.
Associados aos “Requisitos legislativos” estão os requisitos contábeis e de segurança da informação.

A seguir, a descrição dos RNFs (Figura 5):

■ Requisitos do produto: especificam ou restringem o comportamento do
software. Exemplo: requisitos de desempenho (rapidez com que o sistema
deve executar e quanta memória ele requer); requisitos de confiabilidade
(estabelecem a taxa aceitável de falhas); requisitos de proteção e os requi-
sitos de usabilidade.
■ Requisitos organizacionais: são requisitos gerais de sistemas derivados
das políticas e procedimentos da organização do cliente e do desenvol-
vedor. Exemplos: requisitos do processo operacional (definem como o
sistema será usado); requisitos do processo de desenvolvimento (especi-

29
UNIDADE 1

ficam a linguagem de programação, o ambiente de desenvolvimento ou as

normas de processo a serem usadas); requisitos ambientais (especificam
o ambiente operacional do sistema).
■ Requisitos externos: são todos os requisitos derivados de fatores exter-
nos ao sistema e ao seu processo de desenvolvimento. Exemplos: requi-
sitos reguladores (definem o que deve ser feito para o sistema ser apro-
vado ao uso por um regulador, tal como um banco central); requisitos
legais (devem ser seguidos para garantir que o sistema opere dentro da
lei); requisitos éticos (asseguram que o sistema seja aceitável para os seus
usuários e o público em geral).

Geralmente, os RNFs são mensuráveis, ou seja, para cada Requisito Não Funcio-
nal, devemos associar uma medida ou referência.
A seguir, no Quadro 4, temos exemplos de métricas que são usadas para
especificar os RNFs.

30
 UNICESUMAR

PROPRIEDADE EXEMPLO DE MÉTRICAS

■ Transações processadas/segundo
Velocidade ■ Tempo de resposta de usuário/evento
■ Tempo de atualização de tela

■ Tempo de treinamento
Facilidade de uso ■ Número de frames (telas) de ajuda

■ Tempo médio para falha

■ Probabilidade de indisponibilidade
Confiabilidade ■ Taxa de ocorrência de falhas
■ Disponibilidade

■ Tempo de reinício após falha

Robustez ■ Percentual de eventos que causam falhas
■ Probabilidade de corrupção de dados em
caso de falha

■ Percentual de declarações dependentes do

Portabilidade sistema-alvo
■ Número de sistemas-alvo

Quadro 4 - Exemplos de métricas para especificar Requisitos Não Funcionais

Fonte: Sommerville (2018, p. 63).

PENSANDO JUNTOS

Você deve ter percebido que os Requisitos Funcionais descrevem as funcionalidades (o

que o sistema faz), e os Requisitos Não Funcionais relacionam as especialidades ou restri-
ções do software (como o sistema é).

Agora, você aprenderá sobre os Requisitos de Domínio/Negócio (RDs): são

os requisitos derivados do domínio da aplicação. Descrevem as características do
sistema e as qualidades que refletem a regra de negócio do cliente. Tais requisitos

31
UNIDADE 1

são derivados da especialidade na qual o software será implantado e podem ser

novos Requisitos Funcionais ou alguma restrição de algum requisito existente
ou algum cálculo específico, por exemplo, o cálculo de impostos ou de taxas
específicas.
Em uma empresa, o setor de RH possui incrementos e descontos específicos
do seu domínio, por exemplo, férias, horas extras etc. Se a empresa tiver impos-
tos tributários, há cálculos e porcentagens específicas inerentes à sua aplicação:
IPI, substituição tributária, ICMS, IPTU, ISS, entre outros (PIS, COFINS etc.).
Devem ser expressos usando uma linguagem específica do domínio da aplicação.
Seguem alguns exemplos de Requisitos de Domínio (RDs):

[RD001] O cálculo da média final de cada aluno é dado pela fórmula: (Nota1
* 2 + Nota2 * 3)/5.

[RD002] O valor do IPI é calculado em relação ao valor da nota fiscal da

mercadoria despachada e pode, eventualmente, incluir valores sobre o
frete e despesas acessórias (juros, taxas etc.).

[RD003] O cálculo de comissão dos vendedores é de 15% sobre o total

líquido das vendas no mês.

Na especificação de software, a imprecisão é a causa de muitos problemas da

engenharia de software. Muitas vezes, ocorre a interpretação ambígua de um
requisito de forma, para, de alguma maneira, simplifique-se a sua implementação
ou pode ocorrer, também, de o requisito não ser a preferência do cliente, neste
caso, é necessário estabelecer novos requisitos e fazer mudanças no sistema. Com
isso, acontecem os atrasos de entrega, gerando aumentos nos custos.

32
 UNICESUMAR

OLHAR CONCEITUAL
Para entender a relação entre os requisitos, temos, a seguir, um infográfico do
ciclo dos requisitos de software.

Descrevem o
que o software
deve fazer
Requisitos do Software

Requisitos
funcionais

Tarefas do Requisitos não-funcionais

usuário
transferidas
para o software
Restrições gerais Estabelecem níveis
que afetam como de serviço que
o software deve se esperam para
ser feito o software

Figura 6 - Requisitos do software / Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: a ilustração representa a relação entre os requisitos, mostrando, por meio de
setas, o ciclo dos requisitos de software. É possível ver os Requisitos Funcionais, os quais são as tarefas
do usuário transferidas para o software e descrevem o que o software deve fazer. Em seguida, estão os
Requisitos Não Funcionais: estes são as restrições gerais que afetam como o software deve ser feito e
estabelecem níveis de serviços esperados para o software.

Depois de ter aprendido sobre os requisitos, você deve estar pensando: qual a
importância deles no projeto de software? A fim de te fazer entender, falarei,
primeiro, da importância dos Requisitos Funcionais.
Primeiramente, as funcionalidades do sistema existem, somente, para realizar
Requisitos Funcionais, logo, sem eles, não há funcionalidades e, sem funciona-

33
UNIDADE 1

lidades, não há sistema, por isso, os RFs precisam ser bem detalhados, claros e
com qualidade.
Você deve estar pensando: “o que devemos entender como qualidade de
um requisito?”. Pois bem, Requisitos Funcionais de qualidade precisam aten-
der a alguns atributos qualitativos específicos, tais como: unidade, completude,
consistência, atomicidade, não ambiguidade, ser verificável e rastreável, possuir
prioridade e tempo verbal.
A seguir, o Quadro 5 mostra os atributos e exemplos de cada um.

Atributos Descrição dos atributos

O Requisito Funcional deve propor, apenas, uma

única coisa, ou seja, não deve atender a mais de
uma necessidade.
Unidade Exemplo: o Requisito Funcional “cadastrar clien-
te” não é requisito unitário, pois, podemos ter
vários tipos de clientes (pessoa física e pessoa
jurídica).

O Requisito Funcional deve ser autocontido, ou

seja, deve ter um início, um meio e um fim.
Exemplo: o Requisito Funcional “pagar fatu-
Completude ra” não está completo, faltam partes. Agora, o
Requisito Funcional “pagar fatura com cartão de
débito para cliente pessoa jurídica” está comple-
to, com início, meio e fim.

O Requisito Funcional não deve contradizer ou-

tro Requisito Funcional, isto é, se propõe a fazer
Consistência
a mesma coisa, mas cada um fazendo de forma
diferente.

O Requisito Funcional deve assumir, apenas,

Atomicidade uma responsabilidade e, também, deve ser algo
indivisível, não pode ser decomposto.

34
 UNICESUMAR

Atributos Descrição dos atributos

O Requisito Funcional não pode ser ambíguo, ou

seja, não pode propor algo que não é claro no
que faz.
Exemplo: o Requisito Funcional “imprimir relató-
Não ambiguidade
rio” não diz muita coisa, pois imprimirá relatório
do que e para quê? Agora, o Requisito Funcional
“imprimir relatório de saldo da conta poupança
do cliente pessoa física” já está completo e claro.

O Requisito Funcional deve ser testável, isto é,

Verificável validado, para saber se ele atende à necessida-
de do cliente.

O Requisito Funcional é passível de ser rastreá-

Rastreável vel no sistema, quando estiver funcionando e
executável.

O requisito deve fazer uso do tempo verbal no

próprio nome, ou seja, ele refere-se a algo que
será feito, uma ação a ser realizada pelo siste-
Tempo verbal
ma.
Exemplo: realizar, comprar, emitir, consultar,
validar, acessar etc.

Quadro 5 - Lista de atributos de qualidade dos Requisitos Funcionais

Fonte: adaptado de Sommerville (2018).

Mas, e a importância dos Requisitos Não Funcionais para o sistema? Com o

objetivo de tornar tal assunto compreensível, descreverei um cenário hipotético.

Exemplo 1
■ A empresa de transportes XYZ possui uma frota de 600 caminhões, mas
eles não podem ficar esperando muito tempo no pátio, mesmo para saí-
rem dos armazéns de carga. A empresa solicitou que, no módulo de logís-
tica, todas as cargas devem ser liberadas em, no máximo, 15 minutos. Para
isso, é emitido um documento de solicitação de liberação de carga, nele
é anexado a nota fiscal eletrônica dos produtos contidos no caminhão.

35
UNIDADE 1

Após a leitura do cenário hipotético, identifique os Requisitos Não Funcionais.

Imagine que você tenha chegado ao seguinte RFN:

[RNF01] Requisito de Desempenho: tempo limite de, no máximo, 20 mi-

nutos para o processamento de solicitação de liberação de carga.

Depois da identificação do Requisito Não Funcional, você descobriu que os

desenvolvedores responsáveis pela implementação do módulo de logística não
deram a devida importância ao requisito não funcional (RNF01) e que esta ne-
cessidade de tempo de resposta da emissão da nota fiscal eletrônica será imple-
mentada, somente, no fim do projeto.
Quando o módulo de logística da empresa de transporte ficou pronto, ini-
ciou-se a homologação das funcionalidades. E o que aconteceu? Quando ocorreu
a primeira bateria de testes com o módulo, o sistema foi reprovado pelos usuários
da área de logística da empresa, pois estava demorando 1 hora, em média, apenas
para que o sistema processasse a solicitação de liberação de carga. Resultado?
Sistema considerado inviável à produção, sendo necessário reestruturar toda a
sua arquitetura, porque a performance do módulo de logística ficou muito ruim,
não atendendo ao Requisito Não Funcional (RNF01).

EXPLORANDO IDEIAS

“Muitas empresas estão dispostas a trocar a qualidade e o compromisso com requisitos do

software por uma implantação mais rápida do software de que necessitam. Essas empresas
operam em um ambiente de mudanças rápidas, por isso, muitas vezes, é, praticamente, im-
possível obter um conjunto completo de requisitos de software estável.
Os requisitos iniciais, inevitavelmente, serão alterados, pois os clientes acham impossível
prever como um sistema afetará as práticas de trabalho, como interagirá com outros siste-
mas e quais operações do usuário devem ser automatizadas. Pode ser que os requisitos se
tornem claros apenas após a entrega do sistema e à medida que os usuários ganhem expe-
riência. Mesmo assim, devido a fatores externos, os requisitos são suscetíveis a mudanças
rápidas e imprevisíveis. Por exemplo, quando for entregue, o software poderá estar desatua-
lizado”.
Fonte: Sommerville (2018, p. 38).

36
 UNICESUMAR

Depois do fragmento de texto exposto no explorando ideias, você deve estar se

perguntando: E os requisitos nas metodologias ágeis? Quando usamos meto-
dologia ágil, nos processos ágeis, os requisitos são considerados um “objetivo”
ao invés de ser uma solicitação ou necessidade sobre o que deve ser feito.
Conforme Pressman e Maxim (2021, p. 38), “[uma] das características mais
convincentes da metodologia ágil é sua habilidade de reduzir os custos da mu-
dança no processo de software”, ou seja, as mudanças nos requisitos são consi-
deradas bem-vindas, mesmo que elas venham, tardiamente, durante o desen-
volvimento do software. Tal metodologia é passível de ser aplicada a qualquer
processo de software, e a sua especificação ocorre durante todo ciclo de vida do
desenvolvimento dele, inclusive há a participação efetiva do stakeholder. Este
promove esclarecimentos imediatos, em caso de dúvidas.
Existe uma filosofia por trás dos métodos ágeis e refletida no Manifesto Ágil,
o qual, segundo Pressman e Maxim (2021), foi acordado, em uma reunião, por
muitos dos principais desenvolvedores dessa metodologia.
A seguir, veremos, na Figura 7, os valores do Manifesto Ágil.

VALORES DO MANIFESTO ÁGIL

Indivíduos e interações mais que processos e ferramentas

Softwares em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Figura 7 - Valores do Manifesto Ágil / Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: a ilustração representa os valores do Manifesto Ágil, por meio de cinco retângulos
que apresentam os textos mostrados, aqui, a seguir. O texto “Valores do Manifesto Ágil” funciona como
título e dele sai uma seta apontando para baixo, em direção ao retângulo cujo texto é: “Mais indivíduos
e interações do que processos e ferramentas”, seguido pelo retângulo com o texto “Mais softwares em
funcionamento do que documentação abrangente”, seguido pelo retângulo com o texto “Mais colaboração
com o cliente do que negociação de contratos”, depois, vê-se o retângulo com o texto “Mais respostas a
mudanças do que seguir um plano”.

37
UNIDADE 1

Quando se usa um processo ágil, não é comum fazer um planejamen-

to completo de tudo o que precisa ser desenvolvido antes de iniciar
a implementação do sistema. É feito o planejamento de incrementos
— pedaços do software que são desenvolvidos aos poucos e entregues,
constantemente, ao cliente —, afinal, o foco está no valor do produto
de alta qualidade que será entregue e que, também, fornecerá valor de
negócio.
E o time ágil? Para Sommerville (2018), os métodos ágeis dependem
do fato de o time compreender os aspectos do sistema, sem a necessi-
dade de consultar a documentação. Mas, tem um problema: e se o time
ágil for alterado? Ou se algum dos desenvolvedores sair do time? Sig-
nifica que todo o conhecimento implícito sobre os aspectos do sistema
é perdido. Para os novos membros do time, é difícil construir/alterar
sem ter uma documentação viável do sistema e dos seus componentes.
Como especificar os requisitos na metodologia ágil? A especifica-
ção de Requisitos Funcionais é feita por meio da utilização de histórias
de usuário (user stories), cujo objetivo principal é garantir ao time a
capacidade de entender e responder, rapidamente, às necessidades do
usuário. Quando histórias de usuário são utilizadas, produz-se menos
documentação e, também, é mostrada, de forma mais rápida e eficiente,
a evolução das necessidades do usuário, além de haver mais ajuda na
descoberta de novos requisitos que possam ocorrer durante o desen-
volvimento do sistema.
Neste momento, quero que você pense: qual a diferença entre as
histórias de usuário e a descrição tradicional dos requisitos? A diferen-
ça entre elas está na comunicação verbal, porque a linguagem escrita
pode ser, muitas vezes, imprecisa, e a interpretação do usuário e do
desenvolvedor costumam não ser as mesmas. A especificação de um
requisito usando histórias de usuário segue as mesmas recomendações
de especificação das metodologias tradicionais, vistas anteriormente.
Na Unidade 4, será explicada a especificação de requisitos utilizan-
do histórias de usuário. Não se preocupe, logo você chega lá.

38
 UNICESUMAR

EXPLORANDO IDEIAS

“Os requisitos relacionados ao produto farão parte de um documento de especificação de

requisitos ou artefato similar, como cartões com histórias de usuário nos métodos ágeis,
enquanto os requisitos de processo e de projeto serão parte do plano de projeto ou artefa-
to que tenha função similar. Já requisitos de sistema se desdobrarão em requisitos relacio-
nados à parte física (hardware) e requisitos relacionados à parte de software, os quais po-
dem estar em um mesmo artefato, mas que se desdobrarão em implementações distintas”.
Fonte: Reinehr (2020, p. 39)..

Agora, pense na seguinte frase: “o que é mais importante e o que deve ser feito
primeiro”. Então, como saber quais requisitos são mais importantes, isto é, qual
dos requisitos deve ser implementado primeiro? A recomendação é analisar o
que, realmente, é essencial ou urgente a ser implementado e, para isso, usa-se a
Priorização de Requisitos de Software.
Uma das melhores formas para decidir o que deve ser feito com os recursos
em mãos é priorizar os requisitos. Em termos de método aplicado, a “grosso
modo”, estamos falando de criar uma lista com os requisitos, definir uma priori-

39
UNIDADE 1

dade para cada um, e os mais prioritários vão ao início da lista, os menos prio-
ritários, para o fim.
Imagine a situação: você desenvolveu um sistema cujo objetivo é controlar
a venda de produtos. Nele, a emissão de Nota Fiscal Eletrônica ou de Cupom
Fiscal está pronta, mas o módulo que realiza a venda, ou seja, o Pedido de Venda,
ainda não. Após a priorização, é importante definir, com a mesma prioridade,
uma ordem de execução aos requisitos.
Como definir essa ordem de execução? De acordo com a literatura pesquisa-
da, a atribuição de prioridade dos requisitos é de três tipos: essencial, importante
e desejável.
■ Essencial: requisito sem o qual o sistema não entra em funcionamento.
São os requisitos imprescindíveis, os quais devem ser disponibilizados na
implantação do sistema.
■ Importante: requisito sem o qual o sistema entra em funcionamento,
ainda de forma satisfatória. Não impedem a implantação do sistema, mas
devem ser implementados o mais breve possível.
■ Desejável: requisito que, embora não implementado, permite que o siste-
ma funcione de modo satisfatório, sem comprometer as funcionalidades
básicas. É um requisito com a possibilidade de ser entregue em qualquer
momento, sem prejuízo para os serviços oferecidos pelo sistema.

Quando devemos priorizar os requisitos? A priorização acontece durante a de-

finição do escopo do sistema. Imagine que você tenha o escopo definido do seu
projeto e começa o desenvolvimento, porém não priorizou nenhum requisito.
Isso gera problemas no projeto bem como possíveis atrasos na entrega.
Não priorize os requisitos, somente, no início do projeto, procure fazer isso
quando ocorrer mudanças nos requisitos. Mas, para isso, o documento de re-
quisitos precisa ser bem elaborado e detalhado, além de atualizado, sempre que
necessário.
Talvez, você esteja se perguntando como registrar o que aprendeu, até aqui,
sobre requisitos. Este registro é feito por meio de um documento chamado Do-
cumento de Requisitos de Software, cuja função é documentar o que foi acor-
dado entre quem solicita e quem desenvolve, estabelecendo, também, o escopo
do software, ou seja, o conjunto de funcionalidades que ele deverá oferecer. Além
de servir de referência a desenvolvimento, testes, manutenção e evolução do

40
 UNICESUMAR

sistema (mudanças), esse documento garante, ainda, a rastreabilidade mínima

dos requisitos, ao longo do ciclo de vida do software.
O Quadro 6 mostra a lista de usuários do Documento de Requisitos de Software.

Clientes do sistema: especificam os requisitos e os leem, para conferir

se satisfazem às suas necessidades. Os clientes especificam mudanças nos
requisitos.

Gerentes: usam o documento de requisitos para planejar uma proposta ao

sistema e planejar o seu processo de desenvolvimento.

Engenheiros de sistema: usam os requisitos a fim de compreender qual

sistema deve ser desenvolvido.

Engenheiros de testes: usam os requisitos com o intuito de desenvolver

testes de validação do sistema.

Engenheiros de manutenção: usam os requisitos para entender o sistema

e as relações entre as suas partes.

Quadro 6 - Lista de usuários do Documento de Requisitos de Software

Fonte: Sommerville (2018, p. 110)

Segundo Sommerville (2018, p. 109), os documentos de requisito “são essenciais

quando: os sistemas têm o seu desenvolvimento terceirizado, times diferentes
desenvolvem partes diferentes do sistema ou uma análise detalhada dos requisitos
é obrigatória”.
Mas, afinal, como documentar? Te convido a fazer uma busca pela internet,
usando as palavras “documento de requisitos”, então, visualize o que aparece.
Além de inúmeras páginas de conceitos, você se deparará com inúmeros modelos
e templates sugeridos para a documentação. Qual escolher? O desafio entre os
modelos sugeridos é decidir qual o modelo que melhor se adapta ao seu projeto,
às suas empresa e equipe.
Com tantos modelos, qual o nível certo para realizar a documentação? Em
primeiro lugar, o documento deve ser capaz de garantir o entendimento dos
stakeholders. Em segundo lugar, a equipe técnica precisa estar ciente de que esse
documento é a única garantia que atende às solicitações do cliente, portanto,
ele necessita estar, sempre, atualizado. Qual modelo ou padrão usar? Há vários
modelos os quais são, também, adaptáveis. O ideal é você definir, junto com a

41
UNIDADE 1

equipe, qual o modelo ou padrão que utilizarão à documentação dos requisitos

do projeto. O documento de requisitos deve ter:
1. Escopo do software: a descrição do conjunto de funcionalidades que ele
deverá ter e os atributos de qualidade que o sistema suportará bem como o con-
junto de características técnicas, ou seja, a descrição completa dos Requisitos
Funcionais e Não Funcionais e de Domínio.
2. O documento deve ser elaborado de maneira precisa, detalhada, consis-
tente e de acordo com as necessidades do cliente, além de ser compreensível por
todos stakeholders, isto é, os interessados no sistema.
3. Guia de referência para validação, verificação e testes, além de manutenção
e evolução do sistema.
O Quadro 7 mostra os itens para organizar o documento de requisitos, com
base em um padrão IEEE genérico. No entanto as empresas podem adaptá-lo a
usos específicos, de acordo com os seus processos.

Itens Descrição

Define os possíveis leitores do docu-

mento e descreve o histórico de versões,
Prefácio incluindo uma justificativa à criação de
uma nova versão e um resumo das mu-
danças feitas em cada versão.

Descreve as necessidades para o siste-

ma, em suma, as funções, e como ele
Introdução funcionará com outros sistemas, além de
descrever os objetivos gerais de negócio
ou estratégicos da empresa.

Define os termos técnicos usados no

Glossário
documento.

Descreve os serviços fornecidos ao usuá-

Definição de requisitos de rio. Esta descrição pode usar linguagem
usuário natural, diagramas ou outras notações
compreensíveis para os clientes.

42
 UNICESUMAR

Itens Descrição

Apresenta a visão geral em alto nível da

arquitetura do sistema previsto, mos-
trando a distribuição de funções entre os
Arquitetura do sistema
módulos do sistema. Componentes de
arquitetura reusados devem ser desta-
cados.

Descreve, em detalhes, os Requisitos

Especificação de requisitos do Funcionais e Não Funcionais. As inter-
sistema faces com outros sistemas podem ser
definidas.

Incluem modelos gráficos do sistema

que mostram os relacionamentos entre
Modelagem do sistema
os componentes do sistema, o sistema e
o seu ambiente.

Descreve quaisquer mudanças previstas,

em decorrência da evolução de hardwa-
Evolução do sistema
re e de mudanças nas necessidades do
usuário etc.

Fornece informações detalhadas e

específicas relacionadas à aplicação em
desenvolvimento, além de descrições de
hardware e banco de dados, por exem-
plo. Os requisitos de hardware definem
Apêndices
as configurações mínimas ideais para o
sistema. Requisitos de banco de dados
definem a organização lógica dos dados
usados pelo sistema bem como os rela-
cionamentos entre esses dados.

Vários índices podem incluídos no do-

cumento. É possível haver, além de um
Índice índice alfabético normal, um índice de
diagramas e de funções, entre outros
pertinentes.

Quadro 7 - Estrutura de um documento de requisitos / Fonte: Sommerville (2018, p. 111).

43
UNIDADE 1

As informações contidas em um documento de requisitos dependerão do tipo

de software a ser desenvolvido e da metodologia que está sendo usada para o
processo de desenvolvimento. O importante, independentemente do tipo de
software, é incluir, no documento, conteúdo para todos os leitores e interessados
serem capazes de encontrar e entender, facilmente, todas as informações acerca
do sistema.

EXPLORANDO IDEIAS

“O nível de detalhes que você deve incluir em um documento de requisitos depende do

tipo de sistema em desenvolvimento e do processo usado. Os sistemas críticos precisam
ter requisitos detalhados, porque a segurança e a proteção devem ser analisadas em
detalhes. Quando o sistema está sendo desenvolvido por uma companhia separada (por
exemplo, através de outsourcing (terceirização), as especificações de sistema devem ser
detalhadas e precisas. Se um processo interno de desenvolvimento iterativo é usado, o
documento de requisitos pode ser muito menos detalhado e quaisquer ambiguidades
podem ser resolvidas durante o desenvolvimento do sistema”.
Fonte: Sommerville (2018, p. 110-111).

NOVAS DESCOBERTAS

Minha recomendação de leitura é a obra Engenharia de Requisitos, o

qual pode ser encontrado na Biblioteca Digital Unicesumar (BDU).
Neste livro, a autora Sheila Reinehr aborda os elementos e as etapas
do ciclo de vida da Engenharia de Requisitos. Por meio desta leitura,
você aprofundará os conceitos aprendidos nesta unidade, por exem-
plo, a compreensão da diferença entre Requisitos Funcionais e Não Funcio-
nais, assim como os Requisitos de Domínio.

A fim de concluir a nossa unidade, segue um exemplo prático de um template

para o documento de requisitos, a ser utilizado na disciplina. Esse documento de
requisitos é direcionado a um sistema online de gerenciamento de uma fictícia
casa de apoio social (SGCA).

44
 UNICESUMAR

DOCUMENTO DE REQUISITOS

SISTEMA SGCA

Histórico de revisões
Data Versão Descrição Responsável

Especificação
10/01/2022 1.0 dos objetivos do Janaina Freitas
documento

Especificação
dos Requisitos
15/01/2020 1.1 Rafael Florindo
Funcionais e
Não Funcionais

Modificação do
20/01/2022 2.0 Janaina Freitas
escopo geral

1. Objetivos

O SGCA é um sistema online de gerenciamento de casas de apoio social. O ob-

jetivo dele é cadastrar, listar e relacionar as casas de apoio, visando a facilitar as
contribuições e doações.
1.1. Objetivos do documento

Este documento tem, por objetivo, descrever e especificar os requisitos de um sis-

tema online de gerenciamento de casas de apoio social. Os seus leitores (usuários
desse documento) são profissionais envolvidos no desenvolvimento e pessoas
que tenham interesse em usar o sistema.

2. Escopo geral do produto

O SGCA é um sistema online que visa a possibilitar o cadastro de casas de apoio

social da cidade, onde será possível visualizar qual tipo de público elas atendem,
os projetos que desenvolvem e a de que modo fazer contribuições e doações.

45
 UNIDADE 1

3. Convenções, termos e abreviações

3.1 Termos e abreviações:

■ SGCA – Sistema de gerenciamento online de casas de apoio social.

■ RF – Requisitos Funcionais.
■ RNF – Requisitos Não Funcionais.
3.2 Convenções:

A seguinte convenção foi adotada neste documento:

■ Casas de apoio social: referem-se ao indivíduo/empresa cadastrado(a) ou
não no sistema e que faz uso das funcionalidades oferecidas pelo sistema.
4. Requisitos
Descrever, de maneira geral, todas as funcionalidades do sistema.
4.1. Requisitos Funcionais

Preencher a tabela, a seguir, com as informações pertinentes a cada um dos requisitos:

PR:
RF: RF001 Efetuar login de usuário no sistema. UC: 001
alta

Descrição/Ação: o sistema deve permitir a autenticação de usuário, por meio de nome

de usuário e senha. Caso o usuário não se lembre de seu login ou senha, ele poderá
recuperar os dados pelo botão “Esqueci a minha senha”. A partir disso, será pedido ao
usuário que digite o e-mail, em seguida, serão encaminhados os dados para login.

Entrada: informações de nome de usuário e senha.

Saída: login efetuado com sucesso.

Pré-condição: ter cadastro de usuário realizado, com sucesso, no sistema.

Pós-condição: autenticação de usuário efetuado, com sucesso, no sistema.

Stakeholder: usuário administrador do sistema.

46
 UNICESUMAR

4.2 Requisitos Não Funcionais

PR:
RNF: RNF001 Usuários simultâneos. UC:
média

Descrição/Ação: o sistema deverá suportar o processamento multiusuário, ou seja,

vários usuários poderão utilizar, ao mesmo tempo, o sistema.

Entrada: informações de vários nomes de usuários e senhas.

Saída: login de vários usuários efetuados com sucesso.

Pré-condição: usuário com cadastro no sistema.

Pós-condição: não se aplica.

Stakeholder: usuário administrador do sistema.

5. Escopo não contemplado

No momento, não será desenvolvido:

■ Os relatórios com as casas de apoio social cadastradas no sistema.
■ Atendimento a consultas de informações por meio de e-mail.
6. Aprovação
_______________________

Juscelino Kubitschek de Oliveira

Gerente de projeto

_______________________

Marechal Cândido Rondon

Analista de Requisitos

_______________________

Tancredo Neves

Cliente/Solicitante

Maringá, 2 de Dezembro de 2021

47
UNIDADE 1

Convido você a assistir o vídeo, para aprender a criar um

documento de requisitos, na prática, visando a absorver o
conteúdo visto nesta unidade. O documento de requisitos
que criaremos tem o objetivo de descrever e especificar
os requisitos de um sistema online de gerenciamento de
casas de apoio social. Acesse e aprenda na prática.

NOVAS DESCOBERTAS

Título: Engenharia de Software: Uma Abordagem Profissional

Autores: Roger S. Pressman e Bruce R. Maxim
Editora: AMGH
Sinopse: o objetivo deste livro é ser um guia para uma disciplina de
Engenharia em fase de amadurecimento. Assim como as edições que a pre-
cederam, esta é voltada tanto a estudantes quanto a praticantes, servindo,
também, como guia para profissionais da área e como introdução abran-
gente para estudantes no final do curso de graduação ou no primeiro ano
de pós-graduação.

48
Crie um Mapa Mental sobre os conceitos fundamentais da Engenharia de Requi-
sitos. O seu mapa deve conter as seguintes palavras-chaves:
■ Processo de Software
■ Engenharia de Requisitos
■ O que é um requisito
■ Requisitos de sistema
■ Requisitos de usuário
■ Requisitos de Domínio
■ Requisitos Funcionais
■ Requisitos Não funcionais
■ Documento de Requisitos
Organize a ideia do seu Mapa Mental a partir das palavras-chaves propostas. É
uma forma de você absorver bem como sintetizar os conceitos vistos nesta uni-
dade. Recomendo o uso da ferramenta gratuita GoConqr (www.goconqr.com).
2
Processos da
Engenharia de
Requisitos
Esp. Janaína Aparecida de Freitas

Caro(a) estudante, após ter aprendido sobre os fundamentos da En-

genharia de Requisitos e a sua importância no processo de desenvol-
vimento de software, agora, nesta unidade, você conhecerá os pro-
cessos e as atividades responsáveis por garantir a especificação de
bons requisitos de software. Você aprenderá acerca dos processos da
Engenharia de Requisitos e, também, como realizar o levantamento e
a análise de Requisitos de Software, além disso, entenderá a verifica-
ção e a validação desses requisitos. Por último, compreenderá como
realizar a especificação dos mesmos.
 UNIDADE 2

Na unidade anterior, iniciamos a nossa jornada de estudos sobre a Engenharia

de Requisitos e a sua importância no processo de desenvolvimento de software.
Você conheceu os conceitos fundamentais bem como as etapas para compreen-
der essa engenharia.
Para verificar se você absorveu o conteúdo, te faço uma pergunta: o quanto a
Engenharia de Requisitos é relevante no processo de desenvolvimento de softwa-
re? E qual o objetivo dela? São questionamentos importantes a um(a) futuro(a)
engenheiro(a) de software, pois ele(a) precisa lidar com várias situações que en-
volvem tanto os processos quanto a equipe.
Na unidade anterior, você aprendeu que o processo de descobrir, analisar,
documentar e verificar é chamado de Engenharia de Requisitos e que ela cons-
trói uma ponte entre o projeto e a construção do software. Aprendeu, também,
que essa engenharia fornece todos os artefatos que promovam o entendimento
do que se deseja produzir a todos os envolvidos no projeto de desenvolvimento
de software.
Mas, como ter a certeza de que esses artefatos reproduzem, de fato, a solução
final desejada? Para responder a esta pergunta, lembre-se que os eles podem
incluir: cenários de uso, modelos de análise, listas de funções e características,
também devem ser revisados e validados junto com o cliente, os usuários ou os
patrocinadores, ou seja, com os stakeholders integrantes do projeto.
Em suma, são vários os artefatos, afinal, eles são produzidos durante as etapas
da Engenharia de Requisitos, isto é, durante os processos que envolvem a Enge-
nharia de Requisitos de Software.

52
 UNIDADE 2

Achou complicado? Falamos em processos de software que são compostos

por várias tarefas, agora, citamos os processos da Engenharia de Requisitos. Bem,
para descomplicar, te convido a fazer uma busca pela palavra “processo”, de for-
ma geral. Deixe de lado o aspecto técnico, abra o seu navegador na internet, digite
“processo” ou “o que é um processo”. Em seguida, veja as definições apresentadas
nos links, com os resultados.
Registre, em seu Diário de Bordo, as definições do que é um processo, então,
descreva a sua análise dessas definições.
Agora, pesquise a definição de “processo” em um dicionário, anote e compare.
Depois, pense: de forma geral, as definições mostradas nos remetem a uma ativida-
de continuada, em algo desenvolvido, passo a passo, ou a uma forma adotada para
se desenvolver algo, concorda? Espero que após estas pesquisas, fique mais claro
quando falamos em processos de software e processo da Engenharia de Requisitos.

53
 UNIDADE 2

Processos da Engenharia de Requisitos de Software

Você aprendeu, na unidade anterior, que, durante a produção de um software, são

necessárias diversas fases/etapas compostas por várias tarefas e este conjunto de
fases/etapas chama-se processo de software. Um processo de Engenharia de Re-
quisitos é, também, um conjunto estruturado de atividades/etapas/fases que são se-
guidas para derivar, validar e manter um documento de requisitos de um sistema.
O processo usado nessa engenharia pode variar bastante, em função das ca-
racterísticas dos projetos ou do domínio da aplicação, das pessoas envolvidas e da
organização. Para Pressman e Maxim (2021), as atividades de Engenharia de Requi-
sitos são divididas em Especificação de Requisitos e Gestão de Requisitos (Figura 1).

Engenharia de Requisitos

Especificação de Requisitos Gestão de Requisitos

Levantamento e Análise Controle de Mudanças

Negociação Versionamento
Documentação Configuração
validação Rastreabilidade
Verificação Gerência de Qualidade

Figura 1 - Atividades da Engenharia de Requisitos / Fonte: a autora.

Descrição da Imagem: a ilustração mostra as atividades de Engenharia de Requisitos, as quais são divi-
didas em especificação de requisitos e gestão de requisitos. Em especificação de requisitos, temos outras
atividades, que são, respectivamente: levantamento e análise, negociação, documentação, validação e ve-
rificação. Em gestão de requisitos, estão as respectivas atividades: controle de mudanças, versionamento,
configuração, rastreabilidade e gerência de qualidade.

Para entender cada uma das atividades, leia as definições a seguir:

■ Especificação de requisitos: representa todas as atividades realizadas
para identificar, analisar, especificar e definir as necessidades do sistema,

54
 UNIDADE 2

as quais veremos, com mais detalhes, a seguir: levantamento/elicitação e

análise, negociação, documentação, validação e verificação.
■ Gestão de requisitos: atividades responsáveis pela documentação, ver-
sionamento, controle de mudanças e qualidade dos requisitos levantados
na fase de especificação. Tais atividades serão estudadas na Unidade 5.

Sommerville (2018) afirma que a Engenharia de Requisitos envolve três ativida-

des fundamentais:
■ Elicitação e análise: ocorre a descoberta dos requisitos, por meio da
interação com os stakeholders.
■ Especificação: ocorre a conversão dos requisitos em uma forma padrão.
■ Validação: ocorre a averiguação de que os requisitos, realmente, definem
o sistema desejado pelo cliente.

Esse processo da Engenharia de Requisitos, na prática, é um processo iterativo

cujas atividades são intercaladas, conforme apresentado na Figura 2. Elas são
organizadas em torno de uma espiral, e o resultado do processo é um documento
de requisitos de sistema (SOMMERVILLE, 2018).

55
 UNIDADE 2

Especificações
de Requisitos

Especificação e
modelagem dos
requisitos de sistema

Especificação de
requisitos de usuário

Especificação de
requisitos de negócio

Estudo de
Início viabilidade
Elicitação
Elicitação de requisitos Validação
de requisitos de sistema Elicitação de de requisitos
requisitos de
usuário
Prototipação

Revisões

Documentos de
requisitos de sistema

Figura 2 - Visão em espiral do processo de Engenharia de Requisitos

Fonte: Sommerville (2018, p. 95).

Descrição da Imagem: a ilustração mostra as atividades fundamentais: elicitação de requisitos, especi-

ficação de requisitos, validação de requisitos e documentação de requisitos de sistema, intercaladas em
torno de uma espiral. Na atividade de elicitação, há o início, com a elicitação de requisitos de usuário e
requisitos de sistema. Em especificação de requisitos, há as especificações de requisitos de negócio, de
requisitos de usuário e a especificação e modelagem dos requisitos de sistema. Na atividade de validação
de requisitos, estão o estudo de viabilidade, a prototipação e as revisões. O ciclo encerra na atividade de
documento de requisitos de sistema.

Quando se inicia o processo de Engenharia de Requisitos, dedicamos a maior

parte do esforço a compreender os requisitos do negócio, seguindo para um estudo
de viabilidade, em seguida, os requisitos do usuário do sistema. Em etapas mais
avançadas do processo, Sommerville (2018, p. 96) destaca, nos anéis mais externos
da espiral, o seguinte: “mais esforço será dedicado à elicitação e à compreensão dos
requisitos não funcionais e dos requisitos de sistema mais detalhados”.

56
 UNIDADE 2

Qual a quantidade de iterações em torno da espiral? O número pode variar de

acordo com os níveis de detalhes, conforme os requisitos são desenvolvidos, e ela
pode ser encerrada após alguns requisitos ou todos eles terem sido levantados ou
elicitados. Em vez da prototipação, há a possibilidade de se utilizar desenvolvimen-
to ágil, para que os requisitos e a implementação sejam desenvolvidos em conjunto.
Durante o processo de Engenharia de Requisitos, entendemos as necessida-
des do cliente, por isso, é importante analisar o que foi especificado e corrigir, caso
seja necessário ou caso não se tenha entendido, exatamente, o que era esperado.
Em todos os sistemas, os requisitos mudam e, como estudamos na unidade ante-
rior, entender o que o cliente almeja está entre as tarefas mais difíceis enfrentadas
por um engenheiro de software.
Por este motivo, as mudanças devem ser gerenciadas. Ao longo da unidade,
você perceberá que as atividades do processo de Engenharia de Requisitos pre-
cisam andar juntas e permanecerem durante todo o ciclo de vida do projeto do
software, o que dará garantias da elaboração de um bom documento de requisitos
do sistema.
Para o nosso estudo, seguiremos as atividades do processo de requisitos de
software: levantamento e análise, verificação, validação e especificação.

57
 UNIDADE 2

Levantamento e Análise de Requisitos de Software

Também conhecida como elicitação e análise de requisitos, esta atividade inicia

o processo de Engenharia de Requisitos bem como a atividade de desenvolvi-
mento de software. É quando compreendemos o que o cliente quer e como será
desenhada a sua proposta para atender às expectativas dele. O objetivo do le-
vantamento de requisitos é compreender as tarefas que os usuários realizam,
além de procurar entender como eles usariam um novo sistema para ajudar na
realização dessas tarefas.
Durante o levantamento de requisitos, o engenheiro de software trabalha
com os usuários, a fim de saber sobre o domínio e as regras do negócio, quais
atividades devem ser envolvidas, os serviços, as ferramentas, as características da
aplicação que eles desejam, assim como o desempenho esperado e as limitações
de hardware, entre outros (SOMMERVILLE, 2018).
O levantamento de requisitos exige a compreensão dos requisitos dos sta-
keholders. Isso é considerado um processo difícil, por várias razões, como
verificaremos, a seguir:

1. Os usuários, muitas vezes, não sabem, exatamente, o que querem no

sistema, exceto em aspectos gerais, portanto, costumam fazer exigências
irreais, pois não sabem o que é viável ou não.

2. Os usuários expressam os requisitos em seus próprios termos devido

ao conhecimento de suas tarefas, com isso, os engenheiros de software,
sem experiência no domínio de negócio do cliente, talvez não entendam,
claramente, tais requisitos.

3. Diferentes usuários, com requisitos distintos, podem expressá-los de

maneiras variadas.

4. Fatores políticos e tributários costumam influenciar os requisitos de

um sistema.

58
 UNIDADE 2

5. O ambiente econômico e de negócios é dinâmico, então, inevitavelmen-

te, ocorrem mudanças durante o processo de análise.

6. Novos requisitos surgem, muitas vezes, devido a mudanças de novos

usuários que não foram, originalmente, consultados.

Fonte: Sommerville, 2018, p. 96

A atividade levantamento e análise de requisitos de software possui um modelo

de processo (Figura 3) com um conjunto de etapas/atividade. É um modelo com
processos iterativos e um feedback contínuo de cada atividade, o qual é transmi-
tido para as demais.

1. Descoberta e
compreensão dos
requisitos

4. Documentação 2. Classificação e
dos requisitos organização dos
requisitos

3. Priorização e
negociação dos
requisitos

Figura 3 - Modelo de processo de levantamento e análise de requisitos

Fonte: Sommerville (2018, p. 97).

Descrição da Imagem: a ilustração mostra as quatro atividades do modelo de processo de levantamento

e análise de requisitos. Essas atividades estão dispostas em círculo e ligadas por setas. Este recurso mostra
a sequência de cada atividade, em sentido horário. A primeira atividade é a descoberta e compreensão
dos requisitos, logo em seguida, vê-se a atividade classificação e organização dos requisitos. A terceira
atividade é a priorização e negociação dos requisitos e, na sequência, a quarta atividade, a documentação
dos requisitos. Esta encontra-se ligada, por meio de uma seta, à primeira atividade. Tal sequência forma
um processo contínuo e iterativo.

59
 UNIDADE 2

É possível observar, na imagem, que o ciclo se inicia com a descoberta e a com-

pressão dos requisitos, seguindo para a classificação, depois, são realizadas a
priorização e a negociação dos requisitos, então, o ciclo termina com a criação
da documentação. Por ser um processo iterativo, a compreensão do engenheiro
de software acerca dos requisitos aumenta a cada rodada do ciclo e termina
quando o documento for produzido, mas há a possibilidade de, ao longo do
ciclo de vida do software, haver mudanças.
Sobre a análise dos requisitos, Sommerville (2018, p. 97) indica que:

“
Para simplificar a análise dos requisitos, é útil organizar e
agrupar as informações dos stakeholders. Uma maneira de
fazer isso é considerar cada grupo de stakeholders como um
ponto de vista e coletar todos os requisitos desse grupo a
partir de um determinado ponto de vista. É possível incluir
pontos de vista para representar requisitos de domínio e
restrições dos outros sistemas. Alternativamente, é possível
usar um modelo da arquitetura do sistema para indicar sub-
sistemas e associar requisitos a cada um deles.

60
 UNIDADE 2

O Quadro 1 apresenta a descrição mais detalhada das atividades do modelo de

processo.
Modelo de processo de levantamento e análise de requisitos

Atividade em que ocorre a interação

com os stakeholders da aplicação
para a descoberta dos requisitos
de domínio e documentação. Deve
1. Descoberta e compreensão dos
haver a compreensão do domínio
requisitos
da aplicação, para que a transcrição
seja eficiente e clara aos demais pro-
fissionais envolvidos no processo de
desenvolvimento de software.

Atividade na qual os requisitos são

2. Classificação e organização dos
classificados e organizados em gru-
requisitos
pos coerentes.

Atividade na qual ocorrem a prioriza-

3. Priorização e negociação dos ção dos requisitos mais importantes
requisitos e a negociação para a resolução de
conflitos.

Atividade na qual os requisitos são

4. Documentação dos requisitos documentados e servem para a pró-
xima entrada na volta da espiral.

Quadro 1 - Descrição das atividades do modelo de processo de levantamento e análise de requisitos

Fonte: adaptado de Sommerville (2018)

EXPLORANDO IDEIAS

Ponto de vista é uma maneira de coletar e organizar um conjunto de requisitos de um

grupo de stakeholders que têm algo em comum. Portanto, cada ponto de vista inclui um
conjunto de requisitos de sistema. Os pontos de vista poderiam vir de usuários finais,
gerentes ou outros, e ajudam a identificar as pessoas que podem fornecer informações
sobre seus requisitos e estruturá-los para análise”.
Fonte: Sommerville (2018, p. 98).

61
 UNIDADE 2

NOVAS DESCOBERTAS

Título: Engenharia de Software

Autor: Ian Sommerville
Editora: Pearson Universidades
Sinopse: o livro traz questões essenciais para a Engenharia de Soft-
ware. Autor de conceitos vistos ao longo das nossas unidades, Sommerville
apresenta conteúdos importantes sobre a Engenharia de Requisitos que ga-
rantem a segurança e a resiliência dos sistemas, tais como: o gerenciamento
da complexidade e a integração da agilidade a outros métodos.
Comentário: recomendo o livro por ser uma obra de referência para estu-
dantes de Ciência da Computação, Engenharia da Computação e Sistemas
de Informação e, também, para qualquer profissional que deseje atualizar os
seus conhecimentos a respeito de requisitos, reuso de software, arquitetura
de projetos, Engenharia de Sistemas, confiabilidade e segurança.

Pense comigo: em uma empresa, podemos ter diferentes stakeholders e cada um

deles é capaz de ter opiniões diferentes sobre a importância dos requisitos frente
às diferentes prioridades. Devido a tal situação, os stakeholders podem entrar
em conflito e, muitos deles, por acharem a sua opinião mais relevante do que a
dos outros, têm o potencial de minar ou sabotar, deliberadamente, o processo
de levantamento de requisitos.
O que você pode fazer, nestes casos? Procurar organizar reuniões regulares
com os usuários, desenvolvendo espaços para expressar as opiniões e as preo-
cupações, tentando chegar a um acordo em relação aos requisitos e à prioridade
de cada um.
Como fazer esse levantamento de requisitos? Tanto a obtenção quanto a com-
preensão deles não são um processo formal, por isso, é difícil realizar a automatização.
Assim, o engenheiro de software deve usar algumas técnicas para coletar requisitos:
entrevistas, questionários, cenários, mapeamentos, entendimento do processo-alvo,
histórias de usuário, shadowing, protótipos, brainstorming, entre outras.
As técnicas voltadas à elicitação de requisitos de software serão estudadas
na Unidade 3.

62
 UNIDADE 2

Verificação e Validação dos Requisitos de Software

Aprendemos que o desenvolvimento de software é uma atividade com muitos

desafios complexos e que erros humanos são passíveis de ocorrer, durante todas
as fases desse processo. Mas como reduzir esses erros e os seus efeitos? Uma
alternativa é utilizar técnicas de verificação e validação, ao longo das atividades
do processo de desenvolvimento de software, principalmente, na fase de levan-
tamento de requisitos, com o objetivo de diminuirmos os erros e efeitos.
Validação e verificação de requisitos são atividades as quais garantem que
a necessidade real do usuário esteja descrita, corretamente, no documento de
requisitos, visando a descobrir erros nos requisitos documentados na atividade
de elicitação de requisitos. Lembre-se que o documento de requisitos é referência
para todas as demais atividades de desenvolvimento.
As atividades de validação e verificação são, extremamente, importantes, pois
o custo de correção de um requisito, nesta fase, é bem inferior ao custo nas fases
posteriores (implementação ou testes). Um erro de requisito encontrado pelo
cliente, quando o sistema já está em operação, exige a revisão de todos os artefatos
gerados — código-fonte, relatórios de testes, projeto de arquitetura do software e
o próprio documento de requisitos — o que implica custos significativos.

63
 UNIDADE 2

EXPLORANDO IDEIAS

Segundo Reinehr (2020), verificação e validação são termos diferentes. De acordo com a
norma internacional ISO/IEC/IEEE 12207 (ISO, 2017):
• A 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” (ISO, 2017,
p. 10-11, tradução minha).
• A verificação é a “confirmação, por meio do fornecimento de evidência objetiva, que
os requisitos especificados foram atendidos” (ISO, 2017, p. 10-11, tradução minha).
Ainda, de acordo com o CMMI-DEV 2.0 (CMMI INSTITUTE, 2018), a diferença entre os ter-
mos é a seguinte:
• A validação “demonstra que a solução vai atender seu uso pretendido no ambiente
alvo, isto é, ‘você está construindo a coisa certa’” (CMMI INSTITUTE, 2018, p. 525, tra-
dução minha).
• A verificação “endereça que o produto de trabalho ou a solução refletem adequada-
mente os requisitos especificados, isto é, ‘você está construindo certo’” (CMMI INSTI-
TUTE, 2018, p. 525, tradução minha).
Fonte: adaptado de Reinehr (2020), ISO (2017) e CMMI Institute (2018).

Vamos começar falando da atividade de validação de requisitos? Essa atividade

refere-se a um conjunto de tarefas as quais asseguram que o software foi criado
e pode ser rastreado segundo os requisitos do cliente. O objetivo principal da
validação é avaliar se o que foi entregue atende às expectativas, ou seja, se os
requisitos, independentemente do que foi planejado, estão implementados para
atender ao negócio do cliente.
A atividade de verificação de requisitos refere-se ao conjunto de tarefas que
garantem que o software implemente, corretamente, uma função específica. O
objetivo principal da verificação é avaliar se o que foi planejado, realmente, foi
realizado, se os requisitos e funcionalidades documentados foram implementa-
dos.
Entendeu a diferença entre validação e verificação? Para facilitar, adotaremos
as perguntas, a seguir:
Verificação: “estamos construindo, corretamente, o sistema?”. Diz respeito
ao que foi construído).
Validação: “estamos construindo o sistema correto?”. Diz respeito ao enten-
dimento do que era para ser construído.

64
 UNIDADE 2

Durante o processo de validação de requisitos, diferentes tipos de verificação

devem ser efetuados, no documento, com os requisitos. Essas verificações podem
ser observadas no Quadro 2.

Tipos de Verificação Descrição

Identificar se certas funções citadas

como necessárias por um usuário
Verificações de validade
são, realmente, indispensáveis para
o todo.

Requisitos no documento não

devem entrar em conflito, não deve
Verificações de consistência haver restrições contraditórias ou
descrições diferentes da mesma
função do sistema.

Deve incluir requisitos que definem

Verificações de completude todas as funções e as restrições pre-
tendidas pelo usuário do sistema.

Os requisitos devem ser verificados

para assegurar que podem, realmen-
Verificações de realismo
te, ser implementados (considerar o
orçamento e o cronograma).

Os requisitos do sistema devem ser

passíveis de verificação, por meio de
um conjunto de testes direcionados
Verificabilidade
a demonstrar que o sistema entre-
gue atende a cada requisito especi-
ficado.

Quadro 2 - Diferentes tipos de verificação do processo de validação de requisitos

Fonte: adaptado de Sommerville (2018).

Para a realização da atividade de validação, Sommerville (2018) propõe algumas

técnicas de validação: revisões técnicas de requisitos, prototipação e geração de
casos de teste.
A Figura 4, a seguir, descreve cada uma dessas técnicas.

65
 UNIDADE 2

Formal:
trata-se de um processo no qual
a equipe examina as especificações
procurando por erro de registro ou
de interpretação, por requisitos
que precisam de mais esclarecimento

Revisão Técnica

Informal:
debate que ocorre entre equipe
técnica e cliente com o objetivo
de identificar problemas e propor
soluções

Os requisitos são apresentados de maneira

mais lúdica, por exemplo, no formato de
Técnicas de
Prototipação telas para o usuário, facilitando a
Validação interpretação das rotinas a serem
desenvolvidas

Geração de
Casos de Teste

Verifica-se se o requisito é implementável

e isto significa que ele é de fácil interpretação
e codificação, caso não seja, ele deve ser
reconsiderado

Figura 4 - Técnicas de validação de requisitos / Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: a ilustração apresenta, dispostas em quadros, as técnicas de validação, no caso,

revisão técnica, prototipação e geração de casos de teste. Cada quadro contém linhas que ligam cada uma
das atividades ao quadro maior, chamado de técnicas de validação. A técnica de revisão técnica pode ser
formal ou informal. A formal trata de um processo no qual a equipe examina as especificações procurando
por erro de registro ou de interpretação e por requisitos que precisam de mais esclarecimento. A informal
é um debate que ocorre entre equipe técnica e cliente com o objetivo de identificar problemas e propor
soluções. Na técnica de prototipação, os requisitos são apresentados de maneira mais lúdica, por exemplo,
no formato de telas para o usuário, facilitando a interpretação das rotinas a serem desenvolvidas. Na
técnica geração de casos de teste, verifica-se se o requisito é implementável. Isto significa que ele é de
fácil interpretação e codificação, caso não seja, deve ser reconsiderado.

Outra técnica de validação de requisitos sugerida por Sommerville (2018) é a

técnica de checklist. Ela deve ser usada durante a revisão técnica formal de requi-
sitos, pois auxilia o analista de requisitos a coordenar a reunião de revisão formal

66
 UNIDADE 2

de requisitos, colaborando para manter o foco dos revisores nas características

importantes. Os checklists costumam ser aplicados a documentos de análise,
projeto, codificação e testes.
Os objetivos da técnica de checklist são descobrir erros possíveis em funções
bem como erros de lógica ou de implementações no software. Também é avaliado
se o software atende aos requisitos antes especificados, sendo necessário garantir
que ele seja representado de acordo com os padrões predefinidos e desenvolvido
de maneira uniforme, como padrão para o desenvolvimento de projetos mais
gerenciáveis (SOMMERVILLE, 2018).
O Quadro 3 apresenta um modelo de checklist de validação de requi-
sitos com base na análise e na compilação de vários modelos que tenham as
características necessárias para a validação da especificação de requisitos, porém
considerando o cenário de visão do negócio do cliente.

67
 UNIDADE 2

Modelo de checklist
ITEM ITEM PARA VERIFICAÇÃO SIM NÃO

Cada requisito está descrito

1 com clareza e concisão, sem
ambiguidades?

2 Existem requisitos conflitantes?

3 Existem requisitos implícitos?

Os requisitos exibem a distinção

4 clara entre funções, dados e
restrições?

As restrições e dependências
5
foram, claramente, descritas?

Existem requisitos que contêm

6 algum nível desnecessário de
detalhe do projeto?

Os requisitos definem todas as

7 informações a serem apresenta-
das aos usuários?

Os requisitos descrevem as
8 respostas do sistema ao usuário
devido às condições de erro?

Existem situações não tratadas

9 pelos requisitos que precisam
ser consideradas?

O documento contém, realmen-

10 te, toda a informação que foi
prometida em sua introdução?

Quadro 3 - Modelo de checklist de validação de requisitos / Fonte: adaptado de Sommerville (2018).

68
 UNIDADE 2

Analisando as informações no quadro e com base no processo de análise rea-

lizado para o desenvolvimento de um sistema, surgem as características “não
ambíguo”, “completo” e “consistente” voltadas à validação dos requisitos, pois elas
estão, totalmente, envolvidas no processo de análise do sistema.
■ Não ambíguo: esta característica é atribuída, somente, se cada requisito
declarado ser suscetível a uma interpretação, apenas.
■ Consistente: característica atribuída, somente, se nenhum dos requisi-
tos do documento — tomado individualmente — está em conflito com
qualquer outro requisito do mesmo documento.
■ Completo: característica atribuída, somente, se houver toda a informa-
ção necessária (e apenas ela) para que o software correspondente seja
produzido.

Acompanhe a Figura 5, na qual são demonstradas as possíveis entradas e saídas

para o processo de validação de requisitos.

Especificações
de Requisitos
Validação de Lista de Problemas
Requisitos e Ações
Conhecer a
Organização Saídas
(Negócio e Padrões)

Entradas

Figura 5 - Entradas e saídas do processo de validação de requisitos

Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: Descrição da imagem: a ilustração mostra as entradas “Especificação de requisitos”

e “Conhecer a organização (negócios e padrões)”, representadas por flechas preenchidas com os respec-
tivos textos. Em “Especificação de requisitos”, a entrada são as informações contidas na versão completa
do documento de requisitos. Na entrada “Conhecer a organização” é onde temos as informações sobre
os stakeholders e as pessoas envolvidas na validação de requisitos as quais possuem o conhecimento
acerca do negócio e dos padrões da organização. Enquanto saída do processo, há a “Lista de problemas e
ações”. A lista de problemas deve ser organizada por tipo, como: inconsistentes, incompletos, intangíveis
etc., a fim de facilitar a identificação bem como auxiliar nas possíveis soluções. A lista de ações precisa
conter as atividades a serem realizadas para solucionar os problemas listados.

69
 UNIDADE 2

Assim, levando em consideração as entradas e saídas, ao final do processo de va-

lidação de requisitos, temos, praticamente, o documento de requisitos completo.
Para completar esse documento, a seguir, temos a fase de especificação de
requisitos de software.

EXPLORANDO IDEIAS

“Documentos de requisitos são essenciais quando um contratante externo está desen-

volvendo o sistema de software. Entretanto, os métodos ágeis de desenvolvimento argu-
mentam que os requisitos mudam tão rapidamente que um documento de requisitos e
no final, já está ultrapassado assim que termina de ser escrito. Portanto, o esforço é, em
grande parte, desperdiçado. Em vez de um documento formal, abordagens como a Extre-
me Programming, que coletam os requisitos de usuário de forma incremental e escrevem
nos em cartões como estórias de usuário. O usuário então prioriza os requisitos para
implementação no próximo incremento do sistema. Acredito que essa seja uma boa abor-
dagem para os sistemas de negócio em que os requisitos são instáveis. No entanto, penso
que ainda é útil escrever um pequeno documento de apoio no qual estejam definidos os
requisitos de negócio e de confiança para o sistema; quando o foco está nos requisitos
funcionais dos próximos releases do sistema, é fácil nos esquecermos dos requisitos que
se aplicam ao sistema como um todo”.
Fonte: Sommerville (2018, p. 77). .

Especificação de Requisitos de Software

Na Unidade 1, foram apresentados os conceitos fundamentais da Engenharia

de Requisitos. Falamos sobre o documento de requisitos e exemplificamos uma
estrutura para o preenchimento das informações trazidas por ele.
Neste tópico, será detalhado como especificar os requisitos para escrever o
documento de requisitos. A especificação de requisitos, segundo Sommerville
(2018, p. 79), “é o processo de escrever os requisitos de usuário e de sistema em
um documento de requisitos”. O mesmo autor afirma que eles devem ser claros,
inequívocos, de fácil compreensão, completos e consistentes.
Pensando em termos práticos: isso não é uma tarefa fácil. Por quê? Devido
ao fato de os requisitos terem a possibilidade de ser interpretados de maneira
diferente pelos stakeholders. Assim surgem os conflitos, as inconsistências e as

70
 UNIDADE 2

ambiguidades nos requisitos. Idealmente, o documento deve considerar o pú-

blico a quem se destina, em suma, os leitores.
O Quadro 4 apresenta os públicos-alvo do documento de requisito.

Público que lê o documento para validar se está de

Clientes
acordo com o que foi solicitado.

Público que utiliza o documento para solicitar uma

Gerentes
proposta e planejar o processo de desenvolvimento.

Público que utiliza o documento para entender o

Programadores
que deve ser desenvolvido/implementado.

Público que utiliza o documento para planejar os

Testes
testes de validação do sistema.

Público que utiliza o documento para compreender

Manutenção
o sistema e as suas relações.

Quadro 4 - Público-alvo do documento de requisito / Fonte: adaptado de Sommerville (2018).

O documento de requisitos deve descrever os requisitos do sistema, não os deta-

lhes da arquitetura ou do projeto do sistema. Ao escrever o documento, nos re-
quisitos de usuário, procure não usar o jargão de software, tampouco as notações
estruturadas ou formais. Caso você escreva os requisitos de sistema — usados por
engenheiros de software como ponto de partida ao desenvolvimento do proje-
to — procure acrescentar detalhes que explicam como os requisitos de usuário
precisam ser atendidos, ou seja, uma especificação completa de todo o sistema.
De acordo com Sommerville (2018), no momento de realizar o registro dos
requisitos e as definições para a validação, é recomendado considerar alguns
parâmetros:
■ Necessidade: releia e verifique se os requisitos descritos são necessários.
Pergunte-se “esta função é necessária?”.
■ Verificável: durante e após a escrita, verifique se o que está sendo produ-
zido poderá ser verificável. Pergunte-se “como posso testar esta função?”.
■ Realizável (atingível): após a escrita, analise se o requisito descrito po-
derá ser desenvolvido levando em consideração a tecnologia disponível,
o orçamento e o prazo determinados no planejamento do projeto. Per-
gunte-se “o requisito é atingível?”.

71
 UNIDADE 2

■ Claro: releia o documento, então, verifique se cada requisito expressa

uma única função e, também, se os requisitos especificam um bom re-
quisito. Pergunte-se “está claro o que precisa ser feito?”.

Na descrição dos requisitos, é recomendável empregar uma linguagem natural,

com tabelas simples, além de formas e diagramas intuitivos.
Sommerville (2018) descreve, ainda, algumas regras básicas, a seguir:
■ Use um formato padrão na escrita e garanta que todos os requisitos sigam
esse padrão.
■ Use uma linguagem coerente, variações de verbos para indicar os requi-
sitos obrigatórios e desejáveis.
■ Procure destacar as partes mais importantes na descrição do requisito.
■ Não use jargões técnicos na escrita do requisito a ser desenvolvido. Caso
sejam termos de negócio, importantes ao domínio da aplicação, procure
detalhar da forma mais completa.

Quando o nível da especificação dos requisitos for considerado mais técnico, a

descrição pode ser feita utilizando linguagem natural, porque se exigir muitos
detalhamentos, é possível surgir problemas no momento de documentar.
Como vimos, anteriormente, a interpretação de um requisito ou de uma regra
de negócio depende do usuário do sistema, e a linguagem natural possui uma
ambiguidade intrínseca, mas ela é, também, muito flexível, pois permite escre-
ver a mesma coisa de muitas maneiras diferentes, entretanto ela não possibilita
padronização.
Visando a contornar este problema, temos algumas linguagens padroniza-
das — sugeridas por Sommerville (2018) — para a especificação de requisitos,
conforme mostra o Quadro 5.

72
 UNIDADE 2

Linguagem padronizada Descrição

Os requisitos são escritos em lin-

guagem natural em um formulário
Linguagem natural estruturada padrão ou template. Cada campo for-
nece informações sobre um aspecto
do requisito.

Os requisitos são escritos em uma

linguagem como a de programação,
mas com características mais abstra-
Linguagem de descrição de projeto
tas, a fim de especificar os requisitos,
definindo um modelo operacional do
sistema.

Os requisitos são definidos usando

modelos gráficos, suplementados por
Notações gráficas
anotações de texto, diagramas de
caso de uso e sequência da UML®.

Os requisitos são escritos com nota-

ções baseadas em conceitos matemá-
ticos, como máquinas de estado finito
ou conjuntos. Embora essas especifi-
Especificações matemáticas
cações possam reduzir a ambiguida-
de de um documento de requisitos,
a maioria dos clientes não entende
uma especificação formal.

Quadro 5 - Lista de algumas linguagens padronizadas à especificação de requisitos

Fonte: adaptado de Sommerville (2018).

Para a disciplina, faremos o uso da linguagem natural estruturada e usaremos o

template padrão para a especificação dos requisitos do sistema.

73
 UNIDADE 2

Engenharia de Requisitos de Software: conhecendo

todas as etapas do processo
Vimos que a Engenharia de Requisitos é um processo que
engloba todas as atividades contribuidoras à produção de
um documento de requisitos e à sua manutenção ao longo
do ciclo de vida de um software. Confira o podcast, saiba
a importância de conhecer e entender todas as etapas de
todo o processo.

A fim de concluir a nossa unidade, seguem mais alguns exemplos práticos para
continuarmos a preencher o documento de requisitos do sistema online de ge-
renciamento de casas de apoio social (SGCA) que vimos na Unidade 1. Agora,
foram incluídos mais exemplos de especificação dos requisitos.

Requisitos Funcionais

Preencha o quadro, a seguir, com as informações pertinentes a cada um dos

requisitos.

PR:
RF RF002 Cadastrar casas de apoio social UC: 002
alta

O sistema deverá ter o cadastro de casas de apoio social de modo

que o usuário poderá cadastrar os dados referentes às casas de
Descrição/Ação
apoio.

Informações das casas de apoio social (nome, endereço, cidade,

Entrada
telefone e outras informações).

Cadastro das informações das casas de apoio social efetuado com

Saída
sucesso.

Pré-condição Ter efetuado login, com sucesso, no sistema.

Pós-condição Cadastro da casa de apoio social no sistema.

Stakeholder Usuário administrador do sistema.

74
 UNIDADE 2

UC: PR:
RF RF003 Altera casas de apoio social
002 alta

O sistema deve permitir alterar o cadastro de casas de apoio

Descrição/Ação social de modo que o usuário poderá alterar os dados referentes
às casas de apoio.

Entrada Lista de casas de apoio social cadastradas no sistema.

Alteração das informações das casas de apoio social efetuada

Saída
com sucesso.

Informações das casas de apoio social (nome, endereço, cidade,

Pré-condição
telefone e outras informações) gravadas/salvas no sistema.

Pós-condição Cadastro da casa de apoio social alterado no sistema.

Stakeholder Usuário administrador do sistema.

UC: PR:
RF RF004 Excluir casas de Apoio Social
002 alta

O sistema deve permitir excluir o cadastro de casas de apoio

Descrição/Ação social de modo que usuário poderá excluir os dados referentes
às casas de apoio.

Entrada Lista de casas de apoio social cadastradas no sistema.

Saída Exclusão das casas de apoio social efetuado com sucesso.

Informações das casas de apoio social (nome, endereço, cidade,

Pré-condição
telefone e outras informações) gravadas/salvas no sistema.

Pós-condição Cadastro da casa de apoio social excluído no sistema.

Stakeholder Usuário administrador do sistema.

75
 UNIDADE 2

Requisitos Não Funcionais

RNF RF002 Usabilidade UC: PR: alta

O sistema deve prover uma interface simples e intuitiva, de

Descrição/Ação
fácil navegação, para facilitar o uso por parte dos usuários.

Entrada Não se aplica.

Saída Não se aplica.

Pré-condição Não se aplica.

Pós-condição Não se aplica.

Stakeholder Não se aplica.

RF003 Acesso ao sistema

RNF UC: PR: média
(Segurança)

O sistema deverá permitir o acesso dos usuários, somente

após esses usuários informarem o seu usuário e senha, caso
Descrição/Ação já esteja cadastrado, ou ainda, somente após a realização do
um novo cadastro e, consequentemente, o acesso com os
dados de usuário e senha.

Entrada Informação válida de nome de usuário e senhas.

Saída Login de usuário efetuado com sucesso.

Pré-condição Não se aplica.

Pós-condição Autenticação de usuário efetuado, com sucesso, no sistema.

Stakeholder Usuário administrador do sistema.

Em que:
■ Função: identifica a função do requisito sendo: Requisito Funcional (RF),
Requisito Não Funcional (RNF) ou Requisito De Domínio/Negócio (RD
ou RN) contendo a descrição e a identificação numérica ou outro código,
por exemplo: RF001, RF002, RNF003 etc.

76
 UNIDADE 2

■ UC: é a identificação do caso de uso que auxilia na especificação do requi-

sito. Pode ser, também, a identificação de um método, uma representação
gráfica ou os diagramas da UML@.
■ PR: representa a prioridade estipulada ao requisito para o seu desenvol-
vimento. Pode ser alta, média ou baixa.
■ Descrição/Ação: campo para ser usado à descrição do requisito ou à
ação a ser tomada.
■ Entrada: onde são descritas as entradas necessárias para o processamento
da função do requisito.
■ Saída: onde são descritas as saídas ou os resultados produzidos com o
desenvolvimento do requisito.
■ Pré-condições: campo que descreve o que deve ter ocorrido ou deve estar
disponível antes da execução/desenvolvimento do requisito.
■ Pós-condições: campo que descreve o que deve ser mostrado quando a
execução do requisito se completar.
■ Stakeholder: campo que identifica o stakeholder solicitante do requisito.

Este formulário preenchido precisa ser incorporado, no formato de quadro, ao

documento de requisitos.

77
 UNIDADE 2

OLHAR CONCEITUAL

Atividades responsáveis pela

documentação, versionamento,
controle de mudanças e
qualidade dos requisitos.

Processo de Engenharia de
Requisitos de Software

Especificação Gestão de
É onde compreendemos o de requisitos requisitos
que o cliente quer e como
será desenhada sua proposta
para atender às expectativas
dele.
Levantamento
e Análise de Processo de escrever os
requisitos requisitos de usuário e de
sistema de um documento
de requisitos.
Garantem que a necessidade Verificação
Especificação
real do usuário esteja descrita e Validação
de requisitos
corretamente no Documento dos Requisitos
de Requisitos, tendo como
objetivo descobrir erros nos
requisitos documentados.

78
Mapa de Empatia de Processos de Engenharia de Requisitos de Software

Como avaliar os melhores

requisitos?

O que ainda ficou complexo Qual etapa apresentada no

para a sua compreensão? podcast você achou mais
desafiadora?

O que mais te chamou

atenção no conteúdo da unidade?

O que você ganhou ao aprender sobre o conteúdo O que você gostaria de acrescentar ou sugerir
apresentado? sobre o conteúdo apresentado?
3
Técnicas de
Elicitação de
Requisitos de
Software
Esp. Janaína Aparecida de Freitas

Caro (a) estudante, nesta unidade, você conhecerá as fontes de infor-

mação usadas no levantamento dos requisitos de software, além de
algumas técnicas de elicitação de requisitos e como as selecionar de
acordo com o contexto do que será desenvolvido.
 UNIDADE 3

Lembra que, na Unidade 1, falamos que entender os requisitos de um proble-

ma ou de uma necessidade de um cliente é uma das tarefas mais difíceis de ser
enfrentada pelo engenheiro de software? Explicamos que a dificuldade está em
entender, realmente, o que o cliente quer, por isso, registramos os requisitos de
forma desorganizada e gastamos pouco tempo para organizar ou gerenciar estas
informações.
Vem à nossa cabeça aquela frase: “você não entendeu o que eu disse, pois o
que eu disse não era o que eu quis dizer”. Isso é assustador para muitas empresas
que passaram por determinadas situações: o cliente não gostou do que foi desen-
volvido; ele achou que a função desenvolvida não foi solicitada por ele; o cliente
achou o orçamento muito alto para o projeto e com prazo muito longo para ficar
pronto; esse cliente pensou que o sistema deveria realizar determinadas ações,
então, encontrou erros nesse mesmo sistema, entre muitas outras situações as
quais levaram projetos ao fracasso, gerando prejuízos.
Para evitar este panorama assustador, as empresas investem em técnicas de
coleta dos requisitos, de forma a compreender as reais necessidades do cliente e
as informações por ele transmitidas.
Há várias técnicas que podem ser usadas, portanto, você deve estar se per-
guntando qual a melhor ou como saberá qual delas usar. A resposta é: depende
do contexto do projeto, da tecnologia e dos recursos disponíveis.
Para você entender a situação, te apresentarei a Maria. Ela é funcionária de um
restaurante e exerce a função de controlar as compras mensais. Maria controla a
sua lista de compras por meio de uma planilha do Excel, onde cadastra o nome
do produto, a unidade de compra, a quantidade prevista para o mês, a quantidade
que, efetivamente, será comprada, o preço estimado (atualizado todo mês) e o
valor total de cada compra.
Agora, imagine que você é o(a) engenheiro(a) de software responsável pela
coleta de requisitos para desenvolver um sistema de controle de compras à em-
presa onde Maria trabalha. Seguem algumas informações: a quantidade de com-
pra pode variar em virtude da sobra de um mês para o outro ou da necessidade
de gasto maior no mês. As compras são feitas pela própria Maria, por este motivo,
ela não vê necessidade de relacionar as marcas dos produtos. Mensalmente, a
funcionária analisa o quanto o restaurante pagou por cada produto e, se ela achar
necessário, atualiza o preço estimado de cada mercadoria, semanalmente.

82
 UNICESUMAR

Registre, em seu Diário de Bordo, quais ações você realizaria para coletar os
requisitos e desenvolver um sistema de controle de compras para a empresa na
qual Maria trabalha.

Recomendo que pense, como exemplo, na seguinte situação: você precisa com-
prar produtos para a sua casa ou para a casa da sua família. Qual seria a primeira
anotação? Provavelmente, começaria anotando o que está faltando e a quantida-
de, certo? E como você organizaria estas informações? A fim de te auxiliar, analise
a planilha usada pela Maria, então, anote tudo o que conseguir!
Qtde. com- Preço esti-
Produto Unidade Qtde. mês
pra mado

Carne Kg 8 7,5 15,00

Arroz Kg 2 1 10,00

Feijão Kg 6 6 3,50

Leite Litro 12 2 2,20

Tabela 1 - Lista de compras da Maria / Fonte: a autora.

83
 UNIDADE 3

Para você entender como realizar a coleta de requisitos durante o desenvolvimen-

to de um software, é necessário identificar quais as fontes de informação que
podem ser usadas, com o intuito de compreender as necessidades dos clientes e
como interagir com eles.
O processo de coleta dos requisitos tem, como objetivo, definir e documentar
as características dos produtos e serviços do projeto que satisfarão às necessi-
dades e expectativas dos usuários do sistema. Coletar requisitos é o processo
de interagir com os usuários, visando descobrir os requisitos do sistema, porém
esses requisitos precisam ser bem definidos, bem analisados e descritos com
detalhamento suficiente para serem medidos (aceitos) e, também, controlados
durante o desenvolvimento do software (SOMMERVILLE, 2018).

84
 UNICESUMAR

Todo o projeto possui um ou mais clientes, sejam internos, sejam externos.

Na prática, a coleta dos requisitos estabelece os produtos e serviços que serão
gerados e entregues a esses clientes, ação a qual denominamos escopo para o
cliente ou escopo do cliente. Para que seja entregue o escopo, outras entregas
devem ser geradas. Segue um exemplo:
Imagine que um cliente solicite a construção de uma termelétrica ou ter-
moelétrica, estabelecendo todas as características que a mesma deve ter. O cliente
permite que seja fornecido, inclusive, um projeto básico de Engenharia. Para a
termoelétrica ser construída, são necessárias as aquisições de turbinas, transporte
marítimo e terrestre, seguro e outras entregas, não solicitadas pelo cliente. A de-
finição dessas outras entregas depende da estratégia de condução do projeto. O
escopo do projeto é maior do que o escopo para o cliente (Figura 1).

Produto e
Escopo do projeto X Escopo para o cliente serviços que
serão gerados e
entregues ao
cliente

Escopo do
Cliente

Depende da Escopo do Projeto

estratégia de
condução do
projeto

Figura 1 - Escopo do projeto x Escopo para o cliente / Fonte: a autora.

Descrição da Imagem: a ilustração mostra dois círculos, onde o maior deles representa o escopo do
projeto. Esse círculo encontra-se ligado a uma caixa de diálogo e, no interior dela, lê-se o texto: “Depende
da estratégia de condução do projeto”. O círculo menor está dentro do maior e representa o escopo do
cliente. Esse círculo menor encontra-se ligado a uma caixa de diálogo e, no interior dela, lê-se o texto:
“Produtos e serviços que serão gerados e entregues ao cliente”.

Em muitos casos, objetivando entender os produtos e serviços a serem gerados

ou as estratégias de condução, é possível conversar com alguém responsável por

85
 UNIDADE 3

essas definições, mas há casos cuja lei determina o que deve ser feito. Para cada
software existem, também, diversos olhares e perspectivas vindos das partes en-
volvidas.
Para cada projeto, existe uma forma adequada de coletar os requisitos
de um produto de software. Segundo Reinehr (2020), temos diferentes tipos
de produtos de software e cada um implica diferentes tipos de requisitos, com
isso, há distintas fontes de informação para a coleta.
Pense em vários tipos de sistema: de informação para as áreas administrativas,
de controle do tráfego aéreo, para a área da saúde, para a logística, o agronegócio
e o controle de usinas, de jogos de celular, entre outros. São sistemas diferentes
e que possuem particularidades de cada tipo de negócio e de cada contexto
de projeto, com isso, fontes de informação diferentes.
Em alguns casos, é possível que haja falha no momento de identificar as
fontes de informação para o tipo de sistema, acarretando muitas consequências,
por exemplo: usuários esquecidos, requisitos importantes que surgem quando o
sistema estiver em uso etc. O melhor é tentar envolver todas as fontes de infor-
mação disponíveis.

“
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, restrições e escopo. Geralmen-
te, 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 desen-
volvimento 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 com-
pliance. 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) (REINEHR, 2020, p. 53, grifos do autor).

Assim como existem tipos de sistemas, também existem classificações para os

tipos de fonte de informação, como mostra o Quadro 1, a seguir.

86
 UNICESUMAR

Tipo de informação Descrição

Influenciam direta ou indiretamente

os requisitos do sistema, tais como:
Stakeholders usuários, operadores do sistema,
desenvolvedores, arquitetos, clientes
e testadores.

Recurso que contém informações

importantes, passíveis de se torna-
rem requisitos, como: documentos
Documentos de ordem legal ou regulatória, nor-
mas e padrões, documentos espe-
cíficos do domínio do negócio ou da
própria empresa.

São sistemas legados, predecesso-

res, ou, mesmo, concorrentes. Os
Sistemas em operação sistemas podem ser a fonte de infor-
mações sobre novas funcionalidades
desejadas pelos clientes.

Quadro 1 - Tipos de fonte de informação / Fonte: adaptado de Reinehr (2020).

Quando identificamos as fontes de informação, devemos lembrar quais os

stakeholders que precisam ser considerados, pois eles influenciam os requi-
sitos, afinal, estão ligados, diretamente, às funcionalidades e regras de negócio.
O nível de envolvimento dos stakeholders, muitas vezes, varia de acordo com as
diferentes necessidades do projeto que está sendo desenvolvido e dos requisitos.
A origem dos requisitos deve estar clara e, de acordo com Reinehr (2020), os
stakeholders, independentemente de como são classificados, devem estar “en-
volvidos logo no início do processo de elicitação de requisitos”. Como descobrir
quais as fontes de informação? Ao conversar com o cliente, procure identificar
as áreas de negócio que serão impactadas pelo software, identifique regras, leis
e regulamentações as quais precisam ser atendidas bem como os stakeholders
responsáveis por essas áreas e informações.
Existem inúmeras técnicas para interagir com os stakeholders. Elas auxiliam
tanto na identificação das fontes de informação quanto na coleta de requisitos.

87
 UNIDADE 3

Técnicas para Elicitação de Requisitos de Software

A elicitação de requisitos é considerada a etapa mais crítica da Engenharia

de Requisitos, pois é o coração de todo o processo de desenvolvimento de
software. Não é uma tarefa fácil reunir-se com os stakeholders, conquistá-los
e tentar entender as características do projeto que determinarão a técnica mais
adequada para a coleta de requisitos.
As razões para tal etapa ser considerada tão crítica podem ser: (i) os usuários,
talvez, não sabem explicar como realizam as suas tarefas diárias; (ii) esses usuá-
rios deixam informações importantes de lado; (iii) eles, simplesmente, não estão
disponíveis para transmitir as informações; (iv) não querem prestar informações
sobre as suas tarefas.
É função do engenheiro de requisitos tentar resolver, adequadamente, essas
situações, além de selecionar a técnica de elicitação mais apropriada para cada
situação específica.

88
 UNICESUMAR

A Figura 2 mostra as técnicas e ferramentas voltadas à coleta de requi-

sitos bem como as entradas e saídas esperadas.

Técnicas e Ferramentas
Entrevistas
Brainstorming
Entrada
Histórias de usuário (user stories)
Compreensão Oficinas
dos Requisitos Questionários
Pesquisas
Cenários
Shadowing

Saída
Matriz da Rastreabilidade dos Requisitos
Documentação dos Requisitos

Figura 2 - Técnicas e ferramentas para a coleta de requisitos

Fonte: adaptada de Sommerville (2018).

Descrição da Imagem: a ilustração apresenta as técnicas e ferramentas para a coleta de requisitos, além
das entradas e saídas esperadas. É possível ver um retângulo intitulado “Entrada” e, embaixo desse título,
o texto “Compreensão dos requisitos”. Esse retângulo se relaciona, por meio de uma seta, com outro
retângulo que contém a seguinte lista de técnicas e ferramentas: “Entrevistas”, “Brainstorming”, “Histórias
de usuário (user stories)”, “Oficinas”, “Questionários”, “Pesquisas”, “Cenários”, “Shadowing”. Este retângulo
se relaciona, por meio de uma seta, com o retângulo intitulado “Saída” e, embaixo desse título, estão os
seguintes textos: “Matriz de rastreabilidade dos requisitos” e “Documentação dos requisitos”.

Uma técnica de elicitação de requisitos pode ser compreendida “como uma fer-
ramenta para auxiliar o analista de requisitos na condução da etapa de elicitação
e compreensão dos requisitos do software” (REINEHR, 2020, p. 58).
A seguir, serão analisadas algumas técnicas de coleta de requisitos: entrevis-
tas, brainstorming, histórias de usuário (user stories), oficinas e questionários.

89
 UNIDADE 3

Entrevista

A entrevista é uma das técnicas mais simples de ser utilizada a partir de fontes
humanas e, também, é uma das mais tradicionais na coleta de requisitos, afinal,
ela produz bons resultados, principalmente, na fase inicial do levantamento de
informações. Trata-se de uma conversa entre duas pessoas, provocada por uma
delas e com um objetivo definido.

“
A entrevista proporciona o contato pessoal, que faz com que o en-
trevistado se sinta parte do processo de construção da solução. A
entrevista facilita a obtenção de informações que, muitas vezes, es-
tã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 (REINEHR, 2020, p. 59).

Convém deixar o entrevistado expor as suas ideias e, a fim de evitar a dispersão

do assunto, o ideal é preparar um plano de entrevista para produzir bons
resultados. Mas, como executar a entrevista? A seguir, apresentamos alguns
procedimentos a serem pensados quando se usa a técnica de entrevista:
■ Identifique os stakeholders que serão entrevistados.
■ Cuidado com o clima amistoso entre você e o usuário/cliente: ele não é
seu amigo.
■ Evite induzir as respostas. Por exemplo: “para calcular este resultado, bas-
ta multiplicar A por B, não é?” .
■ Prepare uma lista de questões.
■ Procure fazer todas as anotações possíveis, elas poderão ser úteis mais
tarde.
■ Deixe o cliente/usuário à vontade porque, normalmente, este público não
gosta de ser entrevistado.

A seguir, a Figura 3 mostra a técnica entrevista, inclusive as suas vantagens, di-

ficuldades e aplicações.

90
 UNICESUMAR

Motivar o entrevistado

Vantagens
Alterar a ordem das perguntas

Evitar que a entrevista fique longa

Entrevista Dificuldades

Desvio do assunto ao longo da entrevista

Aplicação Usada em qualquer situação

Figura 3 - A técnica entrevista e as suas vantagens, dificuldades e aplicação / Fonte: a autora.

Descrição da Imagem: a ilustração mostra um retângulo com o título “Entrevista”. Esse retângulo está
ligado, por meio de três linhas, a três retângulos que apresentam, cada um, os seguintes textos: “Van-
tagens”, “Dificuldades” e “Aplicação”. No retângulo “Vantagens”, estão os seguintes tópicos: “Motivar o
entrevistado” e “Alterar a ordem das perguntas”. No retângulo “Dificuldades”, é possível ler os seguintes
tópicos: “Evitar que a entrevista fique longa” e “Desvio do assunto ao longo da entrevista”. No retângulo
“Aplicação”, está o seguinte tópico: “Usada em qualquer situação”.

A entrevista tem a possibilidade de ser conduzida de forma presencial, mas, hoje,

ela pode ser realizada online, por meio do uso de ferramentas de comunica-
ção. Neste caso, precisamos ter o cuidado de garantir que a tecnologia escolhida
funcione, adequadamente, evitando as interrupções que possam prejudicar o
andamento da entrevista.
A seguir, apresentamos um exemplo de um roteiro de entrevista.

91
UNIDADE 3

ROTEIRO DA ENTREVISTA
[Transcreva, aqui, o roteiro utilizado para realizar as entrevistas].

Exemplos de perguntas básicas sobre o tipo de serviço:

1. Qual o tipo de encomenda que você faz? Quais são os produtos?

2. Há quanto tempo você trabalha com isso? Este trabalho é a sua fonte
de renda principal?

Exemplos de perguntas básicas sobre a organização dos pedidos:

3. Como você organiza as suas encomendas? Anota no papel, na agenda,

no celular? Ou não anota?

4. Quais as dificuldades que você encontra ao utilizar este método? Já

esqueceu/atrasou alguma encomenda? Já confundiu as encomendas? Já
esqueceu de anotar alguma encomenda ou informação?

5. Você está satisfeito(a) com esse método? Por quê?

Exemplos de perguntas básicas sobre o uso de tecnologia para auxiliar

nestas atividades:

6. Você usa aplicativos para realizar atividades cotidianas ou organizá-las?

7. Você usa/já usou algum aplicativo ou programa para organizar as suas

encomendas e os seus pedidos?

8. Você gostaria de utilizar um software para organizar as suas encomen-

das? Qual tipo? Aplicativo ou programa no computador? Quais funcionali-
dades gostaria de ter num aplicativo para organizar as encomendas?

RESPOSTAS DAS ENTREVISTAS

[Transcreva, aqui, as respostas dos entrevistados e, se possível, identifi-

que-os].

92
 UNICESUMAR

Exemplo de respostas sobre o(a) entrevistado(a):

Rayanne (4º ano de Comércio).

Respostas básicas sobre o tipo de serviço:

1. Ramo de doces, em especial, brigadeiros com diversos granulados.

2. Três anos.

3. No momento não, mas essa atividade foi, por dois anos, a renda principal
da família, o que ajudou bastante.

Respostas básicas sobre a organização dos pedidos:

4. Para organizar os pedidos, geralmente, escrevo no celular e organizo

por data, coloco o nome do cliente e, também, a quantidade de doces
solicitados. Posteriormente, criei, no próprio celular, uma planilha (Excel)
e anoto todo o material necessário à realização da encomenda, além do
lucro, da entrada e da saída de dinheiro.

Quadro 2 - Exemplo de roteiro de entrevista / Fonte: a autora.

93
 UNIDADE 3

EXPLORANDO IDEIAS

Veja, a seguir, algumas dicas adicionais para a condução de entrevistas no momento da

elicitação de requisitos:
• Conquiste a confiança do entrevistado, apresente-se e explique, claramente, a finali-
dade do encontro.
• Tome notas durante a entrevista ou grave-a (se o entrevistado permitir).
• Se possível, utilize algum colega para a função de redator (liberando você para focar
na conversa com o entrevistado).
• Deixe para analisar as respostas, criticamente, depois (não corrija falhas, nem faça
críticas, nem discuta).
• Inicie com questões mais abertas, do tipo: “como é o trabalho que você realiza?”.
• Evite termos muito técnicos e tente se aproximar do jargão da área pesquisada.
• Evite perguntas com respostas apenas do tipo “sim” ou “não”. Tais perguntas costu-
mam 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 co-
legas em papel similar, ou, em último caso, do superior hierárquico 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.
Fonte: adaptado de Reinehr (2020)..

Brainstorming

O brainstorming é uma ferramenta poderosa na busca por ideias inspiradoras,

pois o foco é a quantidade de ideias expostas. É uma técnica grupal na qual são
realizados exercícios mentais com a finalidade de resolver problemas específicos,
ou seja, uma “tempestade de ideias”, sem julgamentos ou análises, em um am-
biente descontraído e informal. Quando uma sessão de brainstorming é bem-su-
cedida, o resultado é um conjunto de boas ideias, além do mais, os participantes
sentem que cada um contribuiu de alguma maneira.
Para a realização do brainstorming, é necessário preparar alguns materiais:
notas adesivas coloridas (post-it), canetas coloridas, um quadro branco ou uma
parede. A sessão é composta por três fases: (i) aquecimento: é escolhida a dinâ-
mica a ser usada no grupo, (ii) ideação: ocorre a geração das ideias; (iii) encer-
ramento: acontece o agrupamento das ideias. Pode ocorrer, como última fase, a
análise ou a votação das melhores ideias.

94
 UNICESUMAR

A seguir, algumas regras na busca por soluções:

■ É permitido ter ideias (muitas ideias, uma chuva delas).
■ Não é permitido julgar ou criticar as ideias dos participantes.
■ Ambiente não é avaliativo.
■ Tem como base a descontração, o enriquecimento da ideia do vizinho
(evitar discussões de ideias).
■ Deve ser definido o papel do condutor e do escriba (quem anota cada
ideia em um quadro ou em forma de notas).

Além disso, um brainstorming deve ter como métodos: (i) a divulgação clara dos
objetivos; (ii) a geração de ideias deve ser entre 20 a 60 minutos; (iii) um intervalo
para relaxamento; (iv) um estudo detalhado de cada ideia.
A seguir, a Figura 4 mostra a técnica brainstorming, inclusive as suas vanta-
gens, dificuldades e aplicações.

95
 UNIDADE 3

Os participantes expõe suas ideias

Estimula o pensamento criativo

Vantagens
Os participantes se sentem valorizados

Modificação ou combinação de ideias

Alguns do grupo podem não querer participar (tímidos)

Brainstorming Dificuldades Garantir a igualdade de oportunidades em expor ideias

Participantes não se sentem a vontade em anexos ideais

Ideal para grupos participativos e ativos

Aplicação
Quando se quer em primeiro conhecimento

Figura 4 - A técnica brainstorming, as suas vantagens, dificuldades e aplicação / Fonte: a autora.

Descrição da Imagem: a ilustração apresenta um retângulo com o título “Brainstorming”. Esse retângulo
está ligado, por meio de três linhas, a três retângulos que apresentam, cada um, os seguintes textos:
“Vantagens”, “Dificuldades” e “Aplicação”. No retângulo “Vantagens”, estão os seguintes tópicos: “Os par-
ticipantes expõem suas ideias, “Estimula o pensamento criativo”, “Os participantes se sentem valorizados”
e “Modificação ou combinação de ideias”. No retângulo “Dificuldades”, é possível ler os seguintes tópicos:
“Alguns do grupo podem não querer participar (tímidos)”, “Garantir a igualdade de oportunidades em ex-
por ideias”, “Participantes não se sentem à vontade em expor ideias”. No retângulo “Aplicação”, estão os se-
guintes tópicos: “Ideal para grupos participativos e ativos” e “Quando se quer um primeiro conhecimento”.

Questionário

A técnica questionário — também conhecida como survey ou pesquisa de

opinião — é um conjunto de questões as quais devem ser respondidas pelos
stakeholders. O seu uso é indicado, por exemplo, quando há diversos grupos de
usuários em diversos locais do país.
Conforme Reinehr (2020), o objetivo do questionário é coletar informações
de fontes, informações que podem estar em grande volume e/ou distantes, fisi-
camente, mas que servirão de base para tratamentos estatísticos.

96
 UNICESUMAR

“
O questionário é composto por um conjunto de perguntas com
respostas objetivas ou abertas, dispostas em sequência lógica e pro-
gressiva. 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 rique-
za 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 (REINEHR, 2020, p. 66).

Existem vários tipos de questionários a serem utilizados, dentre eles:

■ Múltipla escolha.
■ Lista de verificação.
■ Questões com espaços em branco.

O questionário deve ser desenvolvido de forma a minimizar o tempo gasto

em sua resposta. A seguir, a Figura 5 mostra a técnica questionário, as suas
vantagens, dificuldades e aplicações.

97
 UNIDADE 3

Custos reduzidos

Vantagens Atinge uma quantidade enorme de pessoas

Liberdade aos participantes

Equívoco no significado das perguntas pelos entrevistados

Questionário Dificuldades

Muitas pessoas com opiniões distintas

Quando a distância é considerável

Aplicação
Quando se quer um primeiro conhecimento

Figura 5 - A técnica questionário, as suas vantagens, dificuldades e aplicação / Fonte: a autora.

Descrição da Imagem: a ilustração apresenta um retângulo com o título “Questionário”. Esse retângulo
está ligado, por meio de três linhas, a três retângulos que apresentam, cada um, os seguintes textos:
“Vantagens”, “Dificuldades” e “Aplicação”. No retângulo “Vantagens”, estão os seguintes tópicos: “Custos
reduzidos”, “Atinge uma quantidade enorme de pessoas” e “Liberdade aos participantes”. No retângulo
“Dificuldades”, é possível ler os seguintes tópicos: “Equívoco no significado das perguntas pelos entrevis-
tados” e “Muitas pessoas com opiniões distintas”. No retângulo “Aplicação”, estão os seguintes tópicos:
“quando a distância é considerável” e “Quando se quer um primeiro conhecimento”.

Para que o seu questionário de levantamento de requisitos tenha chances de

sucesso, fique atento(a) a algumas questões a serem verificadas, de acordo
com Reinehr (2020): (i) procure adicionar uma breve introdução que esclareça
os pontos principais; (ii) utilize uma linguagem clara e simples na elaboração das
perguntas; (iii) use frases concisas, sem prejudicar o entendimento da questão;
(iv) utilize termos que evitem a dupla interpretação; (v) dê preferência às ques-
tões objetivas e, facilmente, tabuladas, fornecendo conclusões objetivas sobre o
trabalho em andamento; (vi) procure revisar se as alternativas cobrem todas as
possibilidades as quais você deseja investigar; (vii) tente não deixar um espaço
muito grande para as respostas das questões abertas, de modo a evitar longos
discursos do respondente; (viii) faça perguntas encadeadas, visando a testar a
coerência das respostas, e perguntas complementares, a fim de esgotar o assunto.
A seguir, um exemplo questionário de levantamento de requisitos para um
sistema voltado ao controle de venda e compra de produtos.

98
 UNICESUMAR

1. Como é feito o controle do caixa?

2. Como é realizado o controle de estoque?

3. Como são realizados os pedidos de venda e como são monitorados?

4. Como é feito o pedido dos produtos que faltam no estoque? Quem

realiza a compra?

5. Como é realizado o cadastro dos produtos e quem emite a nota fiscal?

Quadro 3 - Exemplo de questionário para um sistema de controle de venda e compra de produtos

Fonte: a autora.

Além das questões que devem ser verificadas quando se aplica o questionário, há al-
guns passos direcionados à utilização da técnica de questionário (REINEHR, 2020):
1. Determinar os objetivos da pesquisa: é possível utilizar o questionário
para levantar as necessidades ou os problemas do sistema e entender as
“dores do usuário”, os quais podem servir de base ao planejamento dos
requisitos do sistema que está sendo desenvolvido. O questionário tem
a chance de ser usado, também, como um apoio na priorização dos re-
quisitos identificados.
2. Identificar o público-alvo da pesquisa: é necessário identificar os pos-
síveis usuários do sistema e, assim, não aplicar o questionário para o pú-
blico-alvo incorreto, resultando em perda de tempo e falta de alcance dos
objetivos do sistema a ser desenvolvido. O público-alvo pode ser consti-
tuído de usuários internos ou externos à empresa, portanto, as questões
precisam ser elaboradas em função do perfil desse público identificado.
3. Elaborar e revisar as questões da pesquisa: esta é considerada a etapa
mais complexa da técnica de questionário, pois é onde elaboramos as
questões que serão utilizadas e como as respostas serão tabuladas e in-
terpretadas. Se não forem bem elaboradas, há a chance de haver interpre-
tação incorreta por parte dos usuários, então, os resultados poderão ser
errados. Se o questionário for online, não haverá alguém para esclarecer

99
 UNIDADE 3

as dúvidas dos usuários. Caso o questionário seja complexo e/ou extenso,

os usuários não o responderão.
4. Estimar o tempo de preenchimento: ao elaborar os questionários, é
importante pensar no tempo de preenchimento, considerando, também,
o perfil do público-alvo.
5. Realizar teste-piloto do questionário: o objetivo, aqui, é avaliar se o
questionário está de acordo com o perfil e com os objetivos pretendidos
da pesquisa. É como realizar um teste de software para identificar erros no
sistema, no caso, erros e falhas no questionário a ser aplicado. Caso haja
erros, eles necessitam de correção antes de o questionário ser distribuído
ao público-alvo estipulado.
6. Distribuir o questionário: nesta etapa, é planejada a estratégia que será
usada para a distribuição do questionário. Por exemplo, distribui-lo no
formato online ou aplicá-lo presencialmente.
7. Analisar os resultados: etapa onde as informações coletadas nos ques-
tionários passam a ser interpretadas e analisadas, servindo de base ao
levantamento dos requisitos.

As questões devem ser elaboradas levando em consideração o perfil do públi-

co-alvo, então, a partir disso, será definida a forma mais adequada de aplicação.

EXPLORANDO IDEIAS

“A preparação do questionário envolve elaborar as questões, estimar o tempo de respos-

ta, simular previamente as análises e realizar um teste piloto. Esse teste piloto deve permi-
tir identificar se as pessoas conseguem compreender adequadamente o que está sendo
perguntado e se o tempo de preenchimento está compatível com o estimado”.
Fonte: Reinehr (2020, p. 66, grifos meus).

Oficinas

As oficinas procuram reunir os stakeholders para definir os requisitos do soft-

ware a ser desenvolvido ou melhorado. O objetivo principal das oficinas é co-
locar em ação o trabalho em equipe bem como promover a discussão entre os

100
 UNICESUMAR

envolvidos. Um facilitador acompanha e faz a mediação, pois as tomadas de

decisão são baseadas em processos bem-definidos, enquanto o objetivo é obter
um processo de negociação.
As abordagens possíveis de serem utilizadas em oficinas são:
■ JAD.
■ Histórias de usuário (user stories).

A JAD (Joint Application Design) é uma técnica chamada de Métodos de

Projeto Interativo, cuja função é extrair dos stakeholders informações de alta
qualidade, em curto espaço de tempo, por meio de reuniões de grupo realizadas
de forma estruturada e que buscam decisões por consenso.
A JAD permite utilizar a criatividade e as dinâmicas de grupo, as quais são
inerentes ao trabalho em equipe e mostram o ponto de vista dos usuários em re-
lação ao sistema. Podem ser aplicadas dinâmicas que apresentam os objetivos de
aplicações, tais como: geração de telas e projetos de relatórios aos participantes.
O quadro, a seguir, descreve os quatro princípios do método JAD.

101
 UNIDADE 3

Princípio Descrição

Facilita o entendimento do problema

e das necessidades das áreas envol-
Dinâmica de grupo vidas no projeto. Os participantes
compartilham ideias e exploram a
criatividade na criação da solução.

Usa técnicas visuais que facilitam a

comunicação e o entendimento, por
exemplo, utilizar, na sala de reunião,
painéis contendo referências e con-
Recursos visuais ceitos do projeto, indicadores mag-
néticos, protótipos e transparências
que servem para melhor comunicar
e validar ideias durante a definição
do projeto.

O método emprega análise top-

-down com atividades bem defini-
Processo organizado e racional das, a fim de atingir a definição de
objetivos, especificações e projetos
externos.

Cada sessão possui um documen-

to de saída padrão cujo objetivo é
registrar, formalmente, os resulta-
Documentação padrão
dos do processo, para que todos os
participantes entendam as decisões
tomadas.

Quadro 4 - Princípio do método JAD / Fonte: adaptado de Sommerville (2018).

Os benefícios do JAD são: (i) mais produtividade; (ii) mais qualidade; (iii) tra-
balho em equipe; (iv) custos mais baixos de desenvolvimento e manutenção.
A seguir, a Figura 6 mostra uma visão geral do processo de JAD.

102
 UNICESUMAR

Projeto Projeto
Visão Geral - JAD
Resultados
Dados sobre
revisados
o projeto

Preparação Sessão Revisão

Objetivos e Dados Resultados e
prévios Avaliações

Figura 6 - Visão geral do processo JAD / Fonte: a autora.

Descrição da Imagem: a ilustração apresenta dois retângulos com o título “Projeto”, um à esquerda da
imagem e outro, à direita, ambos ligados, por meio de setas, a três retângulos, os quais mostram, no
interior de cada um, respectivamente, as palavras: “Preparação”, “Sessão” e “Revisão”. Na seta que sai do
primeiro retângulo intitulado “Projeto”, está o texto “Dados sobre o projeto”, enquanto que, na seta que sai
do retângulo “Preparação”, está o texto “Objetivos e dados prévios”. A seta que sai do retângulo “Sessão”,
por sua vez, traz o texto “Resultados e avaliações” e, por último, a seta a qual sai do retângulo “Revisão”
traz o texto “Resultados revisados” e aponta para o segundo retângulo intitulado “Projeto”.

Outra abordagem empregada nas oficinas se chama histórias de usuário (user

stories), que são descrições feitas pelos clientes, como funções, as quais eles gos-
tariam que o sistema realizasse, ou seja, são como contos cujo ponto central está
nas necessidades do usuário. Em algumas literaturas, você encontrará o termo
“estórias de usuários”.
Essa técnica é usada nas metodologias ágeis, nas quais temos a seguinte per-
cepção: uma história de usuário é uma descrição curta, informal — feita por
meio de uma linguagem simples — daquilo que o usuário deseja ser realizado/
executado pelo sistema e que ele considere ter valor para o seu dia a dia. De
acordo com Reinehr (2020, p. 162):

“
Quando os métodos ágeis surgiram, no final da década de 1990,
trouxeram uma forma diferente de pensar tanto a organização do
time de desenvolvimento quanto a organização dos requisitos, que
passaram a ser tratados como histórias de usuário. O conceito de
história de usuário foi criado por Kent Beck, na metodologia ágil
XP (eXtreme Programming). A definição original de história do
usuário, dada por Kent Beck e Martin Fowler é: ‘A história é a uni-
dade de funcionalidade em um projeto XP. Nós demonstramos o

103
 UNIDADE 3

progresso entregando código integrado e testado, que implementa

uma história. Uma história deveria ser compreendida pelos clien-
tes, testável pelo desenvolvedor, de valor para o cliente e pequena o
suficiente para que os programadores possam construir uma meia
dúzia delas em uma iteração’.

Podemos pensar a história de usuário como um cenário de uso de um sistema

por um tipo específico de usuário. Essa técnica proporciona um entendimento
comum com o cliente a respeito do que ele almeja que seja desenvolvido. Para
Reinehr (2020, p. 162), “no caso do XP, a história é escrita pelo próprio cliente.
No caso do SCRUM, isso é feito pelo PO, que é quem representa os interesses
dos clientes e usuários”.
A história do usuário usa um cartão escrito ou notas adesivas, onde temos
a expressão ou a voz dessa história. Deve seguir um formato padronizado, com:
afirmações escritas em primeira pessoa, o papel (“Quem?”: tipo do usuário), a
ação específica (“O quê?”) e o resultado da ação ou o valor de negócio da história
(“Por que?”), conforme o modelo na Figura 7.

Nome da história

Quem? O quê?

Como <tipo do usuário>, eu quero <ação específica> de

modo que <resultado esperado/valor>

Por quê?

Figura 7 - Formato de um cartão de história de usuário / Fonte: adaptada de Reinehr (2020).

Descrição da Imagem: ilustração de um retângulo com cantos arredondados. O título dele é: “Nome
da história” e, no meio desse retângulo, está o seguinte texto: Como <tipo do usuário>, eu quero <ação
específica> de modo que <resultado esperado/valor>. Logo abaixo do título, do lado esquerdo da imagem,
há a pergunta “Quem?”, dela sai uma seta apontando para o texto <tipo de usuário>. Também embaixo
do título, mas do lado direito da imagem, vê-se a pergunta “O quê?” e dela sai uma seta que aponta para
o texto <ação específica>. No lado de baixo da imagem, há a pergunta “Por quê?”, dela sai uma seta
apontando em direção ao texto <resultado esperado/valor>.

104
 UNICESUMAR

EXPLORANDO IDEIAS

O papel (“Quem?”) representa quem se beneficiará. A atividade (“O quê?”) descreve o que
será a funcionalidade (ou seja, o Requisito Funcional). O resultado (“Por quê?”) ou valor
agregado, traduz a perspectiva da utilidade da funcionalidade no contexto de utilização,
em suma, qual é o seu valor de negócio. Representamos, portanto, três elementos: quem?
(papel), o quê? (atividade), para quê? (valor).

Como a menor unidade de trabalho em um ambiente agile, as histórias de usuá-

rios são uma ferramenta-chave no desenvolvimento incremental.
Segue um exemplo de história de usuário para a funcionalidade “consulta
de livros”:

Consulta de livros
O
Quem? qu
ê?

Como um vendedor responsável pelo setor de livros, eu

quero procurar por livros filtrando por nome, para que seja
possível verificar se o livro X está disponível para pronta
entrega
Por quê?
Figura 8 - Exemplo de uma história de usuário para a funcionalidade “consulta de livro”
Fonte: a autora.

Descrição da Imagem: ilustração de um retângulo com cantos arredondados. Nele, vê-se o título “Con-
sulta de livros” e, no centro, o texto: “Como um vendedor responsável pelo setor de livros, eu quero
procurar por livros filtrando por nome, para que seja possível verificar se o livro X está disponível para
pronta entrega”. Logo abaixo do título, à esquerda da imagem, está a pergunta “Quem?”, dela sai uma
seta que aponta para a palavra “vendedor”. Embaixo do título, à direita da imagem, está a pergunta “O
quê?”, dela sai uma seta que aponta para o texto “eu quero procurar por livros”. No lado de baixo da
imagem, há a pergunta “Por quê?”, a partir dela sai uma seta que aponta em direção ao texto “verificar
se o livro x está disponível”.

Foi criado por Bill Wake um acrônimo em inglês — I.N.V.E.S.T. — que fornece
algumas dicas para a realização adequada dessa atividade e a criação de boas
histórias de usuário (REINEHR, 2020).

105
 UNIDADE 3

Técnica INVEST

Independente Negociável Valiosa Estimável Small Testável

Figura 9 - Técnica INVEST / Fonte: adaptada de Reinehr (2020).

Descrição da Imagem: ilustração de um retângulo com o texto “Técnica INVEST” em seu interior. Ele está
ligado a outros seis retângulos, cada um apresentando os seguintes textos, da esquerda para a direita:
“Independente”, “Negociável, “Valiosa”, “Estimável”, “Small” e “Testável”.

Cada letra do acrônimo INVEST tem os seguintes significados:

I - Independente (independent): uma boa história de usuário deve ser indepen-

dente, ou seja, capaz de ser identificada, discutida, implementada e, até mesmo,
liberada para uso de forma autônoma em relação a outras histórias.

N - Negociável (negotiable): uma boa história de usuário deve ser negociável.

Isto significa que ela não é um contrato imutável, o usuário pode mudar de ideia
e a história poderá ser adaptada.

V - Valiosa (valuable): uma boa história de usuário deve agregar valor para o
cliente.

E - Estimável (estimable): uma boa história de usuário precisa ser estimável,

ou seja, fornecer uma estimativa da complexidade da história, para saber se ela
é compatível.

S - Pequena (small): uma boa história de usuário deve ter um tamanho suficiente
para caber em uma única funcionalidade.

T - Testável (testable): uma boa história de usuário deve ser testável, isto é, avaliá-
vel. Se não soubermos como a avaliar, ela não está pronta para ser implementada.
A seguir, alguns exemplos de histórias de usuário.

106
 UNICESUMAR

Exemplo 1

Consultar cliente pelo CNPJ:

“Sendo um vendedor, eu quero consultar os meus clientes pelo CNPJ, para

conseguir negociar com ele, estando melhor informado”.

Exemplo 2

Alterar os próprios horários:

“Como um usuário não administrativo, devo modificar os meus próprios horá-

rios, mas não os horários de outros usuários, para que não seja necessário abrir
um chamado, sempre que as minhas tarefas mudarem”.
Conforme Reinehr (2020, p. 171), a mensagem transmitida é: “que o usuário
deseja uma funcionalidade que resolva uma dor que ele sente. Para isso, você deve
lançar mão da ferramenta da engenharia de requisitos que seja mais adequada
àquele contexto”. Como vimos antes, podemos usar entrevistas, questionários,
histórias de usuários, entre outros. Qualquer técnica para levantamento de re-
quisitos é útil ao desenvolvimento de melhores produtos de software.

107
UNIDADE 3

Seleção da técnica de elicitação de requisitos

Depois de conhecermos algumas técnicas para a coleta de re-

quisitos, vem a pergunta: qual técnica selecionar? A resposta
é: depende de vários fatores — o tipo de software, o contexto em
que o projeto está sendo desenvolvido, as tecnologias e os recur-
sos disponíveis —. Talvez, em alguns casos, é possível conversar
com os responsáveis, então, coletar todas as informações, mas
há casos nos quais a lei determinará o que o sistema deverá fazer.
Segundo Reinehr (2020, p. 52): “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”. No início
da unidade, conversamos sobre os diferentes tipos de produtos
de software e que, com isso, temos diferentes tipos de requisitos.
Em função disso, temos diversas fontes de informação à coleta
dos requisitos.
A coleta é o ponto mais crítico da Engenharia de Requisitos,
pois não é, apenas, perguntar ao usuário o que ele deseja; coletar
requisitos é investigar, instigar, questionar, descobrir, explorar,
extrair o máximo de informação dos stakeholders. Lembrando
que os usuários, nem sempre, sabem explicar como desempe-
nham as suas tarefas, às vezes, nem querem prestar informações.
Desse modo, para haver engajamento nesta fase, é necessário
selecionar uma técnica de elicitação mais apropriada a cada si-
tuação específica.
Como selecionar a melhor técnica de elicitação de requisitos,
já que existem diversas técnicas disponíveis? Depende. Algumas
técnicas implicam a interação direta com os stakeholders, en-
quanto outras podem ser aplicadas a outros tipos de fontes de
informação. Mas, independentemente da técnica de elicitação de
requisitos selecionada para o tipo de software a ser desenvolvido,
algumas etapas de preparação são necessárias.
Portanto, a fim de entender o que queremos dizer, observe
o quadro, a seguir.

108
 UNICESUMAR

Ações/Etapas Descrição

Identificar os stakeholders que

Identificação das fontes de informa-
tenham competência para prestar a
ção
informação.

Buscar conhecer as terminologias e

os jargões da área de negócio que
Familiarização com o assunto
está sendo abordada bem como os
conceitos-chave do negócio.

Identificar os objetivos da elicitação e

Identificação dos objetivos
o nível de informação.

Elaborar um cronograma de ativida-

des necessárias, visando à divulga-
Elaboração do cronograma ção dos objetivos e das informações
logísticas (local, data, horário, mate-
riais necessários).

Identificar e documentar os possíveis

riscos envolvidos na elicitação de
Identificação dos riscos na elicitação
requisitos e as ações que serão ado-
tadas para os prevenir ou mitigar.

Quadro 5 - Ações para a seleção da técnica e ferramenta para a elicitação de requisitos

Fonte: adaptada de Reinehr (2020).

Quando coletamos requisitos, muitas vezes, deve-se usar mais de uma técnica
necessária ou apropriada para cada caso. As técnicas costumam ser combinadas
conforme as necessidades dos projetos.
A seguir, algumas dicas para aplicar a técnica mais adequada e, com
isso, obter os melhores resultados de seu uso na coleta dos requisitos.

109
 UNIDADE 3

Técnica Quando usar

Quando existem pessoas que têm

o conhecimento necessário sobre o
negócio e que estão disponíveis para
serem entrevistadas.
Quando queremos captar as in-
Entrevista
formações subjetivas (desabafos,
sentimentos, pontos de vista) úteis à
definição de requisitos do sistema.
Quando queremos identificar o fluxo
de trabalho e de documentos.

Quando o ambiente da empresa é

informal e propício para o desenvol-
vimento de atividades criativas.
Brainstorming Quando desejamos encontrar solu-
ções inovadoras e criativas.
Quando desejamos lançar novos
produtos no mercado.

Se não houver tempo suficiente para

entrevistar todas as pessoas relevan-
tes.
Se as informações puderem ser tra-
balhadas, adequadamente, para fins
Questionário estatísticos.
Se as pessoas estão situadas em
pontos geográficos muito distantes.
Se, com o objetivo de prestar in-
formações, houver necessidade de
consultar arquivos físicos.

Quadro 6 - Seleção das técnicas para elicitação de requisitos / Fonte: adaptada de Reinehr (2020).

As técnicas podem ser combinadas conforme as necessidades dos projetos. A

seleção da melhor técnica de elicitação de requisitos deve considerar as caracte-
rísticas dos projetos.

110
 UNICESUMAR

Olá! Agora, quero aproveitar para te convidar a ouvir o

nosso podcast. Falaremos a respeito de temas importantes
à nossa área. Acesse o nosso QRCode.

NOVAS DESCOBERTAS

Título: Engenharia de Requisitos

Autora: Sheila Reinehr
Editora: Grupo A
Sinopse: a Engenharia de Requisitos é um dos temas mais impor-
tantes aos interessados no desenvolvimento e na engenharia de software
como um todo. Possivelmente, nenhuma outra atividade do ciclo de vida
de desenvolvimento será capaz de afetar o resultado como a ausência ou a
negligência na adoção de conceitos, práticas e ferramentas da Engenharia
de Requisitos. Este livro aborda esta temática.

Com o intuito de concluir a nossa unidade, segue uma análise de um cenário de

negócio. Em negrito, estão as informações importantes:
A Dra. Polenza é uma pediatra e possui dois consultórios na cidade, cada
um está localizado em locais diferentes. Por este motivo, cada consultório tem
um horário diferente de atendimento. Maria trabalha nos dois consultórios
como secretária e, para realizar o agendamento de consultas, ela necessita
abrir as duas agendas, a fim de fazer a verificação. Para o cadastro dos pacien-
tes, Maria anota nome, endereço, telefone, data de nascimento, data da primeira
consulta, e-mail e se o paciente tem convênio. Caso ele tenha convênio, ela
anota qual é o plano de saúde.
A Dra. Polenzal tem horários diferenciados para cada consultório: no
consultório do centro da cidade, ela atende de segunda à sexta, das 8:00 às 12:00.
No consultório do Jardim Aclimação, atende na terça e na quarta, das 13:00 às

111
 UNIDADE 3

16:00. São permitidos três encaixes de consulta por dia e, caso o paciente
seja novo, Maria anota o nome e o telefone. Além disso, para cada consulta, é
necessário verificar se é uma consulta de revisão e se é necessário realizar a
entrega de exames. Caso seja uma consulta de revisão, a mesma não é cobrada.
A seguir, a lista de alguns requisitos coletados a partir do cenário de negócio
(cadastros, consultas/relatórios). O sistema deve ter:
■ Um cadastro de paciente/manter paciente.
■ Uma agenda de consultas/manter agenda.
■ Um cadastro de convênio/manter convênio/plano de saúde.

112
1. “Entre as dificuldades encontradas na fase de levantamento de requisitos estão: o
usuário principal do sistema não sabe o que quer que o sistema faça ou sabe e não
consegue transmitir para o analista; requisitos identificados, mas que não são rea-
listas e não identificam os requisitos similares informados por pessoas diferentes.
Um stakeholder errado afetará em perda de tempo e dinheiro para ambas as partes
envolvidas no desenvolvimento do sistema”.

Fonte: DEVMEDIA. Técnicas para levantamento de requisitos. [2022]. Disponível

em: https://www.devmedia.com.br/tecnicas-para-levantamento-de-requisitos/9151.
Acesso em: 17 jun. 2022.

Considerando o trecho apresentado, analise as alternativas, a seguir, a respeito dos

requisitos, e assinale a alternativa correta:

a) Podemos dizer que o levantamento de requisitos é uma atividade que relaciona

todos os desejos dos usuários em um sistema ao longo do seu desenvolvimento.
b) Durante a fase de levantamento de requisitos, se faz necessário realizar a tarefa
de priorizar qual requisito é mais importante e isso é feito junto com os stakehol-
ders.
c) Podemos dizer que a coleta de requisitos é um processo onde se faz a busca dos
requisitos no sistema já pronto.
d) No início do desenvolvimento, os requisitos devem ser verificados para desco-
brir se estão incompletos e consistentes, para que ocorra o desenvolvimento do
sistema.
e) Na fase de levantamento de requisitos, os engenheiros de requisitos devem de-
senvolver o código-fonte da aplicação, assim, o restante dos envolvidos entenderá
o que será executado.

2. Quando se fala na técnica entrevista, pode parecer que o processo de entrevistar

um usuário é uma questão simples e direta, afinal, ela é a técnica mais utilizada na
elicitação de requisitos, dado o fato que permite a ocorrência de reuniões e encon-
tros diários. Nessas reuniões, são debatidos necessidades, problemas, processos,
atividades e desejos para o desenvolvimento de um sistema.

Considerando o trecho apresentado, analise as afirmativas, a seguir, a respeito dos

problemas com a técnica de entrevista na elicitação de requisitos:

I - Entrevistar a pessoa errada no momento errado, perdendo tempo na coleta de

113
 requisitos.
II - Fazer perguntas erradas e obter respostas erradas.
III - O usuário não se sente à vontade, ou, mesmo, se colocar em posição antagônica
na entrevista, porque ele acha que o objetivo do novo sistema é tomar o seu
emprego.
IV - Os usuários e os analistas de sistemas têm vocabulários e experiências diferentes,
desse modo, é feita uma pergunta ao usuário sobre os requisitos do sistema,
porém ele não entende a pergunta.
É correto o que se afirma em:

a) I, apenas.
a) II, apenas.
b) I e III, apenas.
c) I, III e IV, apenas.
d) I, II, III e IV.

3. A técnica de coleta de requisitos conhecida como brainstorming significa “tempesta-

de cerebral” ou “tempestade de ideias”. De acordo com o dicionário de significados
(DICIO, [2022], on-line), é uma expressão inglesa formada pela junção das palavras
brain, que significa “cérebro”, “intelecto”, e storm, que significa “tempestade”. É, ba-
sicamente, uma dinâmica de grupo cujo objetivo é desenvolver novas ideias para
solucionar problemas.

Pensando no conceito apresentado, analise as alternativas, a seguir, a respeito do

brainstorming, e assinale a correta:

a) Durante um brainstorming, é necessário realizar uma moderação para filtrar as

ideias que o cliente, talvez, não concorde.
b) Durante a realização de um brainstorming, é opcional que os integrantes enten-
dam o seu objetivo, pois, durante esta técnica, os integrantes o compreenderão.
c) Durante a realização de um brainstorming, é necessário garantir que os seus
integrantes tenham a mesma oportunidade de expor as ideias.
d) Durante a realização de um brainstorming, as críticas construtivas devem ser
aplicadas a todos os integrantes, visando a garantir boas ideias e a evitar tumultos.
e) A técnica de brainstorming deve ser aplicada, somente, quando o analista/enge-
nheiro de requisitos está sem ideias para realizar a coleta de requisitos

114
4
Especificação
de Requisitos de
Software
Esp. Janaína Aparecida de Freitas

Caro(a) estudante, após ter aprendido sobre as fontes de informação

que são usadas para o levantamento dos requisitos de software, as
técnicas de elicitação e como selecionar essas técnicas, chegamos à
especificação desses requisitos. Nesta unidade, aprenderemos como
realizar uma especificação de Requisitos Funcionais, por meio da utili-
zação de casos de uso e histórias de usuário. Também veremos como
realizar a especificação de requisitos em um cenário de negócios, em
seguida, conheceremos alguns indicadores para avaliar os requisitos
e os critérios de qualidade.
UNIDADE 4

Na unidade anterior, falamos sobre as técnicas para coletar

os requisitos, de forma a compreender as reais necessidades
do cliente e entender as informações transmitidas por ele.
No início da nossa jornada de estudos, falamos de Requi-
sitos Funcionais, lembra? Eles dizem respeito à definição
das funções que um sistema ou um componente de sistema
deve fazer (entradas e saídas) bem como se referem a uma
requisição, por parte do cliente, de uma funcionalidade que
o software deverá atender ou realizar. Ou seja, a exigência, a
solicitação, o desejo, a necessidade do cliente a serem mate-
rializados pelo software a ser desenvolvido.
Agora, pense: temos diversas formas ou recursos para ex-
pressar ou modelar os Requisitos Funcionais em um projeto.
Alguns já foram citados — linguagem natural, desenhos, dia-
gramas, cartões (histórias de usuários) e outros — portanto,
qual forma ou recurso usar? Independentemente do meio
utilizado, o mais importante é a comunicação entre o cliente
e a equipe que desenvolverá o software.
Como saber qual forma usar? Esta decisão dependerá
do contexto do sistema a ser desenvolvido. Qualquer forma
pode ser usada para qualquer metodologia de desenvolvi-
mento adotada? Independentemente de a metodologia de
desenvolvimento ser ágil ou tradicional, os requisitos serão
fundamentais para qualquer projeto ter sucesso.
Para você entender, contarei a história do Pedro. Ele aca-
bou de entrar em uma empresa de desenvolvimento de soft-
ware, e o seu novo gestor passou um diagrama de caso de uso,
em seguida, pediu para ele familiariza-se com o diagrama,
ou seja, estudá-lo, a fim de que vocês pudessem conversar a
respeito, no final da manhã. Pedro não conhece os detalhes
deste software, mas, analisando o diagrama de casos de uso,
ele conseguiu, rapidamente, identificar quem são os atores
integrantes do contexto do projeto e, também, quais são as
principais funcionalidades apresentadas no diagrama.

118
 UNIDADE 4

Agora, imagine que você é o Pedro: acabou de entrar em uma empresa de

desenvolvimento de software, e o seu novo gestor passou um diagrama de caso
de uso, em seguida, pediu que se familiarizasse com o diagrama, pois ele, o gestor,
conversará, depois, com você.

Realizar
login

Adicionar livro
ao carrinho

Cliente

Visualizar
include carrinho

Concluir
pedido

Figura 1 - Diagrama de casos de uso / Fonte: a autora.

Descrição da imagem: a ilustração mostra um homem-palito, à esquerda da imagem, acompanhado pelo

texto “Cliente. Esse homem é conectado por uma linha com quatro elipses que representam os casos de uso.
Cada elipse traz, em seu interior, respectivamente, os textos “Realizar login”, “Adicionar livro ao carrinho” e
“Visualizar carrinho”, a qual contém uma linha pontilhada com uma seta na ponta e um rótulo com o texto
“<include>” ligado ao caso de uso, com o texto “Concluir pedido”.

119
UNIDADE 4

Agora, registre, em seu Diário de Bordo, se você conseguiu identificar quais

são os atores que fazem parte do contexto e quais as funcionalidades envolvidas
apresentadas no diagrama de casos de uso. Será que estão faltando informações
no diagrama? A partir desta representação, podemos pensar em regras de funcio-
namento para o sistema? O que mais podemos identificar a partir do diagrama?
Procure anotar as questões as quais você poderá esclarecer com o seu gestor,
quando vocês se reunirem. Você consegue!

DIÁRIO DE BORDO

120
 UNIDADE 4

Especificação de Requisitos Funcionais Utilizando Casos de Uso

Aprendemos que o processo de coleta dos requisitos tem, como objetivos prin-
cipais, definir e documentar as características dos produtos e serviços do projeto
que satisfarão as necessidades e as expectativas dos usuários do sistema. Para tan-
to, os engenheiros de software têm várias formas ou recursos disponíveis, a fim de
expressar ou modelar, em um projeto, os Requisitos Funcionais. Alguns já foram
citados: linguagem natural, desenhos, diagramas, cartões (histórias de usuários)
e outros. Neste tópico, estudaremos como especificar Requisitos Funcionais, por
meio da utilização dos casos de uso.
Empregar casos de uso significa que queremos colocar o usuário no cen-
tro do processo de coleta de requisitos, visando a definir funcionalidades que
agreguem valor a esse usuário.
Na especificação de Requisitos Funcionais, por meio da utilização de casos
de uso, temos duas etapas: (i) na primeira, está construção do diagrama de casos
de uso; (ii) na segunda etapa, está a especificação dos requisitos que acompa-
nham o diagrama de caso de uso.
O diagrama de caso de uso faz parte da UML®, ele é usado para auxiliar na
elicitação de requisitos, pois facilita a compreensão de alguns deles, afinal, é
considerado um dos diagramas da UML® mais abstrato, flexível e informal. O
seu objetivo é modelar as funcionalidades e os serviços oferecidos pelo sistema.
Em relação ao aprendizado de como especificar, satisfatoriamente, um requisito
utilizando o diagrama de caso de uso, você terá disciplinas específicas para isso.
O objetivo desta unidade é apresentar a utilização do caso de uso como uma
técnica voltada à especificação de requisitos.

121
UNIDADE 4

Então, começaremos a falar acerca do caso de uso. Ele descreve uma fun-
cionalidade proposta para o sistema a ser desenvolvido ao mostrar como será
a interação do usuário, isto é, refere-se aos serviços, tarefas ou funções que
podem ser utilizadas, de alguma maneira, pelos usuários do sistema. Os casos
de uso devem representar uma única funcionalidade, e os usuários do sistema
são representados por atores (homens-palito). Os atores são qualquer elemento
externo que interaja com o sistema.

Figura 2 - Atores / Fonte: a autora.

Descrição da imagem: a ilustra-

ção mostra dois homens-palito,
cada um identificado pelos res-
pectivos textos: “Cliente” e “Caixa
eletrônico”.

Cliente Caixa
Eletrônico

Os casos de uso são representados na forma de elipses cujo texto interno descreve
a qual serviço/tarefa/função o caso de uso se refere. O texto interno deve ser da
seguinte forma:

Nome = verbo + substantivo (indicação de ação).

Comprar
Abrir Conta Efetuar Login
Produtos

Figura 3 - Casos de uso / Fonte: a autora.

Descrição da imagem: a ilustração mostra três elipses que representam os casos de uso, com os respectivos
textos no interior de cada uma delas: “Abrir conta”, “Comprar produtos” e “Efetuar login”.

122
 UNIDADE 4

Para entender melhor, veja, a seguir, um exemplo de um diagrama de caso de uso

cuja função é “comprar produtos”:

Caso de uso: comprar produtos.

Atores: cliente e atendente.

Comprar Produtos

Atendente Cliente

Figura 4 - Exemplo de diagrama de casos de uso “comprar produtos” / Fonte: a autora.

Descrição da imagem: a ilustração mostra dois homens-palito, cada um no extremo oposto da imagem. Á
esquerda, o homem-palito é identificado pela palavra “Atendente” e conectado, por uma linha reta e uma
elipse, ao homem-palito à direita da imagem, identificado pela palavra “Cliente”. Essa elipse apresenta, em
seu interior, o texto “Comprar produtos”.

Observando a Figura 4, é possível perceber as principais funcionalidades do siste-

ma, que é mostrar como ocorre a compra de produtos, além de levantar algumas
dúvidas as quais precisam, ainda, ser esclarecidas, mesmo que você não tenha
participado da elicitação de requisitos desse software.
Temos um cliente que chega ao ponto de vendas para comprar produtos. O
atendente registra a compra e coleta o pagamento, então, o cliente vai embora com
a compra efetuada. Por meio desta descrição, observamos que o diagrama de casos
de uso “comprar produtos” é simples e carrega considerável poder de comunicação.

123
UNIDADE 4

EXPLORANDO IDEIAS

“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 alinha-
dos. Se um for alterado, é necessário analisar se o outro também não sofrerá modificações”.
Fonte: Reinehr (2020, p. 139).

Uma especificação de casos de uso, segundo Reinehr (2020, p.

139), 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 desenvolvimento tenha mais subsídios para validar
e seguir para a implementação”.
Você deve estar pensando como se inicia a especificação de
casos de uso. Lembra que foi falado, antes, que, na especificação
de Requisitos Funcionais, utilizamos duas etapas? Então, aca-
bamos de ver o diagrama de casos de uso, agora, vamos para a
segunda etapa, onde temos a especificação dos requisitos que
acompanham o diagrama.
Na Unidade 2, aprendemos sobre o documento de requisi-
tos e, também, sobre o template padrão para a especificação dos
requisitos do sistema adotado na disciplina, está lembrado(a)?
Portanto, para a especificação dos casos de uso, também utiliza-
remos um template padrão similar, no entanto com mais níveis
de detalhes. Lembrando que cada empresa tem a liberdade de
optar por outros modelos e customizá-los conforme as suas
necessidades, incluindo mais ou menos detalhes, de acordo
com o seu processo de desenvolvimento. O importante é que
o documento de requisitos tenha utilidade aos membros da
equipe e que seja de fácil entendimento por todos.

124
 UNIDADE 4

Quadro 1 - Especificação do caso de uso UC3 – Realizar compra – Fluxo principal

Identificador único do caso de uso UC3 – Realizar compra.

Permite ao comprador realizar a com-

Descrição
pra de um produto.

Atores principais Comprador Logado.

Atores secundários x

O caso de uso UC1 – Realizar login ter

Pré-condição sido executado com sucesso e o com-
prador estar logado.

Comprador Logado seleciona “Realizar

Gatilho
compra”.

Fluxo principal

Ações do ator Ações do sistema

1 – Sistema exibe categorias de produ-

tos.

2 – Comprador Logado seleciona categoria

de produto.
3 – Sistema executa UC2 – Pesquisar
Produtos.

4 – Comprador Logado seleciona produto.

5 – Sistema solicita quantidade.

6 – Comprador Logado informa a quanti-

dade.

7 – Sistema exibe opções de entrega.

8 – Comprador Logado seleciona opção de

entrega.

9 – Sistema executa UC4 – Realizar

Pagamento.

125
UNIDADE 4

Fluxo alternativo

Ações do ator Ações do sistema

A8.1 – Comprador Logado seleciona Alte-

rar Endereço.
A8.1 – Comprador Logado seleciona
Alterar Endereço.

A8.3-Comprador Logado preenche novo

endereço.
A8.3-Comprador Logado preenche
novo endereço.

Fluxo de exceção

Ações do ator Ações do sistema

E4.2 - Comprador Logado confirma que E6.1 - Sistema exibe mensagem “Quan-
quer voltar para seleção de produtos. tidade indisponível. Quer reduzir a
quantidade?”.

E5.3 - Sistema retorna para a seleção

da quantidade.

Pós-condição Não se aplica.

Quadro 1 - Modelo de especificação de casos de uso / Fonte: Reinehr (2020, p. 146).

A seguir, a descrição dos elementos envolvidos no template de especificação de

casos de uso, seguindo o modelo proposto por Reinehr (2020):
■ Identificador único do caso de uso: refere-se ao nome do caso de uso,
onde se utiliza um verbo no infinitivo que caracteriza a ação que será
realizada. Ele é útil na rastreabilidade do requisito.
■ Descrição: campo usado para apresentar uma visão resumida do objetivo
do caso de uso.
■ Ator principal: campo usado para descrever aquele que inicia o caso de
uso.

126
 UNIDADE 4

■ Atores secundários: campo usado para descrever aqueles que

participam na execução do caso de uso ou que fornecem infor-
mações para que o caso de uso possa ser realizado, o qual nem
sempre terá atores secundários.
■ Pré-condição: campo que descreve a condição que deve ser ver-
dadeira para o caso de uso ter início. A pré-condição não é testa-
da quando o caso de uso inicia, ele só inicia se ela for verdadeira.
■ Pós-condição: é o status no qual o sistema deve ser deixado
quando for encerrada a execução do caso de uso.
■ Gatilho: evento que dá início ao caso de uso, ou seja, quando
o caso de uso é chamado por um ator, o gatilho é a chamada
feita por esse ator.
■ Fluxo principal: campo que se refere ao cenário mais comum
do caso de uso, considerando que tudo está certo. Conhecido
como o “caminho feliz”, ele é mapeado como uma conversa en-
tre o que o ator (ação do ator) faz e o que o sistema (ação do
sistema) responde.
■ Fluxos alternativos: são as possibilidades de cenários alternati-
vos ao fluxo principal, conforme escolhas do usuário ou situações
específicas do sistema.
■ Fluxos de exceção: demonstram como o sistema reagirá na
presença de situações inesperadas. Os fluxos de exceção po-
dem ocorrer dentro do fluxo principal ou dentro de um fluxo
alternativo.

Nem todos os elementos dos envolvidos no template serão preenchi-

dos, pois isso depende do contexto do sistema que está sendo mo-
delado. Os diagramas de casos de uso são considerados ferramentas
complementares que podem ser utilizadas em uma variedade ampla
de situações, dentre elas, a de especificação de requisitos. Os casos de
uso se aplicam a pequenos projetos e a projetos de grande porte ou que
tenham mais complexidade e, como aprendemos, são úteis em projetos
envolvendo interação expressiva entre os usuários e o sistema.

127
UNIDADE 4

EXPLORANDO IDEIAS

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, Delete). A resposta é: não existe uma
forma padrão! Há os que defendem que essas operações estejam agrupadas em 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 tan-
to o diagrama quanto as especificações ficam mais simples. Essa é a forma normalmente
adotada na prática”.
Fonte: Reinehr (2020, p. 151).

128
 UNIDADE 4

Especificação de Requisitos Funcionais utilizando histórias de

usuário

Outra forma ou recurso para expressar ou modelar os Requisitos Funcionais em

um projeto de software são as histórias de usuários. Na unidade anterior, aprende-
mos que as histórias de usuário (user stories) são descrições feitas pelos clientes
— como funções — as quais os clientes gostariam que o sistema realizasse. Tais
histórias são como contos e o ponto central das user stories está nas necessidades
do usuário. De acordo com Reinehr (2020, p. 155) “Independentemente da forma
que se escolha para realizar as atividades relacionadas a requisitos, um ponto é
chave: o foco na entrega de valor para o cliente”. Uma frase muito utilizada em
equipes de desenvolvimento que utilizam metodologias ágeis é: se não houver
valor na entrega ao cliente, ela não deve ser realizada.
As equipes ágeis usam as histórias de usuário para a elicitação de requisitos.
Neste tópico, identificaremos os elementos que compõem uma história de usuário
e como as aplicaremos na especificação de Requisitos Funcionais.
Depois de compreender e detalhar as histórias de usuário, a equipe de de-
senvolvimento estima o que será realizado para compor o seu planejamento da
sprint. O backlog da sprint contém os itens que foram estimados para a sprint
e o seu planejamento.

“
O princípio básico do Scrum é de que o desenvolvimento de software
deve ser dividido em entregas menores, de uma a quatro semanas, de-
nominadas sprints. O desenvolvimento é todo organizado em torno
das sprints. Ao final de uma sprint, é gerado um item potencialmente
entregável para o cliente. O backlog é o repositório de todas as requi-
sições dos clientes e é gerenciado pelo Product Owner (PO, ou dono
do produto). É o PO quem prioriza o conteúdo do backlog que será
alocado à sprint. Só pode ser alocado à sprint um item do backlog
que já esteja em um nível de detalhe suficiente para que a equipe pos-
sa implementar. Um item de backlog geralmente é uma história de
usuário, mas pode ser qualquer solicitação do cliente. Quem planeja
a sprint é a equipe, estimando os itens do backlog e discutindo suas
dificuldades para implementar (REINEHR, 2020, p. 155).

129
UNIDADE 4

É possível dizer que uma história do usuário é um cenário de uso de um software

por um usuário específico e que registra a comunicação com o cliente, a fim de
chegar a um entendimento comum do que será desenvolvido. Quando usamos
histórias de usuário, temos os 3Cs: Cartão, Conversa e Confirmação.
O Cartão (Card) foi adotado para as histórias de usuário porque as empresa
passaram a adotar um formato padronizado no qual, conforme Reinehr (2020, p.
163), temos as “afirmações escritas em primeira pessoa, contendo o papel (quem),
a ação (o que) e o resultado da ação ou o valor de negócio da história (porque)”,
conforme ilustrado na Figura 5.

Nome da história

Quem O quê
Como <tipo do usuário>, eu quero <ação específica> de
modo que <resultado esperado/valor agregado>
Porque

Figura 5 - Formato de uma história de usuário / Fonte: Reinehr (2020, p. 163).

A identificação dos elementos da história do usuário no Cartão são:

■ Quem: representa quem se beneficiará com a funcionalidade, ou seja, o
tipo de usuário e não quem está solicitando a funcionalidade.
■ O que: representa a descrição da funcionalidade, ou seja, o requisito
funcional do sistema.
■ Porque: é o resultado ou o valor agregado à funcionalidade, o que será
entregue ao cliente.

O elemento da história do usuário mais importante a se preocupar é com o quem:

os usuários e os clientes que utilizarão a funcionalidade. Depois, a preocupação
é entender o que deve ser desenvolvido.

130
 UNIDADE 4

A Conversa (Conversation) é o ponto de partida para que os requisitos sejam

coletados e muito bem compreendidos. A comunicação com o cliente é o princí-
pio fundamental da Engenharia de Requisitos e, na conversa, há a possibilidade
de utilizar as técnicas de elicitação de requisitos aprendidas na unidade anterior.
Na Confirmação (Confirmation), temos os critérios de aceitação que ajudam
a esclarecer como será validada a história do usuário. Alguns chamam esses cri-
térios de testes de aceitação da história. A fim de entender, veremos um exemplo
de história de usuário aplicado um sistema de check-in de uma companhia aérea:

Como PASSAGEIRO, eu quero FAZER MEU CHECK-IN VIA CELULAR, para não
perder tempo na fila do aeroporto.

Os CRITÉRIOS DE ACEITAÇÃO seriam:

■ Apresentar os assentos para seleção, destacando os assentos vazios.

■ Destacar os assentos especiais, permitindo compra na hora do check-in.
■ Apresentar a possibilidade de compra de bagagem extra no momento do
check-in.

Quadro 2 - Exemplo de história de usuário para um sistema de check-in de uma companhia aérea
Fonte: Reinehr (2020, p. 166).

O maior esforço das equipes de desenvolvimento, quando coletam os Requisitos

Funcionais dos sistemas, é compreender as histórias de usuário, ou seja, manter
uma boa conversa e escrever os critérios de aceitação visando que elas sejam
testadas e aceitas, posteriormente. Mas como construir boas histórias de usuário?
A seguir, veremos alguns itens a serem utilizados na hora de desta construção.

131
UNIDADE 4

Delimite para quem o software está sendo de-

Delimite o problema
senvolvido e por que está sendo desenvolvido.

Procure fazer um mapa que mapeie o mundo

Mapeie a visão geral
com as dores e alegrias do usuário.

Procure aprofundar-se, entendendo como as

Explore
outras pessoas fazem a mesma coisa.

Gere uma estratégia de Procure, sempre, pesquisar, antes, para construir

entrega e priorize o que agrega mais valor.

Gere uma estratégia de Procure construir o produto mínimo viável e,

aprendizagem para aprender, teste com o público-alvo.

Procure dividir o que deverá ser desenvolvido

Gere uma estratégia de
agora e depois. Desenvolva, primeiro, o que
desenvolvimento
oferece mais riscos.

Quadro 3 - Itens para construir uma história de usuário / Fonte: adaptado de Reinehr (2020).

Podemos dizer que as histórias de usuários são diferentes de outras aborda-

gens para a coleta de requisitos por que: (i) não detalham as especificações
de requisitos, mas, por outro lado, são expressões de intenção negociáveis; (ii)
são curtas, fáceis de ler e compreensíveis por stakeholders, desenvolvedores e
usuários; (iii) representam pequenos incrementos de funcionalidade de valor;
(iv) são, relativamente, fáceis de estimar; (v) são escritas e organizadas em listas
passíveis de serem arrumadas mais facilmente, à medida que novas informações
são descobertas; (vi) não são detalhadas no início do projeto, mas elaboradas à
medida que são necessárias (just-in-time); (vii) requerem pouca ou nenhuma
manutenção e podem ser, facilmente, descartadas, depois de implementadas;
(viii) o código que é criado, rapidamente, a partir delas, serve como entradas à
documentação, a qual é, então, desenvolvida, incrementalmente, também.

132
 UNIDADE 4

Você, talvez, esteja pensando em qual usar: casos de uso ou histórias do usuá-
rio? As duas formas são excelentes para coletar requisitos funcionais de software,
o que devemos ter em mente é o fato de o usuário desejar uma funcionalidade
que resolva a dor dele. As duas formas ajudam a apoiar o diálogo à compreensão
dos requisitos e, com isso, a desenvolver um software de sucesso.

Especificação de requisitos para um cenário de negócios

Aprendemos várias técnicas e formas de coletar requisitos e, neste tópico, anali-

saremos um cenário de negócios para compreender o contexto de um projeto e
identificar as fontes de informação que podemos usar. Depois, selecionaremos
quais as melhores formas e técnicas à especificação de requisitos em um cenário
de aplicação.
Aprendemos, nas unidades anteriores que, na Engenharia de Requisitos, te-
mos as atividades de elicitação, análise, especificação e validação de requisitos.
A fim de iniciarmos essas atividades, primeiro, precisamos compreender qual o
cenário de negócio e identificar as possíveis fontes de informação à coleta dos
requisitos. Então, para entendermos, nos basearemos em um exemplo fictício
prático, proposto por Reinehr (2020):

133
UNIDADE 4

Descrição do cenário de negócios: desenvolveremos um aplicativo direcionado

apoiar as atividades do Detran (Departamento de Trânsito). O aplicativo inter-
ligará os diversos atores envolvidos neste ecossistema, conforme ilustra a Figura
6. Os atores são os seguintes: o próprio Detran, o motorista, o proprietário, o
agente de trânsito, os bancos e as clínicas médicas. Entende-se por “proprietário”
o dono de um veículo automotor e, em determinado momento, pode ser, também,
o motorista do veículo.

DETRAN
INTELIGENTE

Figura 6 - Contexto do aplicativo Detran Inteligente / Fonte: Reinehr (2020, p. 304).

Descrição da imagem: a ilustração mostra o contexto do aplicativo Detran Inteligente. É possível ver um
retângulo com cantos arredondados simulando um aparelho celular, no monitor, aparece o texto “Detran
Inteligente’’. Ligado a esse aparelho, há seis círculos com ícones que representam as funções do aplicativo,
esses círculos estão inseridos em retângulos. No primeiro retângulo, está o texto “Detran”, no segundo,
o texto “Agente de trânsito”, no terceiro, o texto “Banco”, enquanto que no quarto retângulo está o texto
“Motorista”. No quinto, vê-se o texto “Proprietário” e, no sexto e último retângulo, o texto “Clínica Médica”.

Agora, imagine que você é o(a) engenheiro(a) de requisitos que coletará as infor-
mações para o desenvolvimento deste aplicativo fictício ao Detran da sua cidade.
O seu objetivo é coletar os requisitos especificados em um nível de detalhe sufi-
ciente para que a equipe de desenvolvimento consiga implementar o aplicativo.

134
 UNIDADE 4

Como você iniciará o seu trabalho? A primeira atividade, conforme vimos

nas unidades anteriores, é tentar compreender o contexto do problema que será
resolvido pelo desenvolvimento do novo aplicativo. É importante identificar as
possíveis fontes dessas informações, por exemplo, gestores e principais usuários,
pois é neste momento que surgem situações, tais como: resistências dos envol-
vidos, questões de ordem política dentro da empresa etc. Colete todas as infor-
mações e as organize com o objetivo de as explorar, depois, junto aos usuários,
clientes e à sua equipe de desenvolvimento.
Outra atividade importante é a pesquisa acerca do negócio, a fim de co-
nhecer mais sobre ele e dar início ao contato com os envolvidos. Nesta etapa,
é importante compreender as terminologias usadas no negócio, as regulamen-
tações e regras do setor. Assim, desde as primeiras conversas com os usuá-
rios, será possível aprofundar as especificações dos requisitos com o cliente.

PENSANDO JUNTOS

“Quando um analista de requisitos chega bem preparado para a primei-

ra reunião, demonstrando que ‘fez a tarefa de casa’, ele já passa para o clien-
te uma boa impressão e a confiança de que eles têm um parceiro de traba-
lho. Invista tempo se preparando. Essa tarefa simples ajuda também a vencer
resistências que possam, eventualmente, haver por parte de alguns dos clientes”.
(Sheila Reinehr)

135
UNIDADE 4

Quando você pesquisar o contexto do problema a ser resolvido, é importante

pensar em alguns itens, conforme mostra o Quadro 4.

Itens de pesquisas Descrição

No exemplo, procurar pelos websites

Informações sobre o negócio a
dos diversos Detrans do país para com-
que se refere o sistema
preender o funcionamento deles.

No exemplo, você pode procurar por

Dados sobre sistemas similares sistemas para apoiar os Detrans e apli-
disponíveis cativos para apoiar motoristas e proprie-
tários de veículos automotores.

No exemplo, é possível pesquisar as leis

Leis e regulamentações do de trânsito, as regras para tirar a cartei-
setor ra de habilitação, para emplacamento e
licenciamento de veículos, entre outros.

Pesquisar se existem inovações no setor

que estejam sendo implementadas no
Inovações no setor país ou no exterior e que contribuam
às especificações do sistema que está
sendo desenvolvido.

Quadro 4 - Itens de pesquisas sobre o contexto de negócio / Fonte: adaptado de Reinehr (2020).

Depois de realizar a pesquisa, devemos realizar o primeiro contato com o cliente,

visando a identificar as fontes de informação para a coleta de requisitos e os sta-
keholders do projeto. No exemplo fictício do Detran, é possível ter coordenadores
de equipe de infração, de equipe de emissão de carteira de habilitação, entre outros.
O próximo passo após a identificação das fontes de informações é a sele-
ção das técnicas de elicitação de requisitos. Aqui, devemos escolher a melhor
técnica ao contexto do projeto a ser desenvolvido e planejar como será a sua
aplicação junto aos interessados.
A Figura 7, a seguir, mostra as atividades do processo de elicitação de requisitos.

136
 UNIDADE 4

PREPARAÇÃO ORGANIZAÇÃO
IDENTIFICAÇÃO
DAS FONTES DE DA ELICITAÇÃO
... DOS
...
INFORMAÇÃO ... DE RECURSOS ...
... ... ... REQUISITOS

..
... ...

..

...
...

...
.. ... ...

...
COMPREENSÃO .....

...
SELEÇÃO DAS ... REALIZAÇÃO DA

. ..
...

...
ELICITAÇÃO DE

...
DO CONTEXTO TÉCNICAS DE

...
...
ELICITAÇÃO REQUISITOS

Entrevista
Reunião
Observação
Questionário
JAD
...

Figura 7 - Atividades do processo de elicitação de requisitos / Fonte: Reinehr (2020, p. 308).

Descrição da imagem: a ilustração mostra o processo de elicitação de requisitos. Há seis círculos que
representam cada atividade. No primeiro círculo, está a atividade “Compreensão do contexto” ligada, por
meio de uma seta, ao círculo com a atividade “Identificação das fontes de informação”. Esta, por sua vez, se
liga, por meio de uma seta, ao círculo com a atividade “Seleção das técnicas de elicitação” que está ligada a
um retângulo no qual, em seu interior, está o texto “Entrevista, reunião, observação, questionário, JAD…”.
O círculo “Seleção das técnicas de elicitação” liga-se, por uma seta, ao círculo com a atividade “Preparação
da elicitação de requisitos”, que está ligada, também, por meio de uma seta, ao círculo com a atividade
“Realização da elicitação de requisitos”. Esta encontra-se ligada, da mesma forma, ao círculo com a atividade
“Organização dos requisitos”.

Na garantia de sucesso do projeto de desenvolvimento de um sistema, a seleção

das técnicas é um passo importante, pois é com elas que coletamos os requisitos,
levando em consideração: (i) a disponibilidade das fontes de informação; (ii) o
tempo disponível para realizarmos a coleta de requisitos; (iii) o contexto do proje-
to que está sendo desenvolvido; (iv) o tipo de informação que precisa ser coletada.
De acordo com Reinehr (2020, p. 310), para “selecionar as técnicas mais apro-
priadas para a elicitação de requisitos, temos que olhar atentamente para as in-
formações que foram prestadas, além das características de cada técnica”.

137
UNIDADE 4

EXPLORANDO IDEIAS

Os artefatos produzidos como consequência do levantamento de requisitos variarão de-

pendendo do tamanho do sistema ou produto a ser construído. Na maioria dos sistemas,
dentre os artefatos, temos: (i) uma declaração da necessidade e viabilidade. Uma decla-
ração restrita do escopo para o sistema ou produto; (ii) uma lista de clientes, usuários e
outros interessados que participaram do levantamento de requisitos; (iii) uma descrição
do ambiente técnico do sistema; (iv) uma lista de requisitos (preferencialmente, organiza-
da por função) e as restrições de domínio que se aplicam a cada uma delas; (v) um con-
junto de cenários de uso que esclarecem o uso do sistema ou do produto sob diferentes
condições operacionais. Cada um desses artefatos é revisado por todas as pessoas que
participaram do levantamento de requisitos.
Fonte: adaptado de Pressman e Maxim (2021).

138
 UNIDADE 4

Indicadores para avaliar requisitos de software

Depois de realizarmos a coleta de requisitos, precisamos avaliar se chegamos ao

resultado esperado, isto é, ao que foi planejado. Como avaliamos? Comparando se
o que foi coletado é o que estava planejado. De acordo com Reinehr (2020, p. 208):

“
Medições também fazem parte da nossa vida profissional: quan-
to 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 imple-
mentar 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.

Você deve estar se perguntando: como avaliamos os requisitos de software? Como

garantimos que será entregue ao usuário o que coletamos e se é o que esse usuário
queria? Inicialmente, precisamos investir na elicitação de requisitos e, depois,
identificar se a equipe de desenvolvimento atendeu às necessidades dos usuários
de acordo com o planejado.

139
UNIDADE 4

Para começarmos, primeiro, entenderemos o que é medição. O termo “me-

dição” tem várias definições, como mostrado no quadro, a seguir:

Termo Descrição

Algoritmo ou cálculo realizado para combinar

Função de medição
duas ou mais medidas básicas.

Função de medição. Algoritmo ou cálculo rea-

Medição lizado para combinar duas ou mais medidas
básicas.

Variável à qual um valor é atribuído resultante

Medida
de uma medição.

Conjunto de operações, descrito, especifica-

Procedimento de mente, utilizado no desempenho de determi-
mediação nada medição, de acordo com determinado
método.

Resultado numérico ou categórico atribuído

Valor a uma medida básica, medida derivada ou
indicador.

Quadro 5 - Definição de termos para medição / Fonte: Reinehr (2020, p. 209).

A partir desses termos, relacionaremos os elementos envolvidos na medição.

Mas como usar? Pensaremos no seguinte: queremos identificar se um stakehol-
der está com a sua produtividade média compatível com a sua equipe de de-
senvolvimento. Para isso, precisamos:
■ Identificar o objeto (entidade) que deve ser medido e quais as suas ca-
racterísticas (atributos) que precisamos medir, a fim de atender às neces-
sidades do requisito. Pense no objeto como uma tarefa ou funcionalidade
a ser realizada e os atributos sendo o tamanho ou tempo para desenvolver.
■ Definir um método de medição para saber como obter o valor do atributo.
■ Usar uma função de medição visando a combinar as medidas. Pode-
mos considerar, por exemplo, que uma função de medição será a razão
entre a quantidade de pontos de uma história de usuário pelo tempo de
desenvolvimento dessa história.

140
 UNIDADE 4

■ Procedimento de medição com o intuito de analisar o que acabamos

de obter e definir um indicador que diga se a produtividade está abaixo,
na média ou acima do mercado.

No modelo de requisitos é onde formulamos e estabelecemos uma base ao

projeto a ser desenvolvido e, para definir um método de medição, o ideal é
estabelecer uma base usando o modelo de informação, a seguir (Figura 8).

Necessidades
Produto da informação
de informação

Interpretação

Indicador

Modelo de
análise

Medidas derivadas

Função de
medição

Medidas básicas Medidas básicas

Método de Método de
medição medição

Entidade Atributo Atributo

Figura 8 - Modelo de informação de medição Fonte: Reinehr (2020, p. 211).

Descrição de imagem: a ilustração é um esquema que representa o modelo de informação de medição.

De cima para baixo, o modelo segue as etapas: “Entidade: atributo, método de medição, medidas básicas,
função de medição, medidas derivadas, modelo de análise, indicador, interpretação”. Em seguida, “Neces-
sidades de informação: produto da informação”.

141
UNIDADE 4

Visando a explicar o modelo de informação de medição, usaremos o exemplo

dado por Reinehr (2020), no qual você deve supor que a necessidade de infor-
mação de um stakeholder seja identificar se a produtividade de sua equipe de
desenvolvimento está compatível com a produtividade média do mercado (in-
terpretação).
Como você atenderá a esta necessidade de informação?
Primeiro: identificar as entidades envolvidas e quais são os atributos (carac-
terísticas) a partir das entidades que você precisa medir para atender à necessidade
de informação. Pensando na sua necessidade, pode ser: a entidade é a tarefa realiza-
da, e os atributos são o tamanho da tarefa e o tempo necessário para a desenvolver.
Segundo: definir qual o método de medição envolvido para essa necessida-
de. Como exemplo: você precisa saber como obter o valor do atributo de tamanho
da tarefa e o valor do atributo do tempo. Então, precisamos saber qual técnica de
coleta de requisitos foi usada. No exemplo, suponha que você tenha usado uma
história de usuário e imagine que tenha utilizado pontos de história do usuário
(story points) com o objetivo de definir prioridades. Assim, para o atributo de
“tempo”, você assume o tempo decorrido do início até o final da história do usuá-
rio. A medida básica será: quantidade de pontos x tempo de desenvolvimento da
história. Temos a função de medição que será a forma como você pode combinar
as medidas básicas para gerar uma medida derivada, se necessário.
Terceiro: estabelecer o modelo de análise, que é a forma como são analisadas
as medidas básicas e derivadas obtidas.
Neste exemplo, é possível ter critérios de decisão, tais como:
■ Qual é o valor médio da produtividade no mercado para este tipo de
necessidade de informação?
■ Produtividade com a tecnologia usada?
■ E com outra produtividade usada no mercado? Dentre outras decisões
que você pode usar.

Esse modelo de análise tem a possibilidade de ser a base de interpretação da pro-

dutividade que foi obtida pela função de medição e pelo indicador, o qual é obtido
para dizer se a produtividade está ou abaixo ou na média ou acima do mercado.
Segundo Reinehr (2020, pg. 210) isso permite “realizar a interpretaçã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 compreende”.

142
 UNIDADE 4

EXPLORANDO IDEIAS

Com o intuito de tornar a avaliação de um produto de software mais efetiva, é importante

utilizar um modelo de qualidade que permita estabelecer e avaliar requisitos de qualida-
de. O processo de avaliação deve ser, também, bem definido e bem estruturado.
A norma NBR ISO/IEC 14598-1 fornece requisitos e recomendações para a implementação
prática da avaliação de produto de software. É uma norma utilizada por fornecedores e
compradores de software, laboratórios de avaliação de produtos de software, usuários
experientes e entidades certificadoras, sendo que cada um tem um objetivo específico.
O processo de avaliação proposto pela norma NBR ISO/IEC 14598-5 é semelhante ao da
parte 1, incluindo uma etapa a mais às etapas da avaliação, que são: (i) análise de requisi-
tos da avaliação; (ii) especificação da avaliação; (iii) projeto da avaliação; (iv) execução da
avaliação; (v) conclusão da avaliação.
A análise de requisitos procura definir os requisitos de qualidade do produto. Ela inicia a
partir dos objetivos definidos para a avaliação e que procuram traduzir, diretamente, o
interesse do requisitante.
Fonte: adaptado de Freitas (2021).

Olá! Agora, quero aproveitar a oportunidade e te convidar a

ouvir o nosso podcast. Nele, falaremos a respeito de temas
importantes da área. Acesse o nosso QRCode.

NOVAS DESCOBERTAS

Título: Engenharia de Software – Projetos e Processos

Autor: Wilson de Pádua Paula Filho
Editora: LTC
Sinopse: livro que abrange as atividades de especificação, por exem-
plo, requisitos e análise, e as atividades de solução, tais como o projeto, os
testes e a implementação do desenvolvimento do software.

143
UNIDADE 4

Funcionalidades de um sistema existem, somente, para realizar Requisitos Fun-

cionais. Logo, sem esses requisitos, não há funcionalidades e, sem funcionalida-
des, não há sistema. Por ser algo importante, os requisitos precisam ser bem feitos,
bem detalhados e com qualidade (SOMMERVILLE, 2018).
O que devemos entender como qualidade de um requisito? Um Requisito
Funcional de qualidade precisa atender a alguns atributos específicos, de acordo
com Sommerville (2018):
■ Unidade: o RF deve propor uma única coisa, apenas, ou seja, não deve
atender a mais de uma exigência. Exemplo: o RF “Incluir cliente”
não é unitário, pois há a possibilidade termos que incluir clientes de
tipos diferentes (pessoa física e jurídica), assumindo, assim, várias
responsabilidades.
■ Completude: o RF deve ser autocontido, ter “início/meio/fim”, ser comple-
to. Exemplo: o RF “Pagar fatura” não é completo, a não ser que seja “Pagar
fatura com cartão de crédito para cliente pessoa física”.
■ Não ambiguidade: um RF não pode ser ambíguo. Exemplo: o RF “Emitir
relatório” não diz nada (relatório de que, para quê?). “Emitir relatório de
saldo” diz, mas é, ainda, ruim (saldo de quê?). “Emitir relatório de saldo
da conta corrente do cliente pessoa física” é mais completo.
■ Tempo verbal: é o uso do tempo verbal no nome do RF. Este refere-se a
algo que será feito, uma ação a ser realizada pelo sistema. Exemplo: “Rea-
lizar compra de produto com pagamento em cartão de crédito”.

Considerando que um Requisito Funcional de qualidade precisa atender aos atri-

butos descritos, identifique os Requisitos Não Funcionais do cenário hipotético,
a seguir, e identifique um possível cenário negativo.
Imagine que você é o(a) engenheiro(a) de requisitos responsável pelo siste-
ma de uma transportadora e que está com o levantamento de requisitos atra-
sado. No módulo de logística, toda carga deve ser liberada em, no máximo, 30
minutos, pois a transportadora tem uma frota de mil caminhões que não podem
esperar mais do que isso para sair dos armazéns. Para a liberação da carga, é emi-
tido um documento de solicitação de liberação e, junto dela, é anexada a nota
fiscal dos produtos contidos no caminhão. A seguir, o Requisito Não Funcional:

144
 UNIDADE 4

[RNF01] Requisito de desempenho: tempo limite de, no máximo, 20 minutos

para processamento de solicitação de liberação de carga.

Cenário negativo: pelo fato de a coleta de requisitos estar em atraso e por ser
um Requisito Não Funcional, a equipe de desenvolvimento não deu a devida
importância ao RNF01 e deixou esta necessidade de tempo de resposta para o
fim do projeto. O que aconteceu? Quando o módulo de logística ficou pronto, a
equipe de implantação iniciou a homologação do sistema e, na primeira bate-
ria de testes, o sistema foi reprovado pela equipe do cliente, responsável pelos
testes de aceitação — área de logística — porque estava demorando 50 minu-
tos, em média, para processar a solicitação de liberação de carga. Qual o efeito
disto? Sistema inviável à produção. Foi necessário reestruturar porque a perfor-
mance do módulo de logística ficou muito ruim.

Causa do cenário negativo: não atendimento do RNF01.

145
Crie um Mapa Mental de como realizar uma especificação de Requisitos Funcio-
nais utilizando casos de uso, histórias de usuário e Requisitos Funcionais para
um cenário de negócios.
O seu mapa deve conter as palavras-chave:
• Especificação de Requisitos.
• Casos de uso.
• Histórias de usuário.
• Requisitos Funcionais para um cenário de negócios.
5
Gerenciamento de
Requisitos
de Software
Esp. Janaína Aparecida de Freitas

Caro(a) estudante, nesta unidade, falaremos sobre o gerenciamento

de requisitos, como ocorre a rastreabilidade dos requisitos, como rea-
lizar o controle de mudanças, construir uma matriz de rastreabilidade
e preencher um template da matriz de rastreabilidade de requisitos
de software.
UNIDADE 5

Durante o nosso estudo, falamos o quanto é complexo e desafiador realizar a coleta

de requisitos de software. Desenvolver um sistema é algo que exige interpretação
e dedução do que o cliente deseja, o que nem sempre é fácil. Como resolver isso?
Aprendemos várias formas e técnicas de levantamento de requisitos e, se eles mu-
darem ao longo do desenvolvimento do sistema? Pode ter certeza: eles mudam,
pois, como vimos, o cliente, às vezes, não sabe o que quer. Ou leis e normas do
negócio se alteram ou o cliente quer algum recurso tecnológico novo no sistema.
E como ficam os requisitos coletados e aprovados? Precisam ser gerenciados.
De que modo realizar o gerenciamento de requisitos? Desde as fases iniciais
da coleta de requisitos, pois é neste momento que as políticas de gestão de requisi-
tos devem ser definidas e planejadas, pensando nas características e necessidades
do sistema a ser desenvolvido. Você lembra da Maria, funcionária de um restau-
rante cuja função era controlar as compras mensais? Você foi o(a) engenheiro(a)
de software responsável pela coleta de requisitos para desenvolver o sistema de
controle de compras. Mas, agora, no lugar da Maria, entrou o colaborador João,
ele quer mudanças nesse sistema.
Agora, você é responsável pelas mudanças que o João deseja no sistema de
compras do restaurante. As compras, antes, eram feitas pela própria Maria e,
por este motivo, ela não via necessidade em relacionar as marcas dos produtos,
porém João quer um cadastro de marcas de produtos para comparar os preços.

150
 UNICESUMAR

Registre, em seu Diário de Bordo, o que você precisa fazer para realizar as
mudanças solicitadas pelo João no sistema de compras do restaurante. Será que
você precisa usar alguma técnica de coleta de requisitos para saber como o João
quer esse cadastro de marcas de produtos? Será que haverá alterações em requi-
sitos já implementados? Além do novo cadastro de marcas, o João quer algum
novo relatório? Ou ele quer alterações em algum relatório existente no sistema?
Procure anotar todas as possibilidades que poderão esclarecer com esse funcio-
nário, quando vocês se reunirem. Você consegue!

DIÁRIO DE BORDO

151
UNIDADE 5

Evolução dos requisitos de software

Aprendemos que um processo de Engenharia de Requisitos é, também, um con-

junto estruturado de atividades/etapas/fases que são seguidas para derivar, vali-
dar e manter um documento de requisitos de um sistema. O processo usado na
Engenharia de Requisitos pode variar bastante em função de vários fatores e as
atividades na área são divididas em especificação de requisitos, as quais foram
conhecidas nas unidades anteriores, e a Gestão de Requisitos, que conheceremos
nesta unidade.

“
As atividades da engenharia de requisitos têm o objetivo de apoiar o
ciclo de desenvolvimento de software em todos os aspectos relacio-
nados com os requisitos, que vão desde as atividades de elicitação até
as atividades de verificação e validação, incluindo o gerenciamento
de requisitos. O gerenciamento de requisitos envolve estabelecer
mecanismos que permitam acompanhar o status dos requisitos ao
longo do processo de desenvolvimento, garantindo que as versões
estejam sob controle. Além disso, visa a tratar as solicitações de mu-
danças que irão inevitavelmente acontecer ao longo da vida de um
produto de software, provendo mecanismos de rastreabilidade que
apoiam a tomada de decisão (REINEHR, 2020, p. 283).

A atividade Gestão de Requisitos é responsável por documentação, versiona-

mento, controle de mudanças e qualidade dos requisitos levantados na fase de
especificação deles, ou seja, a evolução dos requisitos do software. Para Sommer-
ville (2018, p. 77): “os requisitos para sistemas de software de grande porte estão
sempre mudando. [..] Porque o problema não pode ser totalmente definido, os
requisitos de software são obrigados a ser incompletos”.

152
 UNICESUMAR

Aprendemos que, durante o processo de desenvolvimento do software, o

entendimento dos usuários a respeito do problema está em constante mudanças,
ou seja, em evolução (Figura 1).

Compreesão Compreensão
inicial do alterada do
problema problema

Requisitos Requisitos
iniciais alterados

Tempo
Figura 1 - Processo de evolução dos requisitos / Fonte: Sommerville (2018, p. 78).

Descrição da imagem: a ilustração representa o processo de evolução dos requisitos de software. Há, na
imagem, quatro retângulos. No primeiro retângulo, no interior dele, está o texto “Compreensão inicial do
problema”. Desse retângulo sai uma seta que o liga ao segundo retângulo, o qual traz o texto “Requisitos
iniciais”. Esse retângulo está ligado, por meio de uma seta, ao terceiro retângulo, cujo texto é “Compreensão
alterada do problema”. A partir desse retângulo sai uma seta ligando-o ao quarto retângulo, que traz o texto
“Requisitos alterados”. Em paralelo aos retângulos, do lado de baixo deles, há uma linha com uma longa seta
apontando para o lado direito da imagem e, na ponta da seta, o texto “Tempo”.

Logo depois dos requisitos iniciais do sistema, caso ocorram mudanças, de-
vemos ter uma compreensão alterada do problema, isto é, evoluir para refletir
estas novas percepções do problema.
Pense no cenário: depois que o sistema é implantado no cliente e ele passa a
usá-lo, regularmente, é inevitável surgirem novos requisitos. Há como antecipar
essas mudanças? Não, porque é difícil para o(a) engenheiro(a) de requisitos pre-
ver o que os usuários e clientes, realmente, precisarão ou antecipar os efeitos que
o novo sistema terá no negócio ou como o trabalho será realizado, tampouco se
há regras de negócio as quais possam vir a ser alteradas pelo governo ou pelos
órgãos. Enquanto os usuários usam o sistema, eles vão adquirindo experiência e,
com isso, descobrindo novas necessidades e prioridades.

153
UNIDADE 5

“
Requisitos são elementos que têm um ciclo de vida bem definido.
Eles nascem a partir das atividades de elicitação, são analisados, es-
pecificados, validados e então seguem para o desenvolvimento, em
que serão codificados, testados e entregues na forma de um produto
de software. A partir da sua entrega, o requisito passa a viver para
sempre dentro do produto, até que alguma solicitação de mudança
o elimine ou modifique (REINEHR, 2020, p. 283).

Na perspectiva da evolução dos requisitos, Sommerville (2018) apresenta duas

classificações deles: Requisitos Permanentes e Requisitos Voláteis, conforme
mostra a Figura 2.

Requisitos Permanentes: são os requisitos

criados a partir do domínio da aplicação,
são relativamente estáveis, mudam mais
lentamente do que os Requisitos Voláteis.
Classificação
dos Requisitos
(Evolução dos
Requisitos)
Requisitos Voláteis: são requisitos que
mudarão durante o tempo de desenvolvi-
mento do sistema, provavelmente, depois,
quando já estiverem em operação.

Figura 2 - Mapa mental da classificação dos requisitos / Fonte: adaptada de Sommerville (2018).

Descrição da imagem: a figura representa o mapa mental da classificação dos requisitos, onde, do lado
esquerdo, há um retângulo com o texto “Classificações de Requisitos (Evolução dos Requisitos)”. Desse re-
tângulo saem duas setas para outros dois retângulos que têm, no interior de cada um, os textos “Requisitos
Permanentes: são os requisitos criados a partir do domínio da aplicação, são, relativamente, estáveis, mudam
mais lentamente do que os Requisitos Voláteis” e “Requisitos Voláteis: são requisitos que mudarão durante o
tempo de desenvolvimento do sistema, provavelmente, depois, quando já estiverem em operação”.

154
 UNICESUMAR

Para entender a diferença entre os requisitos, seguem alguns exemplos. Como

Requisitos Permanentes, temos:
■ Sistema de Recursos Humanos (SRC): em sistemas deste tipo, sempre
existirão os requisitos relacionados à documentação dos funcionários/
colaboradores ou requisitos que fazem referências à empresa ou requisitos
referentes ao calendário básico de vencimentos.
■ Sistema Hospital: em sistemas deste tipo, sempre haverá médicos, enfer-
meiros e atendentes, ou seja, é padrão disponibilizarem uma aba/janela/
menu referente aos cadastros básicos.

Como exemplos de Requisitos Voláteis, temos que:

■ Sistema de Recursos Humanos (SRC): as regras de pagamento dos fun-
cionários/colaboradores podem sofrer alterações por imposição de leis
ou por mudança na política da empresa.
■ Sistema Hospital: um sistema de hospital tem requisitos derivados da
política de saúde.
■ Sistema de Vendas: um sistema que emite notas fiscais tem requisitos de-
rivados das políticas tributárias.

Sommerville (2018) ainda divide os Requisitos Voláteis em quatro classes: Mutá-

veis, Emergentes, Consequentes e Compatibilidade, conforme a Figura 3.

155
UNIDADE 5

Mutáveis: modificam devido às mudanças

no ambiente em que a organização está
inserida.

Emergentes: surgem conforme a

compreensão do cliente referente ao
sistema.

Divisão dos
Requisitos
Volatéis

Consequentes: são os requisitos

que surgem após a inserção do
sistema na organização.

Compatibilidade: são os requisitos que

dependem de outro sistema, equipamento
ou processo

Figura 3 - Mapa mental da divisão dos Requisitos Voláteis / Fonte: adaptada de Sommerville (2018).

Descrição da imagem: a ilustração representa o mapa mental da divisão dos Requisitos Voláteis, onde, do
lado esquerdo, um retângulo com o texto “Divisão dos Requisitos Voláteis”. Desse retângulo saem quatro
setas que apontam para quatro retângulos e, no interior de cada um, estão os textos: “Mutáveis: modificam
devido às mudanças no ambiente em que a organização está inserida”, “Emergentes: surgem conforme a
compreensão do cliente referente ao sistema”, “Consequentes: são os requisitos que surgem após a inserção
do sistema na organização” e “Compatibilidade: são os requisitos que dependem de outro sistema, equipa-
mento ou processo”.

De acordo com Sommerville (2018), existem várias razões pelas quais a evolução
dos requisitos é inevitável:

156
 UNICESUMAR

O ambiente técnico e de negócios do sistema sempre

muda. Um novo hardware pode ser introduzido, afinal,
talvez seja necessário fazer a interface do sistema com
outros sistemas, as prioridades do negócio podem mu-
1. Após a implantação
dar (com consequentes alterações necessárias no apoio
do sistema), é possível que sejam introduzidos novas
legislações e regulamentos os quais o sistema deve,
necessariamente, respeitar etc.

As pessoas que pagam por um sistema e os seus usuá-

rios, raramente, são os mesmos. Clientes do sistema
impõem requisitos devido a restrições orçamentárias e
2. Quem paga não é
organizacionais, as quais podem entrar em conflito com
quem usa
os requisitos do usuário final e, após a entrega, novos
recursos são, talvez, adicionados, para dar suporte ao
usuário, a fim de que o sistema cumpra as suas metas.

Sistemas de grande porte têm uma comunidade de di-

versos usuários com diferentes requisitos e prioridades,
às vezes, conflitantes ou contraditórios. Os requisitos do
3. Sistema com diver-
sistema final são, certamente, um compromisso entre
sos usuários
esses usuários e, com a experiência, frequentemente,
descobre-se que o balanço de apoio prestado aos dife-
rentes usuários precisa ser mudado.

Quadro 1 - Razões para mudanças nos requisitos / Fonte: adaptado de Sommerville (2018).

Perguntar, hoje em dia, porque os requisitos mudam, é considerado algo estranho.

O ideal é perguntar o que não muda, afinal, o setor de tecnologia está em cons-
tantes transformações. Em suma, mudar se tornou uma regra para as empresas
que querem acompanhar essa evolução tecnológica.

157
UNIDADE 5

EXPLORANDO IDEIAS

“As causas para as mudanças nos requisitos vão muito além das mudanças de tecnologia.
Devemos ter sempre em mente que o usuário tem um problema que precisa ser resolvido
por meio do software. O software não é um fim em si mesmo, mas é o meio pelo qual o
problema é resolvido, seja um problema do mundo dos negócios, seja uma questão ligada
ao lazer ou à sua vida pessoal. O usuário entende do problema em si, e não do mundo de
desenvolvimento de software. E nós, da computação, entendemos do mundo dos bits e
bytes, e não do negócio”.
Fonte: Reinehr (2020, p. 269).

Mudanças ocorrem e a depender da causa, os requisitos evoluem, então, temos

que os gerenciar para analisar o impacto dessas mudanças, procurar avaliar os
riscos e, com isso, priorizar as implementações. Segundo Sommerville (2018), o
gerenciamento de requisitos é o processo de compreensão e controle das mudan-
ças nos requisitos do sistema, etapa a qual pode se tornar complexa.
Mas o que torna o gerenciamento dos requisitos complexo? A mudança
em um requisito costuma gerar fortes impactos em outros requisitos já im-
plementados ou não no sistema e isso é assustador (SOMMERVILLE, 2018).
Para agravar a situação: os sistemas, de modo geral, devem levar em conta que
o mundo está em constante mudança, de modo que algumas das hipóteses
levantadas nas fases iniciais do levantamento de requisitos correm o risco de
se tornarem equivocadas (SOMMERVILLE, 2018).
Visando a amenizar essas situações, o processo para o gerenciamento de re-
quisitos precisa começar logo que uma versão preliminar do documento de re-
quisitos do sistema estiver disponível. O primeiro passo é o planejamento, onde
se decide sobre:
1. Identificação dos requisitos: identificar, unicamente, cada requisito.
2. Gerenciamento de mudanças: conjunto de atividades que avaliam o im-
pacto das mudanças no sistema.
3. Políticas de rastreabilidade: definir relacionamentos entre os requisitos e
como esses requisitos devem ser mantidos.
4. Ferramentas de apoio: o gerenciamento de requisitos precisa de apoio
automatizado. As ferramentas costumam ser escolhidas durante a fase
de planejamento.

158
 UNICESUMAR

Conforme Sommerville (2018, p. 80): “mudanças organizacionais, mudanças nos

negócios e mudanças técnicas inevitavelmente geram mudanças nos requisitos
para um sistema de software”. Assim, o gerenciamento de requisitos é importante,
pois ele ajuda no processo de gerenciamento e controle dessas mudanças que
podem ocorrer ao longo do ciclo de vida do software.

EXPLORANDO IDEIAS

“O gerenciamento de requisitos é o processo de compreensão e controle das mudanças

nos requisitos do sistema. Você precisa se manter a par das necessidades individuais e
manter as ligações entre as necessidades dependentes para conseguir avaliar o impacto
das mudanças nos requisitos. Você precisa estabelecer um processo formal para fazer
propostas de mudanças e a ligação destas às exigências do sistema. O processo formal
de gerenciamento de requisitos deve começar assim que uma versão preliminar do docu-
mento de requisitos estiver disponível. No entanto, você deve começar a planejar como
gerenciar mudanças de requisitos durante o processo de elicitação de requisitos”.
Fonte: Sommerville (2018, p. 80).

Controle de mudanças dos requisitos de software

Os requisitos e as necessidades das empresas mudam durante o ciclo de vida do

software, seja por bugs, seja porque precisam se adaptar às mudanças do merca-
do. Após a aprovação do documento de requisitos, é necessário pensar em como
controlar as mudanças deles, isto é, o gerenciamento de mudança de requisitos
deve ser aplicado a todas as mudanças que forem propostas aos requisitos de um
software (Figura 4).

159
UNIDADE 5

Problema Requisitos
identificado Análise de problema Análise de Implementação revisados
e especificação mudanças e custos de mudanças
de mudanças

Figura 4 - Gerenciamento de mudanças de requisitos / Fonte: Sommerville (2018, p. 79).

Descrição da imagem: a ilustração representa o gerenciamento de mudanças de requisitos, começando

por uma seta apontando da esquerda para direita e, em cima dela, há o texto “Problema identificado”. A
seta vai em direção ao retângulo que traz, em seu interior, o texto “Análise de problema e especificação de
mudanças”. Desse retângulo sai uma seta em direção ao retângulo cujo interior mostra o texto “Análise de
mudanças e custos”. Desse retângulo parte uma seta em direção ao retângulo que mostra o texto “Imple-
mentação de mudanças” e, desse retângulo sai uma seta apontando para a direita e, em cima dela, há o
texto “Requisitos revisados”.

Para o processo de gerenciamento de mudanças, temos três estágios principais,

de acordo com Sommerville (2018):
1. Análise de problema e especificação de mudanças: o processo come-
ça com um problema de requisitos identificado ou com uma proposta
específica de mudança. Durante este estágio, analisa-se o problema ou a
proposta de mudança, a fim de se verificar a sua validade.
2. Análise de mudanças e custos: neste estágio, o efeito da mudança pro-
posta é avaliado por meio das informações de rastreabilidade e dos co-
nhecimentos gerais dos requisitos do sistema. O custo de fazer a mudança
é estimado em termos de modificações no documento de requisitos e, se
apropriado, no projeto e na implementação do sistema.
3. Implementação de mudanças: neste estágio, o documento de requisitos
ou o projeto e a implementação do sistema são modificados.

O ideal é, sempre, tentarmos modificar o documento de requisitos ao mesmo

tempo em que o requisito é alterado ou adicionado ao sistema, assim, a especifi-
cação de requisitos e a implementação do sistema não ficarão defasadas.

160
 UNICESUMAR

“
O gerenciamento de mudanças é essencial, pois é necessário de-
cidir se os benefícios da implementação de novos requisitos jus-
tificam os custos de implementação. A vantagem de se usar um
processo formal de gerenciamento de mudanças é que todas as
propostas de mudanças são tratadas de forma consistente, e as
alterações nos documentos de requisitos são feitas de forma con-
trolada (SOMMERVILLE, 2018, p. 79).

Empresas que utilizam metodologias ágeis de desenvolvimento, como Extre-

me Programming (XP), lidam com requisitos mutáveis durante o processo de
desenvolvimento e, nestas metodologias, quando um cliente solicita uma mu-
dança nos requisitos, a mudança proposta não passa por um processo de ge-
renciamento de mudanças. Neste caso, é o contrário, o cliente precisa priorizar
essa mudança e, caso ela seja de alta prioridade, ele decide quais recursos do
sistema planejados para a próxima iteração devem ser abandonados, visando à
implementação dessa prioridade.

EXPLORANDO IDEIAS

“Embora seja tentador definir diversos atributos para caracterizar um requisito, favore-
cendo o seu gerenciamento, isso pode custar caro em termos de manutenção. Para cada
um dos atributos de um requisito, deverá ser prevista uma forma de garantir a sua integri-
dade ao longo do tempo. Por exemplo, quando um requisito que, no primeiro momento,
estava instável se tornar mais claro e estável, será necessário refletir essa mudança no
atributo relativo à estabilidade. Isso vale para todos os demais atributos. Dessa forma,
é importante selecionar aqueles mais relevantes de acordo com o contexto do projeto,
pois eles precisarão estar sempre atualizados para que possam ser úteis para o gerencia-
mento dos requisitos. Para selecionar os atributos que serão mantidos, imagine em que
situações eles serão úteis. Pense que perguntas poderão ser respondidas por eles e com
que frequência você se faz essas perguntas. É possível que em alguns momentos você
pense: “seria tão legal ter este atributo!”. Em seguida, pense: “Se fosse eu que tivesse que
manter atualizados todos estes atributos, eu continuaria investindo em mantê-los?”. Se a
resposta for sim, este é um candidato. Se for não, aproveite para trocar uma ideia com
outros colegas, para analisar a real importância da manutenção dele”.
Fonte: Reinehr (2020, p. 288).

161
UNIDADE 5

Rastreabilidade dos requisitos de software

Falamos sobre o processo de gerenciamento de requisitos e os passos para o

planejamento. Mas você pode estar se perguntando: o que garante um geren-
ciamento de requisitos bem-sucedido? Um processo de controle de mudanças
conciso e um atributo de rastreabilidade bem definido auxiliam na garantia de
um gerenciamento com boas execução e sucesso.

“
Para que possamos analisar o impacto decorrente de uma soli-
citação de mudança e, posteriormente, planejar a modificação, é
necessário que sejam disponibilizadas informações para apoiar
essa tomada de decisão. Uma das formas de realizar essa análise
é por meio dos registros de rastreabilidade. Identificar e manter a
rastreabilidade dos requisitos é uma das atividades da gerência de
requisitos (REINEHR, 2020, p. 267).

A rastreabilidade de requisitos de software é definida como um conjunto de rela-

cionamentos ou ligações dos requisitos coletados com as fontes das informações
dos requisitos ou com eles mesmos e com outros artefatos.

162
 UNICESUMAR

A rastreabilidade é, com frequência, conseguida das seguintes formas:

■ Vínculo do requisito ao stakeholder que solicitou.
■ Vínculo do requisito aos requisitos relacionados.
■ Vínculo do requisito aos padrões do projeto.

Em certos momentos, durante o levantamento de requisitos, algumas das con-

dições de rastreamento são atribuídas e vinculadas aos requisitos e, em outros
momentos, são atribuídas para refletir a facilidade de se encontrar, quando ne-
cessário, os requisitos relacionados.
Sommerville (2018) relaciona três tipos de rastreabilidade de requisitos:
1. Rastreabilidade por stakeholders: vincula o requisito ao stakeholder
que o solicitou. Utilizada quando uma mudança ocorre, a fim de desco-
brir os stakeholders e, assim, os consultar.
2. Rastreabilidade por requisitos dependentes: ocorre quando o re-
quisito é vinculado a outro requisito, no seu levantamento. Utilizada
para avaliar quantos requisitos serão afetados pela mudança solicitada
e a extensão dessas mudanças.
3. Rastreabilidade por modelos de projeto: vincula o requisito ao mo-
delo de projeto onde foi implementado. Utilizada com o objetivo de
avaliar o impacto das mudanças para o projeto e a implementação.

O ideal seria se os critérios de rastreabilidade dos requisitos fossem determi-

nados no momento da sua especificação. Segundo Reinehr (2020, p. 272), para
que “uma mudança possa ser realizada de forma adequada, é necessário garantir
que as ligações entre os requisitos ou entre os requisitos e outros elementos do
sistema sejam conhecidas e possam ser utilizadas como base para essa análise”.
Esta ligação é chamada de rastreabilidade de requisitos.
Podemos dividir a rastreabilidade de requisitos em:
■ Rastreabilidade vertical para trás (backward traceability): quando
se refere a rastrear um requisito quanto à sua origem.
■ Rastreabilidade vertical para frente (forward traceability): quando
se refere aos desdobramentos que um requisito pode ter.
■ Rastreabilidade horizontal entre os requisitos: quando se mapeia as
dependências entre os requisitos.

163
UNIDADE 5

Rastreabilidade horizontal
(entre requisitos)

Rastreabilidade vertical Rastreabilidade vertical

para trás (backward) para frente (forward)

Artefatos Requisitos Artefatos

anteriores/ baseados nos
Fontes de requisitos
informação

Figura 5 - Tipos de rastreabilidade / Fonte: Reinehr (2020, p. 273).

Descrição da figura: a ilustração apresenta os tipos de rastreabilidade. No lado esquerdo da imagem, há

um círculo cujo interior mostra um desenho de um grupo de pessoas e, logo abaixo desse círculo, o texto
“Artefatos anteriores/Fontes de informação”. No centro da imagem, há um círculo cujo interior mostra o
desenho de uma folha de documento e, embaixo desse círculo, está a palavra “Requisitos”, em cima dele, o
texto “Rastreabilidade horizontal (entre requisitos)”. Do lado esquerdo dessa figura, vê-se um triângulo na
horizontal com a ponta para o lado esquerdo e, em cima desse triângulo, o texto “Rastreabilidade vertical
para trás (backward)”, enquanto que, do lado direito do círculo, vê-se outro triângulo na horizontal com a
ponta para o lado direito e, em cima, o texto “Rastreabilidade vertical para frente (forward)”. Esse triângulo
aponta para outro círculo cujo interior mostra um desenho de celular e um monitor e, embaixo desse círculo,
o texto “Artefatos baseados nos requisitos”.

De acordo com Reinehr (2020, p. 273) manter a rastreabilidade é:

“
Uma ação importante e que gera valor para o software, especial-
mente na fase de manutenção. O importante é manter o equilíbrio
do que é rastreado para poder garantir que as informações estejam
sempre atualizadas. Pior do que não ter uma informação, nesse caso,
é ter uma informação incompleta ou incorreta.

A rastreabilidade de requisitos é muito importante para uma análise do impacto

das solicitações de mudança que possam ocorrer ao longo do ciclo de vida de um
software. O Quadro 2 mostra o que a rastreabilidade permite:

164
 UNICESUMAR

Permite buscar requisitos de domínio que não são

Encontrar requisitos rastreados para requisitos de usuário e requisitos de
faltantes usuário que não são rastreados para nenhum requisi-
to funcional.

Permite procurar por quaisquer requisitos funcionais

Encontrar requisitos que não são rastreados de volta para requisitos de
desnecessários usuários e requisitos de domínio e que podem ser
desnecessários.

Permite usar as informações de rastreabilidade para

Realizar a certificação
certificar um produto crítico, a fim de demonstrar que
e a conformidade
todos os requisitos foram implementados.

Permite verificar requisitos sem informação de ras-

Realizar a análise de
treamento e que podem afetar o sistema, caso sejam
impacto de mudanças
realizadas mudanças nele.

Permite ter informações de rastreamento confiáveis

Manter o software que facilitam a capacidade de fazer mudanças de for-
ma correta e completa durante a manutenção.

Permite registrar os dados de rastreamento durante o

Acompanhar o projeto desenvolvimento. Terá um registro preciso do status
de implementação da funcionalidade planejada.

Permite listar as funções em um sistema existente que

Realizar a reengenha- está sendo substituído e rastreá-las até onde elas são
ria endereçadas nos requisitos do novo sistema e compo-
nentes de software.

Permite que as informações de rastreabilidade de

Promover a reutiliza- reuso facilitam a reutilização dos componentes do
ção produto, identificando pacotes de requisitos, projetos
(design), códigos e testes relacionados.

Permite que, quando um teste falha, as ligações entre

os testes, os requisitos e o código apontem os desen-
Executar testes volvedores às áreas prováveis a serem examinadas.
A rastreabilidade apoia, portanto, as correções de
defeitos encontrados em testes.

Quadro 2 - Itens que mostram a importância da rastreabilidade / Fonte: adaptado de Reinehr (2020).

165
UNIDADE 5

Quando se faz o planejamento do gerenciamento de requisitos, é necessário deci-

dir quais critérios de rastreabilidade serão utilizados para atribuir ao requisito, já
no momento da sua especificação. Visando a auxiliar nessas decisões, são usadas
ferramentas de mapeamento de grafo ou matrizes bidimensionais para imple-
mentar a rastreabilidade, além de manter o controle das mudanças nos requisitos.
Temos muitos itens que podem ser rastreáveis, e a identificação de quais de-
les devem ser rastreados envolve uma tomada de decisão por parte da equipe
de desenvolvimento e demais stakeholders. Precisamos decidir quais elementos
devemos colocar sob controle de configuração de mudanças e quais elementos
devemos, apenas, documentar.
De acordo com Reinehr (2020), temos alguns itens candidatos a serem itens
rastreáveis:
■ As fontes de informação que fornecem a origem do requisito.
■ Os requisitos considerados críticos para o negócio (regras de negócio).
■ Os requisitos que mais impactam na arquitetura de software.
■ Os requisitos sujeitos a mudanças e com maior volatilidade (impostos e
tributos, notas técnicas, tecnologias novas etc.).
■ Os requisitos considerados mais críticos sob a ótica da equipe de teste,
por exemplo, quais os requisitos são mais difíceis de testar.
■ Os códigos críticos para o sistema.
■ Os casos de teste críticos para o sistema.

EXPLORANDO IDEIAS

“Escolha do que será rastreado: todos sabemos que manter atributos que permitam a
rastreabilidade de todos os elementos de um projeto é uma tarefa praticamente impossí-
vel. São necessários muito esforço e muita disciplina para que os elementos selecionados
sejam mantidos atualizados. Pior do que não haver um mecanismo de rastreabilidade é
ter um mecanismo desatualizado e não confiável. Se uma análise de impacto foi baseada
em registros de rastreabilidade não confiáveis, corremos o risco de iniciar uma mudança
sem a real visão sobre sua abrangência, o que pode levar a uma estimativa imprecisa de
custos, cronograma e riscos. Por outro lado, registrar todos os relacionamentos entre to-
dos os elementos do desenvolvimento de software também é uma tarefa difícil e onerosa.
Pode ser que haja relacionamentos muito triviais, que nunca serão utilizados e que, se
tivessem sido analisados previamente, talvez não precisassem ser mantidos”.
Fonte: Reinehr (2020, p. 276).

166
 UNICESUMAR

Matriz de rastreabilidade de requisitos de software

Aprendemos sobre o gerenciamento de requisitos, as mudanças e os tipos de

rastreabilidade. Agora, veremos como ligar os requisitos às suas origens e os ras-
trear durante todo o ciclo de vida do software. Com este intuito, veremos como
elaborar um documento para registrar as mudanças e permitir, do início ao fim
do projeto de software, o rastreamento dos requisitos. Esse documento é a matriz
de rastreabilidade de requisitos de software.
A matriz de rastreabilidade de requisitos, de acordo com o guia Guia PM-
BOK® (2013), possui as seguintes funções:
■ Garante que cada um dos requisitos adicione valor de negócio por meio
do seu relacionamento/ligação aos objetivos funcionais do projeto de
desenvolvimento (regra de negócio).
■ Fornece um meio de rastreamento desde o início até o fim do ciclo de
vida do software.
■ Garante que os requisitos validados no documento de requisitos sejam
entregues no final do projeto.
■ Fornece uma estrutura de gerenciamento das mudanças dos requisitos
do software.

A matriz de rastreabilidade de requisitos é uma tabela que relaciona os atri-

butos associados a cada requisito e que os relaciona à sua origem. Os atributos
associados podem ser:

167
UNIDADE 5

I - Identificador do requisito.
II - Descrição do requisito conforme o documento de requisitos.
III - Nome do solicitante do requisito.
IV - Prioridade do requisito.
V - Situação do requisito que pode ser: aprovado, em desenvolvimento, en-
tregue, entre outros.
VI - Critérios de aceitação do requisito.

Para a disciplina, o template da matriz de rastreabilidade de requisitos de software

escolhido baseia-se no modelo proposto pelo Guia PMBOK® (2013) à elaboração
da matriz de rastreabilidade de requisitos.
Segue o template criado em uma planilha de Excel:

Matriz de Rastreabilidade de Requisitos

Data Versão Descrição Responsável

23/04/22 1.0 Elaboração da matriz Janaina Freitas

… … … ..

25/04/22 3.0 Inserção de novo requisito Rafael Florindo

Legendas

Priorida- Tipo do Requisito Complexida-

Status
de (PR) (TR) de (Cx)

Alta Funcional Validado Alta

Média Não funcional Em desenvolvimento Média

Baixa Qualidade Em teste Baixa

Concluído

ID Critérios Solicitan- Dt
Descrição Complex. Status
Req. aceitação te Validação

Quadro 3 - Matriz de rastreabilidade de requisitos / Fonte: Guia PMBOK® (2013, p. 115).

168
 UNICESUMAR

Neste modelo, as informações devem ser preenchidas com os requisitos expressos

em linguagem natural e numerados sequencialmente (ID). As colunas e as linhas
são, muitas vezes, adaptadas de acordo com o processo de desenvolvimento da
empresa.
Para entender, segue um exemplo de matriz de rastreabilidade no qual é
possível verificar os requisitos e os casos de testes:

MATRIZ DE RASTREABILIDADE

Identificação do projeto Data criação matriz

Gerente projeto

Resumo projeto

ID Requisito Doc. Fonte Arquitetura Componente Caso de teste

Quadro 4 - Exemplo de matriz de rastreabilidade / Fonte: Guia PMBOK® (2013, p. 115).

A empresa tem a possibilidade de desenvolver um software destinado a registrar

os atributos da matriz de rastreabilidade. No exemplo da Figura 3, temos infor-
mações para registrar um caso de testes, onde temos os requisitos associados e os
designs associados a cada um deles. O sistema poderá ter, também, informações
gerais, descrição dos requisitos e artefatos associados.

169
UNIDADE 5

Figura 6 - Exemplo de software para registrar atributos da matriz de rastreabilidade / Fonte: a autora.

Descrição de imagem: a imagem mostra, por meio de um print screen, uma tela de um software destinado a
registrar a matriz de rastreabilidade. Nessa tela, é possível ver o título “Registrar: Caso de Teste”. A tela mostra três
abas: “Informações Gerais”, “Descrição” e “Artefatos Associados”. Dentro da aba “Artefatos Associados”, está a lista
de requisitos associados em forma de tabela, com as colunas “Identificador”, “Título”, “Categoria” e “Tipo”. Embai-
xo dessa lista, há outra tabela mostrando os designs associados, por meio das colunas “Identificador” e “Título”.

A matriz de rastreabilidade costuma ser representada por um modelo simples,

como o template usado, ou, pelo uso de uma ferramenta de rastreabilidade de
requisitos.
Existem, no mercado, várias ferramentas usadas no gerenciamento de re-
quisitos e na matriz de rastreabilidade. Veja, a seguir, uma lista de ferramentas:

170
 UNICESUMAR

Ferramenta Descrição
Software usado para o gerenciamento de requisitos e que ajuda
as equipes a planejar e a executar projetos entregues e os
monday.com
resultados que estão no prazo, seja no escritório, seja em casa
ou em qualquer lugar.

Software usado para a gestão de requisitos em projetos de

engenharia de sistemas e processos. Fornece as ferramentas de
Cradle gestão de requisitos de última geração e integra essa gestão com
o suporte total de engenharia de sistemas, incluindo modelagem,
gestão de teste, gestão e controle de configuração formal.

A ferramenta Jira ocupa, entre as equipes ágeis, o primeiro

lugar. Ela mostra uma visão geral do trabalho bem como au-
menta a produtividade ao automatizar, apenas com alguns cli-
Jira
ques, tarefas e processos. Tem edição gratuita para equipes
de até dez usuários aproveitarem toda a potência do Jira sem
custos, para sempre.

O ClickUp oferece tarefas, agendamento, automações, priori-

dades, comentários atribuídos, visualizações personalizadas,
ClickUp documentos, lembretes, metas, calendários, bate-papo, entre
outros, para ajudar a gerenciar requisitos em qualquer projeto
ou equipe.

O software do Wrike planeja, gerencia e gera relatórios sobre os

requisitos. Acompanhe os requisitos usando modelos predefi-
Wrike nidos, gráficos de Gantt, fluxos de trabalho poderosos e painéis
de equipe compartilhados. Automatize os seus processos de
solicitação usando aprovações e solicitações.

O SpiraTest é uma solução integrada de gestão da qualidade e

dos requisitos que gerencia casos de teste, liberações, requi-
SpiraTes
sitos, defeitos e problemas do projeto em um ambiente com
rastreabilidade completa.

O TraceCloud é uma solução de rastreabilidade e gestão de

requisitos de projetos. Ele também está disponível na platafor-
ma ServiceNow. Para grandes projetos de engenharia onde a
TraceCloud
gestão de mudanças, o controle de mudanças e a rastreabili-
dade são fundamentais, o TraceCloud fornece uma estrutura
leve e fácil de usar.

171
UNIDADE 5

O ReqView é uma ferramenta de gestão de requisitos simples

de usar. Ela é voltada a capturar requisitos estruturados para
ReqView
produtos de software ou sistema e gerenciar links de rastreabili-
dade entre requisitos de produtos, design, testes e riscos.

A ferramenta de gestão de requisitos do Orcanos é uma so-

lução em nuvem econômica e completa para rastreamento e
gestão de requisitos e testes, como parte de sua plataforma de
Orcanos
ALM e QMS integrada. O Orcanos ALM oferece, em um único re-
positório, procedimentos nas seguintes gestões: de requisitos,
de testes, de riscos de FMEA, de documentos e de qualidade.

O ReQtest oferece um módulo de gestão de requisitos que aju-

ReQtest da a gerenciar as suas necessidades de negócios com melhor
controle, rastreabilidade total e informações acionáveis.

Com o aqua, você define, no início do projeto por requisitos e

histórias de usuário, o que o produto deve alcançar. Um editor
UML integrado facilita a criação de diagramas UML, claramente,
aqua ALM compreensíveis que complementam requisitos. Casos de teste
podem ser gerados, automaticamente, a partir desses diagramas,
com o apertar de um botão. A vinculação automática dos casos
de teste e defeitos com os requisitos cria transparência e rastrea-
bilidade bem como facilita a comunicação dentro do projeto.

Visure é um provedor líder de ferramentas de gestão de requi-

sitos que oferece uma abrangente plataforma colaborativa de
ALM, incluindo total rastreabilidade, integração com MS Word/
Excel, gestão de riscos e de testes, rastreamento de erros,
Visure
testes de requisitos, análise da qualidade de requisitos, versão
e linha de base de requisitos, poderosa geração de relatórios e
modelos de conformidade padrão para ISO 26262, IEC 62304,
IEC 61508, CENELEC 50128, DO-178B/C, FMEA, SPICE, CMMI etc.

Quadro 5 - Lista de ferramentas para gerenciamento de requisitos e matriz de rastreabilidade

Fonte: adaptado de Capterra ([2022], on-line).

A rastreabilidade dos requisitos, conforme Reinehr (2020), garante que:

■ Os requisitos foram, totalmente, tratados nas funcionalidades entregáveis
para o cliente.
■ Os requisitos de baixo nível possam ser rastreados a uma fonte de infor-
mação válida.

172
 UNICESUMAR

■ Os requisitos foram implementados.

■ Os requisitos selecionados foram verificados e validados.
■ Os relacionamentos com outras entidades possam incluir dependências
nas quais a mudança em um requisito implica a mudança em outros re-
quisitos, o que ajuda no apoio no projeto e na avaliação do impacto das
mudanças.
■ Afete a avaliação do impacto das mudanças.
■ Apoie a mudança antecipada do escopo.
■ O projeto (design) e outras documentações reflitam os requisitos.
■ Os planos e casos de teste reflitam os requisitos.

EXPLORANDO IDEIAS

“No caso de ambientes ágeis, os elementos mais presentes são o blacklog e, consequente-
mente, os itens do backlog, as histórias do usuário, os critérios de aceitação, as sprints e o
próprio código. É comum que os critérios de aceitação funcionem como especificação das
regras de negócio e que deem origem aos casos de teste que, geralmente, são automati-
zados. Bastaria substituir os elementos representados por eles. Embora o product owner
funcione como o representante dos usuários para a equipe de desenvolvimento, cada
item do backlog deve ter a sua origem registrada, ou seja, quem solicitou aquele item”.
Fonte: Reinehr (2020, p. 280).

Aprendemos que, independentemente do tipo da mudança a ser realizada no

software, é necessário gerenciá-la. Então, para termos uma gestão de mudanças
efetiva, a organização deve garantir alguns itens, como:
■ Todas as mudanças de requisitos solicitadas pelos stakeholders devem ser
avaliadas, cuidadosamente, antes de serem implementadas.
■ Os responsáveis adequados precisam tomar as decisões de negócio ade-
quadas sobre as mudanças solicitadas.
■ A atividade de gerenciamento de mudança de requisitos deve se tornar
visível a todos os stakeholders que serão afetados.
■ As alterações aprovadas pelos responsáveis necessitam ser comunicadas
a todos os stakeholders afetados.
■ O projeto deve incorporar, de forma consistente e eficaz, as mudanças de
requisitos solicitadas.

173
UNIDADE 5

Pois se mudanças de requisitos forem realizadas sem os devidos cuidados, ou

seja, sem gerenciamento eficaz, os impactos costumam ser desastrosos e tanto a
qualidade quanto a satisfação do usuário são comprometidas (REINEHR, 2020).

Priorização de requisitos e avaliação da qualidade

de software segundo a percepção dos usuários
Como é possível realizar a avaliação da qualidade de um
produto de software desde as etapas iniciais do projeto, de
forma que seja possível realizar as melhorias com menos
esforço? Confira o podcast e veja como é possível realizar a
priorização de requisitos e a avaliação da qualidade.

NOVAS DESCOBERTAS

Título: Engenharia de Software

Autor: Iam Sommerville
Editora: Pearson
Sinopse: considerada uma obra de referência para estudantes dos
cursos de Engenharia de Software e para qualquer profissional que deseje atualizar
os seus conhecimentos sobre Engenharia de Requisitos, projeto de software, reuso e
arquitetura de software, confiabilidade e segurança e engenharia de sistemas, teste e
qualidade de software.

NOVAS DESCOBERTAS

Rastreabilidade de requisitos através da web

O artigo apresenta uma ferramenta para o gerenciamento de re-
quisitos via web cuja ênfase está no uso de matriz de rastreabilidade
como forma de implementar ligações entre requisitos de software.
Por meio dessas ligações, é possível apresentar ao analista as consequências de uma
alteração ou exclusão de requisitos no projeto.
O interessante deste artigo é que ele mostra a o gerenciamento sendo feito via web,
possibilitando que equipes alocadas em diferentes locais acompanhem as informações
atualizadas sobre o andamento do projeto.

174
 UNICESUMAR

Visando a consolidar o conteúdo da unidade, mostraremos um exemplo de ma-

triz de rastreabilidade preenchida. Para o nosso exemplo, usaremos o planeja-
mento voltado à criação de um negócio na modalidade e-commerce cujo termo
de abertura do projeto é denominado “Festas e Datas Comemorativas”.

MATRIZ DE RASTREABILIDADE

Identificação do projeto: Criação do website Data criação matriz 24/04/22

Gerente Projeto Janaina Freitas

Criação de um negócio na modalidade e-com-

Resumo Projeto merce com o termo de abertura do projeto denominado
“Festas e Datas Comemorativas”.

Doc. Componente ou
ID Requisito Prior. Caso de Teste
Fonte Requisito técnico

RT1 - O site terá CT 1 - Teste de

um layout organi- usabilidade do
zado e intuitivo. site.
RF1- Ferra-
menta de Necessi- RT2 - O site terá CT 2 - Portfólio
comerciali- dade do uma tela específica dos produtos
01 Média
zação dos Cliente de exibição das para divulgação
produtos. (NC1) ofertas que estão no site.
Website em destaque.
CT 3 - Documen-
RT3 - Registro de tos da compra
domínio do site. de domínio.

175
UNIDADE 5

RF2 - Implantação CT 3 - Teste de

por meio da cus- usabilidade do
tomização de um sistema.
sistema de infor-
mação já existente CT 4 - Teste de
no mercado. usabilidade do
banco de dados
RF3 - O sistema SQL Server Mi-
Implan- deverá permitir crosoft.
tação do Necessi- realizar e manter
e-com- dade do cadastro de forne- CT 5 - Teste de
02 Média
merce da Cliente cedores, produtos integração do
empresa (NC2) e usuários. sistema.

RF4 - O sistema
deverá permitir
que seja salvo
um histórico de
informações sobre
o recebimento e
armazenamento
de cada produto.

RF1 - Entrevistar CT 6 - Currículo

candidatos para contendo expe-
vaga de auxiliar. riência com web-
site e certificado
Contrata- Necessi- RF2 - O trabalho de Marketing
ção de dade do será executado em digital.
03 Média
funcionário cliente período integral
(NC3) em sistema de CT 7 - Do-
home office. cumento de
recebimento dos
equipamentos
eletrônicos.

Aprovações

Responsável Rafael Florindo - Gerente de Projetos

Data aprovação 24/04/22

176
Crie um Mapa Mental sobre os três tipos de rastreabilidade de requisitos. Ele
deve conter as palavras-chave:
• Rastreabilidade.
• Stakeholders.
• Requisitos dependentes.
• Modelos de projeto.
UNIDADE 1

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software. 9. ed. Porto Alegre: AMGH, 2021.

REINEHR, S. Engenharia de Requisitos. Porto Alegre: Sagah, 2020.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018.

UNIDADE 2

CMMI INSTITUTE. CMMI-DEV 2.0. Schaumburg: CMMI, 2018.

ISO. ISO/IEC/IEEE 12207: 2017. Systems and software engineering — Software life cycle pro-
cesses. Geneva: ISO, 2017.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software. 9. ed. Porto Alegre: AMGH, 2021.

REINEHR, S. Engenharia de Requisitos. Porto Alegre: Sagah, 2020.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018.

UNIDADE 3

DICIO. Brainstorming. [2022]. Disponível em: https://www.dicio.com.br/brainstorming/. Aces-

so em: 17 jun. 2022.

REINEHR, S. Engenharia de Requisitos. Porto Alegre: Sagah, 2020.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018.

UNIDADE 4

FREITAS, J. A. de. Qualidade de Software. Maringá: Unicesumar, 2021.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software. 9. ed. Porto Alegre: AMGH, 2021.

REINEHR, S. Engenharia de Requisitos. Porto Alegre: Sagah, 2020.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018.

179
UNIDADE 5

CAPTERRA. Ferramentas para Levantamento de Requisitos. [2022]. Disponível em: ht-

tps://www.capterra.com.br/directory/10018/requirements-management/software. Acesso
em: 8 jul. 2022.

PROJECT MANAGEMENT INSTITUTE. Um Guia do Conjunto de Conhecimentos em Gerencia-

mento de Projetos (Guia PMBOK®). 5. ed. Newtown Square: PMI, 2013.

REINEHR, S. Engenharia de Requisitos. Porto Alegre: Sagah, 2020.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Prentice Hall, 2018.

180
UNIDADE 1

O Mapa Mental é de autoria do(a) aluno(a), portanto, ele(a) deverá fazer as associações
sugeridas.

UNIDADE 2

O Mapa da Empatia é de autoria do(a) aluno(a), portanto, ele(a) deverá fazer as associa-
ções sugeridas.

UNIDADE 3

1. B. Quando falamos em requisitos de software, durante a fase de levantamento de

requisitos, se faz necessário realizar a tarefa de priorizar qual requisito é mais impor-
tante. Isto se realiza junto com os stakeholders, ou seja, os interessados no sistema.

2. E. Alguns problemas podem surgir quando se usa a técnica de entrevista para elicitação
de requisitos: entrevistar a pessoa errada no momento errado, perdendo tempo na
coleta de requisitos; fazer perguntas erradas e obter respostas erradas; o usuário não
se sente à vontade, ou, até mesmo, se colocar em posição antagônica na entrevista,
porque acha que o objetivo do novo sistema é tomar o seu emprego; os usuários e os
analistas de sistemas têm vocabulários e experiências diferentes, então, é feita uma
pergunta ao usuário sobre os requisitos do sistema, e ele não a entende.

3. C. Sobre o brainstorming, durante a sua realização, é necessário garantir que os seus

integrantes tenham a mesma oportunidade de expor as ideias.

UNIDADE 4

Organize a ideia do seu Mapa Mental a partir das palavras-chave propostas. É uma forma
de você absorver e sintetizar os conceitos vistos nesta unidade. Recomendo o uso da
ferramenta gratuita GoConqr.

UNIDADE 5

Organize a ideia do seu Mapa Mental a partir das palavras-chave propostas. É uma forma
de você absorver e sintetizar os conceitos vistos nesta unidade. Recomendo o uso da
ferramenta gratuita GoConqr.

181