Using Behaviour-driven Requirements Engineering for Establishing and Managing Agile Product Lines

Requirements engineering in agile product line engineering refers to both common and variability components establishing a software. Although it is conventional for the requirements engineering to take place in a dedicated upfront domain analysis phase, agile-based environments denounce such a proactive behaviour. This paper provides an observational study examining a reactive incremental requirement engineering approach called behaviour-driven requirements engineering. The proposed approach uses behaviour-driven development to establish and maintain agile product lines. The findings of the study are very promising and suggest the following: the approach is easy to understand and quick to learn; the approach supports the constantly changing nature of software development; and using behaviour-driven requirements engineering produces reliable and coherent requirements. In practice, the observational study showed that using the proposed approach saved time for development team and customers, decreased costs, improved the software quality, and shortened the time-tomarket. Keywords—Agile product line engineering; behaviour-driven requirements engineering; observational study; requirements engineering


I. INTRODUCTION
Agile product line engineering (APLE) has been gaining a momentum throughout the past decade due to its faster delivery, lesser time-to-market, and more involvement for customers in every development cycle. APLE is the resulting approach of merging agile software development (ASD) and software product line engineering (SPLE); that term was formally coined at the first APLE'06 Workshop [1]. The purpose of APLE is to overcome the weaknesses of both paradigms (i.e., ASD and SPLE) while maximizing their benefits. A software product line (SPL) is a family of software products that share a common set of features (i.e., core assets) in addition to the unique features (i.e., variability) associated to each product in the family that satisfy the different needs of the customers [2]. Thus, it is intuitive to deduce that agile product lines (APLs) are SPLs that are either developed in an entirely ASD environments or in traditional environments that adopt some of the ASD practices. ASD, on the other hand, is a group of incremental and iterative software development methodologies that advocate quick clean software delivery and customers' involvement throughout the project lifetime [3]. The work in this paper focuses on behaviour-driven development (BDD) which is an ASD process that encourages the collaboration between the different stakeholders (i.e., customers, quality assurance, developers, etc.) of a software project [4].
According to the studies in [5,6], there are eleven factors that contribute to the success of a software project. While eight of those factors are related to requirements engineering (RE), ten of them are related to ASD. RE is the process of identifying, analysing, documenting, and managing user requirements [7,8]. The overlapping between the RE-related and the ASD-related project's success factors indicates that they share the same goals. Thus, it is most likely that having an agile-based requirements engineering process highly increases the possibility of having a successful software project.
Having realised the advantages of APLE as a development approach and the critical role of RE in a project's success, it is inquisitive to know whether it is feasible to achieve an incremental agile-based RE approach for APLs using BDD in a real-life empirical case study.
The rest of the paper is organised as follows: Section II explains BDD in further details while Section III briefs the reader about related work. Section IV summarises the proposed behaviour-driven requirements engineering (BDRE) approach. Section V presents the conducted observational study. Section VI discusses the results of the study. Finally, Section VII concludes the paper.

II. BACKGROUND
BDD was created to overcome the shortcomings of testdriven development (TDD). In particular, the starting point of testing, when and what to test, how much to test, understanding why a test fails, the need to have naming conventions for tests, and knowing whether a specification is met or whether the code delivers a business value [4]. BDD combines the general methods and practices of TDD with concepts from domaindriven design and objected-oriented analysis and design [4]. This provides a shared process and a common understanding to all the involved stakeholders (i.e., developers, designers, etc.). Thus, helps them to successfully collaborate on software development with well-defined outputs. As a result, BDD is capable of delivering working and tested software in shorter time-to-market while better managing traceability between the different artefacts of the system [4]. www.ijacsa.thesai.org BDD has six main characteristics [4,9]:  Ubiquitous language: which is a common language that enables customers and development teams to communicate without ambiguity. That language contains all the terms that will be used to define the behaviour of the systems. Although the structure of such languages emerges from the business domain model, BDD has its own pre-defined domainindependent ubiquitous language.
 Iterative decomposition process: since it is often difficult for the development team to find a starting point through which they can collect the customers' requirements, BDD works in an iterative manner to resolve that issue. Although the customers themselves might not have a clear view of the requirements they need, they surely know the business values and the behaviour they expect from the software project. As a consequence, the analysis process in BDD starts with the identification of the expected behaviour of the system, based on the intended business outcomes, which is later decomposed into a set of features. Each feature is then realised by a set of user stories and each user story is further described through a set of scenarios. A scenario is a specific instance of a particular user story that describes an actual context and output for that user story.
 Plain text description with User Story and Scenario templates: features, user stories, and scenarios are represented in plain text predefined templates using the BDD ubiquitous language. For example, to write a story, the following template is used: [UserStoryTitle] (One line describing the story)

