Davi Viana, Rogério do Nascimento, Tayana Conte 2 Grupo de Pesquisa Usabilidade e Engenharia de Software

Transcrição

1 Avaliando uma Técnica para Extrair Requisitos a partir de Diagramas de Processos de Negócios através de Estudos Experimentais Sérgio Roberto Costa Vieira 1,2 1 Fundação Centro de Análise, Pesquisa e Inovação Tecnológica (FUCAPI) Av. Danilo Areosa, 381 Distrito Industrial Manaus-AM, Brasil sergio.vieira@fucapi.br Abstract In the area of requirements engineering there are elicitation techniques that are based on business context to identify the software requirements. However, these techniques do not commonly use business processes models as a source of information relevant to the elicitation of requirements. Such techniques extract use cases from business processes models. However, before modeling use cases, it is important to produce a document with functional and non-functional requirements and business rules. Therefore, this work proposes a new technique to aid extracting the requirements from business process diagrams: the REMO (Requirements Elicitation oriented by business process MOdeling) technique. This paper shows that, through the use of empirical studies, it was possible to obtain results that contributed to the evolution of the REMO technique. Additionally, the paper describes the qualitative analysis of the second empirical study, which used the procedures of two different methods: the Technology Acceptance Model (TAM) and Grounded Theory. Keywords: Requirements Elicitation; Business Process Modeling; Empirical Study; Technology Acceptance Model; Grounded Theory Resumo Na área de engenharia de requisitos existem técnicas de elicitação que são baseadas em contextos de negócios para identificar requisitos de software. Entretanto, estas técnicas não usam comumente os modelos de processos de negócios como uma relevante fonte de informação para a elicitação de requisitos. Essas técnicas extraem os casos de uso a partir dos modelos de processos de negócios. Porém, antes da modelagem de casos de uso, é importante produzir um documento com requisitos funcionais, requisitos não-funcionais e regras de negócios. Assim, este trabalho propõe uma nova técnica para auxiliar na extração de requisitos a partir de diagramas de processos de negócios: a técnica REMO (Requirements Elicitation oriented by business process MOdeling). Este artigo apresenta que, através do uso de estudos experimentais, foi possível obter resultados que contribuíram para a evolução da técnica REMO. Adicionalmente, o artigo descreve a análise qualitativa do segundo estudo experimental, o qual usou procedimentos de dois métodos diferentes: o Modelo de Aceitação de Tecnologia (TAM) e Grounded Theory. Palavras-chave: Elicitação de Requisitos; Modelagem de Processos de Negócios; Estudos Experimentais; Modelo de Aceitação de Tecnologia; Grounded Theory. I. INTRODUÇÃO Durante o desenvolvimento de software, uma das Davi Viana, Rogério do Nascimento, Tayana Conte 2 Grupo de Pesquisa Usabilidade e Engenharia de Software (USES) Universidade Federal do Amazonas (UFAM) Av. Rodrigo Otávio, 3000 Coroado I Manaus-AM, Brasil {davi.viana,rogerio,tayana}@icomp.ufam.edu.br atividades citadas como complexa e crítica é a elicitação de requisitos [3, 5, 14, 35]. De acordo com Vale et al.[31], a elicitação de requisitos tem como objetivo identificar os fatos que compõem os requisitos de um software, a fim de obter conhecimento de forma correta e completa sobre o domínio do problema. A maneira como a atividade de elicitação de requisitos é realizada influencia diretamente no produto de software que será entregue para o cliente [3]. Segundo De La Vara et al. [11] os requisitos de software são considerados os principais indicadores para o sucesso do projeto de desenvolvimento de software e podem contribuir fortemente para a qualidade do produto. Uma das formas de obter a qualidade do produto de software é realizar o seu desenvolvimento buscando entender claramente o domínio do negócio, considerando os processos de negócio como fonte relevante para a elicitação de requisitos [12]. De acordo com De La Vara et al. [10] e Xavier et al. [35] a comunidade de engenharia de requisitos tem reconhecido a importância do uso de conceitos de processos de negócios para orientar a elicitação de requisitos. Utilizar essa abordagem orientada a processos permite uma melhor compreensão da organização, além de ajudar a compreender as reais necessidades de sistemas para apoiar os processos de negócios [8]. Desta forma, o uso da modelagem de processos de negócios agrega benefícios para o desenvolvimento de software, tais como [1]: (i) os requisitos passam a refletir as necessidades do negócio; (ii) baixo número de redundâncias de requisitos e (iii) o desenvolvimento do software passa a ser guiado pela necessidade do negócio. Segundo Monsalve et al. [23] o desenvolvimento de software é dependente da qualidade das atividades que envolvem a elicitação de requisitos. Não adotar a modelagem de processos de negócios como subsídio para construir um produto de software pode trazer como conseqüências [35]: (i) requisitos incompletos em relação às necessidades do negócio; (ii) retrabalho e (iii) pode conduzir o projeto ao fracasso. Algumas abordagens de elicitação estão considerando os modelos de processos de negócios como o primeiro passo para desenvolver um software [10]. Os trabalhos [13, 15, 26] utilizam a modelagem de processos de negócios para identificar as funcionalidades que um software deve possuir. Porém, além das funcionalidades, faz-se necessário identificar os demais requisitos e regras de negócio que refletem as reais

