An enhanced requirements elicitation framework based on business process models

Requirements elicitation is a central and critical activity in the requirements engineering process. Completeness is among the most difficult challenges facing requirements engineers. Missing requirements is one of the major causes of software failure; they often result from the lack of anticipation of all possible relations between elements of the system-to-be. In this paper, we propose a requirements elicitation framework which starts with an organization’s business process models and buildsthe system’s CRUD matrix. This matrix provides all possible relationships between entities and functions of the system in order to capture all possible requirements of the system. The generated relationships between entities and functions provide analysts with the required prompts to ask potential users/stakeholders during interviews to ensure encompassing all questions. The new framework is demonstrated using a real case study; the Cancer Care and Registration in Jordan.


INTRODUCTION
Requirements elicitation represents the set of activities involved in discovering what the system requirements are, including: The identification of all stakeholders of the system, analysis of the problem application domain, the system"s operating environment and of the customers" organizational and business environment (Damian, 2000).Improper capturing of system requirements is the major factor in the failure of most software projects.
Requirements are most commonly written in natural language or represented in semi-formal modelling representations.However, a written natural language requirement is error prone and vague leading to inherent imprecision, such as ambiguities, incompleteness and inaccuracy (Kamalrudin et al., 2011).Completeness of requirements is of major significance in software engineering and can have a major impact on testing, formal verification, robustness and safety of software.Missing requirements are reported as one of the major causes of software failure (Alrajeh et al., 2012;Cheng et al., 2007); they often result from the lack of anticipation of all possible relations between elements of the system-to-be.In this paper, we propose a new requirements elicitation framework which helps anticipate all possible relations between entities and functions for the system starting with BPMs and building the system"s CRUD matrix.This matrix provides all possible relationships between entities and functions in order to capture all possible requirements of the system.So, the ultimate goal is to capture all possible user requirements of a system and reduce the number of missing requirements as much as possible.
The new framework is proposed after providing an overview of the current requirements elicitation techniques and discussing challenges facing requirements engineers during the requirements elicitation phase.The framework is then demonstrated using a real case; the Cancer Care and Registration in Jordan (CCR).

Interviews
Interviews are the commonly used and most popular method for requirements elicitation (Kotonya et al., 1998;Sampaio et al., 1996).First you identify the range of people who are involved as potential users/stakeholders of the system.This extends the range of viewpoints that will eventually feed into your proposed system.However, the completeness and correctness of the elicited requirements relays to a great extent to the way the interviewer asks the questions.Our proposed framework helps the interviewer in phrasing questions through identifying all possible relationships between business entities and functions, and hence allows him/her to include all possible questions within the system boundaries and reduce the chance of missing any question and consequently reducing the chance of missing any requirement.

Questionnaires
Questionnaires can be used to get responses from a larger group of people than can be handled in interviews.Eliciting requirements through questionnaires involves asking individuals to respond to a fixed set of questions, often by indicating their preferred option from a list of alternative responses to each question.The correctness and completeness of requirements elicited through questionnaires also depend on the way questions are presented.

Observation
Observation is the approach used to collect requirements by observinghow people does their work.This method is used to collect requirements when users are too busy to be involved in interviews.Observation helps elicit implicit requirements that interviews can not reveal.However, it is time consuming and may not work if the current process involves intellectual work or work that is not easily observable.

Brainstorming
Brainstorming is a technique used to generate new ideas and find the solution to a specific issue (Pfleeger et al., 1998;Robertson et al., 1998;Wilson, 2006).This is conducted as a conference with 6 to 10 members from different departments and domain experts.
Brainstorming includes choosing a topic or a problem, and then drawing up and discussing different solutions.This method is helps the group members to share their experiences and creativitiesto find the best solution.It"s alsohelpful in eliciting requirements in a relatively short time period, but depends on the member"s creativity.

