Captulo I.

Usurios e Requisitos
A hundred objective measurements didn't sum the worth of a garden;
only the delight of its users did that.
Only the use made it mean something.
Lois McMaster Bujold, A Civil Campain, 1999
Stakeholders
Requisitos Funcionais
Requisitos No Funcionais
Descrevendo Requisitos
Elicitao de Requisitos
Entrevistas e JAD

A principal tarefa de um analista descobrir o que o sistema deve fazer e como

deve se comportar segundo as expectativas de seus usurios e outros interessados.
Usualmente, chamamos esses desejos dos usurios de requisitos1.
O problema de encontrar os requisitos que, no incio do desenvolvimento,
ningum realmente sabe o que um sistema desejado deve exatamente fazer ao ficar pronto,
inclusive o cliente. Por isso, encontrar os requisitos uma tarefa investigativa, que envolve
descobrir e validar os requisitos encontrados.
Alm disso, com o tempo, os requisitos mudam. importante, ento, manter os
requisitos sempre atualizados
Dessa forma, descobrir e registrar os requisitos de um sistema, alm de mante-los
sempre atualizados, um trabalho bastante difcil, investigativo, criativo e contnuo.

I.1

Stakeholders e Usurios

Os sistemas que desenvolvemos devem ser utilizados. Na verdade, uma medida

importante da qualidade de um sistema de informao e do sucesso do projeto que o
construiu quanto do sistema realmente usado pelos seus usurios, ou seja, quanto do
que foi feito realmente til.
Logo, para descobrir o que deve ser feito (o qu), devemos primeiro entender para
quem o sistema se destina (quem).
Usurios so todos aqueles que usam de alguma forma o sistema com algum
objetivo. O nome pode ser entendido de forma restrita, indicando apenas aqueles usurios
finais, isto , que realmente usam o sistema dentro do escopo do seu objetivo, ou de forma
ampla indicando todos aqueles que usam o sistema ou algum de seus produtos, de alguma
forma, o que inclui tambm os desenvolvedores, programadores, instaladores, operadores,
etc.

Em ingls, requirement, o que levou alguns tradutores a usar o termo requerimentos, considerado
inadequado.

Stakeholders, ou partes interessadas, so todos aqueles com algum interesse no

sistema, afetando ou sendo afetados por seus resultados. A palavra uma composio dos
termos stake, interesse ou aposta, e holder, possuidor. Fica claro que um stakeholder uma
pessoa que possui algum interesse no sistema, em especial um interesse que envolve algum
risco. Atualmente a traduo mais comum para esse termo parte interessada, mas esse
termo no tem todo o significado do termo em ingls, que adotaremos na falta de um
melhor em portugus. O grupo de stakeholders bem maior que o grupo de usurios, pois
envolve no s estes, mas tambm financiadores e outros que podem at mesmo nunca ter
contato direto com o sistema, mas de alguma forma so afetados por ele.
Abordagens simplificadas permitem identificar imediatamente trs tipos de
stakeholders: desenvolvedores, compradores e usurios finais. Uma investigao mais
profunda pode achar muitos outros interessados, como: gerentes dos usurios finais,
auditores, responsveis pela operao, responsveis pela manuteno, usurios de sistemas
que enviam ou recebem dados para o sistema especfico, etc. interessante que seja feito
um esforo para levantar todos os stakeholders de um sistema e mapear, de alguma forma,
seus interesses e interaes com o mesmo.
Interesses e Objetivos
Usurios possuem um ou mais objetivos ao usar um sistema, i.e., ele usa o sistema
para obter uma resposta planejada. Usurios e stakeholders tm interesses no sistema, isto
, eles esperam que o sistema afete o negcio de alguma forma.
importante atentar para a diferena que existe entre usar o sistema para fazer uma
ao(o que), o objetivo do uso, com o motivo ou motivao do sistema para um stakeholder
(por que), o interesse.
Estudar os interesses nos permite saber melhor como realizar os objetivos. Por
exemplo, um cliente de web site de vendas de produtos tem como objetivos, ao longo de
uma compra, vrias aes, como escolher um produto, saber seu preo, pagar o produto.
Porm ao longo de todo esse tempo, seu nico interesse receber o produto. Mais do que
comprar, o usurio quer recebe-lo em casa. Ento toda a dinmica do site, ou do software
e logstica do sistema por trs dele, pode ser construda voltada para esse interesse. Mesmo
que quisssemos atender um interesse menor, como comprar o produto, j poderamos
imaginar formas diferentes de implementar as aes correspondentes. Um exemplo disso
no mundo real o one-click buy, ou seja, comprar um produto com s um click do mouse
e ter certeza de recebe-lo, ideia que foi inclusive patenteada pela Amazon.
Uma prtica til e que pode facilitar a compreenso do ambiente onde os sistema
ser implantado definir uma tabela indicando que objetivos cada usurio e que interesse
cada stakeholder tem no sistema. Lembre-se, porm, que todo usurio stakeholder. Isso
pode ser feito, inclusive, desde o incio do projeto, mesmo que de forma preliminar.
A tabela a seguir um exemplo tpico. Outro exemplo est no diagrama do tipo
ThinkMap aps a tabela.

Objetivos e Interesses de Stakeholders

Agente ou
Interessado

Objetivo

Interesse

Prioridade

Cliente

Fazer pedido

Receber o
produto pedido

Cliente

Obter status do
pedido

Prever o prazo de
chegada do
pedido

Gerente

Obter lista de
pedidos diria

Saber a produo
diria

Tabela 1. Lista de objetivos e interesses

Figura 1. Um mind map com a informao de objetivos e

interesses de stakeholders.

I.2

Perspectivas dos Usurios

Quando estamos fazendo a anlise de um sistema, por meio de entrevistas ou

reunies, interagimos com pessoas com vises e descries diferentes do que o sistema.
Um cuidado importante que devemos ter quanto posio da descrio que est sendo
feita em relao ao sistema.
Mais tarde veremos que as tcnicas de anlise de sistema esto interessadas, no
incio, em informaes e comandos que partem do ambiente, de fora, para dentro do
sistema, ou no sentido inverso. Basicamente, grande parte da anlise dedicada a
estabelecer as fronteiras do sistema e que informaes cruzam essa fronteira em uma
direo ou outra. Desta forma, devemos descrever todo o sistema com essa perspectiva.
Nossos clientes, porm, no tm sua perspectiva limitada pelo nosso modelo, afinal
eles conhecem seu negcio e no precisam de um mtodo como o nosso, onde as limitaes
tm como objetivo clarificar a compreenso do sistema pelo analista.
Assim, muitas vezes um entrevistado descreve o sistema como se fosse uma
entidade mgica, outros descrevem o sistema como se fizessem parte dele, outros
descrevem apenas as sadas do sistema, etc.
Devemos estar preparados para isso e garantir uma modelagem condizente, que
atenda todos os pedidos do usurio. Devemos tambm fazer, sutilmente, o usurio
compreender a nossa forma de descrever o sistema, pelas suas fronteiras. Muitos usurios

entendem facilmente esses conceitos quando traduzidos para portugus mais simples,
como entrada de dados e entrada de comandos.
A figura a seguir mostra uma forma um pouco antiga, mas muito utilizada at hoje
para definir as fronteiras de um sistema: um Diagrama de Fluxo de Dados, em seu modo
contextual.

Figura 2. Um diagram do tipo DFD uma das tcnicas usadas para

delimitar a fronteira de um sistema e as informaes que as
cruzam.

As perspectivas bsicas que encontramos em entrevistas e reunies so as

seguintes:

Entrevistado onisciente: descreve o sistema como o sistema, indicando

coisas que ele deve fazer. V tanto o sistema como os seus usurios de
uma perspectiva externa, aparentemente conhecendo os mecanismos tanto
por dentro quanto por fora. Normalmente a posio da alta gerncia e de
quem contratou o sistema. comum que no conhea os procedimentos
internos do sistema como acontecem realmente, mas apenas de forma geral
ou como aconteciam no passado. Exige funcionalidade do sistema,
principalmente para atender o nvel gerencial.

Entrevistado usurio: descreve o sistema como se o estivesse usando

diretamente, muitas vezes j usando o sistema atual. Exige funes do
sistema, principalmente para atender o seu nvel de atuao (gerencial ou
operacional). Pode apresentar alguma desconfiana, pois o novo sistema
pode exigir novos conhecimentos. Conhece a entrada e a sada do sistema,
mas no necessariamente os procedimentos internos.

Entrevistado parte do sistema: descreve o sistema visto por dentro.

