
No desenvolvimento de sistemas, uma atividade inicial e complexa é a elicitação de requisitos, uma vez que essa atividade influencia diretamente no produto de software que será entregue aos clientes. De acordo com o PMI, projetos podem fracassar quando não atendem às expectativas dos clientes. Além disso, os requisitos podem contribuir fortemente para a qualidade do produto (De la Vara et al., 2011).
O domínio de negócio e a compreensão do ambiente organizacional onde esse sistema irá atuar podem ser fontes relevantes de requisitos. Pesquisadores têm reconhecido a importância do uso de elementos dos processos de negócio durante as atividades de engenharia de requisitos (De la Vara, Sánchez e Pastor, 2008) (Aoyama, 2016) visando agregar os seguintes benefícios (Vieira et al., 2012): os requisitos passam a refletir e ser guiados pelas necessidades do negócio; e baixo número de redundâncias de requisitos.
Como modelos de processo e negócio podem auxiliar a encontrar requisitos de sistemas?
Modelos de processos de negócio descrevem a atividade fim realizada por uma empresa.
A modelagem de processos pode ser o primeiro passo para o desenvolvimento de um sistema. A partir dos modelos de processos é possível identificar requisitos de sistema para automatizar atividades desse negócio, assim como requisitos não funcionais e regras de negócio.
A análise comparativa entre as abordagens convencionais e as abordagens que utilizam modelos de processos de negócio como ponto de partida vem sendo aplicada há alguns anos. Cardoso et al. (2009), apresentam um estudo de caso comparativo no contexto do Departamento de Recursos Humanos em uma grande organização do setor energético. Ao comparar as duas abordagens, analisaram alguns aspectos, como:
(1) Completude – a abordagem convencional de elicitação de requisitos não cobria todas as ações dos atores envolvidos com o futuro sistema;
(2) Corretude – os modelos de processos de negócio mostram exatamente como a atividade ocorria impossibilitando que importantes regras de negócio fossem deixadas de lado pelo analista de sistema;
(3) Consistência – na abordagem de elicitação convencional, o foco era descrever interações isoladas do usuário com o futuro sistema. Ao analisar os modelos de processos, foi possível ter uma visão global do “modus operandi” da organização e, com isso, identificar os extrair os requisitos de sistema. Desta forma, a análise do fluxo de atividades do negócio auxiliou na identificação de inconsistências que não poderiam ter sido percebidas ao analisar a forma “isolada”;
(4) Diversidade – os modelos de processos permitem que os analistas verifiquem a necessidade de diversos módulos de um sistema ou até mesmo diversos sistemas que podem cobrir todas ou quase todas as atividades descritas nos modelos de processos. Ao utilizar uma técnica convencional, o poder de dizer quais requisitos entram ou não em um sistema é de responsabilidade do analista de sistemas. Ele pode não considerar, inocentemente, algumas atividades importantes da organização.
Leia também:
Abordagens para descoberta de requisitos
Algumas iniciativas visam auxiliar na descoberta de requisitos a partir de modelos de processos.
Técnica REMO
Vieira et al. (2012) desenvolveu uma técnica chamada REMO (Requirements Elicitation oriented by business process MOdeling). Essa técnica utiliza heurísticas que auxiliam o analista de sistemas na identificação dos requisitos a partir dos diagramas de processos de negócio. A última versão da técnica propõe a utilização de nove heurísticas que auxiliam na derivação de requisitos a partir dos elementos do modelo de processos. A figura abaixo apresenta as cinco primeiras heurísticas da técnica REMO.

Além disso, cada heurística possui um exemplo de aplicação. Esses exemplos de aplicação aumentam o poder de entendimento sobre o uso das heurísticas nas derivações dos requisitos. O exemplo apresentado na figura abaixo descreve uma atividade de um processo de acompanhar projetos de conclusão de curso em uma instituição de ensino superior. Após aplicar a Heurística 3, o analista identificou um requisito funcional e um requisito não-funcional. A técnica REMO foi avaliada experimentalmente buscando analisar sua adequação e aplicabilidade real na identificação de requisitos. Os resultados são promissores (Vieira et al., 2012) (Vieira, 2012) e atualmente a técnica encontra-se na versão 3.

