Engenharia de requisitos: processos e técnicas no contexto organizacional

Autores: Edna Pacheco Zanlorenci - GPS Robert Carlise Burnett - PUC - PR

Resumo

Do ponto de vista conceitual, são abordados os fundamentos da engenharia de requisitos, os processos inerentes ao descobrimento, análise, validação e documentação dos requisitos, bem como as técnicas aplicáveis ao desenvolvimento dos processos.

Do ponto de vista da aplicação, é apresentada a abordagem de estudo do contexto organizacional, como uma das técnicas utilizáveis para o conhecimento do problema.

Palavras-chave: cenário, engenharia, ponto de vista, problema, processo, requisito, técnica.

1 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 [4], 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 [5] é 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 [4], simplesmente, podem ser definidos como "algo que um cliente necessita". Entretanto, do ponto de vista de um desenvolvedor, requisito pode também ser definido como "algo que necessita ser projetado".

Stackholders [5], são todos aqueles que são afetados ou que têm direta ou indiretamente influência sobre os requisitos para um sistema (clientes, usuários, desenvolvedores, gerentes,...).

2 Conceitos Fundamentais de ER

Sob o ponto de vista conceitual, no contexto da Engenharia de Requisitos, são apresentados os fundamentos da engenharia de requisitos, os requisitos e as especificações do produto e, os diferentes tipos de processos e de técnicas aplicáveis.

2.1 Engenharia de Requisitos

O termo "Requirements Engeneering" é traduzido para o português, como "Engenharia de Requisitos".

Engenharia de Requisitos [5 e 3] é um termo relativamente novo que foi inventado para cobrir todas as atividades envolvidas em descobrimento, documentação e manutenção de um conjunto de requisitos para um sistema baseado em computador. O uso do termo engenharia implica em técnicas sistemáticas e repetitíveis a serem usadas para assegurar que os requisitos do sistema sejam completos, consistentes, relevantes,... O termo engenharia de requisitos vem da antecedente engenharia de sistemas, correspondendo à fase de análise de sistemas.

Conceito:

Engenharia = aplicação de princípios matemáticos e científicos às construções.

Requisito = condição que se precisa para atingir um fim, como exigência legal ou necessária para certos efeitos.

"Engenharia de Requisitos

... processo sistemático de desenvolvimento de requisitos,

  • processo iterativo e cooperativo de análise do problema,
  • documentação de observações resultantes em uma variedade de formatos de representação,
  • checagem da precisão do entendimento obtido..." K.Pohl CAISE’93

"Requisitos

... são expressados em termos de relacionamentos de fenômenos acerca do domínio da aplicação[2],

  • devem ser eventos e estados que possam ser descritos precisos o suficiente para serem confiavelmente reconhecidos no domínio da aplicação..." M Jackson ISRE’95

A definição de Engenharia de Requisitos [4], apresentada por Klaus Pohl na 5.Conferência Internacional sobre Engenharia Avançada de Sistemas de Informação (CAISE’93 – The three dimensions of Requirements Engineering) é importante porque clarifica algumas das complexidades da Engenharia de Requisitos: o processo sistemático de desenvolvimento de requisitos, o processo iterativo e cooperativo de análise de problema, o processo de documentação das observações resultantes de uma variedade de formatos de representação e o processo de checagem da precisão do entendimento obtido.

