resumo artigo27 para 26-03-11 - engenharia de requisitos

R E V I S T A E L E T R Ô N I C A F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É

4ª Edição ISSN: 2178-3098

1

ENGENHARIA DE REQUISITOS

Rafael da Silva Rocha1

Teresinha Moreira de Magalhães2

RESUMO

Este artigo procura descrever a engenharia de requisito como uma condição ou uma

capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema,

para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos

formalmente.

PALAVRAS-CHAVES: Especificação, Requisitos, Processos

INTRODUÇÃO

O interesse por uma abordagem sistemática do conhecimento de problema, levou à busca

de apoio de uma nova área de pesquisa, a engenharia de requisitos. A Engenharia de

Requisitos pode ser definida como o processo sistemático de desenvolvimento de requisitos

através de um processo iterativo e cooperativo de análise de problema, de documentação de

observações resultantes em uma variedade de formatos de representação e de checagem da

precisão do entendimento obtido. O processo de engenharia de requisitos é um conjunto

estruturado de atividades para extrair requisitos, validá-los e mantê-los. As técnicas de

engenharia de requisitos referem-se ao conjunto de ferramentas aplicáveis ao

desenvolvimento dos processos. Requisitos, simplesmente, podem ser definidos como "algo

1 Bacharelando em Sistemas de Informação pela Faculdade de Ciências Gerenciais de Santos Dumont. [email protected] 2 Graduada em Processamento de Dados e Pós Graduada em Redes de Computadores pelo Centro de Ensino Superior de Juiz de Fora, Pós Graduada em Matemática e Estatística pela Universidade Federal de Lavras, Mestre em Engenharia da Produção com ênfase em Produção de Mídias pela Universidade Federal de Santa Catarina e Doutora em Sistemas Computacionais pela Universidade Federal do Rio de Janeiro. [email protected]



2

que um cliente necessita". Entretanto, do ponto de vista de um desenvolvedor, requisito pode

também ser definido como "algo que necessita ser projetado".

REQUISITOS

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. Documentos imprecisos são gerados (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 seqüê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.



3

Figura 01 – Classificação dos Requisitos

O PROCESSO DE PRODUÇÃO DE REQUISITOS

• Os quatro sub-processos da Produção de Requisitos:

– Estudo de Viabilidade : Avaliação se o sistema é útil para a empresa;

– Elicitação e Análise : Identificação da fonte de informação. Obtenção dos dados e fatos;

– Documentação : Especificação e conversão dos requisitos em alguma forma-

padrão;Documentação;

– Validação : Verificação se os requisitos realmente definem o sistema que o cliente deseja;

Protótipo.

O PROCESSO DE GERENCIA DE REQUISITOS

• Os quatro sub-processos da Gerência de Requisitos:

– Gerência de Mudanças : Controla as solicitações de mudança do cliente;

– Gerência de Configuração : Controla as versões dos artefatos;

– Gerência de Qualidade dos Requisitos : Define o padrão de produção e verificação da

qualidade dos requisitos;



4

– Rastreabilidade : Relação entre as fontes dos requisitos, os requisitos propriamente ditos e

outros artefato.

CONCEITO DE 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.

� 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.

� 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.



5

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 do 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.

APLICAÇÕES DA 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



6

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.

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 conseqüê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.



7

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.

CONCLUSÃO

Identificar e aplicar a técnica mais adequada para o desenvolvimento de um processo de

engenharia de requisitos depende do tipo de produto ou de serviço ou de resultado que se

deseja obter ou oferecer ao cliente. É atribuição do engenheiro de software, em função do

ambiente do negócio e da especificidade do produto, adequar ao processo de desenvolvimento

de requisitos, as ferramentas e as técnicas individualmente ou em conjunto, com o objetivo

único e verdadeiro de se obter o conhecimento do problema, no contexto dos variados pontos

de vista do cliente e das perspectivas de solução.

O método apresentado como modelo de estudo para o contexto organizacional não sozinho,

mas associado a outras técnicas (a exemplo de projeto participativo envolvendo o cliente na

solução), é o que mais se aproxima do entendimento dos problemas.



8

REFERÊNCIAS

PRESSMAN, Roger S. Engenharia de Software. São Paulo- Makron Books, 1995.

SOMMERVILLE, Ian. Engenharia de Software. São Paulo – Pearson Addison Wesley,

2003.

PAULA FILHO, W. P. Engenharia de Software: Fundamentos, Métodos e Padrões –

LTC, 2003.

resumo artigo27 para 26-03-11 - engenharia de requisitos

Documents