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).

 

REQUIREMENTS ELICITATION TECHNIQUES

 

Here, we provide a brief description of the most popular requirements elicitation techniques; these are interviews, questionnaires, observations, brainstorming, focus group, prototyping, document analysis, joint application development and interface analysis (Kotonya et al., 1998; Hickey et al, 2002; Hickey et al, 2003; Parvianen et al, 2007; Wiegers, 2013; Dyba, 2013; Iqbal, 2014).

 

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.

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 ill-defined, 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. 

Figure 1 represents our proposed framework process model, to elicit requirements starting from existing business process models.

 

 

 

11. Set the matrix cell as the relationship between t_k and u_l which is one of the CRUD functions (Create, Read, Update or Delete)

12. end for

13. end for

End

 

Algorithm II: Extract_EBEs_from_BPMs

 

Input: A BPMN business process model, bpm_i, where it is a collection of roles, R = {r₀, …,r_m} consisting of a number of tasks T = {t₀, …, t_l}

Output: A set of essential business entities present in the bpm_i, EBE={ebe₀, …, ebe_x1}

Begin

Add the bpm_i process name to EBE;

Identity the set of rolls in the business process model, bpm_i; R={ r₀, r₁, …, r_j, …,r_n}, 0≤ j≤n;

For each role r_j in R do the following

      Add r_j role name to EBE

      Identity the set of tasks in r_j, T={ t₀, t₁, …, t_k, …,t_m}, 0≤ k≤m;  

      For each task t_k in T do the following

            If not already in EBE

                        Add the subject name of the task t_k to EBE

                        Add the object name of the task t_k to EBE

            End if

      End for each task

Exclude designed business entities

End for each role

End

 

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).

 

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.

 

 

 

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 from (AbuRub, 2006) and then translated from Role Activity Diagram to Business process model notation diagram by Yousef et al. (2009).

 

 

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.

 

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. 

The authors have not declared any conflict of interest.