Keywords

1 Introduction

Requirement engineering is a segment of software engineering that is responsible for identifying the real functions and limitations of software system. By identifying both user and system requirements through the respective stakeholders of a system, it leads to a quality deliverance of a software system [1]. During recent years, researchers actively attempted to improve quality in the initial stage of the software development life cycle (SDLC). Automation of requirement engineering process became of high importance, but despite all the effort, requirements engineering (RE) still remain a tough problem to automate because of its human-centered nature [2].

Requirements are highly important in understanding, managing and controlling costs in software projects and their identification are considered as vital towards success of software projects [3, 4]. Although requirements need to be sufficiently complete, consistent and testable, the most neglected practice in SDLC is to document them [3]. Moreover, using requirement documents that have errors as a reference in other projects can adversely cause further errors in the final product. A study showed that companies spent nearly 10% out of total time allocated on a project in requirement gathering and on completion of the project many companies realized that about 50–80% of their budget is gone on rework because time spent on requirement gathering was not enough [3]. Furthermore, projects where adequate time was spent on requirement gathering was found to have high success rate in comparison to projects that were allocated less time for requirement gathering [4].

In software requirement engineering, two types of requirements are gathered, namely, functional and non-functional requirements [5,6,7,8]. Functional requirement specifies something the system should while non-functional requirements relate to the operation of a system [2, 9, 10]. The core activities in requirement engineering are:

  1. i.

    Requirement Elicitation: Requirement elicitation is the process of gathering data from the user or stakeholders to the system developer [11, 12].

  2. ii.

    Requirement Analysis: All information gathered in the requirement elicitation process are analyzed and broken-down for the understanding of stakeholders needs [13].

  3. iii.

    Requirement Implementation: Requirement implementation is the stage where the software is coded and executed.

  4. iv.

    Requirement Documentation: The elicited data are documented for use during the implementation of the software [12].

  5. v.

    Requirement Validation: Also called as requirement verification [14], this process ensures that requirement documents are complete with unambiguity and users/stakeholders are satisfied with the requirement specification.

1.1 Requirement Elicitation

Getting quality requirements is of high importance to any software development project, which is directly proportional to the success of that project irrespective of the methodology utilized [14]. As such, requirement elicitation is vital in software development process [2]. It is the process of understanding the problems a proposed system will address through seeking, understanding and full disclosure of the needs of users and stakeholders, so as to communicate those needs to the developers [15]. There are two types of requirements elicitation techniques, namely, the direct approach and indirect approach. The direct approach techniques are based on case-study, interview, and prototyping [16]. The indirect approach is used in cases where information and data are cannot be easily retrieved. The techniques under in-direct approach involve use of questionnaire and document analysis, among others. Figures and statistics are utilized in this approach to clarify things.

1.2 Requirement Elicitation Techniques

As discussed earlier, requirement elicitation is the stage where the system developer gets to understand the problems of a proposed system [15, 17]. Different techniques are used in the process where the first one is interview. The main aim of interview is to investigate and understand the requirement engineering process [18, 19]. In an interview, the users/stakeholders need to be interviewed first [20] and the interviewer will discuss the requirement of the product (system) with the user/stakeholder to get the overall view of the whole system. This technique has also been identified as the most utilized one because it mandates face to face interaction between the interviewer and the users/stakeholders and information can be driven quickly [21]. Survey is another technique and is used to gather requirements from users/stakeholders that may reside at different locations [22]. This technique is also utilized to analyze data from larger population of people than interviews [21]. With questionnaire, information can be obtained from a large group of people to get different views from the users/stakeholders [6, 12]. Another technique is observation which involves observing how people do their work practically. This technique can help in getting complex requirements that interviews cannot reveal [24]. Brainstorming is another technique where an individual member is free to express his/her idea about a product (system) to help bring about new ideas and solutions to a problem [25]. Finally, prototyping involves developing a version of the product (system) in order to get feedback from users/stakeholders.

2 Related Work

Hickey and Davis [26] presented a mathematical model of requirements elicitation that provided understanding of what analysts need to perform during elicitation, how elicitation techniques should be selected, and clue on improving likelihood that the system conform to customers’ needs. The same work suggested that future models should capture the critical roles played by knowledge in both elicitation and elicitation technique selection. Another study [11] provided an overview on requirement elicitation techniques while comparing the strength of various requirement elicitation tools based on various parameters. The cons of adopting single requirement elicitation technique were highlighted in the same study. Basir et al. [27] constructed a framework for eliciting requirements that are considered as hidden or embedded and whose omission might cause software failure (i.e. tacit requirements). A hybrid framework was designed by integrating a reputable process and model of tacit requirements elicitation. Furthermore, 15 expert interviews were conducted to explore current practices in requirements engineering in three industries developing hybrid products [2]. Results of the same study showed that most components of hybrid products are developed independently from each other while involving high-level of technological integration of the elements and because of that, hybrid techniques was suggested as the way toward comprehensive requirements engineering. To improve effectiveness and efficiency of requirement elicitation different studies have been conducted using the hybrid approach [28,29,30]. Rooksby et al. [31] developed a hybrid process to fast-track consensual problem definition in large-scale systems with multiple stakeholders when eliciting requirement. Additionally, hybrid approaches was also highlighted to be effective in agile software development [32].