Abordagem BPMNFR
Esta abordagem visa integrar modelos de processo de negócio com requisitos não-funcionais, aumentando a expressividade de um modelo, uma vez que não é possível ter, explicitamente, requisitos não-funcionais descritos nos modelos de processo de negócio (Xavier, 2009). Para isso a abordagem cria um rótulo inserido na representação de uma atividade dentro de um modelo de processo de negócio. A Figura abaixo apresenta um exemplo de rotulação.

A partir do diagrama, outro artefato era gerado contendo a especificação deste rótulo em formato de requisito não-funcional. Em seguida, são criadas operacionalizações que objetivam avaliar aquele requisito não-funcional no futuro.
Referências
AOYAMA, M. (2016, November). Bridging the requirements engineering and business analysis toward a unified knowledge framework. In International Conference on Conceptual Modeling (pp. 149-160). Springer, Cham.
CARDOSO, E. C. S., ALMEIDA, J. P. A., & GUIZZARDI, G. (2009, September). Requirements engineering based on business process models: A case study. In 2009 13th Enterprise Distributed Object Computing Conference Workshops (pp. 320-327). IEEE.
de OLIVEIRA, M., VIANA, D., CONTE, T., VIEIRA, S., & MARCZAK, S. (2013, July). Evaluating the REMO-EKD technique: A technique for the elicitation of software requirements based on EKD organizational models. In 2013 3rd International Workshop on Empirical Requirements Engineering (EmpiRE) (pp. 9-16). IEEE.
J. L. De la VARA, J. SÁNCHEZ, O. PASTOR. Business Process Modelling and Purpose Analysis for Requirements Analysis of Information Systems. In: CAiSE – 20th International Conference on Advanced Information Systems Engineering. 2008, pp. 213 – 227.
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: 23rd International Conference on Software Engineering and Knowledge Engineering, Miami, 2011, pp. 438-443.
VIEIRA, S. R. C. Remo: uma técnica de elicitação de requisitos orientada pela modelagem de processos de negócios. 2012. 129 f. Dissertação (Mestrado em Informática) – Universidade Federal do Amazonas, Manaus, 2012.
VIEIRA, S. R. C., VIANA, D., NASCIMENTO, R. P. C., & CONTE, T. (2012). Avaliando uma Técnica para Extrair Requisitos a partir de Diagramas de Processos de Negócios através de Estudos Experimentais. In CLEI 2012-XXXVIII Conferencia Latinoamericana en Informática. Elsevier, Medelin, Colombia (Vol. 11).
XAVIER, L. (2009). Integração de Requisitos não Funcionais a Processos de Negócios: Integrando BPMN e NFR. Master’s thesis.

Publicado por: Davi Viana davi.viana@lsdi.ufma.br
Graduado em Ciência da Computação pela Universidade Federal do Amazonas (UFAM), Mestre e Doutor em Informática pelo Programa de Pós-Graduação em Informática da UFAM. Possui curso técnico em informática pela Fundação Nokia de Ensino. Atualmente é Professor Adjunto da Universidade Federal do Maranhão (UFMA). Além disso, é membro permanente dos Programas de Pós-Graduação em Ciência da Computação (PPGCC), Doutorado em Ciência da Computação Associação UFMA/UFPI (DCCMAPI) e Mestrado Profissional em Propriedade Intelectual e Transferência de Tecnologia para a Inovação (PROFNIT). Adicionalmente, é Coordenador dos programas PIBIC e PIBITI da UFMA. É vice-coordenador da Comissão Especial de Sistemas de Informação (CESI) da SBC e Secretário Regional da SBC no Maranhão. Tem interesse nas áreas de sistemas de informação, qualidade de software, melhoria processo de software (MPS), implementação de programas de MPS com ênfase na adoção de modelos de maturidade, educação em engenharia de software, engenharia de software experimental. Por fim, também atua na aplicação de metodologias de engenharia de software em diversos contextos, como: internet das coisas; startup de software; e computação aplicada à saúde.