2.

Engenharia de Requisitos
A engenharia de requisitos tem sido reconhecida como uma das mais importantes
fases do processo de engenharia de software. Este reconhecimento decorre da descoberta
que a maior parte dos problemas e geralmente os mais dispendiosos e de maior impacto
negativo no desenvolvimento de software, so originados nas etapas iniciais do
desenvolvimento. Estas etapas constituem o processo de engenharia de requisitos, no qual,
as principais atividades podem ser definidas como: elicitao, anlise, negociao,
especificao, gerenciamento e validao de requisitos (kotonya et al. 1997). Normalmente,
falhas na realizao destas atividades, resultam em documentos de requisitos inconsistentes,
incompletos e conseqentemente produtos de software de baixa qualidade.
Neste captulo, apresentamos uma descrio dos elementos mais importantes da
engenharia de requisitos, incluindo as reas de interesse para a nossa proposta.
Inicialmente, na seo 2.1 apresentamos uma viso geral da engenharia de requisitos
apontando vrias definies para os termos Engenharia de Requisitos e Requisitos. Na
seo 2.2 fazemos uma breve discusso de como requisitos podem ser classificados. Na
seo 2.3 apresentamos uma viso geral do processo de engenharia de requisitos Na seo
2.4 so descritas as principais atividades desse processo e na seo 2.5 descrevemos as
principais preocupaes e tendncias de pesquisa da comunidade de engenharia de
requisitos.
2.1 A Engenharia de Requisitos Uma Viso Geral
Por se tratar de uma rea de pesquisa relativamente recente na literatura, podemos
encontrar vrias definies da Engenharia de Requisitos. A seguir faremos uma reviso das
principais definies.
A Engenharia de Requisitos a fase do desenvolvimento de sistemas de software
responsvel pela identificao dos objetivos do sistema pretendido, pela operacionalizao
de tais objetivos em servios e restries e pela atribuio da responsabilidade dos
requisitos resultantes para agentes como: humanos, hardware, e software (Lamswerdee
2000).
Uma outra definio dada pelo IEEE (IEEE 1984), segundo a qual a Engenharia
de Requisitos corresponde ao processo de aquisio, refinamento e verificao das
necessidades do cliente para um sistema de software, objetivando-se ter uma especificao
completa e correta dos requisitos de software.
Para o projeto STARTS, segundo Hofman (1993), Engenharia de Requisitos
compreende o processo pelo qual as intenes e requisitos escritos e falados de seu
possuidor so transformados em uma especificao precisa, consistente, no ambgua e
completa do comportamento do sistema, incluindo funes, interfaces, desempenho e
limitaes.
Para Leite (1987), a Engenharia de Requisitos pode ser definida como um processo
segundo diferentes pontos de vista, no qual "o que" para fazer capturado e modelado.
Neste processo utiliza-se uma combinao de mtodos, ferramentas e atores, sendo
produzido, como resultado da modelagem, um documento de requisitos.
Boehm (1989) define Engenharia de Requisitos como uma atividade que objetiva
desenvolver uma especificao completa, consistente, no ambgua e correta dos requisitos,
que sirva, inclusive, de base para um acordo entre as partes envolvidas no processo de
desenvolvimento do software, onde se pactue, de forma concisa, "o que" o produto ir
fazer. Nesse sentido, a Engenharia de Requisitos caracteriza-se como um processo que
requer um envolvimento muito grande entre cliente e desenvolvedores, evitando decises
de projetos durante a definio dos requisitos, ficando, assim, definidas, pelo menos, duas
fases bem distintas: o que se tenta alcanar e como projetar o sistema para satisfazer os
requisitos. Segundo Hofman, essa definio parece separar a Engenharia de Requisitos de
outras preocupaes do desenvolvimento de software (Hofman 1993).
J segundo Davis (1993), a Engenharia de Requisitos corresponde atividade de
entendimento das necessidades do usurio no contexto do problema a ser resolvido, bem
como das limitaes impostas na soluo.
De acordo com Loucopoulos et al. (1995), a Engenharia de Requisitos corresponde
ao processo sistemtico de desenvolvimento de requisitos, atravs de um processo iterativo,
cooperativo de anlise do problema, documentao das observaes resultantes, em uma
variedade de formatos de representaes e checagem da acurcia da compreenso ganha.
Segundo Kotonya et al. (1997), Engenharia de Requisitos trata-se de um termo
relativamente novo, para cobrir todas as atividades envolvidas na descoberta,
documentao e manuteno de um conjunto de requisitos, num sistema baseado em
computador. Nesta definio, o termo Engenharia implica que tcnicas sistemticas e
repetitivas so usadas para assegurar que os requisitos do sistema sejam completos,
consistentes e relevantes.
Para Zave (1997), a Engenharia de Requisitos est relacionada com a identificao
de metas para serem atingidas pelo sistema a ser desenvolvido, assim como a
operacionalizao de tais metas em servios e restries.
Outra definio necessria para o correto entendimento de nosso trabalho a de
requisitos. Vrias definies tm sido usadas para requisitos de software. Elas representam
perspectivas diferentes e graus variados de detalhes e preciso. A IEEE (IEEE 1997) define
requisito como sendo:
1) Uma condio ou uma capacidade de que o usurio necessita, para solucionar
um problema ou alcanar um objetivo.
2) Uma condio ou uma capacidade que deve ser alcanada ou possuda por um
sistema ou componente do sistema, para satisfazer um contrato, um padro, uma
especificao ou outros documentos impostos formalmente.
3) Uma representao documentada de uma condio ou capacidade, conforme os
itens (1) e (2).
A definio da IEEE cobre a viso do usurio sobre requisitos (comportamento
externo do sistema), a viso do desenvolvedor (2) e o conceito fundamental que requisitos
devem ser documentados (3).
Uma outra definio sugere que um requisito uma necessidade do usurio ou uma
caracterstica, funo ou atributo necessrio do sistema que pode ser percebido de uma
posio externa daquele sistema (Davis 1993). Essa definio enfatiza o que o sistema deve
conter.
Segundo Kotonya et al. (1997), um requisito pode descrever:
Uma facilidade no nvel do usurio; por exemplo, um corretor de gramtica e
ortografia.
Uma propriedade muito geral do sistema; por exemplo, o sigilo de informaes no
autorizadas.
Uma restrio especfica no sistema; por exemplo, o tempo de varredura de um
sensor.
Uma restrio no desenvolvimento do sistema; por exemplo: a linguagem que dever
ser utilizada para o desenvolvimento do sistema.
Uma definio bastante simples para requisitos dada por Macaulay (1996).
Segundo este autor, requisito simplesmente algo que o cliente necessita. J segundo
Jackson (1995), requisitos so fenmenos ou propriedades do domnio da aplicao que
devem ser executados, normalmente expressos em linguagem natural, diagrama informal ou
em notao apropriada ao entendimento do cliente e da equipe de desenvolvimento.
2.2 Classificao de Requisitos
Durante o processo de especificao dos requisitos, surge tambm a necessidade de
estabelecer o tipo de requisito de que se est tratando, a fim de melhorar a compreenso das
necessidades do cliente, bem como modelar melhor esta necessidade.
De forma geral, podemos categorizar os requisitos, em trs classes bsicas distintas,
mas que podem estar relacionadas: funcionais, no-funcionais e organizacionais
(Loucopoulos et al. 1995) (Kotonya et al. 1997) (Davis 1993). Alguns autores preferem
classificar os requisitos somente segundo os dois primeiros tipos, funcionais e no-
funcionais.
Os requisitos funcionais dizem respeito definio das funes que um sistema ou
um componente de sistema deve fazer. Eles descrevem as transformaes a serem
realizadas nas entradas de um sistema ou em um de seus componentes, a fim de que se
produzam sadas.
Os requisitos no-funcionais dizem respeito a restries, aspectos de desempenho,
interfaces com o usurio, confiabilidade, segurana, manutenibilidade, portabilidade,
padres, e outras propriedades que o sistema deve possuir, bem como aspectos sociais e
polticos. Alguns desses requisitos so provavelmente traduzidos em funes
(operacionalizados), ao longo do processo de desenvolvimento de software (Chung et al.
2000).
De forma geral, a diferena entre requisitos funcionais e no-funcionais est no fato
dos primeiros descreverem o que o sistema deve fazer, enquanto que os outros fixam
restries sobre como os requisitos funcionais sero implementados.
Os requisitos organizacionais dizem respeito s metas da empresa, suas polticas
estratgicas adotadas, os relacionamentos entre os seus atores junto com seus respectivos
objetivos.
Encontram-se ainda sugestes de que requisitos possam ser vistos como sendo "o
que" o sistema deve fazer, associado com "o porque" deva fazer, em lugar do "como" o
sistema deve fazer. Procura-se ampliar a viso tradicional dos requisitos que trata apenas de
aspectos funcionais e no-funcionais, com informaes organizacionais que abordam a
intencionalidade dos fatos, ou seja, os requisitos organizacionais (Loucopoulos et al. 1995)
(Yu 1995) (Yu 1997) (Yu et al. 1995) (Mylopoulos 1995).
Segundo essa nova viso, a Engenharia de Requisitos pode ser dita como: A rea do
conhecimento preocupada na comunicao com agentes organizacionais, com respeito a
suas vises, intenes e atividades relativas s suas necessidades de suporte de
computadores, desenvolvimento e manuteno de uma especificao de requisitos
adequada a um sistema (Loucopoulos et al. 1995). Isso sugere que a Engenharia de
Requisitos tambm inclua problemas e aspectos gerenciais, organizacionais, econmicos,
tcnicos, sociais e ambientais. Nesse contexto, em Bubenko (1995), salienta-se que a
prpria definio da Engenharia de Requisitos evoluiu ao longo dos anos.
A viso tradicional (Loucopoulos et al. 1995), em geral, esquece aspectos
importantes, que influenciam diretamente no sistema que se deseja especificar, tais como:
Os objetivos do prprio sistema e o relacionamento desses com os objetivos da
organizao.
Outras propriedades dos sistemas, como as relacionadas com o desempenho,
segurana e restries.
Esta viso mais ampla sobre os requisitos, serve para caracterizar que deve ser
levado em considerao, quando da especificao dos requisitos, o fato de que o sistema
que est sendo especificado apenas um dentre os vrios sistemas no ambiente da
organizao.
Os requisitos organizacionais desempenham papel fundamental no projeto e no
desenvolvimento de um sistema. Para Dobson et al. (1994), requisitos organizacionais so
aqueles que resultam do sistema pretendido, considerando-se o contexto social no qual ele
se encontra inserido. Por exemplo, obrigaes e responsabilidades, controle e autonomia,
valores e ticas que so normalmente, embutidos na estrutura e na poltica da empresa, de
forma que no so diretamente observados ou facilmente articulados.
A razo principal para se considerar os requisitos organizacionais, est na ajuda
compreenso de interaes complexas entre as empresas (organizaes) e as pessoas
envolvidas. Assim, esta ajuda torna-se essencial, por oferecer meios:
Para a descrio dos processos da organizao.
Para a definio e estruturao da informao de suporte a estas aplicaes.
Embora as muitas classificaes propostas tenham muitos pontos em comum,
elas diferem de acordo com o ponto de vista dos autores, visto que uma dada
classificao pode enfatizar mais um aspecto do que outro. Todavia, a tendncia
atual aponta para a necessidade de tratar, especificamente, dos requisitos
organizacionais (Dardene et al. 1993) (Yu 1995) (Mylopulos 1995) (Mylopulos et
al. 2000) (Castro et al. 2001). At pouco tempo, os projetistas e desenvolvedores
ignoravam a importncia dos aspectos organizacionais para o desenvolvimento de
seus produtos. S mais recentemente que esses aspectos comearam a serem
observados e foram considerados essenciais ao sucesso das implementaes. Hoje,
existem modelos, que representam componentes intencionais, tais como, razes,
motivaes e os porqus.
2.3 O Processo de Engenharia de Requisitos
consensual que de uma completa e consistente especificao de requisitos
depende a qualidade do produto de software bem como uma maior satisfao do cliente. Se
os requisitos so especificados de forma incompleta ou inconsistente, os artefatos
resultantes das prximas etapas do processo de software (Projeto, Implementao e Testes)
no tero a qualidade desejada. Quanto mais tarde problemas com requisitos forem
detectados no processo de desenvolvimento, maior ser o custo para corrig-los.
Para entender melhor o processo de engenharia de requisitos, vejamos a figura 2,
extrada de Kotonya et al. (1997).
Verificamos que as entradas para o processo de engenharia de requisitos incluem:
informaes sobre sistemas j existentes; necessidades dos stakeholders; padres da
organizao; regulamentaes; e informaes do domnio da aplicao. Todas estas
informaes so utilizadas para a realizao das atividades do processo. Como resultado
(sada) obtemos os requisitos acordados, uma especificao de requisitos e modelos do
sistema. Esta viso macro ressalta que para a realizao das atividades do processo de
engenharia de requisitos, fatores humanos e tcnicos tm de ser adequadamente tratados,
objetivando desta forma, que cada resultado do processo, seja o mais completo e
consistente possvel.