2 necessidades para automatizar os processos. Por essa razão, foi elaborada a técnica REMO (Requirements Elicitation oriented by business process MOdeling), para apoiar a identificação de requisitos funcionais, não-funcionais e regras de negócio a partir dos modelos de processos. A técnica REMO propõe o uso de heurísticas para análise dos diagramas de processos de negócios modelados em BPMN (Business Process Modeling Notation). A partir da análise guiada pelas heurísticas são extraídos os requisitos de software. A abordagem empregada pela técnica REMO utiliza a modelagem de processos de negócios para compreender o contexto no qual o software irá funcionar, antes mesmo de identificar as funcionalidades. Após a definição da primeira versão da técnica REMO [33] foi realizado um estudo experimental para investigar a viabilidade de uso no desenvolvimento de software, comparada com uma abordagem tradicional [8]. Os resultados desse estudo não apontaram diferença significativa ao utilizar a técnica em relação ao número total de requisitos identificados [32]. Porém, a partir de dados qualitativos contendo a opinião dos participantes desse primeiro estudo, foram identificadas sugestões de mudanças. Essas sugestões foram analisadas e possibilitaram elaborar a segunda versão da técnica REMO. Neste artigo descreve-se a definição e evolução da técnica REMO, além de apresentar a condução de um novo estudo experimental executado para avaliar a viabilidade de uso da segunda versão da técnica. Este artigo mostra as abordagens que foram identificadas na literatura por meio de um mapeamento sistemático e apresenta como o segundo estudo experimental foi planejado, conduzido e como os resultados foram obtidos. Além da análise quantitativa, os resultados foram também analisados qualitativamente seguindo os procedimentos de dois diferentes métodos: o Modelo de Aceitação de Tecnologia (TAM) [9] e o método Grounded Theory (GT) [30]. A combinação destes procedimentos permitiu uma melhor compreensão sobre a percepção da técnica pelos participantes do estudo, além de sugerir aprimorála para uma nova versão. As próximas seções do artigo estão organizadas da seguinte forma: a Seção II apresenta uma análise das principais Trabalhos Bortoli e Price [6] Castro et al. [7] Martins e Daltrini [20] Estrada et al. [15] Santander e Castro [26] Martinez et al. [21] Cruz Neto et al. [24] TABELA I. características de abordagens de elicitação de requisitos baseadas em modelos de processos de negócios, coletadas a partir de um mapeamento sistemático da literatura. A Seção III descreve a técnica REMO e sua evolução após análise dos resultados do primeiro estudo experimental, além de discutir as mudanças realizadas para gerar a segunda versão da técnica. A Seção IV descreve o segundo estudo experimental conduzido para avaliar a técnica REMO (v2). Por fim, a Seção V expõe as conclusões do artigo e as perspectivas futuras. II. ABORDAGENS DE ELICITAÇÃO DE REQUISITOS BASEADA EM MODELOS DE PROCESSOS DE NEGÓCIOS A modelagem de processos de negócios tem como objetivo a formalização dos processos de uma organização. Seu propósito é capturar o contexto em que estes processos são executados, a fim de identificar suporte computacional para possibilitar automatização dos processos [8]. De acordo com Andrade et al. [1] o uso da modelagem de processos de negócios durante a elicitação dos requisitos, aumenta a compreensão sobre o domínio do negócio no qual o software irá funcionar. Considerando à importância da modelagem de processos para uma completa compreensão do negócio, recomenda-se a utilização de estratégias que visem um maior nível de conformidade dos requisitos de software associados às necessidades do negócio. Estas estratégias são conhecidas como abordagens de elicitação de requisitos orientada por modelos de processos de negócios. As abordagens de elicitação de requisitos baseadas em modelos de processos de negócios foram identificadas na literatura através de um mapeamento sistemático. Este mapeamento sistemático procurou investigar materiais relevantes sobre abordagens de elicitação de requisitos que utilizassem modelagem de processos de negócios. Esta pesquisa realizou buscas manuais nos anais do Workshop de Engenharia de Requisitos (WER) e buscas automatizadas nas bibliotecas da Compendex e da IEEE Xplore. A Tabela I apresenta os 16 artigos selecionados através do mapeamento sistemático. ABORDAGENS IDENTIFICADAS NA LITERATURA Descrição Apresentam um método de trabalho que utiliza diagramas de workflow para representar os processos de negócios. Este método é utilizado antes da definição dos requisitos do sistema de informação. A partir das representações dos processos por workflow, os engenheiros de requisitos conseguem definir os requisitos funcionais do sistema a ser construído. Utilizam o framework i* para capturar os requisitos iniciais seguindo um conjunto de orientações para construir o modelo de negócio organizacional, além de utilizar a UML juntamente com a linguagem textual OCL (Object Constraint Language) para capturar os requisitos finais. Descrevem uma proposta que tem por objetivo organizar o processo de elicitação de requisitos utilizando conceitos da Teoria da Atividade. Estes conceitos são utilizados no momento de elicitar os requisitos. Em seguida, o foco é direcionado para análise das atividades operacionais realizadas pelos usuários, isto permite identificar potencialmente requisitos do sistema de informação. Apresentam uma abordagem que consiste em realizar a aquisição de requisitos de software a partir da modelagem de processos de negócios, onde através de análise orientada a metas é construído um modelo de negócio seguindo os princípios do framework i*. Para adquirir o modelo de casos de uso, é realizado um refinamento do modelo de negócios por meio de mecanismo de árvore de metas, que tem por função identificar os tipos de metas e relacionar seus atores. Apresentam diretrizes que podem auxiliar o desenvolvimento de casos de uso em UML, sendo baseados em modelos de negócios organizacionais descritos pelo framework i*. Estas diretrizes são descritas para a identificação de atores a partir da modelagem organizacional. Em seguida, são apontadas diretrizes para a descoberta de cenários de possíveis casos de uso. Apresentam uma abordagem para derivar esquemas conceituais de sistemas de informação a partir de modelagem de negócios. O modelo de requisitos iniciais é adquirido por meio do uso de uma metodologia de desenvolvimento de software, denominada TROPOS, no qual adota os princípios do framework i*. Apresentam um método que possui um conjunto de diretrizes que realizam a transformação de diagramas de modelos de atividades, em modelos de negócios organizacionais, seguindo os princípios do framework i* no contexto de desenvolvimento da metodologia

