1.

Introduo
A engenharia de requisitos no tem recebido a devida ateno e por causa disto tem sido vista com maus olhos pois os documentos produzidos atravs dela por analistas inexperientes tem causado problemas aos mesmos e aos seus contratantes, falta a viso mais metdica e de consenso geral na descrio de requisitos algo que no seja nem to tcnico, a partir do analista, nem to ai eu no sei bem o que eu queria, a partir do contratante. Ela est situada em uma regio onde h grande desentendimento e confuso, est situada entre o analista e o contratante, sendo usada como arma e como escudo ao mesmo tempo, e sendo menosprezada como uma coisinha que se faz no inicio da anlise, apenas um texto descritivo e outras uma lista ou tabela a qual se deve cumprir no tempo determinado.

2.Estado da arte
No h um mtodo em vigncia para descrio de requisitos, o usado mais comumente e por costume a descrio textual o que tem causado grandes empecilhos a todas as partes relacionadas no processo, so gerados documentos imprecisos (requisitos, ao contrrio do que imaginam muitas pessoas ligadas ao processo de desenvolvimento, so difceis de serem expressos pelo usurio) quanto s obrigaes do sistema e tambm quanto s no obrigaes, deixando margem s dvidas. Outro problema encontrado que a engenharia de requisitos tem sido vista como um processo muito pessoal e feito aos moldes de cada analista diminuindo e muito o reuso do documento produzido por outros analistas na resoluo de problemas semelhantes e s vezes at o mesmo problema. Problemas referentes engenharia de requisitos funcionais tm sido resolvidos atravs de modelos como o diagrama de sequncia, diagrama de classes e diagrama de estados, dentre outros de acordo com a cultura de cada empresa/consultor que faz a anlise. Este mtodo tem resolvido a questo para os contratados, mas produz um documento muito tcnico e de difcil entendimento para o contratante e muitas vezes no reflete as reais necessidades que o sistema deve suprir, na viso (limitada, obviamente, do ponto de vista da implementao) do usurio. Os requisitos no-funcionais, por serem geralmente atrelados qualidade, no so fceis de expressar por modelos, pois a qualidade no expressa por abstraes de coisa concretas ou coisas por entidades pertencentes ao domnio do problema, entidades que tem vida determinada comeam e terminam dentro do seu escopo.

Figura 01 Classificao dos Requisitos

topo

3.O que engenharia de requisitos?

a engenharia (Arte de aplicar os conhecimentos cientficos inveno, aperfeioamento ou utilizao da tcnica industrial em todas as suas determinaes Dicionrio Michaelis) aplicada a obteno metdica de requisitos (Requisitos: Condio necessria para a obteno de certo objetivo, ou para o preenchimento de certo objetivo. - Leite 94) do sistema, sejam estes Funcionais ou No-Funcionais, tratando-os de maneira sistemtica e padronizada com o fim de se ter um reaproveitamento da anlise de requisitos feita, para qualquer outro projeto semelhante ou mesmo para manuteno do mesmo.
topo

3.1.Requisitos Funcionais:
Esto intimamente ligados s funcionalidades propostas pelo sistema, e que sero usadas na resoluo do problema do contratante, e atender todas as suas necessidades funcionais. Resumidamente, so os requisitos que objetivamente cumprem as reais necessidades do usurio do sistema. Exemplo: Controle financeiro, controle de trfego areo, controle de produo.
topo

3.2.Requisitos No-Funcionais:

Geralmente ligados qualidade do produto como, por exemplo, robustez, segurana ou integridade. Dividem-se, assim como a qualidade de produtos, em dois sub-ramos: Dependncia positiva:

Quando da presena de um o outro mais facilmente incorporado.

Figura 02 Dependncia positiva

Dependncia negativa: So conflitantes entre si, a presena ou existncia de um compromete o outro ou diminui seu grau de atuao.

Figura 03 Dependente negativa. Requisitos no-funcionais podem ser classificados como: Orientados ao consumidor: Observveis pelos clientes, no necessariamente os contratantes, mas os usurios dos software. Por exemplo: eficincia, amigabilidade, ergonomia. Atributos orientados tecnicamente: Ligados diretamente ao sistema e que garantem a sua qualidade como tratamento de erros ou anomalias (robustez), processamento em tempo real. Duas abordagens podem ser utilizadas na engenharia de requisitos: Orientada ao produto: Uma abordagem onde o produto a ser produzido focalizado como principal fonte de elicitao de requisitos no funcionais. Naturalmente a de mais assimilao pelo contratante, j que feita de acordo com ponto de fcil mensurao por algum que no tenha experincia tcnica.

Exemplo: Deve ser veloz (eficiente), seguro contra erros do usurio (robusto), etc. Orientada ao processo Abordagem tcnica que prioriza o processo de desenvolvimento e no somente o produto, usa a premissa que atravs de um processo bem estruturado e de qualidade comprovada, o produto final incorpora as qualidades propostas pelo processo de desenvolvimento. Exemplo: O sistema deve ser feito em Java, deve ser orientado a objetos e deve usar como base de dados MySQL.
topo

