EN

REQUISITOS
DE SOFTWARE
Uma viso 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

1
 Essa famosa imagem reflete perfeitamente a nossa realidade nos
projetos de software. E tudo comea nos Requisitos...

2
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
3
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, baseando-
se 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.

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

4
 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.

5
 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.

6
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

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

7
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/

8
 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
O RF deve propor uma nica coisa apenas. No deve atender
a mais de uma exigncia. O RF Incluir cliente no unitrio,
Unidade pois se refere a incluir clientes de tipos diferentes (pessoa
fsica e jurdica), assumindo assim vrias responsabilidades,
quando deveria assumir apenas uma.
O RF deve ser autocontido, deve ter incio/meio/fim, ser
Completude
completo. O RF Pagar fatura no completo, s conta parte

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

9
Atributo Referente a
da estria. Para ser completo deveria ser algo como Pagar
fatura com carto de crdito para cliente pessoa fsica.
O RF no deve contradizer outro RF do mesmo escopo do
projeto. como termos dois RFs se propondo a fazer uma
Consistncia
mesma coisa, mas cada RF se propondo a fazer esta coisa
de uma forma diferente.
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
Atomicidade 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.
Um RF no pode ser ambguo, no pode propor algo que no
fica claro o que . O RF Emitir relatrio no quer dizer nada.
No- Relatrio de que, para que? Emitir relatrio de saldo j
Ambiguidade 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.
No adianta ter um RF se ele no palpvel, possvel de
associar com um artefato de construo, de testes. Um RF
Verificvel 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.
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
Rastrevel
pontas (associar o RF interface grfica, que ser associada
a um caso de uso, que ser associado a funcionalidades, que
sero implementadas etc.).
Um RF Essencial algo muito diferente de um RF Desejvel,
Prioridade5
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
<<Data>> Autor <<Texto>>
criao
Data da ltima
<<Data>> Autor <<Texto>>
alterao
Verso <<Numero>> Prioridade <<Texto>>
Descrio <<Texto>>

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

11
Campo Descrio
Sufixo seguido de um identificador nico. O sufixo
Identificador geralmente utilizado RF (Requisito Funcional) e o
identificador nico geralmente composto de quatro dgitos.
Nome curto do RF, mas que possibilite entender bem o que
Nome
RF faz apenas pelo nome.
Mdulo ao qual o RF pertence. Se for um sistema pequeno
Mdulo que no possua nenhum mdulo, somente o prprio
sistema, deve ser preenchido com N/A (no se aplica).
Data da criao do RF, ou a data em que ele foi
Data de criao
especificado.
Profissional que especificou o RF pela primeira vez, quem o
Autor
criou.
Data da ltima
Data em que houve a ltima alterao no RF.
alterao
Profissional que alterou a especificao do RF pela ltima
Autor
vez.
Nmero da verso do RF. Geralmente utiliza-se algo
simples, como 1, 2. A verso inicial sempre a 1, e a cada
Verso
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
Consultar automaticamente o CEP de clientes atravs do
Nome
endereo residencial
Mdulo Cadastro
Data de
31/01/2016 Autor Arquitas de Tarento
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 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
Herdar permisses de acesso para o usurio que for
Nome associado a um grupo de usurios previamente cadastrado
e ativo
Mdulo Segurana
Data de
31/01/2016 Autor Nelson Goodman
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Essencial
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).
Descrio
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 pr-
configuradas para o grupo em questo, e mant-las at
enquanto fizer parte do grupo.

Identificador RF0003
Emitir carta de cobrana para clientes inadimplentes
Nome
conforme critrios pr-estabelecidos
Mdulo Cobrana
Data de criao 31/01/2016 Autor Hpias de Elis
Data da ltima
N/A Autor N/A
alterao
Verso 1 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.

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
Descrio
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
Recalcular contribuies calculadas incorretamente que
Nome
no tenham sido pagas para participantes ativos
Mdulo Contribuies
Data de
31/01/2016 Autor Lucrcio
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 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.

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
Descrio 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
Colar sem formatao o texto copiado da rea de
Nome
transferncia
Mdulo Editor de Texto
Data de criao 25/02/2016 Autor Eckhart
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Essencial
Aps a cpia de algum contedo textual para rea de
transferncia do sistema operacional, o usurio poder
Descrio 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
25/02/2016 Autor Eraststenes
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Desejvel
O usurio dever ter um recurso para que, sob demanda,
verifique se existem atualizaes disponveis para o
Descrio 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
N/A Autor N/A
alterao
Verso 1 Prioridade Essencial