A definição de requisitos apresentada por Michael Jackson no 2.Simpósio Internacional sobre Engenharia de Requisitos (ISRE'95) é importante porque enfatiza o conhecimento do problema no ambiente de negócio do cliente.

2.2 Processo de Engenharia de Requisitos

O processo de engenharia de requisitos [5] é um conjunto estruturado de atividades para extrair, validar e manter um documento de requisitos. Uma completa descrição do processo poderá incluir quais atividades são realizadas, a estruturação ou particionamento destas atividades, quem é responsável pela atividade, as entradas e saídas de/para atividade e as ferramentas usadas para suportar a engenharia de requisitos.

Conceito:

Processo = conjunto de atividades para extrair informação, validar e manter um documento de requisitos.

Tipos Processos:

  • Extração de Requisitos = descobrimento (elicit, em inglês);
  • Análise e Negociação de Requisitos = requisitos acordados;
  • Validação de Requisitos = consistentes, completos, precisos;
  • Gerenciamento de Mudança de Requisitos;

O processo de Engenharia de Requisitos[4] pode ser entendido como uma série de atividades consistindo de: articulação do conceito inicial, análise de problema, viabilidade e escolha de opções, análise e modelagem e documentação de requisitos. Cada atividade requererá o uso de técnicas potencialmente diferentes.

  • Conceito – o conceito de produto provê um gatilho para o processo de requisitos começar. Este gatilho pode ser um aperfeiçoamento em serviço do cliente, uma necessidade futura, um pequeno aperfeiçoamento incremental no sistema existente ou a necessidade de uso de alguma tecnologia que está disponível;
  • Análise de Problema – preocupação em desenvolver um entendimento da natureza do problema associado ao conceito de produto;
  • Estudo de viabilidade e escolha de opções – preocupação com avaliação de custos e de benefícios das soluções alternativas;
  • Análise e Modelagem – preocupação com a modelagem do domínio da aplicação e do espaço de solução, onde cada atividade pode ser seguida de validação, a fim de checar a precisão da informação reunida e do entendimento obtido;
  • Documentação de Requisitos – complementação do documento de requisitos.

2.3 Técnicas de Engenharia de Requisitos

O papel das técnicas de engenharia de requisitos pode ser sumarizado como necessário para suportar as diferentes fases do processo de engenharia de requisitos. É um conjunto de ferramentas aplicáveis às atividades para extrair, validar e manter um documento de requisitos.

Conceito:

Técnica = conjunto de ferramentas aplicáveis ao desenvolvimento dos processos.

Tipos Técnicas:

  • Processos ER;
  • Comunicação Humana;
  • Desenvolvimento do Conhecimento;
  • Documentação de Requisitos;
  • Gerenciamento de Requisitos.

Aplicação:

Para definir quais técnicas do conteúdo do portfólio são necessárias e quando usá-las, é necessário identificar os cenários envolvidos sob o enfoque de dois componentes básicos:

  1. O relacionamento entre o fornecedor de software e o cliente.
  2. O modelo do processo de engenharia de requisitos.

Existe uma série de abordagens para o entendimento do problema de requisitos:

  • Marketing – interessada no relacionamento entre requisitos e o sucesso de um produto no mercado (suporte ao usuário, pesquisas, grupos de usuários, apresentações produto, grupos de foco, análise de mercado,...);
  • Psicologia e Sociologia – interessada no relacionamento entre requisitos e necessidades de pessoas como seres inteligentes e sociais (entrevistas com usuário, observações, gravação de comportamento do usuário em vídeo, experimentos pensando em voz alta, jogos de cartas, estudos etnográficos,...);
  • Análise Orientada a Objetos (OOA) – interessada no relacionamento entre requisitos e o processo de desenvolvimento do software, iniciando de uma perspectiva de objetos do mundo real (modelo de objetos, comportamentos,...);
  • Análise Estruturada (SSA) – interessada no relacionamento entre requisitos e o processo de desenvolvimento de software, iniciando de uma perspectiva de processos e dados;
  • Projeto Participativo (Participative Design) – interessada em requisitos como parte de um processo que permite o envolvimento ativo do usuário no projeto de sistemas que afeta seu próprio trabalho (reuniões conjuntas e participativas);
  • Interação Computador-Humanos e Fatores Humanos (HCI) – interessada na aceitabilidade de sistemas para pessoas, a usabilidade dos sistemas e o relacionamento entre requisitos e avaliação do sistema em uso;
  • Método Sistemas Soft (SSM) – interessada no relacionamento entre requisitos e como as pessoas trabalham como parte de um sistema organizacional;
  • Qualidade – interessada no relacionamento entre requisitos e a qualidade de um produto, em relação ao processo de aperfeiçoamento que conduz à satisfação do cliente (QFD - quality function deployment,..);
  • Representação Formal Ciência da Computação – interessada no relaciona- mento entre requisitos e a necessidade de precisão da engenharia de software.

2.4 Abordagem do Problema

O processo de extração de requisitos requer uma análise cuidadosa da organização, do domínio da aplicação, de processos do negócio e, principalmente, da informação do cliente relativa às suas necessidades ou desejos e exigências.

O enfoque do problema no contexto de extração de requisitos é a razão principal para o entendimento, especialização e o domínio do conhecimento. Identificar o que é o problema, qual é a definição do problema, quem tem o problema e, qual a essência do problema sob o ponto de vista de quem o tem, caracteriza a complexidade do processo. Fatos como determinar o que está errado e o que pode ser feito acerca do erro e como identificar o problema em função da diferença entre o que é desejado e o que é percebido pelas pessoas, agregam um esforço considerável ao processo de descobrimento.

O foco no conhecimento do problema é representado na fig.1, considerando as colunas (vertical) como de domínio do projetista e, as linhas (horizontal) como de domínio do cliente, com os pontos de vista respectivos. As células representantes da interseção dos pontos evidenciam o domínio do conhecimento do problema, para compor o projeto de solução:

- essencial - o que deve ser atendido abrange a parte conhecida pelo projetista e pelo cliente, constitui-se no mínimo desejável;

- expectativa cliente - o que o cliente espera ser atendido abrange a parte conhecida pelo cliente, mas não conhecida pelo projetista; a conseqüência desta falta caracteriza a oportunidade perdida de negócio e a importância do papel do engenheiro de software (projetista);

- 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.

wpe2.jpg (18668 bytes)

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.

 

wpe6.jpg (21058 bytes)

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.

wpe1.jpg (21912 bytes)