3 Trabalhos Shi et al. [28] Villanueva et al. [34] Dias et al. [13] Gonzalez et al. [16] Mayr et al. [22] Retamal et al. [25] Hadad et al. [17] Santos et al. [27] Xavier et al. [35] Descrição TROPOS. Esta metodologia é utilizada para a identificação de casos de uso no desenvolvimento de software. Propuseram a utilização de uma plataforma orientada a processos, no qual tem como principal objetivo capturar informações do domínio do negócio e transformá-las em conhecimentos do ponto de vista da área de TI sobre a visão interna dos processos de uma organização. Esta plataforma foi denominada S-BMW (Service-Oriented Business Modeling Workbench). Apresentam um modelo de gestão orientado a processos EFQM (European Foundation for Quality Management) com o objetivo de guiar o levantamento de requisitos. Este modelo permite a associação de aspectos organizacionais com requisitos do sistema. Apresentam uma abordagem que permite transformar modelos de processos de negócios, utilizando a ferramenta gratuita RAPIDS (Rules And Processs for the Development of Information Systems), em modelos de requisitos representados por diagramas de casos de uso e diagramas de classes de domínio. Descrevem uma abordagem para criar um modelo de processos de negócios no padrão de notação BPMN. O objetivo da abordagem deste trabalho possibilita gerar um modelo de requisitos usando como uma etapa auxiliar a elaboração de árvore de metas, para assim identificar e definir as funções do sistema de acordo com as metas e processos. Discutem uma proposta de uma linguagem de modelagem de processos de negócios, denominada como KCPM (Klagenfurt Conceptual Pré-Design Model), que pode ser utilizada a partir de um esquema de fluxo de trabalho representado por um diagrama de atividades UML para identificação de requisitos. Discutem uma forma de criar um modelo de processos de negócios seguindo o padrão de modelagem BPMN baseado em heurísticas, no qual tentam direcionar o foco para um modelo de negócio voltado para tomada de decisão. Os autores afirmam que este modelo pode ser usado como complementar para especificar casos de uso. Apresentam uma estratégia que possibilita criar um documento de requisitos, tendo como ponto de partida os cenários já construídos. Esta estratégia possui atividades envolvidas no processo que fazem parte do modelo SADT (Structured Analisys and Design Technique), no qual compreende as etapas de: gerar uma lista de requisitos; atribuir requisitos; organizar os requisitos em um documento de requisitos, e como etapa final, realiza uma verificação de consistência do documento de requisitos. Apresentam uma abordagem denominada GV2BPMN (Meta-Análise Orientada a Variabilidade BPMN), no qual o foco é mostrar a variabilidade de um modelo de processos de negócios existente, criado com modelagem por metas, visando criar um meta-modelo que represente as variantes dos processos de negócios do modelo BPMN anterior. Apresentam o framework BPMNFR, uma extensão do padrão de modelagem BPMN que visa integrar os requisitos não-funcionais ao BPMN. O framework BPMNFR ajuda na construção do modelo de processos de negócios, identifica os requisitos não-funcionais através de rótulos e cria um catalogo de requisitos. A partir do estudo desses trabalhos foi realizada uma análise das características de cada abordagem identificada. Esta atividade consistiu na elaboração de uma tabela comparativa das características que cada abordagem possui. As características analisadas são apresentadas a seguir: C1: Processo Definido - Durante a apresentação da abordagem são descritas as etapas que devem ser seguidas para o uso da mesma. C2: Decomposição dos Processos de Negócios - A modelagem de processos de negócios em questão permite uma decomposição dos processos em ações e operações. C3: Foco na Identificação dos Requisitos A abordagem apresentada auxilia a identificar requisitos funcionais, requisitos não-funcionais, casos de uso ou não há uma descrição clara. C4: Flexibilidade dos Modelos - Permite ser aplicada em contextos que já possuem uma modelagem de processos de negócios criada. C5: Adoção de um Documento de Requisitos - A abordagem adota a elaboração de um documento ou uma lista de requisitos após a modelagem dos processos. C6: Identificação das Necessidades A abordagem identifica ou gera uma lista de quais são as reais necessidades do cliente que devem ser automatizadas. Diante destas características foi realizada uma análise comparativa entre as abordagens apresentadas na Tabela II. A partir desta análise, observou-se uma lacuna a ser analisada com maior atenção, vista a partir da característica C5 sobre a adoção de um documento de requisitos. Esta análise permitiu identificar que apenas o trabalho de Hadad et al. [17] realizava a adoção de um documento de requisitos. Porém a proposta dos autores utilizava como fonte de informação cenários criados a partir dos processos de negócios, e não os diagramas de processos de negócios. Alguns trabalhos apresentaram abordagens que identificavam apenas um tipo de requisito, outros apenas direcionavam como uma fonte para possível identificação de requisitos. Esta análise mostrou que apenas o trabalho de Castro et al. [7] permitia identificar requisitos funcionais e não-funcionais. Das demais abordagens seis trabalhos propuseram abordagens que identificavam casos de uso baseados nos modelos de processos de negócios, estas análises foram todas observadas a partir da característica C3. Entretanto, considerase relevante gerar um documento com os requisitos funcionais, não-funcionais e possíveis regras de negócios antes de realizar a modelagem dos casos de uso, pois o documento de requisitos deve expressar os resultados desejados pelo cliente [29]. Desta forma, decidiu-se elaborar uma nova técnica que apoiasse a extração de requisitos a partir dos diagramas de processos de negócios, antes de modelá-los como casos de usos do sistema. A próxima seção descreve a definição e evolução da técnica. TABELA II. ANÁLISE DAS CARACTERÍSTICAS DAS ABORDAGENS TRABALHOS C1 C2 C3 C4 C5 C6 Bortoli e Price [6] S S RF N N N Castro et al. [7] S S RF/RNF N N N Martins e Daltrini [20] S S N N N S Estrada et al. [15] S S CSU N N S Santander e Castro [26] S N CSU N N N Martinez et al. [21] N N N N N S Cruz Neto et al. [24] S S N N N N Shi et al. [28] S N N S N N Villanueva et al. [34] S N CSU N N S Dias et al. [13] S S CSU N N N Gonzalez et al. [16] S N CSU N N S Mayr et al. [22] S N N S N N Retamal et al. [25] N S CSU N N N Hadad et al. [17] S N RF N S S Santos et al. [27] S N RNF S N N Xavier et al. [35] N S RNF S N S Legenda: S sim; N não; RF requisito funcional; RNF requisito nãofuncional; CSU caso de uso;.

