Inspeção, Especificação e Analise de Requisitos

Classificação, Especificação e
Gerenciamento de Requisitos
SENAI – DEPARTAMENTO REGIONAL
DE SANTA CATARINA
MANTENEDORA
Fabrizio Machado Pereira

Diretor Regional do SENAI/SC e Diretor de Charles Zanini Miranda
Educação e Tecnologia da FIESC Diretor do Campus Jaraguá do Sul
Adriana Paula Cassol Fabricio Roulin Bittencout

Gerente Executiva de Educação Diretor do Campus Florianópolis
Cleunisse Aparecida Rauen de Luca Canto Flavio Numata Junior

Gestão da Educação Superior Diretor do Campus Blumenau
MANTIDA Josiane Betat

Diretor do Campus Chapecó
Barbara Yadira Mellado Perez
Pro-Reitora de Ensino, Pesquisa e Extensão do Marcelo Teixeira dos Santos
Centro Universitário Diretor do Campus Joinville
Ana Luisa Mülbert Valério Junior Piana

Interlocutora para Projetos de Educação Digital Coordenador de Curso
CENTRO DE EDUCAÇÃO DIGITAL Roger Humphreys

Programação Web
Fabiano Bachmann
Bruno Rodrigues Magalhães
Gerente da Rede Digital
Flora Marre Bioni
Gisele Umbelino Gabriel Vieira
Coordenadora de Desenvolvimento de Gabriela da Silva Cândido
Recursos Digitais Isac Silva Pinto Diniz
Paulo Roberto Alves de Almeida
Hellen Cristine Geremia
Victória Vivian Formulo
Líder de Projeto
Produção Audiovisual
Gustavo Lucas Alves
Michele Antunes Corrêa
Analista de Educação Digital
Stephanie Johansen Longo Basso
Diego Martins Polla de Moraes Projeto Educacional
Autoria
Heliziane Barbosa
Pedro Sidnei Zanchett Janaina da Silveira Vieira
Revisor Técnico Juliana Tonietto
Projeto Webgráfico
Delma Cristiane Morari ________________________________________
Design Educacional
Airton Júlio Reiter
Heliziane Barbosa
Revisão ortográfica, gramatical e normalização
Design Gráfico
IStock Photo
Davi Leon Dias
Banco de Imagens
Ilustrações e Tratamento de Imagens
SUMÁRIO
Classificação, Especificação e Gerenciamento de Requisitos..............1
Para Iniciar.........................................................................................5
Estudo e Prática I: Classificação e especificações de requisitos.....7

E-book I..........................................................................................7
Classificação de requisitos........................................................9
E-book II........................................................................................37
Modelagem e especificação de requisitos...............................39
Videoflix.........................................................................................61
O que são histórias de usuário?................................................61
Histórias de usuário: cartão e conversação.............................61
Histórias de usuário: confirmação e critérios de aceite..........61
Infocast..........................................................................................63
Definition of Ready e Definition of Done...................................65
INVEST: construa histórias de usuário eficazes.......................67
Quero saber +................................................................................69
Resumindo.....................................................................................71
Estudo e Prática I: Gerenciamento de requisitos.............................73

E-book I..........................................................................................73
Gerenciamento de Requisitos...................................................75
Videoflix.........................................................................................87
Verificação e validação de requisitos de software...................87
Registro de aceite dos requisitos de software.........................87
Infocast..........................................................................................89
Conflitos entre partes interessadas: um desafio para a
engenharia de requisitos..........................................................91
Desenvolvimento de sistemas e legislação: a
responsabilidade dos profissionais de tecnologia...................93
Quero saber +................................................................................95
Resumindo.....................................................................................97
Para Concluir.....................................................................................99
Referências........................................................................................103
PARA INICIAR
Olá! Nesta videoaula, vamos explorar conceitos essenciais da Engenharia de

Requisitos relacionados à Classificação, à Especificação e ao Gerenciamento
de Requisitos, questões que desempenham papéis fundamentais no
desenvolvimento de software.
Nosso objetivo é proporcionar a você uma compreensão aprofundada e
abrangente das práticas fundamentais envolvidas nesse campo tão importante.
A Classificação de Requisitos desempenha um papel essencial na construção
de uma organização em relação às demandas das partes interessadas e garante
que todas as necessidades sejam atendidas de forma adequada. Através dos
resultados obtidos durante o processo de elicitação de requisitos de um software,
é necessário classificá-los e descrevê-los de forma clara e adequada. Isso nos
ajudará a entender melhor as necessidades e as expectativas dos envolvidos.
Avançando, abordaremos a Especificação de Requisitos, uma etapa vital no
ciclo de desenvolvimento de software. Existem diversas formas de se produzir
uma documentação de requisitos de um software, e é essencial conhecer cada
uma delas, para aplicá-las adequadamente nos diferentes tipos de projetos.
Por fim, exploraremos o Gerenciamento de Requisitos, que envolve
práticas e processos para garantir a consistência, a rastreabilidade e o controle
contínuo dos requisitos durante todo o ciclo de vida do software. Para construir
bons software com longa vida útil, devemos estar preparados para lidar com
mudanças e a evolução dos requisitos. O emprego de um processo formal de
controle de mudanças é fundamental, envolvendo avaliação, aprovação e
comunicação adequada de todas as alterações aos envolvidos.
Ao dominar esses conceitos e técnicas, você estará desenvolvendo
habilidades essenciais para o sucesso em projetos de desenvolvimento de
software. Esses estudos proporcionarão uma base sólida de conhecimento
teórico e prático, permitindo que você se torne proficiente na classificação, na
especificação e no gerenciamento de requisitos.
5
Por meio de conceitos, análises críticas e exemplos concretos, você
desenvolverá as capacidades essenciais para o sucesso em projetos de
desenvolvimento de software. Assim, você estará preparado para enfrentar
desafios reais no mundo profissional com confiança.
Estamos empolgados para compartilhar esse conhecimento com você e
acompanhá-lo nessa jornada rumo ao sucesso!
Vamos em frente!
6
ESTUDO E PRÁTICA I
CLASSIFICAÇÃO E ESPECIFICAÇÕES DE REQUISITOS
Requisitos são a base do desenvolvimento de software. Antes de selecionar

linguagem e tecnologias, é crucial compreender a proposta do software. Na
sequência, exploraremos classificação e especificação de requisitos para
garantir uma documentação sólida.
E-book I
Quando se trata do desenvolvimento de software,

é fundamental compreender, classificar e especificar
corretamente os requisitos do sistema. Ao dominar
esses conceitos, você estará apto a garantir que as
atividades de elicitação de requisitos sejam traduzidas
em uma documentação precisa e completa, servindo como
um guia para o desenvolvimento do software. Ao entender
o propósito do sistema e as necessidades dos usuários, você estará
no caminho certo para construir um software de qualidade, que atenda às
expectativas e supere as necessidades dos clientes.
A classificação de requisitos de software é uma técnica importante que ajuda
a organizar e categorizar os requisitos de um projeto de sistema. Existem várias
formas de classificar os requisitos, como por sua origem, por sua importância, por
sua natureza ou por sua prioridade. Uma classificação adequada dos requisitos
pode ajudar a equipe de desenvolvimento a compreender as necessidades dos
stakeholders, a priorizar os requisitos mais importantes, a avaliar a complexidade
do projeto e a gerenciar melhor o escopo do projeto. É importante lembrar que a
classificação dos requisitos deve ser atualizada e refinada ao longo do tempo, à
medida que o projeto evolui e novas necessidades surgem.
7
Classificação de requisitos
CLASSIFICAÇÃO DE REQUISITOS
Os requisitos desempenham um papel fundamental no sucesso do
desenvolvimento de software. Portanto, é crucial aprofundar o conhecimento
sobre requisitos para assegurar que eles atendam às necessidades das partes
interessadas no projeto. Isso engloba a compreensão da categorização
dos requisitos e das várias maneiras de descrevê-las, a fim de obter uma
compreensão mais precisa das demandas dos usuários, clientes e outras
partes envolvidas. Com uma abordagem cuidadosa e estruturada na gestão de
requisitos, é possível criar um software que satisfaça todas as expectativas e
exigências, resultando em um produto final de elevada qualidade.
Por essa razão, a compreensão dos requisitos é um elemento-chave para o
sucesso no desenvolvimento de software e pode ser alcançada por meio de uma
análise aprofundada, de refinamento constante e de envolvimento das partes
interessadas no processo. De acordo com Sommerville (2018, p. 85), os “[...]
requisitos de um sistema são as descrições dos serviços que o sistema deve
prestar e as restrições a sua operação.”
Veja que o autor se refere à necessidade de expressar tanto o que o sistema
deve fazer quanto o que ele não deve fazer. Além disso, o autor complementa
essa ideia ao diferenciar os requisitos em duas categorias: requisitos de usuário,
que são requisitos abstratos, declarados em linguagem natural e alto nível e os
requisitos de sistema, que devem conter uma descrição detalhada do que o
sistema deve oferecer ao usuário.
Outros autores acrescentam que os requisitos de usuário representam as
necessidades e as expectativas do usuário final do sistema ou software.
10 Classificação de requisitos
Esses requisitos podem ser obtidos através das mais diversas técnicas de
levantamento de requisitos e eles descrevem o que o usuário precisa que o
sistema faça e como ele deve se comportar para atender às suas necessidades
(WIEGERS; BEATTY, 2013). Essa abordagem permite considerar a diversidade de
usuários finais e suas demandas específicas.
Por outro lado, os requisitos de sistema são as características e
funcionalidades que o sistema deve ter para atender aos requisitos de usuário
e atingir seus objetivos. Eles são elaborados a partir dos requisitos de usuário e
levam em consideração as limitações tecnológicas, orçamentárias e de recursos
humanos. Os requisitos de sistema são, portanto, especificações técnicas, como
desempenho, confiabilidade, segurança e escalabilidade, que o sistema deve ter
para cumprir os requisitos de usuário (VALENTE, 2020). Os requisitos de sistema
são as peças que se juntam para criar um software coeso e operacional.
Resumidamente, os requisitos de usuário definem as necessidades do usuário

e como o sistema deve atender a elas, enquanto os requisitos de sistema
estabelecem as características técnicas que o sistema deve ter para cumprir
essas necessidades.
A distinção entre esses dois tipos de requisitos se dá devido ao viés e ao
nível de detalhamento em relação a eles. Os usuários estão mais focados
no seu resultado de negócio, enquanto os profissionais de tecnologia estão
empenhados em resolver os problemas de negócio dos usuários, assegurando
uma solução correta e adequada.
Classificação de requisitos 11
Para exemplificar melhor do que se trata essa diferença, serão
utilizados exemplos de requisitos relacionados a uma loja de
vestuário:
• Requisito de usuário: Os clientes devem ter a opção de escolher a
forma de pagamento mais conveniente para eles, incluindo cartão de
crédito, débito ou pagamento em dinheiro.
• Requisito de sistema: O sistema deve ser capaz de processar

pagamentos online de forma segura e confiável, integrando-se a
provedores de serviços de pagamento confiáveis.
Para tornar a descrição dos requisitos mais efetiva, é importante adequar

o nível de aprofundamento de acordo com o tipo de leitor e seu grau de
envolvimento no sistema. Em geral, os requisitos de usuário estão mais
relacionados aos gerentes do cliente, usuários finais do sistema, engenheiros
do cliente, gerentes da equipe contratada e arquitetos do sistema. Já os
requisitos de sistema são voltados principalmente a usuários finais do
sistema, engenheiros do cliente, arquitetos do sistema e desenvolvedores
(SOMMERVILLE, 2018).
Os requisitos de software são comumente divididos em duas categorias
principais:
• Requisitos funcionais: estão relacionados às funcionalidades que o software
deve apresentar e ao que ele deve fazer.
• Requisitos não funcionais: estão vinculados às características de qualidade

e arquiteturais do software, como desempenho, segurança, usabilidade e
escalabilidade, por exemplo.
Durante a etapa de levantamento de requisitos, a tradução dos resultados
obtidos por meio de diversas técnicas é fundamental para a construção de
uma relação clara e completa de requisitos funcionais e não funcionais.
Essa relação permite que os desenvolvedores compreendam com precisão o que
é esperado do sistema e ajuda a garantir que ele seja desenvolvido de acordo
com as expectativas das partes interessadas.
Além disso, a classificação dos requisitos em categorias ajuda a assegurar que
todas as necessidades importantes sejam consideradas e atendidas, evitando
confusões e ambiguidades em relação às expectativas do sistema. Com isso, é
possível aumentar a qualidade do software desenvolvido e evitar retrabalhos ou
insatisfações por parte dos usuários. Veja, na sequência, cada uma visão mais
detalhada de cada uma dessas categorias.
Requisitos funcionais
Os requisitos funcionais, conforme Sommerville (2018, p. 88), consistem
em “[...] declarações dos serviços que o sistema deve fornecer, do modo
como o sistema deve reagir a determinadas entradas e de como deve se
comportar em determinadas situações.” Durante o processo de definição dos
requisitos de um sistema, as necessidades específicas dos usuários devem ser
levadas em consideração, visando solucionar os problemas de negócio que os
usuários enfrentam.
De acordo com o autor, além de estabelecer os serviços a serem oferecidos,
um requisito funcional deve apresentar o comportamento esperado do sistema
em situações específicas, bem como explicitar o que o sistema não deve fazer.
Essa abordagem assegura que o sistema atenda às expectativas dos usuários e
ofereça a funcionalidade necessária para solucionar os problemas de negócio de
forma eficiente.
É de suma importância que os requisitos funcionais sejam rastreáveis e
testáveis, de modo a assegurar que o sistema seja desenvolvido conforme as
especificações e que suas funcionalidades operem adequadamente. Segundo o
IEEE (2017), a rastreabilidade dos requisitos desempenha um papel fundamental
no gerenciamento de mudanças e na garantia da qualidade do software.
“
A rastreabilidade de requisitos é a habilidade de identificar e registrar as
conexões entre diferentes requisitos, bem como entre requisitos e outros
elementos do projeto de software, como testes, casos de uso e código-fonte.
Segundo o IEEE (2017), a rastreabilidade de requisitos é definida como:
[...] a capacidade de rastrear a origem, o destino e o

