Project Toolkit

Requirements

Requirements

Requirements

Capturing, managing, and tracing business and system requirements.

Requirements Management

Requirements management ensures that stakeholder needs are captured, documented, and traced through to delivery.

What is a Requirement?

Definition: A requirement is a statement that describes what a system must do or a quality it must have to satisfy stakeholder needs.

Requirement Types

Type Description Example
Business What the organisation needs “Reduce order processing time by 50%”
Stakeholder What users need “Users need to track order status”
Functional What the system must do “System shall display order status”
Non-functional How the system performs “Page load time < 2 seconds”
Transition What’s needed for implementation “Migrate 5 years of order history”

Requirements Hierarchy

flowchart LR A[Business
Requirements] --> B[Stakeholder
Requirements] B --> C[Solution
Requirements] C --> D[Functional] C --> E[Non-functional] classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D,E blue

Good Requirements

Requirements should be:

Characteristic Description
Clear Unambiguous, single interpretation
Complete Contains all necessary information
Consistent No conflicts with other requirements
Testable Can be verified objectively
Traceable Linked to source and implementation
Prioritised Importance is understood
Feasible Achievable within constraints

Requirements Process

flowchart LR A[Elicit] --> B[Analyse] B --> C[Document] C --> D[Validate] D --> E[Manage] classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D,E blue
Activity Purpose
Elicit Gather requirements from stakeholders
Analyse Understand, clarify, and prioritise
Document Record in appropriate format
Validate Confirm requirements are correct
Manage Track changes and trace delivery

Documentation Formats

Format Best For
User stories Agile projects, user perspective
Use cases Complex interactions, scenarios
Shall statements Formal specifications
Process models Workflow requirements
Prototypes UI/UX requirements

User Story Format

As a [role]
I want [capability]
So that [benefit]

Shall Statement Format

The system shall [function]
when [condition]
so that [rationale]

Requirements Prioritisation

MoSCoW Method

Priority Meaning
Must have Essential, project fails without
Should have Important, but can work around
Could have Nice to have if time permits
Won’t have Out of scope for this release

Requirements Traceability

Traceability links requirements to:

  • Source - Where did it come from?
  • Related requirements - What depends on it?
  • Design - How is it being implemented?
  • Test cases - How is it being verified?
  • Deliverables - Where is it delivered?

Traceability Matrix

Req ID Source Design Test Status
REQ-001 BRD-1 DES-05 TC-12 Complete
REQ-002 User workshop DES-08 TC-15 In progress

Managing Requirements Changes

flowchart LR A[Request] --> B[Assess
Impact] B --> C[Approve/
Reject] C --> D[Update
Baseline] D --> E[Communicate] classDef blue fill:#108BB9,stroke:none,color:#fff class A,B,C,D,E blue

All requirement changes should:

  • Be formally requested
  • Have impact assessed
  • Follow approval process
  • Update traceability
  • Be communicated to stakeholders

Common Pitfalls

Pitfall Mitigation
Vague requirements Use clear, testable language
Missing requirements Thorough stakeholder engagement
Scope creep Strong change control
Gold plating Stick to documented requirements
Requirements churn Establish baseline, manage changes
Lost traceability Maintain traceability matrix

Requirements Checklist

  • All requirement types identified?
  • Requirements clearly documented?
  • Prioritisation completed?
  • Stakeholders validated requirements?
  • Traceability established?
  • Change process defined?
  • Baseline established?
Last updated: 13 January 2026
Themes

Planning

Delivery