UNIVERSIDADE FEDERAL DE PERNAMBUCO

PS-GRADUAO EM CINCIA DA COMPUTAO

CENTRO DE INFORMTICA

UM ESTUDO SOBRE A VALIDAO DE

REQUISITOS NO CONTEXTO DA
ENGENHARIA DE SOFTWARE
Autor

Alberto Ramos de Lima

Orientador

Prof. Jaelson Freire Brelaz de Castro

Recife, maro 2008
2008

Universidade Federal de Pernambuco

Centro de Informtica

ALBERTO RAMOS DE LIMA

ndice
1

Introduo .......................................................................................3
1.1 Motivao..................................................................................3
1.2 Objetivos...................................................................................4
1.3 Organizao do Trabalho...........................................................4

Processo de Engenharia de Requisitos ..............................................6

2.1 Viso Geral do Processo de Engenharia de Requisitos.................6
2.1.1 Entradas e Sadas do Processo .............................................7
2.2 Atividades do Processo de Engenharia de Requisitos ..................8
2.3 Gerenciamento de Requisitos...................................................12

Validao de Requisitos..................................................................15
3.1 Processo de Validao de Requisitos ........................................15
3.2 Tcnicas de Validao de Requisitos ........................................21
3.2.1 Reviso de Requisitos ........................................................21
3.2.2 Prototipao......................................................................25
3.2.3 Testes de Requisitos..........................................................27

Consideraes Finais ......................................................................30

Referncias Bibliogrficas...........................................................................31

1 Introduo
Este primeiro captulo mostra a motivao de se realizar a pesquisa
deste trabalho, bom como toda sua organizao.

1.1 Motivao
notrio o crescimento do mercado de Tecnologia da Informao e ele
traz consigo o aumento da concorrncia entre as empresas produtoras de
software, as quais precisam buscar diferenciais para agregar valor a seus
produtos e, assim, expandir seu mercado consumidor Um dos fatores, talvez
o principal, que vem se mostrando eficiente em diferenciar empresas
produtoras de software a implantao de um processo de garantia da
qualidade de software [GOMES 2005].
Na prtica, empresas bem-sucedidas da rea de construo de
software tm percebido que um compromisso organizacional com a
qualidade traz melhorias no tempo de desenvolvimento, reduo de custos e
permite que novas funcionalidades sejam adicionadas com maior facilidade
[IBM 2004]. Nesse aspecto, a Engenharia de Requisitos tem um papel
preponderante.
Estudos demonstram que uma grande quantidade de projetos de
software so cancelados ou fracassam por no atenderem completamente as
necessidades dos clientes e excederem o prazo e o oramento estimados.
No h uma explicao simples para este fenmeno, mas diversos trabalhos
apontam deficincias nos requisitos dos sistemas como uma das principais
causas de fracassos em projetos de software [ESPINDOLA 2004].
3

A Engenharia de requisitos (ER) o processo de descoberta de

funcionalidades e restries de um sistema, identificando stakeholders e
suas necessidades e documentando essas descobertas de uma forma que
possibilite a anlise, comunicao e uma implementao futura [NUSEIBEH
2000].
E no contexto na Engenharia de Requisitos que a atividade de
Validao de Requisitos apresentada como fundamental na garantia do
desenvolvimento de produtos cada vez melhores, minimizando o re-trabalho
e custo e maximizando os lucros para as empresas.

1.2 Objetivos
Este trabalho tem como objetivo primordial a explicitao dos
conceitos relativos Validao de Requisitos, bem como o estudo de
algumas tcnicas usadas na execuo desta atividade. Alm disso, objetivase dar uma viso geral do Processo de Engenharia de Requisitos, suas
atividades e relatar a importncia da Validao de Requisitos neste contexto.

1.3 Organizao do Trabalho

A monografia est estruturada em captulos que se dividem da
seguinte forma:
Captulo 1 introduz o trabalho, apresenta as razes pelas quais
deram motivao para esse estudo.
Captulo 2 - apresenta uma viso geral do Processo de Engenharia de
Requisitos, descrevendo sucintamente cada uma de suas atividades.

Captulo 3 apresenta de forma mais detalhada a Validao de

Requisitos, destacando seus conceitos e algumas tcnicas existentes para
facilitar a execuo desta atividade.
Captulo 4 apresenta as consideraes finais do trabalho.

2 Processo de Engenharia de Requisitos

Requisitos
Neste captulo apresentaremos as definies envolvidas no Processo de
Engenharia de Requisitos, explicitando suas entradas, sadas e atividades.

