Article Preview
Top1. Introduction
Requirement management process plays a very important role in the software engineering process. It is composed of requirement definition, analysis, validation and verification. High-quality users’ requirements management process is expected with the view to accurately describe and represent the software requirements and also meet the needs of the customers (Abbas, Alam, Iqbal, & Ajmal, 2019; Bulajic, Stojic, & Sambasivam, 2014; Lee, In, & Kazman, 2014). Operations in private and government organizations are being automated using customized applications. These software need proper analysis, validation, verification and implementation using variables from the users’ requirement definition document (SRS document). Our concern in this paper is on Software Requirement Validation.
Requirements are elicited through consultation with client-stakeholders during the requirements engineering phase. The client-stakeholders are end-users, customers, decision-makers or developers. Additionally, the elements of the business environment (i.e. Political, Social-cultural, Economic, Information and Communication Technology, and Legal environment) form part of the variables to be considered by client-stakeholders when defining operational requirements for their businesses (Muqeem & Beg, 2014). Thus the process of gathering users’ business requirements for software development can be a difficult task when requirements are driven by the components of the business environment which are mostly controlled by the government policies, beliefs of people (i.e. culture and religion) and technological advancement.
User requirements are among the factors that influence a software project. The software performance will be poor if requirement are not properly captured and understood. As a result, the customers’ needs will not be met and eventually the software may be abandoned (Abbas et al., 2019; Lee et al., 2014). Therefore, the adequate understanding of users’ requirements is key to software analysis and design and it is critical to the success of software systems (Akinnuwesi, Uzoka, Olabiyisi, & Omidiora, 2012; Akinnuwesi, Uzoka, & Osamiluyi, 2013; Akinnuwesi, Uzoka, Olabiyisi, Omidiora, & Fiddi, 2013). It is imperative for a software engineer to understand the needs and requirements of the users as emphasized in the ISO 13407 standard (ISO, 1999).
There are some instances whereby clients could not state a number of important details during requirement gathering due to omission, forgetfulness or inability to express their needs in a way that requirement engineers will understand (Abbas et al., 2019; Walia & Carver, 2009). Software requirement engineering process has been identified as one of the most sensitive processes in software development life cycle (Carreño & Winbladh, 2013; Khanh, Daengdej, & Arifin, 2017). In this light, it becomes pertinent to carry out requirement validation to ensure that users’ needs are well stated in the SRS document in an understandable format that is known to both the client and the requirement engineer.
Our focus in this paper is to identify various techniques that could be used for software requirement validation and hence carry out a SWOT analysis of the SRV techniques with emphasis on their strengths, weaknesses, opportunities and threats (SWOT) vis-à-vis the involvement of end-users in SRV process. We opined to identify a SRV technique(s) that could be considered best and have a good level of user involvement in the SRV process. SRV is very essential in the software development process because it helps to ascertain: (1) if the system behaves as described in SRS document; (2) if the users’ requirements (i.e. functional and non-functional) are well recorded; (3) if the software functions as described in the SRS document; and (4) If the system architecture matches with the specifications in the SRS document. In light of this, we defined research questions to guide our discussion. We did a systematic literature review to identify and classify SRV techniques based on the guidelines in (Kitchenham, 2004, 2012).