Muitas vezes quem vai ter o trabalho substitudo, em todo ou em parte,
pelo sistema, o que pode causar desconfiana e at mesmo franca
hostilidade. Conhece os procedimentos na forma como so realizados e as
excees que podem acontecer.

No podemos deixar de entender que alguns usurios fornecem uma perspectiva

mista, principalmente quando envolvidos com diferentes partes do sistema.

Figura 3. Os tipos de entrevistados em relao ao sistema

Na prtica do desenvolvimento de software, percebemos que na grande maioria dos

casos o usurio tem dificuldade de expressar suas necessidades. Isso pode acontecer por
vrios motivos, como o desconhecimento, o foco nas tcnicas de soluo (que so
responsabilidade do analista e no do usurio), a dificuldade de encontrar uma linguagem
comum com o desenvolvedor e muitos outros.
O que devemos notar que apesar do analista ter que atender aos usurios, no tem
que atender exatamente ao que eles dizem, mas sim ao que realmente precisam. O trabalho
de anlise um trabalho investigativo, realizado junto com os usurios. Discutiremos esse
assunto um pouco mais ao falar da elicitao de requisitos.
No podemos nunca esquecer, porm, que um dos principais fatores de sucesso de
um projeto de software a participao do usurio. Ento, no basta entrevista-los, mas
devemos conquista-los para a equipe do sistema. Por isso to importante entender as
motivaes e os interesses, e no apenas os objetivos.

I.3

O que um Requisito
Segundo a norma IEEE Std 610.12-1990, um requisito

Uma condio ou capacidade necessria para um usurio resolver um

problema ou atingir um objetivo

Uma condio ou capacidade que precisa ser possuda ou alcanada por

um sistema ou componente de uma sistema para satisfazer um

contrato, padro, especifio ou outro documento formalmente

imposto

Uma representao documental de uma condio ou capacidade no

sentido das duas definies anteriores.

Qualquer que seja o sistema, existem vrias formas de entend-lo. Similarmente,

existem vrios tipos de requisitos, que so aplicveis ou no, dependendo da viso
necessria naquele instante.

Um requisito do usurio algum comportamento ou caracterstica que o

usurio deseja do software ou o sistema como um todo; o que o usurio
quer. So escritos pelo prprio usurio ou levantados por um analista de
sistemas que consulta o usurio.

Um requisito do sistema algum comportamento ou caracterstica exigido

do sistema como um todo, incluindo hardware e software. O
comportamento desejado do sistema. So normalmente levantados por
engenheiros ou analistas de sistemas, refinando os requisitos dos usurios e
os transformando em termos de engenharia.

Um requisito do software algum comportamento ou caracterstica que

exigido do software. So normalmente levantados por analistas de
sistemas.O objetivo da anlise capturar todos os requisitos para o software
sendo desenvolvido e apenas aqueles requisitos verdadeiros.

Figura 4. Requisitos formam uma pirmide invertida, sendo que o

nvel inferior serve de base para a criao do nvel superior, que
contm sempre mais requisitos.

Exemplos de requisitos so:

O sistema dever imprimir a nota fiscal de venda ao consumidor referente

venda sendo registrada.

O sistema dever permitir ao usurio calcular diferentes oramentos para

uma mesma proposta, baseados em formas diferentes de pagamento.

O sistema dever avisar que a rede est fora do ar em 204 segundos aps
a rede sair do ar.

O sistema dever permitir agendar uma consulta, reservando a data e o

horrio da sala e do profissional de acordo com as disponibilidades da
clnica e o desejo do paciente.

Caractersticas de um Bom Requisito

Um requisito deve ter as seguintes caractersticas [B8]:

Necessrio, significando que, se retirado, haver uma deficincia no

sistema, isto , ele no atender plenamente as expectativas do usurio.
o Em especial, no devem existir requisitos do tipo seria interessante
ter. Ou o requisito necessrio ou dispensvel.
o Deve ser levado em conta que cada requisito aumenta a
complexidade e o custo do projeto, logo, no podem ser introduzidos
de forma espria.

No-ambguo, possuindo uma e apenas uma interpretao. Nesse caso

muito importante prestar ateno na linguagem sendo utilizada.

Verificvel, no sendo vago ou geral e sendo quantificado de uma maneira

que permita a verificao de uma das seguintes formas: inspeo, anlise,
demonstrao ou teste.

Conciso, de forma que cada requisito defina apenas um requisito que deve
ser feito e apenas o que deve ser feito, de maneira clara e simples.
o Um requisito, para ser conciso, no inclui explicaes, motivaes,
definies ou descries do seu uso.
o Estes textos podem ser mantidos em outros documentos, apontados
pelo requisito (de preferncia sob o controle de um sistema de
gerncia de requisitos).

Alcanvel, ou seja, realizvel a um custo definido por uma ou mais partes

do sistema

Completo, ou seja, no precisa ser explicado ou aumentado, garantindo

capacidade suficiente do sistema.

Consistente, no contradizendo ou mesmo duplicando outro requisito e

utilizando os termos da mesma forma que outros requisitos,

Ordenvel, por estabilidade ou importncia (ou ambos).

Aceito, pelos usurios e desenvolvedores.

Alm desses requisitos, quando um requisito for funcional, dever ser tambm
Independente da Implementao, ou seja, o requisito define o que deve ser feito, mas
no como.

Efeitos de Requisitos Errados

A importncia de obter requisitos corretos pode ser compreendida rapidamente se
imaginarmos que um requisito, quanto mais bsico e importante ele , mais partes do
sistema vai afetar.
Basicamente, cada requisito do usurio vai gerar um ou mais requisitos do sistema,
que vo, por sua vez, gerar outros requisitos mais detalhes. O efeito, com a evoluo do
projeto, que cada requisito inicial representa no s um compromisso, mas um fator
crtico em uma seqncia de decises que so tomadas ao longo do projeto.
Assim, os erros de requisito afetam drasticamente todo o projeto. Dados empricos
indicam que um problema nos requisitos, se detectado nas fases finais do projeto, pode
custar 100 vezes mais para ser corrigido do que se for detectados na fase de elicitao de
requisitos. Mesmo que essa deteco se faa mais cedo, em uma fase intermediria, esse
custo ainda seria 10 vezes maior.
Um requisito que no caiba em uma das caractersticas de qualidade citadas ser
propenso a defeitos e aumentar o risco do proejto. Se no for necessrio, gastaremos
esforos em sua definio e implementao que seriam mais bem gastos tratando de outros
requisitos. Alm disso, cada requisito adicional aumenta o risco do projeto como um todo,
ainda mais se a adio for dispensvel. Se for ambguo, corremos alto risco de implementlo errado, desagradando o cliente. Se no for verificvel, no poderemos testar de maneira
inequvoca se est corretamente atendido, possibilitando discusses sobre sua realizao.
Se no for conciso, estamos aumentando a complexidade do documento de especificao,
permitindo interpretaes erradas. Se no for independente da implementao, corre o risco
de estar erroneamente definido ou se tornar obsoleto, ou ainda errado, caso a tecnologia
evolua. Se no for alcanvel, o projeto no ter como terminar adequadamente. Se no for
completo, faltar ao projeto alguma coisa que o usurio necessita. Se no for consistente,
o projeto chegar a encruzilhadas ou talvez se torne impossvel. Se no for ordenvel, no
saberemos em que momento realiz-lo, e, finalmente, se no for aceito tanto pelos usurios
quanto pelos desenvolvedores, se tornar uma discusso permanente no projeto.

Figura 5. O efeito de um requisito original vai se espalhando pelo

projeto.

Requisitos Mudam com o Tempo

Tambm importante perceber que os requisitos de um software mudam com o
tempo. Essas mudanas ocorrem porque o ambiente em que o software reside tambm
muda. Os pases alteram suas leis, as organizaes alteram suas prticas, a tecnologia
evolui, os usurios exigem novas funcionalidades at ento no imaginadas ou
desnecessrias.
Caper Jones2, em 2005, afirmou que a taxa de mudanas de requisitos para um
software comercial chega a 3,5% ao ms, e para um software para Web, chega a 4,0% ao
ms. Considerando o tempo mdio de execuo desses e outros tipos projetos, ele chega a
valores mdios de 2,58% de mudanas ao ms, 14 meses em mdia de execuo e 32,33%
de mudana total nos requisitos. importante notar, porm, que todas essas afirmaes so
baseadas em clculos com Pontos de Funo para manuteno, onde pequenas alteraes
podem causar grandes efeitos.
Esse fato tem efeitos em nossa prtica. O primeiro que devemos estar preparados
para a mudana, pois ela vai acontecer. O segundo que quanto maior o tempo de durao
do projeto, maior a quantidade de mudanas de requisitos, o que aumenta ainda mais o
risco, que j afetado pelo projeto ser longo e provavelmente complexo.
Assim, no s importante conhecer os requisitos, mas tambm conhecer qual a
sua estabilidade. Requisitos pouco estveis devem ser tratados de forma diferente dos
requisitos mais estveis3. Requisitos mais crticos devem ser tratados de forma diferente
dos requisitos opcionais.

