On the expressiveness of business process modeling notations for software requirements elicitation

Abstract

Business process models have proved to be useful for requirements elicitation. Since software development depends on the quality of the requirements specifications, generating high quality business process models is therefore critical. A key factor for achieving this is the expressiveness in terms of completeness and clarity of the modeling notation for the domain being modeled. The Bunge-Wand-Weber (BWW) representation model is frequently used for assessing the expressiveness of business process modeling notations. This article presents some propositions to adapt the BWW representation model to allow its application to the software requirements elicitation domain. These propositions are based on the analysis of the Guide to the Software Engineering Body of Knowledge (SWEBOK) and the Guide to the Business Analysis Body of Knowledge (BABOK). The propositions are validated next by experts in business process modeling and software requirements elicitation. The results show that the BWW representation model requires to be specialized by including concepts specific to software req uirements elicitation.

Transforming Process Models to Problem Frames

“…However, process models are not expressive enough for requirements engineering [16]. Yet, there exist a few studies that integrate process and requirements modeling [6] or derive requirements from process models [17].…”

“…Business process modeling (BPM) is the key instrument to analyze, design and identify the user requirements of a PAIS [16,20]. However, process functions need to be further analyzed for their behavior, data usage and operations during PAIS execution to identify user requirements in the business domain [7,16,17,20].…”

A semi-automated approach for generating natural language requirements documents based on business process models

“…Li et al propose a method to link textual requirements to activities in the process model [8]. [30]. What all these works have in common is that they exemplify how process models can support requirements elicitation.…”

“…The second part of the algorithm handles the generation of the data need and constraint sentences (lines [18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34]. For this purpose each system from the requirements model is analyzed separately.…”

“…sentences [28][29][30][31][32][33]. In case the considered system is associated with one or more constraints, a sentence following the template C1 is created for each of these (lines [30][31].…”