2.1 Viso Geral do Processo de Engenharia de Requisitos

O processo de engenharia de requisitos um conjunto estruturado de
atividades que so seguidas para derivar, validar e manter um documento de
requisito [KOTONYA 1998]. Uma descrio completa do processo deve
incluir: (a) quais atividades so executadas; (b) a estruturao e o
cronograma delas; (c) quem o responsvel por cada uma das atividades; (d)
suas entradas e sadas; e (e) as ferramentas usadas para suportar a
engenharia de requisitos.
Podemos definir as entradas e sadas de um processo da Engenharia de
Requisitos na Figura 1 [KOTONYA 1998].

Figura 1 Processo da Engenharia de Requisitos

Para melhor entendimento, seguem as descries de cada entrada e

sada que compem o processo acima.

2.1.1 Entradas e Sadas do Processo

De acordo com a Figura 1, temos o detalhamento de cada uma das
entradas e sadas que fazem parte do Processo de Engenharia de Requisitos
[KOTONYA 1998].

Entradas
o Informaes Existentes do Sistema - Refere-se a informaes
gerais sobre o sistema que ser substitudo ou criado e de
outros sistemas com o qual o sistema dever interagir.

o Necessidades dos Clientes/Usurios - Refere-se a uma descrio

das necessidades das partes interessadas para apoiar seu
trabalho.

o Padres Organizacionais - Refere-se a padres e normas

adotadas pela empresa para o desenvolvimento de sistemas,
incluindo mtodos para o desenvolvimento, prticas para
garantia de qualidade, etc..

o Regras e Regulamentos - Normas e regulamentos externos que

se apliquem ao sistema.

o Informaes do Domnio
Domnio - Informaes gerais sobre o domnio
do sistema.

Sadas

o Requisitos Agregados - Descrio dos requisitos levantados,

avaliados e aprovados pelas partes interessadas.

o Especificao do Sistema - Uma especificao mais detalhada do

sistema a ser desenvolvido.

o Modelos do Sistema - Um conjunto de modelos que descrevem o

sistema a partir de diferentes perspectivas.

2.2 Atividades do Processo de Engenharia de Requisitos

Diversas atividades podem ser definidas para o processo da engenharia
de requisitos. A diversidade existente entre os processos definidos por vrios
autores se deve a complexidade da rea, a interpretao da resoluo dos
problemas ou as diferentes reas de aplicao da engenharia de requisitos.
Com este panorama no existe um consenso sobre um modelo de processos
para a Engenharia de Requisitos, viabiliza-se assim a definio e a
modelagem de um processo de requisitos que suporte a construo de
sistemas de informao [GENVIGIR 2005].

Podemos relacionar como atividades da Engenharia de Requisitos as

atividades abaixo.

Elicitao de Requisitos

a atividade relacionada com a identificao dos requisitos do sistema,

a partir de consulta aos representantes de cada grupo de usurios; da anlise
de documentos do domnio em questo; do conhecimento desse domnio;
e/ou de pesquisas de mercado. A finalidade geral do processo de elicitao
identificar os fatos que compem os requisitos do sistema, de forma a prover
o mais correto entendimento do que dele esperado [PAIM 2003].

Anlise e Negociao de
de Requisitos
Envolve atividades que visam descobrir problemas com os requisitos
de sistema e estabelecer um acordo de mudanas que satisfaa todos os
afetados. O processo de anlise e negociao caro e demorado porque
requer pessoas qualificadas e experientes para dedicar tempo leitura
cuidadosa de documentos e identificao das implicaes contidas nas
declaraes presentes nesses artefatos [KOTONYA 1998). Na maioria das
vezes, atividades de anlise e negociao de requisitos so executadas de
forma paralela ou intercalada, em conjunto com atividades de elicitao de
requisitos.

Documentao de Requisitos

Nesta fase, os requisitos acordados so anotados num documento que

rene, num nvel apropriado de detalhe, o escopo de requisitos que servir
como base para o processo de desenvolvimento do software. O documento
de requisitos serve como um contrato entre usurios e desenvolvedores, e
deve ser formatado e estruturado de acordo com padres organizacionais
[PAIM 2003].

Validao de Requisitos

definida como o processo que certifica que o modelo de requisitos

