Modelo para qualificação da fonte de informação do cliente e de requisito funcional

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

Artigo apresentado no I. Workshop de Engenharia de Requisitos WER'98, XII Simpósio Brasileiro de Engenharia de Software, Maringá (12-16 out) SBES'98

Resumo

O modelo proposto visa incrementar ao conteúdo do requisito parâmetros para qualificação e validação das informações. O foco de observação é sobre dois elementos: fonte de informação e características do requisito. Quanto à fonte de informação, o modelo propõe, primeiro, identificar a pessoa responsável pela declaração do requisito sob o ponto de vista de produtor e/ou consumidor da informação; segundo, visualizar claramente o papel que esta pessoa ocupa na organização (operacional, tático, estratégico) como formadora de opinião e, terceiro, qualificar o nível de exigência (essencial, expectativa, excedente) para a satisfação do requisito. Quanto ao requisito, o modelo propõe, primeiro, identificar a área de aplicação (operacional, tático, estratégico); segundo, identificar a área de origem do requisito (interno, externo, ordem legal) e terceiro, identificar a relação de dependência do requisito no contexto em estudo (individual, secundário, grupo).

O procedimento seguinte será a validação de requisitos pelo confronto das informações do requisito com as dos variados pontos de vista das pessoas, através da ponderação (valor) do grau de exigência e conformidade com a necessidade e/ou desejo do cliente expresso no processo de extração de requisito, em relação ao produto ou serviço.

Como resultado, obtém-se um índice médio de qualificação do requisito, que permitirá avaliar o grau de risco (alto, médio e baixo) para a implementação do requisito.

Palavras-chave: contexto, domínio aplicação, negócio, ponto de vista, problema, requisito

1 Introdução

O interesse por uma abordagem sistemática de conhecimento do problema levou à busca de apoio de uma nova área de pesquisa, a Engenharia de Requisitos.

A Engenharia de Requisitos, segundo Macaulay [9], pode ser definida como o processo sistemático de desenvolvimento de requisitos através de processos iterativos de análise do problema, de documentação das 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, Sommerville [08,10] é um conjunto estruturado de atividades para extrair requisitos, validá-los e mantê-los.

Requisito, para Macaulay [9], simplesmente pode ser definido como "algo que um cliente necessita". Entretanto, do ponto de vista do engenheiro de software, requisito pode também ser definido como "algo que necessita ser projetado".

O produto do processo de engenharia de requisitos é o documento de requisitos. Agregar qualificação à fonte de informação e quantificação ao requisito no processo de extração, é fundamental para permitir a validação do requisito, que é o enfoque do modelo proposto.

A parte 2 deste artigo apresenta aspectos contextuais do processo de extração de requisitos. A parte 3 apresenta uma proposta de modelo para qualificação da fonte da informação do cliente e das características do requisito, individualmente, e relacionado a outros requisitos integrantes do problema. A parte 4 apresenta um parecer sobre a contribuição para a pesquisa e a prática, no tratamento da fonte de informação do requisito para obtenção de requisitos completos, consistentes, não ambíguos e válidos. A parte 5 apresenta vantagens e limitações do modelo. A parte 6 finaliza com um resumo de considerações finais sobre o processo de extração de requisitos e os resultados esperados com a aplicação do modelo.

2 O Processo de Extração de Requisitos

O processo de extração de requisitos requer uma análise criteriosa da organização, compreendendo: a definição do alvo e da abrangência do domínio da aplicação, o entendimento do foco no problema a resolver (o quê, para quê e para quem), a identificação de processos do negócio e, principalmente, o conhecimento da informação do cliente relativa às suas necessidades ou desejos e exigências.

Extração de requisitos[8] é o nome usual dado às atividades envolvidas em descobrimento de requisitos, representadas na fig.1.

wpe2.jpg (13007 bytes)

fig1: componentes de extração de requisitos - Fonte [8]

2.1 Domínio da Aplicação ou Ambiente

O primeiro passo em análise de problemas, segundo Jackson[5], é estruturar e analisar o domínio da aplicação. O princípio de relevância do domínio declara que "Tudo o que é relevante para os requisitos, deve aparecer em alguma parte do domínio da aplicação". Existe uma importante conseqüência deste princípio. O domínio da aplicação não é limitado a partes do mundo que estão diretamente ligadas ao domínio da máquina. É mais abrangente, pois refere-se ao negócio.

O domínio da aplicação é onde os requisitos particulares dos clientes são encontrados. Se o domínio da aplicação não for identificado corretamente, não se está apto para focalizar os requisitos dos clientes. Zave [12] apresenta que todas as descrições envolvidas em engenharia de requisitos poderão ser descrições de ambiente.