status de cada requisito, assim como suas relações
com outros requisitos ao longo do ciclo de vida do
software.
Uma matriz de rastreabilidade, por exemplo, permite que um engenheiro

de requisitos represente as relações entre os requisitos, fornecendo uma visão
clara das dependências entre eles durante todo o ciclo de vida do software.
Isso auxilia os engenheiros de requisitos e a equipe de desenvolvimento a
garantir a consistência e o atendimento de todas as necessidades dos usuários
durante o processo de desenvolvimento. Uma forma simples de elaborar uma
matriz de rastreabilidade de requisitos é montar uma tabela em que as linhas
são os requisitos e as colunas também o são. Os requisitos que têm alguma
dependência, estarão marcados na célula correspondente, facilitando a análise e
o acompanhamento das inter-relações entre os requisitos. Veja o exemplo:
REQ. 01 REQ. 02 REQ. 03 REQ. 04 REQ. 05

REQ. 01 X
REQ. 02 X X
REQ. 03 X
REQ. 04 X X
Fonte: Do autor (2023)
Requisitos testáveis são requisitos de um software ou de um sistema

que podem ser verificados através de testes, ou seja, são características ou
funcionalidades que podem ser avaliadas e confirmadas por meio de uma
metodologia de testes adequada. Para que um requisito seja considerado
testável, ele precisa ser claro, específico e mensurável, além de estar livre de
ambiguidades e inconsistências. Isso significa que deve ser possível definir
critérios objetivos para avaliar se o requisito foi atendido ou não.
Para exemplificar a noção de requisitos funcionais, imagine um casal que deseja
comprar um carro para atender às necessidades de sua família. Para tal todas as
partes interessadas foram ouvidas, incluindo os pais e os filhos, resultando em
uma lista de requisitos funcionais para o veículo, que ficou da seguinte forma:
1. O veículo deve ter capacidade para transportar pelo menos cinco pessoas.
2. O veículo deve possuir airbags de segurança dos ocupantes em caso de
colisão.
3. O veículo deve possuir sistema de freios, para garantir a estabilidade do
carro em situações de frenagem brusca.
4. O veículo deve possuir sistema de ar-condicionado, para garantir o
conforto dos ocupantes em dias quentes.
5. O veículo deve possuir um porta-malas espaçoso, para acomodar as
bagagens da família em viagens.
6. O veículo deve ter um sistema de entretenimento que permita conectar
dispositivos móveis, para ouvir música ou assistir a vídeos.
7. O veículo deve ter um consumo de combustível razoável, para minimizar
os custos com abastecimento.
8. O veículo deve ser fácil de estacionar e manobrar em locais apertados,
como estacionamentos de supermercados.
Veja que, na lista, os requisitos foram especificados de acordo com as
necessidades repassadas pelas partes interessadas (neste caso a família),
apresentando um determinado nível de detalhe. Em alguns casos, há mais
especificidades, características, enquanto, em outros, as definições permanecem
mais abertas, como no segundo requisito, que determina a necessidade dos
airbags, mas não entra em detalhes sobre a sua posição ou quantidade.
O quinto requisito fala que precisa ter um porta-malas espaçoso. O que é
espaçoso para uma pessoa, é para outra também? Então, por que não detalhar?
Parece um pouco exagerado ter que detalhar tudo isso? Se não o fizer, podem
haver muitas dúvidas. Observe também que fica difícil referenciar cada requisito
mencionando apenas sua posição na lista, como primeiro, segundo, terceiro.
“
Wiegers e Beatty (2013) enfatizam a importância de documentar todos os
requisitos, mesmo aqueles que parecem óbvios, para garantir que eles sejam
compreendidos por todas as partes envolvidas no projeto. Eles afirmam que:
Embora possa parecer óbvio para você, não

assume que todos os outros compartilham o seu
conhecimento. Documente-o de qualquer maneira,
para que possa ser revisado e confirmado ou discutido.
Para ter um detalhamento melhor e uma melhor forma de identificação, é
apresentado uma reescrita dos requisitos do veículo.
RF01 - O veículo deve ter capacidade para transportar pelo menos

cinco pessoas e uma capacidade de carga de 400 kg.
RF02 - O veículo deve possuir airbags frontais e laterais para os

passageiros dos bancos da frente e traseiros, para segurança dos
ocupantes em caso de colisão.
RF03 - O veículo deve possuir sistema de freios com ABS e EBD, para
garantir a estabilidade do carro em situações de frenagem brusca.
RF04 - O veículo deve possuir sistema de ar condicionado digital, para

garantir o conforto dos ocupantes em dias quentes.
RF05 - O veículo deve possuir um porta-malas espaçoso com no

mínimo 480 litros de capacidade, para acomodar as bagagens da
família em viagens.
RF06 - O veículo deve ter um sistema de entretenimento que permita

conectar dispositivos móveis através de conexões P2 e Bluetooth,
para ouvir música ou assistir a vídeos.
RF07 - O veículo deve ter um consumo de combustível máximo 9 km/l

na cidade e 13 km/l na estrada com gasolina, para minimizar os custos
com abastecimento.
RF08 - O veículo deve ser fácil de estacionar e manobrar em locais

apertados, como estacionamentos de supermercados. Para isso, deve
ter um diâmetro de giro de no máximo 10,5 metros.
Note que, na lista, os requisitos foram especificados de acordo com as
necessidades relatadas pelas partes interessadas (a família), oferecendo um
determinado nível de detalhamento. Da mesma forma, as listas de requisitos
funcionais de sistemas a serem construídos também devem seguir esse padrão.
A lista inicial de requisitos é baseada no levantamento de informações e deve
ser continuamente refinada e revisada pelos engenheiros de requisitos e pelas
partes interessadas envolvidas.
Nesta nova lista de requisitos, um aspecto adicional foi incorporado: a
atribuição de uma identificação única para cada requisito, composta pela
sigla “RF” (para requisito funcional) e um número. Isso permite que os
requisitos sejam facilmente referenciados em reuniões, e-mails ou documentos
de alteração de escopo. A numeração também torna mais simples a classificação
dos requisitos por ordem de importância. Por exemplo, o engenheiro de
requisitos pode descrever facilmente que foi necessário alterar o RF21 para
incluir os detalhes discutidos na última reunião, e todos serão capazes de
identificar rapidamente o requisito em questão.
Agora que você compreendeu que os requisitos funcionais estão ligados
essencialmente à funcionalidade do veículo, acompanhe os requisitos funcionais
de um sistema de loja de conveniência em um posto de gasolina. Esses requisitos
descrevem as funcionalidades essenciais do sistema a serem desenvolvidos.
RF01: O sistema deve permitir o cadastro de produtos disponíveis na
loja de conveniência, incluindo descrição, preço e foto.
RF02: O sistema deve permitir o cadastro de fornecedores e produtos

disponíveis em cada fornecedor, para facilitar a gestão de estoque.
RF03: O sistema deve permitir a atualização automática do estoque de

produtos a partir das vendas realizadas no caixa.
RF04: O sistema deve permitir a criação de promoções de produtos com

desconto ou brindes para os clientes.
RF05: O sistema deve permitir a realização de vendas no caixa, com

opções de pagamento em dinheiro, cartão de crédito ou débito.
RF06: O sistema deve gerar um comprovante de venda para o cliente e

um comprovante de caixa para o funcionário responsável.
RF07: O sistema deve permitir a consulta de informações sobre vendas

realizadas em um determinado período, para fins de gestão e controle
financeiro.
RF08: O sistema deve permitir a criação de relatórios sobre vendas por

produto, fornecedor e período.
RF09: O sistema deve permitir a geração automática de pedidos de

reposição de estoque quando os níveis mínimos forem atingidos.
“
A qualidade dos requisitos de software é crítica para o sucesso do projeto,
conforme destacado por Pressman e Maxim (2021), que afirmam que
[...] a qualidade dos requisitos de software é um fator

crítico para o sucesso do projeto. Requisitos mal
definidos, incompletos ou inconsistentes são uma das
principais causas de fracasso de projetos de software.
Os requisitos funcionais são essenciais para o processo de desenvolvimento

de software, pois eles definem as funcionalidades e servem como base para
a implementação e teste do sistema. É crucial escrever requisitos funcionais
claros, precisos e detalhados, a fim de garantir que o projeto atenda às
expectativas dos stakeholders e tenha sucesso. Nesse sentido, seguir as boas
práticas é fundamental: envolver as partes interessadas, manter a clareza
e precisão dos requisitos, detalhar as funcionalidades de forma adequada,
priorizá-las e assegurar que os requisitos sejam testáveis. Tudo isso aumenta
significativamente as chances de sucesso do projeto de software.
Para ilustrar a importância dos requisitos de software em uma situação real,
imagine um cenário em que uma empresa de desenvolvimento de software foi
contratada por uma grande rede de supermercados para criar um sistema de
gerenciamento de estoque A equipe de desenvolvimento recebeu a tarefa de
criar um sistema que pudesse gerenciar o estoque dos produtos em todas as
lojas da rede e fornecer informações precisas em tempo real.
No início do projeto, a equipe de desenvolvimento trabalhou em

conjunto com os stakeholders para definir os requisitos funcionais e não
funcionais. No entanto, por falta de comunicação efetiva, muitos dos
requisitos foram mal compreendidos ou não foram especificados com
detalhes suficientes.
À medida que o projeto avançava, ficou cada vez mais evidente que
os requisitos não estavam claros e precisos. Por exemplo, a equipe
de desenvolvimento criou um sistema para rastrear as vendas dos
produtos em cada loja, mas o sistema não levou em consideração o
armazenamento e transporte desses produtos, o que resultou em
estoques inadequados e desalinhados entre as lojas.
O sistema também não considerou a complexidade do estoque de
produtos sazonais, levando a problemas na época de feriados ou eventos
especiais, quando a demanda por produtos específicos aumentava
significativamente.
Consequentemente, os gerentes de lojas estavam insatisfeitos com
o sistema de gerenciamento de estoque e a rede de supermercados
perdeu vendas e clientes por não ter produtos disponíveis nas
prateleiras. Após uma análise dos resultados do sistema, foi constatado
que muitos requisitos importantes foram mal definidos, incompletos ou
inconsistentes. A equipe de desenvolvimento percebeu que o fracasso
do projeto ocorreu, em grande parte, devido a falhas no processo de
definição de requisitos.
Por fim, a rede de supermercados precisou cancelar o projeto e buscar
outra empresa de desenvolvimento de software para criar um sistema de
gerenciamento de estoque mais eficiente e preciso.
Esse cenário mostra como requisitos bem definidos, claros e precisos são
fundamentais para o sucesso de projetos de software. A comunicação efetiva
entre a equipe de desenvolvimento e os stakeholders é essencial para garantir
que as necessidades e as expectativas sejam compreendidas e incorporadas
aos requisitos.
Uma maneira eficaz de realizar essa tarefa é revisar e atualizar os requisitos
de forma contínua, conforme o projeto avança. É importante envolver todas
as partes interessadas e os membros da equipe de desenvolvimento nesse
processo, a fim de garantir que as perspectivas e necessidades de todos sejam
consideradas e incorporadas aos requisitos. Dessa forma, é possível manter
a relevância dos requisitos funcionais e garantir que o software desenvolvido
atenda às expectativas do projeto.
Requisitos não funcionais
De acordo com Vazquez e Simões (2016), os requisitos não funcionais são
fundamentais para complementar a especificação do software. Enquanto
os requisitos funcionais definem o que o software deve fazer, os requisitos
não funcionais estabelecem os critérios para que ele funcione bem, ou seja,
desempenhe adequadamente suas funções. Ao determinar esses critérios, os
requisitos não funcionais estabelecem os níveis de serviço esperados para o
software.
Segundo o IEEE (2014), esses requisitos têm como objetivo restringir as
soluções a serem desenvolvidas. Essas restrições podem incluir requisitos
de desempenho, manutenção, segurança, confiabilidade, interoperabilidade,
entre outros tipos que estejam relacionados ao sistema como um todo e não a
uma funcionalidade específica. Esses requisitos também são conhecidos como
requisitos de qualidade.
Por sua vez, o IIBA (2011) define que os requisitos não funcionais estão
relacionados ao ambiente no qual o software deve operar. Esses requisitos
abrangem aspectos como desempenho, usabilidade, segurança, confiabilidade
e outros, e devem ser considerados para garantir que o sistema atenda às
expectativas dos usuários e do ambiente em que será utilizado. Em resumo,
os requisitos não funcionais são fundamentais para garantir a qualidade do
software desenvolvido e sua adequação ao ambiente no qual será utilizado.
Os requisitos não funcionais frequentemente possuem uma importância maior
em comparação aos requisitos funcionais (KERR, 2015). Destaca-se a importância
dos requisitos não funcionais para o bom funcionamento do software. Embora
um usuário comum possa, em muitos casos, lidar com falhas em requisitos
funcionais, a falta de um requisito não funcional essencial pode tornar o
sistema inoperável para o usuário. Portanto, é fundamental que os requisitos
não funcionais sejam considerados e atendidos durante o desenvolvimento do
software, garantindo sua eficácia e usabilidade para os usuários.
Um exemplo de requisito funcional que, se estiver inoperante, pode
permitir que o usuário realize o trabalho de outra forma. Por exemplo,
é a possibilidade de realizar a busca por um produto em uma loja
virtual. Se essa funcionalidade não estiver funcionando corretamente, o
usuário ainda pode navegar pelas categorias de produtos ou usar outras
ferramentas de pesquisa para encontrar o que deseja.
Já um exemplo de requisito não funcional que impede qualquer
atividade do usuário seria a disponibilidade do sistema. Se o sistema
não estiver disponível, o usuário não poderá realizar nenhuma atividade,
mesmo que seja capaz de contornar falhas em requisitos funcionais.
Por exemplo, se um site de comércio eletrônico estiver fora do ar, o
usuário não poderá navegar pelo site, fazer compras, visualizar produtos
ou realizar qualquer outra atividade. A indisponibilidade do sistema,
nesse caso, é um requisito não funcional crítico e que impede qualquer
atividade do usuário.
Os requisitos não funcionais podem ser mais difíceis de compreender e definir
“
do que os requisitos funcionais, especialmente para iniciantes em tecnologia. Isso
ocorre porque os requisitos não funcionais estão relacionados a aspectos como
desempenho, segurança, confiabilidade, usabilidade e outros fatores que podem
ser subjetivos e difíceis de quantificar. Vazquez e Simões (2016) afirmam que:
[...] embora não seja uma regra, uma característica