2
3

http://www.stsc.hill.af.mil/crosstalk/2005/04/0504Jones.html

Mesmo que muitas vezes requisitos supostamente estveis mudem, mas no h como nos prepararmos de
forma economicamente vivel para essa alterao.

Tabela 2. Algumas taxas mensais de mudana de requisitos,

segundo Caper Jones.

I.4

Requisitos e Necessidades

Requisitos so originrios de necessidades dos usurios e stakeholders. Enquanto

os requisitos vivem no mundo das solues, as necessidades vivem no mundo dos
problemas. Os requisitos implementam as caractersticas observadas do sistema, que
atendem as necessidades (Figura 6).

Figura 6. Enquanto as necessidades surgem no mundo dos

problemas, caractersticas e requisitos definem a soluo
desejada.

Um problema uma diferena entre uma situao percebida e uma situao

desejada. Mais tarde vamos analisar vrios tipos de problema. No momento, nos basta a
noo que o problema incomoda o usurio (ou stakeholder) ao ponto dele considerar
necessrio investir alguma quantia de forma a evitar que o problema acontea.
comum ouvirmos o ditado Em time que est ganhando, no se mexe. Quando
somos chamados para desenvolver um sistema, devemos imaginar imediatamente que, se
algum deseja mexer em sua organizao, ento porque no est ganhando, pelo menos
da maneira que supe possvel. Faz pouco sentido imaginar que algum iria fazer um
investimento de risco, e sempre h risco no desenvolvimento de software, sem que haja
uma necessidade clara. No prximo captulo veremos que um sistema precisa, alm de um

objetivo funcional, metas de negcio, que visam determinar como ser a soluo para
problemas especficos.

Figura 7. O problema uma diferena entre uma situao

percebida e uma desejada.

Muitas vezes o analista se depara com a necessidade de, antes de definir requisitos,
definir propriamente qual o problema a ser tratado. Para isso, deve fazer com que os
clientes cheguem a um acordo sobre qual o verdadeiro problema, ou o problema mais
importante. Faz pouco sentido construir um sistema se o verdadeiro problema de negcios
no for endereado pela soluo planejada.
Para analisar o problema, necessrio que os usurios:

Concordem com a definio do problema

Entendam as causas do problema

o O problema por trs do problema pode ser mais importante, sendo
que o problema visto inicialmente apenas um sintoma

Identificem todos os stakeholders e usurios

Definam a fronteira do sistema de soluo

Identifiquem as restries impostas soluo

Para estabelecer o problema, interessante criar uma sentena apropriada, como a

seguinte:

O problema de <descrio do problema> , afeta <stakeholders afetados>

e resulta em <impacto nos stakeholders>. A soluo <indicar a soluo>
Trar os benefcios de <lista dos principais benefcios>.

Um sistema pequeno certamente produzir a soluo para uma pequena quantidade

de problemas, um sistema grande certamente atingir uma grande quantidade de
problemas. O ponto em questo que deve existir alguma no conformidade, seja ela atual
ou futura, para valer a pena o investimento, e o risco, de tentar um sistema novo.

I.5

Tipos de Requisitos

Vrios autores dividem os requisitos de formas diferentes, porm quase todos

concordam que existem dois tipos bsicos de requisitos: os requisitos funcionais e os
requisitos no funcionais.

Requisitos Funcionais e de Informao

Um requisito funcional representa algo que o sistema deve fazer, ou seja, uma
funo esperada do sistema que agregue algum valor a seus usurios. Exemplos tpicos
incluem a emisso de relatrios e a realizao e manuteno de cadastros.
Um requisito funcional normalmente escrito de uma forma especfica, indicando
que o sistema deve fazer algo, como em:

O Sistema deve emitir o histrico escolar.

Tambm possvel que um requisito funcional seja uma especificao mais

detalhada, impondo limites ou exigncias a outro requisito, com em:

O CR ser calculado a partir da mdia ponderada das notas em cada curso,

sendo que o peso de cada nota ser a quantidade de crditos acreditada ao
curso.

Existem muitas formas de levantar os requisitos funcionais de um sistema. Como

veremos mais tarde, os eventos essenciais definem todos os requisitos funcionais do
sistema, dado que a funo dele responder a todos os eventos. Apesar de no ser fcil
levantar corretamente os requisitos funcionais, a metodologia essencial fornece um
arcabouo eficiente para essa tarefa, que perfeitamente adequado para sistemas de
informao.
Requisitos de Informao representam a informao que o cliente deseja obter do
sistema. Requisitos de informao tambm so atendidos por eventos. Muitas vezes o
cliente expressa requisitos de informao de forma funcional Outras vezes o cliente est
preocupado em conseguir uma informao, mas no sabe como faz-lo na forma de um
requisito funcional. Em todo caso, sempre nos preocuparemos em levantar todos os
requisitos de informao, pois eles representam as respostas fundamentais do sistema.
Requisitos no funcionais
Requisitos no funcionais falam da forma como os requisitos funcionais devem
ser alcanados. Eles definem propriedades e restries do sistema. Muitos requisitos no
funcionais so tambm requisitos de qualidade, como exigncias de desempenho e
robustez. Outros so restries ou exigncias de uso de uma ou outra tecnologia.
Porm, muitas vezes no s difcil descobrir quais so os requisitos nofuncionais, mas tambm produzir uma especificao do sistema que possa ser cumprida
em custo razovel e prazo hbil de forma a atender os usurios. Um exemplo tpico seriam
dois requisitos no funcionais que, genericamente, so opostos: velocidade e
transportabilidade. Ora, para fazer um software muito veloz voc precisa adapt-lo
especificamente para o ambiente onde ele est funcionando. Para fazer um software
transportvel, voc precisa implement-lo de forma a funcionar no maior nmero possvel
de ambientes. Normalmente esses dois requisitos se relacionam de forma inversa e para
implement-los simultaneamente necessrio um grande investimento de recursos.
Existem muitas formas de se dividir os requisitos no funcionais, a figura a seguir
apresenta uma dessas formas, apenas para deixar clara a quantidade de fatores que podem
envolver um requisito no funcional, mas sem consider-la melhor ou pior que outras.

Requisitos
No Funcionais

Requisitos
do
Produto

Requisitos
de
Usabilidade

Requisitos
de
Confiabilidade

Requisitos
de
Eficincia

Requisitos
de
Desempenho

Requisitos
da
Organizao

Requisitos
De
Prazo

Requisitos
de
Portabilidade

Requisitos
de
Implementao

Requisitos
de
Espao

Requisitos
Externos

Requisitos
de Interoperabilidade

Requisitos
De
tica

Requisitos
De
Padronizao

Requisitos
Legais

Requisitos
de
Privacidade

Requisitos
de
Segurana

Figura 8. Tipos de requisitos funcionais, adaptado de Ian Sommervile,

Software Engineering.

Esse texto tem como foco requisitos funcionais e requisitos de informao. Ainda
no existe uma forma plenamente aceita de tratar requisitos no funcionais, mas o leitor
interessado poder encontrar diferentes mtodos, a maioria incipiente, na literatura de
Engenharia de Software.
Alguns requisitos no funcionais, quando negados, geram um anti-requisito que
nunca seria pedido por um cliente. Por exemplo, um requisito no funcional comum que
o software seja confivel. Ningum pediria para ser construdo um software no
confivel, porm diferentes clientes esto interessados em diferentes nveis de
confiabilidade e diferentes formas de certificar esse nvel. Deve ser levado em conta que
quanto mais esforo colocado para se alcanar um requisito, maior o custo agregado ao
projeto e isso servir como referncia para o cliente escolher o grau de confiabilidade que
deseja. Por isso um requisito deve ser verificvel. O requisito robusto, por exemplo,
pode ser medido por meio do MTBF4 do sistema.
Outros tipos de Requisitos
James e Susan Robertson [B9] identificam mais trs tipos de requisitos: restries
de projeto, temas de projeto e impulsionadores de projeto.

Tempo mdio entre falhas, do ingls Medium Time Between Failures.

 As restries de projeto so os limites impostos ao sistema para que funcione no seu