gerado esteja consistente com as necessidades e intenes de clientes e
usurios [PAIM 2003]. Essa viso da atividade de validao retrata um
processo contnuo, ocorrendo na maior parte do tempo em paralelo com as
fases de elicitao e especificao (anlise, negociao e documentao). De
fato, a validao no s aplicada ao modelo final de requisitos, mas
tambm a todos os modelos intermedirios gerados ao longo do processo de
requisitos.
O sucesso de um projeto diretamente afetado pela qualidade do
Documento de Requisitos. desejvel que cada requisito relacionado no
Documento de Requisitos apresente as caractersticas a seguir [SAYAO 2003]:
Univocamente identificvel: requisitos que referenciam tabelas ou
figuras ou que so na verdade compostos por outros devem ser
individualizados;

10

Ser necessrio: deve refletir uma funcionalidade ou caracterstica

essencial, que no possa ser preenchida por outra existente no produto ou
processo; sua ausncia implicar numa deficincia no sistema;
Ser conciso: a definio do requisito deve ser clara e objetiva, sendo
facilmente compreensvel;
Independente de implementao: esta caracterstica indica que a
definio do requisito deve apontar para o que deve ser feito, e no para
como faz-lo. Adequada na maior parte das vezes, esta caracterstica no
entanto funo de requisitos no funcionais, os quais podem prdeterminar uma srie de aspectos de implementao;
Vivel: claramente, a implementao do requisito deve ser possvel de
ser feita, nas condies e no estado-da-arte atuais, e a um custo razovel;
Bem definido: a definio deve procurar ser objetiva e o mais completa
possvel, no necessitando de informaes adicionais para ser entendida;
No ambguo: muitos documentos de requisitos so escritos em
linguagem natural, que inerentemente ambgua; nesses casos deve-se
utilizar tambm um glossrio ou incluir o Lxico Ampliado da Linguagem na
baseline de requisitos, possibilitando a todos os envolvidos o mesmo
entendimento;
Consistente: ele no deve estar em conflito ou contradio com outros
requisitos. Cada requisito deve ser consistente com todos os demais
requisitos na especificao; a consistncia tambm deve existir entre os
vrios nveis de abstrao, se utilizada a decomposio de requisitos em
nveis;

11

Unicidade:
Unicidade no deve haver duplicidade de requisitos, ou seja, no
devem existir vrios requisitos correspondendo a uma mesma caracterstica
ou funcionalidade;
Verificvel/mensurvel: deve ser possvel, aps o sistema estar
codificado, verificar se o requisito foi atendido (est presente no sistema) e
se a implementao est correta. Isto particularmente importante para
requisitos no funcionais, como por exemplo desempenho, dado que
relativamente comum encontrar definies do tipo "o tempo de resposta
deve ser adequado" ou "o usurio no deve ficar aguardando muito tempo
pela informao solicitada";
Categorizado: deve estar explicitamente indicado a categoria qual ele
pertence, ou seja, se requisito funcional, funcional, no funcional, inverso
ou de interface.
Os requisitos de um projeto devem estar claramente definidos,
possibilitando assim, aps a fase de testes, a validao do software pelos
clientes e a concluso que os mesmos foram corretamente atendidos [SAYAO
2003].

2.3 Gerenciamento de Requisitos

Geralmente no h uma fronteira bem definida entre essas atividades e
algumas delas ocorrem de forma paralela. Alm disso, o gerenciamento de
requisitos uma atividade que ocorre durante todo o processo. Atravs do
gerenciamento, pode-se controlar a rationale (ou razo) dos requisitos,
atravs da evoluo destes, alm da possibilidade de realizar o rastreamento,

12

que uma atividade muito importante para verificar impactos de mudanas

em requisitos consolidados [KOTONYA 1998].

Uma dos maiores impasses para a Engenharia de Requisitos a

averiguao e a agregao de novos requisitos ao sistema. Isso acontece em
virtude do impacto das propostas de mudanas, a inflexibilidade dos
processos e a dificuldade de assessorar essas mudanas.
O processo de gerncia de requisitos tem por objetivo resolver tais
problemas tendo como principais objetivos o gerenciamento das mudanas,
o gerenciamento entre requisitos relacionados e o gerenciamento das
dependncias entre a documentao de requisitos e outros documentos
originados durante outros processos da engenharia de software [KOTONYA
1998].
Os requisitos s podem ser gerenciados efetivamente se existir uma
forma de rastrear esses requisitos. Um requisito inteligvel se existe alguma
forma de descobrir quem sugeriu o requisito, por que o requisito existe, com
quem o requisito est relacionado e como o requisito relaciona outras
informaes como implementao e documentao de usurio.
Um bom gerenciamento de requisitos deve manter informaes entre
qual a relao dos requisitos levantados e os benefcios deste requisito ao
usurio.
Um modelo descreve as atividades existentes em um processo. No
existe um nico modelo de processo para a Engenharia de Requisitos, pelo
contrrio, cada organizao pode implantar um processo especfico que