A identificação do ambiente ou domínio da aplicação onde está inserido o problema que se quer tratar é o passo inicial para o planejamento das atividades de descobrimento dos requisitos inerentes ao contexto do negócio. Pode-se pensar o domínio da aplicação como o que é dado e o domínio da máquina como o que será construído[5].

wpe3.jpg (5824 bytes)

fig.2: o domínio da aplicação no contexto do conhecimento (fonte[5])

 2.2 Problema a ser Resolvido

Um problema ao ser tratado por pessoas agrega sempre características inerentes ao fator humano do querer, do saber, do poder e, principalmente, da comunicação e do entendimento do requisito. Gause em [3] e [4] apresenta várias abordagens de enfoque sobre problema.

Ainda persiste na área de engenharia de software a tentativa de visualizar a tecnologia como solução de problema, sem antes focar intensivamente o esforço em definição e entendimento do problema e na negociação de eventuais conflitos de interesses pela solução.

A falta de habilidade para discutir problemas tem sido uma das mais flagrantes deficiências da teoria e da prática em software. Muitos escritores sobre métodos de desenvolvimento afirmam oferecer uma análise de problema, quando de fato oferecem somente um contorno de solução, deixando o problema inexplorado e inexplicável[5].

O problema no contexto de extração de requisitos é a razão principal para o entendimento, a especialização e o domínio do conhecimento. Identificar a designação do que é 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, caracterizam a complexidade do processo. Fatos como determinar o que está errado e o que pode ser feito acerca do erro ou como identificar o problema em função da diferença entre o que é desejado pelo cliente e o que é percebido pelo engenheiro de software agregam um esforço considerável ao processo de descobrimento.

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). Como a fonte de problemas vem de dentro das pessoas, o importante é identificar qual a necessidade de ter resolvido o problema e se existe realmente o desejo de uma solução[5].

2.3 Contexto do Negócio

Assuntos organizacionais [11] 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 à definição da melhor forma de administrá-la. Cabe aí uma negociação cuidadosa e a delimitação de fronteiras, com o estabelecimento de objetivos, o entendimento do histórico e da estrutura organizacional e da própria organização do conhecimento.

Um fator expressivo de conflito também ocorre em ambientes descentralizados geograficamente, em relação ao desenvolvimento dos processos organizacionais. O desconhecimento das peculiaridades regionais pelo poder centralizado, as dificuldades de comunicação e a falta de padronização no tratamento da informação tornam mais complexo o processo de validação de requisitos, quando estes tendem a ser necessidades comuns ou até mesmo particulares.

2.4 Informação do Cliente

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 de comprometimento na identificação de problemas e na procura de solução.

O posicionamento do cliente como consumidor e/ou produtor, como formador de opinião para definição do problema em estudo é o passo inicial do processo, especialmente no esclarecimento do nível de exigência do requisito sob o enfoque de grandeza do que é essencial para a organização, acima dos interesses particulares. É claro que o ponto de vista particular do cliente é importante, mas no contexto organizacional este pensamento pode ser diluído em confronto com os demais posicionamentos sobre o requisito, considerando-se a necessidade de se obter a melhor representatividade de opiniões para a definição do problema.

Portanto, a aplicação de um critério de qualificação da fonte de informação cliente contribui para as etapas seguintes de análise e validação do requisito.

3 Modelo para Qualificação da Fonte de Informação e de Requisitos

O que é?

O modelo é uma proposta aplicável ao processo de extração de requisitos dentro de um âmbito organizacional. A fig.3 representa o modelo de objetos no contexto da informação, caminho para o descobrimento de requisitos. O foco de estudo concentra-se especificamente na parte escurecida do modelo, compreendendo a fonte de informação cliente (ponto de vista, qualificação ocupacional e nível de exigência) e o requisito funcional (qualificação funcional, área de origem e relação de dependência).

wpe4.jpg (26922 bytes)

fig.3: modelo de objetos do contexto da informação

Objetivos?

- a nível geral - utilizar um método que possibilite qualificar o agente da fonte de informação e seu posicionamento sobre o requisito descrito;

