EN

REQUISITOS
DE SOFTWARE
Uma viso sobre detalhada sobre Requisitos
Funcionais, Requisitos No-Funcionais e Regras
de Negcio

Uma produo do blog de Engenharia de Software:

http://www.ateomomento.com.br

Eu sou o Plnio Ventura, do blog At o

Momento e da Indtech Academia de
Software.
um prazer poder lhe oferecer este
eBook!
Espero realmente que este material seja
muito til a no seu dia a dia profissional.
Trabalho com TI desde 1998, e pude
viver um pouco de tudo na rea de
Engenharia de Software.

J atuei como Programador, Analista de Sistemas, Coordenador de

Qualidade, Coordenador de Desenvolvimento, empreendedor em startup e
Gerente de Projetos.
Em todo este tempo, no restou dvida sobre o que mais gosto: gosto de
ser tcnico! As coisas podem e devem ser bem-feitas; realmente no acredito
que poltica e presso realizam bons projetos. Acredito na qualidade e no
compromisso, na excelncia tcnica o no time horizontal!
Nestes longos anos sempre fiquei muito (muito mesmo) incomodado com
a forma como as empresas lidavam/lidam com Engenharia de Software,
principalmente quando o assunto era Engenharia de Requisitos.
Requisitos so o incio de tudo, so a causa de todo o resto em projetos
de software. Entend-los corretamente, e materializar este entendimento no
dia a dia, faz toda a diferena no sucesso dos projetos.
Aqui tem um contedo bacana sobre isso, e que ser muito til a voc.
Grande abrao, bons estudos, e muita energia positiva!

Indtech Academia de Software

http://www.indtech.com.br
http://www.ateomomento.com.br
http://www.facebook.com/ateomomento
https://www.youtube.com/c/plinioventura

Essa imagem (no sei o autor da que inseri acima, mas j de domnio
pblico por ter inmeras verses e variantes feitas por diversas pessoas) reflete
perfeitamente a nossa realidade nos projetos de software. E tudo comea nos
Requisitos...

Requisitos de Software
Achar uma definio objetiva e exata para a palavra requisito difcil. A
palavra possui alguns significados (conforme os dicionrios), mas chega a ser
um pouco abstrata. Mas basicamente, quando falamos de requisito, estamos
falando de necessidade, exigncia, desejo, solicitao. Levando esta palavra
para o contexto de um software, estamos falando de necessidades de um
usurio, exigncias do negcio, desejos da empresa, solicitao da
empresa, tudo isso devendo ser realizado por um sistema, ou seja, o software
dever atender estas necessidades, exigncias, desejos e solicitaes, e
materializar isso em um sistema.
Acho legal pensarmos no software como uma caixa de ferramentas, onde
cada ferramenta contida dentro desta caixa uma funcionalidade, que atende
um ou mais requisitos do sistema.

No escopo de um software comum se ter muitos requisitos, e por uma

questo de mtodo, estes requisitos so agrupados e trabalhados conforme
seus objetivos. Entendemos que requisitos possuem um objetivo s, que
atender a uma exigncia informada por algum, mas a natureza de tal exigncia
pode ser diferente para cada requisito. Em funo disso separamos e
trabalhamos os requisitos conforme a natureza de cada um, conforme o tipo
de cada necessidade, o tipo de cada requisito.
Na Engenharia de Software existe um hbito de se categorizar demais,
de se classificar demais, e isso torna os mtodos/processos aplicados muito
inchados, com muitas coisas para fazer (em termos de documentao por

exemplo), coisas que nem sempre geram valor na produo final de um

sistema.
Isso ainda uma realidade, infelizmente, mas percebo que uma
realidade que tem ficado mais no campo da teoria, no mais indo para a prtica
como acontecia nas dcadas pretritas.
A Engenharia de Software uma cincia/rea de conhecimento
relativamente nova. Tudo comeou formalmente na dcada de 1960,
ento estamos falando de uma rea de conhecimento com menos de 70
anos. reas como a engenharia civil j existem h mais de 3000 anos,
apenas para comparao. Qualquer rea de conhecimento que surge
comea no caos at que se conhea melhor o todo e suas partes, para
da se buscar sair do caos e ir para a ordem.
Mas quando essa busca pela ordem comea, todos querem organizar
tudo, e geralmente utilizam-se mtodos e processos para isso, baseandose consciente/inconscientemente no mtodo cientfico1.
E neste momento natural o exagero na burocracia. Tempos depois,
chega-se ao equilbrio. Estamos vendo isso na Engenharia de Software
hoje com os mtodos geis, que pregam menos burocracia e mais
software executvel para gerao de valor, muito diferente do que
tnhamos na dcada de 90, que era a tentativa de organizar o caos que
se criou nas dcadas de 70/80/90 a um custo proibitivo em termos de
burocracia.
Algumas literaturas definem diversas classificaes/tipos para requisitos:
requisitos de sistema, requisitos de software, requisitos emergentes, requisitos
de produto, requisitos de projeto, requisitos de processo, requisitos de teste etc.
E na prtica, no dia a dia nas fbricas de software, nos projetos e nas operaes
das empresas, fica claro que quanto menos denominaes existirem mais
simples ficam as coisas e mais objetivas e rpidas tambm.
Eu defendo e acredito que em projetos de software mais do que
necessrio haver apenas trs tipos de requisito: Requisitos Funcionais,
Requisitos No Funcionais e Regras de Negcio.

https://pt.wikipedia.org/wiki/Mtodo_cientfico

Na literatura de engenharia de software, de um modo geral, regras de

negcio no so tratadas como requisitos, em vrios casos nem so
mencionadas. Mas eu as coloco no mesmo nvel de importncia que os
requisitos funcionais e No Funcionais, pois sem elas no existe
sistema, sem elas no existem requisitos funcionais.
Essa viso se aplica por dois motivos principais: o que se pratica
efetivamente no mercado, e mais do que isso, gera-se burocracia alm do
permitido para projetos de software (que j requerem um mnimo de
burocracia).
Abaixo segue a viso que citei anteriormente, para requisitos de software
e seus elementos:

Na imagem acima, o que temos uma especializao de requisitos de

software. O requisito de software o tipo mais genrico (generalizao), e
Requisito Funcional, Regra de Negcio e Requisito No-Funcional so
tipos mais especializados (especializao).
Conceitualmente falando, um sistema nada mais que: um escopo, dividido
em mdulos, cada mdulo com seus requisitos funcionais e regras de
negcio, e requisitos No Funcionais fora dos mdulos, permeando todo o
sistema. Abaixo uma figura ilustrando um pouco dessa decomposio das
partes, no todo que o software.

Vamos detalhar cada um dos trs tipos de requisitos e entender melhor do

que se trata cada um deles.
O nvel de detalhe nas especificaes pr-requisito para um projeto de
software seguro, blindado, com qualidade. Mas isso no significa que devemos
criar complexidade quando podemos ter simplicidade.
Simplicidade fundamental nos projetos de software.

Requisito Funcional
Como vimos no captulo anterior, requisito uma exigncia, solicitao,
desejo, necessidade. Quando falamos de um Requisito Funcional estamos nos
referindo requisio de uma funcionalidade que um software dever
atender/realizar. Ou seja, exigncia, solicitao, desejo, necessidade, que um
software dever materializar.
comum os profissionais de engenharia de software associarem a ideia de
um Requisito Funcional a uma tela, uma rotina, que no fim sero as
funcionalidades de fato de um sistema. Mas necessrio entender que uma
funcionalidade no necessariamente realizar apenas um Requisito
Funcional, podendo realizar vrios requisitos funcionais significa que em
uma funcionalidade um ou mais requisitos funcionais podem ser atendidos, no
necessariamente apenas um. Se pensarmos em multiplicidade2, uma
funcionalidade pode realizar um ou muitos requisitos funcionais (1.. *).
A figura abaixo ilustra esta relao.

Para entender melhor isso vamos a um exemplo mais bsico.

Imaginemos um sistema que possui uma tela para Manuteno de Clientes,
que mantm os dados cadastrais de um cliente no sistema. Estamos falando
de
uma
nica
funcionalidade.
Nesta
tela

possvel
2

http://www.ibm.com/support/knowledgecenter/SS5JSH_9.5.0/com.ibm.xtools.petal.ui.doc/topics/rkeydifmulti
plicity.html?lang=pt-br

incluir/alterar/consultar/excluir clientes dos tipos pessoa fsica e pessoa jurdica.

Mas quantos requisitos so realizados (atendidos) por esta funcionalidade?
Oito requisitos. Vejamos a lista a seguir:
Requisitos Funcionais (Identificador e Nome)
RF001 Incluir cliente pessoa fsica
RF002 Alterar cliente pessoa fsica
RF003 Consultar cliente pessoa fsica
RF004 Excluir cliente pessoa fsica
RF005 Incluir cliente pessoa jurdica
RF006 Alterar cliente pessoa jurdica
RF007 Consultar cliente pessoa jurdica
RF008 Excluir cliente pessoa jurdica

O que no um Requisito Funcional?

comum quando se fala de Requisito Funcional associar a isto
funcionalidade, caso de uso, Regra de Negcio ou at mesmo requisito
no funcional. So coisas muito diferentes.
Uma funcionalidade pode realizar um ou mais requisitos funcionais.
Requisito funcional no uma funcionalidade, uma necessidade
funcional (uma funo) que o software deve atender. Uma
funcionalidade ser executada por um ator (um ator sistmico [pelo
prprio sistema] ou um ator humano [usurio final]). onde requisitos
funcionais sero viabilizados.
Um caso de uso3 uma especificao do comportamento de uma
funcionalidade. Nele se tem detalhes sobre como a funcionalidade
funcionar, com restries, premissas e diretrizes pertinentes
funcionalidade.
Regra de negcio refere-se a premissas ou restries de negcio que o
sistema dever atender, regras que podero ou no estar associadas a
um Requisito Funcional, mas que sempre sero realizadas por uma ou
3 http://www.ateomomento.com.br/o-que-e-caso-de-uso/

mais funcionalidades do sistema. Na viso da modelagem conceitual,

Regras de negcio so o como, requisitos funcionais so o o que.
Requisitos No Funcionais so premissas ou restries que o sistema
dever atender, mas que no so realizados atravs de funcionalidades.
Podem ou no estar associados a requisitos funcionais, mas no tem,
necessariamente, relao com o negcio, na viso do usurio.