4 III. DEFINIÇÃO E EVOLUÇÃO DA TÉCNICA REMO A técnica REMO (Requirements Elicitation oriented by business process MOdeling) consiste em uma técnica de elicitação de requisitos orientada pela modelagem de processos de negócios, a qual utiliza heurísticas para extrair requisitos de software a partir dos diagramas de processos de negócios. Tem como principal objetivo auxiliar os analistas responsáveis pelo desenvolvimento do software a extraírem os requisitos a partir dos diagramas de processos de negócios. O propósito da técnica é utilizar a modelagem de processos de negócios como fonte de informação relevante para extrair os requisitos do software. Ao utilizar a técnica REMO conforme mostra a Figura 1, o analista deverá primeiramente usar os diagramas de processos de negócios modelados em BPMN como uma pré-condição para compreender o contexto para o qual o software será desenvolvido. Em seguida, o analista irá utilizar um conjunto de heurísticas da técnica REMO para extrair os requisitos funcionais, requisitos não-funcionais e regras de negócios. Por fim, o analista irá obter uma listagem com os reais requisitos do software. H1.2 Documentos utilizados nas Atividades dos Processos (a) Identifique as atividades que possuem documentos; (b) Verifique se neste documento há alguma anotação de dados obrigatórios; (c) Descrever a obrigatoriedade destes dados no requisito. H2 - Requisitos Não-Funcionais H2.1 Atividades que possuem Restrições (a) Identifique a atividade; (b) Identifique o evento de restrição e faça uma análise para verificar, se é possível extrair um requisito não funcional. H2.2 Atividades com Atributos de Qualidade (a) Identifique a atividade; (b) Identifique o evento de exceção ou alguma anotação associada a atividade; (c) Faça uma análise para verificar, se é possível extrair um atributo de qualidade; (d) Se for possível, transforme em um requisito não funcional. Cada heurística possuía um exemplo de aplicação, mostrando uma instância de um requisito extraído a partir do diagrama de processos de negócios. A Figura 2 apresenta um exemplo de uma heurística da versão inicial da técnica REMO: Figura 1. Processo de aplicação das heurísticas da técnica REMO. A. Proposta Inicial da Técnica REMO Na versão inicial, a técnica REMO foi composta de heurísticas com instruções para guiar o analista de sistemas durante a elicitação, baseadas em ações contidas nos diagramas de processos de negócios. Para a versão inicial da técnica REMO foram elaboradas oito heurísticas: seis para identificação de requisitos funcionais e duas para identificação dos requisitos não-funcionais, conforme parcialmente é mostrado na Tabela III. A descrição detalhada das heurísticas desta versão inicial da técnica encontra-se disponível em [33]. TABELA III. H1 - Requisitos Funcionais RELAÇÃO DAS HEURÍSTICAS DA TÉCNICA REMO (V1) H1.1 Operações do Processo (a) Identifique as atividades; (b) Para cada atividade, verifique se ela pode se tornar uma ação do software; (c) Se for possível, transforme em um requisito funcional. (d) Analise se para esta atividade, existe alguma exigência de dados obrigatórios. Figura 2. Exemplo de heurística da versão inicial da técnica. A descrição detalhada de mais exemplos de aplicação das heurísticas da técnica REMO pode ser vista em [33]. B. Primeiro Estudo Experimental O primeiro estudo experimental foi realizado com o objetivo de avaliar a viabilidade de uso da técnica para identificação dos requisitos a partir dos diagramas de processos de negócios. Este estudo foi conduzido no período de Maio de 2011, o qual contou com a participação de alunos de graduação da UFAM no lugar de analistas de sistemas. Todos os alunos receberam treinamento e praticaram exercícios sobre elicitação de requisitos e modelagem de processos de negócios. Estes participantes realizaram uma elicitação de requisitos a partir da modelagem de processos de negócios, a fim de comparar os resultados obtidos com o uso

5 da técnica e com uso de uma abordagem tradicional. Estes participantes foram divididos em dois grupos, os quais realizaram o estudo em dias distintos. Na execução do estudo os participantes receberam o roteiro de execução de tarefas e os instrumentos necessários para realização do estudo. Após a execução do estudo, os requisitos identificados foram coletados e registrados em planilhas separadas por grupo de participantes. Estes requisitos foram integrados em uma única lista para realizar a discriminação dos requisitos. Em seguida, realizou-se a reunião de discriminação com a participação do analista responsável do sistema. A análise quantitativa apoiada pelo método estatístico Mann-Whitney apontou que a técnica REMO apresentou resultado similar comparada com a abordagem tradicional. O resultado obtido em relação ao indicador de eficácia dos requisitos (p=0857 e α = 0.05) apoiou a hipótese nula H01 apresentando que não houve diferença significativa entre as duas abordagens utilizadas. Em relação ao indicador de adequação dos requisitos o resultado obtido (p=0.106 α = 0.05), suportou a hipótese alternativa HA2 mostrando que houve uma diferença significativa no percentual de requisitos adequados. A Tabela IV sumariza um resumo dos resultados quantitativos deste estudo. A descrição detalhada da análise quantitativa encontra-se disponível em [32]. TABELA IV. RESULTADOS SUMARIZADOS DO 1º. ESTUDO EXPERIMENTAL 1. Grupo (TRADICIONAL) 2. Grupo (REMO) Requisitos Identificados Média dos Requisitos por Participantes 11,23 11,92 Falsos Positivos Média de Eficácia em % 38,73% 41,11% Média de Adequação dos requisitos em % 49,33% 58,13% C. Segunda Versão da Técnica REMO A análise dos resultados quantitativos e qualitativos do primeiro estudo experimental apresentados em [32], permitiu aplicar melhorias e sugestões de modificações, as quais resultaram em uma nova versão da técnica REMO. A seguir descreve-se algumas modificações que permitiram evoluir a técnica. Com o propósito de tornar as heurísticas mais objetivas, na segunda versão da técnica a abordagem utilizada foi modificada. Os analistas passaram a identificar primeiramente os elementos do conjunto BPMN para depois aplicar as heurísticas e obter os requisitos. A Figura 3 ilustra a diferença das modificações que foram feitas na nova versão da técnica. Além destas modificações realizadas para elaboração da segunda versão da técnica REMO, outras modificações foram realizadas para aprimorá-la, como: organização da ordem de aplicação das heurísticas; identificação de novas heurísticas que não eram contempladas na versão anterior; mudança no nome das heurísticas e, redução no texto das instruções, tornando-as mais claras e diretas para a obtenção dos requisitos. A segunda versão da técnica contempla um conjunto de nove heurísticas, classificadas de acordo com o tipo de requisito que se espera identificar. Figura 3. Exemplo da evolução da técnica REMO. Na segunda versão da técnica, os analistas identificam primeiramente os elementos da notação BPMN. Em seguida, é feita a aplicação das instruções de cada heurística para obter os requisitos, podendo ser: RF Requisito Funcional, RNF Requisito Não-Funcional ou RN Regra de Negócio. As modificações aplicadas resultaram na segunda versão da técnica REMO, conforme mostra parcialmente na Tabela V. A descrição detalhada das heurísticas da técnica encontra-se disponível em [33].

