Engenharia de Requisitos

em Contextos Ágeis

Vinicius Carvalho

1
Este material faz parte do livro “Engenharia de Requisitos” e está disponível na disciplina
de mesmo nome em nossa Pós-graduação em Engenharia de Software com Ênfase em
Qualidade e Testes de Software. Foi escrito pelo nosso professor Vinicius Carvalho. Você
pode saber mais sobre a pós entrando em contato por e-mail: contato@uniciv.com.br ou
telefone: 0800 006 4224

2
Sumário

PREFÁCIO ...................................................................................................................................... 4
Sobre o livro .............................................................................................................................. 5
INTRODUÇÃO ................................................................................................................................ 6
UNIDADE I: Introdução a Engenharia de Requisitos ................................................................... 7
Modelo Tradicional. O mais famoso, Cascata! ........................................................................ 8
Modelo Ágil............................................................................................................................. 10
O que pode ser considerado um requisito ............................................................................ 12
O engenheiro de requisitos. Quem são da onde vem o que fazem ...................................... 13
Sou desenvolvedor, mas será que estou me tornando analista? ..................................... 15
O Mercado .......................................................................................................................... 15
Certificação de engenharia de requisitos .......................................................................... 16
UNIDADE II: Processos da engenharia de requisitos ................................................................. 17
Concepção ............................................................................................................................... 18
Planejamento.......................................................................................................................... 19
Elicitação ................................................................................................................................. 20
Técnicas de elicitação ......................................................................................................... 21
Prototipação ........................................................................................................................... 21
Documentação ........................................................................................................................ 23
Markdown........................................................................................................................... 24
Requisitos Funcionais e Não Funcionais ................................................................................ 26
Requisitos funcionais .......................................................................................................... 26
Requisitos não funcionais .................................................................................................. 27
Como descrever os requisitos ................................................................................................ 28
Histórias de usuários .......................................................................................................... 28
Critérios de aceitação ......................................................................................................... 29
Outra estrutura de documentação ........................................................................................ 31
Gerenciamento dos requisitos ................................................................................................... 36

3
PREFÁCIO

Raramente eu vejo alguém saindo da faculdade dizendo que deseja ser

analista de negócios, engenheiro de requisitos, product owner ou product
manager. Quando entrei no mercado de trabalho como desenvolvedor
ainda era muito raro conhecer um especialista em requisitos em um projeto
de desenvolvimento de software. Até hoje, aqui no Brasil, há poucas
publicações falando sobre esse assunto que direcione os profissionais. Há
até um grande desconhecimento dos profissionais da área de
desenvolvimento de software sobre essas funções.

Aqui no Brasil, ainda tem muito a cultura das empresas apenas vender o
desenvolvimento de software sem análise e muitos projetos até sem testes.
Essas duas etapas são bastante lembradas quando os projetos dão
problema e prejuízo.

Este livro é para profissionais que queiram se aventurar no mundo da

engenharia de requisitos / análise de requisitos e desejam conhecem as
boas práticas e como aplicar no dia a dia. Também para profissionais que já
atuam na área e desejam se aperfeiçoar. E também para devs, testers, gps
e qualquer outra função.

Além de compartilhar meu conhecimento sobre o assunto, eu espero que

outros profissionais conheçam quais são as funções desse profissional e
como a análise, especificação e gerenciamento de requisitos podem
contribuir para os projetos.

4
Sobre o livro

Durante os capítulos irei introduzir assuntos referente as atividades de um

engenheiro de requisitos e o seu processo de trabalho. Cada capítulo irei
apresentar o que será visto e como é aplicativo no processo de engenharia
de requisitos.

No primeiro capítulo 1 você irá ter uma introdução sobre engenharia de

requisitos, a função e perfil dos engenheiros de requisitos e também
conhecer um pouco do mercado. No capítulo 2 você irá conhecer como é o
processo de engenharia de requisitos e como escrever requisitos. O
restante do livro está disponível em nossa pós-graduação em Engenharia
de Software com Ênfase em Qualidade e Teste de Software.

5
INTRODUÇÃO

Neste livro trouxe os processos e as atividades de um engenheiro de

requisitos em um projeto de desenvolvimento de software. Como já dizia
Frederick P. Brooks, Jr., não existe bala de prata no desenvolvimento de
software, isto é, não existe uma técnica única que irá resolver todos seus
problemas de software. Com esses processos e ferramentas você poderá
adapta-las para a sua realidade. Seja para um projeto simples ou para um
projeto complexo. Tentei trazer para este livro os conceitos da engenharia
de requisitos de forma bem prática e como pode ser aplicada no dia a dia.
Com base nas minhas experiências trabalhando com engenharia de
requisitos, tentei mostrar as situações que esses conceitos podem ser
aplicados.