I want a [Feature]
So that [Benefit] To write a scenario, the following template is used:

Given [context]
And [Some more contexts]

Then [Outcome]
And/But [Some more outcomes] While a user story describes an activity that is done by a user in a given role, the scenario describes how the system should behave when it is in a specific state for a specific feature and an event happens. Both user stories and scenarios are directly mapped to tests.
 Executable acceptance tests (EATs) with mapping rules: acceptance tests (ATs) in BDD is the satisfaction condition(s) that determines whether the behaviour of a particular feature is successfully achieved. BDD inherits the characteristic of executable testing from automated TDD, where ATs are regarded as automated specifications that verify the behaviour/interaction of the object rather than its state. Mapping rules provide a standardised way of mapping from scenarios to test codes, thus, facilitates managing traceability between the different artefacts of the system.
 Readable behaviour oriented specification code: BDD emphasises the importance of including the code in the system's documentation. Thus, the code should be readable and the specifications should be part of the code. The mapping rules help produce readable behaviour oriented code.
 Cross-cutting through the different software development phases: at the planning phase, the business outcomes are mapped to behaviours, where they are then decomposed into a set of features in the analysis phase. Then at the implementation phase, the EATs take place in which testing classes are derived from scenarios.

III. RELATED WORK
The APLE literature tackled various problems for the different RE activities (i.e., requirements elicitation, analysis, modelling, verification and validation, and management). After thoroughly studying the APLE RE literature and to the best of our knowledge, none of the previous efforts in this area proposed a RE solution that was based on BDD.
As a further matter, there were no efforts in the literature that offered a reliable RE solution that addressed the five activities of the RE process. Although there was an allinclusive RE solution attempt [13,14] in the literature, the authors did not validate their work through either a theoretical or a practical case study. Additionally, the authors collected their data from managers only and disregarded the perspective of the other stakeholders. Thus, directly violates the values of ASD where the perspectives of all the involved stakeholders should be taken into consideration throughout the development lifetime. Finally, none of the literature mentioned in this paper conducted a real-life empirical study to validate the respective proposed work.
The aforementioned research gaps were further confirmed by five systematic literature reviews [32][33][34][35][36]. These studies concluded that RE was not addressed properly or sufficiently in APLE regardless of the agility degree of the used development approach. Based on these findings and in addition to the crucial role of RE in the success of software projects, it has become imperative to have a systematic lightweight RE approach to reactively and incrementally develop and manage APLs. www.ijacsa.thesai.org

