In this article, I am going to discuss top 6 characteristics of well written requirements. Requirements are key to the success of a software project.
So, how do you ensure that the requirements are well written. This is achieved by verifying the key characteristics of requirements.
Bad or incomplete requirements have been one of the top reasons for most of the projects, which fail. Standish group publishes CHAOS Report every year on the track record of software projects. The pie chart below shows the top 10 reasons for the failure of the projects, for the period 2011-2015.
As you can see incomplete requirements is one of the top reasons for the failure of the projects. So, its important to understand, how can we make sure that requirements are documented correctly.
Here are top 6 characteristics of well written requirements specifications:
The requirements must be complete, what is the meaning of completeness? It means that all the required information to implement (read Code) the requirement. There is no need to assume anything in order to implement the same. One of the important aspects of completeness is to also have measuring units, if applicable.
In case of an error, the system must exit gracefully.
I am sure, many of you must have seen this requirement before. This is an incomplete requirement as it does not provide all the information needed to implement the exit, in case of error.
A complete requirement would be as follows:
In case of an error, the system must show an error page to the users with the following message:
Oops! We have encountered some error and working on it. In the while you can go to the home page and try other options or write to us about what were you doing, so that we can help. Our email id is firstname.lastname@example.org
Consistency is an important aspect of requirements. It means that all inputs to any process, must be processed similarly. It should not happen that processes produce different outputs for inputs coming from different sources. Consistent requirements also mean that you will not find a contradicting information in the SRS document. Let’s look at the following two requirements:
Req1: The invoices will be generated and sent automatically based on the milestones achieved with a copy to the accounts department
The second requirement mentioned in the same document
Req2: The accounts department will generate the invoice based on milestones achieved and will send it to the customer.
The requirements mentioned above are not consistent as they are presenting contradictory information.
This is one of the crucial parts of requirements capturing. All the requirements included in the SRS must be feasible to implement. A requirement to be feasible must be:
Let’s look at some of the requirements below:
The developed software must be reliable and should not crash.
The developed software must be free of defects.
Both the above requirements are not feasible. There is no software which is free of defects.
Every SRS document must be modifiable. In the modern software projects, requirements are never static and don’t stop coming after the SRS document is signed off. We can’t expect the customers to stop altering the requirements or adding new requirements as we also need to look at business needs.
So the best way to manage the requirements is to manage these changes. In order to do so, we must have an SRS, which clearly identifies each and every requirement in a systematic manner. In case of any changes, the specific requirements and the dependent ones can be modified accordingly without impact the others.
Unambiguous means there could be only interpretation of the requirement. If a requirement is defined in such a manner that it can only be interpreted in one way, it means that the requirement is unambiguous. All subjective words or statements must be eliminated from the requirements.
Let’s look at this requirement:
All the screens in the system must load quickly.
Do you think, this statement is clear? Certainly not. Nothing can be understood from the word “quickly”. It must specify clearly what is the meaning of “quickly”. A better version of this requirement would be:
All the screens in the system must load within 8 seconds.
A testable requirement can be defined as a requirement, which can be tested and validated using any of the following methods:
In this manner, it is possible to ensure that the requirement has been implemented correctly.
Let’s take an example and examine if it is testable:
The system must be user-friendly.
If this is allowed to be part of the final SRS document, how will you test it once the software is developed and is ready to be delivered for the UAT. It is not testable. So a better example would be:
The user interface should be menu driven on the top of the website along with site index. A tool tip for all the text boxes must be provided.
Let me know if you feel, there could be any other points.