6 TABELA V. RELAÇÃO DAS HEURÍSTICAS DA TÉCNICA REMO (V2) ELEMENTOS HEURÍSTICAS INSTRUÇÕES Tarefa Gateway ou Decisão Evento de Mensagem Evento de Condicional H1 Atividades / Tarefas do Processo H2 Condições de Decisão H3 Eventos de Mensagens / Comunicados H4 Eventos Condicionais RF Transforme em um requisito funcional (RF), caso a atividade/tarefa possa / deva tornarse uma ação do sistema; RNF Descreva como um requisito não-funcional (RNF), caso a atividade / tarefa possua restrições para ser realizada. RF Verifique se é necessário descrever um ou mais RF, a partir da condição identificada. RN Identifique qual/quais regras de negócios (RN) podem ser atendidas, relacionada ou não ao requisito. RF Verifique se é necessário descrever o envio da mensagem como um RF. RNF Para cada mensagem que deverá ser exibida pelo sistema, verifique se é necessário descrever um RNF para o seu tempo de resposta. RN Descreva como uma RN a condição que deve ser atendida pelo evento condicional. Como foi descrito anteriormente, uma das modificações realizadas diz respeito a criação de um exemplo de aplicação para cada heurística. A Figura 4 apresenta um exemplo de aplicação da segunda versão das heurísticas da técnica REMO. Figura 4. Exemplo de aplicação da técnica REMO (v2). A descrição detalhada das heurísticas e demais exemplos de aplicação da segunda versão da técnica REMO podem ser vistos em [33]. Após a definição da segunda versão da técnica foi realizado um segundo estudo experimental para avaliar se as modificações iriam tornar a técnica viável em relação ao indicador de eficácia dos requisitos, além de medir o indicador de adequação dos requisitos neste segundo estudo. A seguir é apresentado o segundo estudo experimental. IV. SEGUNDO ESTUDO EXPERIMENTAL O principal objetivo desse estudo foi investigar a viabilidade da técnica REMO em apoiar a identificação de requisitos. Isto foi medido através de dois indicadores quantitativos: Eficácia: consiste na razão entre o número de requisitos reais identificados pelo total de requisitos conhecidos a partir dos modelos de processos de negócios; Adequação: corresponde ao percentual de requisitos apontados como adequados ao contexto de processos de negócios. Esse indicador foi considerado relevante para evitar a descrição de possíveis requisitos que na realidade não se aplicam ao contexto de desenvolvimento do software. Na abordagem utilizada pela técnica REMO, o analista identifica requisitos a partir dos elementos BPMN. No entanto, fez-se necessário verificar se as heurísticas não induziam a sugestão de requisitos desnecessários. Por este motivo o indicador de adequação relata o percentual de requisitos adequados que estão em conformidade com as necessidades identificadas a partir dos processos de negócios. Para permitir uma análise qualitativa da técnica, foi definido adicionalmente um terceiro indicador: Opinião subjetiva do analista sobre a viabilidade de aplicação da técnica REMO. Segundo Laitenberger e Dreyer [19], investigar a aceitação dos usuários para uma tecnologia requer um modelo que explique as atitudes e comportamentos das pessoas. Desse modo, buscou-se operacionalizar este indicador através de dois fatores com base no Modelo de Aceitação de Tecnologia TAM (Technology Acceptance Model) [9]: (1) Percepção sobre utilidade (Perceived usefulness) e, (2) Percepção sobre facilidade de uso (Perceived ease of use). A. Planejamento do Estudo O objetivo do estudo foi elaborado segundo os princípios do paradigma GQM (Goal Question Metric) [4], conforme descrito na Tabela VI. Analisar TABELA VI. Com o propósito de Em relação à Do ponto de vista de No contexto de OBJETIVO DO 2 O. ESTUDO EXPERIMENTAL A segunda versão da técnica REMO Caracterizar Eficácia e Adequação dos requisitos identificados a partir dos processos de negócios em BPMN, em comparação com uma abordagem tradicional. Pesquisadores em Engenharia de Software Uma elicitação de requisitos baseada em modelos de processos de negócios realizada por alunos de graduação As respectivas hipóteses, nula e alternativa, definidas para este estudo relacionadas aos indicadores de eficácia e adequação são: H01: Não existe diferença em relação à eficácia da técnica REMO comparada com a abordagem tradicional.