IV. SUMMARY OF THE BDRE APPROACH
The BDRE approach depends on BDD to have an incremental evolutionary flexible RE process. The full details about the BDRE approach are available in [37]. In BDRE, it is assumed that business goals, both functional and nonfunctional, are already identified and available for the development team to start their RE process. Generally, business goals are derived from the business need of finding solutions for a particular business problem.
The BDRE approach consists of five key activities: requirements elicitation, analysis, modelling, validation and verification, and management. Each activity is briefed as follows:  Requirements elicitation: This is the first step in the BDRE approach where the work starts outside-in. The input to this activity is the set of solution hypotheses for the already identified business problem. The development team uses prototyping to determine the relevancy of the proposed solutions set to the underlined business goal. After agreeing on the final set of solution, the development team determines the scope of the system accordingly. After that, the development team and the customer's representative decide the initial set of features, reflecting the needed behaviour of the system-under-development (SUD), to be developed in the next iteration. This concludes the elicitation activity with that initial set of features as an output.
 Requirements analysis: This is the second activity in the BDRE approach where the initial user requirements are further examined. The initial set of features from the previous activity in addition to the already existing features, of other products in the same SPL, are fed as an input for the analysis activity. The personnel representing the roles of business analyst, developer, and quality assurance conduct specifications workshops (aka. the three Amigo's meetings) to further analyse and negotiate that given inputs. Firstly, they examine the relevancy and the clarity of the given features in comparison to the business goals. Then, they come to a consensus on which features to consider as core assets and which ones to consider as variabilities. In case they detect an abnormality in the given requirements, they may go back to the requirements analysis activity for further inspection. Otherwise, they conclude this activity by producing an initial set of user stories for each core asset/variability feature.
 Requirements modelling: This is the third step in the BDRE approach with the initial set of user stories, produced at the analysis activity, as an input. The main goal of this activity is to illustrate each user story by an example. This is achieved through developing a series of real scenarios with actual values for each user story. After meetings and negotiations, the development team finalises the initial set of scenarios (i.e., the output of this activity) for each user story of each feature. If a scenario or a user story needs further clarification, the development team may go back to the analysis activity.
Otherwise, they proceed to the next step in the BDRE approach.

 Requirements validation and verification (V & V)
: This is the fourth step in the BDRE approach. The three Amigo's meetings take place again for refining the scenarios, produced from the modelling activity, according to their relevancy and importance. The purpose of this activity is to make sure that all the scenarios are done. To ensure that this happens, all the associated test cases of each scenario must successfully pass. Before producing the final set of scenarios, the development team negotiates and discusses all the examples with the customer's representative. In case of a disagreement, the three Amigos may decide to go back to the modelling activity or start over from the elicitation activity based on the severity level of the situation. Otherwise, the development team automates the produced final set of scenarios; thus, producing executable (aka. automated) specifications. The output of this V & V activity is the actual implementation, till the current development iteration, of the SUD.
 Requirements management: This is a cross-cutting activity in the BDRE approach through which all the other activities of the approach are maintained and managed.

V. OBSERVATIONAL STUDY
This section presents an evaluation to investigate the feasibility and usefulness of the proposed BDRE approach.

A. Research Instruments
A research instrument is a tool that is used to measure, obtain, and analyse data subjects. Research instruments could be qualitative, quantitative, or a mix. In this observational study, a mixed approach seemed to be the better option as our level of understanding and familiarity with the product-understudy evolved throughout the lifetime of the development. The following are the research instruments [38] we used:  Qualitative Methods: A qualitative research instrument is an exploratory tool that is used to have a better understanding of the subject at hand. It provides an indepth look into the problem and/or helps developing ideas or solution hypotheses. In this research, we used two qualitative methods: o Observation: When using the observation research instrument, the observer can play the role of either a participant-observer or an observer participant. A participant-observer becomes a member of the community being observed; thus, enables them to earn the right to participate in the various activities accordingly. An observer participant, on the other hand, is treated as a visitor who can only observe the behaviour and the working environment of the development team, with no actual participation in their activities. Most of the time, we were an observer participant with few participations in some hands-on activities. www.ijacsa.thesai.org o Interviews: They are an integrated part of any agile-based environment. Interviews are basically a set of questions, regardless of their form (i.e., structured, semi-structured, unstructured, or a mixed-form interviews), with respective answers. Although agile advocates face-to-face communications, this might not be feasible at all times in practice. Alternatively, interviews can be mediated via telephones or other electronic means. We mainly used three types of interviews: indepth interviews, face-to-face interviews, and discussion groups.

 Quantitative
Methods: Quantitative research instruments are techniques that transform data from opinions/feelings into numbers and consequently from being subjective into being objective. One of the most popular quantitative research instruments is questionnaires. In this technique, questions can be in the format of multiple choices, dichotomous, short answers, checkboxes, drop-down, rating scales, and more. Depending on the research needs, one or more question formats can be adapted. In this research, we used the rating scale questions format. In this format, a participant is required to give an answer based on a well-defined evenly spaced range.

B. Working Environment
We tested the proposed approach in a small-sized (i.e., 100 -200 employees) start-up agile-based company that is based in Egypt. The company has an intensive experience in agile development; in particular, Lean and Scrum agile methods.
The company focuses on the main agile practices such as iterative and incremental development; refactoring; automated testing; short iterations; pair programming; self-organising cross-functional teams; continuous deployment; progressive discovery; user story maps; and objectives and key results.
As the BDRE approach shares the same already implemented agile practices in place, the development team welcomingly embraced the proposed approach.

C. The Product under Development: RevoSuite
RevoSuite is a Business-to-Business Enterprise Softwareas-a-service (SaaS). It is an artificial intelligence (AI)-enabled customer relationship management (CRM)/customer lifecycle management (CLM)/business intelligence (BI) system for pharmaceutical and life sciences businesses. The development of the product started in 2012 and evolved throughout the years. New enhancements are still added to the product despite being realised in the market late 2012.

D. The Observational Study Goal
The goal of this observational study is to investigate the feasibility of the BDRE approach in a real-life industrial case study. The elements of the observational study are inferred from the values of BDD. Table I lists the five elements of the observational study and the required observation from each one of them.
The participants in this study volunteered to take a part in our observational study. All the participants, except for the customer's representative, have worked on RevoSuite throughout its lifetime. The total number of volunteering participants is 24, categorised as follows: six business analysts, eleven developers, six quality assurance, and one customer's representative.
Prior to starting the observational study, we explained the BDRE approach to the participants and offered them training on how to implement the approach. Afterwards, the participants took parts in various complexity pilot projects throughout the RevoSuite different development iterations. Thus, enabled us to monitor and observe the participants' performance. Additionally, we developed a questionnaire addressing the elements listed in Table I in further details and asked our participants to anonymously answer the questionnaire from the perspective of each one's role. Whether the participants are able to start a feature, integrate new changes as they come in, and eventually deliver the feature in a manner consistent with the behaviour expected by the customer.

Readability
Whether the participants are able to read and understand the documentation, including the code, of the system.

VI. RESULTS AND DISCUSSION
This section presents and discusses the results of both the pilot projects and the questionnaire.

A. Pilot Projects Results
The participants' performance was measured by two factors: the time spent on each feature from beginning to end; and the uniformity of their output compared to that expected by the respective business goal. In general, the time spent on each feature was directly proportional to the complexity degree of that feature. Consequently, the time spent in high-complexity pilot projects varied between double to tribble that of the lowcomplexity projects. Despite that, the performance of all the participants was almost consistent regardless of the complexity of the features. The only exception was for the one customer's representative whose performance was inversely proportional to the complexity of the feature at hand. www.ijacsa.thesai.org In projects with low-medium complexity, we observed that:  Learnability: almost all the participants were able to successfully use the BDD ubiquitous language to illustrate features, user stories, and scenarios.
 Coherence: more than 80% of the participants were able to have consistent outputs to those of the required business goals.
 Restrictions and conflicts: more than 75% of the participants were able to deduce all the explicit restrictions and conflicts. However, only half of them were able to spot all the implicit constraints.
 Evolution: more than 80% of the participants were able to start a feature, integrate new changes as they merge, and eventually deliver the feature (i.e., a core asset or a variability) in consistency with the expected behaviour of the system.
 Readability: all the participants were able to read and understand the system's documentation with minor difficulties.
In projects with high complexity, on the other hand, the participants spent more time on the features although they attained the same performance as that of the low-medium complexity projects. The only exception was the customer's representative whose performance dropped as the complexity of the feature increased.

B. Questionnaire Results
We used a five points Likert-scale, ranging from strongly disagree to strongly agree, to record the questionnaire responses. Fig. 1 illustrates the average responses per role for each question in the questionnaire. According to the recorded responses, the participants have come to a consensus that the BDRE approach is flexible, easy to understand, and easy to apply in practice. Some participants, however, shared their concerns about the potentiality and reliability of the BDRE approach in terms of scalability or when used with more complex systems. Lastly, finding implicit constraints was tricky and out of the comfort zone for some developers as well as for the customer's representative.

VII. CONCLUSION
APLE is increasingly gaining momentum in software development. Nonetheless, adopting APLE in practice calls for a special focus on RE. We proposed the BDRE approach to provide a flexible lightweight incremental RE process through using BDD throughout the different activities of RE. In this paper, we presented an observational study to examine five aspects of the BDRE approach in an empirical real case study. The results of the study were encouraging and shed the light on the strengths and weaknesses of the approach.

ACKNOWLEDGMENT
The authors would like to thank RevoSuite Company for their guidance and cooperation throughout the conduction of the observational study presented in this paper.