ambiente operacional. Estas restries tanto podem ser tcnicas, envolvendo necessidades
ou disponibilidades de fatores como hardware, software, rede e interoperabilidade com
outros sistemas, quanto podem ser ligadas ao negcio. Restries podem ser vistas como
requisitos no funcionais de certa forma especiais, pois so limitantes.
Os impulsionadores de projeto so as foras do negcio que fazem o projeto
acontecer. Podem ser considerados requisitos na medida em que so os geradores originais
dos requisitos funcionais e no funcionais. Tanto o objetivo inicial do sistema como todos
os nele interessados (stakeholders) so impulsionadores.
Fatores Crticos de Sucesso servem para completar o quadro geral de todos os fatores
que influenciaro o sucesso ou o fracasso do projeto.

I.6

Descrevendo Requisitos

Normalmente as especificaes de requisitos so escritas em linguagem natural

(ingls ou portugus, por exemplo). O problema que a forma como falamos e
normalmente escrevemos bastante ambgua. Isso exige que adotemos algumas tcnicas
bsicas, principalmente um formato padronizado, um estilo de linguagem e uma
organizao que facilite a manipulao do conjunto de requisitos.
Algumas dicas para escrever requisitos so [B10]:

Use sentenas e pargrafos curtos.

Use a voz ativa.

Use verbos no futuro5.

Use os termos de forma consistente e mantenha um glossrio.

Para cada requisito, avalie se a partir de sua definio possvel determinar

se ele est pronto ou no.

Garanta que todos os requisitos so verificveis imaginando (e

possivelmente documentando) uma forma de faz-lo.

Verifique requisitos agregados (termos como e e ou so uma boa

indicao) e divida-os.

Mantenha um nvel de detalhe nico em todos os requisitos.

Exemplos de Requisitos
A seguir listamos alguns exemplos de requisitos bem descritos, seguindo o estilo
de exemplos originais de Karl Wiegers 6:

Alguns autores sugerem que o verbo esteja no presente. Na verdade, isso pode causar alguma confuso no
leitor de um sistema a ser feito, pois a leitura dar a idia que o sistema j faz. Alm disso, pode haver a
confuso entre o sistema a ser feito com o sistema a ser substitudo.
6

Software Requirements Specification for Cafeteria Ordering System, Release 1.0

O sistema dever permitir que um paciente marque uma consulta.

O sistema dever confirmar que a consulta foi aceita pelo paciente.

O sistema dever permitir que um condmino solicite a segunda via de sua

conta condominial.

O sistema dever permitir um aviso ao condmino que no pagar sua no

prazo correto.

O sistema dever permitir que um fornecedor cadastre um produto no

catlogo.

O sistema dever informar ao sistema de estoques que um produto foi

vendido.

Todas as sentenas acima usam, na verdade, uma expresso do tipo dever,

traduo do ingls shall, que uma forma tradicional do americano definir uma ordem.
Talvez as seguintes descries sejam mais adequadas a nossa lngua:

O sistema permitir que um paciente marque uma consulta.

O sistema confirmar ao paciente que a consulta foi marcada.

O sistema permitir que um condmino solicite a segunda via de sua conta

condominial.

O sistema permitir um aviso ao condmino que no pagar sua no prazo

correto.

O sistema permitir que um fornecedor cadastre um produto no catlogo.

O sistema informar ao sistema de estoques que um produto foi vendido.

Tambm devemos notar que as entradas do usurio so descritas como dever

permitir. Alguns autores, como o prprio Wiegers, admitem que uma especificao de
requisito exija algo do usurio, como em:

O paciente dever especificar qual a especialidade mdica que deseja.

Essa abordagem no adequada, pois est fazendo uma exigncia ao usurio e no

ao sistema. Uma abordagem mais apropriada seria:

O sistema exigir que o usurio especifique a especialidade mdica que

deseja.

Desta forma deixamos claro que:

1. O requisito do sistema
2. Cabe ao sistema exigir do usurio a resposta
3. No cabe ao usurio saber o que fazer, mas sim ao sistema saber o que o
usurio tem que fazer.
4. A especificao de requisitos do software no requer nada ao usurio.

Em concluso, uma especificao de requisitos s deve exigir funcionalidade do

sistema sendo definido.
Entendemos que muitas vezes um sistema faz exigncias ao ambiente. Essas
exigncias podem algo como o usurio deve falar ingls ou o computador deve ser do
compatvel com chips XYZ/2001. Todas as exigncias que o sistema faz devem ser
documentadas. Uma localizao especfica do documento para isso a seo de suposies
ou dependncias, mas demandas que o sistema faz no podem ser vistas realmente como
um requisito do sistema, apesar de possivelmente definir caractersticas do sistema.
Documentando os requisitos
Requisitos de projeto podem ser descritos de vrias formas. O mtodo Volere
prope as seguintes informaes [B11]:

Nmero identificador,
o para facilitar a discusso, identificamos todos os requisitos
unicamente.

Tipo
o Classificando-o como funcional, no funcional,...

Evento que o atende

Descrio
o Sentena que descreve o evento

Justificativa

Fonte do requisito
o A pessoa ou o grupo que o originou

Critrio de aceitao
o Uma medida que possa ser usada para garantir que o requisito foi
alcanado.

Satisfao do usurio
o Um grau, de 1 (nenhum interesse) a 5 (extremamente satisfeito), por
exemplo, indicando a satisfao do cliente se esse requisito for
alcanado.

Insatisfao do usurio
o Um grau, de 1 (nenhum interesse) a 5 (extremamente insatisfeito),
por exemplo, indicando a satisfao do cliente se esse requisito no
for alcanado.

Dependncias
o Referncias a outros requisitos que dependem de alguma forma
desse requisito

Conflitos
o Referncia aos requisitos que de alguma forma conflitam com esse

Material de apoio

Listagem de material de apoio para atender esse requisito

Histrico

Documentao da criao e das mudanas efetuadas

O mtodo Volere ainda prope que os requisitos sejam levantados em cartes

padronizados. O uso de cartes facilita a discusso, auxiliar a documentao, cria um foco
(se discute apenas o que est no carto sendo tratado) em entrevistas e reunies, e permite
a ordenao manual. Maiores detalhes sobre o mtodo podem ser encontrados na pgina
Web da Atlantyc Systems Guild7.

Figura 9. Algumas necessidades relativas as satisfao ou

insatisfao do usurio quanto a implementao ao no do
requisito.

Dependncia de Requisitos
importante notar que os requisitos no so independentes uns dos outros. Muitos
requisitos s podem ser implementados se outros requisitos forem implementados antes.
Por exemplo, impossvel fazer um relatrio de vendas sem que se cadastrem as vendas
previamente no sistema. Uma das atividades mais importantes da gerncia de requisitos
manter esse relacionamento de dependncia, que influenciar em todo desenvolvimento e
Processo do sistema.

http://www.volere.co.uk/template.htm

Para isso existem algumas solues possveis. Uma delas manter uma tabela de
dependncia de requisitos, outra manter um banco de dados de requisitos que inclua
relaes de dependncia. Existem alguns produtos no mercado especializados na gerncia
de requisitos.
Priorizando Requisitos
Existe uma tendncia grande de o sistema crescer muito durante a anlise.
Principalmente se entrevistamos um grande nmero de pessoas, existe uma facilidade
natural das pessoas para propor novas funcionalidades para um sistema que ainda no
existe, por imaginarem alguma utilidade nessas funes propostas.
Assim, muitas vezes nos vemos envolvidos com uma quantidade de requisitos to
grande que bvio que o sistema a ser feito no poder ser entregue no prazo ou pelo custo
combinado, ou que se pensava em combinar.

Nesse caso, algumas tcnicas podem ser utilizadas para caracterizar o que deve ser
realmente feito ou, pelo menos, em que ordem as coisas devem ser feitas.
A primeira tcnica disponvel associar a cada requisito do sistema uma
importncia. Uma escala de trs ou cinco valores adequada para isso, como em:
Imprescindvel para o sucesso do sistema, Funcionalidade Importante, mas podemos
esperar algum tempo, Ajudaria ter, mas possvel viver sem essa funcionalidade,
Benefcios mnimos, Desnecessrio.
A segunda tcnica disponvel planejar o sistema para ser entregue em vrias
verses, mesmo que nem todas as verses estejam includas nesse contrato, e pedir para o
cliente determinar que funcionalidades devem aparecer em cada verso. Nesse caso pode
ser interessante dar um peso ou custo para cada requisito, de modo que o cliente possa
controlar seus gastos.
Uma terceira tcnica disponvel dar uma moeda virtual para o cliente, por
exemplo, 1000 dinheiros, e pedir para ele distribuir quanto pagaria por cada funo,
priorizando no desenvolvimento aquelas funes que o cliente decidir pagar mais.
Todas essas tcnicas, porm, ficam dependentes de uma outra priorizao
importante dos requisitos: a priorizao por dependncia.
Devem ser levados em conta os vrios fatores que influenciam nessa determinao
de prioridades, entre eles os citados por [B13]:

