COEPD – Center of Excellence for Professional Development Happy Learning
A requirement is basically need of the client related to business. A requirement can be a thought of something that is demanded from a system. Requirement acts as foundation for building new system or enhance existing one.
Requirement may be good or bad, complete or incomplete, perfect or ambiguous.
A requirement said to be good if it possesses following characteristics
- Complete
- Consistent
- Feasible
- Modifiable
- Unambiguous
- Testable
Complete Requirement
If user/client gives description in such case no need to assume anything while implementation. This specification is sufficient to implement application by coding it.
For example consider following requirement specification
“If an error occurs while functioning, the system must exit gracefully”.
This type of system behavior comes under incomplete requirement, because it does not provide sufficient information needed to implement the exit, in case of error.
A complete requirement for above case will be as follows:
If an error occurs while functioning, the system must show an error message if the form of new page or pop up window to the users with the following message:
Oops!!! We have encountered error while processing your request and we are working on it. For more details email us support@xyz.com
Consistent Requirement
Consistency means that all inputs to any process of application must be processed similarly. Application should not produce different outputs for inputs coming from different sources. Also time and location is irrelevant in case of consistent requirement.
Following is the example of inconsistent 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.
As requirements mentioned has almost same functionality but it is presenting contradictory information.
Feasible Requirement
In feasibility analysis related to requirement we need to check followings criteria
- Requirement need to be implementing within the given time frame and budget
- Requirement should be Implementable using the existing and chosen technology platform at client side
- Also we are checking whether some part or entire functionality of feature, which will be used by the end users can out source.
Once feasibility is checked the requirement is included in the SRS.
Consider the following examples of requirement:
“The software developed should not crash and must be reliable”.
“The developed software must be defects free”.
Above requirements are not feasible in real world. Because there is always possibility of defects in software and 100% defect free software is not feasible.
Modifiable Requirement
As we are living in dynamic world, customers may alter requirement as per business requirement. So never expect static requirement from customer end. Also there is possibility of addition of new requirement in specification from customer end as per business needs
To deal with this type of requirement, project team must manage all changes in systematic manner without affecting dependent requirement in application to reduce over work.
If the specific requirements require change then the dependent ones need to be modified accordingly without impact the others.
Unambiguous Requirement
Requirement specification should have single interpretation then we can say requirement is unambiguous. All words referring to a subject must be eliminated from the requirements.
Let’s consider following requirement:
“All the screens in the system must load quickly”.
Here we cannot understand from the word “quickly”. A complete, details of quickly word need to specified from customer end.
An improved version of above requirement would be:
All the screens in the application must load within 8 seconds.
Testable Requirement
If it is possible to test requirement and able to validate so that we can say system provide desired features
Let’s consider below example and check whether it is testable:
“The system must be user-friendly”.
Here no criterion is specified about user friendliness, so we cannot test this requirement. So a better specification would be:
The user interface should be menu driven and a tip/help for all the text boxes must be provided.
