The document outlines the characteristics of good software requirements, emphasizing that they should be complete, consistent, feasible, modifiable, unambiguous, and testable. Good requirements should provide all necessary information without assumptions, avoid contradictions, be implementable within time and budget, accommodate changes, have clear interpretations, and be verifiable through testing. Highlighting these attributes aims to reduce project failures due to poor requirements in the IT industry.

1. CHARACTERISTICS OF REQUIREMENTS
SOFTWARE REQUIREMENT ENGINEERING
PREPARED BY MUHAMMAD SAAD
B.S SOFTWARE ENGINEERING (PUCIT)

2. CHARACTERISTICS OF GOOD REQUIREMENTS
Bad requirements have been one of the top reasons for most of the projects, which fail and the rate of
failure is pretty high in the IT industry. So I thought to highlight key aspects of the software requirements,
which make requirements good and worthy.
Any good requirement should have these 6 characteristics:
 Complete
 Consistent
 Feasible
 Modifiable
 Unambiguous
 Testable

3. COMPLETE
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.
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 support@abc.com

4. CONSISTENT
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 these requirements:
 Req1: The invoices will be generated and sent automatically based on the milestones achieved with a
copy to the accounts department
 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.

5. FEASIBLE
This is one of the crucial part of requirements capturing. All the requirements included in the SRS must be
feasible to implement. A requirement to be feasible must be:
 Implementable within the given time frame and budget
 Implementable using the existing and chosen technology platform
A feature, which will be used by the end users
Let’s look at some of the requirements below:
1. The developed software must be reliable and should not crash.
2. The developed software must be free of defects.
Both the above requirements are not feasible. There is no software which is free of defects

6. MODIFIABLE
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.

7. UNAMBIGUOUS
Unambiguous means a single interpretation. 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.

8. TESTABLE
A testable requirement can be defined as a requirement, which can be tested and validated using any of the following methods:
 Inspection
 Walkthrough
 Demonstration
 Testing
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.