The Requirements Definition document contains a list of all functions and constraints of a system along with short descriptions for each. The detailed descriptions are provided in the Requirements Specification document. The descriptions in the Requirements Definition are customer oriented and are prepared by a business analyst.
The Requirements Definition document will contain the following items:
- Specify the behavior of the system and the project objectives (what the system is expected to do) but not the implementation details (how the system achieves its objectives).
- List both the functional and non-functional requirements of the system. Functional requirements are the operations that the user can perform using the system. Non-functional requirements are constraints such as “The system should be able to handle traffic of 100 transactions per hour” or “The system should be installable as a windows executable”.
- List the acceptance criteria for efficiency, portability, performance and reliability.
- List the space constraints, legislative constraints and safety and privacy requirements for the final product.
- Specify software, hardware and programming language constraints if any. For example, “The application should be developed using open source software PHP, My SQL and Apache web server”.
- Specify requirements that are a result of company policy or standard procedure. For example, “The training manual and test plans should be delivered during the user acceptance testing phase”.
- Write using natural language and include diagrams wherever applicable. Avoid program snippets, algorithms and computation logic.
- Separate out the requirements logically for clarity.
- Specify the reason for each requirement. This will be useful when a requirement is altered at a later stage. It will also help the development team to understand customer expectations.
- Assign a unique number to identify each requirement. This will help in cross-referencing inter-related requirements. It will also facilitate tracking.
- Define system interfaces briefly. Interfaces may be procedural (external system whose service is accessed by our application) or data (external system with which data / messages are exchanged).
- List the critical delivery deadlines if any. (e.g. “The product must be delivered before <specific date> in order to be of any use to the organization”)
- Define the requirements in a way that they can be verified in the end product. For example “The application should be easy to use” is vague and subject to individual interpretation. Instead use a sentence such as “The product should conform to W3C standards”.
Important associated tasks to be done before formulating a Requirements Definition:
- Interact with the client through meetings, end-user interviews and workshops to get consensus on the list of features.
- Prioritize requirements and identify dependencies.
- Prepare business flow diagrams to understand the event triggers, sequence of events and identify rules that govern the outcome of events.
- List the user types and their roles.
The Requirement Definition should be reviewed, approved and signed-off by all stakeholders to ensure accuracy and completeness of the product’s features. A good Requirement Definition makes sure that all project participants understand what has to be accomplished and is a basis for accurate cost and schedule estimation. Bear in mind the business, technical and end user perspectives while defining requirements.