O principal objetivo deste trabalho é propor uma abordagem que permita aplicar a Teoria de Projeto Axiomático (TPA) (SUH, 1990) na especificação de requisitos de sistemas de software. Outro objetivo é integrar a abordagem proposta a um processo estabelecido de especificação de requisitos como o fluxo de requisitos do Processo Unificado (JACOBSON, BOOCH, & RUMBAUGH, 1999). Desta forma, esta abordagem de especificação de requisitos poderá ser integrada aos processos e métodos de desenvolvimento de software usados atualmente. Da mesma forma, a abordagem proposta poderá ser integrada à abordagem de projeto orientado a objetos baseado em projeto axiomático (PIMENTEL, 2007).
A criação de uma abordagem que aplica a Teoria de Projeto Axiomático à especificação de requisitos de software em conjunto com o Processo Unificado se propõe a trazer vantagens ao processo de desenvolvimento de sistemas de software. Entre estas vantagens estão: estabelecer um método para a análise dos problemas e do domínio do problema; estabelecer um método que facilite a identificação e entendimento das necessidades do cliente; e rastrear os requisitos deste de sua origem, dos problemas do cliente até os casos de uso.
As metodologias de especificação de requisitos tradicionais utilizam recursos como entrevistas, workshops de requisitos, brainstorming e storyboards (LEFFINGWELL & WIDRIG, 2003) para entender os problemas e necessidades do cliente. Assim, frequentemente são definidos os requisitos do sistema sem que seja verificado se os problemas e necessidades definidos pelo cliente estão claros ou se existem questões que ele não deixou explícitas. Normalmente, as informações fornecidas pelos clientes são ambíguas e obscuras. Caso não sejam analisadas com cuidado levarão à definição de um conjunto inadequado de requisitos ou à definição de soluções de projeto ineficazes.
Desta forma, as abordagens de especificação de requisitos não propõem a decomposição de problemas e necessidades do cliente. A maioria delas tampouco sugere o detalhamento de requisitos. Nestas abordagens, estes elementos costumam ser interpretados apenas em um nível alto de abstração, o que pode tornar a sua análise superficial. Diferentemente, algumas abordagens, ditas baseadas em problemas, como a proposta por (JACKSON, 1999), defendem a importância de se analisar o problema de maneira detalhada com o objetivo de simplificar a elaboração da arquitetura do sistema.
Por outro lado, a TPA propõe a decomposição dos requisitos funcionais em uma estrutura hierárquica detalhada (SUH, 2001). Porém, não faz nenhuma menção à decomposição das necessidades do cliente, apenas apresenta-as como uma fonte para a identificação dos requisitos funcionais. Além disso, a TPA não define o domínio do problema e, portanto, também não trata a decomposição de problemas.
Na abordagem desenvolvida, em primeiro lugar, é proposta uma mudança no conjunto de domínios da TPA, adicionando o Domínio do Problema ao conjunto de domínios de projeto definido por Suh (1990). Esta nova visão permite incluir as tarefas de análise do problema na especificação de requisitos proposta por meio desta abordagem. Tendo em vista essa mudança na visão de domínios, a
abordagem redefine a correspondência entre os domínios da Teoria de Projeto Axiomático (TPA) e os fluxos do Processo Unificado (PU), com foco na relevância de cada fluxo de acordo com as fases de projeto. Esta abordagem também estabelece os conceitos que são aplicados em cada nível de detalhamento dos Problemas, Necessidades e Requisitos. Além disso, a abordagem apresenta elementos de modelagem que representam estes conceitos em linguagem UML/SysML. Finalmente, define as etapas e atividades do modelo de especificação de requisitos da abordagem.
De maneira geral, o trabalho propõe o uso do Axioma da Independência (AI) para avaliar se as necessidades são independentes entre si, em relação aos problemas que ajudam a resolver. Da mesma maneira, o AI é utilizado para avaliar a independência dos requisitos em relação às necessidades que atendem. Desta forma, é possível identificar os vínculos existentes entre estes elementos. Por outro lado, a decomposição dos mesmos elementos em vários níveis de hierarquia tem papel fundamental na compreensão dos problemas e necessidades. Por meio destes dois mecanismos se torna possível identificar e resolver inconsistências na análise e, consequentemente, definir com mais segurança os requisitos do sistema.
Além disso, o uso das ferramentas de Projeto Axiomático, como a matriz de projeto (MP) e a hierarquia funcional (processo em zig-zag), facilita a rastreabilidade dos requisitos em relação às necessidades e problemas (elemento incluído por esta abordagem). Para cada Problema (PB) é identificado o conjunto das Necessidades do Cliente (NC) vinculadas. Assim, cada PB é relacionado com as NCs correspondentes. Esta correspondência é mapeada na matriz de projeto.
Da mesma forma, para cada NC são identificados os Requisitos (RQs) que a atendem, sendo que cada NC é relacionada com os RQs correspondentes na matriz de projeto. Por sua vez, cada RQ de mais baixo nível está relacionado aos elementos de mais alto nível de abstração por meio da hierarquia funcional. O mesmo conceito é válido para os PBs e NCs. Este mecanismo permite uma rastreabilidade tanto horizontal (ex: de necessidades para problemas) quanto vertical (ex: de requisitos para sub-requisitos). Desta forma, é possível que um componente de software seja rastreado até o requisito de alto nível que satisfaz e para problema que originou este requisito.
A capacidade de rastrear requisitos é um meio comprovadamente eficaz para aumentar a qualidade e a confiabilidade do software, bem como para garantir
que os requisitos do sistema foram atendidos. Além disso, é muito importante para a minimização de impacto de mudanças de requisitos (LEFFINGWELL & WIDRIG, 2003). Esta capacidade é exigida em modelos de maturidade de software como MPS.BR (Softex, 2011) e CMMI (CHRISSIS, KONRAD, & SHRUM, 2007). Estes modelos de maturidade têm como objetivo (ou exigência) alcançar e manter a rastreabilidade dos requisitos em relação aos modelos de arquitetura e códigos fonte.
A abordagem proposta nesta dissertação pode ajudar a atingir um nível suficiente de rastreabilidade por meio da aplicação dos axiomas, teoremas, ferramentas e processos da TPA. Além disso, pode ser um método eficiente para se alcançar um alto grau de entendimento dos requisitos que o sistema deve atender.