13

atenda as suas necessidades. Por outro lado podemos ter modelos de

processos definidos para determinadas reas de domnio [KOTONYA 1998].

14

3 Validao de Requisitos
Todas

as atividades

relativas

Engenharia

de

Requisitos

so

fundamentais para o desenvolvimento de documentos e software que

atendam

essencialmente

as

necessidades

restries

dos

sistemas

solicitados pelos clientes. No entanto, neste trabalho, vamos nos deter a

ltima atividade deste processo: a validao de requisitos, que tem como
objetivo fundamental mostrar que os requisitos definem o sistema que o
cliente deseja.

3.1 Processo de Validao de Requisitos

A Validao de Requisitos tem o objetivo de apresentar os requisitos
que definem o sistema e realizar a validao dos requisitos durante o
andamento das fases anteriores, uma vez que mudanas e ajustes ao final de
todo o processo significam aumento considervel de custos. Esta etapa
apoiada pelo uso do documento de requisitos.
Deve haver uma cuidadosa avaliao dos requisitos, com nfase em
sua consistncia e completude. Nessa atividade devem-se identificar
possveis problemas nos requisitos antes que o documento produzido sirva
de base para o desenvolvimento do sistema.
Validar os requisitos significa confirmar que o documento de requisitos
e suas especificaes complementares refletem as reais necessidades dos
clientes e usurios finais, autenticando os artefatos que serviro de base
para as fases subseqentes do processo de desenvolvimento. De acordo com
Kotonya [KOTONYA 1998], cuidadosas checagens devero ser realizadas nos
15

requisitos para garantir consistncia e integralidade. Em geral, a validao

deve criar os meios necessrios para que ocorra um consenso entre as partes
envolvidas no projeto, geralmente com objetivos conflitantes.
Segundo Loucopoulus [LOUCOPOULUS 1995], o processo de validao
de requisitos definido como a atividade na qual certifica que o documento
de requisitos consistente com as necessidades dos usurios. Descrever os
requisitos de forma explcita uma condio necessria no somente para
validar os requisitos mas tambm para resolver conflitos entre usurios.
De acordo com Sommerville [SOMMERVILLE 2003], necessrio que
exista validade na identificao de funes que so exigidas para atender aos
diversos usurios do sistema; consistncia para verificar se os requisitos no
possuem descries diferentes para uma mesma funo no sistema;
completeza para incluir todas as funes e restries solicitadas pelo cliente;
realismo sob tica da tecnologia para que seja assegurada a implementao
e facilidade de verificao para que possam existir verificaes que
minimizem possveis divergncias entre cliente e fornecedor.
Em geral, a validao de requisitos considerada uma atividade
complicada por dois principais motivos. Inicialmente, a prpria natureza
filosfica desse processo, onde levado em considerao o que verdadeiro,
permite que muitos pesquisadores comparem a validao de requisitos com
o problema de validao do conhecimento cientfico [NUSEIBEH 2000]. O
segundo motivo social e est relacionado com a dificuldade de obter um
consenso entre diferentes usurios com objetivos conflitantes [LAMSWEERDE
1998].

16

 certo que a validao de requisitos pode requerer vrias sesses de

trabalho at que todos encontrem no somente pontos de concordncia a
respeito dos requisitos, mas principalmente visualizem as implicaes
futuras de suas decises. Nesse sentido, a participao de especialistas de
domnio contribui sobremaneira para a orientao de clientes, usurios e
desenvolvedores na resoluo de possveis impasses.
A viso da atividade de validao retrata um processo contnuo,
ocorrendo na maior parte do tempo em paralelo com as fases de elicitao e
especificao (anlise, negociao e documentao). De fato, a validao no
s aplicada ao modelo final de requisitos, mas tambm a todos os modelos
intermedirios gerados ao longo do processo de requisitos.
A validao de requisitos um dos mais importantes na Engenharia de
Requisitos. Isto porque tal como um documento de requisitos bem definido
permite a correo de incoerncias e inconformidades no desenvolvimento
de um produto de software, a validao permite minimizar o tempo gasto na
deteco dessas incoerncias e inconformidades devido sua alta eficincia
na descoberta. Tambm porque como este processo que permite a
identificao destas mesmas incoerncias na fase anterior verso final do
relatrio de requisitos, minimiza grandemente o risco de encontrar estas
incoerncias