4. Para que serve engenharia de requisitos?

Todas as etapas que formam a base de desenvolvimento de software maduro tm sua importncia dentro do contexto geral, sempre com o objetivo principal de auxiliar, dentro de suas especificaes, o andamento desse desenvolvimento. Com a engenharia de requisitos ocorre da mesma forma. Ela possui uma tarefa inicial muito importante nesse processo, pois havendo procedimentos bem definidos que ajudem na tarefa de elicitar os requisitos de um sistema a ser desenvolvido, isso se torna mais fcil e um pouco menos dependente do talento das pessoas e de suas experincias nesse tipo de atividade, evitando boa parte do re-trabalho e de inconsistncias desses requisitos. Define um documento de requisitos funcionais e requisitos no funcionais onde se deve ter a viso de todos os requisitos do problema a ser resolvido ou de sua face inicial de acordo com o modelo de ciclo de vida usado na anlise. Tambm tem a funo de diminuir custos de desenvolvimento atravs de um processo de amadurecimento de idias a medida que novos requisitos so expostos, isso se deve a premissa de que quanto mais cedo que identificar a mudana menos esforo ela resultar. Isso feito atravs, principalmente da conscientizao de que os requisitos so mutveis e atravs da escolha de um modelo de ciclo de vida adequado. Pode fazer o acompanhamento da resoluo dos requisitos e da mudana dos mesmos, dando suporte a avaliao de custos e riscos na mudana dos requisitos ao longo da anlise ou projeto com a finalidade de avaliar a viabilidade da mudana dos mesmos no atual instante de desenvolvimento.
topo

5. Quem se beneficia com a engenharia de requisitos?

Contratantes, quem solicita o servio de anlise do problema, por terem um documento que assegure a resoluo dos problemas referentes aos requisitos funcionais propostos e

terem tambm a garantia da qualidade atravs de requisitos no funcionais expressados no mesmo documento. Contratado, que fornece o servio de anlise de problemas, com o documento produzido atravs da engenharia de software este ter uma viso mais precisa e clara dos verdadeiros requisitos funcionais necessrios, no perdendo tempo e sendo mais objetivo, e tambm pode focalizar a qualidade do produto de acordo com os requisitos no-funcionais escolhidos. Futuros contratados e contratantes, que podem se beneficiar do reuso da engenharia de requisitos atravs de documentos bem elaborados feitos anteriormente para resoluo de problemas semelhantes, diminuindo assim o tempo de desenvolvimento e por consequncia o custo para o contratante, contextualizando o contratado com o problema a ser resolvido e com as peculiaridades do mesmo em relao a conhecimentos especficos do domnio do problema na rea proposta. Em suma, a engenharia de requisitos traz benefcios a ambas as partes, tanto com diminuio de custos para os contratantes, como em uma melhor contextualizao e um maior controle sobre os requisitos para o contratado, e tambm prope o reuso dos documentos produzidos, ou seja, incita o reuso do conhecimento adquirido atravs a iterao entre as partes ao longo do processo de engenharia de requisitos.
topo

6. Concluso
importante perceber que a engenharia de requisitos depende muito da interao entre contratantes e contratados, de modo que seja minimizado qualquer problema na definio de requisitos por parte do cliente. Por mais que no se deseje, os requisitos estaro sempre mudando durante o desenvolvimento de um sistema, e quo melhor for o processo de engenharia de requisitos desenvolvido por todos na empresa, menores sero os problemas encontrados em funo de toda a dificuldade que envolve esta importante parte da anlise. Tambm notvel que o cenrio atual na engenharia de requisitos esta muito longe ideal tanto para os contratantes como para os contratados, isto se deve a falta padronizao principalmente na engenharia de requisitos no funcionais, e a falta uma real conscientizao da importncia da engenharia de requisitos no contexto engenharia de software. do de de da

Tambm h uma carncia conceitual em relao aos profissionais da rea de engenharia de software relacionada a falta ou pouco entendimento do domnio do problema do problema a se analisado e documentado, sendo este causado pela transdisciplinalidade da aplicao de engenharia de software na resoluo de problemas.

7. Referncias
Tese sobre Requisitos No-Funcionais http://www-di.inf.puc-rio.br/~julio/Tese%20-%205.pdf Representing and Using Non-Functional Requirements http://www-di.inf.puc-rio.br/~karin/pos/nonfunctional.pdf Gerenciamento de Requisitos http://www.ietec.com.br/ietec/techoje/techoje/tecnologiadainformacao/2003/10/10/2003 _10_10_0003.2xt/-template_interna Four Dark Corners of Requirements Engineering http://www-di.inf.puc-rio.br/~karin/pos/corners.pdf