6
UNIDADE I: Introdução a Engenharia de Requisitos

"Algumas pessoas não gostam de mudanças, mas você precisa abraçar a mudança se a alternativa for
desastre"
— Elon Musk

Seja um aplicativo ou software que funcionalidades complexas, ambos são

compostos de requisitos. Estes funcionais e não funcionais. Requisitos são
as necessidades que o sistema tem para existir. Estas necessidades podem
ser levantadas através de solicitações, desejos ou até mesmo por exigências
de uma lei, por exemplo.

Segundo a IEEE, as definições de requisitos são:

I - Uma condição ou capacidade necessária por um usuário para

resolver um problema ou alcançar um objetivo;

II - Uma condição ou capacidade que deve ser atingida ou possuída

por um sistema ou componente de um sistema para satisfazer um
contrato, padrão, especificação ou outro documento formalmente
imposto;

III - Uma representação documentada de uma condição ou

capacidade como (I) ou (II).

Com essas definições em mente e analisando a figura abaixo, podemos

visualizar a existência de requisitos de negócio, que é o porquê que um
sistema deverá ser desenvolvido. A partir desses requisitos os usuários que
utilizaram o sistema terão suas necessidades e expectativas sobre o projeto
que será desenvolvido. Esses dois requisitos geram os requisitos do sistema,
que são os requisitos de como o sistema deverá se comportar para atender
os requisitos de negócios e dos usuários.

7
 Figura 1 Tipos de requisitos

Esses requisitos de software podem ser do tipo Funcional e Não Funcional.

Iremos nos aprofundar nesses dois tipos de requisitos no capítulo 2.

Modelo Tradicional. O mais famoso, Cascata!

O modelo desenvolvimento de software mais utilizado ainda no mundo,

que é comumente conhecido como o modelo “tradicional” ou seu nome
oficial Waterfall.

Figura 2 Modelo de desenvolvimento de software waterfall

Neste modelo temos fases bem definidas durante o processo de

desenvolvimento de software. Na fase de Planejamento é realizado a
documentação do projeto inteiro.
8
Neste modelo figura do analista de requisitos ou engenheiro de requisitos
é entender todas as necessidades do cliente, transformar em requisitos,
enviar para os desenvolvedores. E depois com software pronto como estava
descrito nos requisitos é entregue ao cliente, como mostra a figura abaixo.

Figura 3 Modelo de análise no modelo tradicional

Esse modelo ainda é bastante utilizado e em alguns cenários funciona muito

bem. Mas, ele funciona melhor quando os requisitos, aqueles que mostrei
anteriormente (principalmente os requisitos de negócios), são bem
conhecidos por todos os envolvidos no projeto e o engenheiro consegue
colocar de forma claro na documentação.

Mas o maior grande problema deste tipo de modelo em relação a análise

de requisitos, é que se se passa muito tempo desde a documentação até o
software ficar pronto. Alguns requisitos e necessidades dos usuários podem
mudar nesse meio tempo. E as falhas de análise só são vistas com todo o
software já desenvolvido. E o custo para realizar uma alteração se torna
muito alta.

9
Modelo Ágil

Diferente do modelo waterfall, no modelo ágil, não esperamos a

documentação do projeto todo ficar pronto para iniciar o desenvolvimento.
Neste modelo é quebrado em funcionalidades testáveis e tanto a análise
quando o desenvolvimento é focado nas funcionalidades do sistema. Assim
o cliente irá receber pequenas funcionalidades do sistema que ele possa
testar e assim fica mais simples as alterações no projeto. Pois quando ele
receber uma pequena parte, ele já consegue perceber quais são as reais
necessidades das funcionalidades que virão no futuro.

Figura 4 Modelo ágil de desenvolvimento de software

Como podemos ver na imagem abaixo, a comparação entre os dois

modelos. No waterfall a entrega apenas no final de todo o projeto e no ágil,
temos a entrega de funcionalidades para que o cliente possa já ir utilizando
o software e testando-o.

10
 Figura 5 Modelo waterfall comparado ao modelo ágil

Esse modelo é muito utilizado em cenários onde o nível de incerteza dos

requisitos é bem alto ou onde os requisitos estão mudando
constantemente. Mas funciona muito bem em cenários onde os requisitos
já são muito bem definidos.

