A practical metamodel for requirements management based on the IIBA Business Analysis Body of Knowledge (BABOK v3) requirements classification. Covers all five BABOK requirement types plus context elements for stakeholders, assumptions, constraints, use cases, and acceptance criteria.
| Type | Shape | Colour | Properties | Description |
|---|
| Business Requirement | rounded | #42A5F5 (blue) | Priority, Status, Source | High-level need or goal of the organisation |
| Stakeholder Requirement | rounded | #42A5F5 | Priority, Status, Source | Need of a specific stakeholder or stakeholder group |
| Functional Requirement | rounded | #42A5F5 | Priority, Status, Complexity | A capability the solution must provide |
| Non-Functional Requirement | rounded | #42A5F5 | Priority, Status, NFR Category | A quality or constraint on the solution (performance, security, etc.) |
| Transition Requirement | rounded | #42A5F5 | Priority, Status | A capability needed only during the transition to the new solution |
| Type | Shape | Colour | Properties | Description |
|---|
| Stakeholder | rectangle | #66BB6A (green) | Role, Influence, Interest, Contact | A person or group with an interest in the requirements |
| Assumption | rectangle | #66BB6A | Status, Impact If Wrong, Validation Approach | Something believed to be true but not yet verified |
| Constraint | rectangle | #66BB6A | Constraint Type, Rationale | A restriction on the solution (business, technical, regulatory, organisational) |
| Use Case | rectangle | #66BB6A | Actor, Complexity, Precondition | A scenario describing how an actor interacts with the solution |
| Acceptance Criterion | rectangle | #66BB6A | Verification Method, Pass/Fail Threshold | A measurable condition that must be met for a requirement to be accepted |
| Relationship | Style | Description |
|---|
| Traces To | dashed, arrow | Traceability between requirements at different levels |
| Raised By | solid, arrow | A requirement is raised by a stakeholder |
| Depends On | dashed, arrow | One requirement depends on another |
| Verified By | solid, arrow | A requirement is verified by an acceptance criterion |
| Elaborated By | dashed, arrow | A requirement is elaborated by a use case or lower-level requirement |
| Constrained By | solid, arrow | A requirement is constrained by a constraint |
| Assumes | dashed, arrow | A requirement relies on an assumption |
| Includes | solid, arrow | One requirement includes another |
| Conflicts With | dotted | Two requirements are in conflict |
| Association | solid, none | General unconstrained connection |
- Priority — Must Have, Should Have, Could Have, Won’t Have (MoSCoW)
- Requirement Status — Draft, Proposed, Approved, Implemented, Verified, Deferred, Rejected
- Complexity — Low, Medium, High
- NFR Category — Performance, Security, Usability, Reliability, Scalability, Availability, Maintainability, Portability, Compliance, Accessibility
- Influence Level — High, Medium, Low
- Interest Level — High, Medium, Low
- Assumption Status — Unvalidated, Validated, Invalidated
- Impact Level — High, Medium, Low
- Constraint Type — Business, Technical, Regulatory, Organisational
- Verification Method — Demonstration, Test, Inspection, Analysis
Based on the IIBA Business Analysis Body of Knowledge (BABOK) v3 requirements classification.