Importncia dos Requisitos

Requisitos Funcionais
Funcionalidades somente existem para realizar requisitos funcionais.
Logo, sem requisitos funcionais no h funcionalidades e sem funcionalidades
no h sistema. Este raciocnio por si s demonstra a importncia absoluta e
inquestionvel dos requisitos funcionais no escopo de um sistema.
E por ser algo importante como , todo cuidado pouco para que estes
requisitos possuam a maior qualidade possvel, pois apenas a existncia deles
no escopo no garante um bom sistema, eles precisam ter qualidade em termos
de sintaxe e semntica4. Precisam ser bem feitos. Mas o que devemos entender
como qualidade de um requisito?

Atributos de um bom Requisito Funcional

Um Requisito Funcional de qualidade precisa atender alguns atributos
especficos. Na literatura, principalmente estrangeira, existem vrias
recomendaes de atributos que um requisito deve atender para ter qualidade.
Mas vou me ater apenas aos que realmente considero relevantes na prtica,
que fazem diferena no dia a dia. A seguir a lista dos atributos que considero
relevantes.
Atributo

Referente a

Unidade

O RF deve propor uma nica coisa apenas. No deve atender

a mais de uma exigncia. O RF Incluir cliente no unitrio,
pois se refere a incluir clientes de tipos diferentes (pessoa
fsica e jurdica), assumindo assim vrias responsabilidades,
quando deveria assumir apenas uma.

Completude

O RF deve ser autocontido, deve ter incio/meio/fim, ser

completo. O RF Pagar fatura no completo, s conta parte

4 http://www.ateomomento.com.br/sintaxe-semantica-software/

Atributo

Referente a
da estria. Para ser completo deveria ser algo como Pagar
fatura com carto de crdito para cliente pessoa fsica.

Consistncia

O RF no deve contradizer outro RF do mesmo escopo do

projeto. como termos dois RFs se propondo a fazer uma
mesma coisa, mas cada RF se propondo a fazer esta coisa
de uma forma diferente.

Atomicidade

Um RF para ser atmico precisa tambm ter unidade, pois

atomicidade remete a assumir apenas uma responsabilidade.
Mas tambm deve ser algo indivisvel, no podendo ser
decomposto. Muitos RFs possuem conjuno, dependem de
outros para se realizarem. Onde temos dois RFs Realizar
compra de produto e Realizar pagamento com carto de
crdito na realidade, se pensarmos em atomicidade, temos
um nico RF que Realizar compra de produto com
pagamento em carto de crdito.

NoAmbiguidade

Um RF no pode ser ambguo, no pode propor algo que no

fica claro o que . O RF Emitir relatrio no quer dizer nada.
Relatrio de que, para que? Emitir relatrio de saldo j
melhor, mas ainda ruim. Saldo de que? Seria no ambguo
se no deixasse dvidas, algo como Emitir relatrio de saldo
da conta corrente do cliente pessoa fsica.

Verificvel

No adianta ter um RF se ele no palpvel, possvel de

associar com um artefato de construo, de testes. Um RF
tem que ser testvel, tem que ser possvel atestar que o RF
foi atendido, foi construdo, foi homologado. Para isso tem que
ser tambm rastrevel.

Rastrevel

Deve ser possvel achar o RF no sistema pronto, funcional e

executvel. Como saber se um RF foi atendido? Para isso
necessrio ter rastreabilidade, e isso s possvel ligando as
pontas (associar o RF interface grfica, que ser associada
a um caso de uso, que ser associado a funcionalidades, que
sero implementadas etc.).

Prioridade5

Um RF Essencial algo muito diferente de um RF Desejvel,

possuem valores para o negcio completamente diferentes.

5 http://www.ateomomento.com.br/priorizacao-de-requisitos/

10

Atributo

Referente a
O RF deve possuir sua prioridade, isso interfere diretamente
no projeto do software.

Um detalhe fundamental o uso do tempo verbal no nome do RF. Um RF,

em tempo de especificao, refere-se a algo que ser feito, uma ao a ser
realizada pelo sistema. Por isso o nome precisa estar no tempo verbal
infinitivo. Um RF que fala sobre expurgo de registros de clientes inativos no
pode ter este nome, deve se chamar Expurgar registros de clientes inativos.
uma necessidade, mas que precisa ser verbalizada como uma ao a ser
realizada.

Estrutura de um Requisito Funcional

No h um padro estabelecido sobre a estrutura de um RF. Mas a
maioria das empresas utiliza um formato semelhante, contendo campos
especficos. O modelo a seguir contempla os campos mais relevantes, com
posterior descrio de cada um.
O modelo citado aplicvel em especificaes produzidas em Editores
de Texto como o Microsoft Word, por exemplo. recomendado que se utilize,
sempre que possvel, alguma ferramenta Case6 que d suporte a Engenharia
de Requisitos, para melhorar a produtividade na modelagem e a gesto dos
requisitos.
Identificador

<<Numero>>

Nome

<<Texto>>

Mdulo

<<Texto>>

Data de
criao

<<Data>>

Autor

<<Texto>>

Data da ltima
alterao

<<Data>>

Autor

<<Texto>>

Verso

<<Numero>> Prioridade <<Texto>>

Descrio

<<Texto>>

https://pt.wikipedia.org/wiki/Ferramenta_CASE

11

Campo

Descrio

Identificador

Sufixo seguido de um identificador nico. O sufixo

geralmente utilizado RF (Requisito Funcional) e o
identificador nico geralmente composto de quatro dgitos.

Nome

Nome curto do RF, mas que possibilite entender bem o que

RF faz apenas pelo nome.

Mdulo

Mdulo ao qual o RF pertence. Se for um sistema pequeno

que no possua nenhum mdulo, somente o prprio
sistema, deve ser preenchido com N/A (no se aplica).

Data de criao

Data da criao do RF, ou a data em que ele foi

especificado.

Autor

Profissional que especificou o RF pela primeira vez, quem o

criou.

Data da ltima
alterao

Data em que houve a ltima alterao no RF.

Autor

Profissional que alterou a especificao do RF pela ltima

vez.

Verso

Nmero da verso do RF. Geralmente utiliza-se algo

simples, como 1, 2. A verso inicial sempre a 1, e a cada
alterao incrementa-se a verso (na criao verso 1, na
primeira alterao verso 2 e por a vai).

Prioridade7

Se o RF Essencial, Importante ou Desejvel.

Descrio

Descrio detalhada (a mais detalhada possvel) do RF.

O uso de identificador fundamental para uma melhor organizao do

projeto. Localizar requisitos pelo nome no funciona, devido ao volume
dos requisitos e ambiguidades nos nomes. E tambm, importante ter
algum recurso de numerao automtica, pois controlar os nmeros dos
identificadores manualmente invivel.

Exemplos de requisitos
requisitos funcionais especificados
Vejamos alguns exemplos de requisitos funcionais especificados:

7 http://www.ateomomento.com.br/priorizacao-de-requisitos/

12

Identificador

RF0001

Nome

Consultar automaticamente o CEP de clientes atravs do

endereo residencial

Mdulo

Cadastro

Data de
criao

31/01/2016 Autor

Arquitas de Tarento

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Desejvel

Para todos os clientes cadastrados dever ser possvel

consultar o CEP do endereo residencial de maneira
automtica atravs dos dados de logradouro, nmero,
complemento, bairro, cidade e estado.
Descrio
A consulta se dar aps os dados citados serem informados,
de maneira transparente para o usurio final. No deve ser
necessrio clicar em boto ou acionar algum outro comando
para que a consulta ocorra.
Identificador

RF0002

Nome

Herdar permisses de acesso para o usurio que for

associado a um grupo de usurios previamente cadastrado
e ativo

Mdulo

Segurana

Data de
criao

31/01/2016 Autor

Nelson Goodman

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Descrio

O sistema trabalha com o conceito de grupo de usurios,

onde todo usurio deve fazer parte de, ao menos, um grupo
ativo (grupos inativos no se aplicam).
Para informao, no permitido atribuio individual de
permisso diretamente ao usurio. As permisses se do

13

apenas no nvel de grupo. Cada grupo de usurios possui

um perfil pr-configurado de permisses de acesso.
Sempre que um usurio for associado a um grupo, este
usurio deve herdar as permisses de acesso prconfiguradas para o grupo em questo, e mant-las at
enquanto fizer parte do grupo.
Identificador

RF0003

Nome

Emitir carta de cobrana para clientes inadimplentes

conforme critrios pr-estabelecidos

Mdulo

Cobrana

Data de criao 31/01/2016 Autor

Hpias de Elis

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Para todo cliente que esteja inadimplente dever ser

possvel a emisso de carta de cobrana atravs do sistema.
O resultado da emisso ser a carta impressa, que ser
posteriormente despachada por correios ou outro agente de
entrega.

Descrio

Os critrios para definir se um cliente ou no inadimplente

devem estar cadastrados no sistema utilizando regras de
negcio especficas. Nem todo cliente com pagamento em
atraso ser considerado inadimplente, pois dever ser
levado em considerao o score de crdito do cliente, sua
renda mensal, patrimnio etc. Obs.: verificar os requisitos
funcionais e regras de negcio especficas para manuteno
dos critrios citados.
No haver diferena na emisso da carta de cobrana para
clientes pessoa fsica (particular) ou jurdica (empresarial),
logo, o processo ser o mesmo para ambos.

14

Identificador

RF0004

Nome

Recalcular contribuies calculadas incorretamente que

no tenham sido pagas para participantes ativos

Mdulo

Contribuies

Data de
criao

31/01/2016 Autor

Lucrcio

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Importante

Aps o clculo das contribuies de um participante

(participante de qualquer plano previdencirio cadastrado no
sistema) haver a conferncia manual, por um aturio, dos
valores de contribuio que foram calculados pelo sistema.

Descrio

Para cada contribuio que o aturio detectar que houve erro