Figura 2. Entradas e Sadas do Processo de Engenharia de Requisitos, segundo
Kotonya et al. (1997).
O processo de engenharia de requisitos composto basicamente pelas seguintes
atividades:
elicitao de requisitos;
anlise e negociao de requisitos;
documentao de requisitos;
validao de requisitos;
gerenciamento de Requisitos.
Estas atividades, no seguem rigorosamente uma certa seqncia de realizao no
processo de engenharia de requisitos. Tipicamente inicia-se com a elicitao de requisitos,
juntamente com uma anlise dos requisitos seguida de negociaes. Estas negociaes so
s vezes necessrias tendo em vista vrios pontos de vista de usurios, os quais podem
diferir em relao importncia, necessidade e/ou prioridade dos requisitos sendo
definidos. Posteriormente, os requisitos ento so documentados e validados. Paralelamente
Requisitos
Acordados
Especificao
do Sistema
Modelos do
Sistema
Necessidades de
Stakeholders
Sistemas de
Informao
Existentes
Regulamenta
es
Padres
Organizacionais
Domnio da
Informao
Processo de
Engenharia de
Requisitos
a todas estas atividades realizado o gerenciamento de requisitos, no qual objetiva-se
controlar a evoluo e mudanas nos requisitos bem como possibilitar o rastreamento
1
dos
mesmos ao longo de todo o processo de desenvolvimento.
De forma geral, o que na prtica ocorre uma intensa interao entre as atividades
no sendo necessrio concluir totalmente uma atividade para iniciar a outra.
Os problemas maiores surgem na execuo destas atividades. Diversos fatores
dificultam o desenvolvimento de documentos de requisitos que realmente satisfaam os
usurios. Alguns problemas com requisitos encontrados durante o processo de engenharia
de requisitos so relatados em Kotonya et al. (1997):
Os requisitos no refletem as reais necessidades do cliente em relao ao
sistema a ser desenvolvido;
Os requisitos so inconsistentes e/ou incompletos;
dispendioso fazer mudanas aps os requisitos terem sido acordados entre as
partes (cliente e equipe de desenvolvimento);
comum ocorrer interpretao errnea entre clientes e equipe de
desenvolvimento.
Desta forma, para atender adequadamente aos requisitos dos usurios e clientes,
necessrio que as atividades do processo de engenharia de requisitos, sejam realizadas de
forma mais sistemtica possvel e com um suporte computacional adequado. Isto leva a
processos com maior maturidade, o que permite que uma organizao obtenha softwares

