A Lightweight BPMN Extension for Business Process-Oriented Requirements Engineering

Abstract

Process-oriented requirements engineering approaches are often required to deal with the effective adaptation of existing processes in order to easily introduce new or updated requirements. Such approaches are based on the adoption of widely used notations, such as the one introduced by the Business Process Model and Notation (BPMN) standard. However, BPMN models do not convey enough information on the involved entities and how they interact with process activities, thus leading to ambiguities, as well as to incomplete and inconsistent requirements definitions. This paper proposes an approach that allows stakeholders and software analysts to easily merge and integrate behavioral and data properties in a BPMN model, so as to fully exploit the potential of BPMN without incurring into the aforementioned limitation. The proposed approach introduces a lightweight BPMN extension that specifically addresses the annotation of data properties in terms of constraints, i.e., pre- and post-conditions that the different process activities must satisfy. The visual representation of the annotated model conveys all the information required both by stakeholders, to understand and validate requirements, and by software analysts and developers, to easily map these updates to the corresponding software implementation. The presented approach is illustrated by use of two running examples, which have also been used to carry out a preliminary validation activity.

Business Process Modeling Supporting the Requirements Elicitation of an Audit System

“…According to Intrigila et al (2021), "BPMN is now considered as the de facto standard in the business process management field. However, when applied to the definition and specification of software requirements, it shows significant limitations in terms of data modeling" (p. 2), and according to Sosnowski et al (2021), "Further evidence indicates that process modelling can be used as a requirements documentation technique in agile projects" (p. 186).…”

Process-Oriented Requirements Definition and Analysis of Software Components in Critical Systems

“…In this respect, in [9], the authors propose the introduction of ad hoc data models in the requirements elicitation phase, in order to make such requirements easy to understand and verify by stakeholders and, at the same time, unambiguous for the IT developers. This paper contribution exploits this idea to introduce ad hoc annotations to the BPMN model that defines the starting point of the proposed approach.…”

“…As stated in Section 3, this paper's approach to process-oriented requirement analysis is inspired by the lightweight BPMN extension presented in [9], where ad hoc attributes (AHAs) are defined as a set of key properties which get a specific graphical representation in the BPMN model for the system to be developed, with visual hints that make it easier to read and understand how such properties guide the execution flow and the requirements satisfaction. Ad hoc attributes may be in turn real properties of the entities involved in the requirement or synthetic/derived properties, easier to understand for the non-developer but formally linked to the underlying real system data model through potentially complex algorithms.…”

“…Step 1: from BPMN-AHA models to BPMN and DMN models. In the first step, requirements modeled as in [9] are represented through a combination of standard BPMN and DMN models. In particular, Data Objects, i.e., sets of variables, are used to represent the information consumed and produced by tasks as well as to indicate the data used in the DMN Decision Tables.…”

“…In this paper, we focus on the specification of the behavioral view, which is annotated with so-called ad hoc attributes (according to [9]), so to drive a more detailed system specification in the SysML. The proposed contribution introduces a stepped approach that progressively refines the system specification, from models at higher levels of abstraction, which are effectively used to help stakeholders defining their own requirements, down to more detailed models, which provide the requirements specification used to feed the subsequent system development and maintenance activities.…”