no clculo e que ainda no foi paga pelo participante, poder
haver o recalculo atravs do sistema (o sistema dever ter
um recurso para reclculo da contribuio). O reclculo
dever ser possvel para uma nica referncia (ms/ano) e
um nico participante; para vrios participantes numa
mesma referncia; para um nico participante em vrias
referncias (considerando um perodo referncia inicial e
final) e para vrios participantes em vrias referncias.
Para reclculo de contribuies calculadas incorretamente,
mas que j foram pagas, verificar RF correspondente. Neste
caso ser necessrio estornar o pagamento antes de efetuar
o reclculo da contribuio.

Exemplos de requisitos funcionais materializados

Vimos requisitos funcionais especificados. Isso ocorre em tempo de
especificao dos requisitos, na fase do ciclo de vida do projeto em que a
modelagem de requisitos acontece.
Quando o sistema est pronto, os requisitos so realizados por
funcionalidades do sistema. Vejamos a seguir exemplos de requisitos
funcionais materializados, ou seja, implementados.

15

Isto um menu de contexto, o famoso menu que exibido aps o clique

com o boto direito do mouse (pode ser o esquerdo tambm, dependendo da
configurao no sistema operacional). Neste menu temos diversos comandos
que podem ser executados, onde podemos extrair facilmente mais de uma
dezena de requisitos funcionais que nesta funcionalidade (menu de contexto)
so realizados.
Quando o comando Colar especial com a opo Texto sem formatao
executado o contedo que est armazenado na rea de transferncia
colado no corpo do texto, assumindo a formatao padro do local do
documento onde est sendo feita a colagem.
Vejamos como seria a especificao deste Requisito Funcional.
Identificador

RF0019

Nome

Colar sem formatao o texto copiado da rea de

transferncia

Mdulo

Editor de Texto

Data de criao 25/02/2016 Autor

Eckhart

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Descrio

Aps a cpia de algum contedo textual para rea de

transferncia do sistema operacional, o usurio poder
realizar a colagem deste contedo no documento que estiver
editando.

16

A colagem sem formatao dever considerar a formatao

configurada no exato local onde o contedo estar sendo
colado (no documento em edio pelo usurio), assumindo
esta formatao. A formatao contida na origem onde o
texto foi copiado dever ser ignorada.

Este um sub menu que exibido aps o clique no item de menu Ajuda.
Temos diversos comandos no sub menu e vamos analisar o comando Verificar
por atualizaes.
Quando o usurio executa este comando o aplicativo exibe uma janela
onde o resultado da verificao da atualizao exibido.

Vejamos como seria a especificao deste Requisito Funcional.

Identificador

RF0087

Nome

Verificar por atualizaes disponveis

Mdulo

Editor de Texto

17

Data de
criao

25/02/2016 Autor

Eraststenes

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Desejvel

Descrio

O usurio dever ter um recurso para que, sob demanda,

verifique se existem atualizaes disponveis para o
aplicativo, atualizaes que ainda no foram instaladas por
ele.
Esta verificao dever ser feita no servidor do fabricante do
aplicativo e o aplicativo dever exibir para o usurio quais as
atualizaes disponveis, demonstrando qual a verso
instalada na mquina do usurio, e qual a verso atual
disponvel para atualizao.

Obs.: na janela Verificar Atualizaes temos vrios comandos (Ajuda,

Download, Instalar e Fechar). A janela ainda exibe os dados da consulta
verso mais atual disponvel para atualizao. Esta tela um exemplo de como
uma nica funcionalidade realiza vrios requisitos. Ao chamar esta tela o
aplicativo realiza o Requisito Funcional de verificao de atualizaes
(RF0087), e atravs desta mesma tela (funcionalidade) outros requisitos
funcionais so realizados, como os de realizar download da verso para
atualizao e instalar a verso de atualizao.
muito importante refletir sobre a relao de Requisito Funcional e
Funcionalidade.
Como j citado, comum analistas confundirem as duas coisas. E essa
confuso leva a prejuzos para o projeto.
O principal prejuzo o comprometimento do nvel de detalhamento dos
requisitos funcionais, e o no atendimento aos seus atributos de
qualidade. E isso fica pior quando toda a equipe pensa da mesma forma,
pois assim assume-se que o que foi produzido na modelagem de
requisitos est bom.
Onde se confunde Requisito Funcional e funcionalidade geralmente
encontra-se requisitos funcionais como Realizar Pagamento, Emitir

18

Fatura, Transferir dinheiro e coisas do tipo. Neste nvel de detalhe,

conflitos entre usurios e analistas ou entre analistas e programadores,
por exemplo, algo fatal.
A seguir, uma janela de preenchimento de perfil de usurio existente
numa rede social.
Nesta janela temos um menu lateral que possui diversos grupos de
informaes. Para cada grupo, temos comandos diversos utilizados no
preenchimento das informaes.

No menu Trabalho e Educao, temos quatro sub-grupos, cada um com

um comando para adicionar informaes. Aqui temos quatro requisitos
funcionais materializados: Adicionar um local de trabalho, Adicionar uma
habilidade profissional, Adicionar uma faculdade, Adicionar uma instituio de
ensino mdio.
Vejamos como seria a especificao de um destes requisitos:
Identificador

RF0096

Nome

Adicionar um local de trabalho

Mdulo

Perfil do usurio

Data de criao 25/03/2016 Autor

Plotino

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

19

Descrio

O usurio poder inserir informaes sobre trabalho e

educao em seu perfil na rede social. Neste contexto,
dever poder adicionar seus locais de trabalho (empresas
onde trabalhou).
Para cada local de trabalho, dever poder inserir o nome da
empresa, endereo da empresa, data incio e data fim do
perodo em que trabalhou na empresa, e a funo que
exerceu na empresa.
Esta informao poder ser alterada a qualquer momento
pelo usurio, e ser exibida aos seus amigos na rede social.

20

Requisito No Funcional
Requisito No Funcional, como o prprio nome diz, uma no
funcionalidade, ou seja, trata-se de algo que no uma funcionalidade, mas
que precisa ser realizado para que o software atenda seu propsito.
Existe uma definio propagada na literatura de Engenharia de Software
que afirma que um Requisito Funcional define o que o sistema far, e o
requisito no funcional define como o sistema far. Alguns afirmam que um
requisito no funcional especifica como um Requisito Funcional ser
implementado; tambm no uma boa definio, pois uma funcionalidade
teoricamente pode ser implementada sem nenhum requisito no funcional no
projeto e isso no gerar nus nenhum.
Acho que nenhuma dessas definies suficiente, no d para entender
muito bem; tem outra que diz que requisitos No Funcionais so atributos de
qualidade para o sistema, essa eu j acho melhor, mas ainda um pouco
subjetiva.
Um RNF tem como objetivo atender a requisitos do sistema que no so
requisitos funcionais (no se referem a funcionalidades do negcio), mas que
fazem parte do escopo do sistema.
Um RNF pode ou no estar associado a um Requisito Funcional (essa
associao muito comum em requisitos No Funcionais de integrao de
sistemas, por exemplo, pois para cada integrao existe uma necessidade do
negcio de faz-la, necessidade que est descrita em um Requisito Funcional).
Toda necessidade que for realizada atravs de funcionalidades
resultado de um ou mais requisitos funcionais (pois uma funcionalidade pode
realizar vrios requisitos funcionais, no necessariamente apenas um) e toda
necessidade que no puder ser atendida desta forma, um requisito no
funcional geralmente trata-se de premissas e restries tcnicas aplicadas ao
projeto. Acho que essa definio, aparentemente simples, define bem um RNF.

21

Importncia dos Requisitos No Funcionais

Requisitos No Funcionais so to importantes quanto os requisitos
funcionais ou regras de negcio. Infelizmente muito difcil encontrar alguma
empresa que leve isso a srio, e a est a causa do fracasso de muitos projetos
de software.
Existem duas principais causas que justificam a pouca importncia que
os RNFs tem na maioria dos projetos:

Usurios no sabem o que isso

Usurios pensam apenas no negcio, que remete a requisitos funcionais,
e consequentemente, funcionalidades. Apenas em empresas de grande porte,
com uma TI mais estruturada, onde a rea de TI apoia os usurios nos projetos
que se d alguma importncia a RNFs;

RNFs so difceis de estimar

Em termos de volume de trabalho/esforo (horas gastas na produo),
geralmente isso feito baseado na famosa opinio de especialista. Medidas
como Ponto de Funo, Linha de Cdigo, Pontos por Caso de Uso e tcnicas
semelhantes mensuram apenas o que perceptvel para o usurio, e RNFs
geralmente no o so (na ltima verso da Anlise por Pontos de Funo h
algo mais maduro para medir RNFs, mas na minha opinio ainda no atende
por completo). Muitos fornecedores ignoram os RNFs quando no solicitado
explicitamente pelo cliente, pois acham que gastaro mais no projeto.
Dependendo de como se enxerga, RNFs podem ser at mais importantes
que RFs. Se pensarmos num sistema de grande porte (como um ERP para
grandes empresas), no escopo de um sistema como este tem facilmente mais
que cinco mil requisitos funcionais e dez mil regras de negcio. Mas podemos
ter poucas dezenas de requisitos No Funcionais. No meio de cinco mil
requisitos funcionais, deixar de atender no escopo uns poucos provavelmente
no inviabiliza o sistema, no meio de quinze mil regras de negcio idem. Mas
existem RNFs que se no so atendidos, inviabilizam um sistema gigante como
este.
Diferente dos RFs, os RNFs permeiam todo o sistema (geralmente so
utilizados em vrios mdulos do sistema, de maneira horizontal),

22

existem em quantidade muito menor nos projetos se comparado com os

