Software requirements are actually customer’s statements of scope. They are defined as a set of guidelines, conditions, capabilities or abilities that a system must provide, conform or be consistent with. They deal with functional and nonfunctional requirements of a system. They should be documentable, actionable, measurable, testable, traceable, related to identified business needs or opportunities and defined to a level of detail sufficient for software design.

In requirement finalization process, the stakeholders play an important role. A stakeholder can be defined as anyone who is directly or indirectly affected by the system being developed or deployed. Stakeholders are broadly classified into two major categories: 1) user, who uses the system and 2) customer, who requests for the development of the system and be responsible for approving it. Requirement analysis plays an important role in the software development process. It serves as a baseline for any software project. It must consider the system in all of its stages. From the small units (e.g. objects or modules) to the integration phase, it fits in a broader and a bigger picture. Requirement analysis is critical to the success of a software project. It depends on the correctness and completeness of the software requirements [1] [2] . Failing to successfully analyze the requirements will be fatal for the software at hand and will lead to problems in delivering the required products on time with the right quality. Realizing a high quality application is a tedious development activity. Many projects fail because the analysis phase was immature and did not fully address the system’s specifications. A number of studies conducted on this issue have reported that the main reason of project failure is due to employing bad requirement engineering practices. In [3] , it has been reported that 70% of the systems errors are ordinarily due to the improper requirements and remaining 30% are because of the design faults.

The introduction of modern technological applications can enhance and improve the software development process. In the IT community, this was realized through the usage of computer aided software engineering (CASE) tools. CASE tools are being used to facilitate activities during software development process [4] . As a result, productivity can be increased and quality can be improved. CASE tools can help in managing the complex tasks of the requirement analysis process.

This paper introduces the activities of the analysis process and the impact of each activity on the development process and on the software itself. It proposes a systematic approach and describes the development of the ReqVerifier tool to test and verify the analyzed requirements of the software against the stakeholders’ needs and expectations.

This paper is structured into five sections. Section 2 introduces the literature review. Section 3 discusses the requirement analysis and its related issues. Section 4 demonstrates the development of the ReqVerify tool. Finally, Section 5 provides the concluding remarks and future prospects.

The requirement analysis is an important phase in the software development process. In 1992, Christel and Kang [5] identified the following problems that indicate the challenges of the requirement analysis:

1) Problems of scope: The boundary of the system is ill-defined.

2) Problems of understanding: The users are not completely sure of what is needed?

3) Problems of volatility: The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility.

In 1997, Alfeche [6] published a guide on good requirement engineering practices. He considered requirement elicitation as a major part of a systems analysis.

In 1998, Kotonya and Sommerville [7] have mentioned that any software development process has to involve some requirement analysis.

In 2001, Pressman [4] specified that the analysts job is to assure that proper function of the system will be achieved, and that the requirement analysis process is intensified and focused specifically on software.

In 2003, Wiegers [8] stated that most IT systems fail to meet expectations because the requirements didn’t address the right issues. He showed how to collect and present a good requirement specification.

In 2005, Stellman and Greene [9] described requirement management to be the process of documenting, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. In the same year, Abran and Moore [10] stressed the fact that requirement analysis involves frequent communication with system users to determine specific feature expectations, resolution of conflict or ambiguity in requirements as demanded by the users.

In 2007, Gorschek and colleagues [11] indicated the importance of analysis in comparing incoming requirements to the production strategies of the organization. In the same year, Zagajsek and colleagues [12] proposed a requirement management process model for software based legacy systems. They mentioned that using incomplete requirement specification and adopting improper requirement management techniques are the main reason behind any failed project.

In 2008, Jiang [13] presented requirement engineering process as a research object by proposing a formal method for describing the processes. He also highlighted different tools and technologies that can be used during the requirement engineering process. In the same year, Cheng and Liu [14] presented a framework, which uses view-based requirement elicitation techniques to merge different viewpoints of the stakeholders. Also in this year, Mishra and colleagues [15] highlighted the importance of requirement engineering and indicated that the backbone for the project success is selecting the right technique.

In 2009, Berkovich and colleagues [16] wrote about requirement analysis, specifically about validation and verification and stakeholder integration in the development process. They explained that requirement validation and verification ARE the process of checking whether the requirements, as identified, do not contradict the expectations about the system of various stakeholders, and do not contradict each other. It is sort of a requirement quality control.

In 2010, Pandey and colleagues [17] emphasized that it is extremely important to execute planning phase independently to achieve an effective requirement management. In the same year, Pavanasam and colleagues [18] proposed a model for requirement inspection and stated that the requirements change management and requirement analysis phases play an important role in software development process.

In 2012, Torkar and colleagues [19] described how analysis can predict the impact of requirement change. Also in 2012, Gorschek and colleagues [20] have concluded that if analysis is performed, then implementation costs and resources can be estimated for requirement comparison and prioritization.

In 2013, Khan and colleagues [21] discussed software requirement issues and provided a review on how to manage them. They studied existing methodologies for resolving and managing software requirements.

Requirement analysis is an early stage in the more general activity of requirement engineering which encompasses all activities concerned with eliciting, analyzing, documenting, validating and managing software or system requirements [7] . These activities are described in the following sections.

The gap between stakeholders’ vision of the proposed solution and the analysts’ depiction of that solution is the cause of shortcomings in analysis. To narrow this gap, researchers were challenged to find a way to verify the requirement specifications against stakeholders’ expectations. As a step forward in this direction, the current author proposes the ReqVerifier tool, which is developed for this purpose. The intension of the current author is to make the design of the tool simple and straight forward.

The tool depends on three perspectives: 1) analyst perspective; 2) stakeholder perspective and 3) tester perspective. The testing team could use the ReqVerifier tool to test and verify the requirement specification prepared by the analysts against the results and feedback on the requirement specifications received by the stakeholders. The ReqVerifier tool offers three main processes in accordance to the three perspectives: 1) Manage analysts’ perspective; 2) Manage stakeholder perspective and 3) Manage tester perspective. These processes are further discussed below. Using this tool, the analysts, software developers and testers are expected to gain some knowledge about the product, which is to be developed. It could help them in making their discussion with the stakeholders more organized and focused.

All software requirements must be defined to develop high quality software. The basic technique used is requirement elicitation which is a critical part of the project and different techniques are required to determine the requirements. Fundamental way is to perform analysis in order to identify people, processes and different resources involved in the project. Every project should have been given an amount of analysis. Failure of a project is due to lack of some functional and non-functional requirements.

This paper attempted to study the requirement analysis phase and some of its related issues. The current author proposed the ReqVerifier tool as one effort of CASE to help the software engineering community to resolve or at least to reduce the conflicts that might occur between the software developers and the stakeholders. The tool helped in providing information in both sides to the software developers and the stakeholders as a cross check technique. This would eventually lead to the development of a quality software. Analysts, software developers and testers could view reports of the test cases’ results and stakeholders’ feedback to make conclusions about the specifications they had derived from the stakeholders’ requirements and how close they were from the stakeholders’ expectations.

As a future work, the author would like to enhance the tool to be able to: classify reports according to results, associate priority with test cases, represent tests as XML files derived from development itself and store them in the tool’s database and add specifications interrelations.