que costuma diferenciar os requisitos funcionais dos
não funcionais é que os não funcionais costumam
se manifestar de forma geral sobre o software, e os
funcionais de forma específica.
Além disso, os requisitos não funcionais podem ser mais técnicos e exigir
conhecimentos específicos, como arquitetura de sistemas, bancos de dados e
redes de computadores. Isso pode tornar difícil para um iniciante em tecnologia
compreender completamente esses requisitos.
Para ajudar a superar essa dificuldade, é importante que os iniciantes em
tecnologia estudem e se familiarizem com os diferentes tipos de requisitos não
funcionais e suas implicações no desenvolvimento do software. Eles também
podem buscar orientação e apoio de profissionais mais experientes, além de
utilizar ferramentas e recursos de gerenciamento de requisitos para facilitar a
identificação e a especificação desses requisitos.
Beatty and Wiegers (2013) destacam a importância dos requisitos não
funcionais, enfatizando a tendência de negligenciá-los devido à ênfase natural
na funcionalidade do produto. Eles ressaltam a necessidade de consultar os
clientes sobre as características de qualidade, como desempenho, usabilidade,
segurança e confiabilidade, além de documentar esses requisitos não funcionais
e seus critérios de aceitação com a máxima precisão possível.
De acordo com Sommerville (2018), os requisitos não funcionais podem ser
difíceis de serem identificados pelos clientes e usuários diretos de um sistema,
devido à necessidade de conhecimentos técnicos específicos. Alguns requisitos
não funcionais podem ser complexos e difíceis de entender, especialmente
para aqueles sem experiência em tecnologia. Nesse sentido, é recomendável
que o analista de requisitos envolva pessoal técnico da área de tecnologia da
organização demandante do software, que conheça a realidade da organização e
possa ajudar a identificar ou até mesmo determinar os requisitos não funcionais.
Atenção
Eles podem estar relacionados a diversas necessidades dos usuários,
tais como desempenho, segurança, usabilidade, confiabilidade,
escalabilidade, entre outros. Além disso, os requisitos não funcionais
podem estar associados a restrições orçamentárias, políticas
organizacionais e regulamentações externas, como a Lei Geral
de Proteção de Dados (LGPD) ou outras normas de segurança de
informação aplicáveis (SOMMERVILLE, 2018).
Segundo Somerville (2018), a tabela métricas para especificar requisitos

não funcionais pode ser empregada como uma maneira de iniciar a discussão
e aprofundar em vários aspectos a especificação de requisitos não funcionais.
Ao utilizar essa tabela, é possível descrevê-los quantitativamente, pois somente
desta forma poderão ser efetivamente validados.
MÉTRICAS PARA ESPECIFICAR REQUISITOS NÃO FUNCIONAIS

Propriedade Medida
Velocidade Transações processadas/segundo

Tempo de Resposta usuário/evento
Tempo de atualização da tela
Tamanho Megabytes
Número de chips de memória ROM
Facilidade de uso Tempo de treinamento
Número de quadros de Ajuda
Confiabilidade Tempo média para falha
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Disponibilidade
Robustez Tempo de reinicio após falha
Percentual de eventos que causam falha
Probabilidade de corrupção de dados em caso de falha
Portabilidade Percentual de declarações dependentes no sistema-alvo

Número de sistemas-alvo
Fonte: Adaptado de Sommerville (2018)
Agora que você percebeu que os requisitos não funcionais estão ligados a
questões gerais, de confiabilidade e de características gerais de um software,
acompanhe exemplos de requisitos não funcionais de um sistema de informação.
São exemplos de requisitos não funcionais de um sistema de uma conveniência
de um posto de gasolina:
RNF01 - Segurança: O sistema deve garantir a segurança das

informações dos clientes e do posto de gasolina, atendendo às leis e às
regulamentações aplicáveis.
RNF02 - Desempenho: O sistema deve ser capaz de lidar com um grande

número de transações simultâneas, sem prejudicar o desempenho.
RNF03 - Usabilidade: O sistema deve ser fácil de usar e ser intuitivo para
os usuários, independentemente de sua experiência com tecnologia.
RNF04 - Confiabilidade: O sistema deve ter uma alta confiabilidade,

para evitar falhas e interrupções no serviço.
RNF05 - Compatibilidade: O sistema deve ser compatível com

diferentes plataformas, dispositivos e navegadores.
RNF07 - Interoperabilidade: O sistema deve ser capaz de interoperar

com outros sistemas de gerenciamento do posto de gasolina, como
sistemas de pagamento eletrônico e de monitoramento de estoque.
RNF08 - Escalabilidade: O sistema deve ser capaz de crescer e se

adaptar às mudanças na demanda, sem prejudicar o desempenho ou a
confiabilidade.
RNF09 - Rastreabilidade: O sistema deve permitir o rastreamento de

transações, permitindo a identificação de problemas e a realização de
auditorias.
RNF10 - Disponibilidade: O sistema deve estar disponível para uso 24

horas por dia, 7 dias por semana, garantindo que os clientes possam
realizar transações a qualquer momento.
Ao analisar esta lista de requisitos não funcionais, é preciso ponderar que
muitos deles não são testáveis. O que é uma alta disponibilidade? O que é alto
para um contexto é alto para outro? Como ele deve interoperar com outros
sistemas? A seguir, será discutida e apresentada uma descrição mais detalhada
dos requisitos RNF02, RNF03, RNF04, RNF05 e RNF07, que permitam sua
testabilidade e mensurabilidade.
RNF02 - Desempenho: o sistema deve ser capaz de lidar com até 1.000
transações simultâneas, sem prejudicar o desempenho, que deve ser de
no máximo 2 segundos por transação.
RNF03 - Usabilidade: o sistema deve ser fácil de usar e intuitivo para

os usuários, independentemente de sua experiência com tecnologia.
Um usuário deve aprender a utilizar o sistema em até 1 hora de
treinamentos com vídeos, tutoriais e/ou apostilas.
RNF04 - Confiabilidade: o sistema deve ter uma alta confiabilidade

para evitar falhas e interrupções no serviço. Deve apresentar também
um tempo médio entre falhas (MTBF) de no mínimo 7 dias e um Tempo
médio de reparo (MTTR) de no máximo 2 horas.
RNF05 - Compatibilidade: o sistema deve ser compatível com

diferentes plataformas, dispositivos e navegadores, restritos às últimas
versões disponíveis em maio de 2023 dos navegadores Google Chrome,
Microsoft Edge, Safari e Opera.
RNF07 - Interoperabilidade: o sistema deve ser capaz de interoperar

com outros sistemas de gerenciamento do posto de gasolina, como
sistemas de pagamento eletrônico e de monitoramento de estoque,
através de WebServices ou APIs REST.
Os requisitos não funcionais possuem igual importância em relação aos
requisitos funcionais em um projeto de software, pois definem as características
do sistema, como sua performance, segurança, usabilidade, escalabilidade
e outros aspectos que afetam diretamente a experiência do usuário final.
Identificá-los e documentá-los desde o início do projeto é essencial para que
sejam incorporados na arquitetura e no design do sistema, garantindo sua
qualidade e a satisfação do usuário.
Atenção
Não entender direito os requisitos não funcionais podem causar muitos
problemas e consequências ruins para o projeto de software. Alguns desses
problemas incluem: o sistema não ter uma boa performance, não ser
seguro o suficiente, não ser fácil de usar, não conseguir crescer conforme o
número de usuários aumenta e ter dificuldades para manutenção.
Por isso, é importante que os requisitos não funcionais sejam bem definidos
desde o começo do projeto para garantir que o sistema tenha qualidade e
satisfaça as necessidades do usuário.
A inclusão dos requisitos não funcionais é crucial para prevenir problemas
futuros, como o aumento dos custos para correção de falhas ou a perda de
clientes devido a problemas de desempenho. Portanto, é essencial considerar
esses requisitos desde a fase de planejamento e monitorá-los durante todo o
processo de desenvolvimento, garantindo assim que o sistema final atenda
tanto às necessidades funcionais quanto às não funcionais. Em última análise, a
consideração dos requisitos não funcionais desempenha um papel fundamental
para o sucesso de um projeto de software.
Requisitos inversos ou restrições
Os requisitos inversos, também conhecidos como restrições, são condições
declaradas que impõem limitações a certos aspectos do sistema. Essas
restrições podem estar relacionadas tanto a aspectos funcionais quanto não
funcionais do software. Uma regra de negócio restritiva estabelece que certas
ações devem ser realizadas ou evitadas, ou que apenas determinadas pessoas
ou perfis têm permissão para executar tais ações. Em vez de descrever o que
o sistema deve fazer, os requisitos inversos, ou restrições, especificam o que o
sistema não pode fazer ou que limitações ele deve respeitar. Esses requisitos
são importantes para garantir que o sistema esteja em conformidade com as
políticas e normas relevantes, bem como para evitar problemas de desempenho
ou segurança que possam surgir se não houver restrições adequadas (WIEGERS;
BEATTY, 2013).
Um exemplo de restrição que pode ser vinculada a um requisito funcional é
o cenário de um aplicativo para facilitar a compra de passagens e a consulta
de horários e rotas. O requisito funcional seria permitir que os usuários
comprassem suas passagens através do aplicativo, enquanto a restrição para esse
requisito funcional poderia ser a necessidade de integração com um sistema de
processamento de pagamentos já existente na empresa que não permite o uso de
determinadas formas de pagamento (como o PIX, por exemplo).
Quando declaramos restrições vinculadas a requisitos não funcionais,
geralmente eles estão vinculados a aspectos de performance ou tecnologias,
como os exemplos a seguir:
• O tamanho do aplicativo não deve exceder 50 MB;
• O software deve utilizar apenas bibliotecas dependentes que tenham

licença open source;
• Nenhuma transação executada no software pode ultrapassar 20 segundos

de processamento.
Wiegers e Beatty (2013) ressaltam que as restrições transmitem implicações
diretas no desenvolvimento de software e devem ser consideradas, pois
apresentam, de forma complementar, aspectos relacionados à funcionalidade
do software, sejam funcionais – vinculadas ao negócio, ou não funcionais –
vinculadas a aspectos de ambiente computacional, tecnologia, desempenho,
segurança e confiabilidade.
Atenção
É essencial destacar que a atividade de identificação, definição e
especificação de requisitos é uma tarefa intelectualmente desafiadora,
que requer uma abordagem disciplinada e sistemática. Para lidar
com esses desafios, a revisão de requisitos é uma atividade crucial no
processo de engenharia de requisitos. Ela envolve a análise sistemática
dos requisitos para identificar e corrigir possíveis problemas. A revisão
de requisitos ajuda a garantir que os requisitos sejam compreendidos
corretamente, que sejam consistentes e completos e que atendam às
necessidades do cliente.
Segundo Pressman e Maxim (2021), a revisão de requisitos é uma atividade

crítica no processo de engenharia de requisitos e deve ser realizada por uma
equipe multidisciplinar, que inclui membros da equipe de desenvolvimento,
clientes e usuários finais. A revisão de requisitos deve ser conduzida em várias
etapas do processo de desenvolvimento, incluindo a elicitação de requisitos, a
análise e a especificação de requisitos e a validação de requisitos.
Durante a revisão, a equipe deve avaliar os requisitos quanto à sua clareza,
consistência, completude, verificabilidade e rastreabilidade. Isso envolve analisar
cada requisito para garantir que ele seja compreendido corretamente, que não
haja conflitos ou redundâncias com outros requisitos, além de ser verificado e
rastreado ao longo do processo de desenvolvimento do projeto.
A classificação de requisitos em funcionais e não funcionais é um processo
essencial na elaboração de um projeto de software. Como resultado dos
processos de elicitação de requisitos, eles precisam ser documentados de forma
adequada. Enquanto os requisitos funcionais descrevem as funcionalidades e
ações que o sistema deve realizar, os requisitos não funcionais especificam como
essas ações devem ser realizadas.
A distinção entre esses dois tipos de requisitos é muito importante, pois,
embora ambos sejam essenciais para o sucesso do projeto, as falhas nos
requisitos não funcionais podem ser mais graves e difíceis de corrigir, pois
englobarão o projeto como um todo. Os requisitos funcionais têm uma
tendência de serem mais fáceis de medir e testar, enquanto os requisitos não
funcionais tendem a ser mais subjetivos e difíceis de definir claramente. Por isso,
é fundamental que a equipe de desenvolvimento esteja atenta à definição e à
validação desses requisitos.
Atenção
A classificação de requisitos auxilia a equipe de desenvolvimento
a priorizar as funcionalidades do sistema, estabelecer metas de
desempenho e segurança, além de planejar os testes. Além disso, a
classificação de requisitos contribui para garantir que os objetivos do
projeto estejam alinhados às necessidades do cliente ou usuário final,
resultando em um produto final mais satisfatório e que atenda às
expectativas das partes interessadas.
Os requisitos funcionais definem o que o sistema deve fazer. Já os requisitos
não funcionais especificam como o sistema deve se comportar em termos
de estrutura, qualidade e desempenho. E, os requisitos inversos estabelecem
as restrições e limitações que o sistema deve obedecer. Ao considerar e
descrever adequadamente esses diferentes tipos de requisitos, as equipes de
desenvolvimento podem construir softwares que atendam às necessidades dos
usuários, cumpram os padrões de qualidade e garantam a conformidade com as
restrições estabelecidas.
REFERÊNCIAS
IEEE. Guide to the software engineering body of knowledge: SWEBOK. v. 3.0.