RFs mas possuem uma amplitude enorme no sistema. Um RNF
pertinente usabilidade, por exemplo, algo sobre padro de barra de
rolagem, pode existir em quase todas as telas do sistema.
Para ilustrar, no contexto do ERP citado, vamos imaginar a seguinte
necessidade de um cliente, num cenrio hipottico:
No mdulo de logstica, toda carga deve ser liberada em no mximo 20
minutos, pois temos uma frota de dois mil caminhes que no podem
esperar mais que isso para sair dos armazns. Para a liberao da
carga, um documento de solicitao de liberao de carga deve ser
emitido, e nele anexada a nota fiscal dos produtos contidos no
caminho.
A partir deste cenrio imaginamos que um analista identificou um RNF de
Desempenho (mais frente falaremos sobre as categorias dos requisitos No
Funcionais) nomeado de RNF0087 Tempo limite para processamento de
solicitao de liberao de carga, onde foi especificada a restrio do tempo
de vinte minutos para liberao da carga.
Requisitos No Funcionais so entradas (input) para a definio da
arquitetura tcnica de um software. Em sistemas com alto volume de
processamento e exigncias desafiadoras de tempo de resposta,
projetar e implementar a arquitetura ignorando os requisitos No
Funcionais sacramentar o caos vindouro.
Entretanto, os arquitetos responsveis pela implementao da
arquitetura do ERP no deram a devida importncia ao RNF citado e pensaram
a estrutura do sistema ignorando uma performance otimizada, e esta
necessidade de tempo de resposta ficou relegada para o fim do projeto. Quando
o produto ficou pronto, iniciou-se a homologao. Na primeira bateria de testes
de desempenho o sistema foi reprovado pela rea de logstica, pois estava
demorando 35 minutos, em mdia, apenas para processar a solicitao de
liberao de carga (gerar nota fiscal, anex-la solicitao, processar a
solicitao e rodar o fluxo no sistema at o caminho poder sair do armazm).
Efeito: sistema invivel para produo, necessrio reestruturar sua arquitetura
porque a performance ficou muito ruim. Causa: no atendimento do RNF0087.

23

Reestruturar uma arquitetura no uma atividade trivial. E no geral (no

regra) o impacto de uma reestruturao destas proporcional ao
tamanho do sistema. Quanto maior o sistema, mais problemtico
realizar alteraes arquiteturais.
J presenciei um caso onde a construo de um sistema levou trs
anos para ficar pronta, para ento iniciar a homologao. Quando
comearam os testes, percebeu-se inviabilidade em termos de
performance.
Para constar apenas, no precisava chegar ao fim da construo para
comear os testes, mas o ciclo de desenvolvimento adotado neste
projeto no dava outra opo.
Neste caso, foram necessrios mais 10 meses para reestruturao
(alm do atraso j contrado pelo projeto), oramento adicional de R$
1,2 milhes e desperdcio de ao menos R$ 1 milho em custo de
implementao (horas gastas na implementao errada desta parte
da arquitetura do sistema). Somando tudo, num sistema de grande
porte (4000 pontos de funo), prejuzo de R$ 2,5 milhes.

Estrutura
Estrutura de um Requisito No Funcional
Como no caso dos requisitos funcionais e regras de negcio, no h um
padro estabelecido sobre a estrutura de um RNF. Mas a maioria das empresas
utiliza um formato semelhante, contendo campos especficos. O modelo a
seguir contempla os campos mais relevantes, com posterior descrio de cada
um.
Como citado para a modelagem de requisitos funcionais, o modelo abaixo
aplicvel em especificaes produzidas em Editores de Texto como o
Microsoft Word, por exemplo. recomendado que se utilize, sempre que
possvel, alguma ferramenta Case8 que d suporte a Engenharia de Requisitos,
para melhorar a produtividade na modelagem e a gesto dos requisitos.

https://pt.wikipedia.org/wiki/Ferramenta_CASE

24

Identificador

<<Numero>> Categoria <<Texto>>

Nome

<<Texto>>

Data de
criao

<<Data>>

Autor

<<Texto>>

Data da ltima
alterao

<<Data>>

Autor

<<Texto>>

Verso

<<Numero>> Prioridade <<Texto>>

Descrio

<<Texto>>

Campo

Descrio

Sufixo seguido de um identificador nico. O sufixo geralmente

utilizado RNF (Requisito No Funcional) e o identificador nico
Identificador
geralmente composto de dois dgitos (dificilmente um projeto
ter mais que 99 RNFs).
Categoria

Categoria qual o RNF pertence (Desempenho, Usabilidade,

Padro etc.).

Nome

Nome curto do requisito, mas que possibilite entender bem o

que RNF faz apenas pelo nome.

Data de
criao

Data da criao do RNF, ou a data em que ele foi especificado.

Autor

Profissional que especificou o RNF pela primeira vez, quem o

criou.

Data da
ltima
alterao

Data em que houve a ltima alterao no RNF.

Autor

Profissional que alterou a especificao do RNF pela ltima vez.

Verso

Nmero da verso do RNF. Geralmente utiliza-se algo simples,

como 1, 2. A verso inicial sempre a 1, e a cada alterao
incrementa-se a verso (na criao verso 1, na primeira
alterao verso 2 etc.).

Prioridade9

Se o RNF Essencial, Importante ou Desejvel.

Descrio

Descrio detalhada (a mais detalhada possvel) do RNF.

9 http://www.ateomomento.com.br/priorizacao-de-requisitos/

25

Mais frente teremos vrios exemplos de RNFs, onde poderemos ver o

modelo apresentado com todos os campos preenchidos.

Categorias dos Requisitos No Funcionais

Para uma melhor organizao da especificao e semntica do projeto do
software, RNFs so separados por categorias, conforme o propsito de cada
requisito. A seguir, a lista das principais categorias existentes:
Categoria

Referente a

Desempenho

Desempenho do sistema, restries de performance,

tempo de resposta em processamentos especficos,
cargas, velocidade de resposta de processamentos em
telas etc.

Disponibilidade

Disponibilidade do sistema em tempo til, restries sobre

janelas de manuteno, janelas de produo, solues de
contorno quando houver queda de energia etc.

Segurana

Diretrizes pertinentes segurana do sistema, como

algoritmo de criptografia a ser utilizado, regras para
criao e manuteno de usurios e senhas, uso de
certificados digitais, uso de protocolos seguros
especficos, uso de captcha etc.

Necessidades de integrao do sistema com outros

Interoperabilidade sistemas, integrao com APIs10, componentes, banco de
dados externos etc.

Usabilidade

Quantidade mxima de cliques por tipo de funcionalidade,

uso de componentes e lgicas de telas especficas,
restrio/premissas para uso de componentes grficos
(grids, barras de rolagem, menus), recursos de
acessibilidade para deficientes, compatibilidade com
idiomas etc.

Compatibilidade

Browser e sistemas operacionais nos quais o software

dever rodar, verses de browser e sistemas
operacionais, protocolos compatveis, verses de
linguagens de programao e banco de dados para
retrocompatibilidade etc.

10http://www.ateomomento.com.br/o-que-e-api/

26

Categoria

Referente a

Confiabilidade

Polticas para backup do sistema e seus dados,

quantidade limite de erros em clculos e processamentos
com erro, regras para rollback quando houver alguma
falha, recursos para restaurao automtica do sistema
em caso de queda de energia etc.

Padres

Padres em geral, aplicveis ao software e ao projeto:

padro de log de erro, de log de informao, padro de
mensagens, metodologia para desenvolvimento do
sistema, padres de projeto (design patterns) a serem
aplicados, padres arquiteturais etc.

Legais

Exigncias de conformidade do software com alguma

legislao pertinente ao projeto, por exemplo,
atendimento a alguma norma da Agncia Nacional de
Sade para software de hospital, a norma do Banco
Central para sistemas financeiros etc.

Exemplos por categoria

A seguir, vamos ver um exemplo de RNF para cada categoria listada
anteriormente.
Muitos profissionais de software acham que um RNF geralmente algo
subjetivo, mas com base nos exemplos a seguir podemos ver que no, basta
que sejam especificados com clareza e nvel de detalhes suficientes (e
necessrios) para um bom entendimento. Obs.: para identificar a qual categoria
pertence o RNF observe o campo pertinente (campo Categoria).
Identificador

RNF01

Categoria Desempenho

Nome

Tempo limite para processamento de todos os lotes de

fatura na rotina diria

Data de
criao

18/01/2016 Autor

Alexandre de Afrodsias

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Descrio

No mdulo de faturamento o processamento de faturas em

lote um processo oneroso em termos de memria e CPU

27

devido ao alto volume de dados. Em funo desta realidade

o sistema dever prover recursos para processamento
paralelo (multithreading) que possibilite processar lotes de
faturas de forma paralela, compactando o tempo de
execuo da rotina diria.
A mdia diria de faturas a serem processadas 80.000.
Cada lote contm 500 (quinhentas) faturas, totalizando 160
(cento e sessenta) lotes. A janela de produo disponvel
para o processamento de todos os lotes de 4h.
Considerando as medidas acima, o sistema deve processar
todos os 160 lotes em, no mximo, 4h. Para atender isso, o
sistema dever rodar os lotes na quantidade mxima
permitida de threads, considerando a seguinte especificao
do servidor de aplicativos:
- 16 processadores com quatro ncleos cada.
- 64 GB de memria RAM.
- 1 TB de espao em disco.
Obs.: deve haver no sistema alguma funcionalidade ou
arquivo de configurao onde seja possvel o prprio analista
da TI parametrizar a quantidade de threads que o sistema
dever rodar. Esta informao no pode ser fixada em cdigo
e nem ser de domnio apenas do fornecedor que
implementar a soluo.
Identificador

RNF02

Categoria Disponibilidade

Nome

Utilizao do mdulo de Informaes Cadastrais em modo

off-line

Data de
criao

25/01/2015 Autor

Aristarco de Samos

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Importante

Descrio

O mdulo de Informaes Cadastrais um mdulo do CRM

que precisa funcionar 24 x 7 (vinte e quatro horas por dia,

28

sete dias por semana) na operao do Call Center da

empresa. Por isso necessrio que o sistema possua
recursos para sua utilizao em modo off-line, pois em
nossa infraestrutura no possvel ter garantia de 100% de
disponibilidade do servidor de banco de dados. Para
informao, a garantia atual de 89% de disponibilidade do
ambiente.
Todos os registros de clientes cadastrados no mdulo
podero ser mantidos (alterados/consultados/excludos) com
o sistema off-line e novos registros de clientes (incluso)
podero ser includos tambm com o sistema off-line. Todos
os relatrios do mdulo de informaes cadastrais tambm
precisaro rodar off-line.
Cada usurio do mdulo dever ter em sua estao de
trabalho uma cpia do banco de dados do mdulo citado,
sempre com a mesma verso do modelo de dados utilizado.
Dever haver uma rotina no banco de dados do sistema
(banco hospedado no servidor da aplicao) que a cada
operao de incluso/alterao/excluso de registros nas
tabelas do mdulo de informaes cadastrais sincronize
estas atualizaes com as bases de dados locais de cada
usurio, para manter a massa de dados na mesma posio.
Sempre que o usurio abrir o sistema uma funo dever
verificar se h conectividade com o servidor de banco de
dados. Se houver, dever conectar neste ambiente
(servidor), seno, dever conectar na verso do banco de
dados local da aplicao.
O sistema dever ainda ser preparado para fazer
sincronizao dos dados includos/alterados/excludos
quando no uso do banco de dados local (sistema off-line), e
na sincronizao de volta (banco local para banco no
servidor), verificar se mais de um usurio manteve um
mesmo registro, e realizar merge para que no haja
defasagem/perda de dados.