1
Define-se por rastreamento em engenharia de requisitos (Toranzo 2002), a possibilidade de rastrear para
frente e para trs os requisitos de um sistema. Exemplificando: para trs, rastreando um requisito para a
fonte (quem o solicitou) ou para frente, rastreando um requisito para os artefatos da fase de projeto ou
implementao, por exemplo
com qualidade, no por dependncia de esforos individuais, mas por uma prpria evoluo
do seu processo, o qual utiliza boas prticas de Engenharia de Requisitos.
2.4 Atividades da Engenharia de Requisitos
Nesta seo, descrevemos as atividades do processo de engenharia de requisitos
separadamente, apontando tcnicas bem como dificuldades encontradas para a realizao
das mesmas. Vrios relatos na literatura tm apontado algumas diferenas de nomenclatura
ou seqncia de realizao destas atividades. No entanto, consideramos que de uma forma
geral, as definies apresentadas em Kotonya et al. (1997), fornecem-nos uma viso
adequada destas atividades.
2.4.1 Elicitao, Anlise e Negociao de Requisitos
Quando desejamos solucionar um problema atravs de um sistema computacional, o
primeiro passo deve ser o de descobrir quais so os requisitos desejveis em relao a esse
sistema. Neste processo de descoberta, o elemento essencial e mais importante o
cliente/usurio que requisita e/ou utilizar o sistema. As maiores dificuldades que surgem
no so computacionais, mas de comunicao, pois o objetivo extrair do usurio o que ele
espera do sistema a ser desenvolvido. Recai no engenheiro de requisitos a tarefa de
discernir o que relevante entre as informaes dadas pelo usurio, bem como lidar
adequadamente com as declaraes vagas do usurio a respeito do que o mesmo espera de
sistemas computacionais.
Assim, a tarefa de elicitar os requisitos no trivial. Tambm necessrio analisar
os requisitos em relao a inconsistncias e incompletudes, bem como negociar,
solucionando conflitos, de forma que um conjunto de requisitos sejam acordados. Estas
atividades so realizadas, na maioria das vezes, paralelamente e/ou de forma intercalada. O
objetivo delimitar um conjunto de requisitos que atendam os desejos dos usurios.
Entre as vrias tcnicas para elicitar requisitos podemos apontar: entrevistas;
cenrios (Hadad et al. 1999) (Haumer et al. 1998) (Leite et al. 1997) (Breitman et al. 1998);
observao e anlise social (Goguen et al. 1993); etnografia (Sommerville et al. 1999);
entre outras. Toda tcnica de elicitao deve descrever os requisitos atravs de uma
representao facilmente entendida por todos os Stakeholders. Este um aspecto essencial,
pois o cliente/usurio deve compreender e concordar com os requisitos que esto sendo
definidos.
Aps a atividade de elicitao ou mais comumente, de forma intercalada, os
requisitos devem ser analisados para detectar incompletudes, omisses ou redundncias. Na
anlise, a preocupao est em descobrir os requisitos que realmente so necessrios e que
o stakeholder deseja. Vrias tcnicas podem ser utilizadas para este fim. Entre elas
destacam-se:
1. Lista de Checagem da Anlise: uma lista de questes, as quais o analista pode
usar para avaliar cada requisito. Cada item serve de guia na avaliao do
requisito. No final da checagem, pode obter-se uma lista de problemas
associados com requisitos. Estes problemas podem ser solucionados atravs de
negociao ou se necessrio com nova elicitao.
2. Matrizes de Interao: utilizada para descobrir as interaes entre requisitos,
apontando possveis conflitos entre requisitos. A atividade de negociao pode
corrigir estes conflitos.
3. Prototipao: os prottipos desenvolvidos na etapa de elicitao de requisitos
podem ser aperfeioados na etapa de anlise, possibilitando uma anlise mais
completa dos requisitos. Prottipos facilitam o envolvimento dos diferentes
stakeholders na elicitao, anlise e negociao de requisitos.
Aps a anlise de requisitos, sendo descobertos conflitos ou problemas, ocorre o
processo de negociao de requisitos. Esta atividade visa solucionar problemas advindos do
conflito entre os diversos stakeholders, os quais podem atribuir diferentes prioridades aos
requisitos. A negociao consiste em que todos os stakeholders entrem em consenso em
relao a um conjunto de requisitos definidos bem como em relao s prioridades
definidas para os mesmos. Este trabalho bastante complexo, pois incide diretamente em
interesses pessoais e obedece na maioria das vezes a hierarquias entre os diversos usurios
e/ou clientes. No necessariamente as pessoas que esto no controle da organizao, so as
mais adequadas para definirem prioridades bem como estabelecerem os requisitos do
sistema. O trabalho do engenheiro de requisitos recai neste tipo de dificuldade. Toda e
qualquer fonte de informao de requisitos deve ser adequadamente verificada. Os diversos
pontos de vista devem ser ponderados para que o documento de requisitos acordados atenda
s reais necessidades dos clientes/usurios.
Os processos de elicitao, anlise e negociao ocorrem de forma intercalada. Para
se chegar a um documento de requisitos que satisfaa aos diversos usurios do sistema,
normalmente cada uma das atividades deve ser realizada vrias vezes. A meta estabelecer
um consenso sobre os requisitos que esto sendo definidos.
As tcnicas existentes na literatura para estas atividades exigem dos engenheiros de
requisitos uma formao no somente computacional, mas principalmente humanstica,
voltada para aspectos de comunicao e necessidades de usurios.
importante salientar que para uma melhor realizao destas atividades iniciais no
processo de engenharia de requisitos, so necessrias ferramentas que suportem estas
atividades. O grande nmero de requisitos existentes aponta para a necessidade de
utilizao de ferramentas CASE, as quais permitem controlar e facilitar o trabalho de
engenheiros de requisitos (Kotonya et al. 1997).
2.4.2 Validao de Requisitos
Na elicitao, anlise e negociao de requisitos, a preocupao principal residia em
que os requisitos certos fossem elicitados e acordados entre clientes e desenvolvedores. Na
atividade de validao de requisitos a preocupao que os requisitos estejam definidos de
forma correta. Nesta atividade concentramo-nos na checagem do documento de requisitos
em relao sua completude, consistncia e acurcia.
A atividade de validao de requisitos a ltima atividade para certificar-se que o
documento final de requisitos satisfaz em todos os aspectos o que o usurio deseja do
sistema. Vrias tcnicas podem ser aplicadas com este fim:
revises dos requisitos: esta uma das alternativas mais populares para validar
requisitos. Consiste na reviso dos requisitos por um grupo de pessoas que analisam,
discutem e apontam caminhos para solucionar os problemas encontrados. A partir
dessas descobertas, pode-se adotar medidas que solucionem os conflitos. Problemas
tpicos encontrados nas revises incluem: incompletude das descries dos requisitos;
ambigidade; bem como no obedincia a padres da organizao.
prototipao: prottipos so desenvolvidos com o intuito de permitir uma melhor
representao dos requisitos de um sistema. Enquanto tradicionalmente, o usurio tem
de esperar at etapas no final do processo de desenvolvimento, para visualizar uma
verso executvel do sistema, com o desenvolvimento de prottipos, usurios podem ter
uma idia antecipada de como o sistema executvel funcionar. observado que a
tcnica de prototipao geralmente usada para ajudar nas atividades de elicitao e
anlise de requisitos. Contudo, ela tambm pode ser usada para validar os requisitos.
Aps o documento de requisitos j ter sido definido e acordado, pode-se aperfeioar o
prottipo desenvolvido na elicitao e anlise e utiliz-lo para validar os requisitos, com
um auxlio mais efetivo dos usurios/clientes.
testes de requisitos: comumente, testes de software so realizados no final do processo
de desenvolvimento de software. No entanto, recomenda-se desenvolver casos de teste
para os requisitos, j no processo de engenharia de requisitos. Por exemplo, tcnicas
baseadas em cenrios podem ser usadas para elicitar e analisar requisitos e criar casos
de teste para os cenrios desenvolvidos. Casos de teste podem ser aplicados de forma
simulada nos cenrios desenvolvidos. Se surgirem dificuldades para criar os casos de
teste bem como para execut-los atravs de simulao, h uma grande probabilidade de
existirem problemas com os requisitos. menos oneroso e traumtico descobrir estes
problemas na atividade de validao do processo de engenharia de requisitos ao invs
de em etapas finais do processo de desenvolvimento de software.
validao de modelos: geralmente, quando documentamos requisitos, os mesmos so
descritos atravs de linguagem natural e diagramas. Tipicamente, cria-se um documento
em linguagem natural descrevendo os requisitos do sistema. Para detalhar melhor o
funcionamento do sistema so desenvolvidos modelos do sistema. O desenvolvimento
destes modelos est associado abordagem de desenvolvimento de software adotada.
Normalmente so desenvolvidos modelos de fluxo de dados, modelos de dados
semnticos ou modelos inerentes ao paradigma de desenvolvimento, por exemplo,
orientao a objetos, mtodos formais, etc. Estes modelos necessitam ser validados para
demonstrar que os mesmos so consistentes tanto internamente como externamente.
Outrossim, eles devem representar os reais requisitos dos usurios. Na prxima seo, a
atividade de documentao de requisitos ser melhor descrita.
2.4.3 Documentao e Modelagem de Requisitos
Esta atividade est relacionada a uma descrio detalhada dos requisitos do
software, a qual deve ser facilmente entendida por todos os envolvidos. O processo de
engenharia de requisitos geralmente guiado por um mtodo adotado para a realizao das
atividades. Estes mtodos possuem uma abordagem sistemtica para produzir modelos do
sistema. Quando modela-se requisitos, produz-se modelos, os quais podem pertencer a
abordagens tais como: modelagem de fluxo de dados, abordagens orientadas a objetos e
mtodos formais.
A atividade de documentao de requisitos intercalada em muitos momentos com
as atividades de elicitao, anlise e negociao de requisitos. O resultado da documentao
de requisitos inclui os requisitos acordados representados atravs de um documento em
linguagem natural bem como uma especificao dos requisitos do sistema. Esta
especificao em geral consiste de diagramas e modelos pertencentes metodologia
adotada no desenvolvimento. Cada metodologia possui modelos utilizados para documentar
diferentes aspectos dos requisitos.
A seguir apresentamos uma breve descrio dos mtodos que podem ser utilizados
para documentar/ especificar os requisitos de um sistema:
modelagem de fluxo de dados: esta uma das abordagens mais conhecidas na
literatura. A abordagem estruturada de desenvolvimento de software foi uma das
primeiras abordagens que surgiram com o objetivo de sistematizar a
especificao de requisitos bem como as demais fases do processo de software.
O diagrama mais utilizado nesta abordagem DFD (Diagrama de Fluxo de
Dados) o qual objetiva modelar o fluxo de informaes que um sistema conter.
composto por entidades, fluxos de informaes, depsitos de dados e
processos. Tom DeMarco foi um dos primeiros autores a propor uma notao
grfica para DFDs (DeMarco 1979). O processo de desenvolvimento de DFDs
consiste em inicialmente desenvolver um diagrama de contexto, no qual uma
descrio macro do sistema seja obtida e ento evoluir a partir desse diagrama,
detalhando o fluxo de informaes bem como os processos envolvidos para
transformar informaes. A idia bsica chegar em um nvel de detalhes, no
qual requisitos do sistema possam ser acordados e bem compreendidos. No final
de um DFD, deve ser possvel evoluir para etapas posteriores do processo de
software com todos os requisitos j definidos, ou grande parte deles. s vezes
um dicionrio de dados tambm acompanha estes DFDs, visando descrever em
mais detalhes elementos que compe cada Diagrama de Fluxo de Dados. A
figura 3, mostra uma das notaes utilizadas em um DFD.