numa

fase

tardia,

ou

at

mesmo

na

terminao,

do

desenvolvimento do sistema. fcil entender que um erro encontrado numa

fase tardia do desenvolvimento do projeto pode ser desastroso, pois a sua
alterao poder ser bastante custosa, se no incomportvel, em termos
temporais [WIKIPEDIA 2007].

17

Fazendo uma analogia, a validao de requisitos est para o

documento de requisitos assim como a fase de testes unitrios e de sistema
est para a fase de desenvolvimento de um projeto de software.
Outro grande desafio durante a validao de requisitos demonstrar
que a especificao dos requisitos do sistema est correta. Enquanto o
projeto e a implementao possuem o documento de requisitos para verificar
seus resultados, a validao de requisitos no possui nenhuma outra
representao que pode ser usada como base. Ou seja, no existe uma forma
para demonstrar formalmente que a especificao est correta [KOTONYA
1998].
Alguns problemas, muitas vezes, s so detectados durante a
Validao de Requisitos. Dentre eles podemos citar:

Falta de conformidade com padres de qualidade;

Requisitos ambguos;

Erros em modelos do sistema ou do problema;

Conflitos entre requisitos no detectados durante a anlise.

Esses problemas devem ser solucionados antes da aprovao do

documento de requisitos e usado como base para o desenvolvimento do
sistema. Em muitos casos, os problemas sero simplesmente problemas de
documentao e podem ser corrigidos para melhorar a descrio dos
requisitos. Em outros casos, os problemas resultam de falhas na elicitao,
anlise e modelagem de requisitos [KOTONYA 1998].

18

O principal problema da validao de requisitos que no existe um

documento que pode ser base para a validao. Um projeto ou um programa
pode ser validado de acordo com a especificao. Por outro lado, no h uma
maneira de demonstrar que uma especificao de requisitos esteja correta
com respeito a alguma outra representao do sistema.
A Figura 2 apresenta as entradas e sadas do Processo de Validao de
Requisitos [KOTONYA 1998].

Figura 2 Entradas e Sadas do Processo de Validao de Requisitos

Entradas
o Documento
Documento de Requisitos (Requirements Document) Deve ser
uma verso completa do documento ao invs de um rascunho
no finalizado. Deve estar formatado e organizado de acordo
com padres organizacionais.

o Padres
processo

Organizacionais
de

validao

verificar

(Organisational

Knowledge)

de

deve

requisitos

conformidade em relao a padres organizacionais. Todos

19

padres relevantes para o documento de requisitos deve ser

entrada para o processo de validao.

o Conhecimento Organizacional (Organisational Standards)

Standards) No
uma entrada tangvel, mas, na prtica, muito importante. As
pessoas envolvidas na validao de requisitos podem conhecer a
organizao, sua terminologia particular e suas prticas e o
perfil das pessoas envolvidas no desenvolvimento e uso do
sistema.

Sadas
o Lista de Problemas (List
(List of Problems) Lista de problemas com o
documento de requisitos. Idealmente, deve ser organizada por
tipo de problema (ambigidade, incompletude, etc). Na prtica
difcil classificar problemas dessa maneira.

Aes Acordadas (Agreed Actions) ) Lista de aes em

resposta a problemas com requisitos que devem ser aceita em
comum acordo por aqueles envolvidos no processo de validao.
No

necessrio

haver

uma

correspondncia

1:1

entre

problemas e aes.

H sempre uma tendncia natural de tornar mais rpido o processo de

validao para se comear a fase de implementao. Esse tipo de
pensamento acontece especialmente quando os prazos esto curtos. Por
20

outro lado, esse procedimento pode ser danoso, pois qualquer atropelo
poder incorrer em fases de reviso e re-anlise, aumentando as mtricas e
o tempo do processo.

3.2 Tcnicas de Validao de Requisitos

Existe uma variedade de tcnicas que podem ser aplicadas para apoiar
o processo de validao. Dentre elas podemos destacar:

3.2.1 Reviso de Requisitos

