Engenharia de Requisitos

5. QUEM SE BENEFICIA COM A ENGENHARIA DE REQUISITOS?

1.Introdução

A engenharia de requisitos não tem recebido a devida atenção e por causa disto tem sido vista com maus olhos pois os documentos produzidos através dela por analistas inexperientes tem causado problemas aos mesmos e aos seus contratantes, falta a visão mais metódica e de consenso geral na descrição de requisitos algo que não seja nem tão técnico, a partir do analista, nem tão “ai eu não sei bem o que eu queria”, a partir do contratante.

Ela está situada em uma região onde há grande desentendimento e confusão, 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 análise, apenas um texto descritivo e outras uma lista ou tabela a qual se deve cumprir no tempo determinado.

topo

2.Estado da arte

Não há um método em vigência para descrição de requisitos, o usado mais comumente e por costume é a descrição textual o que tem causado grandes empecilhos a todas as partes relacionadas no processo, são gerados documentos imprecisos (requisitos, ao contrário do que imaginam muitas pessoas ligadas ao processo de desenvolvimento, são difíceis de serem expressos pelo usuário) quanto às obrigações do sistema e também quanto às não obrigações, deixando margem às dúvidas.

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 resolução de problemas semelhantes e às vezes até o mesmo problema.

Problemas referentes à engenharia de requisitos funcionais têm sido resolvidos através de modelos como o diagrama de sequência, diagrama de classes e diagrama de estados, dentre outros de acordo com a cultura de cada empresa/consultor que faz a análise. Este método tem resolvido a questão para os contratados, mas produz um documento muito técnico e de difícil entendimento para o contratante e muitas vezes não reflete as reais necessidades que o sistema deve suprir, na visão (limitada, obviamente, do ponto de vista da implementação) do usuário.

Os requisitos não-funcionais, por serem geralmente atrelados à qualidade, não são fáceis de expressar por modelos, pois a qualidade não é expressa por abstrações de coisa concretas ou coisas por entidades pertencentes ao domínio do problema, entidades que tem vida determinada começam e terminam dentro do seu escopo.

Figura 01 – Classificação dos Requisitos

topo

3.O que é engenharia de requisitos?

É a engenharia (“Arte de aplicar os conhecimentos científicos à invenção, aperfeiçoamento ou utilização da técnica industrial em todas as suas determinações” – Dicionário Michaelis) aplicada a obtenção metódica de requisitos (“Requisitos: Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo objetivo.“ - Leite 94) do sistema, sejam estes Funcionais ou Não-Funcionais, tratando-os de maneira sistemática e padronizada com o fim de se ter um reaproveitamento da análise de requisitos feita, para qualquer outro projeto semelhante ou mesmo para manutenção do mesmo.

topo

3.1.Requisitos Funcionais:

Estão intimamente ligados às funcionalidades propostas pelo sistema, e que serão usadas na resolução do problema do contratante, e atenderá todas as suas necessidades funcionais. Resumidamente, são os requisitos que objetivamente cumprem as reais necessidades do usuário do sistema.
Exemplo: Controle financeiro, controle de tráfego aéreo, controle de produção.

topo

3.2.Requisitos Não-Funcionais:

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

Dependência positiva:

Quando da presença de um o outro é mais facilmente incorporado.

Figura 02 – Dependência positiva

Dependência negativa:

São conflitantes entre si, a presença ou existência de um compromete o outro ou diminui seu grau de atuação.

Figura 03 – Dependente negativa.

Requisitos não-funcionais podem ser classificados como:

Orientados ao consumidor:

Observáveis pelos clientes, não necessariamente os contratantes, mas os usuários dos software. Por exemplo: eficiência, 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 elicitação de requisitos não funcionais. Naturalmente a de mais assimilação pelo contratante, já que é feita de acordo com ponto de fácil mensuração por alguém que não tenha experiência técnica.

Exemplo:
Deve ser veloz (eficiente), seguro contra erros do usuário (robusto), etc.

Orientada ao processo

Abordagem técnica que prioriza o processo de desenvolvimento e não somente o produto, usa a premissa que através 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 têm sua importância dentro do contexto geral, sempre com o objetivo principal de auxiliar, dentro de suas especificações, 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 fácil e um pouco menos dependente do talento das pessoas e de suas experiências nesse tipo de atividade, evitando boa parte do re-trabalho e de inconsistências desses requisitos.

Define um documento de requisitos funcionais e requisitos não funcionais onde se deve ter a visão 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 análise.

Também tem a função de diminuir custos de desenvolvimento através de um processo de amadurecimento de idéias a medida que novos requisitos são expostos, isso se deve a premissa de que quanto mais cedo que identificar a mudança menos esforço ela resultará. Isso é feito através, principalmente da conscientização de que os requisitos são mutáveis e através da escolha de um modelo de ciclo de vida adequado.

Pode fazer o acompanhamento da resolução dos requisitos e da mudança dos mesmos, dando suporte a avaliação de custos e riscos na mudança dos requisitos ao longo da análise ou projeto com a finalidade de avaliar a viabilidade da mudança dos mesmos no atual instante de desenvolvimento.

topo

5. Quem se beneficia com a engenharia de requisitos?

Contratantes, quem solicita o serviço de análise do problema, por terem um documento que assegure a resolução dos problemas referentes aos requisitos funcionais propostos e terem também a garantia da qualidade através de requisitos não funcionais expressados no mesmo documento.

Contratado, que fornece o serviço de análise de problemas, com o documento produzido através da engenharia de software este terá uma visão mais precisa e clara dos verdadeiros requisitos funcionais necessários, não perdendo tempo e sendo mais objetivo, e também pode focalizar a qualidade do produto de acordo com os requisitos não-funcionais escolhidos.

Futuros contratados e contratantes, que podem se beneficiar do reuso da engenharia de requisitos através de documentos bem elaborados feitos anteriormente para resolução de problemas semelhantes, diminuindo assim o tempo de desenvolvimento e por consequência o custo para o contratante, contextualizando o contratado com o problema a ser resolvido e com as peculiaridades do mesmo em relação a conhecimentos específicos do domínio do problema na área proposta.

Em suma, a engenharia de requisitos traz benefícios a ambas as partes, tanto com diminuição de custos para os contratantes, como em uma melhor contextualização e um maior controle sobre os requisitos para o contratado, e também propõe o reuso dos documentos produzidos, ou seja, incita o reuso do conhecimento adquirido através a iteração entre as partes ao longo do processo de engenharia de requisitos.

topo

6. Conclusão

É importante perceber que a engenharia de requisitos depende muito da interação entre contratantes e contratados, de modo que seja minimizado qualquer problema na definição de requisitos por parte do cliente. Por mais que não se deseje, os requisitos estarão sempre mudando durante o desenvolvimento de um sistema, e quão melhor for o processo de engenharia de requisitos desenvolvido por todos na empresa, menores serão os problemas encontrados em função de toda a dificuldade que envolve esta importante parte da análise.

Também é notável que o cenário atual na engenharia de requisitos esta muito longe do ideal tanto para os contratantes como para os contratados, isto se deve a falta de padronização principalmente na engenharia de requisitos não funcionais, e a falta de uma real conscientização da importância da engenharia de requisitos no contexto da engenharia de software.

Também há uma carência conceitual em relação aos profissionais da área de engenharia de software relacionada a falta ou pouco entendimento do domínio do problema do problema a se analisado e documentado, sendo este causado pela transdisciplinalidade da aplicação de engenharia de software na resolução de problemas.

topo