As hybrid techniques has been suggested as the way towards comprehensive requirements engineering, this paper proposes a novel hybrid requirement elicitation technique to tackle the challenges developers have in the process of software development [4, 14, 33].

3 The Proposed Hybrid Requirement Elicitation Approach

This study attempted the combination of 3 requirement elicitation techniques, namely use of questionnaire, interview and prototyping in a unified framework that is expected to strengthen the process of requirement elicitation. The approach used operates as follows and is depicted in Fig. 1:

Fig. 1.
figure 1

A three-phased hybrid approach to requirement elicitation

Full size image

Stage 1.

In the first phase, the aim is to get information from large group of people so as to get different views from the users/stakeholders using questionnaires. Information collected is then analyzed to get insightful information on the key questions that need to be asked to the main stakeholders of the system.

Stage 2.

In this stage, an interview is conducted to further refine the requirements driven from the questionnaire in phase 1, which will help in building the first prototype of the system at the later stage.

Stage 3.

After acquiring information from users/stakeholders using questionnaires and interview, the requirement driven from interview will help in developing the first prototype of the product (system). This first prototype is to give the users/stakeholders the practical experience of the product (system) and their feedback will help in developing the final prototype.

4 Application of the Three-Phased Hybrid Approach

The conceptualized three-phased hybrid approach was utilized when building a system called NailClassroomFootnote 1 to elicit requirements from users/stakeholders. NailClassroom is an online educational system that makes communication and data sharing between lecturers and students easy and fast. In order to achieve these requirements, different factors pertaining to web design were also implemented [34, 35]. Application of the approach is described as follows:

4.1 Participants

Stage 1 Participants.

A questionnaire was formulated and administered to 550 students and 50 lecturers from public universities in Kano State Nigeria. A valid response of 150 students and 20 lecturers was recorded. The demographic details of the participants are given in Tables 1–3.

Table 1. Age split of the questionnaire respondents
Full size table
Table 2. Gender split of the questionnaire respondents
Full size table
Table 3. Academic level of the questionnaire respondents
Full size table

Stage 2 Participants.

Information obtained from the questionnaire helped in identifying the real users/stakeholders and in narrowing vital questions to be used in our interview to get our requirement right. In Stage 2, 5 lecturers from the Computer Science department, 2 lecturers from Mathematics department and 5 students all from Kano University of Science and Technology, Wudil were interviewed.

Stage 3 Participants.

Requirements finalized in phase 2 helped in building the first prototype of the system. The first prototype was developed and tested on 20 students and 5 lecturers at Kano University of Science and Technology. The feedback accumulated from the first prototype was used to make required changes on the requirement document; which helped in developing the second prototype. This prototype is presently adopted by more than 500 students across Nigerian universities.

4.2 Analysis of Proposed Approach

Among the elicitation techniques utilized, interview and questionnaire were found to be effective in getting ambiguous and complex requirements from users/stakeholders. From phase 1 towards phase 3, requirements were further fine-tuned and the stakeholders claimed to be more involved in the process. Among the three techniques, prototyping was found to be more effective as the stakeholders would were able to obtain the look and feel of the system. However, to confirm whether elicited requirements were correctly collected, the final prototype was validated by the same users involved during each of the 3 stages of elicitation. In the process, data was collected pertaining to collaboration/syllabus (part A) and ease of use of the implemented final prototype (B) was collected.

5 Results and Discussions

Results from the three stages, namely, use of questionnaire, interview and prototype are given as follows (Figs. 2, 3, 4, 5 and Tables 4, 5):

Table 4. Departments of the questionnaire respondents
Full size table

Results from the three phases revealed a high positivity in terms of validity of requirements. A few negative responses were also gathered especially from users who had more expectations from the system in terms of look and feel, although a prototype was used as part of validation. Overall, findings of the study made it clear that hybrid approach to requirement elicitation is the way forward to requirements elicitation, which could be smoothened by the proposed three-phased hybrid requirement elicitation technique in this study. The accuracy of requirements collected varies in each stage of our hybrid technique but showed to improve from Stage 1 until the last stage. There is no such thing as 100% accurate requirement but getting a successful system running according to user requirements, is a tangible and reliable indicator that a developer should consider. The proposed hybrid approach is thus expected to provide software developers a feasible framework toward generating accurate requirements.

6 Conclusions

This paper investigated the hybrid requirement elicitation technique involving the combination of 3 such techniques, namely use of questionnaire, interview and prototyping in a unified framework. The proposed approach was investigated during the implementation of an online educational system called NailClassroom. Results revealed a high positivity in terms of validity of requirements by participants from the three phases. Results also confirmed that hybrid approach to requirement elicitation is the way forward to requirements elicitation as accuracy of gathered requirements improved from first stage to the final one. As future work, the same approach could be further investigated in different types and size of software development projects.