Focus group
Focus group is getting a group of people together to discuss a problem area, preferably with some sort of 'stimulus material' relating to the topic under consideration.The focus group technique can be traditional where members gather in the same physical room or can be an online focus group which allows members to be located remotely while participating.
This technique is effective for learning people's attitudes, experiences and desires; it also gives the ability to ask questions and creates an environment where participants can consider their personal view in relation to other perspectives.However, this method suffers from several problems; if the group is too homogenous the group's responses may not represent the complete set of requirements.It is also difficult to schedule the group for the same date and time.Finally, the collected data (what people say) may not be consistent with how people actually behave.

Prototyping
A Prototype is the representation or visualization of the actual system parts (Andriole, 1994;Kotonya et al., 1998;Robertson et al., 1998).Prototyping aims to uncover and visualize interface requirements before designing or developing the application.But the process of gathering requirements is limited because it is difficult to discover the users/stakeholders expectations without providing some model.A prototype may lead users to set unrealistic expectations of the delivered system's performance, reliability and usability characteristics.

Document analysis (requirements reuse)
Document analysis is used to gather details of the "As Is" environment such as existing business rules, entities, and attributes that need to be included in a new system or need to be updated for the current system.It is used to elicit requirements of an existing system by reviewing the documentation of such system.Reviewing the documentation helps understand the current situation and begin to formulate the questions to ask stakeholders to gather additional requirements.Documents analysis is the first step to prepare for interviews or other interaction based elicitation techniques.One of the drawbacks of this method is that documentation can be outdated so it is important to confirm that what you are reviewing is the most current.Reviewing existing documentation can also be a time consuming process.Accordingly, our proposed framework, helps reduce the time required to analyse the existing system through a semi-automated approach of analysing the set of business process models available for the as-is system.

Requirements workshop (joint application development, JAD)
A requirements workshop, also referred to as joint application development (JAD), is a structured requirements elicitation method (Maiden et al., 1996).It is similar to brainstorming, except that stakeholders are the ones who are involved in the discussion of the proposed system.Key stakeholders should be carefully selected for a short, intensive period of time (typically one or few days) (Maiden et al., 1996).Involving too many participants can slow down the workshop process thus negatively impacting the schedule.Conversely, collecting input from few participants can lead to overlooking requirements that are important to users, or to specifying requirements that do not represent the needs of majority of the users.

Interface analysis
An interface is a connection between two components.Most systems require one or more interfaces with external parties, systems or devices.Interface analysis is initiated by project managers and analysts to reach agreement with the stakeholders on what interfaces are needed.Interface analysis helps to clarify the boundaries of the system.Scenarios are generally used to clarify what the stakeholders need in each interaction.Use cases are the basic guidelines for the scenario models.A thorough interface analysis will describe the purpose of each interface involved and elicit high-level details about it, and outline its content.This type of elicitation is essential for software solutions which involve applications interacting with one another and/or users interacting with applications.The disadvantage of this technique is that it does not provide an understanding of the business process since this technique only exposes the inputs, outputs and key data elements related to the interfaces.