No contexto ágil o papel do engenheiro de requisitos, assim como no

modelo tradicional é entender as necessidades dos clientes e documentar
para os desenvolvedores transformarem a documentação em software.
Mas aqui temos o papel do engenheiro de requisitos integrando os
desenvolvedores na concepção das funcionalidades e participando
repassando para os desenvolvedores as mudanças de requisitos e também
controlando os requisitos que devem ser criados durante todo o projeto.
Uma vez que serão realizadas várias entregas e não mais somente uma
entrega do software completo.

11
 Figura 6 Engenheiro de requisitos no contexto ágil

O que pode ser considerado um requisito

Quando falamos na documentação de requisitos, não estamos nos

referindo apenas em documentos de páginas e páginas com regras
extremamente detalhadas. Alguns outros artefatos podem ser
considerados como documentos de requisitos e alguns deles podem ser
apresentados juntos ou um complementando outros. São eles:

 Protótipos: Desenho de telas que o software deve ter. Os protótipos

podem ser de diversos níveis de detalhamento. Podem ser
extremamente fiéis ao que deve ser desenvolvido ou pode ser apenas
esboços. Iremos conhece-los no capítulo 2.
 Documentos: Documentos de regras de negócios, legislações, leis
etc.
 Diagramas: Diagramas da UML, diagramas BMPN etc.
 Textos: Textos em linguagem natural que descrevem os protótipos,
diagramas e as regras de negócios que o software deve seguir.

12
O artefato que você irá utilizar como seu requisito, irá depender do cenário
e da sua necessidade. E na maioria dos casos você irá utilizar todos eles
juntos. Todos fazendo parte de uma documentação do seu projeto.

O engenheiro de requisitos. Quem são da onde vem o que fazem

A engenharia de requisitos existe a muito tempo na área de

desenvolvimento de software. Por muitos anos ela foi muito negligenciada,
uma vez que encarece um projeto. Mas com o passar dos anos as empresas
começaram a perceber que a falta desse profissional nas empresas
acarretou mais prejuízos que tê-los. Algumas estatísticas indicam que certa
de 60% dos projetos desenvolvidos no mundo todo, não são utilizados. Seja
por problemas de requisitos ou que o projeto não é concluído pois também
não houve uma definição dos requisitos bem-feita.

O profissional que atua na análise de requisitos é o responsável por fazer o

levantamento dos requisitos funcionais e não funcionais de um projeto,
documenta-los, gerenciados e garantir que as necessidades estão bem
desenvolvidas.

Nos últimos anos, esse profissional tem se tornado indispensável nas

empresas aqui no Brasil e fora também. E com o aumentando da
complexidade do desenvolvimento de software, o profissional, o
engenheiro de requisitos, teve que absorver skills de outras áreas e tendo
que evoluir conforme as necessidades do mercado. Hoje em dia um analista
de requisitos tem que ter habilidades de design, negócios, negociação e
técnico.
Geralmente os analistas de requisitos são analistas de sistemas que depois
de formandos decidiram se especializar mais na área de negócio do que
técnica (programação). A maioria dos analistas que conheço, trilham esse
caminho. Pois ainda, aqui no Brasil, não temos uma formação de nível de
graduação que forma engenheiro de requisitos.
Existem algumas habilidades fundamentais para quem quer atuar como
analista ou engenheiro de requisito. Durante o livro, quando eu citar
analista ou engenheiro de requisitos, estarei falando do mesmo papel.

13
Pensando nessas habilidades o perfil que o engenheiro de requisitos precisa
ter é o seguinte:

 Ser bom ouvinte: o usuário do sistema ou seu cliente irá falar os

problemas que você precisará resolver com um software por
exemplo. Desta maneira você sempre tem que se manter focado na
conversa para não perder nenhum detalhe.
 Ser bom questionador: muitas vezes que você estiver conversando
com alguém responsável por fazer o repasse das regras de negócios,
não irá saber como passar essas informações ou muitas vezes nem
saber quais informações deverá passar ou quais serão suficientes. É
importante que você questione de maneira de extrair todas as
informações necessárias para o seu trabalho.
 Ser observador: deverá ser um bom observador para poder detectar
as mudanças e problemas que poderão ocorrer em determinadas
situações.
 Escrever bem: uma das habilidades mais importantes é desenvolver
a escrita. Uma vez que será através dela que você irá passar para a
sua equipe o que deverá ser desenvolvido.
 Ser organizado: uma outra habilidade muito importante, uma vez