Segundo Naddeo [NADDEO 2002], a principal tcnica utilizada na
validao de requisitos basicamente aquela utilizada tambm em outras
atividades do processo de software: revises. Revises envolvem um grupo
de pessoas lendo e analisando a documentao de requisitos procura de
possveis problemas. A reviso de requisitos constitui-se de uma reunio
formal na qual um engenheiro de requisitos apresenta cada um dos
requisitos para crtica e identificao de inconsistncias pelo grupo. As
inconsistncias encontradas so registradas para posterior discusso. O
grupo de reviso deve ento tomar decises que se materializam em aes a
serem executadas para corrigir os problemas identificados [WIKIPEDIA 2007].
Apesar de se ter pouco publicado sobre reviso de requisitos e como
essa deve ser conduzida, tem-se evidencia que a inspeo de programas so
eficientes para a descoberta de problemas com cdigo e vrias formas de se
organizar os processos de inspeo do programa foram propostas [SANTOS
2007]
A Figura 3 representa um processo de reviso de requisitos.

21

Figura 3 Processo de Reviso de Requisitos

Os principais estgios no processo de reviso de requisitos so

descritos da seguinte forma [KOTONYA 1998]:

Reviso de Plano a equipe de reviso selecionada, assim como um

local para reunio.

Distribuio de documentos os documentos de requisitos e outros

documentos relevantes so distribudos para os membros da equipe de
reviso.

Preparao para Reviso os Revisores lem os documentos de

requerimento e identificam conflitos, omisses, inconsistncias,
desvios dos padres e outros problemas derivados.

22

Reunio de Reviso os comentrios individuais e os problemas so

discutidos e uma srie de aes estabelecidas para sanar os
problemas.

Atividades FollowFollow-up Os responsveis pela reviso averiguam se as

aes foram postas em prtica para solucionar tais problemas
elencados.

Reviso de documentos os documentos so revistos para refletir

sobre as aes acordadas. Nesse ponto, os requisitos podem ser
aceitos ou simplesmente solicitada uma nova reviso.

A Reviso de Requisitos deve ser conduzida por algum que no esteve

envolvido produzindo os requisitos que esto sendo validados. Durante o
encontro, um membro do grupo deve fazer a ata dos requisitos conflitantes.
Na inspeo do programa, uma prtica comum reportar os erros para
a equipe responsvel pela programao. Todavia, a equipe de reviso que
decide que aes ou mudanas devem ser tomadas na correo dos erros.
Diferentemente dos erros de programao, tais problemas requerem
discusso e negociao para se chegar a um denominador comum. As aes
devem compreender o seguinte [KOTONYA 1998]:

Clarificao dos requisitos

requisitos os requisitos podem estar expressos
inadequadamente ou podem ter sido omitidos acidentalmente. Nesse
ponto, deve-se buscar reescreve-los.

23

Informao nono-relacionada algumas informaes podem faltar no

documento de reviso. responsabilidade dos engenheiros executar a
reviso dos documentos para descobrir quaisquer incongruncias dos
documentos, seja dos stakeholders do sistema, seja de outras fontes.

Conflito de requisitos Conflitos devem ser negociados entre

stakeholders e a equipe.

Requisitos
Requisitos no realistas s vezes alguns requisitos requerem uma
tecnologia no disponvel para aquele sistema. Desse modo, os
stakeholders devem ser consultados sobre a modificao ou excluso
de tais requisitos para andamento do sistema.

3.2.1.1 Checklist para Reviso

Reviso
O uso de checklists que caracterizam

e descrevem os erros

frequentemente so usados no processo de inspeo. Essa abordagem

funciona bem tanto na validao quanto na programao.
Essa tcnica revela-se produtiva nas empresas e recomenda-se o
desenvolvimento de um conjunto de perguntas-padro para o contexto em
tela, conforme observamos na Tabela 1 [KOTONYA 1998].

Tabela 1 Atributos de qualidade do requisitos

Atributo de qualidade

Descrio
Os leitores do documento podem compreender o que os requisitos

Compreensibilidade

significam? Esse provavelmente o mais importante atributo do

documento de requisitos se ele no pode ser compreendido, os

24

requisitos no podem ser validados.

H alguma informao desnecessariamente repetida? Algumas
Redundncia

vezes a redundncia melhora a compreenso. Deve haver um

equilbrio em remover toda a redundncia e tornar o documento
de difcil compreenso.

Completude

O revisor tem conhecimento de algum requisito falante ou de

alguma informao falante na descrio dos requisitos?
Os

Ambigidade

requisitos

so

expressos

utilizando

termos

claramente

definidos? Leitores com diferente graus de conhecimento podem

ter diferentes interpretaes dos requisitos?
As descries de diferentes requisitos possuem contradies? H

Consistncia

contradies entre requisitos individuais ou nos requisitos gerais

do sistema?
O documento est estruturado da maneira apropriada? As

Organizao

descries dos requisitos esto agrupadas de forma que requisitos