Nova Jersey, EUA: IEEE Computer Society, 2014.
IIBA. Um guia para o corpo de conhecimento de análise de negócios: guia
BABOK. versão 2.0. Toronto: Theiiba.org, 2011.
KERR, E. S. Gerenciamento de requisitos. São Paulo: Pearson, 2015.
PMI. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK. 6.
ed. EUA: Project Management Institute, 2017.
PRESSMAN, R.; MAXIM, B. R. Engenharia de software: uma abordagem profissional.
9. ed. Porto Alegre: Amgh, 2021.
SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson Education
do Brasil, 2018.
VALENTE, M. T. Engenharia de software moderna: princípios e práticas para
desenvolvimento de software com produtividade. São Paulo: Independente, 2020.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado ao
negócio. Rio de Janeiro: Brasport, 2016.
WIEGERS, K. E.; BEATTY, J. Software requirements. 3. ed. Novo México, EUA:
Microsoft Press, 2013.
E-book II
Este material explora a relevância da especificação de requisitos e fornece

diretrizes claras sobre como criar uma especificação detalhada de software. A
etapa de especificação de requisitos é considerada crítica no ciclo de vida do de-
senvolvimento de software, pois permite traduzir as necessidades e as expecta-
tivas dos usuários em requisitos documentados. São abordados conceitos funda-
mentais nesse processo, destacando a importância da clareza, da consistência e
da compreensão mútua entre as partes envolvidas.
Além disso, são apresentadas estratégias práticas para garantir a qualidade e a
consistência da especificação de requisitos. Ao estudar esse conteúdo, você será
capaz de elaborar uma especificação clara e precisa, proporcionando uma base
sólida para o sucesso do desenvolvimento de software e a satisfação dos usuários.
37
Modelagem e especificação de requisitos
MODELAGEM E ESPECIFICAÇÃO DE REQUISITOS
A documentação de software desempenha um papel essencial ao estabelecer
um contrato claro entre a equipe de desenvolvimento e as partes interessadas.
Nela são descritas as funcionalidades, as limitações, os requisitos e as
expectativas do software, permitindo que as partes concordem com o produto
final. Existem diferentes técnicas para especificar os requisitos. E, discutiremos
aqui como esses métodos podem contribuir para a qualidade do software.
De acordo com Sommerville (2018), a especificação de requisitos é o processo
formal de documentar os requisitos de usuário e de converter o sistema em um
documento, conhecido como “documento de requisitos”. Embora seja desejável
que esses requisitos sejam claros, precisos, completos e consistentes, alcançar
a perfeição é quase impossível na prática devido a diferentes interpretações dos
stakeholders e possíveis conflitos ou inconsistências entre os próprios requisitos.
Ao redigir uma especificação de requisitos, é importante garantir que todas as
partes interessadas tenham conhecimento do software, evitando o uso de jargões
e sem incluir detalhes da arquitetura. A especificação deve ser independente de
tecnologia, com foco nos aspectos de negócio (SOMMERVILLE, 2018).
A especificação dos requisitos do software pode ser utilizada como parte do

contrato para desenvolvimento do sistema e, por isso, deve contemplar uma
especificação completa e detalhada do sistema como um todo.
40 Modelagem e especificação de requisitos

Pressman e Maxim (2021) ressaltam que a especificação de requisitos
em linguagem natural é uma abordagem que utiliza uma linguagem clara e
compreensível para descrever os requisitos do software. Isso é feito com o
objetivo de tornar os requisitos mais acessíveis e compreensíveis para todas as
partes interessadas, incluindo desenvolvedores, gerentes de projeto e clientes.
A especificação de requisitos em linguagem natural é uma etapa importante
do processo de desenvolvimento de software, pois ajuda a garantir que todos
estejam alinhados quanto aos objetivos e às expectativas do projeto.
Para minimizar os conflitos de interpretação ao escrever requisitos utilizando
a linguagem natural, Sommerville (2018) apresenta recomendações relevantes
que valem ser consideradas nos projetos de software, tais como:
• É recomendado estabelecer um formato padrão e assegurar que

todas as definições de requisitos sigam esse formato. A padronização
ajuda a reduzir a probabilidade de omissões e facilita a verificação dos
requisitos. Sempre que possível, é aconselhável escrever os requisitos
em uma ou duas frases, no máximo.
• Evitar o uso de abreviações, siglas e jargões técnicos que possam
dificultar a compreensão do requisito pelos usuários e demais partes
interessadas.
• Especificar os requisitos em termos de comportamento do sistema,
em vez de especificar como o comportamento é implementado.
• Distinguir os requisitos obrigatórios dos desejáveis, utilizando-se dos
termos “deve” e “pode” respectivamente.
• Utilizar realces, como negrito, itálico e cores diferenciados, para
destacar ou separar partes importantes do requisito.
Modelagem e especificação de requisitos 41

De acordo com Pressman e Maxim (2021) e Valente (2020), é fundamental
seguir rigorosamente essas recomendações para evitar falhas comuns ao redigir
requisitos em linguagem natural, tais como:
• A falta de clareza nos requisitos, seja por vaguidade ou ambiguidade, pode
resultar em interpretações errôneas e soluções equivocadas.
• A falta de especificidade nos requisitos resulta em informações insuficientes

para a correta implementação do software.
• A falta de testabilidade nos requisitos dificulta sua garantia e validação,

pois requisitos que não podem ser facilmente testados ou verificados
representam um desafio.
• A falta de priorização dos requisitos dificulta a compreensão por parte dos

desenvolvedores daquilo que é mais importante para o usuário, uma vez que
não estão classificados em ordem de importância.
• A falta de consistência nos requisitos, seja por contradições ou inconsistências,

pode resultar em soluções confusas e problemas durante a implementação.
• A falta de rastreabilidade nos requisitos, ou seja, a ausência de vínculo com

objetivos ou necessidades específicas, pode torná-los desnecessários e
difíceis de justificar em caso de mudanças no projeto.
• A falta de completude nos requisitos, seja devido a requisitos faltantes ou

omissões, pode resultar em lacunas no software ou exigir retrabalho posterior.
• A falta de verificabilidade nos requisitos, ou seja, requisitos que não podem

ser testados ou validados por meio de técnicas apropriadas, torna difícil
confirmar se eles foram atendidos ou não.
• A falta de consistência com as restrições de projeto ocorre quando os

requisitos entram em conflito com limitações técnicas ou orçamentárias,
tornando sua implementação impossível.
• A falta de clareza nas responsabilidades dos requisitos, ou seja, quando não

é especificado de forma clara quem é responsável por sua implementação
ou manutenção, pode resultar em atrasos ou problemas de responsabilidade
no projeto.

Essas deficiências podem resultar em interpretações equivocadas,
complicações durante a implementação e dificuldades na validação dos
requisitos. Além disso, a utilização da linguagem natural traz consigo várias
armadilhas na redação dos requisitos.
A seguir, veja exemplos de situações comuns, consideradas inadequadas na
escrita de requisitos, ou seja, mal redigidas, e sugestões para aprimorá-las,
levando em conta as recomendações mencionadas, de acordo com Sommerville
(2018), Pressman e Maxim (2021) e o IEEE (1998).
• O sistema deve ser fácil de usar: Este requisito pode ser melhorado
especificando as tarefas que os usuários precisam realizar no sistema
e definindo os critérios de usabilidade, como o tempo necessário para
completar a tarefa ou a quantidade de cliques necessários.
• O software deve ser rápido: este requisito pode ser mais específico,
definindo quais funções do software precisam ser rápidas, como a resposta a
consultas de banco de dados ou a abertura de arquivos grandes.
• O sistema deve ter uma interface atraente e moderna: este requisito

pode ser mais testável e objetivo, especificando o uso de cores e fontes
específicas, ou o número máximo de cliques para acessar determinada
funcionalidade.
• O software deve ser fácil de instalar: este requisito pode ser mais
rastreável se especificar quais etapas do processo de instalação devem
ser simplificadas, como a configuração de parâmetros ou a escolha de
componentes opcionais.
• O sistema deve ser amigável para os usuários finais: este requisito pode
ser mais claro se especificar as características de amigabilidade mais
importantes para os usuários, como a disponibilidade de ajuda contextual
ou a personalização de menus.
• O preço do software não deve exceder o orçamento definido: este

requisito pode ser mais específico se definir um valor máximo ou um
intervalo de preços aceitáveis, ou ainda estabelecer critérios de avaliação
de custo-benefício.

• O sistema deve ser fácil de aprender: este requisito pode ser mais objetivo
se especificar as tarefas de usuário que precisam ser executadas e os
critérios de sucesso para a aprendizagem, como a quantidade de erros
permitidos ou o tempo máximo de treinamento.
• O software deve ser compatível com os sistemas operacionais

Windows, MacOS e Linux: este requisito pode ser mais rastreável se listar
explicitamente as versões mínimas suportadas de cada sistema operacional
e definir os critérios de compatibilidade a serem testados.
• O sistema deve ser seguro contra ataques externos e internos: este

requisito pode ser mais claro se listar as ameaças específicas que precisam
ser consideradas e os tipos de medidas de segurança que precisam ser
implementadas.
• O software deve ser fácil de atualizar e manter: este requisito pode ser
mais coeso se especificar quais funções do software precisam ser atualizadas
com mais frequência, quais ferramentas serão usadas para manter o software
e quais são as expectativas para a rapidez da manutenção.
De acordo com Wiegers e Beatty (2013), a especificação de requisitos tem

como objetivo documentar, de maneira consistente e acessível, os diferentes
tipos de requisitos, para que possam ser facilmente compreendidos pelo
público-alvo e revisados. É possível registrar os requisitos de negócios em um
documento de visão e escopo, enquanto os requisitos do usuário geralmente são
representados por casos de uso ou histórias de usuário. Os requisitos detalhados
de software, tanto funcionais quanto não funcionais, são registrados em uma
Especificação de Requisitos de Software ou em um repositório de gerenciamento
de requisitos.

Dica
Mesmo que o seu projeto não armazene os requisitos
em um formato de documento tradicional, é
importante lembrar de explorar e registrar os
diferentes tipos de informações de requisitos utilizando
um modelo adequado.
O documento de visão e escopo coleta os requisitos de negócios em

um único entregável que define o cenário para o subsequente trabalho de
desenvolvimento. Diferentes organizações podem criar documentos para
servir a um propósito semelhante, como o charter do projeto, o documento
de caso de negócios ou o documento de requisitos de mercado. O proprietário
do documento é o patrocinador executivo do projeto, a autoridade financeira
ou alguém em um papel semelhante. A entrada para os requisitos de negócios
deve vir de pessoas que têm uma compreensão clara do porquê do projeto.
Normalmente, o documento de visão e escopo segue um modelo específico, que
pode ser baseado no modelo proposto por Wiegers e Beatty (2013):
1 Requisitos de negócio
2 Escopo e limitações
3 Contexto de negócios
• Contexto • Principais características • Perfis das partes

• Oportunidade de negócios • Escopo da liberação interessadas
• Objetivo de negócios inicial • Prioridades do projeto
• Métricas de sucesso • Escopo dos • Considerações de
• Declaração de visão lançamentos sucessivos implantação
• Riscos de negócios • Limitações e exclusões
• Suposições e
dependências de negócios
Para ficar mais claro, será apresentado um exemplo de um documento

de visão da construção de um software para uma locadora de veículos. Esse
documento servirá como guia fundamental para o projeto, permitindo que
a equipe de desenvolvimento compreenda os requisitos de negócio e as
expectativas dos envolvidos no projeto.

Documento de visão - Sistema de Locadora de Veículos
1. Requisitos de negócio
Contexto: A Locadora de Veículos é uma empresa de grande porte que

possui 20 lojas espalhadas por todo o país. A empresa atua no mercado
há mais de 10 anos e tem como objetivo fornecer aos clientes serviços de
qualidade com preço justo.
Oportunidade de negócios: A oportunidade de negócio se baseia na
crescente demanda por serviços de locação de veículos, bem como na
necessidade de um sistema que possa integrar todas as lojas da empresa e
fornecer informações precisas e em tempo real.
Objetivo de negócios: O objetivo da Locadora de Veículos é fornecer
aos clientes um serviço de qualidade com preço justo, além de aumentar a
eficiência e produtividade da empresa através da utilização de um sistema
integrado.
Métricas de sucesso: Aumento de 20% no faturamento da empresa
após 1 ano de implantação do sistema. Redução de 30% no tempo de
atendimento ao cliente. Aumento de 50% na satisfação do cliente após a
implantação do sistema.
Declaração de visão: Nossa visão é sermos líderes no mercado de
locação de veículos, fornecendo um serviço de qualidade com preço justo
e com a utilização de tecnologia de ponta para aprimorar a experiência do
cliente.
Riscos de negócios: Concorrência forte no mercado de locação de
veículos. Instabilidade econômica do país. Falhas no sistema podem
afetar a imagem da empresa.
Suposições e dependências de negócios: A disponibilidade de
infraestrutura tecnológica para suportar o sistema. O suporte dos
funcionários da empresa para a implantação do sistema.

2. Escopo e limitações
O sistema será utilizado pelas 20 lojas da empresa e fornecerá
informações precisas e em tempo real sobre a disponibilidade de veículos,
reservas, devoluções, faturamento, entre outros. O sistema não irá incluir
serviços de manutenção e reparo dos veículos.
Principais características: Sistema integrado que permite o acesso
às informações em tempo real. Possibilidade de realizar reservas e
devoluções online. Disponibilidade de informações sobre a disponibilidade
de veículos em todas as lojas.
Escopo da liberação inicial: A primeira liberação do sistema irá
incluir as funcionalidades básicas de reserva, devolução, faturamento e
disponibilidade de veículos.
Escopo dos lançamentos sucessivos: Os lançamentos sucessivos irão
incluir funcionalidades adicionais, como relatórios gerenciais, integração
com sistemas de pagamento online e melhorias na interface do usuário.
Limitações e exclusões: O sistema não irá incluir serviços de
manutenção e reparo dos veículos.
3.Contexto de negócios
A Locadora de Veículos atende uma variedade de clientes, incluindo
turistas, executivos em viagem de negócios e clientes locais que precisam
de um veículo temporariamente.
Perfis das partes interessadas: Clientes da locadora: pessoas físicas ou
jurídicas que desejam alugar um veículo para fins diversos, como viagens
de lazer ou trabalho.
• Funcionários das lojas: equipe responsável por gerenciar a frota de
veículos e realizar o atendimento ao cliente nas 20 lojas da locadora.
• Equipe de manutenção: equipe responsável pela manutenção

preventiva e corretiva dos veículos da frota.
• Gestores da locadora: responsáveis pela administração geral da

empresa e pela tomada de decisões estratégicas.