19
 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
Descrio 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
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 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.

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

24
Identificador <<Numero>> Categoria <<Texto>>
Nome <<Texto>>
Data de
<<Data>> Autor <<Texto>>
criao
Data da ltima
<<Data>> Autor <<Texto>>
alterao
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 qual o RNF pertence (Desempenho, Usabilidade,
Categoria
Padro etc.).
Nome curto do requisito, mas que possibilite entender bem o
Nome
que RNF faz apenas pelo nome.
Data de
Data da criao do RNF, ou a data em que ele foi especificado.
criao
Profissional que especificou o RNF pela primeira vez, quem o
Autor
criou.
Data da
ltima Data em que houve a ltima alterao no RNF.
alterao
Autor Profissional que alterou a especificao do RNF pela ltima vez.
Nmero da verso do RNF. Geralmente utiliza-se algo simples,
como 1, 2. A verso inicial sempre a 1, e a cada alterao
Verso
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 do sistema, restries de performance,
tempo de resposta em processamentos especficos,
Desempenho
cargas, velocidade de resposta de processamentos em
telas etc.
Disponibilidade do sistema em tempo til, restries sobre
Disponibilidade janelas de manuteno, janelas de produo, solues de
contorno quando houver queda de energia etc.
Diretrizes pertinentes segurana do sistema, como
algoritmo de criptografia a ser utilizado, regras para
Segurana 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.
Quantidade mxima de cliques por tipo de funcionalidade,
uso de componentes e lgicas de telas especficas,
restrio/premissas para uso de componentes grficos
Usabilidade
(grids, barras de rolagem, menus), recursos de
acessibilidade para deficientes, compatibilidade com
idiomas etc.
Browser e sistemas operacionais nos quais o software
dever rodar, verses de browser e sistemas
Compatibilidade 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
Polticas para backup do sistema e seus dados,
quantidade limite de erros em clculos e processamentos
Confiabilidade com erro, regras para rollback quando houver alguma
falha, recursos para restaurao automtica do sistema
em caso de queda de energia etc.
Padres em geral, aplicveis ao software e ao projeto:
padro de log de erro, de log de informao, padro de
Padres mensagens, metodologia para desenvolvimento do
sistema, padres de projeto (design patterns) a serem
aplicados, padres arquiteturais etc.
Exigncias de conformidade do software com alguma
legislao pertinente ao projeto, por exemplo,
Legais 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

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

Tempo limite para processamento de todos os lotes de
Nome
fatura na rotina diria
Data de
18/01/2016 Autor Alexandre de Afrodsias
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Essencial
No mdulo de faturamento o processamento de faturas em
Descrio
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

Utilizao do mdulo de Informaes Cadastrais em modo
Nome
off-line
Data de
25/01/2015 Autor Aristarco de Samos
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Importante
O mdulo de Informaes Cadastrais um mdulo do CRM
Descrio
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
Autenticao de usurio para consumo de webservices do
Nome
sistema por sistemas externos
Data de
30/01/2016 Autor Andr Comte Sponville
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 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 utilizando-
se 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

Integrao com sistema do Banco Central para envio de
Nome
informaes de transferncia internacional de valores
Data de
30/01/2016 Autor Ren Descartes
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Prioridade Essencial
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.

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
Descrio
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
30/01/2016 Autor Digenes de Apolnia
criao
Data da
ltima N/A Autor N/A
alterao
Verso 1 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).

A interface do sistema dever se comportar adequadamente

Descrio 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

Compatibilidade com sistemas operacionais Windows e
Nome
Linux
Data de
30/01/2016 Autor Friedrich Engels
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 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.

O sistema, por se tratar de um aplicativo desktop em

arquitetura cliente/servidor, dever rodar nos sistemas
Descrio
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

Diviso arquitetural do sistema em camadas para
Nome
desacoplamento

