Identifying stakeholder’s needs, eliciting, categorizing and translating them into specifications is the requirement analysis process. Requirement analysis can be a long and arduous process during which many delicate psychological skills are involved. For any software, it is important to identify all stakeholders, collect their requirements and ensure they understand the implications of the software. The gap between stakeholders’ vision of the proposed software and the analysis's depiction of that software is the cause of shortcomings in analysis. If the requirements specified by analysts can be tested against stakeholders' expectations, then this gap might be narrowed, and better solutions might be resulted. This paper discusses the impact of the activities of the analysis phase on the development process and on the software itself. It describes the development of the ReqVerifier tool and proposes a systematic approach on how to test software requirements and verify them against stakeholders’ vision in order to develop a good software requirement for a quality software.
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 [
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 [
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 [
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 [
In 1998, Kotonya and Sommerville [
In 2001, Pressman [
In 2003, Wiegers [
In 2005, Stellman and Greene [
In 2007, Gorschek and colleagues [
In 2008, Jiang [
In 2009, Berkovich and colleagues [
In 2010, Pandey and colleagues [
In 2012, Torkar and colleagues [
In 2013, Khan and colleagues [
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 [
Requirements are actually customer’s statement of scope or interest. One peculiar aspect of human nature is that we fail to understand each other completely since the human communications are imprecise naturally. Requirement gathering is also a form of human communications in which an attempt is made to pass on complex ideas from one mind to another. Requirements are also a sparse form of communications, using simple written words to attempt for precision [
Requirement elicitation is non-trivial because you can never be sure you get all requirements from the users by just asking them what the system should do. Requirement elicitation practices include interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping. Requirement elicitation is essential because it is the source of raw data about the problem domain [
Requirement management is a continuous process throughout any project. Its purpose is to ensure that an organization documents verify and meet the needs and expectations of its users and internal or external stakeholders [
A good process for managing change is essential. Lack of process change control leads to confusion and accordingly leads to bad quality products, overruns and overspends. Change control in requirement management is the process by which any needed changes to the requirement baseline are managed. Whether the change is big and complex or small and simple they still need to travel the same initial route into the change control process. With this in mind, it seems that change is inevitable and therefore a systematic way is needed to deal with it. To create awareness, this process should be agreed on and in place before the baseline is agreed upon.
V & V phase is critical to successful system product development. It is necessary because the designers and implementers of computer based systems are human; who could make errors. These errors might result in undetected faults in delivered systems. Faults can result in dangerous failures causing loss of life, financial loss or property damage. The mission of V & V is therefore to find and correct errors as early as possible in the development life cycle [
To understand the nature of the program(s) to be built, the analyst must understand the information domain for the software, as well as required function’s behavior, performance, and interface [
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.
With respect to the analysts’ perspective, analysts use the ReqVerifier tool to prepare two types of tests. The first type is true or false statements about the system and its functional and non-functional specifications. The second type is a scenario based test. This test will introduce input values to a predefined process and the user is requested to input the value or the behavior of the system, which he expects the system should be able to do.
These tests are uploaded to and stored in the database of the ReqVerifier tool. Also, in this perspective, analysts prepare and store the expected answers of these tests.
With respect to this perspective, stakeholders download the two types of tests, which were prepared by the ana-
lysts and stored in the ReqVerifier database. For the first type of tests (e.g. True/False questions), the stakeholders provide the answers and store them in the ReqVerifier database. However, for the second type of tests (e.g. the Input Output Scenario test), the stakeholder could download the multiple input-process-output scenarios for verification. The stakeholder does a series of input-process-output scenarios pre-loaded by analysts. The stakeholder stores the answers in the ReqVerifier database. Stakeholders can also add extra feedbacks about the specifications of the test scenarios and extra concerns and observations about the desired and expected facilities, which were not specified or covered in the tests. This feedback is also stored in the ReqVerifier database.
With respect to the testers’ perspective, testers request the report from the Req Verifier tool. Once this request is received, the ReqVerifier tool compares the analysts’ expectations of the tests with the tests’ answers received from the stakeholders. It calculates a percentage out of the True Or False Specification Test of how well the stakeholder knows the system. This could give an indication of how well stakeholders’ requirements have been understood by the analysts. On the other hand, for the second type of the tests, the tool compares the output desired by the stakeholder in the Input Output Scenario with the analysts’ expectations entered by the analysts. The tool will compile a report about the comparisons’ results of the conducted tests. The tool compiles this result together with the stakeholders’ feedback as a report stored in the database of the tool for the testing team. The reports add the additional feedback from the stakeholder for the analysts to see. This comparison will show how close the analysts’ expectations were with the test answers of the stakeholders. This would also give an indication of how close the analysis was to what the users expected of the system. In addition, the users can add feedback about the system.
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.