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.
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].
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).
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:
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.
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:
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.
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:
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.
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.
tab.5: Resultado da Atribuição de Peso (opção única)
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.
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
c) quadro comparativo de riscos
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
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
