- expectativa projetista - o que o projetista pode oferecer abrange a parte conhecida pelo projetista, mas não conhecida pelo cliente; a oferta do produto caracterizará o fator surpresa incremental à solução do problema;

- nunca realizável - depende do esforço de conhecimento de ambos, projetista e cliente, o que não é declarado, nunca será realizado.

A resultante dos termos comparativos demonstra o esforço que se tem de investir para redução da coluna desconhecido pelo projetista. Quanto maior for o campo de conhecimento do projetista acerca do problema, tanto maior a oportunidade de negócio e de serviços realizáveis.

fig.1 - foco no conhecimento do problema (fonte D.Gause tutorial ICRE'98 e [1])

Enfim, é necessário distinguir claramente um processo de definição do problema (conhecimento dos requisitos), de um processo de solução do problema (aplicação de ferramentas de software como solução). Isto porque a fonte de problemas vem de dentro de pessoas e o importante é identificar qual o desejo de ter resolvido o problema e se existe realmente o desejo de uma solução.

No contexto do negócio, os assuntos organizacionais [5] e fatores políticos podem influenciar nos requisitos. Nas organizações, a luta pelo poder e relações de influência entre diferentes pessoas dificultam um denominador comum quanto à propriedade da informação e a definição da melhor forma de administrá-la. Cabe aí uma negociação cuidadosa e a delimi- mitação de fronteiras, com o estabelecimento de objetivos, o entendimento do histórico e estrutura organizacional e a própria organização do conhecimento.

A fonte de informação cliente é composta por uma variedade de requisitos expressa de acordo com a posição que a pessoa ocupa na organização e o seu nível de interesse e comprometimento na identificação de problemas e na procura de solução.

3 Contexto da Aplicação

Sob o ponto de vista da aplicação é apresentada a ferramenta SSM (Soft Systems Methodology), um método de estudo do contexto organizacional. A essência do SSM [3] é que ele reconhece que os sistemas estão enraizados na área de atuação humana dentro de um contexto organizacional. O SSM supre os meios para o entendimento abstrato dos requisitos do sistema, pela análise do contexto organizacional, o entendimento do problema a ser resolvido e conhecimento de sistemas existentes disponíveis no mercado. Ele foi um dos primeiros métodos a introduzir a noção de ponto de vista, onde diferentes pontos de vista apresentam diferentes percepções do problema e requisitos de solução.

3.1 SSM – Método de Sistema de Software

A abordagem SSM [4] reconhece que todas as ações humanas se dão dentro de um contexto organizacional. Os elementos básicos da técnica foram estabelecidos no início da década de 1970 e refinados em vários anos por um processo de ação de pesquisa. Envolveu aplicação de técnicas para situações de problemas reais, avaliando sua efetividade e fazendo ajustes de acordo com as necessidades. Não é precisamente a definição de uma metodologia, mas uma coleção de conceitos que os analistas podem usar em variadas formas que encontrem aplicação.

SSM é importante porque tem um número de características que não são explicitadas pela maioria dos métodos tradicionais. Dobbin e Bustard [4 (1994)] apresentaram um resumo destas características:

- tratamento da situação problema - diz respeito à análise inteira da situação problema, por considerar a abrangência do ambiente do sistema tanto quanto a investigação sobre o sistema. Não examina um problema, mas a situação em que existe percepção para ser um problema;

- ênfase sobre comportamento - foca sobre identificação de propósito de um sistema e as atividades necessárias para encontrar estes propósitos. Evita explicitamente uma consideração de sistema estruturado inicialmente;

- ênfase sobre mudanças - é uma metodologia baseada sobre a idéias de mudança em uma situação problema. O modelo de sistema proposto é comparado com o atual a fim de determinar mudanças necessárias;

- múltiplas perspectivas - a essência é a análise da situação problema de um número de diferentes perspectivas ou pontos de vista. Sistemas usualmente servem a um número de diferentes propósitos e um conhecimento de múltiplos pontos de vista provê o mecanismo para identificação e resolução de conflitos;

- dirigida a objetivos - foca sobre o sistema desejável e como alcançá-lo, de preferência, iniciando com a situação atual e considerando como implementá-lo;

- ênfase sobre controle e monitoração - reconhece a importância do controle em qualquer sistema, requerendo a presença de uma atividade de monitoração e controle.

A metodologia básica é representada na fig.2, segundo [4 - (Wilson,1984)] em sete estágios distintos:

1. descobrindo a situação problema;

2. expressando a situação problema (rica des-crição do mundo real);

3. seleção, isto é, selecionando como visualizar a situação para compreensão e produzindo definições abstratas;

4. construindo modelo conceitual do que o sistema deve fazer para cada definição abstrata;

5. comparação do modelo conceitual com o mundo real;

6. identificação de viabilidade e mudanças desejáveis;

7. recomendações de ações para superação da situação problema.

 

fig.2 - uma visão de SSM - (fonte [4])

 

As recomendações de uso da metodologia referem-se à liberdade de utilização e à forma de representação do conhecimento. Primeiro, é possível iniciar a metodologia em qualquer estágio adequando-a ao momento e ao contexto em estudo. Segundo, a linguagem de representação das informações do mundo real, ou seja, referente aos estágios situados acima da linha divisória, deve ser expressada de forma facilmente entendível pelo pessoal envolvido com a situação problema, na forma simbólica ou textual. Enquanto que os estágios situados abaixo da linha, correspondentes às idéias de sistema acerca do mundo real, requerem uma linguagem especializada de sistemas, no modo formal, ou seja, "válida se e, somente se" atender a determinadas condições.

A aplicação da metodologia é melhor detalhada em [4, cap3], com exemplos aplicáveis a um sistema de locação de veículos. As justificativas de propósito de cada estágio são explicitadas da seguinte maneira:

1. a situação problema: não estruturada - é para descrever a situação problema, onde a informação é reunida acerca de quem é envolvido, quais suas percepções da situação, qual a estrutura de organização e quais processos representam;

2. a situação problema: expressada - é para descrever as características importantes da situação problema que ajudarão a definição abstrata de sistemas relevantes;

3. definição abstrata de sistema relevante - é para definir notações de sistemas que são relevantes para a situação problema. Isto inclui um roteiro sumarizado pelo mnemônico "CATWOE", com uso recomendado para exploração e incorporação dos variados pontos de vista:

- C (customers) - clientes que são beneficiários ou vítimas do sistema;

- A (actors) - atores que desempenham atividades definidas;

- T (tranformations) - transformações de entradas em saídas;

- W (weltanschauung) - visão do mundo, representações de pontos de vista;

- O (owner) - proprietário ou quem tem o poder para autorizar ou desfazer o sistema;

- E (environment) - restrições ambientais, elementos restritivos ou condicionantes para o sistema;

4. modelo conceitual - é um modelo de atividade humana que rigorosamente representa uma definição abstrata. Para a checagem do modelo conceitual, podem ser utilizadas outras técnicas de idéias sobre sistemas 4b, mas a principal inclui um roteiro formal 4a. A técnica formal no exemplo provê a validação de um sistema de atividade humana S, utilizando o modelo formal de sistema, isto é, o modelo conceitual é válido se, e somente se, atende às condições:

- S tem um propósito ou missão;

- S tem uma medida de desempenho;

- S contém um processo de decisão;

- S tem componentes que são também sistemas contendo todas as propriedade de S;

- S tem componentes que interagem de tal forma que efeitos e ações podem ser transmitidos através do sistema;

- S existe em grandes sistemas e/ou ambientes com que ele interage;

- S tem uma fronteira, separando-o de um sistema maior ou ambiente que é formalmente definido pela área dentro do processo de decisão e tem poder para causar ação;

- S tem recursos, físicos e através de participantes humanos, que estejam à disposição do processo de decisão;

- S tem alguma garantia de continuidade, isto é, tem algum termo longo de estabilidade ou irá obter estabilidade após algum grau de turbulência.

5. comparação - é para comparar as atividades descritas no modelo conceitual com o que acontece no mundo real. Para cada atividade deve ser feito o questionamento:

- é uma atividade realizada no mundo real?

- como ela é feita?

- como é medido seu desempenho?

- é a atividade realizada efetivamente?

6. definição de viabilidade e mudança desejável - é para investigar quais atividades são ambas viáveis culturalmente e sistematicamente desejáveis. Isto pode envolver a exploração de viabilidade de movimentação da situação atual para a situação insinuada pelo modelo conceitual, trazendo pessoas para compartilhar o entendimento de diferentes percepções da situação e fazer com que as mesmas julguem o nível desejável das atividades.

7. ação para resolver ou superar o problema - é para usar a informação reunida como uma base para o projeto da solução ou escolha de opção e para planejamento de uma implementação aceitável.

Os sete estágios constituem a descrição básica do SSM e contribuem para o aperfeiçoamento do processo de articulação do conceito de produto, análise de problema, análise de opções e também:

 

- prover uma forma de pensar acerca da organização atual e identificar o potencial de mudança;

- ajudar a identificar os stackholders chave e seus objetivos;

- ajudar a identificar grupos de trabalho chave e seus objetivos;

- ajudar a identificar que papéis de trabalho poderão ser suportados e por quê;

- ajudar a descrever descrições de papéis de trabalho;

- ajudar a descrever visões e propósitos de projeto;

- suportar comunicação entre pessoas;

- ajudar a encontrar conflitos entre stackholders e entre pontos de vista.

4 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. Caberá ao 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 de problemas.

Referências Bibliográficas

[1] GAUSE, Donald C., WEINBERG, Gerald M. Exploring requirements (quality before design). USA : Dorset House Publishing, 1989. 300 p.

[2] JACKSON, Michael. Software requirements and specifications: a lexicon of pratice, principles and prejudices. Massachustes : Addison-Wesley, 1995. 228 p.

[3] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering (processes and techniques). England : John Wiley & Sons, 1998. 282 p.

[4] MACAULAY, Linda A. Requirements engineering. Great Britain : Springer-Verlag London, 1996. 202 p.

[5] SOMMERVILLE, Ian; SAWYER, Pete. Requirements engineering (A good practice guide). England : John Wiley & Sons, 1997. 391 p.