Bridging the Gap between Requirements Modeling and Behavior-Driven Development

Abstract

Acceptance criteria (AC) are implementation agnostic conditions that a system must meet to be consistent with its requirements and be accepted by its stakeholders. Each acceptance criterion is typically expressed as a naturallanguage statement with a clear pass or fail outcome. Writing AC is a tedious and error-prone activity, especially when the requirements specifications evolve and there are different analysts and testing teams involved. Analysts and testers must iterate multiple times to ensure that AC are understandable and feasible, and accurately address the most important requirements and workflows of the system being developed. In many cases, analysts express requirements through models, along with natural language, typically in some variant of the UML. AC must then be derived by developers and testers from such models. In this paper, we bridge the gap between requirements models and AC by providing a UML-based modeling methodology and an automated solution to generate AC. We target AC in the form of Behavioral Specifications in the context of Behavioral-Driven Development (BDD), a widely used agile practice in many application domains. More specially we target the well-known Gherkin language to express AC, which then can be used to generate executable test cases. We evaluate our modeling methodology and AC generation solution through an industrial case study in the financial domain. Our results suggest that (1) our methodology is feasible to apply in practice, and (2) the additional modeling effort required by our methodology is outweighed by the benefits the methodology brings in terms of automated and systematic AC generation and improved model precision.

Leveraging natural-language requirements for deriving better acceptance criteria from models

“…We use the AGAC approach and its associated tool [1] for deriving AC from models. AGAC is an Activity Diagram-centered approach and consists of two tasks: (1) Create Specifications and (2) Derive AC.…”

“…AGAC is an Activity Diagram-centered approach and consists of two tasks: (1) Create Specifications and (2) Derive AC. The first task, which is performed manually, is concerned with the creation of a requirements and analysis model by following an existing modeling methodology [1]. The resulting model include Activity Diagrams (ADs), Class Diagrams (CDs) and Use Case Diagrams (UCDs).…”

“…AC Derivation: To generate AC, we employ an existing technique, named AGAC (Automated Generation of Acceptance Criteria) and its associated tool [1]. The AC produced by AGAC are represented in the Gherkin scenario language [17].…”

“…The method identifies the model elements that can be enriched with the extracted information and provides guidance to the analysts as to how they can incorporate this additional information into the model. Subsequently, an existing model-based AC derivation technique, AGAC [1], is applied to the enriched model. This way, we make it possible to account for the information in both the model and the NL requirements during AC derivation.…”

On systematically building a controlled natural language for functional requirements

“…Different studies have reported that one of the main causes of software project failures in industry is related to poorly written requirements, i.e., requirements that are unclear, ambiguous, or incomplete (Ahonen and Savolainen 2010;Hull et al 2011;The Standish Group 1995). Poorly written requirements are difficult to communicate and reduce the opportunity to process requirements automatically, for example, to extract models (Arora et al 2015) or derive test specifications (Alférez et al 2019).…”