8 Best Practices for Software Requirement Documentation
17 Aug. 2012 Software Development
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:
- Complete & Accurate
- 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.