Risks from Inadequate Some Requirement Process
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:
- 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.
3.Ambiguous requirements lead to ill-spent time and rework.
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.
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: “Roko mute 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 placed after “Roko”, the sentence will become “Roko, mute jane doo”, meaning “don’t let him go”. On the other hand if the comma id placed after “mute”, the sentence will become “Roko mute, 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:
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.
Levels of Software Requirements
Software requirements are defined at various levels of detail and granularity. Requirements at different level of detail also mean to serve different purposes. We first look at these different levels and then will try to elaborate the difference between these with the help of different examples.
- Business Requirements:
These are used to state the high-level business objective of the organization or customer requesting the system or product. They are used to document main system features and functionalities without going into their nitty-gritty details. They are captured in a document describing the project vision and scope.
2. User Requirements:
User requirements add further detail to the business requirements. They are called user requirements because they are written from a user’s perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements. They are captured in the requirement definition document.
Problems with natural language
- Lack of clarity
- Precision is difficult without making the document difficult to read.
- Requirements confusion
- Functional and non-functional requirements tend to be mixed-up.
- Requirements amalgamation
- Several different requirements may be expressed together.
4. Functional Requirements:
The next level of detail comes in the form of what is called functional requirements. They bring-in the system’s view and define from the system’s perspective the software functionality the developers must build into the product to enable users to accomplish their tasks stated in the user requirements – thereby satisfying the business requirements.
5. Non-Functional Requirements
In the last section we defined a software requirement as a document that describes all the services provided by the system along with the constraints under which it must operate. That is, the requirement document should not only describe the functionality needed and provided by the system, but it must also specify the constraints under which it must operate. Constraints are restrictions that are placed on the choices available to the developer for design and construction of the software product. These kinds of requirements are called Non-Functional Requirements. These are used to describe external system interfaces, design and implementation constraints, quality and performance attributes. These also include regulations, standards, and contracts to which the product must conform.
Non-functional classifications
- Product requirements
- Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
- Organisational requirements
- Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
- External requirements
- Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