7 o HA1: Existe diferença entre o índice de eficácia da técnica REMO e o índice de eficácia da abordagem tradicional. H02: Não existe diferença em relação à adequação dos requisitos identificados com apoio da técnica REMO comparada com a abordagem tradicional. o HA2: Existe diferença entre o número de requisitos considerados adequados identificados tanto pela técnica REMO quanto pela abordagem tradicional. O estudo ocorreu em Novembro de 2011 e os participantes foram alunos do 6º semestre do curso de Ciência da Computação da UFAM. Os participantes do estudo assumiram o papel de analistas de sistemas. No total 20 alunos concordaram em participar do estudo, estes foram divididos em dois grupos de dez participantes balanceados conforme seu nível de conhecimento sobre desenvolvimento de software e elicitação de requisitos. O modelo de processo de negócio escolhido foi parte dos processos da Secretaria Acadêmica do Instituto de Computação da UFAM. Este modelo havia sido elaborado por outro especialista em modelagem de processos de negócio não envolvido no desenvolvimento da técnica REMO. O modelo foi analisado previamente por dois profissionais para a identificação da lista de requisitos que foi utilizada como oráculo. Este oráculo foi utilizado para fazer a discriminação dos requisitos que seriam considerados como inadequados (falso positivos). Para realizar a elicitação dos requisitos foi definido um roteiro de execução contendo cinco tarefas a serem desempenhadas pelos participantes: compreender a modelagem de processos de negócio feita em BPMN; identificar os requisitos funcionais; identificar os requisitos não-funcionais; identificar as regras de negócios; e, revisar a identificação dos requisitos. No roteiro de execução do grupo que utilizou a técnica REMO, foi solicitado que aplicasse as heurísticas para a identificação dos requisitos. Todos os participantes receberam treinamentos sobre os conceitos de modelagem de processos de negócios, sobre a notação BPMN e uma revisão de elicitação de requisitos. A apresentação das heurísticas para os participantes que iriam fazer uso da técnica foi realizada somente no dia do estudo, com o intuito de minimizar o viés dos participantes se comunicarem entre os grupos. B. Execução do Estudo Os participantes realizaram o estudo em salas distintas, cada grupo teve um tempo livre de 180 minutos para realizar a elicitação dos requisitos. A coleta dos requisitos identificados foi registrada em planilhas separadas por participantes, onde cada lista de requisitos foi unificada em única lista por grupo. Após a coleta dos dados foi feita a discriminação dos requisitos, onde foram identificados os requisitos equivalentes a lista do oráculo. Em seguida, foi feita a identificação dos requisitos considerados como inadequados por um pesquisador especialista nos processos de negócios utilizados no estudo. Após a discriminação dos requisitos foi realizada a análise quantitativa, descrita detalhadamente em [32]. A seguir é apresentado um resumo destes resultados. Foi utilizado o método estatístico Mann-Whitney. Os resultados apontaram que técnica REMO foi mais efetiva que a abordagem tradicional em relação ao indicador de adequação dos requisitos (p=0.162 e α = 0.05). Este resultado refutou a hipótese nula H02, mostrando que houve uma diferença entre a técnica e a abordagem tradicional em relação ao número de requisitos considerados como adequados ao contexto dos processos de negócios. No entanto, em relação ao indicador de eficácia dos requisitos, os resultados mostraram que a técnica REMO manteve-se similar a abordagem tradicional, não apresentando uma diferença significativa nos resultados (p=0.850 e α = 0.05). Este resultado sustentou a hipótese nula H01, demonstrando que não houve diferença significativa entre a técnica e abordagem tradicional em relação à eficácia dos requisitos. A Tabela VII sumariza os resultados deste segundo estudo, mais detalhes da análise quantitativa podem ser vistos em [32]. TABELA VII. RESULTADO SUMARIZADO DO 2º. ESTUDO EXPERIMENTAL 1. Grupo (TRADICIONAL) 2. Grupo (REMO) Requisitos Identificados Média dos Requisitos por Participantes 33,9 33,0 Falso Positivos Média de Eficácia em % 22,30% 21,71% Média de Adequação dos Requisitos em % 77,15% 84,39% Após o relato da análise quantitativa em [32], foi feita nova análise, dessa vez qualitativa, tendo por base os dados coletados no questionário pós-experimento. Os resultados da análise qualitativa são descritos a seguir. C. Análise segundo o Modelo de Aceitação de Tecnologia A fim de verificar a opinião subjetiva dos participantes em relação à viabilidade da técnica, aplicou-se um questionário baseado no Modelo de Aceitação de Tecnologia (TAM) [9]. Investigou-se a aceitação da técnica sobre a percepção de dois fatores: Facilidade de Uso e Utilidade. O grupo que utilizou a técnica REMO respondeu um questionário pós-experimento contendo seis questões, dentro de uma escala de quatro opções: (i) sim em todas as vezes, (ii) sim em boa parte das vezes, (iii) não em boa parte das vezes e (iv) não em nenhuma das vezes. Não foi utilizada uma escala de sete pontos contendo um valor neutro intermediário pois, segundo Laitenberger e Dreyer [19] este valor neutro não fornece informações sobre para qual direção o participante está inclinado (concordar ou discordar). A Figura 5 mostra as respostas dos participantes sobre a percepção de Facilidade de Uso da técnica. É possível perceber que todos os participantes concordaram que a técnica REMO foi fácil de ser aplicada durante a elicitação de requisitos. Isto permite afirmar que as mudanças realizadas contribuíram para a facilidade de uso das heurísticas da técnica. A Figura 6 apresenta as respostas dos participantes avaliando a técnica sob a percepção de Utilidade. Houve um participante que discordou parcialmente em relação às heurísticas serem utilizadas para aumentar a produtividade do

8 trabalho e houve um participante que discordou parcialmente com relação às heurísticas serem úteis durante a elicitação de requisitos. Essa resposta está de acordo com o desempenho desses participantes durante o estudo, pois eles apresentaram baixa eficácia em relação ao número de requisitos identificados. Figura 5. Respostas relacionadas a percepção de Facilidade de Uso. Figura 6. Respostas relacionadas a percepção de Utilidade. D. Utilizando os procedimentos do Método Grounded Theory Para a análise qualitativa das causas que influenciaram na aceitação da técnica, utilizou-se procedimentos do método Grounded Theory [30]. O método Grounded Theory (Teoria Fundamentada em Dados) usa procedimentos sistemáticos de coleta e análise de dados para gerar, preparar e validar teorias substantivas sobre fenômenos essencialmente sociais [30]. As teorias substantivas são específicas para um dado grupo ou situação, e não visam generalizações além de sua área de aplicação [30]. Embora o objetivo do Método GT seja a construção de teorias substantivas, seu uso não precisa necessariamente ficar restrito a este objetivo de pesquisa. De acordo com Strauss e Corbin [30], o pesquisador pode usar apenas alguns de seus procedimentos para cumprir as metas de uma pesquisa. A análise dos dados coletados foi feita utilizando procedimentos de codificação, com o software Atlas TI1 como ferramenta de apoio. Foram criados códigos a partir das citações (quotations) dos questionários. Em seguida, os códigos foram agrupados em três categorias para melhor análise da percepção sobre a técnica: Pontos Positivos, Dificuldades e Sugestões de Melhoria. 1 Site:

9 Os resultados obtidos com os procedimentos de codificação permitiram visualizar quais as principais dificuldades que impactaram no uso da técnica durante a realização do estudo. Os códigos relacionados às dificuldades estão relacionados aos dados obtidos através do questionário do modelo TAM. As principais dificuldades encontradas durante a elicitação foram: dificuldade em encontrar requisitos não-funcionais, não lembrar como aplicar as heurísticas durante a elicitação e falta de clareza em algumas descrições e exemplos. Em relação à percepção de utilidade da técnica, foi mencionado que houve dificuldades em encontrar requisitos não-funcionais e em lembrar como aplicar as heurísticas. Isto está relacionado à produtividade na elicitação dos requisitos. A Figura 7 apresenta a codificação da categoria das Dificuldades. Figura 7. Codificação das dificuldades apontadas com uso da Técnica. Os participantes também fizeram sugestões para a evolução da técnica, como: Apresentar mais heurísticas para outros símbolos BPMN. Estas sugestões estão sendo analisadas para a evolução da técnica REMO e criação de sua terceira versão (v3). E. Ameaças à Validade do Estudo Em todos os estudos experimentais existem ameaças que podem afetar a validade dos resultados. As ameaças relacionadas ao estudo são apresentadas a seguir: Validade Interna: para este tipo de validade identificouse como um risco para uma interpretação equivocada dos resultados, a classificação de experiência dos participantes. Esta ameaça teve seu impacto minimizado através da aplicação de um formulário para caracterizar o perfil de conhecimento de cada participante a partir de experiências práticas (número de projetos) em desenvolvimento de software e elicitação de requisitos, permitindo-se dividir os grupos de forma balanceada. Validade Externa: foram consideradas duas ameaças: (a) a participação de alunos de graduação no lugar de analistas de sistemas da indústria e (b) a utilização de um ambiente acadêmico que não simula totalmente o contexto de um ambiente industrial. Em relação a ameaça (a), boa parte dos alunos participantes já possuíam experiência em desenvolvimento e/ou elicitação em projetos da indústria. Outros estudos já demonstraram que a diferença de desempenho entre estudantes e analistas não é muito grande [18]. E em relação ao contexto do estudo, foi utilizado um diagrama de processos de negócio real. Validade de Conclusão: o maior problema é o tamanho da amostra, com um número pequeno de data points, não ideal do ponto de vista estatístico. Devido a este fato, há limitação nos resultados, sendo estes considerados não conclusivos, e sim indícios. Validade de Constructo: referente a este tipo de ameaça de validade, considerou-se a definição dos indicadores. Os indicadores adotados neste estudo - Eficácia e Adequação representam aspectos importantes ao se elicitar requisitos: qual o percentual de requisitos identificados e se eles são adequados ao cenário. Os resultados da análise qualitativa irão permitir aplicar novas mudanças na técnica, a fim de aprimorar o seu uso durante a elicitação de requisitos. A próxima seção descreve as conclusões finais. V. CONCLUSÕES Este artigo apresentou a proposta da técnica REMO e sua evolução a partir de avaliações feitas através de estudos experimentais. A técnica visa auxiliar analistas de sistemas a extrair requisitos de software a partir de diagramas de processos de negócios, utilizando um conjunto de heurísticas. Este artigo descreveu a análise qualitativa dos resultados de um estudo experimental que teve como objetivo verificar a viabilidade da técnica no contexto de uma elicitação de requisitos, comparada com uma abordagem tradicional. Este estudo experimental apontou que a técnica contribui para a identificação de requisitos adequados ao contexto dos processos de negócios. Deste modo, a técnica torna-se relevante para o desenvolvimento de software, evitando a aplicação de esforços dos analistas de sistemas em encontrar requisitos inadequados (falso positivos). Em relação à eficácia, a técnica REMO apresentou resultados equivalentes a abordagem tradicional. A análise qualitativa permitiu identificar as dificuldades percebidas pelos participantes ao se aplicar a técnica REMO. As causas destas dificuldades, assim como as sugestões feitas pelos participantes, estão sendo tratadas para a evolução da técnica para a sua terceira versão. Após a elaboração da terceira versão da técnica REMO (v3), esta será avaliada por um novo estudo experimental, visando identificar como os analistas aplicam a técnica. Como trabalho futuro, pretende-se propor uma extensão da técnica para que compreenda outras notações de modelagem de processos, como, por exemplo, o framework i* [36]. Adicionalmente, outra perspectiva futura é a realização de um experimento com uma amostra de profissionais da indústria de software, a fim de avaliar como se comportam os indicadores de eficácia e adequação dos requisitos, quando a técnica é utilizada por profissionais. A técnica REMO visa contribuir para uma melhor qualidade dos requisitos, permitindo que o analista de sistema possa identificar requisitos mais apropriados ao contexto dos processos de negócios. A técnica REMO utiliza a modelagem de processos de negócios como uma fonte de informação relevante a ser considerada durante a elicitação de requisitos. Desta forma, espera-se motivar a indústria de software a fazer uso da modelagem de processos de negócios como uma fonte