CHALLENGES FACING REQUIREMENTS ENGINEERS DURING THE ELICITATIONPROCESS
As described previously, the requirements elicitation phase is characterized by a close interaction with customers, system users and others involved with or affected by the system.Accordingly, the gathered requirements are commonly in a form of written natural language so that this form of human-centric representation is understood by both customers and developers.However, a written natural language requirement is commonly error prone and vague (Kamalrudin et al., 2011).
A number of requirements elicitation problems are the problems of scope, the boundary of the system is illdefined, unnecessary design information may be given, problems of understanding, users have incomplete understanding of their needs, users have poor understanding of computer capabilities and limitations, analysts have poor knowledge of problem domain, user and analyst speak different languages, ease of omitting "obvious" information, and conflicting views of different users (Christel et al., 1993;Sutcliffe et al., 2013).
A number of methods have been developed to address the above mentioned problems and improve the elicitation of requirements.For example, the ORDIT methodology (Blyth et al., 1993) emphasizes the definition of organizational requirements as part of the elicitation process.Accordingly, system designers can reason about organizational goals, policies and structures.The authors also developed a language with which to discuss human requirements of socio-technical systems, and to demonstrate how these are linked to the technical features of the system design.
The AMORE project (Christel et al., 1993) is concerned with ways in which large amounts of multimedia information can be visualized, stored and retrieved.AMORE is a system that provides ways to capture and organize requirements generated in many formats to facilitate navigation and browsing of large quantities of material.
Other methodologies that were developed and/or proposed to improve requirements elicitation include concepts like maps and repertory grids (Shaw et al., 1996) and ethnographic techniques (Sommerville et al., 1994).
Amore recent method to improve requirements elicitation is available in Konaté et al (2014) and Sakamoto et al. (2014) where the authors have proposed a method to elicit functional requirements based on existing products that are available in repositories.They accordingly used mobile applications available on the mobile app stores to elicit requirements under an interaction perspective.Other recent work included proposing and validating a framework to help requirements engineers select the most adequate elicitation techniques at any time (Carrizo et al., 2014), while in Konaté et al. (2014) the authors adapted the separation of concerns method to focus on collaborative aspects of requirements elicitation.They separated engineering aspects from collaboration aspects in order to study both of these aspects and then integrate them.Jin et al. (2003) presented an approach to support the elicitation process which combines various techniques for requirements elicitation including model-based concept acquisition, goal-driven structured interview and concept reuse, their goal was to support the automation of interaction with customers and to automate the construction of requirements models.
Our proposed framework for improving requirements elicitation addresses the problems of scope and completeness, were we aim to help analysts to be able to bound the system scope and ensure collecting thesystem requirements even those which are implicit and could be missed out.
Accordingly, our framework is expected to resolve many of the current requirements elicitation problems, such as identifying the system boundaries and including all relevant questions during interviews and questionnaires.

THE NEW REQUIREMENTS ELICITATION FRAMEWORK
Figure 1 represents our proposed framework process model, to elicit requirements starting from existing business process models.

Identifying the system's units of work (UoW) and functions to build the CRUD matrix
As we mentioned earlier, documents analysis is the first step to prepare for interviews or other interaction based elicitation techniques.The requirements of the new system can be easily elicited after understanding the existing system.In this phase we deploy a straightforward algorithm to extract essential business entities as well as functions for the as-is system from the system"s business process model.
An Essential Business Entity (EBE) is part of the subject matter of the organization (Ould, 2005).So, EBEs are there because of the business the organization is in, and they can be identified using a brainstorming exercise with the key person in an organization to answer questions concerned with what the organization makes and what product lines and/or service lines it has, what things the organization can be differentiated from other organizations in the same industry, what events in the outside world it needs to respond to, what business entities are listed in the organization"s data model and what things do the organization"s information systems keep information on.Recognizing who the organization"s external and internal customers, can also help in identifying EBEs.
EBEs can be filtered by putting the word "a" or "the" in front of each suggestion.If it is not familiar, it should be excluded.Designed entities, which are there because of the way the organization chooses to do its business rather than because these entities characterize its business fundamentally, should also be excluded.For example, an "invoice" is not an EBE for a car manufacturer organization because it is not in the business of invoices.However, for the invoice handling department, which is in the business of handling invoices, an "invoice" is an EBE.
In this content we are concerned with EBEs which are considered as units of work (UoW).A Unit of Work is an EBE which has a lifetime handled by members of the organization.For example, an EBE that does not have a lifetime of interest to the organisation, or that is part of another EBE.We will not also consider EBE that are only roles that play part in the processes (Ould, 2005).
In our framework, we adapt the method used to automatically identify EBE from the set of business process models presented in (Yousef, 2014) and extend it to identify functions and units of work and then build the CRUD matrix, Algorithms I and II.

Algorithm 1: Building the CRUD matrix from BPMs
Input: the set of business process models, BP={bp 1 , bp 2 , …, bp i , …, bp n }, 0≤i≤n Output: The CRUD matrix Begin 1.For each business process model bp i in BP do 2. Find irredundant tasks of bp i , T={t 1 , t 2 , …, t k , …,t x }, 0≤k≤x 3.Call Extract_EBEs_from_BPMs (bp i ), return E={e 1, e 2 , …, e l , …,e y }, 0≤l≤y 4. Classify EBEs that have a lifetime which is handled by, or are the responsibly of, members of the organisation as Units of Work (UoWs) 5. End for 6.Build the CRUD matrix as follows: 7. for each task t k in T do 8. set the t k as the row of the CRUD matrix 9. for each unit of work, u l in UOW do: 10. set u l as the column of the CRUD matrix

