Conforme discutido anteriormente, os resultados obtidos no desenvolvimento de sistemas frequentemente causam desapontamentos aos clientes. Sabe-se que uma das maiores causas desses problemas está na dificuldade dos desenvolvedores em entender os objetivos para os quais o sistema será construído. De maneira geral, se um sistema não satisfaz seu usuário é porque foi projetado sem um correto entendimento de seu propósito.
A solução para esse tipo de problema costuma ser a realização de uma análise cuidadosa do objetivo da construção do sistema, antes que se inicie seu desenvolvimento. O método desenvolvido neste trabalho oferece um meio de se compreender melhor os problemas que o cliente pretende resolver por meio do sistema. Uma vez compreendidos os problemas, devem ser identificadas suas necessidades e, como consequência, especificar os requisitos adequados para o sistema. Na Figura 39 são apresentados os passos seguidos no modelo proposto de engenharia de requisitos, por meio de um diagrama de atividades.
1 - Analisar o Negócio do Cliente
Nesta atividade é estudado o negócio do cliente, com foco na área que utilizará o software. Isso significa entender o domínio do problema em que o sistema será inserido. Esta atividade é importante para colocar os desenvolvedores em sintonia com o negócio do cliente, de forma que, ao iniciar a análise referente ao problema a ser solucionado, possuam certa familiaridade com os produtos da empresa e com os termos técnicos relacionados ao negócio. Esta análise de negócio pode ser realizada por meio de visitas para conhecer os processos realizados, estudo de documentos internos, etc.
2 - Obter percepção do Cliente a Respeito dos Problemas e Necessidades
Nesta atividade são obtidas as percepções do cliente (normalmente são diversos stakeholders) a respeito dos problemas que precisam ser resolvidos e o que ele necessita ou espera do sistema que irá solucionar estes problemas. Isso significa, principalmente, obter informações a respeito dos problemas a serem
resolvidos. Esta atividade pode ser desenvolvida em uma ou mais reuniões com o cliente.
Figura 39 – Diagrama de Atividades Modelo Proposto Fonte: Autoria Própria
3 - Organizar Problemas e Necessidades
De forma geral, as informações obtidas do cliente nestas primeiras reuniões costumam ser um tanto quanto confusas e desorganizadas. Por esta razão, o objetivo desta atividade é fazer com que a equipe de desenvolvimento organize estas informações colocando em listas separadas os problemas, as necessidades, os requisitos e até regras de negócio que são apresentadas pelo cliente. Organizar esta lista significa especialmente organizar a informação de forma que a equipe comece a vislumbrar com mais clareza a solução que deverá ser desenvolvida. Esta
atividade pode ser desenvolvida em uma reunião de equipe, desta forma, o fato de se discutir o conteúdo das diferentes listas irá ajudar a equipe a fortalecer seu entendimento do problema e da solução.
4 - Identificar o "Por que" de Cada Necessidade
Nas primeiras reuniões é bastante comum que o cliente apresente diversas necessidades e que não deixe claro que problemas cada necessidade irá solucionar. Por esta razão, nesta atividade deve ser realizada uma entrevista com o cliente com objetivo de interrogá-lo sobre a razão de cada uma destas necessidades existirem. Ao final da conversa espera-se ter identificado um problema para cada necessidade. Neste caso deverá ser estudada a relevância de se solucionar o problema.
5 - Reformular Problemas e Necessidades
Eventualmente, ao final da atividade número 4, é possível que ainda existam problemas e necessidades que não possuam um correspondente. Neste caso deverá ser avaliado se estes elementos devem ser eliminados ou se é necessário encontrar seu correspondente. Além disso, as respostas obtidas na atividade anterior deverão fornecer subsídios à equipe de desenvolvimento para reescrever os problemas e necessidades com base no entendimento obtido por meio da conversa com o cliente.
6 - Mapear Problemas X Necessidades
Nesta atividade os problemas e necessidades, devidamente reformulados, são colocados na matriz de projeto e seus relacionamentos são mapeados. Por padrão, busca-se manter os relacionamentos principais na linha diagonal da matriz e os relacionamentos secundários de distribuem na metade inferior e/ou superior. A prática de buscar manter todos os elementos não diagonais na parte inferior facilita a identificação dos elementos prioritários, especialmente no desenvolvimento. De maneira geral, os elementos mais à esquerda precisam ser realizados primeiro. Esta atividade pode ser realizada por apenas um dos analistas envolvidos no projeto por ser uma atividade bastante simples.
7 - Revisar Problemas e Necessidades com o Cliente
Nesta atividade a matriz de projeto elaborada na atividade anterior deve ser revisada pela equipe de projeto em conjunto com o cliente. Esta atividade é importante para assegurar que está claro como cada necessidade afeta a resolução de um ou mais problemas. A final desta atividade deve também ser avaliado se a matriz de projeto obtida está em acordo com o Axioma da Independência e com os princípios de análise estabelecidos na seção 4.9.
8 - Estabelecer Requisitos do Sistema
Esta atividade consiste em estabelecer os requisitos que atenderão as necessidades definidas até o momento. Recomenda-se que os requisitos sejam definidos por um analista, mas que sejam revisados por outras pessoas da equipe para assegurar que estejam em acordo com o conhecimento adquirido até este ponto do projeto.
9 - Mapear Necessidades X Requisitos
Nesta atividade as necessidades e os requisitos são colocados na matriz de projeto e seus relacionamentos são mapeados. Por padrão, busca-se manter os relacionamentos principais na linha diagonal da matriz e os relacionamentos secundários de distribuem na metade inferior e/ou superior. A prática de buscar manter todos os elementos não diagonais na parte inferior facilita a identificação dos elementos prioritários, especialmente no desenvolvimento. De maneira geral, os elementos mais à esquerda precisam ser realizados primeiro (LEE & JEZIOREK, 2006). Esta atividade pode ser realizada por apenas um dos analistas envolvidos no projeto, mas da mesma forma recomenda-se que seja revisada por uma ou mais pessoas da equipe.
10 - Avaliar Matriz Segundo Princípios de Análise
Esta atividade diz respeito à avaliação da matriz de projeto gerada na atividade anterior segundo o Axioma da Independência e os princípios de análise estabelecidos na seção 4.9. Nesta mesma atividade recomenda-se avaliar a matriz segundo alguns dos princípios de análise destacados na seção 6.6, que trata da discussão dos experimentos realizados.
11 – Detalhar
Nesta atividade, caso a matriz de projeto tenha sido aprovada segundo os princípios de análise e, caso seja considerado necessário, as necessidades e os requisitos são detalhados e, desta atividade, retorna-se à atividade número 9. Caso contrário segue-se para a próxima atividade.
12 - Definir Casos de Uso Correspondentes aos Requisitos
Esta atividade consiste em definir os casos de uso que refinarão os requisitos de sistema definidos até o momento. Recomenda-se que os casos de uso sejam definidos por um analista, mas que sejam revisados por outras pessoas da equipe para assegurar que sejam adequados para o projeto.
13 - Mapear Requisitos X Casos de Uso
Nesta atividade os requisitos e os casos de uso são colocados na matriz de projeto e seus relacionamentos são mapeados. Esta atividade pode ser realizada por apenas um dos analistas envolvidos no projeto, mas da mesma forma recomenda-se que seja revisada por uma ou mais pessoas da equipe.
14 - Avaliar Matriz Segundo Princípios de Análise
Esta atividade diz respeito à avaliação da matriz de projeto gerada na atividade anterior segundo o Axioma da Independência e os princípios de análise estabelecidos na seção 4.9. Nesta mesma atividade recomenda-se avaliar a matriz segundo alguns dos princípios de análise destacados na seção 6.6, que trata da discussão dos experimentos realizados.
15 - Detalhar
Nesta atividade, caso a matriz de projeto tenha sido aprovada segundo os princípios de análise e caso seja considerado necessário, as necessidades e os requisitos são detalhados. Desta atividade, retorna-se à atividade número 12. Caso contrário segue-se para a modelagem das colaborações ou outros elementos de modelagem definidos pela Abordagem de Projeto de Software Orientado a Objetos baseado em Projeto Axiomático (PIMENTEL, 2007). Por esta razão, as etapas seguintes, que envolvem o mapeamento de casos de uso para colaborações e modelagem do sistema, não são descritas neste trabalho.