29

Identificador

RNF03

Categoria Segurana

Nome

Autenticao de usurio para consumo de webservices do

sistema por sistemas externos

Data de
criao

30/01/2016 Autor

Andr Comte Sponville

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Todas as APIs11 do sistema expostas como webservices

podero ser acessadas por sistemas externos de clientes,
fornecedores e parceiros. Este acesso precisa ser seguro,
com autenticao em nvel do servidor e em nvel da
aplicao.
Para autenticao no nvel de servidor, o IP de cada
consumidor dos webservices dever ser cadastrado no
servidor web onde o sistema estar hospedado, com acesso
para execuo de scripts. H uma poltica de segurana que
revisa a validade destes acessos a cada ms, isso deve ser
considerado no tratamento de excees no contexto deste
requisito.
Descrio

Para autenticao no nvel da aplicao, cada consumidor

dos webservices dever possuir um usurio ativo no sistema.
A senha do usurio dever ser gravada/trafegada utilizandose o algoritmo SHA-3 para criptografia.
O sistema no poder permitir cache de senha, salvamento
de senha ou qualquer outro recurso do tipo. A cada novo
acesso, a autenticao dever ser realizada novamente, de
maneira integral.
Dever haver uma poltica de segurana que assegure que,
a cada ms, a senha de cada um dos usurios citados expire
e precise ser renovada, e que tenha critrios de
complexidade alta de senhas (vide o documento da rea de

11

http://www.ateomomento.com.br/o-que-e-api/

30

infraestrutura da empresa que tenha detalhes sobre os nveis

de complexidade exigidos para cadastro de senhas); tudo
isso deve ser considerado no tratamento de excees no
contexto deste requisito.
Identificador

RNF04

Categoria Interoperabilidade

Nome

Integrao com sistema do Banco Central para envio de

informaes de transferncia internacional de valores

Data de
criao

30/01/2016 Autor

Ren Descartes

Data da ltima
N/A
alterao

Autor

Verso

Prioridade Essencial

N/A

Diariamente, em janela de produo especfica, o sistema

dever enviar para o BACEN (Banco Central) as informaes
do processamento dirio (sempre com um dia de atraso, ou
D-1) de transferncias internacionais de valores realizadas
pelo banco.

Descrio

A integrao se dar por envio de arquivo texto, a ser

confeccionado conforme layout especfico para o arquivo
CI03. Os dados do layout para o arquivo citado devem ser
obtidos em https://www.bcb.gov.br/?INFOL,
pgina do site do BACEN que mantm atualizadas as
informaes sobre o layout do arquivo CI03. O protocolo a
ser utilizado para transmisso o FTP, mas por razes de
segurana do BACEN, a porta utilizada nunca a 21. A
conexo autenticada, com usurio e senha que o BACEN
fornece ao banco. Para o sistema transmissor, o usurio e
senha no precisam ser criptografados no ato da abertura da
conexo FTP com o BACEN.
Dever haver um recurso no sistema que permita avisar ao
administrador do sistema, por e-mail e SMS (sempre ambos),
quando a transmisso no for bem-sucedida, detalhando
qual a causa do insucesso. Este mesmo recurso deve permitir
que, aps interveno humana (seja nos dados que populam

31

o arquivo ou nas configuraes do sistema), possa ser

realizada a retransmisso dos arquivos.
Todo o processo de envio/reenvio do arquivo dever ser
logado. Os logs devem ser gravados em arquivo texto quando
o envio for bem-sucedido, e quando no for, em arquivo texto
e no Event Viewer do servidor de aplicaes onde o sistema
estar hospedado.

Para RNFs de integrao (categoria Integrao) que envolvam layouts

de arquivos, estrutura de arquivos xml ou algo do tipo recomendado
que se detalhe a estrutura do arquivo (layout) no corpo do RNF, ou que
se faa referncia a algum documento que contenha os detalhes de tal
estrutura. Quando no h esta especificao muito comum faltar
campo, ter campos com tipos errados, validaes no passarem etc. e
isso sempre gera muitos problemas.
Identificador

RNF05

Categoria Usabilidade

Nome

Uso de design responsivo nas interfaces grficas

Data de
criao

30/01/2016 Autor

Digenes de Apolnia

Data da
ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Importante

O sistema de Atendimento a Clientes ser construdo para

