Article Preview
TopIntroduction
System/software requirement quality is one of the most important drivers for the success of a final system/software related product. But ironically, as stated by Kof (2005), in practice “requirements engineering is the Achilles’ heel of the whole software development process”, because requirements documents are usually inconsistent and incomplete. Cheng and Atlee (2007) identify the main reason for this as follows: “… because requirements reside primarily in the problem space[;] whereas[,] other software artifacts reside primarily in the solution space”.
A study showed that the user involvement is the most important factor for the success of the software development projects (Standish Group, 1995). Moreover, even in the cases where the user involvement is sufficient, the success is dependent on clear statement of the requirements, which appears as the third most important factor on the list. In addition, other studies showed that the underlying reason for 60 to 85% of the software errors during a system’s life time is nothing but the requirement defects (Davis, 1990; Schach, 1992; Young, 2001). On the other hand, if such defects could not be fixed at the early phases of the projects, the cost of fixing the error would dramatically increases at each phase of the development life cycle as seen in Table 1 (Young, 2001). Defects detected during requirement analysis and design phases could reduce the rework effort between 40% and 50% (Boehm, 1981; Boehm & Basili, 2001; Gause & Weinberg, 1989).
Table 1. Relative cost of fixing an error (Young, 2001)
| Phase in which the Error is Found | Relative Cost |
| Requirements Analysis | 1 |
| Design | 3-6 |
| Coding & Unit Test | 10 |
| Development Testing | 15-40 |
| Acceptance Testing | 30-70 |
| Operation | 40-1000 |
All the above studies support that, effective customer interaction and defect-free requirement engineering processes are the key factors for successful system/software development.
Pohl’s requirement engineering process model (Pohl, 1994), depicted in Figure 1, might be considered as a reference for the improvement the software requirement quality. Pohl’s model suggests focusing on the three dimensions seen in Figure 1. Stakeholders of the requirement engineering process should perform a progress on the specification, representation and agreement dimensions. Hence, tools supporting progress in any of those three dimensions would increase the success rates of software development projects.
Figure 1. Pohl’s requirement engineering model (Adapted from (Pohl, 1994))