Inadequate Requirement Process Risk

From the above discussion, it should be clear that the requirements play the most significant role in the software development process and the success and failure of a system depends to a large extent upon the quality of the requirement documents.

Following is a list of some of the risks of adopting an inadequate requirement process:

1. Insufficient user involvement leads to unacceptable products.
   If input from different types of user is not taken, the output is bound to lack in key functional areas, resulting in an unacceptable product. Overlooking the needs of certain user classes (stake holders) leads to dissatisfaction of customers.
2. Creeping user requirements contribute to overruns and degrade product quality.
   Requirement creep is one of the most significant factors in budget and time overruns. It basically means identifying and adding new requirements to the list at some advanced stages of the software development process. The following figure shows the relative cost of adding requirements at different stages.

Requirement Origin and Comparative Costs

3.  Ambiguous requirements lead to ill-spent time and rework.
   Ambiguity means that two different readers of the same document interpret the requirement differently. Ambiguity arises from the use of natural language. Because of the imprecise nature of the language, different readers interpret the statements differently. As an example, consider the following Urdu Phrase: “Rooko mut jane doo”. Now, depending upon where a reader places the comma in this statement, two different readers may interpret it in totally different manner. If a comma is palced after “Rooko”, the sentence will become “Rooko, mut jane doo”, meaning “don’t let him go”. On the other hand if the comma id placed after “mut”, the sentence will become “Rooko mut, jane doo”, meaning “let him go”. Ambiguous requirements therefore result in misunderstandings and mismatched  expectations, resulting in a wasted time and effort and an undesirable product.

Let us consider the following requirement statement:

The operator identity consists of the operator name and password; the password consists of six digits. It should be displayed on the security VDU and deposited in the login file when an operator logs into the system.

This is an example of ambiguous requirement as it is not clear what is meant by “it” in the second sentence and what should be displayed on the VDU. Does it refer to the operator identity as a whole, his name, or his password?

4. Gold-plating by developers and users adds unnecessary features.
   Gold-plating refers to features are not present in the original requirement document and in fact are not important for the end-user but the developer adds them anyway thinking that they would add value to the product. Since these features are outside the initial scope of the product, adding them will result in schedule and budget overruns.
5. Minimal specifications lead to missing key requirements and hence result in an unacceptable product. As an example, let us look at the following requirement. The requirement was stated as: “We need a flow control and source control engineering tool.” Based upon this requirement, system was built. It worked perfectly and had all the functionality needed for source control engineering tool and one could draw all kinds of maps and drawings. The system however could not be used because there was there was no print functionality.

Let us now look at the following set of requirement statements for another system:

• The system should maintain the hourly level of reservoir from depth sensor situated in the reservoir. The values should be stored for the past six months.
• AVERAGE: Average command displays the average water level for a particular sensor between two times.

This is another case of minimal requirements – it does not state how the system should respond if we try to calculate the average water level beyond the past six months.

6. Incompletely defined requirements make accurate project planning and tracking impossible.

In the next we will discuss about Levels of Software Requirements.