Diminuir o custo da implementao

Valor para o comprador

Tempo para implementar

Facilidade tcnica de implementar

Facilidade do negcio para implementar

Valor para o negcio

Obrigao por alguma autoridade externa

Questionando os requisitos
Em vrios momentos do projeto, importante tratar a lista de requisitos como uma
lista a ser abertamente questionada. Para isso devemos analisar as caractersticas desejadas
dos requisitos (Seo I.3.1 ) e verificar, para cada requisito, se elas so verdade. Alm
disso, devemos tambm analisar de que forma os requisitos respondem as perguntas 5W2H
(Who, When, Where, What, Which, How, How much). Se o requisito passar por todos os
questionamentos, temos um requisito muito bom. Se falhar em alguns, pode ser que no
seja o momento ainda no projeto ou que a pergunta no seja pertinente, porm deve ser
analisado cada caso.
Os maiores problemas sempre sero encontrados na ambigidade dos requisitos.
Qualquer ambigidade um risco, porm no incio do projeto a ambigidade necessria,
pois decises importantes ainda no foram tomadas. Cabe ao analista saber em que p
est o projeto e qual o nvel de detalhe adequado aos requisitos.

I.7

A Especificao de Requisitos

Uma especificao de requisitos de sistema um documento que rene os requisitos

definidos e aceitos por todos os interessados naquele sistema.
Os assuntos bsicos que devem ser tratados em uma especificao de requisitos so,
segundo um padro IEEE so8:

Funcionalidade, ou o que o software tem que fazer?

Interfaces externas, com quem ou com que sistemas o software interage?

Desempenho, qual a velocidade, disponibilidade, tempo de resposta das

vrias funes, etc.?

Atributos (de qualidade), quais so as consideraes de portabilidade,

correo, manutenibilidade, segurana, etc.?

Restries de projeto impostas a implementao, como padres a serem

seguindo, polticas de integridade da base de dados, limites dos recursos
disponveis, ambiente de operao, etc.?

Segundo o mesmo padro, um sumrio adequado a uma especificao de requisitos

seria:
Sumrio
1. Introduo
1.1 Objetivo
1.2 Escopo
1.3 Definies, acrnimos e abreviaes
1.4 Referencias
8

IEEE, IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specications

1.5 Viso Geral

2. Descrio Geral
2.1 Perspectiva do Produto
2.1.1 Interfaces do Sistema
2.1.2 Interfaces do Usurio
2.1.3 Interfaces de Hardware
2.1.4 Interfaces de Software
2.1.5 Interfaces de Comunicao
2.1.6 Memria
2.1.7 Operaes
2.7.8 Adaptaes necessrios no ambiente
2.2 Funes do Produto
2.3 Caractersticas do Usurio
2.4 Restries
2.5 Suposies e Dependncias
3. Requisitos Especficos
Apndices
ndices
Figura 10. Um roteiro para a especificao de requisitos segundo
a IEEE9.

Entre os apndices, interessante colocar o modelo de dados e quaisquer outros

modelos que possam ser necessrios.

I.8

Mtodos de Elicitao de Requisitos

A elicitao de requisitos o levantamento, registro e validao [B14] das

expectativas dos diversos interessados no sistema, seguido da consolidao e validao
dessas expectativas em requisitos formais. Contemplar essas diferentes vises implica
projetar interesses divergentes e concili-los.
Para levantar requisitos necessria a interao entre aqueles que conhecem os
requisitos ou a necessidades dos usurios e stakeholders e os desenvolvedores. um
processo interativo de comunicao, onde, por aproximaes sucessivas, o desenvolvedor
constri um modelo aceito pelos usurios.

idem

Figura 11 A elicitao de requisitos um processo interativo onde,

por aproximaes sucessivas, o desenvolvedor consegue a
aprovao de uma especificao de requisitos.

O mesmo acontece na investigao que um analista tem que fazer com o cliente em
busca do requisito. Inicialmente o cliente ser ambguo, generalista e paulatinamente, com
a ajuda do analista, dever chegar a uma especificao precisa do que deseja.
Uma receita geral para o levantamento de requisitos pode ser dada em 5 passos:
1. Identificar quem fornecer os requisitos
2. Levantar lista de desejos para estas pessoas
3. Refinar cada lista de desejos at que seja auto-consistente
4. Integrar as listas de desejos de forma que sejam consistentes
5. Determinar os requisitos no funcionais.
Apesar de tudo, no uma tarefa fcil levantar os requisitos. Muitos problemas
podem acontecer. comum que stakeholders no saibam exatamente o que querem ou no
saibam articular propriamente suas idias, especialmente quando o desenvolvedor no
possui o linguajar tpico da rea de aplicao (jargo). Muitas vezes, tambm, os
desenvolvedores pensam entender melhor do problema que seus clientes, propondo
supostas melhorias que afetam custo e aumento o risco dos sistemas propostos.
Processo de elicitao de requisitos
A elicitao de requisitos pode ser modelada em um processo como o proposto por
Christel e Kang, apresentado nas figuras a seguir.

Busca de Fatos
Coleta e Classificao
de Requisitos
Racionalizao e
Avaliao
Priorizao
Integrao e
Validao

Figura 12. O processo de elicitao de requisitos, adaptado de

Christel e Lang [B14].

Tarefas da Elicitao de Requisitos

Tarefas orientadas ao usurio

Tarefas orientadas ao desenvolvedor

Busca de Fatos

Identificar grupos relevantes atravs de

mltiplos nveis da organizao.
Determinar os contextos operacional e
do problema, incluindo a definio dos
modos
operacionais,
objetivos
e
cenrios de misso como apropriados.
Identificar sistemas similares.
Realizar anlise de contexto.

Identificar especialistas do domnio da

aplicao e de desenvolvimento.
Identificar modelo de domnio e modelo de
arquitetura.
Conduzir pesquisas tecnolgicas, para
mais tarde fazer estudo de viabilidade e
anlise de risco.
Identificar custos e restries
implementao
impostas
pelo
patrocinador.

Coleta e Classificao
dos Requisitos

Levantar a lista de desejos de cada

grupo.

Classificar a lista de acordo com

funcionais, no funcionais, restries de
ambiente, restries de projeto e ainda de
acordo com as parties definidas pelo
modelo de domnio e pelo paradigma de
desenvolvimento.

Racionalizao e
Avaliao

Responder questes da forma Por que

voc precisa de X?, a partir de raciocnio
abstrato. Isso auxilia a transformar o
raciocnio das questes sobre como?
para as questes sobre o qu?.

Realizar uma anlise de riscos,

investigando tcnicas, custos, prazos e
incluindo anlise de custos e benefcios e
viabilidade baseado na disponibilidade da
tecnologia.

Priorizao

Determinar funcionalidades crticas para

a misso.

Priorizar requisitos baseados em custo e

dependncia. Estudar como o sistema
pode ser implementado de forma
incremental,
investigando
modelos
arquiteturais apropriados.

Integrao e Validao

Resolver a maior quantidade possvel de

pontos em aberto.
Validar que os requisitos esto
concordando com os objetivos iniciais.
Obter autorizao e verificao para
passar
ao
prximo
passo
de
desenvolvimento (e.g. a demonstrao e
a validao).

Resolver conflitos e verificar consistncia.

Atividade

Tabela 3. Tarefas do processo de elicitao de requisitos, adaptado

de Christel e Kang [B14].

I.9

Mtodos Simples de Elicitao de Requisitos

Existem muitas tcnicas avanadas de elicitao de requisitos que no cabem no

