De maneira geral, pode-se classificar os domínios de desenvolvimento de sistemas de software em dois grupos: Domínio de Problema e Domínio da Solução. Leffingwell e Widrig apresentam uma divisão destes dois domínios em alguns níveis, como ilustra a Figura 26 (LEFFINGWELL & WIDRIG, 2003). De acordo com os autores, a nuvem representa o conhecimento confuso e desorganizado que compõe o domínio do problema. As necessidades dos stakeholders pertencem também ao mesmo domínio. Por outro lado, no domínio da solução encontram-se as características e os requisitos do software.
O domínio do problema costuma ser um dos maiores desafios dos analistas de negócio e de requisitos. Entender o mundo do cliente, seus termos técnicos, regras e processos de negócio, além dos problemas que precisam ser resolvidos, pode se tornar um processo longo e complicado. O usuário, em geral, tende a ser um completo estranho que vive em um mundo desconhecido para os desenvolvedores.
Esse usuário precisa de ajuda para resolver seus problemas técnicos e, portanto, se torna responsabilidade da equipe de desenvolvimento entender os problemas dele. Nessa situação, tratar o domínio do problema como uma ―nuvem‖ de informações confusas e desorganizadas pode dificultar ainda mais o trabalho da
equipe. Nesse contexto, é necessário que a equipe domine técnicas de análise do problema e especificação de requisitos.
Figura 26 - Visão de Domínios de Problema e Solução Fonte: (LEFFINGWELL & WIDRIG, 2003)
Assim sendo, o domínio do problema foi reestruturado, com objetivo de organizar a ―nuvem‖ em novos níveis da pirâmide como ilustra a Figura 27. Conforme a visão proposta neste trabalho, o domínio do problema passa a ser organizado em três níveis da pirâmide: Necessidades Humanas ou Organizacionais, Problemas e Necessidades do Cliente. Por outro lado, no o domínio da solução é organizado em outras três partes: Características da Solução, Requisitos do Sistema e Casos de Uso.
Aqui é importante salientar que, embora os termos utilizados sejam semelhantes, o conceito de Necessidades Humanas ou Organizacionais é completamente diferente do conceito de Necessidades do Cliente. Como discutido na seção 2.4, as Necessidades Humanas correspondem ao conjunto de necessidades que são percebidas pelas pessoas ou instituições de maneira geral. As Necessidades do Cliente, por sua vez, referem-se somente às necessidades que o cliente espera que sejam atendidas por um determinado sistema.
De maneira geral, o relacionamento que existe entre os níveis da pirâmide é de causa e efeito. Assim sendo, são as necessidades básicas que, quando em desequilíbrio, causam os problemas. Em consequência, a existência dos problemas provoca as necessidades, que pedem por uma ou mais soluções. Finalmente, são as necessidades dos clientes que definem quais requisitos são exigidos de um produto (de forma que o sistema ajude a solucionar os problemas). Assim sendo,
partindo dos problemas e passando por cada um dos níveis da pirâmide, é possível para o analista sistematizar a especificação dos requisitos. Para identificar estas relações pode-se simplesmente perguntar ―quais necessidades este problema gera?‖ ou ―como é possível resolver este problema?‖.
Figura 27 - Nova Visão de Domínios de Problema e Solução Fonte: Autoria Própria
Da mesma forma, partindo dos requisitos e perguntando ―por quê?‖ os analistas serão capazes de chegar às necessidades. Esta rastreabilidade horizontal que deve existir entre os domínios é viabilizada pelo uso de matrizes. Nestas matrizes relacionam-se os elementos de cada domínio com os elementos do domínio seguinte, da esquerda para a direita. Além disso, nesta abordagem a matriz resultante deste relacionamento será avaliada segundo o Axioma da Independência conforme discutido mais adiante neste capítulo. A dinâmica desta relação é ilustrada na Figura 28.
Para efeito da abordagem proposta de especificação de requisitos não é considerado o primeiro nível, das Necessidades Humanas e Organizacionais. Especialmente por que isso levaria a um estudo subjetivo das razões que levam o cliente a querer resolver determinado problema. Este tipo de análise foge do contexto técnico da análise de requisitos, embora possa ser favorável ao analista ter certa sensibilidade em relação às motivações e expectativas do cliente.
Figura 28 - Relacionamento Entre Domínios Fonte: Autoria Própria
Assim sendo, esta abordagem deixa de lado a questão das necessidades humanas/organicionais, porém acrescenta um novo domínio ao conjunto de domínios de projeto propostos por Suh (SUH, 2001) como ilustra a Figura 29. Este novo domínio, denominado Domínio do Problema, contém toda a informação que define o problema e leva ao surgimento das necessidades do cliente. Por sua vez, as características se juntam às necessidades do cliente no domínio do cliente. Essa junção se deve ao fato de que as características representam descrições, na linguagem do cliente, do que o sistema precisa fazer para atender as necessidades deste cliente. Portanto, nesta abordagem as características são consideradas parte do domínio do cliente, por estarem relacionadas de uma maneira muito próxima com as necessidades do cliente (LEFFINGWELL & WIDRIG, 2003).
A proposta deste trabalho é iniciar o processo de especificação de requisitos pela identificação de Problemas e seu detalhamento. Em seguida, passa- se ao mapeamento dos Problemas para as Necessidades e o detalhamento das necessidades. Este processo de mapeamento e detalhamento entre domínios segue para o domínio funcional, chegando à identificação do conjunto dos requisitos funcionais e não funcionais. O conjunto dos requisitos definidos origina os casos de uso e, posteriormente, a arquitetura do produto.
Assim, tem-se nesta abordagem a representação do Domínio Funcional em duas partes, conforme representado pela Figura 29. A primeira, situada na área de Engenharia de Sistema, contém os Requisitos Funcionais e Não Funcionais de
Sistema. A segunda pertence à área de Engenharia de Software e contém os requisitos de software, representados por Casos de Uso. Esta organização é importante para que a abordagem de especificação de requisitos proposta neste trabalho possa ser utilizada em conjunto com a abordagem de Pimentel (2007).
Além disso, esta divisão do domínio funcional é importante pelo fato de se considerar, neste trabalho, que a elicitação de requisitos pertence à Engenharia de Sistemas. Considera-se, assim, que após a sua especificação alguns requisitos de sistema serão transferidos para a Engenharia de Software (transformando-se em casos de uso), enquanto outros poderão ser transferidos para áreas como Eletrônica ou Mecânica, por exemplo. Essa visão permite que a abordagem de especificação de requisitos proposta seja utilizada inclusive em áreas do conhecimento não necessariamente relacionadas com o desenvolvimento de software.
Figura 29 - Domínios de projeto Fonte: Autoria própria
Uma vez definidos os domínios envolvidos na especificação de requisitos, faz-se necessário determinar a forma como a abordagem proposta é aplicada no desenvolvimento de sistemas de software. A maneira mais adequada encontrada para a aplicação da abordagem foi adaptá-la a processos, até então, consolidados no meio de desenvolvimento, como o Processo Unificado.