• Fornecedores de veículos: empresas que fornecem os veículos para a
locadora.
• Concorrentes da indústria de locação de veículos: outras empresas

que atuam no mesmo mercado e que podem representar uma ameaça
ou oportunidade para a locadora.
• Órgãos regulatórios: órgãos governamentais responsáveis por

fiscalizar e regular o mercado de locação de veículos.
Prioridades do Projeto: O objetivo principal do projeto é melhorar a
experiência do cliente e aumentar a eficiência operacional da empresa. As
prioridades do projeto são:
• desenvolver um sistema de reserva online fácil de usar, permitindo
que os clientes encontrem o veículo certo para suas necessidades e o
reservem com antecedência;
• aumentar a eficiência operacional, incluindo a redução do tempo de

espera para os clientes durante o processo de check-in e check-out;
• oferecer uma plataforma unificada para gerenciar o inventário de

veículos e acompanhar as operações em todas as 20 lojas.
• implementar recursos de análise de dados para ajudar a empresa a

tomar decisões informadas e melhorar seus serviços.
Considerações de implantação: O sistema será implantado em todas

as 20 lojas da empresa, com treinamento adequado oferecido a todos os
funcionários relevantes. O sistema será acessível aos clientes por meio
de um site de reserva online e também estará disponível nas lojas para
reservas presenciais. O sistema deve ser compatível com os dispositivos
e navegadores mais comuns. Já a segurança dos dados dos clientes deve
receber uma atenção especial durante o processo de desenvolvimento
e implantação. A implantação será gradual, começando com a liberação
inicial e continuando com lançamentos sucessivos para aprimorar e
expandir as funcionalidades.

O documento de visão de um software é uma visão geral e de alto nível do
sistema, descrevendo sua finalidade, objetivos e principais funcionalidades.
Por outro lado, a especificação detalhada de requisitos é um documento mais
aprofundado que descreve de forma minuciosa e precisa cada requisito funcional
e não funcional do sistema.
A conexão entre esses dois documentos se dá pelo fato de que a especificação
detalhada de requisitos é derivada do documento de visão, detalhando e
expandindo cada aspecto descrito na visão geral. É por meio dessa conexão que
a equipe de desenvolvimento pode entender os requisitos específicos do sistema
e implementá-los de acordo com as expectativas e necessidades delineadas no
documento de visão.
A elaboração da especificação detalhada de requisitos desempenha um papel
fundamental no processo de desenvolvimento de um sistema, pois é por meio
dela que as expectativas e necessidades do usuário são claramente definidas e
compreendidas pela equipe de desenvolvimento. Nesse documento, devem ser
incluídos tanto os requisitos funcionais quanto os requisitos não funcionais do
sistema, garantindo que todas as especificações sejam abrangentes e precisas.
Essa etapa é essencial para o sucesso do projeto, pois serve como base para a
implementação do sistema de acordo com as necessidades e expectativas dos
usuários, como recomendado pelo IEEE (1998).
Uma especificação detalhada de requisitos, seguindo as orientações do IEEE1
(1998), deve incluir informações, tais como as apresentadas a seguir.
• Objetivos do sistema:
O que o sistema deve abranger e como deve atender às necessidades

do usuário.
• Requisitos funcionais:
As funcionalidades específicas que o sistema deve fornecer.

• Requisitos não funcionais:
Critérios de controle e estrutura, como desempenho, segurança,

usabilidade, disponibilidade, conformidade, integração e manutenibilidade.
• Restrições:
Quaisquer limitações ou restrições que possam afetar o projeto.
• Prioridades:
Quais são as funcionalidades e requisitos mais importantes e qual o grau

de prioridade de cada um.
• Prazos:
O cronograma previsto para o desenvolvimento do sistema e a entrega

das funcionalidades.
• Usuários:
Quem serão os usuários finais do sistema e como eles interagirão com ele.
• Ambiente:
O ambiente em que o sistema será executado, incluindo hardware,

software e requisitos de rede.

Com o objetivo de fornecer uma compreensão mais clara da estrutura de um
documento de especificação de requisitos, será apresentado, a seguir, um exemplo
de especificação de requisitos para o sistema de uma locadora de veículos.
Especificação de requisitos para Sistema de Locadora

de Veículos
Objetivos do sistema:
O objetivo do sistema é fornecer um serviço de aluguel de veículos em

uma rede de 20 lojas, permitindo que os clientes façam reservas, retirem
e devolvam os veículos de maneira eficiente e segura. O sistema também
deve permitir a administração de frotas, incluindo manutenção, registro de
danos e gerenciamento de contratos.
Requisitos funcionais:
O sistema deve fornecer as seguintes funcionalidades:

• registro e autenticação de usuários, incluindo clientes e funcionários
da locadora;
• gerenciamento de reservas de veículos, incluindo seleção de datas,

modelos de veículos e lojas de retirada e devolução;
• disponibilidade em tempo real de informações sobre a frota de

veículos, incluindo modelos disponíveis, preços e restrições de idade e
carteira de habilitação;
• processo de retirada de veículo seguro e eficiente, incluindo

verificações de segurança, inspeção do veículo e processamento
de pagamentos;

• processo de devolução de veículo eficiente, incluindo inspeção de
danos e processamento de pagamentos;
• gerenciamento de contratos de aluguel, incluindo cálculo de tarifas,

prazo de locação, cobrança de multas e taxas adicionais;
• registro de danos e manutenção de veículos, incluindo agendamento

de manutenção e rastreamento de reparos.
Requisitos não funcionais:
O sistema deve atender aos seguintes critérios de controle e estrutura:

• Desempenho: o sistema deve fornecer tempos de resposta rápidos e
gerenciar grandes volumes de dados com eficiência;
• Segurança: o sistema deve garantir a privacidade e a segurança dos

dados dos clientes e funcionários, incluindo medidas de segurança de
rede e autenticação de usuário;
• Usabilidade: o sistema deve ser fácil de usar e acessível a clientes e

funcionários com diferentes níveis de habilidade em tecnologia;
• Disponibilidade: o sistema deve estar disponível 24 horas por dia,

sete dias por semana, com manutenção programada agendada com
antecedência;
• Conformidade: o sistema deve cumprir as leis e regulamentações

aplicáveis, incluindo privacidade de dados e proteção do consumidor;
• Integração: o sistema deve se integrar com sistemas de contabilidade,

pagamento e gerenciamento de frotas existentes;
• Manutenibilidade: o sistema deve ser fácil de manter e atualizar, com

documentação clara e suporte técnico disponível.

Restrições:
O sistema deve cumprir as seguintes limitações:
• ser desenvolvido dentro do orçamento e prazo definidos;
• ser compatível com o hardware e software existentes na rede de lojas;
• ser escalável para acomodar o crescimento futuro da frota e dos

negócios da locadora.
Prioridades:
As prioridades das funcionalidades do sistema são as seguintes:
• Cadastro de veículos: o sistema deve permitir o cadastro de novos
veículos, incluindo informações como modelo, ano, placa e categoria.
Alta prioridade.
• Reservas: o sistema deve permitir aos clientes reservar um veículo

para data e hora específica. Alta prioridade.
• Locação: o sistema deve permitir que os clientes aluguem um veículo,

selecionando a loja e as datas de início e término da locação. Alta
prioridade.
• Devolução: o sistema deve permitir que os clientes registrem a

devolução de um veículo e incluam informações como quilometragem
e combustível. Média prioridade.
• Pagamento: o sistema deve permitir que os clientes paguem pelas

locações usando cartão de crédito ou débito. Média prioridade.
• Relatórios: o sistema deve gerar relatórios que mostrem a taxa de

ocupação dos veículos, os clientes que mais locaram veículos e as lojas
com mais locações. Baixa prioridade.

Usuários:
Os usuários do sistema serão os clientes da locadora, que poderão fazer

reservas, locações e devoluções de veículos. Os funcionários da locadora
também utilizarão o sistema para gerenciar o estoque de veículos,
reservas, locações e devoluções.
Ambiente:
O sistema será executado em uma infraestrutura de servidores em

nuvem, com capacidade de escalabilidade para lidar com o aumento de
demanda. O sistema será compatível com os principais navegadores web
e dispositivos móveis. Além disso, será integrado com os sistemas de
pagamento eletrônico disponíveis no mercado.
É importante destacar que um modelo de especificação de requisitos deve

ter a capacidade de se adaptar a diferentes tipos de sistemas, projetos e
necessidades dos usuários, conforme enfatizado por Sommerville (2018). Esse
modelo deve ser flexível o suficiente para acomodar mudanças nas necessidades
do projeto e permitir a inclusão de novos requisitos conforme necessário. Essa
abordagem flexível possibilita sua aplicação em uma variedade de projetos
de software, independentemente do tamanho ou complexidade. Além disso,
uma abordagem flexível também contribui para garantir que os requisitos
sejam suficientemente detalhados e precisos, orientando efetivamente o
desenvolvimento do sistema.
O modelo de especificação de requisitos deve apresentar flexibilidade ao
ser capaz de se adaptar às necessidades específicas de cada projeto. Essa
adaptabilidade permite ajustar o modelo de acordo com a complexidade do
sistema, o tamanho da equipe de desenvolvimento e outros fatores relevantes.
Além disso, o modelo pode ser aplicado em uma variedade de projetos de
software, independentemente de seu porte, abrangendo tanto projetos
complexos quanto mais simples.

A flexibilidade do modelo de especificação de requisitos traz benefícios
notáveis ao processo de desenvolvimento. À medida que o projeto avança, o
modelo pode ser facilmente atualizado para incorporar novas informações e
requisitos adicionais, garantindo que o sistema final seja entregue de forma
completa e alinhada com as necessidades. Além disso, a flexibilidade permite
que a equipe de desenvolvimento se adapte a mudanças no ambiente externo,
como expectativas do cliente e condições de mercado. Essa capacidade de
resposta possibilita ajustes no modelo para refletir as mudanças, assegurando
que o sistema final atenda às demandas em constante evolução.
Em suma, a flexibilidade do modelo de especificação de requisitos

promove um processo ágil e adaptável, resultando em um produto final
que atenda às expectativas e permaneça relevante no cenário atual.
Para aperfeiçoar o entendimento dos requisitos de um sistema, uma

estratégia que pode ser combinada com a especificação de requisitos é a
modelagem de requisitos. Uma das técnicas para se modelar requisitos muito
estudada pelos engenheiros de software é a criação de diagramas de casos de
uso UML (Unified Model Language), conforme destacado por Vicente (2020).
Alguns tipos de software podem requerer apenas a elaboração de histórias
de usuário como a única forma de modelagem de requisitos necessária. Em
contraste, outros podem exigir o desenvolvimento de casos de uso formais e
modelos baseados em classes. Os modelos baseados em classes representam
os objetos que o sistema irá manipular, as operações (também conhecidas
como métodos ou serviços) que serão aplicadas aos objetos para realizar
a manipulação, as relações (inclusive hierárquicas) entre os objetos e as
colaborações entre as classes definidas. Os métodos baseados em classes podem
ser utilizados para criar uma representação compreensível da aplicação para os
envolvidos que não possuem conhecimento técnico (PRESSMAN; MAXIM, 2021).

A atividade de modelagem de requisitos resulta na criação de diferentes tipos
de modelos, conforme discutido por Pressman e Maxim (2021), que podem
incluir os itens apresentados a seguir.
• Modelos baseados em cenários, que descrevem os requisitos do sistema a
partir da perspectiva de vários atores envolvidos.
• Modelos de classes, que representam as classes do sistema, incluindo seus

atributos e operações, além das interações entre as classes para atender aos
requisitos.
• Modelos comportamentais, que descrevem como o software responde a

eventos internos ou externos.
• Modelos de dados, que representam a estrutura e o domínio das

informações relacionadas ao problema.
• Modelos orientados a fluxos, que representam os elementos funcionais

do sistema e como eles transformam os dados à medida que fluem pelo
sistema.
Wiegers e Beatty (2013) citam que um caso de uso é uma representação das
interações entre um sistema e um ator externo, que resulta na capacidade do
ator alcançar um resultado de valor. É importante notar que os nomes dos casos
de uso seguem uma estrutura composta por um verbo seguido por um objeto.
Para garantir clareza e relevância, é recomendado escolher nomes descritivos e
impactantes, que evidenciem o valor proporcionado pelo caso de uso ao usuário
em questão.
Além disso, em sua obra, Wiegers e Beatty (2013) reforçam que a distinção
entre usuários e atores pode se tornar confusa. Eles propõem uma analogia
em que um usuário humano é comparado a alguém que possui uma coleção de
chapéus, cada um rotulado com o nome de um ator reconhecido pelo sistema.
Quando o usuário deseja realizar uma ação específica com o sistema, ele
“veste” o chapéu apropriado, e o sistema reconhece essa pessoa como o ator
correspondente ao chapéu utilizado.

Por exemplo, um químico que deseja solicitar um produto químico
“veste” o chapéu de “Solicitante”, e o sistema o identifica como tal,
independentemente de seu cargo real. Essa analogia de chapéus é uma
Na figura, a seguir, é possível verificar os mais variados casos de uso,

representados pelas elipses, onde um ator Recepcionista, representado por um
boneco palito, pode exercer em um sistema de atendimento a pacientes de uma
clínica médica.
Registrar paciente
Remover registro do paciente
Visualizar informações do paciente
Recepcionista
Transferir dados
Contatar paciente
Figura 1 - Casos de uso envolvendo o papel Recepcionista

Fonte: Sommerville (2018)

A modelagem e documentação de especificação de requisitos é o alicerce
para o sucesso do desenvolvimento de software. Ela é a garantia de que os
desenvolvedores compreenderão plenamente as necessidades dos usuários,
resultando em um software construído de forma precisa e que supera suas
expectativas. Além disso, a documentação evita problemas futuras, como
mudanças não planejadas no software ou conflitos entre as equipes. Não se deve
ignorar também o valor dessa documentação para equipes de manutenção e
suporte, proporcionando uma referência sólida para futuras melhorias e ajustes.
Portanto, investir tempo e esforço na criação de uma documentação completa
e precisa de requisitos é um passo indispensável rumo ao sucesso do seu projeto
de software (SOMMERVILLE, 2018).
Ao compreender a importância da especificação de requisitos, você é capaz de
definir com precisão o que um software deve fazer e como ele deve se comportar.
Com exemplos e orientações, o conteúdo oferece informações valiosas para a
construção de uma especificação detalhada de requisitos de software.