Figura 3. Notaes utilizadas em um DFD.

abordagens orientadas a objetos: Uma das abordagens que mais tem crescido,
tanto na rea acadmica quanto na industrial, a abordagem de
desenvolvimento de software orientado a objetos. No incio da dcada de 90,
diversos mtodos propuseram o desenvolvimento atravs desta abordagem, entre
Depsito de
Entidad
e
Entrad Sada
Transformao
eles a OMT (Rumbaugh et al. 1994), Booch (Booch 1992) e Fusion (Coleman et
al. 1994). Basicamente documentar requisitos atravs desta abordagem, implica
em descobrir os objetos/classes do sistema bem como seus relacionamentos.
Normalmente, um Diagrama de Classes ou Objetos criado contendo estes
elementos. Cada classe pode conter atributos e operaes e os relacionamentos
podem incluir mecanismos de herana, composio e outros. Este tipo de
estrutura representa um modelo conceitual esttico dos requisitos do sistema.
Dependendo do mtodo orientado a objetos utilizado, diferentes modelos e
diagramas so utilizados para documentar artefatos originados em outras etapas
do processo de desenvolvimento tais como projeto e implementao.
Para tornar as notaes orientadas a objetos mais padronizadas e possibilitar
uma unificao das notaes dos vrios mtodos existentes, foi definida pelo
Grupo de Gerenciamento de Objetos (OMG) uma linguagem de modelagem de
objetos denominada de UML (Booch et al. 1999). Esta linguagem surgiu da
unificao dos mtodos dos autores Ivar Jacobson, Grady Booch e James
Rumbaugh. A Linguagem de Modelagem Unificada UML apresenta uma
srie de notaes para o desenvolvimento orientado a objetos. Atualmente, h
uma tendncia em que a documentao/modelagem dos requisitos atravs da
abordagem orientada a objetos, na sua maioria utilize a linguagem UML.
tcnicas formais: as abordagens tradicionais de modelagem de requisitos
fundamentam-se em diagramas bem como em descries textuais, as quais
documentam os requisitos. Outra abordagem para documentar requisitos de
forma precisa descrever as funes e o comportamento do sistema utilizando-
se de uma sintaxe e semntica formal matemtica (Clarke et al. 1996). Vrias
linguagens utilizando estes princpios so utilizadas para especificar sistemas de
software, entre as quais podemos citar Z (Spivey 1989) e VDM (Jones 1990). O
objetivo especificar/documentar os requisitos de forma que o rigor matemtico
propicie diminuir as ambigidades e incompletudes de um documento de
requisitos de usurio.
Atravs de uma linguagem de especificao formal, os requisitos so
documentados utilizando uma sintaxe, semntica e mecanismo de relaes que
permitem um maior grau de preciso dos requisitos e conseqentemente do
sistema que ser desenvolvido.
2.4.4 Gerenciamento de Requisitos
Esta atividade uma das mais importantes do processo de engenharia de requisitos.
Tem como meta principal o controle e gerenciamento de mudanas nos requisitos (Toranzo
2002).
Um dos maiores problemas atuais no desenvolvimento de software reside no fato de
que os requisitos de software so modificados, seja por questes de melhoria das funes
do sistema, por solicitaes do usurio ou devido a correes de erros encontrados. Nestes
casos, mudanas podem gerar efeitos colaterais bem como propagar-se negativamente para
outras partes do software. O controle dos requisitos descobertos e analisados no processo
de engenharia de requisitos fundamental para que as mudanas sejam adequadamente
tratadas e seus impactos corretamente avaliados. Isto implica necessariamente em poder
rastrear os requisitos ao longo de todos os artefatos produzidos no processo de engenharia
de software. Este rastreamento de requisitos deve ocorrer em ambos os sentidos, dos
requisitos iniciais para os artefatos desenvolvidos bem como dos artefatos para as fontes
que originaram os requisitos.
Gerenciar requisitos significa poder escrever e acompanhar um requisito ao longo
de todo o processo de desenvolvimento, enquanto existir. Isto garante documentos de
requisitos mais confiveis e gerenciveis, aspectos importantes para a obteno de produtos
de software de qualidade.
De forma resumida podemos descrever os objetivos do gerenciamento de requisitos
como:
gerenciar mudanas para os requisitos acordados;
gerenciar o relacionamento entre requisitos;
gerenciar as dependncias entre o documento de requisitos e os demais documentos
produzidos no processo de engenharia de requisitos.