Identify system entities and functions
Build the CRUD matrix

EBE and function s
System-tobe CRUD matrix Existing system CRUD matrix

Existing BPMs
Use the matrix to identify relationships of the system-to-be Extract requirements Elicited Requirements  Algorithm I analyses each business process model to extract existing tasks and entities, where each irredundant task is placed in one row and each unit of work, identified as an essential business entity which has a lifetime managed by the organization (Ould, 2005), is placed in a column to build the CRUD matrix"s headers.Algorithm II (Yousef, 2014) assumes that the business processes are modelled using BPMN, however, this algorithm can be generalized for any business process model using model translators such as Yousef et al. (2009).

Set the matrix cell as the relationship between t k and u l which is one of the CRUD functions (
As we have explained in previously, brainstorming is conducted with members from different departments and domain experts to improve thinking by helping to answer specific questions.So, a brainstorming session is required at this stage to set the matrix"s cell relationships for the as-is system.

Building a potential CRUD matrix and eliciting requirements
Having the CRUD matrix built, the system boundaries are set and all potential questions can be extracted from this matrix.According, the analyst can use this matrix to set new relationships for the new system, and generate a new one for the new system.Both matrices will help the analyst phrase questions with a minimum chance of missing a functionality of the system.This would lead to an improvement of the requirements" completeness to a great extent.Following we demonstrate our framework using a real case study form the healthcare domain.

DEMONSTRATING THE PROPOSED FRAMEWORK USING A CASE STUDY
Here, we demonstrate the new framework using a real case study from the healthcare domain; the Cancer Care and Registration in Jordan (CCR).The Jordan"s Cancer Care and Registration (CCR) processes" case study (AbuRub, 2006) is a real case study that has been validated and improved.It provides a number of business process models (BPM)s which we have used to demonstrate the new requirements elicitation framework.
Figure 2 shows one of the CCR processes; the patient reception process.This process was originally obtained

Identifying EBE
A set of EBE were identified using Algorithm II, these are listed in Table 1.Then the set is filtered to produce the Units of Work (those in boldface).

Identifying tasks and building the CRUD matrix
The set of tasks were extracted from the business process model, shown in Table 2, and the CRUD matrix was built using Algorithm I, Figure 3 shows part of the generated CRUD matrix.
The generated CRUD matrix provides an inspiring source of information to the analyst to phrase interview questions and questionnaires, to brainstorm potential relationships between entities and functions, etc. for example, the analyst can identify new functional requirements established from new compensations between entities and functions such as "informing patient" and "appointment", where no relation had been established in this context.
Accordingly, this matrix which was generated from analyzing existing documents, more specifically, the business process models, helps determine the system"s boundaries and improves requirements" completeness to a great extent.

CONCLUSIONS
Traditional requirements elicitation techniques include interviews, questionnaires observation, brainstorming, focus group, prototyping, document analysis, requirements workshop (joint application development, JAD) and interface analysis.Many requirements elicitation problems has been identified in literature, these include the problems of scope, system boundary, understand-ability, poor knowledge of problem domain different terminologies between users and analysts and conflict views of different users.In this paper we were concerned about improving requirements elicitation to help analysts understand the boundaries and identify all entities and functions of the as-is system, so that better questions are phrased during interviews and questionnaires.The proposed framework starts with an inception phase to establish the business case, where in almost all successful applications" developments; this phase constitutes a major part of the development process.Then the framework builds the CRUD matrix of the as-is system, from which requirements of the new system can be inspired.As a consequence, the proposed framework improves requirements" completeness to a great extent.The framework was demonstrated using a real case study from the healthcare domain, the cancer care and registration in Jordan.The next phase in our framework development is to implement a tool to automatically generate questions from the CRUD matrix formulated from the entities identified in the first phase of our framework.So, an analyst can have a well-structured interview with the set of questions that include all entities and functions within the system boundaries.

Figure 1 .
Figure 1.The proposed framework process model.