Requirement gathering, analysis and software requirement documentation plays a vital role in the entire software development life-cycle.
The requirements depict how the business stakeholder visualizes the system, its behavior, its interaction with the users, and the system’s environment based on which the entire business operation runs.
The software requirement documentation process suffices the need of many stakeholders varying in the areas of expertise. Hence a well-documented requirement document proves to be very essential.
However certain practices need to be implemented for effectively documenting the requirements. They are as follows:
 |
| Image source:: FreeDigitalPhotos |
- Tangible
- Atomic
- Valuable/Important
- Consistent
- Complete & Accurate
- Verifiable
- Concise
- Implementation/Design Less
The requirements should be concrete and measurable. The requirement should not include abstract terms like good, excellent and efficient. Rather quantitative and more measurable terms should be used.
Example: The High Level requirement is stated as “The system should have good performance.”
This requirement should be presented as “The page should be loaded in 5 seconds.”
The requirements should be precise and presented at the basic level. The high level requirement should be broken down to its atomic level in order to capture immense clarity in the document. All the requirements should be presented as single and separate entities.
Example: The High Level requirement is stated as “The application should be able to create new and update existing Work Orders.”
The requirement should be presented as “The application should have the capability to create new Work Orders. The application should have the capability to edit/update existing Work Orders.”
The client is the best judge for his business needs. Hence taking into consideration and documenting requirements viewed by the client as important is generally the best idea. The requirements perceived by the client as important cannot be omitted.
The requirement document must not contain conflicting requirements. User needs to make a trade-off decision in case of conflicts. The requirements should be consistent with each other so as to provide clarity to business stakeholders.
The requirements should not be ambiguous and open ended but complete and well defined. They should be accurate and should reflect the client’s need and business perspective.
Example: The requirement is “The application shall be integrated with Payment gateways.” The requirement should be stated as “The application shall be integrated with Payment Gateways – PayPal and DirecPay.”
Requirements should be verifiable under the given constraints of expertise and environment. The non-functional requirements should have a quantitative value so that they can be verified.
Example: The High Level requirement is “The application should display good performance”.
The requirement should be stated as “The application should be able to load the page in 5 seconds.”
This document caters to the need of several stake holders with expertise in different domains. Hence it is essential that it should be concise and convey its intended meaning to all its stakeholders.
The requirement document should not include any implementation/design perspectives. It should only include the solution to the stakeholder’s need. And not any implementation or design choices.
The above discussed points serve as guidelines for a well defined Software Requirement Documentation process.
Article author - R. Parmar
Comments by readers will be forwarded to the author. Response to comments will be posted subject to the editorial guidelines & policies of Rishabh Software.
Rishabh Software, a CMMI Level-3 technology company, focuses on cost-effective, qualitative and timely
delivered Software Development, Business Process Outsourcing (BPO) and Engineering Services. Contact us today or call 1-877-RISHABH (1-877-747-4224)!
We also recommend:
- Software Testing Best Practices – Part I
- Software Assumptions – Principle source of failure
- Custom Software Development Services
- Sarbanes-Oxley Compliance Software
- Software Regression Testing Best Practices
 | Enjoyed this article! Share it with others. |
Fastest Way to Carry Out Application Performance Testing
Comments
Leave a Reply
3 Advantages of Microsoft Dynamics CRM Integration with SharePoint-
Get in touch with us
August 22, 2012
Point (3) seems to be saying that a requirements document should contains requirements!
August 23, 2012
Hi Req. Thanks for your interest in the post. Point 3 highlights a simple fact – The requirements perceived by the client as important cannot be omitted from the document. Do let us know if you need more information or clarification on the same.