que você será o responsável por controlar o gerenciar os requisitos
do projeto e acompanhar as mudanças que irão ocorrer neles.
 Ser criativo: criativo para criar as melhores soluções para o seu
cliente, mais sempre apoiado nas melhores práticas do mercado.
 Integrador: no sentido de integrar a sua equipe de desenvolvimento
na concepção dos requisitos, assim, quando eles pegarem seus
requisitos para desenvolver eles já estarão cientes do que deverá ser
desenvolvido sem surpresas.
 Consultor: nem sempre o seu cliente terá a melhor solução. E o seu
papel como engenheiro de requisitos é informa-lo que a solução que
ele pensou não é a melhor. E propor à ele uma solução melhor.
 Ter conhecimento da tecnologia: É importante que você tenha
conhecimento da tecnologia que será utilizada para desenvolver a

14
 solução, para propor soluções que serão possíveis de serem
utilizadas e também para saber o que poderá ser desenvolvido.

Sou desenvolvedor, mas será que estou me tornando analista?

Mesmo com a crescente dessa área no Brasil, ainda é comum termos

desenvolvedores que fazer o papel de análise e programação. Se você é
desenvolvedor e tem que conversar com clientes, para entender suas
necessidades, documentar e as vezes nem documenta e já sai
desenvolvendo, se você tem que aprender a regra de negócios do seu
projeto para documentar de alguma maneira. Tenho uma notícia para você!
Você ainda não é um engenheiro de requisitos, mas está no caminho. Se
você gosta mais das funções de análise do que desenvolver, foque nessa
área atualmente esse profissional está em falta no mercado.

O Mercado

A imagem mais clichê na área de engenharia de software é a imagem

abaixo. Que representa uma ilustração do que o cliente pediu e que cada
um de uma equipe de desenvolvimento entendeu e o que o cliente recebeu.

15
 Figura 7 Imagem que ilustra o caos do desenvolvimento de software

Essa imagem ficou muito conhecida e famosa, pois ilustra muito bem a
realidade do que acontece nas empresas de desenvolvimento de software.
A busca das empresas para os casos dessa imagem não acontecer mais,
gerou um aumento na procura dos profissionais de análise de requisitos.
Hoje pequenas, médias e grandes empresas estão brigando por esses
profissionais. Uma vez que em comparação com o número de
desenvolvedores, é um número bem menor.

Certificação de engenharia de requisitos

Uma maneira de se destacar no mercado e se manter atualizado, é tirar

certificações. Existe uma certificação internacional especifica para
engenheira de requisitos. A CPRE-FL.

“O órgão responsável pela criação desta certificação foi o IREB –

International Requirements Engineering Board. Com a visão de criar
uma base internacionalmente aceita de profissionalização da
disciplina Engenharia de Requisitos, de forma a dar importância e
orientação correspondente ao seu valor para a indústria. Nesse meio
tempo o IREB tornou-se um organismo de renome mundial de
especialistas para a certificação dos profissionais em Engenharia de
Requisitos. Mais informações aqui.” - https://blog.db1.com.br/certificacao-
de-engenharia-de-requisitos-cpre-fl/

16
UNIDADE II: Processos da engenharia de requisitos

“Toda empresa precisa de gente que erra, que não tem medo de errar e que aprenda com o erro"
— Bill Gates

Assim com existe alguns frameworks de gerenciamento de projetos e

desenvolvimento de software, nós também podemos definir um para a
engenharia de requisitos. Eu gosto de separar a engenharia de requisitos
em 5 etapas. Concepção, Planejamento, Elicitação, Prototipação e
Documentação.

Concepção Planejamento

Documentação Elicitação

Prototipação

17
Concepção

Na fase de concepção é onde o cliente irá lhe apresentar o que deverá ser
desenvolvido, e por consequência você deverá criar uma documentação.
Os objetivos principais da concepção são:

 Verificar a viabilidade do desenvolvimento: uma vez que ele

apresentar o que ele precisa ou uma ideia do que precisará ser
desenvolvido, você com sua expertise técnico e do negócio dele,
sozinho ou junto com sua equipe de desenvolvimento, deverá
avaliar e dizer se o que ele precisa é viável ou não. Não tenha medo
de neste momento dizer que não é possível. Pois você irá estar
assumindo os riscos do pedido dele.
 Definir a delimitação macro de escopo: Neste momento também