- a nível específico - agregar parâmetros para validação do requisito:

  • qualificar a fonte de informação do cliente, como usuário da informação e o papel que exerce na organização;

  • quantificar o nível de exigência do requisito, sob o ponto de vista do cliente;

  • qualificar o requisito, pela funcionalidade na organização e a área de origem do mesmo;

  • quantificar o nível de relação de dependência do requisito em relação a outros requisitos;

  • associar valores ao posicionamento de cada cliente da informação e de cada requisito;

  • atribuir peso aos valores posicionados pelo nível de importância da informação;

  • calcular a média simples das informações obtidas pelo número de informantes;

  • enquadrar o resultado obtido nos parâmetros estabelecidos;

  • determinar o grau de risco de implementação do requisito em relação à representatividade do grupo de informantes e à própria origem do requisito.

3.1 Estratégia para Aplicação do Modelo

O procedimento de validação de requisitos deve confrontar as variadas declarações das pessoas comprometidas com o processo de definição do problema, sob os mais diversos pontos de vista e de cenários de ocorrência do fato. Para isso, a cada requisito, a pessoa segundo seu nível de expectativa declarado, irá definir seu grau de exigência e conformidade com a necessidade e/ou desejo em relação ao produto ou serviço. Nesta declaração, a pessoa estará se posicionando em função de seu papel principal de produtor ou consumidor da informação e, especialmente, em observância ao nível administrativo (operacional, gerencial ou estratégico) ocupado na organização e, como formador de opinião. A fig.4 apresenta todas as possibilidades possíveis de informação, nos três níveis de atributos.

wpe5.jpg (17321 bytes)

fig.4: possibilidades de caminhos de representação da fonte informação e requisito

3.2 Determinando a Qualificação da Fonte de Informação

Para a qualificação da fonte de informação cliente, definem-se três aspectos que caracterizam e personalizam o agente da informação, conforme representado na tab.1:

  • o ponto de vista do cliente - em relação à informação, como produtor, consumidor, ou nem produtor/nem consumidor, mas como observador neutro com experiência na organização e que foi convocado para o processo de extração de requisito;

  • a qualificação ocupacional do cliente na organização - em relação à função ocupada na organização se em nível operacional, em nível gerencial ou em nível estratégico diretivo;

  • o nível de exigência da informação - o que é considerado essencial para o aspecto funcional da organização, o que é expectativa de implementação e o que é futurista para a realidade atual; Karlsson[6(refere-se à classificação de Brackett)].

Fonte Informação Cliente atributo.1 atributo.2 atributo.3

1.Ponto Vista do Cliente

1.1.Produtor 1.2.Consumidor 1.3.Não P/C

2.Qualificação Ocupacional do Cliente

2.1.Operacional 2.2.Tático 2.3.Estratégico

3.Nível de Exigência Informação

3.1.Essencial 3.2.Expectativa 3.3.Excedente

tab.1: Relação entre Fonte de Informação e Requisitos

Analisando-se todas as possibilidades de resposta procedentes de todos os tipos de clientes envolvidos no processo de extração de requisitos, a tab.2, apresenta um quadro completo das situações possíveis, conforme os níveis de decisão da fig.4 anterior.

wpe3.jpg (39157 bytes)

A cada condição atendida atribui-se um valor pelo grau de importância no contexto (8=alto,4=médio,2=baixo)

tab.2: Possibilidades de Qualificação de Cliente e Exigência de Requisitos

3.3 Determinando a Qualificação do Requisito

Para a qualificação do requisito, definem-se três aspectos que caracterizam e qualificam o requisito e estão representados na tab.3:

  • a qualificação funcional do requisito - em relação ao caráter funcional na organização se em nível operacional, em nível gerencial ou em nível estratégico diretivo;

  • a área de origem do requisito - enfocando a exigência do requisito para atendimento à funcionalidade: interna (área origem produto), externa(área destino produto) ou a de ordem legal;

  • o nível de dependência do requisito - se é considerado exclusivo ou integrante de um grupo ou o próprio item grupo, considerando-se o rol de requisitos no contexto do problema.

Requisito Funcional

atributo.1

atributo.2

atributo.3

1.Qualificação Funcional do Requisito

1.1.Operacional

1.2.Tático

1.3.Estratégico

2.Área Origem do Requisito

2.1.Interno

2.2.Externo

2.3.Ordem Legal

3.Relação Dependência de Requisitos

3.1. Grupo

3.2.Secundário

3.3. Individual

tab.3: Relação entre Requisito e Origem Informação

Analisando-se todas as possibilidades de caracterização do requisito, a tab.4, apresenta um quadro completo das situações possíveis, conforme os níveis de decisão da fig.4 anterior.

wpe5.jpg (42290 bytes)

A cada condição atendida atribui-se um valor pelo grau de importância no contexto (8=alto,4=médio,2=baixo)

tab.4: Possibilidades de Qualificação de Requisitos