10 de informação relevante para o desenvolvimento de software, a fim de obter um produto de software com maior qualidade. AGRADECIMENTOS Agradecemos a todos os alunos da UFAM que participaram dos estudos experimentais apresentados. Agradecemos também pelo apoio financeiro da FUCAPI ao primeiro autor do artigo. REFERÊNCIAS [1] A. Andrade, A. Ribeiro, E. Borges, W. Neves. Um estudo de aplicação de modelagem de processo de negócio para apoiar a especificação de requisitos de um sistema, In: VI SIMPROS Simpósio Internacional de Melhoria de Processos de Software, São Paulo, 2004, pp [2] R. Bandeira-de-Mello, C. Cunha. Operacionalizando o método da Grounded Theory nas Pesquisas em Estratégia: técnicas e procedimentos de análise com apoio do software ATLAS/TI, In: 3Es - Encontro de Estudos em Estratégia (Anpad), Curitiba-Paraná, [3] G. Barbosa, M. Werneck, H. Assis, U. Fernandes, I. Silva. Um processo de Elicitação de Requisitos com foco na seleção da Técnica de Elicitação, In: VIII Simpósio Brasileiro de Qualidade de Software, 2009, pp [4] V. Basili, H. Rombach. The TAME Project: Towards Improvement- Oriented Software Environments, In: IEEE Transactions on Software Engineering, vol.14, 1988, pp [5] A. Belgamo, L. E. G. Martins. Estudo Comparativo sobre as Técnicas de Elicitação de Requisitos do Software, In: XX Congresso Brasileiro da Sociedade Brasileira de Computação (SBC), Curitiba Paraná, [6] L. A. de Bortoli, A. M. de A. Price. O Uso de Workflow para Apoiar a Elicitação de Requisitos. In: WER - Workshop de Engenharia de Requisitos, Rio de Janeiro, 2000, pp [7] J.F. Castro, F.M. Alencar, G.A. Filhol, J. Mylopoulos. Integrating organizational requirements and object oriented modeling. In: Requirements Engineering (RE), Fifth IEEE International Symposium on, Toronto, Canadá, 2001, pp [8] E. C. S. Cardoso, J. P. A. Almeida, G. Guizzardi. Requirements Engineering Based on Business Process Models: A Case Study, In: Enterprise Distributed Object Computing Conference Workshops 13th, EDOCW/IEEE, Auckland, New Zealand, 2009, pp [9] F. Davis. Perceived usefulness, perceived ease of use, and user acceptance of information technology. In: MIS Quarterly, v. 13, n. 3, 1989, pp [10] J. L. De la Vara, J. Sánchez, O. Pastor. Business Process Modelling and Purpose Analysis for Requirements Analysis of Information Systems. In: CAiSE - 20 th International Conference on Advanced Information Systems Engineering. 2008, pp [11] J. L. De la Vara, K. Wnuk, R. Berntsson-Svensson, J. Sánchez, B. Regnell. An Empirical Study on the Importance of Quality Requirements in Industry. In: 23 rd International Conference on Software Engineering and Knowledge Engineering, Miami, 2011, pp [12] O. Demirors, C. Gencel, A. Tarhan. Utilizing Business Process Models for Requirements Elicitation. In: 29 th EUROMICRO Conference. IEEE Computer Society, Washington, DC, USA, 2003, pp [13] F. Dias, G. Morgado, P. Oscar, D. Silveira, A. J. Alencar, P. Lima, E. Schmitz. Uma Abordagem para a Transformação Automática do Modelo de Negócio em Modelo de Requisitos. In: WER - Workshop de Engenharia de Requisitos, Rio de Janeiro, 2006, pp [14] O. Dieste, M. Lopez, F. Ramos. Updating a Systematic Review about Selection of Software Requirements Elicitation Techniques. In: Workshop de Engenharia de Requisitos, Barcelona, Espanha, 2008, pp [15] H. Estrada, A. Martinez, O. Pastor, J. Ortiz, O. Rios. Generación de Especificaciones de Requisitos de Software a Partir de Modelos de Negocios: Um Enfoque. In: WER - Workshop de Engenharia de Requisitos, Valência, Espanha, 2002, pp [16] J. L. de L. V. González, D. A. Alcolea, J. S. Díaz. Descomposición de árboles de metas a partir de modelos de procesos. In: WER - Workshop de Engenharia de Requisitos, Toronto, Canadá, 2007, pp [17] G. Hadad, J. Doorn, G. Kaplan. Explicitar Requisitos del Software usando Escenarios. In: Workshop de Engenharia de Requisitos, Valparaíso, Chile, 2009, pp [18] M. Höst, B. Regnell, B. and C. Wohlin. Using Students as Subjects - A Comparative Study of Students and Professionals in Lead-Time Impact Assessment. Emp. Soft. Engineering, Vol. 5, No. 3, 2000, pp [19] O. Laitenberger, H. M. Dreyer. Evaluating the Usefulness and the Ease of Use of a Web-based Inspection Data Collection Tool. In: Software Metrics Symposium Fifth International Proceedings, Bethesda, MD, 1998, pp [20] L. E. G. Martins, B. M. Daltrini. Organizando o Processo de Elicitação de Requisitos Utilizando o Conceito de Atividade. In: Workshop de Engenharia de Requisitos, Buenos Aires, Argetina, 2001, pp [21] A. Martinez, J. Castro, O. Pastor, H. Estrada, Closing the gap between Organizational Modeling and Information System Modeling. In: Workshop de Enegnharia de Requisitos, SP, Brasil, 2003, pp [22] H.C. Mayr, C. Kop, D. Esberger, "Business Process Modeling and Requirements Modeling," In: ICDS - Digital Society First International Conference on the, Guadeloupe, 2007, pp [23] C. Monsalve, A. April, A. Abran. Requirements Elicitation Using BPM Notations: Focusing on the Strategic Level Representation. In: 10 th International Conference on Applied Computer and Applied Computational Science (ACACOS), 2011, Venice, Italy, pp [24] G. Cruz Neto, A. S. Gomes, J. B. de Castro. Mapeando Diagramas da Teoria da Atividade em Modelos Organizacionais Baseados em i*. In: Workshop de Engenharia de Requisitos, Argetina, 2004, pp [25] A. Q. Retamal, V. V. Zepeda, J. G. Arancibia, C. M. Villegas. Una Propuesta Metodológica para Modelar Procesos de Negocio de Decisión como Técnica de Elicitación de Requisitos para Sistemas de Business Intelligence. In: WER - Workshop de Engenharia de Requisitos, Valparaíso, Chile, 2009, pp [26] V. F. A. Santander, J. F. B. Castro, Deriving Use Cases from Organizational Modeling. In: IEEE Joint International Conference on Requirements Engineering, Washington, DC, USA, 2002, pp [27] E. Santos, J. Castro, J. Sanchez, O. Pastor. A Goal-Oriented Approach for Variability in BPMN. In: WER - Workshop de Engenharia de Requisitos, Cuenca, Equador, 2010, pp [28] X. Shi, W. Han, Y. Huang, and Y. Li, "Service-oriented business solution development driven by process model," In: Fifth International Conference on Computer and Information Technology (CIT), Shanghai, China, 2005, pp [29] SEI-Software Engineering Institute. CMMI for Development, V1.2, CMU/SEI-2010-TR-033. Carnegie Mellon University, [30] A. Strauss, J. Corbin. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. In: 2 ed. London, SAGE Publications, [31] L. Vale, A. B. Albuquerque, P. V. Beserra. A Importância da Qualidade Profissional dos Analistas de Requisitos para o Sucesso dos Projetos de Desenvolvimento de Software: um Estudo para Identificar as Habilidades mais Relevantes. In: XXV SBES Simpósio Brasileiro de Engenharia de Software, São Paulo, 2011, pp [32] S. R. C. Vieira, D. Viana, R. do Nascimento, T. Conte. Using Emprirical Studies to Evaluate the REMO Requirement Elicitation Technique. In: 24 th International Conference on Software Engineering and Knowledge Engineering (SEKE), 2012, pp [33] S. R. C. Vieira, R. P. C. do Nascimento, T. Conte. Technical Report: Heuristics of the REMO Requirements Elicitation Technique, Report Number 007, Available at: index.php/publicacoes/cat_view/69-relatorios-tecnicos [34] I. Villanueva, J. Sánchez; Ó. Pastor. Elicitación de requisitos en sistemas de gestión orientados a procesos. In: WER - Workshop de Engenharia de Requisitos, Portugal, 2005, pp [35] L. Xavier, F. Alencar, J. Castro, J. Pimentel. Integração de Requisitos Não-Funcionais a Processos de Negócio: Integrando BPMN e NFR. In: Workshop de Engenharia de Requisitos, Cuenca, Equador, 2010, pp [36] E. Yu. Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In: IEEE International Symposium on Requirements Engineering (RE 97), 1997 pp