que você junto com o seu cliente irá limitar o que irá ser especificado
em cada documento de requisito e o que irá fazer parte de cada
funcionalidade. Na delimitação do escopo é importante focar em
funcionalidades e coisas que realmente serão importantes para o
projeto do seu cliente. Evite deixar o escopo muito grande e o seu
projeto se tornar tão grande a ponto de ele nunca terminar. Quando
eu digo que é uma delimitação macro de escopo, pois quando você
for fazer a elicitação, possivelmente você tentará enxugar um pouco
mais o escopo do projeto.
 O que entrará ou não no projeto: Assim como você irá delimitar o
que irá entrar no escopo do projeto, deixe também bem claro, o que
não irá entrar no projeto, para não gerar falsas expectativas.

18
Planejamento

Após a delimitação do escopo é hora de fazer o planejamento do que será

especificado. É o momento para se organizar e documentar o que deverá
ser especificado durante a sua análise.
Uma boa maneira de fazer a documentação desse planejamento é
utilizando uma EAP (Estrutura Analítica de Projetos) ou até um mapa
mental.
Essas ferramentas irão deixar de forma visual para todos do projeto o que
deverá ser especificado e também uma forma de mostrar um documento
para alinhar com todo a sua equipe e o cliente as expectativas.
E tanto a EAP quanto o mapa mental, servem para exibir o limite do escopo
de cada funcionalidade.
Abaixo segue um exemplo de EAP e na sequência de um mapa mental.

Figura 8 Exemplo de EAP

19
 Figura 9 Mapa mental do seu projeto

Envolva o time de desenvolvimento durante a definição dos requisitos e

durante a produção deles, eles irão lhe ajudar na concepção dos requisitos
e durante o desenvolvedores irão saber mais o valor das funcionalidades
que eles devem desenvolver.

Elicitação

A elicitação acontece desde do planejamento até você começar a

documentar o requisito. Pode ser que durante a elicitação, você crie alguns
protótipos junto com os evolvidos no projeto.
É a fase onde você irá tentar entender o que precisa ser documentado e
futuramente desenvolvido. Você vai sair na aventura de encontrar as fontes
para que você consiga escrever os requisitos.
Nesta fase você irá buscar conhecer as regras de negócios e suas
particularidades. Buscar compreender quem são os interessados no
software que será desenvolvido e como ele será utilizado. Buscar entender
qual o problema que precisa ser resolvido e sugerir a melhor solução.
Agora é hora também entender qual será a real utilização das
funcionalidades que foram

20
Também é hora de enxugar um pouco mais o escopo e focar em o que
realmente será fundamental para o seu cliente. Pois assim você conseguirá
entregar valor real a ele.
Também será hora de identificar quais são as premissas e restrições do
sistema ou do ambiente que ele será implantado.

Técnicas de elicitação

Para realizar a elicitação de requisitos, existem algumas técnicas:

 Entrevista: você pode entrevistar os envolvidos no projeto, afim de

identificar os problemas e possíveis soluções.
 Questionário: você cria um formulário com perguntas que você ache
relevante para o cenário que a pessoa está inserida e envia para os
envolvidos.
 Observação: você vai até o ambiente para o qual o software será
desenvolvido, e observa os problemas afim de identificar
funcionalidades para o software.
 Pesquisa em campo: você sai em busca de conhecer soluções que
podem servir como base para você propor funcionalidade com base
no problema apresentado.
 Protótipos: através de protótipos (protótipos simples, rabiscos), você
pode testar soluções afim de identificar o que deverá ser feito.

O maior objetivo da elicitação é entender o cenário atual e o cenário futuro.

E para propor soluções para os problemas de seus clientes.

Prototipação

21
 Figura 10 Exemplo de protótipos

A prototipação é uma fase que poderá e muitas vezes é o que irá acontecer,
é que ele acontecerá junto com outras fases. É nesta fase que você irá criar
as telas para do seu projeto.
Utilizando os tipos de protótipos que irei apresentar no capítulo 3, você irá
desenhar as telas com base nas informações levantadas durante a
elicitação.

Figura 11 Exemplo de protótipo

Elas são 5 etapas, mas não quer dizer que uma só irá começar depois da
anterior. Pode ser que a prototipação ocorra junto com a etapa da
elicitação. Ou que a documentação e a prototipação poderão ocorrer em
22
conjunto com a prototipação e assim por diante. Não existe uma regra que
limite quando a ordem de desenvolvimento.

Documentação

A documentação é onde, você irá organizar todos os dados e informações