REFERÊNCIAS
IEEE. IEEE recommended practice for software requirements specifications.

IEEE Std 830-1998. New York: IEEE, 1998.
do Brasil, 2018.
VALENTE, M. T. Engenharia de software moderna: princípios e práticas para
desenvolvimento de software com produtividade. São Paulo: Editora Independente,
2020.

Videoflix
As histórias de usuário são uma poderosa ferramenta

utilizada por equipes que seguem os princípios do
desenvolvimento ágil para documentar software. Elas nos ajudam
a compreender as necessidades dos usuários e a criar soluções que
atendam estas necessidades. Podem ser utilizadas de forma combinada ao
processo de escrita de requisitos, ou de forma única, utilizando apenas as
histórias de usuário.
O que são histórias de usuário?
https://player.vimeo.com/
video/860951808?h=55c9a76bac
Histórias de usuário: cartão e conversação
video/860952607?h=1e650d029d
Histórias de usuário: confirmação e critérios de aceite
video/860954892?h=49914741c7
61
Infocast
Nestes podcasts, serão explorados conceitos importantes para o

desenvolvimento de software. No primeiro, são apresentados os conceitos de
Definition of Ready e o Definition of Done, que estabelecem critérios para
a preparação e conclusão de tarefas. No segundo, é discutido o INVEST, um
acrônimo para características essenciais de histórias de usuário. Ambos os
podcasts fornecem insights valiosos sobre como melhorar a qualidade do trabalho
e garantir a entrega de software satisfatório aos usuários.
63
Definition of Ready e
Definition of Done
Olá! Neste podcast, vamos falar sobre duas práticas muito importantes
utilizadas em projetos ágeis de desenvolvimento de software: Definition of
Ready e Definition of Done.
Antes de começarmos, é importante destacar que o objetivo do
desenvolvimento ágil é entregar um software de alta qualidade em um curto
espaço de tempo. Para alcançar esse objetivo, é necessário garantir que todos os
membros da equipe tenham uma compreensão clara do que é esperado deles e
quando cada tarefa será concluída.
É aí que entram as definições de prontidão (Definition of Ready) e de
conclusão (Definition of Done).
A Definição de Prontidão é um conjunto de critérios que uma tarefa ou
requisito precisa atender antes de ser considerado pronto para ser incluído
em uma iteração ou sprint e ser desenvolvido. Esses critérios podem abranger
aspectos como o detalhamento completo do requisito, validação com o cliente,
definição dos critérios de aceitação, entre outros.
Ao definir critérios claros para a prontidão de uma tarefa, a equipe garante
que todos os requisitos estejam completos e prontos para serem implementados
antes do início de uma iteração ou sprint. Isso evita interrupções no
desenvolvimento e permite que a equipe possa focar na implementação e na
entrega de valor ao cliente.
Já a Definição de Conclusão é um conjunto de critérios que uma tarefa ou
requisito deve atender para ser considerado concluído e entregue ao cliente.
Esses critérios podem incluir, por exemplo, testes automatizados, validação do
cliente, documentação completa, entre outros.
65
A Definição de Conclusão é essencial para garantir que o software entregue
atenda aos requisitos e às expectativas do cliente. Ao definir claramente os
critérios de conclusão, a equipe evita entregas incompletas ou com problemas,
garantindo a qualidade do produto final.
É importante destacar que tanto a Definição de Prontidão quanto a
Definição de Conclusão são revisadas e atualizadas continuamente durante
todo o processo de desenvolvimento. Elas são essenciais para o sucesso do
desenvolvimento ágil, pois garantem que todos na equipe trabalhem de forma
alinhada em busca do objetivo comum.
Concluindo, as Definições de Prontidão e de Conclusão são práticas
fundamentais para a entrega de software de alta qualidade em um curto espaço
de tempo. Ao definir critérios claros para a prontidão e a conclusão de cada
tarefa, a equipe garante que todos os requisitos sejam completos e entregues
ao cliente com qualidade. Lembre-se de revisar e atualizar essas definições
continuamente durante todo o processo de desenvolvimento para garantir que
todos estejam alinhados e trabalhando juntos em busca do sucesso do projeto.
Espero que este episódio tenha sido esclarecedor e útil para você.
Até a próxima!
66
INVEST: construa histórias de
usuário eficazes
Olá, você já ouviu falar do conceito INVEST em histórias de usuário? Se
não, prepare-se para descobrir como aplicar esse princípio para criar histórias
eficazes e impactantes. INVEST é um acrônimo apresentado por Wake (2003) e
que representa seis características essenciais que as histórias de usuário devem
possuir. Vamos conhecer cada uma delas e entender como podem melhorar o
processo de desenvolvimento de software.
A letra I faz referência à palavra independente. Uma história de usuário deve ser
independente, ou seja, ela deve ser autônoma e não depender de outras histórias
para ser implementada. Isso permite que a equipe de desenvolvimento trabalhe em
paralelo e priorize as histórias de acordo com o valor que cada uma entrega.
A letra N vem de negociável. As histórias de usuário devem ser negociáveis, ou
seja, flexíveis o suficiente para permitir discussões e ajustes entre a equipe e os
stakeholders. Essa negociação é fundamental para garantir que as necessidades
e expectativas de todos sejam atendidas.
A letra V vem de valiosa . Uma história de usuário deve agregar valor ao cliente
ou usuário final. Ela deve representar uma funcionalidade ou melhoria que seja
relevante e traga benefícios reais para o negócio. Ao manter o foco na entrega de
valor, podemos direcionar nossos esforços para aquilo que realmente importa.
A letra E de estimável. É importante que as histórias de usuário sejam
estimáveis, ou seja, seja possível estimar o tempo necessário para sua
implementação. Isso ajuda na definição de prazos, alocação de recursos e no
planejamento do projeto como um todo.
A letra S vem da palavra inglesa small, ou seja, pequena. Histórias de usuário
devem ser pequenas o suficiente para serem concluídas em um curto período de
tempo, geralmente em uma ou algumas iterações. Ao dividir as funcionalidades
em histórias menores, torna-se mais fácil acompanhar o progresso, obter
feedback e realizar ajustes conforme necessário.
67
A letra T vem de testável. Por fim, as histórias de usuário devem ser testáveis.
Isso significa que deve ser possível definir critérios claros de aceitação e criar
testes que comprovem que a funcionalidade foi implementada corretamente.
Testar as histórias é fundamental para garantir a qualidade do software e a
satisfação dos usuários.
Agora que você compreendeu o conceito INVEST, pode aplicá-lo ao criar
suas histórias de usuário. Lembre-se de torná-las independentes, negociáveis,
valiosas, estimáveis, pequenas e testáveis. Isso ajudará sua equipe a criar um
produto de alta qualidade, focado nas necessidades dos usuários e com um
processo de desenvolvimento mais eficiente.
Espero que esse conhecimento o inspire a aprimorar suas histórias de usuário
e a alcançar resultados ainda mais impactantes em seus projetos.
Até a próxima!
68
Quero saber +
Gostou do assunto? Você pode aprender ainda mais sobre Engenharia de

Requisitos buscando novos horizontes, sites, links, aplicativos e livros. Saiba mais
lendo e conferindo os materiais a seguir.
Requisitos funcionais e seus níveis de granularidade
Neste vídeo, da Fatto Consultoria e Sistemas, Guilherme Siqueira Simões

explica a granularidade dos requisitos e sua evolução ao longo do projeto.
https://youtu.be/WDNrLH7vwgQ
Infraestrutura e requisitos não funcionais
Neste vídeo, de Plínio Ventura, é discutida a relevante participação do

profissional de Infraestrutura de TI no Processo de Desenvolvimento de
Software, para auxiliar na definição de requisitos não funcionais.
https://youtu.be/VgTBe0-kYz4
69
Artigo Engenharia de Software 3: requisitos não funcionais
Este artigo, da Dev Media, apresenta uma visão sobre a importância dos
Requisitos Não Funcionais na construção da arquitetura de um software.
https://www.devmedia.com.br/artigo-engenharia-de-
software-3-requisitos-nao-funcionais/9525
Histórias de usuários com exemplos e template
Neste artigo, da Atlassian, são abordados os conceitos de histórias de usuário,

além de diversos exemplos que tornam mais fácil a compressão de como elas
funcionam na prática.
https://www.atlassian.com/br/agile/project-
management/user-stories
Personas e User Story Mapping: identificando o seu verdadeiro

público-alvo
Este artigo tem como propósito auxiliar na identificação do público-alvo

através do uso de Personas, bem como ensinar a contar histórias de usuários
por meio de um método altamente eficaz chamado User Story Mapping, que
se concentra no design centrado nos usuários.
https://www.devmedia.com.br/personas-e-user-story-
mapping-identificando-o-seu-verdadeiro-publico-
alvo/31699
70
Resumindo
Agora é o momento de conferir um resumo dos principais conhecimentos

estudados ao longo dessa jornada até aqui. Este resumo foi elaborado em formato
de checklist, para que você assinale os itens que considera já ter desenvolvido e,
caso sinta a necessidade, retome os estudos. Aproveite mais esta oportunidade de
construção de saberes.
Compreendi a importância de identificar tipos de requisitos.
Analisei as informações coletadas para definição de requisitos.
Registrei em documentos os resultados obtidos no levantamento de requisitos.
Entendi a importância de utilizar modelos de documentos flexíveis para os

registros de requisitos.
71
ESTUDO E PRÁTICA II
GERENCIAMENTO DE REQUISITOS
Gerenciar requisitos no desenvolvimento de software é desafiador devido

às mudanças inevitáveis. Aceite essa realidade para o sucesso do projeto, seja
flexível, esteja preparado para ajustes e entregue software que atenda às
necessidades em constante evolução dos usuários.
E-book I
O gerenciamento de requisitos é fundamental no

desenvolvimento de software, envolvendo a identificação,
a documentação e o controle dos requisitos do sistema.
Isso envolve o gerenciamento de mudanças para lidar com
alterações e a rastreabilidade para acompanhar a origem
e o status dos requisitos. Com um eficiente gerenciamento
eficiente, é possível garantir que o software atenda às
necessidades dos usuários, seja flexível às mudanças e alinhado com
os objetivos do projeto.
O gerenciamento de requisitos é necessário para garantir que os requisitos do
software sejam continuamente revisados e estejam sempre alinhados com as
expectativas das partes interessadas. Softwares não são produtos acabados, que
são construídos uma vez, entregues e nunca mais precisam de modificações. Eles
evoluem com as necessidades das partes interessadas que os utilizam. Para isso,
o gerenciamento de requisitos prevê atividades e processos que permitem que o
conjunto de requisitos de um software se mantenha consistente e atualizado.
73
Gerenciamento de requisitos
CONCEITOS DE GERENCIAMENTO DE REQUISITOS
O gerenciamento de requisitos é uma atividade essencial que percorre todo
o ciclo de vida do software, desde sua concepção até sua utilização contínua
em produção. À medida que o software é desenvolvido e disponibilizado aos
usuários, é natural que surjam necessidades de modificação e evolução. Nesse
contexto, o gerenciamento de requisitos desempenha um papel fundamental,
assegurando que as demandas dos usuários sejam atendidas e que o software
permaneça relevante e eficaz ao longo do tempo.
No decorrer deste material, exploraremos detalhadamente o que é o
gerenciamento de requisitos e sua importância. Durante a fase de levantamento
de necessidades e requisitos, lidamos com um sistema em seu estágio inicial,
em que ainda não existe um software implementado. No entanto, é importante
considerar que um software tem uma vida útil significativa, sendo utilizado
em produção por muitos anos, inclusive décadas. Essa longevidade ressalta a
importância de se lidar com as mudanças e alterações ao longo do ciclo de vida
do software, garantindo a eficiência e a eficácia das demandas da empresa por
meio do gerenciamento de requisitos.
Para Pressman e Maxim (2021), o gerenciamento de requisitos é um
conjunto de atividades que auxilia a equipe do projeto a identificar, controlar e
acompanhar as necessidades e suas mudanças à medida que o projeto acontece.
O SOFTEX (2016) apresenta em seu modelo de processo para desenvolvimento
de software, o MPS.BR, que os processos de engenharia de requisitos precisam
oferecer os seguintes resultados:
• O entendimento dos requisitos é obtido junto aos fornecedores.
• Os requisitos são avaliados com base em critérios objetivos e um

comprometimento da equipe técnica com estes requisitos.
• A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é

estabelecida e mantida.
• Revisões em planos e produtos de trabalho do projeto são realizadas visando

identificar e corrigir inconsistências em relação aos requisitos.
• Mudanças nos requisitos são gerenciadas ao longo do projeto.
76 Gerenciamento de requisitos
Os requisitos não são tão estáveis quanto gostaríamos, pois, os softwares
devem mudar na mesma medida que as organizações evoluem, ou, muitas
vezes, as evoluções das organizações são sustentadas por mudanças nos
softwares. Uma das características mais desejáveis em projetos de software
é que hajam componentes reutilizáveis. Construir sistemas que possam ter
partes reaproveitáveis é um grande fator competitivo na indústria de software.
É essencial entender que o retorno do investimento em software com partes
reutilizáveis pode não ser imediato. O custo para projetar um software que tenha
partes mais adaptáveis é maior e será absorvido conforme estas partes forem
sendo utilizadas (PRESSMAN; MAXIM, 2021).
Outro aspecto muito importante na construção de sistemas modernos é a
integração. Os sistemas precisam cobrir as operações das empresas de ponta
a ponta, além de ter sistemas que se integram facilmente é um dos desafios
que o gerenciamento de requisitos pode auxiliar. O gerenciamento de requisitos
permite que se conheça como cada requisito interage com o outro, facilitando a
construção de sistemas integrados (LAUDON; LAUDON, 2023).
Sommerville (2018) apresenta o conceito de compreensão modificada do
problema, que tem origem numa compreensão inicial do problema, que é
detalhada em requisitos iniciais e que gera requisitos modificados à medida que
o projeto evolui. Essa ideia pode ser visualizada na figura, a seguir.
Compreensão inicial Compreensão

