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:

1. 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).
2. 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”.
3. List the acceptance criteria for efficiency, portability, performance and reliability.
4. List the space constraints, legislative constraints and safety and privacy requirements for the final product.
5. 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”.
6. 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”.
7. Write using natural language and include diagrams wherever applicable. Avoid program snippets, algorithms and computation logic.
8. Separate out the requirements logically for clarity.
9. 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.
10. Assign a unique number to identify each requirement. This will help in cross-referencing inter-related requirements. It will also facilitate tracking.
11. 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).
12. 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”)
13. 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:

1. Interact with the client through meetings, end-user interviews and workshops to get consensus on the list of features.
2. Prioritize requirements and identify dependencies.
3. Prepare business flow diagrams to understand the event triggers, sequence of events and identify rules that govern the outcome of events.
4. 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.