A Requirement records a need, condition, or criterion that a product or activity is expected to meet. It makes the expectation identifiable and connects it to the product context, related requirements, and supporting evidence.
When to use it
- Use it when a need or acceptance criterion must be tracked through development.
- Use it when the team needs to review where a requirement came from and how it will be verified.
Key information
- Definition: requirement ID, name, description, category, and priority.
- Intent: origin, focus, acceptance criteria, and constraints.
- Evaluation: verification method and validation status.
Common relationships
- Requirement links a Product, Item, Project, or Program to the recorded need.
- Subrequirement breaks a broader requirement into related child requirements.
- Compliance Reference connects the requirement to a supporting Document.
Working with this record
Write the criterion so a reviewer can understand what satisfies it. Identify a verification method and link supporting documents. Review the validation information and evidence together; the existence of a connection alone does not demonstrate that the criterion has been met.
Example
A leakage Requirement for Pump P-100 records the agreed leakage limit and test method. A test report is connected through Compliance Reference. Reviewers use the criterion and the report to assess whether the pump meets the requirement.
Choosing the right type
Choose Requirement for an expectation or acceptance criterion. Choose Document for the specification or evidence containing detailed information, and Task for the activity needed to verify the requirement.