do problema modificada do problema
Requisitos Requisitos
iniciais modificados
Tempo
Figura 2 - Compreensão modificada do problema no desenvolvimento de requisitos

Para exemplificar um caso de alteração de requisitos, vamos considerar uma

plataforma online de compras.
Gerenciamento de requisitos 77
A plataforma permite que os usuários comprem uma variedade de
produtos de diferentes lojas parceiras. Um requisito importante do sistema
é fornecer aos usuários a opção de filtrar os produtos por faixa de preço.
No entanto, após o lançamento da plataforma e à medida que o número
de lojas e produtos aumenta, a equipe de desenvolvimento percebe que o
filtro de faixa de preço atual não é suficientemente flexível para atender
às necessidades dos usuários. Os usuários expressaram frustração por não
poderem especificar intervalos de preço personalizados e por não terem
opções de filtro mais precisas.
Levando em consideração esse feedback, a equipe de desenvolvimento
decide revisar o requisito de sistema relacionado ao filtro de faixa de
preço. Eles planejam fazer a seguinte alteração:
Permitir que os usuários realizem filtros por faixas predefinidas de

ANTES preços de produtos, como “Menos de R$ 50”, “R$ 50 - R$ 100”, “R$
100 - R$ 200” etc.
Permitir que os usuários definam intervalos de preço personalizados,

DEPOIS inserindo o valor mínimo e máximo desejado.
Essa alteração no formato do filtro permitirá aos usuários ter maior

controle sobre o filtro de faixa de preço e atender às suas necessidades
específicas. A equipe de desenvolvimento terá que atualizar a interface do
usuário para incluir campos de entrada onde os usuários poderão inserir
os valores desejados para definir suas faixas personalizadas de preço.
Além disso, eles precisarão ajustar a lógica do sistema para lidar
com os novos valores de faixa de preço e garantir que os resultados de
pesquisa sejam exibidos corretamente de acordo com as preferências dos
usuários. A equipe também deve se certificar de que a alteração não afete
negativamente o desempenho do sistema e realizar testes abrangentes
para garantir a qualidade.
Após a implementação da alteração, a equipe acompanha o feedback
dos usuários para verificar se a nova funcionalidade atende às suas
expectativas e se é fácil de usar.
Nesse exemplo, um requisito de sistema é modificado com o objetivo de
melhorar a precisão e a flexibilidade do filtro de faixa de preço, proporcionando
aos usuários maior controle sobre suas preferências de compra.
Por que que acontecem mudanças em requisitos?

Mudanças em requisitos podem ocorrer por diversas razões. Primeiramente,
pode ter havido falta de clareza inicial dos fornecedores de requisitos, em
que os detalhes fornecidos pelas partes interessadas não foram suficientes
para extrair os requisitos de forma adequada. Outra possibilidade é falha no
levantamento de requisitos, com o envolvimento insuficiente de todas as partes
interessadas necessárias. Além disso, leis e fatores externos, como mudanças
na legislação, podem impactar o mercado e exigir alterações nos sistemas
(SOMMERVILLE, 2018).
Um exemplo é a publicação da lei da reforma trabalhista no Brasil, em 2017,
que permitiu o fracionamento das férias em três períodos. Até então, todos os
sistemas de folha de pagamento tinham uma regra para garantir que só podia
dividir as férias em duas partes, e com a nova lei trabalhista você pode dividir em
três partes, isso gerou muitas mudanças nos requisitos deste tipo de software.
Outro cenário é a necessidade de os novos requisitos para um sistema que
já foi concebido ou construído. Quando uma empresa amplia seus negócios,
amplia suas áreas de atuação, projeta negócios em outros mercados e tem novas
necessidades de ter itens considerados dentro de um sistema. Assim, podem
haver ajustes em requisitos definidos inicialmente, ou seja, requisitos que foram
criados lá no início do projeto que precisam ser melhorados, aperfeiçoados.
A prática de um sistema sendo usado no dia a dia é a melhor forma para
identificar se as definições foram feitas de acordo com as suas necessidades, o
que também pode gerar mudanças em requisitos. Além disso, em alguns casos, a
exclusão de um requisito pode ser necessária se ele não for mais relevante ou se
sua presença prejudicar o funcionamento do sistema.
Atenção
Para lidar com mudança ou exclusão de requisitos, é fundamental
manter versões da documentação.
Sommerville (2018) afirma que um processo formal de gerenciamento de

mudanças é necessário desde a criação da primeira versão do documento de
requisitos. No projeto, é necessário manter como o sistema era antes dessa
mudança, antes dessa exclusão de requisito e como ele ficará depois.
Ferramentas de gerenciamento de configuração, como o Gitlab, podem ajudar
a versionar estes documentos, permitindo o registro de histórico de operações e
a rotulação das versões. O próprio Google Docs permite que isso seja feito. Toda
a vez que um arquivo é salvo, ele registra o histórico dessas operações. Inclusive
é possível nomear estas versões, o que chamamos de rotular essas versões
dentro do conceito de gerência de configuração, ou seja, atribuir um nome para
cada versão do documento. Dessa forma, quando uma versão do software for
liberada, ela pode estar vinculada àquela versão do software.
Gerenciamento de mudanças em requisitos

O gerenciamento das mudanças em requisitos ocorre durante o processo de
levantamento de requisitos e desenvolvimento de sistema e não termina quando
entregamos o software em produção. Ele se estende ao longo de todo o ciclo de
vida do software. Para Sommerville (2018), é essencial definir um planejamento
do gerenciamento de requisitos, que deve conter:
Uma identificação única de cada requisito, um processo definido
de gerenciamento de mudanças, que envolve avaliação do custo e
impacto das mudanças, uma política de rastreabilidade, que define o
relacionamento entre requisitos e artefatos do sistema, e também que
ferramentas apoiarão esse processo.
Sommerville (2018), também afirma que todas as mudanças propostas para

os requisitos de um sistema após a aprovação dos requisitos devem passar por
um processo de gerenciamento de mudanças. Esse processo tem como entrada
o problema identificado e deve conter no mínimo as seguintes etapas:
Problema Requisitos
idenficado revisados
Análise do problema e Análise da mudança e Implementação
especificação da mudança estimativa de custo da mudança
Como saída deste processo, tem-se os requisitos envolvidos revisados.

Além disso, Wiegers e Beatty (2013) ressaltam a importância de utilizar um
conjunto comum de ferramentas baseadas na web para lidar com solicitações
de mudanças e rastrear questões em aberto. Mudanças sempre têm um preço.
Por isso, é vital utilizar práticas de gerenciamento de mudanças para controlar
o escopo do projeto em situações de desenvolvimento contratual. Identificar
os tomadores de decisão para as mudanças propostas e os mecanismos de
comunicação que serão utilizados para garantir que as pessoas certas sejam
mantidas informadas são medidas importantes no processo de gerenciamento
de mudanças em requisitos.
Alguns quesitos são essenciais para alcançar sucesso no trabalho com
gerenciamento de requisitos. Primeiramente, a identificação única de cada
requisito permite mencioná-lo, referenciá-lo e comunicá-lo de maneira mais
eficiente com todas as partes interessadas.
Num processo de gestão de mudança em que é necessário determinar
uma modificação em um requisito, é simples dizer: “estamos analisando a
alteração que foi solicitada, e o RF 003 será impactado devido à legislação X
que foi publicada nesse mês e tem vigência a partir de mês de agosto”, todos
conseguirão facilmente identificar de que requisito está se tratando.
Outro aspecto crucial é a rastreabilidade de requisitos, uma prática essencial
no processo de engenharia de requisitos. Ela permite que a avaliação do impacto
e dos custos das mudanças seja realizada de forma adequada. Essa prática
envolve o registro e o acompanhamento das inter-relações entre os requisitos
do sistema ao longo de todo o ciclo de vida do projeto. Visa a estabelecer uma
trilha auditável, que permite compreender como cada requisito foi originado,
evoluiu e foi implementado, fornecendo uma base sólida para o gerenciamento
de mudanças.
Uma das principais implicações da rastreabilidade de requisitos no processo
de gerenciamento de mudanças é fornecer uma visão clara das consequências
de uma alteração proposta nos requisitos.
Atenção
Quando um requisito é modificado, faz-se necessário identificar todos os
artefatos relacionados a ele, como documentos de especificação, casos
de teste, código-fonte e documentação do sistema. Essa identificação é
facilitada pela rastreabilidade de requisitos, pois permite a localização
rápida e precisa dos artefatos relacionados a um requisito específico.
A rastreabilidade de requisitos também ajuda a avaliar o impacto de uma

mudança nos requisitos em termos de tempo, custo e esforço. Ao rastrear as
relações entre os requisitos e outros elementos do sistema, é possível identificar
os componentes afetados pela mudança proposta. Isso permite uma análise
mais precisa dos recursos necessários para implementar a mudança e ajuda a
evitar a introdução de efeitos indesejáveis em outras partes do sistema.
Ao assegurar que os requisitos sejam claros, consistentes, testáveis e
mensuráveis, o gerenciamento de requisitos ajuda a evitar ambiguidades
e lacunas na compreensão entre as partes interessadas envolvidas no
projeto de software. Ele facilita a comunicação efetiva e a colaboração entre
desenvolvedores, testadores, analistas de negócios e usuários finais, resultando
em um entendimento comum dos objetivos e das funcionalidades desejadas.
Além disso, o gerenciamento de requisitos contribui para a rastreabilidade,
permitindo acompanhar as mudanças e o impacto dos requisitos ao longo do
tempo. Isso facilita o controle de versões, a gestão de mudanças e a tomada de
decisões informadas durante o desenvolvimento do software. A rastreabilidade
também é fundamental para garantir a conformidade com padrões,
regulamentações e requisitos legais aplicáveis.
O gerenciamento de requisitos é uma parte essencial do desenvolvimento de
software, garantindo que as necessidades dos usuários sejam adequadamente
identificadas, documentadas e atendidas. Ao longo do processo de
desenvolvimento, é essencial acompanhar e controlar as mudanças nos
requisitos, garantindo que o software final esteja alinhado com as expectativas
e objetivos do projeto. A rastreabilidade dos requisitos desempenha um papel
fundamental na compreensão das interdependências e no monitoramento do
progresso. Um gerenciamento eficaz de requisitos resulta em softwares de alta
qualidade, que atendem às necessidades dos usuários e proporcionam satisfação
e sucesso ao projeto como um todo.
REFERÊNCIAS
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais: administrando

a empresa digital. 17. ed. Porto Alegre: Bookman, 2023.
SOFTEX.MPS.BR - Melhoria de processo do software brasileiro: guia geral.
2016. Disponível em: https://www.softex.br/wp-content/uploads/2018/11/MPS.
BR_Guia_Geral_Software_2016-com-ISBN.pdf. Acesso em: 24 maio 2023.
do Brasil, 2018.
Videoflix
No desenvolvimento de software, a etapa de verificação e

de validação de requisitos desempenha um papel fundamental
para garantir a qualidade e o sucesso do projeto. O primeiro vídeo
aborda esse tema, explorando as práticas e as técnicas para verificar
se os requisitos estão corretos, consistentes e completos. A verificação é o
processo de revisar, inspecionar e analisar os requisitos, identificando possíveis
problemas, erros ou inconsistências. Já a validação envolve a avaliação dos
requisitos para garantir que eles atendam às necessidades dos usuários e aos
objetivos do projeto. No segundo vídeo, abordaremos o registro formal do aceite
dos requisitos validados. Esse registro é uma etapa importante para estabelecer
um acordo claro entre as partes interessadas, criando uma base sólida para o
desenvolvimento do software.
Verificação e validação de requisitos de software
video/860953236?h=5f0702ac68
Registro de aceite dos requisitos de software
video/860954056?h=78c3fd1413
87
Infocast
Nestes infocasts, exploramos os desafios enfrentados pelos analistas de requisitos