relacionados esto agrupados? Poderia ser utilizada uma outra
estrutura de mais fcil entendimento?

Conformidade a
padres

O documento e os requisitos individuais esto de acordo com os

padres definidos? Se existem divergncias em relao a padres,
as mesmas possuem justificativa?
Os requisitos so identificados de maneira no-ambgua, incluindo

Rastreabilidade

ligaes com requisitos relacionados e com as razes que

justificam a incluso do requisito?

3.2.2 Prototipao
a simulao das telas de uma aplicao a qual permite ao usurio
visualizar a aplicao que ainda no foi produzida.
Se um prottipo foi desenvolvido para fins de elicitao de requisitos,
faz sentido us-lo posteriormente para a validao desses requisitos. Porm,
prottipos para validao devem ser mais completos e conter requisitos
suficientes para garantir que facilidades projetadas para o sistema estejam
de acordo com o uso prtico esperado por seus usurios. Prottipos de
elicitao normalmente apresentam funcionalidades ausentes e podem no
contemplar mudanas acordadas durante o processo de anlise dos
25

requisitos. , portanto, necessrio dar continuidade ao desenvolvimento do

prottipo durante a etapa de validao [KOTONYA 1998].
usualmente mais fcil para os stakeholders conseguirem identificar
exatamente o que querem de uma forma visual e aproximada do que poder
ser o produto final. Dessa forma, atravs do prottipo visual mais fcil
detectar inconsistncias e problemas nos requisitos.
Melhorias na comunicao entre usurios e desenvolvedores so
frequentemente vistas com a implantao da prototipao.
Devem-se notar pequenas desvantagens na utilizao desta tcnica:

A implementao de um prototipo poder levar a desiluses para os

utilizadores

finais,

quando

as

interfaces

da

verso

final

no

correspondem exatamente s do prottipo.

Tambm se dever ter em conta o tempo gasto na implementao do

prottipo e medir se este tempo no final ser compensado pelas
vantagens trazidas.

Projetistas e usurios podem focar-se demais no projeto da interface e

pouco na produo de um sistema que atenda as necessidades do
processo de negcio.

A Figura 4 apresenta o processo de validao de requisitos por

prototipao [KOTONYA 1998].

26

Figura 4 Validao de Requisitos por Prototipao

As atividades visualizadas na Figura 4 so detalhadas abaixo:

Escolha dos testadores de prototipao a escolha dessa equipe

fundamental, pois dever se relacionar com os usurios finais do
sistema. Os melhores testadores so usurios que no esto bem
familiarizados com o sistema ou que apenas esto abertos a descobrir
um sistema novo.

Desenvolvimento de cenrios de teste a prototipao deve ocorrer de

forma sistemtica. Isso requer planejamento para elaborao de
cenrios. Cobrindo assim todas as possibilidades de situaes partindo
dos requisitos.

Execuo de cenrios os usurios do sistema geralmente trabalham

por conta prpria executando os cenrios planejados. Essa perspectiva
a melhor, pois usando o sistema por conta prpria leva o usurio a
uma situao mais realista.

Problemas de documentao todos os problemas encontrados devem

ser cuidadosamente documentados para analise posterior. O ideal
definir um template padro eletrnico para constantemente atualizar
os erros e sugerir mudanas no sistema.

3.2.3 Testes de Requisitos

Nesta tcnica, cada requisito funcional no documento de requisitos
deve ser analisado e um teste deve ser definido que possa objetivamente
27

averiguar se o sistema satisfaz o requisito. O objetivo dos casos de teste

propostos para requisitos validar o requisito e no o sistema. Para definir
casos de teste para um requisito, devem-se fazer as seguintes perguntas
[KOTONYA 1998]:

Que cenrio deve ser usado para averiguar o requisito? Isso definir o
contexto onde ser aplicado.

O requisito por si s inclui informao suficiente para permitir um

teste ser definido? Se no, que outros requisitos devem ser
examinados para encontrar essa informao?

possvel checar o requisito usando um teste nico ou testes

mltiplos?

O requisito pode ser re-escrito de modo que os testes tornem-se mais

bvios?

Uma tabela de registro de teste deve ser projetada e preenchida com a

informao

necessria,

de

cada

item

testado,

incluindo

seguinte

informao:

Identificador de requisitos um por cada requisito

Requisitos relacionados

Descrio do teste

Problemas de Requisitos

Comentrios e Recomendaes
A Figura 5 apresenta um modelo de formulrio de teste de requisitos.

28