rodar em ambiente web. Dever possui um design responsivo
(https://en.wikipedia.org/wiki/Responsive_web_design).

Descrio

A interface do sistema dever se comportar adequadamente

independente do front-end que ser utilizado para acesso
Browser, Smartphone ou Tablet.
Obs.: durante o processo de homologao do sistema sero
realizados testes de usabilidade validando este requisito. O no
atendimento a este requisito gerar o no pagamento relativo

32

 frao pertinente funcionalidade que no for homologada,

segundo os critrios aqui apresentados.
Identificador

RNF06

Categoria Compatibilidade

Nome

Compatibilidade com sistemas operacionais Windows e

Linux

Data de
criao

30/01/2016 Autor

Friedrich Engels

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

O parque da empresa composto, nas estaes de trabalho,

por sistemas operacionais Linux e Windows. Para Linux a
variante utilizada o Ubuntu a partir da verso 15.10, para
Windows utiliza-se verses a partir do XP (XP, Vista 7 e 8),
considerando sempre o Service Pack mais recente.
Para ambos os sistemas so aplicadas rigorosamente as
atualizaes dos fabricantes, sempre que so liberadas.

Descrio

O sistema, por se tratar de um aplicativo desktop em

arquitetura cliente/servidor, dever rodar nos sistemas
operacionais elencados neste requisito considerando as
demais informaes aqui descritas. O comportamento deve
ser o mesmo para qualquer um dos sistemas operacionais
relacionados, tanto no que se refere s funcionalidades
quanto instalao.
Obs.: para este requisito haver garantia do fornecedor do
sistema para que os releases do aplicativo mantenham
retrocompatibilidade com os sistemas operacionais citados.
Esta garantia vigorar enquanto o contrato de manuteno
estiver vigente.

Identificador

RNF07

Categoria Padres

Nome

Diviso arquitetural do sistema em camadas para

desacoplamento

33

Data de
criao

30/01/2016 Autor

Empdocles

Data da ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

O projeto do software dever ser fortemente orientado a

baixo acoplamento e alta coeso, primando pela melhor
separao de responsabilidades.
Todo o projeto dever ser feito utilizando uma arquitetura
separada em camadas, onde cada camada conter apenas
os algoritmos relacionados sua responsabilidade. Abaixo
as camadas que devero ser utilizadas, e suas
responsabilidades:

Descrio

Interface: abrigar lgicas de tela, validao de campos,

acionamento de comandos, cdigos para design de interface
etc. Obs.: Para esta camada dever ser utilizado o code
behind de cada tela, no podendo ser criada uma camada
adicional.
Negcio: abrigar lgicas de negcio, onde ser codificado o
escopo das regras de negcio associadas aos requisitos
funcionais pertinentes funcionalidade.
Dados: abrigar lgicas de acesso a dados, comandos SQL
ou comandos para utilizao de mecanismos de persistncia
utilizado, para o caso de uso de ORM.
Segurana: abrigar lgicas de autenticao, auditoria,
manuteno de usurios.
Infraestrutura: abrigar lgicas no relacionadas a interfaces
grficas, regras de negcio, dados ou segurana, mas que
podero ser utilizadas em todas estas camadas. Conter
recursos para gravao de logs, transferncia de arquivos,
mensagens, envio/recepo de e-mails etc.
Obs.: em nenhuma das camadas sero permitidos mtodos
com mais de 40 linhas de cdigo.

34

Identificador

RNF08

Categoria

Legais

Nome

Atendimento instruo normativa 554 da ANS (Agncia

Nacional de Sade)

Data de
criao

30/01/2016 Autor

Hipcrates

Data da
ltima
alterao

N/A

Autor

N/A

Verso

Prioridade Essencial

Para atendimento instruo normativa 554 da ANS, o mdulo

de pronturio dever gravar em todas as suas tabelas as
informaes de data/hora do atendimento realizado e dados
do mdico que realizou o atendimento (CRM e nome
completo). Estas informaes podero ser solicitadas pela
ANS h qualquer momento, sem aviso prvio.
Para atender este requisito, cada tabela do mdulo de
pronturio dever conter as colunas abaixo, com as
respectivas configuraes:
Campo

Descrio

DTHRATE
ND

Data e hora em Dateti

que
o
mdico me
atualizou
o
pronturio.

NMMEDIC
O

Nome do mdico Varch Sim

que atualizou o ar(100
pronturio.
)

CRMMEDI
CO

CRM do mdico Varch

que atualizou o ar(10)
pronturio.

Descrio

Tipo

Obrigatrio
Sim

Sim

Dever ser criado um relatrio no mdulo correspondente do

sistema, onde conter a informao deste requisito. Este
relatrio ser utilizado numa eventual visita dos fiscais da ANS,
ou caso a ANS solicite envio de comprovao do atendimento
norma 554.

35

Regra de Negcio
Deduzo que antes do lanamento do microcomputador o termo Regra de
Negcio era algo interpretado totalmente isolado dos softwares empresariais,
ou talvez nem fosse um termo conhecido pelas pessoas.
Nos tempos atuais difcil encontrar algum que entende Regra de Negcio
como algo isolado do software. Quando se fala Regra de Negcio,
praticamente sempre no contexto de um sistema. possvel uma empresa
mais arcaica viver sem software, mas no consegue viver sem regras de
negcio.
Para ilustrar isso, imaginemos uma empresa que possui um departamento
de expedio de materiais, mas que no possui software para automatizar as
atividades deste departamento. Vejamos o cenrio abaixo:
Sempre que uma pessoa se dirigir ao departamento de expedio para
solicitar uma mercadoria esta pessoa deve se identificar com seu
documento de identidade. O profissional do departamento de expedio
deve certificar-se que o documento vlido.
Aps checar que o documento vlido, o profissional dever pegar o
documento de protocolo de entrega com a pessoa, e neste documento
conter a seo e caixa onde se encontra a mercadoria.
Dever ento dirigir-se seo, na caixa identificada, pegar o material e
levar ao guich para entrega pessoa que o solicitou. Antes de realizar
a entrega, dever solicitar que a pessoa assine o livro de entregas,
incluindo seu documento e dados de endereo. No livro tambm devem
ser escritos os dados da mercadoria (nome, categoria, marca e modelo),
nome do profissional que fez a entrega, e data e hora da entrega.
Se a mercadoria solicitada no estiver na seo e caixa onde deveria
estar, o profissional do departamento dever entrar em contato com a
gerncia para reportar o problema. O mesmo deve ser feito caso
identifique-se que o documento da pessoa que est buscando o material
no vlido.

No cenrio acima percebemos que a operao do departamento de

expedio vivel sem um software, e que existem uma srie de critrios e

36

restries para que o material seja entregue ao seu solicitante. Os critrios e

restries informados so regras, e regras da empresa (negcio) que faz as
entregas. Logo, so regras de negcio.
Regras de negcio so restries aplicadas a uma operao comercial de
uma empresa, que precisam ser atendidas para que o negcio funcione da
maneira esperada.
Um software tem como objetivo automatizar atividades de uma empresa.
Isso se dar atravs da criao de funcionalidades, que realizaro requisitos
funcionais. Mas os requisitos funcionais, como citado anteriormente, definem
quais so as necessidades/exigncias da empresa em termos funcionais (que
funcionaro atravs de um sistema), ou seja, o que o sistema dever fazer.
As regras de negcio definem como o sistema far o atendimento s
necessidades/exigncias definidas; uma RN pode ser compreendida quanto a
como um Requisito Funcional se realizar.

Importncia das Regras de Negcio

E raro, muito raro mesmo, encontrar um Requisito Funcional que no
possua dependncia com uma ou mais regras de negcio. Em funo disso,
RNs so to importantes quanto RFs. Um RF no identificado ou no realizado
pode gerar um dbito tcnico12 srio de escopo, mas uma RN mal especificada
pode gerar mais nus ainda, pois o sistema poder contrair bugs em funo
disso.
Ou seja, a funcionalidade existir, mas estar processando o que tem que
processar de maneira errada, e detectar isso aps a construo do sistema se
a Regra de Negcio estiver especificada incorretamente algo praticamente
impossvel, s quando o sistema for para produo e parar na mo do cliente.
Isso o pior cenrio possvel.

Atributos de uma boa Regra de Negcio

Uma RN com qualidade precisa atender a alguns atributos especficos.
Na literatura, tanto nacional quanto estrangeira, no h material (ao menos que
eu conhea) que especifique estes atributos para RN. Entretanto, devido
estrutura sinttica de uma RN ser muito semelhante de um RF, eu elenquei
alguns atributos (alguns comuns aos RFs) a serem considerados na
12

http://www.ateomomento.com.br/o-debito-tecnico/

37

especificao de uma RN. A seguir a lista dos atributos que considero

relevantes.
Atributo

Referente a

Unidade

A RN deve propor/viabilizar uma nica coisa apenas. No

deve atender a mais de uma restrio. A RN Clculo de
salrio no unitria, pois se refere implicitamente a clculo
de qualquer tipo de salrio, e em qualquer empresa existem
formas diferentes de calcular salrio (para profissional ativo,
aposentado, estagirio, efetivo, licenciado etc.). Esta RN
assume assim vrias responsabilidades, quando deveria
assumir apenas uma.

Completude

A RN deve ser autocontida, deve ter incio/meio/fim, ser

completa. A RN Clculo de salrio no completa, s conta
parte da estria. Para ser completo deveria ser algo como
Clculo de salrio para profissionais afastados h mais de 15
dias.

Consistncia

No deve contradizer outra RN do mesmo escopo do projeto.

como termos duas RNs se propondo a fazer uma mesma
coisa, mas cada RN se propondo a fazer esta coisa de formas
diferentes.

Atomicidade

Uma RN para ser atmico precisa tambm ter unidade, pois

atomicidade remete a assumir apenas uma responsabilidade.
Mas tambm, deve ser indivisvel, no podendo ser
decomposta. Muitos RNs possuem conjuno, dependem de
outras para se realizar. Onde temos duas RNs Calcular juros
para pagamento atrasado e Incluir juros para pagamentos
de financiamento imobilirio atrasados na realidade, se
pensarmos em atomicidade, temos uma nica RN que
Calcular juros para pagamentos atrasados de financiamento
imobilirio.

NoAmbiguidade

No pode ser ambgua, definir algo que no fica claro o que

. A RN Critrios para processamento de faturas ambgua.
Fatura de que, critrios para processar o que? Critrios para
processamento de fatura de mensalidade j melhor, mas
ainda ruim. Mensalidade de que? Seria no ambguo se no
deixasse dvidas, algo como Critrios para processamento
de faturas de mensalidades de alunos do segundo grau ou

38

Atributo

Referente a
Critrios para processamento de faturas de mensalidades de
qualquer aluno impendente de srie.

Verificvel

No adianta ter uma RN se ele no palpvel, possvel de

associar com um RF que ser construdo, testado etc. Uma
RN tem que ser testvel, tem que ser possvel atestar que a
RN foi atendida atravs de algum RF. Para isso tem que ser
tambm rastrevel.

Rastrevel

Deve ser possvel achar a RN no sistema pronto. Como saber

se uma RN foi atendida? Para isso necessrio ter
rastreabilidade, e isso s possvel ligando as pontas
(associar a RN ao RF, associar o RF interface grfica, que
ser associada a um caso de uso, que ser associado a
funcionalidades, que sero implementadas etc.).

Muitas RNs tratam de clculos, frmulas, algoritmos etc. Uma

RN deve poder ser exemplificada fora do contexto do sistema,
Exemplificvel
para assim facilitar o entendimento de seu escopo pelos
profissionais que a implementaro/validaro.
Um detalhe importante que uma RN no possui prioridade. Como uma
RN, no contexto de um sistema, somente existe se associada a um ou mais
Requisitos Funcionais, a prioridade aplicada RN ser a prioridade aplicada ao
requisito que depende dela.

Estrutura de uma Regra de Negcio

No h um padro estabelecido sobre a estrutura de um RN. Mas a
maioria das empresas utiliza um formato semelhante, contendo campos
especficos. O modelo a seguir contempla os campos mais relevantes, com
posterior descrio de cada um.
Identificador

<<Numero>>

Nome

<<Texto>>

Data de
criao

<<Data>>

Autor

<<Texto>>

Data da ltima
alterao

<<Data>>

Autor

<<Texto>>

Verso

<<Numero>>

Dependncias <<Texto>>

39

Descrio

<<Texto>>

Campo

Descrio

Identificador

Sufixo seguido de um identificador nico. O sufixo

geralmente utilizado RN (Regra de Negcio) e o
identificador nico geralmente composto de quatro dgitos
(podendo ser mais, conforme a o tamanho do sistema que
est sendo especificado).

Nome

Nome curto da RN, mas que possibilite entender bem o que

RN faz apenas pelo nome.

Data de
criao

Data da criao do RN, ou a data em que ela foi

especificada.

Autor

Profissional que especificou a RN pela primeira vez, quem a

criou.

Data da
ltima
alterao

Data em que houve a ltima alterao no RN.

Autor

Profissional que alterou a especificao da RN pela ltima

vez.

Verso

Nmero da verso do RN. Geralmente utiliza-se algo

simples, como 1, 2 etc. A verso inicial sempre a 1, e a
cada alterao incrementa-se a verso (na criao verso 1,
na primeira alterao verso 2 etc.).

Dependncias

Quais RFs so dependentes da RN para serem realizados.

Coloca-se apenas o identificador dos RFs.

Descrio

Descrio detalhada (a mais detalhada possvel) da RN.

Exemplos
Vejamos alguns exemplos de RN. Para os exemplos utilizei o cenrio
descrito anteriormente para a empresa que possui o departamento de
expedio de materiais (entregas). Os RFs que dependem destas RNs no
esto especificados, so fictcios. Utilizaremos apenas o identificador dos RFs
(RF0099 Realizar entrega presencial de material no departamento de
expedio e RF0002 Informar por e-mail o gerente do departamento de
expedio sobre ausncia de material no almoxarifado).

40

Identificador

RN0001

Nome

Validao da identificao da pessoa que solicita a

retirada/entrega do material

Data de
criao

31/01/2016 Autor

Nagarjuna

Data da ltima
N/A
alterao

Autor

Verso

Dependncia RF0099

N/A

Sempre que uma pessoa se dirigir ao departamento de

expedio para solicitar uma mercadoria esta pessoa deve se
identificar com seu documento de identidade. O profissional
do departamento de expedio deve certificar-se que o
documento vlido.
Descrio

Para validar o documento fornecido pela pessoa o nmero do

documento dever ser validado no sistema da Secretaria de
Segurana Pblica do Estado de So Paulo, atravs de
funcionalidade correspondente no mdulo de controle de
expedio. Se o documento no tiver como rgo emissor
SSP-SP, no precisar ser validado, mas dever ser
microfilmado e ter uma cpia armazenada no sistema,
atravs de funcionalidade especfica.

Identificador

RN0002

Nome

Localizao automtica do material solicitado para ser

entregue

Data de
criao

31/01/2016 Autor

Nicolau de Cusa

Data da ltima
N/A
alterao

Autor

Verso

Dependncia RF0099

Descrio

N/A

Aps checar que o documento vlido (vide RN0001) o

profissional dever pegar o documento de protocolo de
entrega com a pessoa.
O nmero do protocolo entregue pela pessoa que solicitou o
material dever ser informado no sistema, que aps insero

41

do nmero do protocolo dever informar qual a seo e caixa

em que o material se encontra.
Se a pesquisa atravs do identificador do protocolo no
informar a seo e caixa em que o material est armazenado,
o sistema automaticamente dever enviar um e-mail ao
gerente do departamento para cincia e providncias,
informando qual o material (nmero de registro, marca e
modelo), quem depositou o material na seo/caixa quando
o material chegou ao almoxarifado, em qual seo/caixa o
material deveria estar, data e hora em que o protocolo foi
emitido, e data e hora em que a entrega foi solicitada.
Identificador

RN0003

Nome

Formalizao da entrega do material solicitado

Data de
criao

31/01/2016 Autor

Parmnides

Data da ltima
N/A
alterao

Autor

Verso

Dependncia RF0099, RF0002

N/A

Aps a coleta do material a ser entregue pelo profissional do

departamento de expedio, a entrega dever ser
formalizada via sistema, onde ocorrer o registro da liberao
do material atravs de um termo de liberao de material.

Descrio

No termo de liberao de material a ser emitido, dever conter

as seguintes informaes: nome e e-mail da pessoa qual o
material foi entregue, nome do profissional que entregou o
material, nome, categoria, marca e modelo do material, data
e hora em que a entrega foi realizada.
O termo de liberao deve ser impresso e assinado pela
pessoa que recebeu o material, e posteriormente
armazenado em local apropriado (no dever ser
armazenado no sistema).

42

Diferenas entre Requisito

Funcional e Regra de Negcio
Eu imagino que antes do lanamento do microcomputador, o termo
Regra de Negcio era algo interpretado totalmente isolado dos softwares
empresariais, ou talvez nem fosse um termo conhecido pelas pessoas.
Nos tempos atuais difcil encontrar algum que entende Regra de
Negcio como algo isolado do software. Quando se fala Regra de Negcio,
praticamente sempre no contexto de um sistema.
Estes dois conceitos (Requisito Funcional e Regra de Negcio) se
encontram (se cruzam) a toda hora na modelagem de um sistema, mas so
coisas diferentes. possvel uma empresa mais arcaica viver sem software,
mas mesmo uma empresa arcaica no consegue viver sem regras de
negcio.
As regras de negcio so restries/premissas necessrias para o
negcio acontecer. E esto em todo lugar, inclusive no nosso corpo. Neste
post, mais frente, vamos ver dois exemplos superficiais de regras de negcio
contidas em nosso corpo, e de requisitos funcionais relacionados.
Nosso corpo no bem uma empresa, mas pode ser encarado desta
forma. Somos o responsvel por administr-lo, e se cuidarmos dele como
um bom empresrio cuida de seu negcio, provavelmente teremos
excelentes resultados.
Por agora, vamos pensar num negcio mais palpvel. Vamos pensar
num negcio de venda de coco na praia, executado e administrado por um
vendedor, que uma pessoa fsica.
Este vendedor pode controlar suas vendas num aplicativo de seu
smartphone; sim, pode.
Mas pode tambm manter seu negcio sem isso (sem automatizar seu
controle atravs de um aplicativo num smartphone). Mas ele no conseguir
trabalhar sem ter suas regras de negcio, mesmo que ele no saiba o que
uma Regra de Negcio.

43

Exemplo
Exemplo num negcio real

Vejamos abaixo algumas regras de negcio inerentes ao negcio de

vender coco na praia:
O coco somente ser entregue ao cliente que realizar o pagamento.
Somente sero aceitos pagamentos em dinheiro vivo. No sero aceitos
cartes de crdito, carto de dbito ou cheque.
Clientes que comprarem 4 cocos ganharo um coco de graa. Esta promoo
no ter data para trmino.
Quando a caixa de isopor (onde ficam os cocos) ficar sem gelo o vendedor
dever parar, abastecer a caixa com gelo e somente a continuar a vender.
O vendedor dever portar ferramenta que permita furar o buraco no coco para
que o cliente possa beb-lo. Esta ferramenta no pode ser cortante nem
serrilhada nas bordas.
O vendedor dever portar canudinho e fornec-lo ao cliente ao entregar-lhe
o coco, para que o cliente possa beb-lo. Sempre dever oferecer o canudinho,
mas dever abri-lo aps o cliente aceitar recebe-lo, pois se o cliente no quiser,
uma vez no aberto o canudinho (no tirado o plstico), no haver desperdcio
deste material.

44

Poderamos elencar dezenas de outras regras de negcio do contexto

apresentado, mas com as descritas j fica claro que Regra de Negcio existe
sem sistema, e que uma empresa no existe sem regras de negcio.
Sistemas no existem sem regras de negcio e nem todas as regras de
negcio so automatizadas atravs de um sistema. Pode at ter um
sistema sem regras de negcio, apenas com requisitos funcionais por
exemplo, mas seria um sistema que permitiria fazer muita coisa de
qualquer jeito, e at hoje acho que ningum fez isso pois seria algo muito
catico. E nem toda Regra de Negcio realizada por um sistema.
Existem procedimentos (por exemplo pegar caf no escritrio sempre
que ficar com sono aps o almoo) que geralmente no so
automatizados via software.
Se o vendedor de coco contratar um profissional para implementar um
software para ajud-lo nas vendas, parte destas estas regras devero ser
atendidas no sistema. Mas no sero requisitos funcionais, sero regras de
negcio.

Diferena de Requisito Funcional e Regra de

Negcio
A diferena entre Requisito Funcional e Regra de Negcio,
conceitualmente falando, que o Requisito Funcional se refere o que o
sistema dever fazer, enquanto a Regra de Negcio refere-se a como o
sistema dever fazer.
Do ponto de vista do negcio (negcio do cliente para o qual o sistema
est sendo feito), ambos so necessidades (Requisito Funcional e Regra de
Negcio), mas cada uma com um foco diferente.
Uma boa dica para saber o que Regra de Negcio perceber quando
h condies: somente, quando, requer, se, obrigatrio, sempre.
Requisitos no possuem condies, regras so condies. Requisitos
so aes objetivas, desejo, solicitao.

45

Mais sobre a Venda de Coco

Ainda no exemplo do vendedor de coco, teramos requisitos funcionais
como:
Processar venda de coco.
Aplicar promoes vigentes na realizao da venda.
Calcular quantidade de gelo conforme o tamanho da caixa de isopor.
Calcular quantidade de canudinhos para a quantidade de cocos contidas na
caixa de isopor.
Incluir desconto padro na venda de cocos.
Vemos acima que os requisitos funcionais so de fato o que o sistema
dever fazer, tratando das necessidades, desejos, solicitaes a serem
materializadas no sistema. Como isso ser feito, no que diz respeito s
restries de negcio, as regras diro.
No dia a dia, o Analista de Sistemas tende a confundir as duas coisas, e
isso gera uma sria de prejuzos ao projeto. Dois bem srios so:
Impossibilidade de se fazer reuso de Regras de Negcio: vrios requisitos
frequentemente realizam regras de negcio comuns. As regras de negcio so
associadas a requisitos, que as realizam. No havendo reuso, fatal que
haver mais de uma Regra de Negcio com o mesmo escopo (regras
repetidas). E provavelmente, isso ser codificado mais de uma vez no
software, uma vez que o norte do desenvolvimento so os requisitos.
No escopo/projeto de um sistema, nada deve ser repetido, isso deve ser
mantra para um profissional da rea. Essa boa prtica/premissa uma
das mais importantes, pois se uma mesma coisa est em dois lugares,
uma mesma coisa foi feita duas vezes e gerou custo dobrado para isso;
so dois pontos de bug em potencial, so dois pontos para manuteno
de uma mesma coisa etc.

46

 Violao do princpio da responsabilidade nica13 (princpio que se aplica

a qualquer artefato de produo de um software, no somente a modelos de
cdigo fonte): Uma Regra de Negcio tem a responsabilidade de restringir
algo, baseado na condio que considerada em seu escopo. Um Requisito
Funcional um objetivo que o sistema dever alcanar, uma funo que o
sistema dever realizar.
Misturar isso faz com que um requisito assuma a responsabilidade de
uma regra, e vice-versa. Essa mistura gera alto acoplamento em nvel de
especificao (pois se no se separa um do outro, naturalmente que o escopo
ficar misturado tambm), o que dificulta separar as responsabilidades dos
requisitos e regras adequadamente, favorecendo assim que na construo seja
gerado um sistema com forte acoplamento e baixa coeso (pois a
especificao insumo para construo).
Dezenas de problemas poderiam ser descritos, mas os citados acima
(acho) j do uma ideia do prejuzo causado por esta confuso.
No final, so conceitos simples (Requisito Funcional = o que o sistema
far Regra de Negcio = como o sistema far), que se bem entendidos
favorecem muito o sucesso do projeto. Pode parecer um pouco complicado no
incio, mas a partir da prtica vai ficando mais claro, menos abstrato.

Exemplos no Corpo Humano

13

http://www.ateomomento.com.br/s-o-l-i-d-srp-single-responsibility-principle/

47

Nosso corpo uma mquina perfeita. Atravs da observao14 podemos

aprender tudo analisando o corpo, de anlise de sistemas artes.
Temos o sistema digestivo. comum associarmos isso ao estmago,
principalmente. Nosso estmago tem como funo principal digerir os
alimentos.
E sabemos que, quando nosso estmago est cheio (cheio mesmo, no
limite), se enviarmos mais alimento para digesto, este alimento no conseguir
ficar armazenado, ento, dever ser colocado para fora (isso acontece pelo
famoso vmito).
Temos ento, a grosso modo, um Requisito Funcional e uma Regra de
Negcio.

Requisito Funcional
Digerir os alimentos inseridos atravs da boca e transportados pelo tubo
digestivo.

Regra de Negcio
Expelir alimentos pelo tubo digestivo quando houver o preenchimento de 100
por cento do espao do estmago.
Consideremos ainda outro contexto presente no corpo humano, ainda no
mundo do comer. Quando engolimos o alimento de maneira errada, ou
tentamos engolir algo que no passa pela traqueia, ocorre o engasgo. Vejamos
um Requisito Funcional e uma Regra de Negcio neste contexto.

Requisito Funcional
Absorver ar pelas vias areas a partir de inalao pelo nariz.

Regra de Negcio
Viabilizar um engasgo quando houver bloqueio das vias reas por entupimento.

14

https://pt.wikipedia.org/wiki/Observao

48

Um exemplo no software, para fechar

Vejamos o programa Ping15, existente em qualquer sistema operacional.
Este programa serve para verificar se h conectividade entre o host local e
um host qualquer. Essa conectividade verificada atravs do envio de pacotes
ICMP16 para o host destino, e se este host receber o pacote envia um retorno
que o programa entende e interprete.
Supondo que estamos especificando o programa Ping logo este o
nosso escopo podemos ento identificar (com base nas imagens a seguir o
programa faz mais coisas alm do que descrevi) os seguintes Requisitos
Funcionais:

Requisito Funcional
Enviar pacotes ICMP para o host destino e monitorar o retorno do envio.

Requisito Funcional
Exibir estatsticas do envio dos pacotes ICMP ao trmino da execuo do
programa.
E, para cada contexto representado pelas imagens, algumas regras de
negcio tambm.

Nesta imagem, temos um retrato da execuo de um Ping do meu host

para o host do meu blog. O teste no foi bem-sucedido, pois os pacotes ICMP
expiraram (TTL17 estourou).

15

https://pt.wikipedia.org/wiki/Ping
https://pt.wikipedia.org/wiki/Internet_Control_Message_Protocol
17
https://www.vivaolinux.com.br/dica/Entendendo-o-campo-TTL-do-Ping
16

49

Regra de Negcio
O envio dos pacotes ICMP dever se repetido quatro vezes por cada execuo
do programa. Mesmo que o TTL dos pacotes ICMP do primeiro envie esgote,
as trs tentativas de envio restantes devero ser executadas.

Nesta imagem, no foi possvel sequer realizar a resoluo do nome

(traduzir o nome do domnio em IP [DNS18]).

Regra de Negcio
Interromper execuo quando no for possvel realizar a traduo do nome do
domnio para um endereo IP.

E nesta imagem, a execuo foi bem-sucedida, o programa conseguiu

realizar a traduo do nome para o domnio, enviou os pacotes ICMP, e obteve
o retorno no tempo limite.

Regra de Negcio
Interromper a execuo quando o tempo de vida (TTL) dos pacotes ICMP
enviados expirar.

18

https://pt.wikipedia.org/wiki/Domain_Name_System

50

Concluindo
Vimos que os dois conceitos citados so coisas diferentes, e no sutilmente
bem diferentes, so muito diferentes.

51

Priorizao de Requisitos
Quando falamos em Escopo do Sistema (no Escopo do Projeto),
estamos falando de requisitos (tanto funcionais quanto No Funcionais, e
tambm regras de negcio)
A grosso modo, vamos entender como requisito tudo aquilo que deve
ser feito no sistema, que compe o escopo do sistema (o que j vimos
anteriormente neste eBook).
Escopo do projeto algo diferente de escopo do sistema, em projetos de
desenvolvimento de software. No escopo do projeto geralmente temos
mais coisas alm do sistema em si atividades de infraestrutura, gesto,
configurao etc., por exemplo. No escopo do sistema, que parte do
escopo do projeto, como citado no pargrafo inicial deste post, o que
temos so requisitos, basicamente. Na literatura de gesto de projeto, o
escopo do sistema chamado Escopo do Produto.
O Cone da Incerteza19 nos explica isso melhor, mas outros fatores
tambm contribuem para a problemtica do escopo; abaixo alguns para
exemplo.

Requisitos mal especificados

No incio do projeto geralmente os requisitos tem um nvel de detalhe
muito alto, muito macro. A partir do incio do projeto, medida que os
requisitos vo sendo detalhados, sendo decompostos, o escopo de verdade
vai aparecendo, e na maioria das vezes no h tempo de
replanejar/recombinar as coisas quando o tempo j passou.

Informaes faltantes
Durante a especificao a equipe faz reunio com os usurios, obtm
leis, normas, e-mails etc. Aps a concluso da especificao, ocorre
a validao, e aps algumas idas e vindas, o escopo validado. Na hora da
materializao dos requisitos (leia-se projeto, construo, testes etc.) comea

19

http://www.ateomomento.com.br/o-problema-da-descoberta-do-escopo-o-cone-da-incerteza/

52

o puxa, esqueci, tinha isso tambm e o puxa, isso aqui um pouco diferente
do que tnhamos pensado.

Dinamismo dos usurios

Usurios mudam de ideia muito rpido20, e gestores geralmente tem
dificuldades em dizer no a usurios.
Definir conceitualmente um sistema um processo de criao
constante; ocorrem definies, revises e ajustes de escopo h todo
momento. Mas dificilmente isso previamente alinhado com o cliente, no h
um trabalho de aculturamento do cliente neste sentido (no sentido de que, se
mudar toda hora, nunca fica pronto).
Em funo dessa caracterstica, da volatilidade do escopo, usurios
tendem a pedir mudanas frequentemente, com o projeto em execuo,
geralmente no percebendo om o impacto que isso gera.

Gesto e controle inadequados do escopo

escopo
Controlar o escopo de um projeto algo muito difcil, pela prpria
complexidade inerente. Soma-se a isso o fato de que gerentes de projeto e
analistas sempre esto envolvidos em vrios projetos/demandas ao mesmo
tempo o que dificulta muito focar numa nica coisa, e presses externas e
internas que sempre existem em qualquer empresa/mercado dificultam ainda
mais o foco.
E nesse ambiente desafiador, a ausncia de critrios na gesto do
escopo do sistema tornam as coisas ainda mais complicadas. Uma forma de
diminuir este problema, dando um pouco mais de ordem ao caos, utilizar
a Priorizao de Requisitos.

O que mais importante vem primeiro

Todos ns deveramos refletir muito sobre a palavra priorizao.
Considerando que na vida os recursos mais necessrios so escassos,
fundamental priorizarmos as coisas. Exemplos facilmente perceptveis de
escassez de recursos so dinheiro, tempo e sade. E na vida, geralmente
fazemos aquilo que queremos, e no aquilo que devemos fazer.
20

www.ateomomento.com.br/relacao-com-o-usuario/

53

Se analisssemos o que realmente importante/urgente, com certeza

viveramos melhor, pois faramos primeiro aquilo que realmente importante.
Mas se no houvesse limitao/escassez de recurso, todos iriam querer tudo!
Para muitos profissionais envolvidos em projetos de software tanto
fornecedores quanto clientes quando o assunto escopo, no h
limitao/escassez de recurso, eles querem tudo!
Mas no d para fazer tudo em um projeto. E para decidir o que deve ser
feito com os recursos que sem tem, uma das melhores formas para isso
priorizar os requisitos. Em termos de mtodo aplicado, a grosso modo,
estamos falando de criar uma lista com os requisitos, definir uma prioridade
para cada um, e os mais prioritrios vo para o incio da lista, os menos
prioritrios, para o fim. Aps a priorizao, importante definir uma ordem de
execuo para os requisitos com a mesma prioridade.

Priorizao dos Requisitos

As priorizaes podem ter nomes diferentes conforme a literatura
consultada, mas geralmente quando falamos de priorizao de requisitos, so
utilizados os termos Essencial, Importante e Desejvel. A seguir, o que
significa cada um destes.

Essencial
Realmente fundamental para o sistema, sem o qual o sistema no pode
ser dado como completo, ou apto para produo. So requisitos que se no
so implementados impedem uma implantao ou a concluso do sistema.
So compulsrios, no sendo possvel aplicar solues de contorno ou
paliativos para eles.

Importante
Deve ser parte do escopo, mas no bloqueia o sistema a entrar em
produo. como se o sistema ficasse com uma pendncia de
escopo criando dbito tcnico21 que ser atendido em momento oportuno.
Sem um requisito importante, o sistema poder rodar, funcionar, ser

21

http://www.ateomomento.com.br/o-debito-tecnico/

54

utilizado. Pode ser simplesmente postergado para ps-implantao, ou ser

atendido temporariamente por solues de contorno ou paliativos.

Desejvel
No indispensvel para o sistema estar completo, para entrar em
produo. Tambm no algo que, mesmo postergado, dever ser feito
obrigatoriamente.
Sem um requisito desejvel o sistema deve funcionar de maneira
satisfatria, atendendo completamente seu objetivo. Por ser algo que no
precisa ser feito para que o sistema esteja completo, a menor das prioridades,
e deve ser postergado para, se possvel ser viabilizado no futuro.

Quando priorizar os Requisitos?

Requisitos?
A priorizao dos requisitos deve ocorrer, no mnimo, durante a
definio do escopo do sistema. Isso o mnimo mesmo. Comear o
desenvolvimento com o escopo definido, mas no priorizado, torna fatal a
ocorrncia de problemas diversos no projeto.
Mas priorizar os requisitos apenas no incio do projeto no boa prtica.
Sabemos que em projetos de software o escopo voltil, e muito dessa
volatilidade origina-se nos desejos/percepo de valor dos usurios,
sentimentos que so descobertos/mudam a todo momento. Em funo disso, a
prioridade dos requisitos tambm pode mudar. Por isso a necessidade
de priorizao constante, ou repriorizao.
Em projetos baseados em ciclo de vida em cascata (waterfall),
colocar marcos no planejamento para reviso da priorizao dos requisitos
uma forma til para manter o escopo mais aderente realidade do negcio.
Excetuam-se os requisitos que j foram implementados, ou seja, a
repriorizao
ocorrer somente
nos
requisitos
ainda
no
implementados (requisitos ainda contidos no backlog do projeto).
Salvo raras excees, no recomendada a utilizao de ciclo de vida
em cascata em projetos de software, a abordagem deve ser iterativa e
incremental. Em projetos onde o ciclo de vida se baseia neste modelo (iterativo
e incremental) a priorizao tambm deve ocorrer no incio do projeto (no

55

backlog do produto/lista de requisitos) e tambm sempre no incio de cada

iterao, para repriorizao.
Por iterao entenda-se fase, pacote, Sprint ou qualquer outro rtulo
empregado a uma iterao de projeto
Em projetos onde o ciclo de vida utiliza Scrum, por exemplo, muito til
nas reunies de Sprint Planning haver reviso do backlog onde so
avaliados/reavaliados tanto os itens do backlog, quanto o esforo para
produo e a priorizao definida para cada item.
De um modo geral, fundamental revisitar as prioridades aplicadas aos
requisitos. As coisas mudam muito rpido.

56