33
Data de
30/01/2016 Autor Empdocles
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 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:

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.
Descrio 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
Atendimento instruo normativa 554 da ANS (Agncia
Nome
Nacional de Sade)
Data de
30/01/2016 Autor Hipcrates
criao
Data da
ltima N/A Autor N/A
alterao
Verso 1 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 Tipo Obrigatrio
DTHRATE Data e hora em Dateti Sim
ND que o mdico me
Descrio atualizou o
pronturio.
NMMEDIC Nome do mdico Varch Sim
O que atualizou o ar(100
pronturio. )
CRMMEDI CRM do mdico Varch Sim
CO que atualizou o ar(10)
pronturio.

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
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
Unidade
formas diferentes de calcular salrio (para profissional ativo,
aposentado, estagirio, efetivo, licenciado etc.). Esta RN
assume assim vrias responsabilidades, quando deveria
assumir apenas uma.
A RN deve ser autocontida, deve ter incio/meio/fim, ser
completa. A RN Clculo de salrio no completa, s conta
Completude parte da estria. Para ser completo deveria ser algo como
Clculo de salrio para profissionais afastados h mais de 15
dias.
No deve contradizer outra RN do mesmo escopo do projeto.
como termos duas RNs se propondo a fazer uma mesma
Consistncia
coisa, mas cada RN se propondo a fazer esta coisa de formas
diferentes.
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
Atomicidade
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.
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
No-
processamento de fatura de mensalidade j melhor, mas
Ambiguidade
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.
No adianta ter uma RN se ele no palpvel, possvel de
associar com um RF que ser construdo, testado etc. Uma
Verificvel 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.
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
Rastrevel
(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
<<Data>> Autor <<Texto>>
criao
Data da ltima
<<Data>> Autor <<Texto>>
alterao
Verso <<Numero>> Dependncias <<Texto>>

39
Descrio <<Texto>>

Campo Descrio
Sufixo seguido de um identificador nico. O sufixo
geralmente utilizado RN (Regra de Negcio) e o
Identificador identificador nico geralmente composto de quatro dgitos
(podendo ser mais, conforme a o tamanho do sistema que
est sendo especificado).
Nome curto da RN, mas que possibilite entender bem o que
Nome
RN faz apenas pelo nome.
Data de Data da criao do RN, ou a data em que ela foi
criao especificada.
Profissional que especificou a RN pela primeira vez, quem a
Autor
criou.
Data da
ltima Data em que houve a ltima alterao no RN.
alterao
Profissional que alterou a especificao da RN pela ltima
Autor
vez.
Nmero da verso do RN. Geralmente utiliza-se algo
simples, como 1, 2 etc. A verso inicial sempre a 1, e a
Verso
cada alterao incrementa-se a verso (na criao verso 1,
na primeira alterao verso 2 etc.).
Quais RFs so dependentes da RN para serem realizados.
Dependncias
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
Validao da identificao da pessoa que solicita a
Nome
retirada/entrega do material
Data de
31/01/2016 Autor Nagarjuna
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Dependncia RF0099
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.

Para validar o documento fornecido pela pessoa o nmero do

Descrio
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
Localizao automtica do material solicitado para ser
Nome
entregue
Data de
31/01/2016 Autor Nicolau de Cusa
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Dependncia RF0099
Aps checar que o documento vlido (vide RN0001) o
profissional dever pegar o documento de protocolo de
entrega com a pessoa.
Descrio
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
31/01/2016 Autor Parmnides
criao
Data da ltima
N/A Autor N/A
alterao
Verso 1 Dependncia RF0099, RF0002
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.

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

as seguintes informaes: nome e e-mail da pessoa qual o
Descrio 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 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
16
https://pt.wikipedia.org/wiki/Internet_Control_Message_Protocol
17
https://www.vivaolinux.com.br/dica/Entendendo-o-campo-TTL-do-Ping

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

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.

Quer se tornar um Expert em

Requisitos?
Em nosso curso Engenharia de Requisitos na real trazemos uma
abordagem indita sobre Requisitos, com uma didtica voltada ao mercado,
abordando de maneira detalhada e pragmtica os fundamentos das
Concepo de um software e mostrando a aplicao na prtica.

Seja voc um Analista que quer dar um salto no curriculum, ou um

Programador, Analista de Testes ou Gerente de Projetos que quer melhorar
sua produtividade, empregabilidade e qualidade profissional, esse curso
para voc.

56