contexto desse livro. Aqui trataremos de duas tcnicas bsicas que coleta de informaes:
a entrevista e reunies de JAD.
A entrevista
Entre as tcnicas mais importantes de elicitao de requisitos est a entrevista. Ela
est constantemente presente dentro de outras tcnicas porque, quase sempre, a Elicitao
de Requisitos em algum ponto - exige comunicao direta com os usurios e outros
interessados e a forma bsica de comunicao, seja de que forma esteja disfarada, a
entrevista.
A entrevista procura explicitar o pensamento do entrevistado a respeito das suas
relaes com seu universo em determinada instncia, tanto como indivduo quanto como
profissional, revelando o conhecimento do entrevistado sobre as pessoas, objetos, fatos e
procedimentos com os quais interage.
Os objetivos so os mais diversos, por exemplo: estabelecer expectativas do
consumidor, verificar nveis de satisfao e necessidades atuais e futuras; estudar
tendncias na satisfao do cliente ao longo do tempo ou avaliar programas em andamento.
O primeiro passo de uma entrevista determinar, entre outros aspectos: seus
propsitos ou objetivos; a informao necessria, e de quem obter, para alcanar esses
objetivos e os recursos disponveis para implementar e manter o processo de pesquisa.
Outros fatores merecem destaque: preciso na determinao da amostra; abrangncia e
relevncia do contedo da pesquisa e, essencial, a validao. Os resultados da entrevista
so sumariados em um relatrio interpretativo que inclui relato sobre os achados e as
recomendaes mais importantes. A anlise pode ser qualitativa ou quantitativa.
Normalmente, as entrevistas abertas esto no primeiro caso, enquanto que os questionrios
so analisados quantitativamente.
A responsabilidade do entrevistador tambm grande. Normalmente, alm das
entrevistas, ele quem integra as diferentes interpretaes, objetivos, metas, estilos de
comunicao, e o uso de terminologia. H tambm outras tarefas complexas como decidir
a oportunidade ou no de incluir certo tipo de informao no conjunto inicial de requisitos.
Finalmente, entrevistar e integrar toma tempo. Como os requisitos so volteis, quanto
mais longo o processo mais facilmente os requisitos deixam de atender as necessidades e
expectativas dos interessados. Todos esses encargos recomendam que o analista conhea
tanto as tcnicas de desenvolvimento quanto o domnio no qual se insere.
Existem vrios tipos de entrevistas. Durante o processo de anlise, elas
normalmente seguem o seguinte processo:
1. Introduo inicial
2. Familiarizao com o ambiente
3. Busca de fatos
4. Verificao de informaes conseguidas de outras formas
5. Confirmao de informaes conseguidas com os candidatos

6. Acompanhamento, amplificao ou clarificao de entrevistas anteriores.

7. Outra grande varivel da entrevista o seu objetivo, entre outros:
8. Levantar informaes sobre a organizao
9. Levantar informaes sobre uma funo de negcio
10. Levantar informaes sobre um processo ou atividade
11. Descobrir problemas
12. Verificar fatos previamente levantados
13. Fornecer informao
14. Obter dicas para entrevistas futuras
H vrias formas de entrevista, entre elas: entrevista por questionrio; entrevista
aberta; entrevista estruturada.
Entrevista por Questionrio
O questionrio muito usado como tcnica de entrevista, principalmente em
pesquisas de mercado e opinio. Exige preparao elaborada. Alguns aspectos particulares
do processo merecem destaque: emprego de vocabulrio adequado para o pblico
entrevistado; incluso de todos os contedos relevantes e de todas as possibilidades de
respostas; cuidado com os itens redundantes ou ambguos, contendo mais de uma idia ou
no relacionados com o propsito da pesquisa; redao clara; execuo de testes de
validade e confiabilidade da pesquisa.
H uma tenso no resolvida entre o uso do questionrio como um evento interativo
ou como instrumento neutro de medida. Por um lado, como entrevista, visto como uma
interao. Por outro lado, no interesse de torn-lo um instrumento, muitos recursos da
interao existentes na conversao no so permitidos, suprimindo recursos de medida de
incertezas de relevncia e interpretao.
Dificuldade importante o fato das palavras possurem significados diferentes para
pessoas diferentes em diferentes contextos. Em interaes normais essas questes de
interpretao so negociadas entre os participantes, mas em entrevistas com questionrios
o treinamento e o mtodo utilizados probem essa negociao. Alm disso, h necessidade
do uso de tcnicas especficas nem sempre do conhecimento dos projetistas - para a
construo e aplicao de questionrios. A menor ambigidade uma das principais
vantagens da entrevista via questionrio.
Para gerar bons itens de questionrio, devemos:

Evitar palavras ambguas ou vagas que tenham significados diferentes para

pessoas diferentes;

Redigir itens especficos, claros e concisos e descarte palavras suprfluas;

Incluir apenas uma idia por item;

Evitar itens com categorias de respostas desbalanceadas;

Evitar itens com dupla negao;

Evitar palavras especializadas, jarges, abreviaturas e anacronismos;

Redigir itens relevantes para a sua pesquisa;

Evitar itens demogrficos que identifiquem os entrevistados

Entrevista Aberta
Esse tipo de entrevista evita muitos dos problemas dos questionrios, porm
tambm cria outros. O entrevistador formula uma questo e permite que o entrevistado
responda como quiser. O entrevistador pode pedir mais detalhes, mas no determina os
termos da entrevista. Permanecem, entretanto, as questes: as perguntas podem ser
respondidas? A resposta faz parte do repertrio normal do discurso do entrevistado? H
muitas coisas que as pessoas sabem fazer, mas tem dificuldade de descrever, como h
tambm o conhecimento tcito, que de difcil elicitao.
Os benefcios das entrevistas abertas so: a ausncia de restries, a possibilidade
de trabalhar uma viso ampla e geral de reas especficas e a expresso livre do
entrevistado.
H desvantagens tambm. A tarefa de entrevistar difcil e desgastante. O
entrevistador e o entrevistado precisam reconhecer a necessidade de mtua colaborao ou
o resultado no ser o desejado. H falta de procedimentos padronizados para estruturar as
informaes recebidas durante as entrevistas. A anlise da informao obtida no trivial.
difcil ouvir e registrar simultaneamente; principalmente, porque h fatos que s tomam
importncia depois de outros fatos serem conhecidos, e a ele j no foi registrado. Da a
importncia da gravao e da respectiva transcrio; fica mais fcil selecionar e registrar o
que relevante e validar com o entrevistado.
So exigncias para o relacionamento entre os participantes de uma entrevista:
respeito ao conhecimento e habilidade do especialista; percepo de expresses no
verbais; sensibilidade s diferenas culturais; cordialidade e cooperao.
Entrevista Estruturada
A entrevista estruturada extrai informaes sobre perguntas especficas. Nesse tipo
de entrevista, importante entrevistar a pessoa certa. uma boa tcnica para ser usada
aps uma pesquisa com questionrio, quando possvel selecionar, entre as respostas, as
partes interessadas com maior potencial de gerao de outras informaes. Suas vantagens
so: Respostas diretas, com menos ambigidade, informao detalhada. Sua desvantagem
bsica que as questes relevantes precisam ser identificadas com antecedncia.
O processo da entrevista
O processo de entrevista no se resume ao ato especfico da entrevista. Na verdade
ele comea muito antes e acaba muito depois. O processo normal da entrevista inclui:
1. Determinao da necessidade da entrevista
2. Especificao do objetivo da entrevista
3. Seleo do entrevistado
4. Marcao da entrevista

5. Preparao das questes ou do roteiro

6. A entrevista propriamente dita
7. Documentao da entrevista, incluindo os fatos e a informao conseguida
durante a entrevista.
8. Reviso da transcrio da entrevista com o entrevistado
9. Correo da transcrio
10. Aceitao por parte do entrevistado
11. Arquivamento
Preparando a entrevista
A preparao uma necessidade bsica da entrevista. No s precisamos preparar a
entrevista propriamente dita, mas tambm preparar a ns mesmos, como entrevistadores, e ao
entrevistado.

Uma entrevista deve ter um objetivo. As perguntas ou o roteiro devem ser

coerentes. Para isso importante a determinao desse objetivo,. O entrevistado deve ter
noo clara da finalidade da entrevista e perceber sua utilidade. Isso se faz por meio de
palestras, textos de divulgao e, principalmente, se explicando ao entrevistado, no incio
da entrevista, seu objetivo e importncia.
Muitas vezes esse objetivo no especfico, principalmente na fase inicial do
projeto. Mas deve ser claro, isso , quando expressado deve permitir que entrevistador e
entrevistado compreendam o motivo da entrevista. Assim, no incio do projeto os objetivos
podem ser: Conhecer o ambiente de trabalho, Levantar expectativas iniciais dos
usurios. J com o passar do tempo do projeto o objetivo se torna mais detalhado, como
em: Levantar os documentos utilizados no processo de compra ou Avaliar as telas
relativas ao cadastro de bens.
A escolha do entrevistado o segundo aspecto importante. Devem ser escolhidas
as pessoas que permitam obter no final das entrevistas uma viso clara e o mais completa
possvel do problema, das diversas formas de analis-lo e solucion-lo. Nunca se deve
tratar um problema a partir de um nico nvel funcional, nem de uma nica viso
organizacional, pois estaramos correndo o srio risco de obter uma viso distorcida.
Devemos lembrar que o sistema afetar todos os nveis funcionais e departamentos da
instituio.
Dependendo do tipo de entrevista, ser necessrio um roteiro ou um questionrio.
No incio da anlise os roteiros levam a execuo de entrevistas abertas, no final geralmente
temos entrevistas por questionrios. Entrevistas estruturadas so preparadas
principalmente para esclarecimento de processos e atividades.
Todos os roteiros e questionrios devem seguir um modelo padro, incluindo a
apresentao e a concluso da entrevista. Quanto maior o nmero de entrevistadores, maior
a importncia de seguir um padro.
Outros aspectos fundamentais a serem preparados so:

