The Requirement Cube: A Requirement Template for Business, User, and Functional Requirements With 5W1H Approach

Introduction

Requirement elicitation is an iterative process that obtains requirements from necessary stakeholders via communication, prioritization, negotiation, and collaboration, and it uses techniques from social sciences, knowledge engineering, and group dynamics rather than computer science (Zowghi & Coulin, 2005). The whole activity regarding the gathering, elicitation, and documenting of the software requirements is called requirements engineering (RE) and it is a fundamental part of the software development process (Garcia, Segura, & Aguirre, 2020). Insufficient requirement specifications are still a major failover reason for software projects. Studies show that poor quality requirements cause 12%–71% failover in information systems projects (Davey & Parker, 2015).

Problems in RE can be listed as communication challenges, natural language burdens, requirement changes, unnecessary requirements, the uncertainty of business needs, a lack of client support, unelaborate requirements engineering, and the nondeterministic nature of RE (Davey & Parker, 2015). The mistakes during RE arise from human errors (communication, participation, domain knowledge, specific application knowledge, process execution, other cognition), process errors (inadequate methods, management, elicitation, analysis, traceability), and documentation errors (Walia & Carver, 2015).

Requirements also have a terminology problem. Shareholders may refer the same requirement statement as user, software, business, system, or functional requirement. Besides, each role (customer, developer, etc.) demands different levels of requirement details. Different classifications exist and the prominent three ones are as follows (Alrumaih, Mirza & Alsalamah, 2018). Lauesen’s (2002) classification is based on data requirements, functional requirements, quality requirements, managerial requirements. Sommerville (2011) classifies requirements as user and system requirements (system requirements are classified as functional and non-functional). Wiegers & Beatty (2013) classify requirements as business, user, and functional requirements. Business requirements are related to the purpose of software development, or why the software is being implemented; user requirement is about what users will do with the software. Finally, functional requirements describe the software’s behavior based on user requirements (Wiegers & Beatty, 2013). In addition, non-functional requirements represent the system constraints, such as compatibility, reliability, performance, portability, restrictions-legality, security, and usability (Silva, Pinheiro, Albuuerque, and Barroso, 2016; Silva, Pinheiro, Albuuerque, and Barroso, 2017).