3.4 Determinando o Grau de Risco de Implementação do Requisito

Primeiro, é necessária a qualificação do requisito, conforme especificado no item 3.3 anterior, com informações sobre o conhecimento que se obteve no trabalho de extração. O parecer terá o resultado correspondente ao valor atribuído, única opção representada na última linha da tabela tab.4. Somente é permitida uma opção do rol das 27, em seguida, ponderada conforme tab.5, agrupada em 9 colunas (3 a 3). O cálculo ponderado resultará em um valor único no intervalo que varia de 2 a 72, observando as 27 colunas de possibilidades.

wpe6.jpg (11762 bytes)

tab.5: Resultado da Atribuição de Peso (opção única)

OBS.: (*)A atribuição de peso representada, refere-se ao requisito de nível operacional. Para o nível tático aplicar ( 6 5 4 9 8 7 3 2 1) e para o nível estratégico aplicar (3 2 1 6 5 4 9 8 7), podendo desta forma ser variável, como uma alternativa de reforçar o enfoque da qualificação funcional do requisito.

O passo seguinte é obter da pessoa, fonte de informação, o parecer do nível de exigência do requisito sob a ótica do ponto de vista próprio, conforme especificado no item 3.2 anterior. Cada parecer terá o resultado correspondente ao valor atribuído, única opção representada na última linha da tabela tab.2, ponderado conforme tab.6, agrupada em 9 colunas (3 a 3). O cálculo ponderado resultará em um intervalo que varia de 2 a 72.. Em seguida, efetuar a somatória de todas as opções por coluna. Da somatória do total de pareceres ponderados, obtém-se a média simples dividindo-se pelo número de pessoas participantes, por coluna, que é o resultado final.

wpe7.jpg (11685 bytes)

tab.6 - Resultado da Atribuição de Peso  

Parâmetros do Resultado da Aplicação do Modelo:

    a) na qualificação da fonte de informação

    1.caso - a média varia de 01 a 20

    2.caso - a média varia de 21 a 40

    3.caso - a média varia de 41 a 72

    b) na qualificação do requisito

1.caso - a média varia de 01 a 20

2.caso - a média varia de 21 a 40

3.caso - a média varia de 41 a 72

c) quadro comparativo de riscos

 

a) fonte de informação

b)requisito

01-20

21-40

41-72

01-20

alto

meio alto

meio baixo

21-40

meio alto

médio

baixo

41-72

meio baixo

baixo

baixo

tab.7: quadro avaliação risco

4 Contribuição na Área de Engenharia de Requisitos

Nas pesquisas realizadas sobre o assunto foram identificados vários artigos que abordam sobre a seleção de requisito a ser implementado: priorização de requisitos[6], seleção de requisitos[7], identificando conflitos e atributos de qualidade de requisitos[1] e medição de sucesso do processo de engenharia de requisitos[2].

Karlsson[6], trata sobre priorização de requisitos de software a partir da informação participativa do cliente. Utiliza-se de duas técnicas: a primeira, é de comparação de requisitos em pares (dois a dois),baseado no processo de hierarquia analítica (AHP Analytic Hierachy Process) que estabelece a seleção pelo grau de importância relativa do requisito num rol de requisitos, atribuído numa escala 1 a 9; a segunda, é de assinalamento numérico, baseada no princípio que cada requisito tem seu grau de importância absoluta, atribuído numa escala 1 a 5.

Karlsson & Ryan[7], tratam sobre seleção de requisitos de software com candidato prioritário para implementação, em virtude da escassez de recursos, tendo como determinante a satisfação do cliente. Utiliza a técnica AHP descrita acima para seleção de prioridade de requisito e sua importância em relação ao custo. O objetivo é gastar melhor o recurso optando pela seleção dos requisitos mais prioritários.

Bohem[1], trata como resolver conflitos e atributos de qualidade de requisito. Propõe identificar e negociar os conflitos, diagnosticando conflitos e atributos de qualidade sob uma base de conhecimento (ferramenta QARCC).

Emam[2], trata como mensurar o sucesso no processo de engenharia de requisitos, sob os aspectos de qualidade do produto e qualidade do serviço(sucesso e causas de falha). Apresenta uma lista de 34 critérios para assegurar o sucesso do processo de engenharia de requisitos.

Comparando com as contribuições pesquisadas, o modelo de qualificação proposto aproxima-se da abordagem de Karlsson & Ryan[6,7], na técnica de assinalamento numérico para enquadramento importância absoluta do requisito, no caso, o nível de exigência do requisito.

