Requirements - Strategic Alignment, Vision, and Roadmap - S04 - Meeting Needs

The solution design should be able to meet the stated user needs and overall business objectives/drivers.

Requirement description

This requirement assesses whether the solution has been designed to address the needs of its intended users whilst supporting the wider objectives of the organisation, programme or service.

The architecture should provide a clear line of sight between identified user needs, business drivers and solution design decisions. There should be evidence that needs have been understood, validated and translated into architecture, product and delivery decisions.

The solution does not need to satisfy every need perfectly, but there should be clear evidence that trade-offs have been understood and consciously managed.

In simple terms:
Can the team demonstrate that the solution has been designed to solve the right problem for users whilst supporting the intended business outcomes?

Scoring rubric table – User Needs and Business Objectives Alignment

Score What it looks like Typical evidence Key gaps / risks
0 No evidence that user needs or business objectives have informed the solution design. Architectural decisions appear disconnected from the intended outcomes. No documented user needs.
No business objectives.
No rationale linking design decisions to outcomes. 		Significant service risk.
Solution may fail to deliver value or solve the intended problem.
High risk of costly rework.
1 Limited evidence that the solution is aligned to user needs or business drivers. Understanding exists largely through assumptions or informal discussion. Verbal stakeholder feedback.
High-level aspirations.
Informal notes or assumptions. 		High-risk gaps in validation and traceability.
User and business expectations may not be aligned.
2 Some user needs and business objectives have been identified and reflected within parts of the solution design. Significant gaps remain. User stories.
Requirements documents.
Business case objectives.
Partial mapping between needs and solution components. 		Significant number of notable gaps.
Some design areas cannot be linked to validated needs.
Success measures may be unclear.
3 Much of the solution design can be traced back to documented user needs and business objectives. The overall alignment is reasonable but notable risks or gaps remain. Defined user needs.
Architecture vision or design documentation.
Evidence of stakeholder engagement.
Requirements linked to major architecture decisions.
Identified trade-offs and assumptions. 		Some needs are not fully addressed.
Validation may be incomplete.
Certain architectural decisions may lack clear outcome-based justification.
4 Most design decisions can be clearly linked to validated user needs and business drivers. The relationship between architecture, product outcomes and organisational objectives is well understood. Maintained user research outputs.
Agreed business objectives.
Traceability between needs, requirements and architecture artefacts.
Stakeholder review records.
Evidence of architecture decisions being assessed against objectives. 		Minor gaps only.
Risks are largely understood and managed.
Remaining needs have agreed mitigations or roadmap actions.
5 Comprehensive evidence shows the solution is strongly aligned to user needs and business outcomes. User-centred and outcome-driven decision making is embedded throughout the lifecycle and represents exemplar practice. Traceability from user needs through to architecture, delivery and outcomes.
Regular user and stakeholder feedback loops.
Clear measures of success and outcome tracking.
Evidence that roadmap and architecture decisions evolve based on learning.
Governance review demonstrating ongoing alignment. 		Minimal gaps.
Risks are monitored continuously.
Strong evidence that the solution remains aligned as needs evolve.

What assessors should look for

  1. User needs are understood – Evidence that intended users, their needs and pain points have been identified.
  2. Business objectives are defined – Clear understanding of the outcomes, drivers and goals the solution is expected to support.
  3. Traceability exists – Architectural decisions can be linked to user needs, requirements and business objectives.
  4. Stakeholder involvement – Relevant users, product owners and business stakeholders have contributed to shaping the solution.
  5. Trade-offs are understood – Design compromises are documented and justified against objectives and needs.
  6. Ongoing validation – The team can demonstrate that the solution continues to meet evolving needs and priorities.

What separates a 3 from a 4 or 5

A score of 3 generally means there is reasonable evidence that user needs and business objectives have influenced the solution design, but the links are not always complete, maintained or consistently evidenced.

A score of 4 typically requires clear traceability between user needs, requirements, architecture decisions and business outcomes, supported by ongoing review and stakeholder engagement.

A score of 5 requires strong evidence that user needs and business objectives actively drive architecture decisions throughout the lifecycle, with continuous validation, outcome measurement and adaptation. The approach should be considered an exemplar for other teams.

Suggested evidence examples (not SAF-mandated artefacts)

  • User research reports
  • Service assessments
  • Personas
  • User journeys
  • Business cases
  • Objectives and key results (OKRs)
  • Architecture vision documents
  • Requirements catalogues
  • Architecture decision records
  • Benefits realisation plans
  • Roadmap reviews

Updated: 04 September 2026 (SAF Version 1.1)