Description
Why perform requirements engineering?
According to the figures reported in the Standish Group’s Chaos Report of 2006, much has improved in the execution of software projects in the twelve years between 1994 and 2006. While about 30 percent of the software projects investigated in 1994 failed, it was a mere 20 percent in 2006. The number of projects that exceeded time or budget constraints significantly and/or did not meet customer satisfaction dropped from 53 percent to 46 percent [Chaos 2006]. Jim Johnson, chairperson of the Standish Group, names three reasons for the positive development of the figures since 1994. One is that the communication of requirements has much improved since ten years ago. These figures are of importance since how the requirements of a system are handled is a significant cause for project failures and/or time and budget overruns.
Requirements engineering as a cause of errors
According to past studies, approximately 60 percent of all errors in system development projects originate during the phase of requirements engineering [Boehm 1981]. These errors, however, are often discovered only in later project phases or once the system has been deployed because incorrect or incomplete requirements can be interpreted by developers in such a fashion that they are subjectively sound or (subconsciously) complete. Missing requirements often remain undetected during design and realization because developers trust the requirements engineers to deliver high-quality work. Developers implement whatever the requirements document says or what they believe it to be saying. Unclear, incomplete, or wrong requirements inevitably lead to the development of a system that does not possess critical properties or possesses properties that were not requested.
Costs of errors during requirements engineering
The later in the development project a defect in the requirements is corrected, the higher are the costs associated with fixing it. For instance, the effort to fix a requirements defect is up to 20 times higher if the correction is done during programming as opposed to fixing the same defect during requirements engineering. If the defect is fixed during acceptance testing, the effort involved may be up to a 100 times higher [Boehm 1981].
Symptoms and causes of deficient requirements engineering
Symptoms for inadequate requirements engineering are as numerous as their causes. Frequently, requirements are missing or not clearly formulated. For instance, if the requirements do not reflect customer wishes precisely or if the requirements are described in an imprecise way and thus allow for several interpretations, the result is often a system that does not meet the expectations of the client or the users.
The most common reason for deficient requirements is the misconception of the stakeholders that much is self-evident and does not need to be stated explicitly. This results in problems in communication among the involved parties that arise from differences in experience and knowledge. To make matters worse, it is often the case that especially the client wishes for quick integration of recent results into a productive system.
The significance of good requirements engineering
The increasing importance of software-intensive systems in industrial projects as well as the need to bring more innovative, more individual, and more comprehensive systems to market and the need to do so quicker, better, and with a higher level of quality calls for efficient requirements engineering. Complete requirements free from defects are the basis for successful system development. Potential risks have to be identified during requirements engineering and must be reduced as early as possible to allow for successful project progress. Faults and gaps in requirement documents must be discovered early on to avoid tedious change processes.