Table 1. Zachman Architecture Framework
At present, interview is still considered one of the pragmatic approaches to gathering software requirements from the different stakeholders in a software project. Despite unrelenting efforts by researchers, requirements gathered using this method still suffer anomalies such as inconsistency and incompleteness; this problem is partly due to communication gaps between Requirement Engineers (RE) and project stakeholders and partly due to the RE directing some questions to the wrong persons. This paper proposes a framework, which mirrors the Zachman's Enterprise Framework to systematically classify requirement interview questions and assign different question categories to appropriate persons in a disciplined way. A working software project is used as an example to illustrate the use of the framework.
Software requirements elicitation is the process of finding out the requirements for an intended software system by communicating with the appropriate stakeholders in the project (Mohanan & Samuel, 2016; Sommerville, 2005). It is the basic and most important aspect in the requirement engineering process; doing it inaccurately will have many adverse effects on the intended software like questionable software quality, late delivery, and software that cost more than its worth (Wong, Mauricio, & Rodriguez, 2017; Jabar, Ahmadi, Shafazand, Ghani, & Sidi, 2013; Zhaoyin, Yanfang, & Chao, 2009).
Gathering information from different stakeholders is challenging (Sutcliffe & Sawyer, 2013) and this leads to a more complex and subjective task; inconsistency and incompleteness in requirement specification are constantly encountered in defining and interpreting of stakeholders' needs by REs.
Furthermore, stakeholder needs change at a great rate during software system development and both the stakeholders and REs rely solely on natural language communication (Mishra, Awal, & Elijah, 2017; Lee & Zhao, 2006). Therefore, it is of great importance that both parties use a clear form of communication to provide and analyze requirements that will lead to the precise definition of the problem.
Generally, it is a common knowledge that elicitation approaches, such as Interview and Questionnaires, depend on some well-defined questioning approaches to gather information. The literature acknowledges the fact that missing or wrongly-stated questions can lead to loss of information and consequently substandard requirement specifications (Nuseibeh & Easterbrook, 2000). Substandard requirement specifications are often characterized by inconsistency and/or incompleteness. Inconsistencies occur in the process of acquiring, specifying, and changing of goals from different stakeholders' requirements specifications (Mishra et al., 2017). The frequent changes in stakeholders' requirements have particular impact on the consistencies of the overall requirement specifications. In order to deal with the inconsistencies arising from such frequent changes, requirements specifications are at times, trimmed and this often leads to incompleteness.
From anecdotal evidences, incompleteness can also result from limited coverage of the questions being asked by the interviewees or the RE directing certain questions to the wrong persons and being unable to get useful responses; he may also get conflicting responses at times, thereby leading to inconsistency in the requirement so gathered.
A critical look at the aforementioned defects in requirement specifications will reveal to the reader, two fundamental causes of most of the problems – a) frequent changes in stakeholders' requirements and b) the RE not directing certain questions to the appropriate persons. At present, not much can be done about cause (a) as it has to do with human desire; we can, however, make efforts to address cause (b) by providing guides to the RE on the construction and assignment of questions. This paper proposes the Requirement Question Classification (ReQueClass) framework to guide the RE in the classification of software requirement interview questions into categories that are directed to some recommended persons. The authors are optimistic that by providing a guide to the RE on whom to direct which questions to during requirement elicitation, the framework will solve the aforementioned problems to a large extent.
The proposed framework takes cues from Kipling's questioning technique and the Zachman's Enterprise Framework; hence, the next section of this paper presents a short backgrounds on them (i.e., Kipling's technique and Zachman's framework) to help the reader follow the subsequent sections.
The Kipling's 5W1H (What, Who, When, Where, Why, and How) technique was proposed in the early 1900s by Rudyard Kipling in a book entitled ‘Just So Stories’ (Kipling, 1902). His aim was to formulate a questioning technique that captures the majority needs of what people want to know about a news story.
The technique was later applied widely by journalists to report news (Carmagnola, 2008). Moreover, The Kipling's 5W1H method has been applied in medical field to diagnose and treat patients (Oranje, Al-Mutairi, & Shwayder, 2016), the approach helps physician to unmask information from patients completely. It has also been applied in academics to enhance students' composition writing ability such as narrative writing (Shabir, 2016) and to expand their ideas. Also important to this work is its application by Zachman (2003) to propose an enterprise architecture to explicitly document the information of an enterprise, which would normally have been kept in the heads of some certain individuals in the organization.
The Zachman Enterprise Framework uses the Kipling's 5W1H method for classification of an organisation's architecture, which is represented graphically using a matrix, with columns and rows. It has been widely adopted by system analyst (Zachman, 2003) for information systems architecture. The framework helps an organisation to breakdown its processes as illustrated in Table 1.
Table 1. Zachman Architecture Framework
Different ways to perform requirement elicitation task have been described in the literature. However, due to the nature of the problems, one elicitation technique cannot work in all situations (Tiwari & Rathore, 2017). In this section, existing uses of the Kipling's 5W1H method in requirement elicitation are briefly reviewed.
Wong et al. (2017) have proposed a general framework to perform a systematic literature review on requirement engineering topics. They noted that there are no proposals about automation to support activities to define techniques, document, and refine requirements. Therefore, recommendations were made on proposals to cover the missing points in order to improve the requirements elicitation process.
Studies by (Mishra et al., 2017; Hanif et al., 2017; Jabar et al., 2013) have proposed a refined means of requirement elicitation process.
However, the initial set of questions that maybe asked during requirement elicitation process for an intended software domain were not considered to capture stakeholders' views or concern.
Sadiq (2017) have presented a method to prioritize stakeholders' views on software requirements using a fuzzy-based approach. Stakeholders’ prioritization plays an important role to detect which stakeholder's requirements is to be implemented in which phase of the software. This study, shows that in practical usage, same requirements are viewed in different ways by different stakeholders; linguistic terminologies may be used in describing the benefits of their requirements.
The Kipling's 5W1H approach, though, has been used severally for other reasons in software engineering (Chung, Won, Baeg, & Park, 2009). A study by (Lee & Zhao, 2006) apply the approach in re-documentation of a given legacy system with UML visual models. The six dimensions were mapped to domain-specific contexts as follows: ‘Who’ are the software developers (Developers role), ‘Why’ re-documentation (Benefits), ‘What’ are the use of UML elements in various stakeholders views (UML element use), ‘Where’ are the different views located (Use-case views of the legacy system), ‘When’ is the different phases going to take place (Time), ‘How’ to construct other elements views and relationships. It is undesirable to limit oneself to usage of only one form of requirement elicitation.
This paper proposes the Kipling's 5W1H approach (see Table 3) based on the Zachman enterprise application as another approach to construct questions that can be used to elicit information to improve the requirement elicitation process. To the best of the knowledge of the authors of this paper, there has not been existing work suggesting the application of the Kipling's 5W1H pattern and Zachman framework to provide a guide to REs on whom to direct which question to during requirement elicitation.
The section presents the classification of Requirement Elicitation questions based on Kipling's 5W1H questioning technique, followed by the question sets in the later part of the section.
The Kipling's method utilizes the 5W1H questioning method. From the REs' perspective, to gather software requirement, the stakeholders should be provided with vital information on six dimensions (Oranje et al., 2016; Hart, 1996):
Furthermore, an RE aims at gathering information for an intended software system to obtain a complete and consistent understanding of the problem domain by mapping out the classifications of work done within the scope of the software.
Recall from section 1 that the Kipling's 5W1H has been widely applied by journalists, medical practitioners, academics, and enterprise framework builders. Thus, journalists, medical practitioners, students, and REs share the goal of seeking to understand and report certain activities (respectively news events, diagnosis, and software requirements) completely.
Typically, Software requirement elicitation is all about exploring the needs of individual stakeholders for an intended system such as extracting and/or discovering needs of the users and other potential stakeholders and developing a concise requirement document (Hickey & Davis, 2003).
REs conduct requirement elicitations by following a wellformed protocol of elicitation processes (Pohl, 2016) to gather information and then analyze it to categorize findings based on a set of pre-proposed questions. Thus, the understanding of an intended software domain by a RE when performing a requirement elicitation is largely determined by the pre-proposed questions. Existing requirement elicitation guidelines (Nuseibeh & Easterbrook, 2000; Hadar, Soffer, & Kenzi, 2014; Sommerville, Sawyer, & Viller, 1998), suggest starting with an exploratory formulation of Questions by interacting with users for the intended software system. For REs knowledgeable in the domain, proposing a relevant set of coherent and probing questions thereafter may not be difficult; however, this task can be challenging to REs new to the domain.
Recall that the goal of the RE is to provide a well-defined rule for one to follow so that different REs can more or less produce similar results (so that the process can allow for knowledge re-use). Simply asking REs to explore some domain areas and developing an exploratory set of questions without a set of concrete guidelines may be too abstract and time consuming.
The Kipling's 5W1H technique provides six dimensions to completely report an area of interest. The authors of this paper argue that it can benefit REs by relieving their challenges in defining the initial set of questions. The next section elaborates on the authors' view on requirement elicitation question sets and how to apply the Kipling's 5W1H information gathering approach to classify them into categories.
This subsection presents a survey of open questions asked by REs during requirement elicitation. Any software design starts with a defined design task, which is often specified by users in natural language. Therefore, the design task is user oriented and may be defined incorrectly or incompletely while the requirement elicitation process should generate formal and structured descriptions, which are engineering oriented. Asking the questions is an effective way to identify the user's real needs and to define a relatively more complete and consistent list of software requirement. Table 2 provides a set of major Open/Close ended question used during software requirement elicitation.
From Table 2, the authors derived some set of major questions used to capture stakeholders' views during requirement elicitation based on existing literatures. The existing works have proposed questions that can serve as an effective questioning set for requirements analysis to bridge the gap between problem and solution. The requirements engineer can use the question set pattern to analyze an intended software problem and assess any missing information. However, the set does not contain questions covering certain software aspects, such as goals of the system, functional limitations, stakeholders' level of expertise, deployment choice, version update, and how the system can change existing activities. These missing questions play important roles in providing a complete set of stakeholder requirements and effective mechanisms for development. This paper proposes an extension (see in Table 3) of the existing question set with suitable questions to address these concerns. Moreover, the existing question set (in Table 2) is not accompanied by a definite guide on who should be asked which question to get the most effective answer to guarantee the complete and consistent requirement specification. This concern is also addressed by the ReQueClass proposed in this paper.
Table 2. Summary of Major Question Sets for Requirement Elicitation
Table 3 proposes an additional question set to complement the existing question set reported in Table 2; an effort towards improving on the completeness of software requirements.
Table 3. Extended Question Set for Requirement Elicitation
A merger of the question sets in Tables 2 and 3, can be used to provide a complete set of information that are consistent. However, to consistently capture stakeholders' viewpoint or concerns requires grouping of questions based on who (Actors) to answer which question (Processes). To group the questions based on who to answer which question, Table 4 presents different stakeholders and questions to be assigned by each actor based on Zachman's enterprise framework. This approach will go a long way in resolving inconsistency in requirement specification by different users associated to the system.
The classification as depicted and grouped in Table 4 provides a descriptive view of different stakeholder viewpoints for requirement specification. Each cell in the table is unique and aligned with the cells immediately above and below it. Combination of the cells in one row provides a corresponding stakeholder.
Table 4. Adaptation of The Zachman Enterprise Architecture Framework
3.3.1 Matrix Columns
The columns present the information that are asked of the software system based on the Kipling's 5W1H technique.
These are:
3.3.2 Matrix Rows
Each row presents a unique view of the classification, from the views of a particular category of stakeholders. A row is assigned to each of the following stakeholders:
The Kipling's 5W1H pattern (defined in Section 3 and shown in Table 2) can be used to formulate question sets to be asked by a stakeholder group. For example, users are asked questions to gather requirements, where as, the RE can be asked questions to analyze the requirements and bridge the gap between problem and intended solution. Generally, Requirements Elicitation is a widespread challenging task. The Kipling's 5W1H method offers a structured approach to tackle these challenges, as shown in Table 3. By answering these questions based on different users' viewpoints, the requirements engineer will be able to determine a complete and consistent set of requirement and reduce conflicts between different users’ requirement.
Based on section 3.1, the ReQueClass framework is applied to classify the requirement questions of a school management system software as presented in Table 5.
Table 5. Case Study of User Requirement Specification Base on Kipling's 5w1h Technique and Zachman Framework
In Software Requirement Elicitation, a major problem is the process of providing an effective guide to requirement engineers to assign requirement elicitation questions to the right stakeholders in order to have a clear and complete requirement specification document. Essentially, this means that assigning the right question to the wrong user could lead to inconsistency and incompleteness in the software requirement specification document. This research proposes a framework which can serve as a guide to software RE on to whom to direct which question during Requirement Elicitation. Furthermore, the proposed framework uses the Zachman's framework for enterprise application and the Kipling's 5W1H information gathering approach to capture each stakeholders' viewpoint correctly and completely. The findings will be of great interest to REs who are new to a domain using the framework to serve as a guide to elicit information. Future work is to extend the technique to build a knowledge base domain for software requirement elicitation and to develop a software system to concretize the framework.