ao lidar com conflitos entre as partes interessadas e a legalidade do software
no processo de engenharia de requisitos de software. Abordamos as diferentes
expectativas, necessidades e objetivos das partes envolvidas e destacamos
a importância das habilidades de comunicação, negociação e resolução de
conflitos para garantir a satisfação de todas as partes interessadas. Discutimos a
responsabilidade do analista de requisitos em relação à legalidade do software
desenvolvido. Enfatizamos a importância de garantir que o software cumpra as leis e
os regulamentos aplicáveis.
89
Conflitos entre partes interessadas: um
desafio para a engenharia de requisitos
Olá, seja bem-vindo ao nosso podcast sobre conflitos entre partes
interessadas na Engenharia de Requisitos. Aqui vamos explorar os desafios
comuns que surgem quando diferentes partes interessadas estão envolvidas
no processo de engenharia de requisitos e como as habilidades do analista de
requisitos podem desempenhar um papel fundamental na resolução desses
conflitos. Vamos começar!
A engenharia de requisitos é um processo complexo que envolve a
identificação, a análise e a documentação das necessidades e das expectativas
das partes interessadas para o desenvolvimento de um software. No entanto,
nem sempre é fácil lidar com as diferentes perspectivas e prioridades das partes
envolvidas. Nesse cenário, o analista de requisitos desempenha um papel crucial
como facilitador e mediador. Suas habilidades técnicas e interpessoais são
fundamentais para lidar com conflitos e encontrar soluções que atendam aos
interesses de todas as partes envolvidas.
A primeira habilidade importante do analista de requisitos é a capacidade de
comunicação eficaz. Ele deve ser capaz de ouvir atentamente as preocupações
e necessidades de cada parte interessada, garantindo que todas as vozes sejam
ouvidas. Ao entender as diferentes perspectivas, o analista pode buscar pontos
de convergência e desenvolver requisitos que atendam às expectativas gerais.
Além disso, o analista de requisitos deve possuir habilidades de negociação.
Ele deve ser capaz de encontrar um equilíbrio entre as diversas demandas e os
interesses conflitantes, buscando soluções viáveis e aceitáveis para todas as
partes envolvidas. A capacidade de encontrar compromissos e facilitar acordos
é essencial para superar os obstáculos que surgem durante o processo de
engenharia de requisitos.
91
Outra habilidade-chave do analista de requisitos é a capacidade de
gerenciamento de conflitos. Conflitos são inevitáveis quando diferentes partes
interessadas têm prioridades e objetivos diferentes. O analista deve ser capaz
de identificar os conflitos, analisar suas causas e trabalhar junto com as
partes envolvidas para encontrar soluções satisfatórias. Isso pode envolver a
realização de reuniões de negociação, facilitação de discussões construtivas e
mediação de disputas.
Por fim, o analista de requisitos precisa ter uma visão abrangente do contexto
do projeto e das restrições envolvidas. Ele deve entender as limitações técnicas,
os prazos, o orçamento e outras restrições que possam impactar as decisões
relacionadas aos requisitos. Essa visão holística permite que o analista tome
decisões informadas, considerando não apenas as necessidades das partes
interessadas, mas também os objetivos do projeto como um todo.
Lembre-se de que a colaboração e o entendimento mútuo são essenciais para
superar os desafios e alcançar requisitos sólidos e eficazes. Ao desenvolver essas
habilidades, o analista de requisitos estará preparado para enfrentar os conflitos
de forma construtiva, promovendo uma melhor compreensão e o alinhamento
entre as partes interessadas.
E, assim, encerramos este tópico com a certeza de que compreender os
conflitos entre as partes interessadas na engenharia de requisitos é um passo
crucial para um desenvolvimento de software bem-sucedido. Esperamos que
você tenha encontrado insights valiosos e consiga aplicá-los em sua jornada
profissional. Até logo!
92
Desenvolvimento de sistemas e
legislação: a responsabilidade dos
profissionais de tecnologia
Olá! Aqui vamos discutir a importância de desenvolver sistemas em
conformidade com a legislação aplicável e destacar a responsabilidade dos
profissionais de TI, mais especificamente o analista de requisitos nesse aspecto.
Quando se trata do desenvolvimento de sistemas, é essencial ter em mente
que a legislação desempenha um papel fundamental. A legislação estabelece
regras e regulamentos que visam a proteger os direitos, os interesses e a
segurança das pessoas e das organizações envolvidas.
Nesse contexto, o profissional de tecnologia assume uma grande
responsabilidade. Ele é o responsável por desenvolver e implementar os
sistemas em conformidade com as leis e regulamentos pertinentes. Isso requer
atenção às legislações aplicáveis, bem como o compromisso de garantir que o
sistema atenda a esses requisitos legais.
A responsabilidade dos profissionais de TI vai além de simplesmente conhecer
as leis. Ele deve estar constantemente atualizado em relação às mudanças nas
regulamentações e garantir que os sistemas sejam adaptados e atualizados de
acordo. Essa responsabilidade exige um compromisso com a educação contínua
e o desenvolvimento profissional.
É importante abordar a questão de quando uma parte interessada solicita
algo que é ilegal em um sistema. Nesse cenário, o profissional enfrenta um
desafio ético e profissional.
Diante de uma solicitação ilegal por parte de um interessado, os profissionais
envolvidos devem agir com integridade e responsabilidade. Em primeiro lugar, é
importante compreender a natureza ilegal da solicitação e avaliar seu potencial
impacto. Isso pode envolver uma consulta a especialistas jurídicos ou buscar
orientação em relação à legislação pertinente.
93
O analista de requisitos deve comunicar claramente à parte interessada que
a solicitação é ilegal e não pode ser implementada no sistema. É importante
explicar as razões legais e éticas por trás dessa decisão, destacando os riscos
associados à não conformidade com a legislação. Em alguns casos, pode ser
necessário buscar o envolvimento da alta administração ou dos responsáveis
pela governança do projeto para resolver o conflito.
O analista de requisitos pode propor alternativas legais e éticas que atendam
aos interesses da parte interessada, mas dentro dos limites legais. É essencial
que o analista de requisitos mantenha registros claros e documente as
discussões e decisões relacionadas à solicitação ilegal. Essa documentação pode
ser necessária para fins de auditoria, conformidade legal e transparência nas
ações tomadas.
Em última análise, o analista de requisitos deve agir em conformidade com os
valores éticos e profissionais, colocando a legalidade e a integridade acima das
demandas individuais de uma parte interessada. A responsabilidade de garantir
a conformidade com a legislação recai sobre toda a equipe de desenvolvimento,
mas o analista de requisitos desempenha um papel fundamental ao identificar,
comunicar e buscar soluções dentro dos limites legais.
A ética profissional e o cumprimento da legislação são pilares essenciais
no trabalho do analista de requisitos. Ao tomar decisões difíceis em relação
a solicitações ilegais, o analista de requisitos contribui para a construção de
sistemas responsáveis e confiáveis.
Lembre-se sempre da importância de agir dentro dos limites legais e éticos
em seus projetos de desenvolvimento de sistemas. Até mais!
94
Quero saber +
Gostou do assunto? Você pode aprender ainda mais sobre Gerenciamento de

Requisitos, buscando novos horizontes, sites, links, aplicativos e livros. Saiba mais
lendo e conferindo os materiais a seguir.
Gerenciamento de requisitos sem mistério
Este vídeo, de Fabrício Laguna, traz uma explicação simples e didática

sobre o conceito de gerenciamento de requisitos, demonstrando como sua
aplicação pode contribuir para o sucesso dos projetos ao alcançarem seus
objetivos de maneira eficaz.
https://youtu.be/jajQyzOpLaE
Uma abordagem para gerência de requisitos em ecossistemas

de software
Neste artigo, é enfatizada a importância do gerenciamento de requisitos

em Ecossistemas de Software (ECOS) e é proposta uma abordagem
específica para lidar com os desafios desse contexto.
https://doi.org/10.5753/cbsoft_estendido.2021.17287
95
GenNormas: um processo genérico para a Conformidade Legal de
Requisitos na Engenharia de Requisitos
Este artigo destaca a importância da conformidade legal nos softwares de

uma organização e propõe o GenNormas, uma adaptação do framework
Nòmos, para relacionar requisitos e leis em várias linguagens de requisitos. O
GenNormas foi avaliado no comércio eletrônico para garantir o cumprimento
das normas jurídicas.
https://sol.sbc.org.br/journals/index.php/isys/article/
view/321
Engenharia de Requisitos: software orientado ao negócio
Leia o Capítulo 9 - Engenharia de Requisitos - Páginas 252 até 269 da

obra Engenharia de Requisitos - Software Orientado ao Negócio, de
Vazquez e Simões. Neste capítulo, você encontrará valiosos insights sobre
o gerenciamento de requisitos que irão aprofundar ainda mais o seu
entendimento sobre o assunto.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado

ao negócio. 1. ed. Rio de Janeiro: Brasport, 2016.
https://plataforma.bvirtual.com.br/Leitor/
Loader/160193/epub
96
Resumindo
Agora é o momento de conferir um resumo dos principais conhecimentos

estudados ao longo dessa jornada até aqui. Este resumo foi elaborado em formato
de checklist, para que você assinale os itens que considera já ter desenvolvido e,
caso sinta a necessidade, retome os estudos. Aproveite mais esta oportunidade de
construção de saberes.
Conheci os conceitos de gerenciamento de requisitos.
Aprendi a necessidade de rastrear requisitos.
Compreendi o processo de gerenciamento de mudança.
Entendi a importância de executar a verificação e a validação dos requisitos

do software.
Sei aplicar princípios éticos e seguir a legislação e as normas na validação

de requisitos.
97
PARA CONCLUIR
Parabéns! Você chegou ao final destes estudos. A seguir, explore o infográfico

que preparamos para você!
Ele traz os principais conceitos e definições que foram abordadas no decorrer de
toda essa importante jornada de construção de conhecimentos. Esse é um breve
resumo para você consultar sempre que sentir necessidade.
99
Classificação, Especificação e Gerenciamento
de Requisitos
Confira agora um resumo dos principais conceitos abordados e retome sempre que
sentir necessidade.
Requisitos funcionais
Descrição dos comportamentos e
funcionalidades que o sistema deve possuir.
Requisitos não funcionais

Especificação das características e
qualidades do sistema, além de seus
comportamentos.
Requisitos inversos
Restrições e limitações
impostas ao sistema.
Histórias de usuário
Narrativas que descrevem as
funcionalidades desejadas do
sistema sob a perspectiva do usuário.
Critérios de aceite de histórias de usuário

Critérios estabelecidos para determinar
se uma história de usuário foi
implementada corretamente.
Especificação detalhada de requisitos

Documentação que descreve
minuciosamente os requisitos do sistema.
Processo de identificação, documentação, verificação e
controle de requisitos durante todo o ciclo de vida do software.
101
Classificação, Especificação e Gerenciamento
de Requisitos
Confira agora um resumo dos principais conceitos abordados e retome sempre que
sentir necessidade.
Gestão de mudanças de requisitos

Processo de gerenciar alterações nos
requisitos ao longo do tempo, mantendo a
integridade e a rastreabilidade.
Processo de identificação, documentação,
verificação e controle de requisitos durante
todo o ciclo de vida do software.
Rastreabilidade de requisitos
Capacidade de acompanhar e documentar
as origens, a evolução e as inter-relações
dos requisitos ao longo do processo de
desenvolvimento do software.
102
REFERÊNCIAS
IEEE. Guide to the oftware engineering body of knowledge: SWEBOK v. 3.0.

Nova Jersey, EUA: IEEE Computer Society, 2014.
IIBA. Um guia para o corpo de conhecimento de análise de negócios: guia
BABOK. versão 2.0. Toronto: theiiba.org, 2011.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais: administrando
a empresa digital. 17. ed. Porto Alegre: Bookman, 2023.
KERR, E. S. Gerenciamento de requisitos. São Paulo: Pearson, 2015.
PMI. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK. 6.
ed. EUA: Project Management Institute, 2017.
SOFTEX. MPS.BR. Melhoria de processo do software brasileiro: guia geral.
2016. Disponível em: https://www.softex.br/wp-content/uploads/2018/11/MPS.
BR_Guia_Geral_Software_2016-com-ISBN.pdf. Acesso em: 24 maio 2023.
do Brasil, 2018.
WAKE, B. INVEST in Good Stories, and SMART Tasks. 2003. Disponível em:
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/. Acesso em:
14 jun. 2023.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado ao
negócio. Rio de Janeiro: Brasport, 2016.
103

Inspeção, Especificação e Analise de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Inspeção, Especificação e Analise de Requisitos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Inspeção, Especificação e Analise de Requisitos

Enviado por

Direitos autorais:

Formatos disponíveis

Classificação, Especificação e

Fabrizio Machado Pereira

Adriana Paula Cassol Fabricio Roulin Bittencout

Cleunisse Aparecida Rauen de Luca Canto Flavio Numata Junior

MANTIDA Josiane Betat

Ana Luisa Mülbert Valério Junior Piana

CENTRO DE EDUCAÇÃO DIGITAL Roger Humphreys

Estudo e Prática I: Classificação e especificações de requisitos.....7

Estudo e Prática I: Gerenciamento de requisitos.............................73

Olá! Nesta videoaula, vamos explorar conceitos essenciais da Engenharia de

Requisitos são a base do desenvolvimento de software. Antes de selecionar

Quando se trata do desenvolvimento de software,

Resumidamente, os requisitos de usuário definem as necessidades do usuário

• Requisito de sistema: O sistema deve ser capaz de processar

Para tornar a descrição dos requisitos mais efetiva, é importante adequar

• Requisitos não funcionais: estão vinculados às características de qualidade

[...] a capacidade de rastrear a origem, o destino e o

Uma matriz de rastreabilidade, por exemplo, permite que um engenheiro

REQ. 01 REQ. 02 REQ. 03 REQ. 04 REQ. 05

Fonte: Do autor (2023)

Requisitos testáveis são requisitos de um software ou de um sistema

Embora possa parecer óbvio para você, não

RF01 - O veículo deve ter capacidade para transportar pelo menos

RF02 - O veículo deve possuir airbags frontais e laterais para os

RF04 - O veículo deve possuir sistema de ar condicionado digital, para

RF05 - O veículo deve possuir um porta-malas espaçoso com no

RF06 - O veículo deve ter um sistema de entretenimento que permita

RF07 - O veículo deve ter um consumo de combustível máximo 9 km/l

RF08 - O veículo deve ser fácil de estacionar e manobrar em locais

RF02: O sistema deve permitir o cadastro de fornecedores e produtos

RF03: O sistema deve permitir a atualização automática do estoque de

RF04: O sistema deve permitir a criação de promoções de produtos com

RF05: O sistema deve permitir a realização de vendas no caixa, com

RF06: O sistema deve gerar um comprovante de venda para o cliente e

RF07: O sistema deve permitir a consulta de informações sobre vendas

RF08: O sistema deve permitir a criação de relatórios sobre vendas por

RF09: O sistema deve permitir a geração automática de pedidos de

[...] a qualidade dos requisitos de software é um fator

Os requisitos funcionais são essenciais para o processo de desenvolvimento

No início do projeto, a equipe de desenvolvimento trabalhou em

Os requisitos não funcionais podem ser mais difíceis de compreender e definir

[...] embora não seja uma regra, uma característica

Segundo Somerville (2018), a tabela métricas para especificar requisitos

MÉTRICAS PARA ESPECIFICAR REQUISITOS NÃO FUNCIONAIS

Velocidade Transações processadas/segundo

Portabilidade Percentual de declarações dependentes no sistema-alvo

Fonte: Adaptado de Sommerville (2018)

RNF01 - Segurança: O sistema deve garantir a segurança das

RNF02 - Desempenho: O sistema deve ser capaz de lidar com um grande

RNF04 - Confiabilidade: O sistema deve ter uma alta confiabilidade,

RNF05 - Compatibilidade: O sistema deve ser compatível com

RNF07 - Interoperabilidade: O sistema deve ser capaz de interoperar

RNF08 - Escalabilidade: O sistema deve ser capaz de crescer e se

RNF09 - Rastreabilidade: O sistema deve permitir o rastreamento de

RNF10 - Disponibilidade: O sistema deve estar disponível para uso 24

RNF03 - Usabilidade: o sistema deve ser fácil de usar e intuitivo para

RNF04 - Confiabilidade: o sistema deve ter uma alta confiabilidade

RNF05 - Compatibilidade: o sistema deve ser compatível com

RNF07 - Interoperabilidade: o sistema deve ser capaz de interoperar