que você levantou durante o planejamento, elicitação e o que você criou na
prototipação.
Você irá escrever o que deverá ser desenvolvido por seus desenvolvedores.
Deverá detalhar as funcionalidades, inserido as regras de negócios, suas
validações e detalhar as telas criadas nos protótipos afim de alinhar o que
deve ou não ser desenvolvido.

23
Friso bastante que é a forma também de alinhar as expectativas com o seu
cliente e equipe.
Algo importante para ter em mente que os documentos que você escrever,
será utilizado, como uma espécie de contrato entre as partes interessadas.
Pois caso algo que você detalhou no projeto, for desenvolvido diferente o
seu cliente irá alegar que foi desenvolvido errado e você terá prejuízo.
Melhor do que não ter documentação é ter uma documentação ruim. Desta
maneira os documentos que você irá escrever poderá ser utilizado como
documentação da evolução de um produto e também para documentação
para novos membros da equipe e futuras consultas de comportamentos do
software. Por isso, tenha em mente que seus documentos precisam estar
muito bem organizados e atualizado, para que eles não fiquem obsoleto em
relação ao software desenvolvido.
Markdown

Sempre que vamos criar qualquer tipo de documentação, a primeira coisa

que nos vem na cabeça, é criar os documentos em nosso querido
“Microsoft Word”. Mas para documentações que serão utilizadas por um
time de desenvolvimento e muito possivelmente será evoluída no futuro, o
Word não é a melhor solução. Eu proponho e gosto muito de escrever os
requisitos utilizando markdown.
“Desenvolvido em 2004 por John Gruber e Aaron Swartz para
simplificar a estruturação de um texto, o Markdown é um sistema de
formatação aberto que torna a escrita e a leitura mais simples. Com
uma codificação mínima, além de fácil, ele é visualmente mais
"limpo" e pode ser convertido facilmente para HTML.” – CanalTech
Ele é realmente muito simples, mais simples que HTML, ele tem uma curva
de aprendizagem muito pequena. O melhor de utilizar o markdown é que
os documentos podem ser versionados e assim conseguimos manter a
rastreabilidade das mudanças que ocorrem nos documentos.

24
Para criar os requisitos em markdown, você pode utilizar uma IDE como o
http://brackets.io e basta salvar o documento com a extensão “.md”.
Abaixo um exemplo de um arquivo escrito em markdown.

A própria IDE permitir gerar um preview desse documento. Que está

representado abaixo.

25
A partir desse requisito é possível gerar arquivo html ou pdf para
disponibilizar para os desenvolvedores ou para seu cliente.
Os exemplos que requisitos que irei demonstrar durante o livro irei utilizar
as notações do markdown. Que você pode conhece-las pelo manual do
github, que utiliza muitos lugares em seu site, https://github.com/adam-
p/markdown-here/wiki/Markdown-Cheatsheet.

Requisitos Funcionais e Não Funcionais

Os requisitos podem ser classificados entre funcionais e não funcionais. O

primeiro se diz a respeito a um requisito que contém funções que o sistema
deve executar e suas regras e o segundo diz a respeito ao funcionamento
do sistema e são ligados às propriedades do sistema.

Requisitos funcionais

A engenharia de requisitos define os requisitos funcionais como sendo os

requisitos que especificam os comportamentos específicos do software,
suas funcionalidades.

Requisitos funcionais são aqueles que descrevem as funcionalidades que

uma aplicação deve ter. Por exemplo: um requisito funcional da
funcionalidade "Cadastrar Clientes" de um sistema, poderia ser que o
cadastro deva ter os campos "Nome", "Endereço", "CPF" e "Telefone". E
que deva haver a validação do número do CPF informado. Isto é um
exemplo de requisito funcional.
Requisitos funcionais, podemos são extremamente importantes para guiar
os desenvolvedores no desenvolvimento da solução. Pois nele estará
descrito as regras que o sistema deve seguir assim, como o que o sistema
deve ter.
Exemplo de requisitos funcionais:

26
 Emitir Nota Fiscal;
Cadastrar de Clientes;

O que descrever?
Informações que deve conter na interface;
As regras de negócios que impactam o cadastro;

Requisitos não funcionais

A engenharia de requisitos define os requisitos não funcionais, ou requisitos

