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: ENGENHARIA DE REQUISITOS

Transcrição

1 1 ENGENHARIA DE REQUISITOS Rafael da Silva Rocha 1 Teresinha Moreira de Magalhães 2 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. rafael_2005@oi.com.br 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. tmagalha@yahoo.com.br

2 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 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 formapadrã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 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 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 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 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 8 REFERÊNCIAS PRESSMAN, Roger S. Engenharia de Software. São Paulo- Makron Books, SOMMERVILLE, Ian. Engenharia de Software. São Paulo Pearson Addison Wesley, PAULA FILHO, W. P. Engenharia de Software: Fundamentos, Métodos e Padrões LTC, 2003.