No processo de gerenciamento de requisitos fundamental que cada requisito
possua algum tipo de identificao nica (Kotonya et al. 1997). Esta identificao o meio
adotado para poder rastrear bem como avaliar os impactos advindos de mudanas. Para
grandes sistemas, nos quais o nmero de requisitos a serem gerenciados muito grande,
necessrio que os mesmos sejam armazenados em uma base de dados e sejam registradas as
ligaes entre os requisitos relacionados. Atualmente, verifica-se que na grande maioria dos
sistemas, faz-se necessrio o uso de ferramentas CASE que apiem o processo de
gerenciamento de requisitos. Grandes quantidades de requisitos no so gerenciveis sem a
utilizao de alguma ferramenta computacional de apoio. Como exemplo de ferramentas
existentes atualmente no mercado usadas com este fim podemos citar Requisite Pro
(Rational 1999), Doors (Quality 1999), QSSRequireit (http://www.qssrequireit.com) e
Caliber-RM (www.tbi.com).
bastante aceito tambm que as ferramentas CASE para gerenciar requisitos devem
evoluir e as mesmas devem ser integradas com outras ferramentas de apoio s demais
etapas do processo de engenharia de software. O aspecto mais relevante que documentos
produzidos/mantidos por uma ferramenta de gerenciamento de requisitos, devem estar
relacionados de alguma forma, com outros artefatos do processo de software. Este ainda
um desafio nesta rea.
importante salientar que a gerncia de requisitos uma atividade considerada
essencial na engenharia de software como um todo. Mostra disto a incluso desta
atividade nos principais mecanismos de avaliao de qualidade de produtos e processos de
softwares tais como CMM (Humphrey 1989), ISO (ISO/IEC 1991) (NBR ISO/IEC 1995) e
SPICE (ISO/IEC 1999). No entanto, estes padres de qualidade ainda no definem em sua
plenitude todas as caractersticas essenciais que devem ser consideradas quando
gerenciamos requisitos. Por outro lado, h uma dificuldade muito em grande em estabelecer
polticas de gerenciamento de requisitos. Isto conseqncia da grande quantidade de
informaes tratadas bem como da prpria complexidade associada execuo das
atividades de gerenciamento de requisitos.
2.5 Preocupaes atuais na engenharia de requisitos
Nos ltimos anos, tem ficado evidente a necessidade de aprofundar de forma mais
sistemtica os estudos relacionados com as atividades de engenharia de requisitos. Um dos
principais motivos o aumento crescente dos custos advindos da correo de problemas
associados com requisitos inadequadamente elicitados, analisados e especificados. O que se
v so usurios insatisfeitos com softwares que no se adequam s suas reais necessidades
(Kozlenkov et al. 2002).
Aspectos relacionados ao ambiente organizacional no qual o software est inserido,
so comumente desconsiderados ou avaliados de forma incompleta. extremamente
importante estabelecer uma correspondncia entre o ambiente organizacional e o sistema de
software sendo desenvolvido para executar neste ambiente. Isto implica em avaliar
objetivos e metas organizacionais e apontar de que forma sistemas de software podem
satisfazer estes objetivos. Fazer esta ligao no um processo trivial, pois envolve lidar
com diferentes stakeholders tais como usurios, clientes e engenheiros de requisitos, os
quais podem possuir diferentes nveis de formao e interesses.
Podemos tambm verificar que a maioria dos mtodos e processos de
desenvolvimento de software (DSouza 1998) (Jacobson et al. 1999) (Kruchten 2000)
existentes no tratam de forma satisfatria estas questes. Em alguns casos, so fornecidas
tcnicas para modelar aspectos organizacionais e de negcio, mas no se estabelece uma
clara conexo entre estes elementos e a especificao dos requisitos do sistema. Pesquisas
nesta rea so importantes e tm sido incentivadas pela comunidade de engenharia de
requisitos.
Outro ponto relevante diz respeito ao aprimoramento e desenvolvimento de recursos
tcnicos e humanos mais apropriados na elicitao, documentao e validao de
requisitos. Isto implica no somente em tcnicas mais efetivas aplicadas em atividades no
processo de engenharia de requisitos (Goguen et al. 1993) (Kotonya et al. 1997)
(Sommerville et al. 1997), mas tambm em uma melhor formao sociolgica e
multidisciplinar dos profissionais envolvidos. Umas das grandes dificuldades ainda reside
no fato de que engenheiros de requisitos tm dificuldade em elicitar requisitos de clientes e
usurios. Isto ocorre por questes sociais e organizacionais, as quais devem ser
adequadamente tratadas para possibilitar o desenvolvimento de sistemas que satisfaam
realmente as metas organizacionais relevantes para a organizao.
Neste aspecto, algumas pesquisas tm apontado tcnicas como a etnografia
(Sommerville et al. 1993) (Sommerville et al. 1999) (Hughes et al. 1995) para auxiliar
engenheiros de requisitos. Este tipo de tcnica tem como base a observao, descrio e
anlise detalhada das prticas de trabalho em uma organizao. Objetiva-se propiciar a
engenheiros de requisitos entender e documentar a linguagem dos usurios do sistema e sua
relao com as tarefas do trabalho das pessoas. Assim, familiarizado com o ambiente e
linguagem dos usurios, o engenheiro de requisitos pode desenvolver documentos de
requisitos com menos ambigidades, incompreenses e incompletudes. Tcnicas com esse
fim vm sendo pesquisadas, mas aponta-se como uma das principais dificuldades para a sua
utilizao, o tempo consumido para aplicao das mesmas. Normalmente, engenheiros de
requisitos possuem prazos de entrega como elemento de presso e limitante na realizao
do seu trabalho.
Existe tambm atualmente uma preocupao em relao ao nvel de preciso adequado que
deve ser utilizado em atividades na engenharia de requisitos. Quando requisitos so
elicitados, documentados e validados, podemos optar pelo uso de tcnicas com maior ou
menor preciso ou podemos at mesmo utilizar mtodos formais, os quais possuem sintaxe
e semntica precisos e passveis de validao. Por outro lado, tcnicas tradicionais so mais
informais e os artefatos produzidos por estas tcnicas so difceis de serem verificados e
validados com completa segurana e exatido. Estabelecer o nvel certo de formalidade no
desenvolvimento de para cada tipo de software bem como possibilitar uma integrao e/ou
utilizao conjunta de mtodos formais e no formais uma aspecto bastante crtico.