de qualidade, como sendo os requisitos que especificam critérios que
podem ser usados para descrever o funcionamento de um sistema, e não
os comportamentos específicos, pois para isso é utilizado os requisitos
funcionais.
Já os requisitos não funcionais, que vem descrever como o sistema deve se
comportar são extremamente importantes para atender as necessidades
dos usuários. Um exemplo de requisito não funcional, é dizer que o sistema
deverá suportar o acesso simultâneo de 10 mil pessoas por hora.
Documentando essa informação, deverá ser preparada a estrutura do seu
sistema para suportar essa quantidade de acessos. Caso requisitos não
funcionais não sejam atendidos, podem gerar insatisfações na utilização do
sistema.
Os requisitos não funcionais são mais difíceis de serem identificados que os
requisitos funcionais, uma vez que os usuários muitas vezes não sabem de
sua existência e até não possuem conhecimento para dizer quais são os
comportamentos esperados pelo sistema. Mas cabe aos analistas de
requisitos levantar hipóteses que ajudem na identificação deles. Iremos
também conhecer como fazer o levantamento desses requisitos.

Exemplo de requisitos não funcionais:

Disponibilidade do software;

27
 Compatibilidade do software;

O que descrever?
Disponibilidade: Quantidade de dias e horas que o software
deve estar disponível para os usuários;
Compatibilidade: O software deverá ser ser compatível com os
sistemas operacionais Android e IOS;

Tanto requisitos funcionais, quantos os não funcionais não podem ser

negligenciados durante o desenvolvimento de software. Pois eles auxiliam
a garantia da qualidade do software final. Agora vamos conhecer no detalhe
o que são esses requisitos.

Como descrever os requisitos

Histórias de usuários

Em um ambiente ágil, a história de usuário é um instrumento de escrita

utilizado no processo de levantamento de requisitos para descrever a
especificação de uma funcionalidade do software, afirmam Beck e Fowler
(2001). Normalmente, uma história de usuário é breve, pois consiste em
apenas uma ou duas frases.
Na história de usuário, você descreve quem irá utilizar a história, o que
deverá ser desenvolvido e porque ela deverá existir. Como mostra abaixo a
estrutura de uma história de usuário.

28
 Figura 12 Estrutura da história de usuários

Abaixo segue um modelo de escrever a história de usuários. Note que estou

dando uma um código de identificação para história além do nome. Ela está
escrita utilizando markdown.

Figura 13 Exemplo de história de usuários

]
Esse markdown no preview deverá ser exibido como mostra a imagem
abaixo:

Figura 14 História de usuário no preview do markdown

Critérios de aceitação

29
Cada história de usuário deve conter alguns critérios de aceitação, que é
uma forma de apresentar como as funcionalidades serão utilizadas e como
valida-las. Representam a confirmação da implementação dos requisitos
Elas devem ter o cenário que em a história será utilizada, o evento ou ação
que deverá ocorrer e como a funcionalidade deverá se comportar.

Figura 15 Estrutura de um critério de aceitação

Abaixo é um exemplo de critérios de aceitação da história de usuário que

foi criada.

Figura 16 Critério de aceitação escrito em markdown da história de usuário

Abaixo como fica no preview.

30
 Figura 17 Critério de aceitação no preview

Você pode colocar as histórias e os critérios de aceitação no mesmo

documento. E dar o nome deste documento o mesmo nome da
funcionalidade que as histórias e os critérios de aceitação pertencem. Como
mostra a imagem abaixo:

Outra estrutura de documentação

Negócios que possuem uma regra de negócio complexa, necessitam

documentos de requisitos mais robustos. Desta maneira, eu sugiro como
uma melhor prática que você crie em sua empresa um template padrão

31
para os requisitos. Abaixo eu deixe para você um template baseado nas
melhores práticas da engenharia de requisitos e como preenche-lo. Ele
também está formatado em markdown. O arquivo deste template está
disponível no meu repositório do github que eu citei no início do livro. Você
pode baixar e utiliza-lo. ;)

Figura 18 Sugestão de estrutura de documento

#Análise de Processos
##Qual a Necessidade (Propósito)?
Nesta seção, deverá ser descrito qual é a necessidade do cliente
baseado na regra de negócio citada na introdução.
Exemplo: Visto o processo de importação, faz-se necessário ter
no sistema financeiro ter um cadastro de moeda e cotação,
para que o cliente possa cadastrar as moedas e cotação e que

32
 o sistema realize as conversões na tela de pedido de venda e
nota fiscal.

##Quem Precisa (Público Alvo)?

Nesta seção, deverá ser descrito a quem a funcionalidade irá atender,
ou seja, quem irá utilizar a mesma depois de entregue.
Exemplo: Esta funcionalidade irá atender as necessidades do
diretor financeiro e do departamento de exportação.