A linguagem

A coerncia das perguntas

A programao dos horrios

importante estar preparado para a linguagem a ser usada na entrevista. Nisso

influenciam vrios fatores, como nvel cultural do entrevistado, terminologia do trabalho,
jargo da rea, etc. Devemos evitar ao mximo usar os nossos termos tcnicos e aproveitar
ao mximo a oportunidade de aprender os termos tcnicos do entrevistado. Se necessrio,
ler um pequeno texto esclarecedor sobre a rea e, sempre, ler o glossrio do projeto. O
entrevistador deve sempre esclarecer com o entrevistado todas as dvidas quanto ao
vocabulrio utilizado no ambiente onde o sistema ser implantado.
Marque a entrevista com antecedncia, com confirmao de data, hora, durao e
local por todas as partes. As seguintes regras devem ser observadas quanto ao horrio;

As entrevistas devem ter 30, 60 ou 90 minutos e, no mximo, duas horas.

As entrevistas iniciais podem ser mais longas, enquanto as entrevistas finais

devem ser mais rpidas.

Evite horrios perto da hora do almoo ou no final de expediente, ou em

uma tarde de sexta-feira ou vspera de feriado.

Obtenha o telefone do entrevistado, para poder avis-lo de sua ausncia em

caso de urgncia.

Chegue sempre 10 minutos adiantado e esteja preparado para esperar e para

ter que encerrar a entrevista mais cedo, principalmente com a alta gerncia.

Se possvel, caso a entrevista seja mais curta que o combinado, marque

imediatamente a sua continuao.

Quanto ao material necessrio para uma entrevista, alm do roteiro:

Prepare e teste o equipamento, principalmente um gravador. Atualmente

existem bons gravadores digitais a preos razoveis no mercado.

Tenha pelo menos 2 horas de gravao e um jogo de pilhas extras.

Tenha um caderno de anotaes ( melhor que um bloco) reservado para o

projeto. Canetas de vrias cores, lpis, borrachas.

Realizando a entrevista
O objetivo normal de uma entrevista conseguir informaes do entrevistado, para
isso devemos fazer no s que o usurio fale, mas tambm que ele pense. importante
para o entrevistador no assumir nada e no fazer pr-julgamentos, caso contrrio correr
o risco de fazer uma entrevista viciada.
O entrevistador deve manter o controle o assunto da entrevista. No deixe o
entrevistador mudar de assunto ou tergiversar, mantendo suas perguntas direcionadas para
o objetivo da entrevista.
As duas principais armas do entrevistador so a pergunta e o silncio. Para
perguntar devemos ter conscincia do tipo de pergunta que escolhemos. Se quisermos que

o usurio explique algo, ento devemos utilizar uma pergunta aberta. Isso muito comum
em entrevistas abertas no incio da anlise.
O importante fazer o usurio pensar, para isso, o entrevistador deve evitar
perguntas que contenham a prpria resposta ou as que podem ser respondidas apenas com
um sim ou no. As perguntas fechadas devem ser utilizadas para tirar dvidas do
entrevistador. Use questes comeando com quem, qual, quando, onde, porque
e como sempre que possvel. Tente completar o ciclo (quem qual quando onde
porque como) para todos os assuntos.
Em dvida, pergunta novamente de outra forma. O entrevistador deve pedir que
processos complicados sejam explicados mais de uma vez, preferencialmente sob
perspectivas diferentes. Desenh-los em quadros brancos ou em papel pode ser uma boa
soluo para eliminar qualquer dvida.
importante estabelecer exemplos concretos para o que est sendo descrito pelo
usurio. Tambm, em caso de uma dvida, melhor descrever um exemplo concreto (o
que aconteceria se ...) do que uma dvida abstrata. O entrevistador deve estar consciente
que muito difcil encontrar um entrevistado capaz de raciocinar plenamente de forma
abstrata sobre um problema. Mesmo nesse caso, normalmente a forma abstrata se resume
ao caso perfeito, sendo que as excees so melhores explicadas com exemplos.
No tenha pressa, no responda pelo entrevistado. No se preocupe com a demora
para responder ou o silncio. O silncio, inclusive, uma boa ttica para fazer o
entrevistado continuar falando. Deixe o entrevistado pensar, olhe para ele curiosamente.
Antes de mudar de assunto, verifique sua compreenso, explicando de forma
resumida o que acabou de ouvir. Isso permite ao entrevistado pensar e dar uma clarificao
se necessrio
Esteja atento para a ausncia de crticas por parte do candidato. Isso pode ser
causado pela falta de confiana do entrevistado em voc ou porque o problema
constrangedor demais para ser tratado. O analista deve constatar esse fato no processo de
anlise, mas no durante a entrevista.
As interrupes causadas por fatores externos (telefone, pessoas que entram e que
saem, etc.) podem ser importantes em um processo de entrevistas. Se uma entrevista for
prejudicada por muitas interrupes, isso deve ficar no relatrio da entrevista.
No relatrio, tambm devemos separar o que fato do que opinio.
O Comportamento do Entrevistador
Esteja atento ao prprio comportamento. Lembre-se que no importa sua inteno
ao fazer ou deixar de fazer algo, mas a interpretao que o entrevistado dar ou que fizer
ou no fizer.
No passado era comum que consultores sempre se vestissem de terno, at mesmo
apenas ternos escuros. A maioria das empresas hoje utiliza um cdigo de vestimenta mais
informal. A regra mais atual que o entrevistador ou consultor tome cuidado para no
provocar um grande desnvel entre a sua roupa e a roupa do entrevistado ou cliente, se
adaptando as normas de vestimenta do cliente (ou do mercado ao qual o cliente pertence).

Fisicamente, no faa movimentos desnecessrios como bater o lpis na mesa,

mexer as chaves no bolso, sacudir ou bater os ps, etc. Movimentos automticos e cacoetes
distraem o entrevistado e, alm disso, so interpretados como falta de ateno. No fume,
mas tambm no evite que seu entrevistado fume. No constranja o entrevistado
comentando sobre os males do fumo. No pea bebidas ou alimentos, como caf, mas pode
aceitar o que for oferecido. Se necessrio, pode pedir gua10.
Estabelea um horrio para a entrevista e o cumpra rigidamente. Devido aos
constantes problemas de trnsito da cidade, e a necessidade de se identificar para
seguranas e secretrias, o entrevistador deve sempre planejar chegar ao local com uma
folga de tempo, algo em torno de 15 minutos.
Mantenha o interesse. Tome notas, mas no seja obsessivo, principalmente no
interrompa o candidato para manter suas notas atualizadas. Se autorizado, grave a
entrevista e a reveja mais tarde se necessrio. Escute ativamente sem interromper. O
entrevistado que deve falar a maior parte do tempo.
Utilize um tom educado e corts. No seja engraado, sarcstico ou depreciativo.
No faa comentrios pejorativos ou preconceituosos. No faa comentrios sobre poltica
e religio, ou outro tema controverso. Seja cordial, mas sem deixar de ser profissional.
Pergunte e responda com cortesia e honestidade. No de opinies particulares, mesmo
quando pedido. A entrevista o momento de levantar informaes, no de emiti-las.
No de a um entrevistado informaes passadas por outros entrevistados.
Educadamente, responda que no cabe a voc decidir ou opinar.
Evite, de toda a forma, confrontar o entrevistado. No torne a entrevista um
interrogatrio. Evite discutir, mesmo que no concorde com o usurio. Em caso de
discusso, defina claramente o motivo do desacordo, seja ele motivado por fato ou por
opinio. Utilize perguntas para restabelecer a comunicao em caso de desacordo. Se
necessrio, pea desculpas.
Se necessrio elucidar algo que foi mal explicado, lembre-se que voc no
entendeu e que precisa de maiores detalhes. Se os detalhes no estiverem disponveis, d
ao entrevistado a chance de envi-los mais tarde.
Basicamente o entrevistador deve ser muito educado.
Roteiro Bsico
1. Apresente-se ao entrevistado: Ol, muito prazer, eu sou fulano-de-tal,
responsvel por parte do projeto XYZ. Apresente seu carto de visitas se
for o primeiro encontro.
2. Informe ao entrevistado o motivo da entrevista e porque foi selecionado:
Estou aqui para levantar o funcionamento da sua rea, e seu nome foi
escolhido por ser o funcionrio mais experiente ou Estou aqui para
levantar o funcionamento da atividade X, que de sua responsabilidade.