A proposta do modelo enfatiza a qualificação da fonte de informação e do requisito como um procedimento que precede à priorização ou seleção de requisito para implementação. Mesmo que o processo de extração de requisito seja de reuniões conjuntas, a proposta prevê uma participação individual e exclusiva do agente da informação ao emitir parecer e o resultado será apropriado para o rol de informações sobre o requisito e, comporá a média sobre a qual incidirá a ponderação que quantificará o grau de risco de representatividade do requisito. Entende-se que a meta é atingir uma participação e colaboração efetiva do maior número de representantes de fonte de informação que são afetados pelo requisito ou que o definem. Por esta razão, a qualificação da fonte de informação e das características do requisito durante o processo de extração, constitui-se fator essencial para a validação do requisito.

5 Vantagens e Limitações do Modelo Proposto

A expectativa das vantagens a serem obtidas com a aplicação prática do modelo é principalmente demonstrar os conflitos de interesses das pessoas na definição do problema no contexto organizacional. Com isto, possibilitar o estabelecimento de pontos de negociação de interesse essencial para a organização em detrimento dos interesses particulares de poder e domínio da informação. A forma de negociação é apresentar os resultados obtidos do processamento das informações relativos ao grau de risco apresentado e identificar os pontos que devem ser revistos antes de dar seqüência ao processo de desenvolvimento. Requisito válido é precondição para posterior priorização de implementação.

O modelo proposto restringe-se aos pontos declarados conforme apresentados na tab.1 e tab3. É pontual no que se refere à exigência de obrigatoriedade de preenchimento de todos os três níveis de quesitos, tanto para qualificação da fonte de informação cliente, como para o requisito.

Como trabalho futuro, além da aplicação prática do modelo para ajustes de atribuição de valor e ponderação, pretende-se, na seqüência, estender o estudo também aos requisitos não-funcionais e especificações que envolvem a solução do problema com a tecnologia de software, características de qualidade, expandindo áreas sombreadas no modelo da fig.3.

6 Conclusão

Como resultado da aplicação do modelo proposto espera-se a partir da qualificação da fonte de informação e seu grau de influência no contexto organizacional, bem como a qualificação do requisito, obter os índices comparativos de enquadramento dos parâmetros definidos para o modelo para validar os níveis de risco de implementação do requisito, sugerindo a revisão do processo de extração quando os indicativos alertarem abaixo da média.

Conclui-se que o documento final de requisitos deve ser realmente um objeto de contratação de produtos e/ou serviços com maior grau de certeza de aplicação e garantia de atendimento do cliente e, para isso, depende de requisitos válidos.

Referências Bibliográficas

[1] BOHEM, Barry; IN Hoh. Identifying quality-requirement conflicts. USA : IEEE Software, 1996. 11 p.

[2] EMAM, Khaled El; MADHAVJI, Nazim H. Measuring the success of RE processes. In: INTERNATIONAL SYMPOSIUM ON REQUIREMENTS ENGINEERING, 2., 1995, Los Alamitos. Proceedings. Los Alamitos : IEEE CSP, 1995. 3 p.

[3] GAUSE, Donald C., WEINBERG, Gerald M. Are your lights on? USA : Dorset , 1990. 157 p.

[4] GAUSE, Donald C., WEINBERG, Gerald M. Exploring requirements: quality before design. USA : Dorset, 1989. 300 p.

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

[6] KARLSSON, Joachim. Software requirements prioritizing. In: INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING, 2., 1996, Los Alamitos. Proceedings. Los Alamitos : IEEE CSP, 1996. 6 p.

[7] KARLSSON, Joachim; RYAN, Kevin. Supporting the selection of software requirements. In: INTERNATIONAL WORKSHOP SPECIFICATION AND DESIGN, 8., 1996, Los Alamitos. Proceedings. Los Alamitos : IEEE CSP, 1996. 4 p.

[8] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering: processes and techniques. England : John Wiley, 1998. 282 p.

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

[10] SOMMERVILLE, Ian; SAWYER, Pete. Requirements engineering: a good practice guide. England : John Wiley, 1997. 391 p.

[11] SOMMERVILLE, Ian; SAWYER, Pete; VILLER, S. Viewpoint for requirements elicitation: a practical approach. INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING , 3., 1998, Los Alamitos. Proceedings. Los Alamitos : IEEE CSP, 1998. 8 p.

[12] ZAVE, Pamela; JACKSON, Michael. Four dark corners of requirements engineering. ACM Association for Computing, v.6, n.1, p. 1-30, jan. 1997.