##Qual Valor Irá Gerar para o Cliente?

Nesta seção, deverá ser descrito o que a funcionalidade irá gerar de
valor para o negócio do cliente, seja otimizando, facilitando ou
gerando segurança em relação aos dados do sistema.
Exemplo: Com a funcionalidade implantada no cliente, espera-
se gerar as INVOICES de com os valores corretos, evitando
assim com que o departamento de exportação necessite fazer
as mesmas de maneira manual.
##Premissas
Informações que serão tomadas como verdadeiras para o
desenvolvimento do requisito e da solução.
Exemplo: O sistema utiliza o banco de dados de CEP dos
correios atualizado.
##Restrições
Explicação de qualquer limitação, que limita a solução. Podem ser
políticas corporativas, as limitações de hardware, tecnologias
específicas, etc.
33
##Riscos e Impactos
Descrições de itens que impactam ou são impactados pela solução e
os riscos a serem cobertos.

##Modelo de Limite das Funcionalidades

Através de um modelo (diagrama de caso de uso, fluxo do usuário,
modelo BPMN, diagrama de classe, diagrama de atividade, mapa
mental, etc.) represente de forma analítica as funcionalidades
apresentadas neste documento.

##Requisitos Funcionais
Esta seção deve descrever em detalhe os requisitos funcionais do
sistema. Não existe uma regra específica para a sua organização,
pode ser feito de acordo com os casos de uso, as ações do sistema, ou
combinações desses usuários. É essencial que esta descrição seja
minuciosa, clara e completa, lógica e facilmente modificado.
Poderá ser incluído:
• Protótipos (obrigatório).
• Elementos gráficos
• Ações exigidas pelo sistema (inserir, remover, apagar,
salvar, anexar, etc.)
• Descrições dos Estados
• Regra de validações do sistema
• Relatórios requeridos
• Etc...

34
Contexto da Rotina: Conforme descrito no Modelo de Limite das
Funcionalidades esta funcionalidade contempla os itens abaixo:
1. Descrição;
2. Descrição;
a. Descrição;
b. Descrição;

###Sub-Tópico Lorem Ipsum

|  |
| :-------------------------------: |
| *Figura : Protótipo da tela xpto* |

Descreva cada componente dos protótipos.

###Sub-Tópico xyz
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
##Padão de descrição de Imagens
|  |
| :--------------------------: |
| *Figura : Legenda da Figura* |
Descreva cada componente dos protótipos.
#Regras de Negócios
###RN1
####Título para Identificação
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec tempor
faucibus suscipit. Integer sit amet consectetur neque. Pellentesque

35
 turpis dolor, aliquet eu tortor eget, facilisis faucibus velit. Aenean ac
urna dui. Phasellus suscipit libero est, id volutpat urna mattis vitae. In
hac habitasse platea dictumst. Quisque posuere lectus sit amet
viverra pellentesque. Nunc sit amet molestie lectus. In aliquam luctus
magna, vitae posuere quam ornare a. Vivamus sed eros scelerisque,
aliquam metus id, cursus ipsum.

#Interface/integração com outros sistemas

Nesta seção, descrever como será feito a integração com outros
sistemas em nível funcional caso haja.
Caso esse item já esteja descrito de forma completa no requisito não
funcional, apenas fazer referência ao mesmo.

#Critérios de Aceitação
Nesta seção, descrever os critérios que devem ser atendidos para os
requisitos sejam aceitos.

Gerenciamento dos requisitos

Um dos grandes desafios é você conseguir gerenciar seus requisitos

mantendo-os atualizados, organizados e com rastreabilidades das
mudanças. Utilizando markdown essa tarefa passa a ser simples utilizando
o Git, que é um gerenciador de versão de arquivos. Pois a cada mudança
no arquivo do requisito, você conseguirá ver a mudança que ocorreu
naquele arquivo.
A imagem abaixo mostra como era um documento em um momento e
como ele ficou depois de uma alteração.

36
 Figura 19 Visualizando a mudança de um arquivo n

Este material faz parte do livro “Engenharia de Requisitos” e está disponível na disciplina
de mesmo nome em nossa Pós-graduação em Engenharia de Software com Ênfase em
Qualidade e Testes de Software. Foi escrito pelo nosso professor Vinicius Carvalho. Você
pode saber mais sobre a pós entrando em contato por e-mail: contato@uniciv.com.br ou
telefone: 0800 006 4224

37