Figura 5 Formulrio de Teste de Requisitos

29

4 Consideraes Finais
Com o decorrer do tempo, as empresas tornam-se mais dependentes
dos seus sistemas de informao. A construo desses sistemas em tempo
hbil, com qualidade e menores custos o desafio que todos os
desenvolvedores tm enfrentado.
Para que as empresas conquistem os nveis competitivos exigidos pelo
mercado, no basta apenas a utilizao de ferramentas isoladas para
melhoria da qualidade e/ou produtividade. necessria a estruturao da
empresa por meio de um sistema gerencial que coordene o uso das tcnicas
e ferramentas disponveis e garanta condies necessrias ao planejamento,
controle e melhorias de cada um dos processos.
Instituies que implementam processos de engenharia de requisitos
obtm grandes benefcios. O maior deles talvez seja a reduo do retrabalho durante os estgios seguintes do processo de desenvolvimento e
durante toda a fase de manuteno do software.
nesse sentido que a atividade de Validao de Requisitos torna-se
mais um meio de garantir documentos de requisitos com qualidade e que
venham a gerar produtos condizentes com as necessidades de seus clientes
e usurios, atravs do uso de tcnicas como as descritas neste trabalho.

30

Referncias Bibliogrficas
[ESPINDOLA 2004] Espindola, R., Majdenbaum, A. e Audy, J., Uma Anlise
Crtica dos Desafios para Engenharia de Requisitos em Manuteno de
Software.
Software. Faculdade de Informtica, PUC-RS, 2004.
[GENVIGIR 2005] Genvigir, E., SantAnna, N., Borrego, L. e Cereja, M., Uma
Requisitos. INPE Instituto
Abordagem para os Processos da Engenharia de Requisitos
Nacional de Pesquisas Espaciais, 2005.

[GOMES 2005] GOMES, M., Um Processo de Avaliao da Portabilidade

Portabilidade de
Unidades de Software. Centro de Informtica, Universidade Federal de
Pernambuco, 2005..
[IBM 2004] IBM Corporation. The Business value of Software Quality A
technical discussion of software quality. 2004.
[LAMSWEERDE 1998] Lamsweerde, A., Darimont, R. e Letier, E., Managing
Conflicts in GoalGoal-Driven Requirements Engineering. IEEE Transactions on
Software Engineering, Special Issue on Managing Inconsistency in Software
Development. Nov. 1998.
[LOUCOPOULOS 1995] Loucopoulos, P. e Kavakli, V., Enterprise Modelling
Engineering, International
and Teleological Approach to Requirements Engineering
Journal of Intelligent and Cooperative Information Systems, 1995.

[KOTONYA 1998] Kotonya, G., Sommerville, I., Requirements Engineering:

Processes and Techniques.
Techniques John Willey & Sons Ltd, 1998.

[PAIM 2003] Paim, F., Uma Metodologia para Definio de Requisitos em

Sistemas Data Warehouse. Dissertao de Mestrado, Centro de Informtica,
UFPE, 2003

31

[NADDEO 2002] Naddeo, P., Uma Taxonomia na rea de Engenharia de

Requisitos.
Requisitos Dissertao de Mestrado, Instituto de Matemtica e Estatstica da
Universidade de So Paulo. So Paulo, SP, 2002.

[NUSEIBEH 2000] Nuseibeh, B. e Easterbrook, S., Requirements Engineering: A

Roadmap.
Roadmap The Future of Software Engineering, Anthony Finkelstein, ACM
Press, 2000

[SANTOS 2007] Santos, M.,

., Estudo Comparativo dos Processos Utilizados na
na
Engenharia de Requisitos. Escola Politcnica, USP, So Paulo, 2007.

[SAYAO 2003] Sayao, M., Staa, A., Leite, J., Qualidade em Requisitos,
Requisitos
Monografia em Cincia da Computao, Departamento de Informtica, PUCRio, 2003.

[SOARES 2005] Soares, A., Introduo, Identificao e Anlise em Engenharia

de Requisitos,
Requisitos 2005.

[SOMMERVILLE 2003] Sommerville, I., Engenharia de Software.

Software 6 Edio,
Makron Books, 2003

[THAYER 1993] Thayer, R., Dorfman, M., Software Requirements Engineering,

Engineering
IEEE Computer Society Press, 1993.

[WIKIPEDIA

2007]

Validao

de

Requisitos.
Requisitos

Disponvel

em:

http://pt.wikipedia.org/wiki/Valida%C3%A7%C3%A3o_de_requisitos , 2007.
32