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, além disso, a compreensão do ambiente organizacional onde esse sistema irá atuar podem ser, sem dúvida, fontes relevantes de requisitos. Pesquisadores têm reconhecido, por exemplo, 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), com o intuito de agregar os seguintes benefícios (Vieira et al., 2012): os requisitos passam a refletir, de fato, e ser guiados pelas necessidades do negócio; e, consequentemente, há um baixo número de redundâncias de requisitos.

Como modelos de processo e negócio podem auxiliar a encontrar requisitos de sistemas?

A utilização de modelos de processo e negócio pode ser fundamental para identificar requisitos de sistemas. Inicialmente, é importante destacar que os modelos de processos de negócio descrevem a atividade fim realizada por uma empresa. Dessa forma, a modelagem de processos surge como o primeiro passo para o desenvolvimento de um sistema. A partir desses modelos, torna-se possível não apenas identificar requisitos de sistema para automatizar atividades desse negócio, mas também, de maneira adicional, reconhecer requisitos não funcionais e regras de negócio.

A análise comparativa entre as abordagens convencionais e, por outro lado, as abordagens que utilizam modelos de processos de negócio como ponto de partida vem sendo aplicada há alguns anos. Nesse sentido, 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. No entanto, ao analisar os modelos de processos, foi possível ter uma visão global do “modus operandi” da organização e, com isso, identificar e 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.

Abordagens para descoberta de requisitos

Algumas iniciativas visam auxiliar na descoberta de requisitos a partir de modelos de processos.

Técnica REMO

Essa técnica utiliza heurísticas que não apenas auxiliam o analista de sistemas, mas também proporcionam uma identificação eficiente dos requisitos a partir dos diagramas de processos de negócio. Na última versão da técnica, são propostas nove heurísticas que facilitam a derivação de requisitos a partir dos elementos do modelo de processos. Abaixo, na figura, são apresentadas as cinco primeiras heurísticas da técnica REMO.

Heurística da Técnica REMO, elemento em BPMN e instruções para geração de Requisitos funcionais e não-funcionais. Todas as heurísticas estão disponíveis em Vieira (2012).
Heurística da Técnica REMO, elemento em BPMN e instruções para geração de Requisitos funcionais e não-funcionais. Todas as heurísticas estão disponíveis em Vieira (2012).

Além disso, é importante destacar que cada heurística possui um exemplo de aplicação. Esses exemplos não apenas ilustram a aplicação prática das heurísticas, mas também aumentam o poder de entendimento sobre o uso delas nas derivações dos requisitos. Por exemplo, na figura abaixo, é descrita 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 não apenas um requisito funcional, mas também um requisito não-funcional. Vale ressaltar que a técnica REMO foi avaliada experimentalmente, buscando analisar sua adequação e aplicabilidade real na identificação de requisitos. Os resultados, conforme destacados por Vieira et al. (2012) (Vieira, 2012), são promissores, e atualmente a técnica encontra-se na versão 3.

Exemplo de aplicação da Heurística H3 – Eventos de Mensagens/comunicados. Todos os exemplos de aplicação estão disponíveis em Vieira (2012).
Exemplo de aplicação da Heurística H3 – Eventos de Mensagens/comunicados. Todos os exemplos de aplicação estão disponíveis em Vieira (2012).

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.

Processo de rotulação de um diagrama de processo de negócio. Fonte: Xavier (2009).
Processo de rotulação de um diagrama de processo de negócio. Fonte: Xavier (2009).

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.