10

As regras de etiqueta consideram a gua a nica coisa que pode ser pedida em qualquer situao.

3. Deixe clara a idia que o conhecimento e as opinies do entrevistado so

importantes e sero teis no processo de anlise
4. Diga o que vai acontecer com a informao levantada
5. Garanta que o entrevistado ler a transcrio da entrevista e ter a
oportunidade de corrigi-la, garanta que nada ser passado a outras pessoas
sem a reviso e verificao do entrevistado.
6. Determine os assuntos confidenciais ou restritos a serem tratados na
entrevista
7. Deixe claro que no haver conseqncias negativas em funo do resultado
da entrevista
8. Solicite permisso para gravar a entrevista
9. Se autorizado, inicie a gravao com um texto de apresentao: Entrevista
realizada no dia X....
10. Faa a entrevista at faltarem 5 ou 10 minutos para o tempo determinado
11. Avise ao entrevistado que o tempo est acabando e pergunte se gostaria de
adicionar alguma informao
12. Solicite ao candidato que responda as perguntas de concluso
13. Conclua a entrevista de forma positiva, relatando brevemente o resultado
positivo alcanado.
14. Se necessrio, marque outra entrevista.
15. Entregue ao candidato o formulrio de avaliao de entrevista e o envelope
correspondente. Ensine-o a enviar a avaliao preenchida.
16. Despea-se educadamente, agradecendo a ateno e o tempo dispensado.
Muitas vezes a entrevista precedida por um bate-papo informal de apresentao.
Tente manter essa conversao em um tempo mnimo razovel.
Documentando a Entrevista
A entrevista deve ser documentada logo aps sua realizao. Ao document-la
rapidamente, estar garantindo que recuperar mais informao.
A documentao da entrevista deve fornecer a seguinte informao.

A data, hora e local da entrevista.

Nome do entrevistador

Cargo do entrevistador

Nome do entrevistado

Funo do entrevistado e a descrio desse cargo

Se necessrio, informaes de background do entrevistado, como

experincia no cargo ou com computadores.

Organograma do entrevistado (superior imediato, colegas do mesmo nvel,

subordinados).

O objetivo da entrevista

Nomes e ttulos de todos os outros presentes na entrevista

Uma descrio completa dos fatos descritos e opinies do entrevistado

Opcionalmente, uma transcrio da entrevista, possivelmente expurgada

das falas que no tinham relao com o assunto da entrevista.

Todas as concluses tiradas dos fatos e opinies como apresentados

Todos os problemas de negcio levantados durante a entrevista

Exemplos de todos os relatrios, diagramas, documentos, etc., discutidos

durante a entrevista.

Todos os desenhos e diagramas feitos a partir ou durante a entrevista

Qualquer comentrio relevante feito pelo entrevistado

Todos os nmeros relevantes (quantidades, volume de dados, etc.) coletados

durante a entrevista.

importante notar que o relatrio da entrevista deve ser aceito pelo entrevistado.
normal o entrevistado remover alguma coisa ou colocar algo a mais. O analista deve ficar
atento aos motivos do usurio em fazer modificaes.
Se houver discusso quanto interpretao de algo e o analista achar essencial
manter sua verso no relatrio, deve tambm permitir que o entrevistado coloque sua
verso.
As perguntas de concluso
Ao final da entrevista, importante realizar uma avaliao da percepo do
entrevistado sobre a entrevista que acabou de ser realizada. Para isso necessrio que seja
respondido um formulrio, contendo perguntas como:

Voc acha que essa entrevista cobriu tudo que era necessrio?

Voc acha que foram feitas as perguntas certas?

Voc acha que era a pessoa mais certa para responder essas perguntas?

JAD
Outra tcnica importante de elicitao de requisitos, que merece um tratamento
separado, o JAD.
Muitas vezes, quando um grupo de informtica entrega um sistema de informao
aos seus clientes escuta a frase: no era isso que eu queria! Isto acontece porque os
desenvolvedores no conseguiram levantar com os usurios suas verdadeiras necessidades.
Este problema de comunicao pode ter diversas causas: linguagem especializada
de ambas as partes, desconhecimento da rea de atuao pelos desenvolvedores,

preocupaes com a tecnologia empregada ao invs das necessidades dos usurios, etc. Na
fase inicial do projeto, a dificuldade de comunicao entre clientes e equipe de
desenvolvimento a principal causa de defeitos que sero encontrados no produto final.
Para enfrentar os problemas de comunicao entre desenvolvedores e usurios,
foram desenvolvidos, ao final da dcada de 1970, vrios mtodos onde o desenvolvimento
de sistemas baseado na dinmica de grupo.
Na forma tradicional de desenvolver sistemas os analistas entrevistam os usurios,
um aps outro, tomando notas que so mais tarde consolidadas e ento validadas com o
usurio, finalmente se transformando em um documento de anlise.
O JAD, Joint Application Design, ou Mtodo de Projeto Interativo, substitui as
entrevistas individuais por reunies de grupo, onde participam representantes dos usurios
e os representantes dos desenvolvedores.
Quando o mtodo aplicado de forma correta, os resultados alcanados
ultrapassam os objetivos imediatos da obteno de informao dos usurios e cria um
ambiente de alta sinergia na equipe, onde todos se sentem comprometidos com as solues
encontradas. Esse comprometimento permite que todos se considerem proprietrios e
colaboradores no desenvolvimento do sistema.
O Objetivo do Mtodo
O objetivo do mtodo extrair informaes de alta qualidade dos usurios, em curto
espao de tempo, atravs de reunies estruturadas para alcanar decises por consenso.
Os Componentes
O lder de sesso tem como tarefa nmero um conduzir o grupo para solues de
consenso. Esse lder de sesso age como facilitador, um servidor neutro dentro do grupo
que no avalia nem contribui com idias. A responsabilidade do facilitador sugerir
mtodos e procedimentos que ajudem o grupo a concentrar energia em tarefas especficas,
garantindo a todos os membros do grupo condies de participar.
O documentador um auxiliar imparcial do lder de sesso, responsvel pelo
registro das decises e especificaes produzidas. Apenas as informaes relevantes so
documentadas, segundo orientao do lder de sesso.
O patrocinador detm a autoridade formal sobre as reas afetadas pelo sistema,
estabelecendo diretrizes e objetivos do projeto.
A equipe responsvel pelo contedo da sesso, representando as reas envolvidas
no projeto.
A Dinmica
A base de trabalho a equipe presente na reunio. Devemos combinar algumas
regras de jogo, de modo a alcanar o mximo de produtividade. natural que em um
grupo de 15 pessoas surjam discusses, conversas paralelas, interrupes, etc. Em respeito
ao tempo precioso dos participantes vamos necessrio estabelecer um cdigo de
cooperao.

O Ambiente
O Ambiente fsico da reunio fundamental para a produtividade dos trabalhos. Os
seguintes aspectos devem ser considerados:
Os participantes devem estar organizados de forma a poderem se olhar e olhar para
o lder de sesso. A melhor arrumao a em forma de U.
No devem acontecer interrupes aos participantes.
Todos devem cumprir a agenda, principalmente o incio e o fim da reunio.

Figura 13. Uma sala de JAD bem planejada

O Consenso
A forma mais produtiva de deciso do grupo aquela obtida por consenso.
Consenso no a unanimidade de opinies, mas, sim, a situao em que cada membro
concorda que a soluo encontrada a melhor para o grupo e que possvel conviver com
ela sem ferir convices ou valores essenciais.

I.10 Exerccios
Projeto 1: Livraria ABC
Baseado em todos os textos disponveis sobre a Livraria ABC, faa:
1. Uma lista de requisitos funcionais preliminares

2. Uma lista de requisitos no-funcionais preliminares

3. Uma lista de requisitos de informao preliminares
Projeto de Curso
Para o seu projeto de curso, faa uma lista com:
1. Requisitos funcionais preliminares
2. Requisitos de informao preliminares
3. Requisitos no funcionais preliminares
4. Documente cada requisito dessa lista de acordo os descritores de requisitos
mostrados nesse captulo.
5. Para o seu projeto de curso, prepare:
6. Um roteiro de uma entrevista inicial do projeto
7. Um questionrio a ser feito com os usurios atuais do servio com a
finalidade de descobrir sua qualidade