Document outcome-focused requirements
Structure outcome focused requirements that involve uncertainty.

Buying projects that are truly open to innovation aim to attract innovative solutions by asking the market to help achieve an outcome. This is done by taking a challenge statement to market and inviting shortlisted respondents to meet more specific and technical requirements at later stages. At each stage, buying teams refine their requirements based on insights from the previous stage.
Why this is challenging
Innovation buying teams using an outcomes-focused approach don’t know the end solution and don't use specifications. They often face the challenge of structuring and documenting a Statement of Requirements (SoR) that involves uncertainty. Existing SoR templates tend to focus on certain information and need to be tailored for challenge-based and multi-stage market approaches.
This page supports buying teams to prepare a challenge-based Statement of Requirements as part of either:
- a market approach to gather market intelligence such as for an Expression of Interest (EoI) or Request for Information (RfI)
- the first stage of a single buying strategy that covers a multi-stage approach.
It helps buying teams document an SoR for outcome-focused market approaches to help achieve great innovation outcomes, while giving suppliers the clarity they need, about:
- project background and business objectives
- scope of both the immediate, and any longer-term opportunity
- deliverables for each stage of multi-stage procurements
- timelines and milestones
- detailed challenge statement including functional requirements
- non-functional requirements
- mandatory requirements
- what is out of scope
- assumptions and constraints
- pricing.
When to document requirements
A Statement of Requirements should be documented after the Discovery phase of procurement. This means a business case or equivalent (such as project mandate) should be in place, confirming the problem is worth solving and that funding is available for at least some early testing of solutions. Buying teams should also ensure that decision-makers have appetite to pursue funding for full implementation if testing is successful, and that they understand the Iteration Plan that will drive testing and short-listing. Through market research, the buying team should also have confirmed that asking the market for proposals is an appropriate way to solve the problem.
An SoR should build on a well-defined challenge, which is part of the Scope step. By defining a challenge, a buying team goes into this first step of the Plan phase with a strong, shared understanding of the problem and desired outcomes, and good engagement with the relevant expertise.
Expand the boxes below to learn more about when to document the requirements.
A Statement of Requirements should be completed:
- after checking on alignment with ICT strategies
- after an initial discovery, innovation scoping and challenge statement definition
- after subject-matter experts and other key contributors have been identified
- after a business case confirms the problem is worth solving, and funding is available
- after establishing an iteration plan to drive testing and short-listing, if multi-stage
- before setting evaluation criteria
- before documenting a procurement strategy
- before suppliers have been engaged, other than for market research purposes, to ensure probity provisions and risks have been considered.
The Statement of Requirements document will be used to create:
- evaluation criteria
- evaluation plan
- Tender documents (RfX)
- supplier briefings and interactive engagements.
Who to involve and their responsibilities
The buyer is the primary driver of documenting the business requirements for innovation. This is because of the focus on the problem or desired outcomes for a business area or service. However, the buyer can rarely complete this step alone. Involvement of users and other subject-matter experts is essential for understanding a problem space, mandatory NSW Government policy requirements and technical requirements such as AI assurance and cyber security.
The buyer or their agent, such as a product or project manager, should identify the key people needed to write, review or approve the Statement of Requirements.
For the smoothest evaluation process later on, the people involved in evaluation should contribute to, or at least review, the Statement of Requirements. This helps avoid consensus challenges by creating an early, shared understanding of the business need.
Expand the headings below to read about the responsibilities of different roles.
The buyer is responsible for assembling the team of experts to collaborate on the Statement of Requirements.
They, or their agent, should identify the key people needed to write, review or approve the document.
As a minimum, they should involve the following key people or roles and ensure they are aware of how challenge-based requirements differ from technical requirements.
- The procurement advisor and/or probity representative, who should review and help shape the scope of deliverables in a way that suppliers will understand
- SME roles such as service designer, ICT partner, enterprise architect, digital, cybersecurity, privacy, accessibility, risk, AI assurance, and innovation specialists, who may contribute to scope writing and review activities
- Approvers.
The procurement officer should review and help shape the Statement of Requirements in a way that suppliers can understand. They will need to be aware of how an outcome-focused innovation scope might differ from technical requirements.
They should help identify the key people needed to review or approve the Statement of Requirements document.
Responsibilities vary for different types of subject-matter experts:
- service designers may be engaged to write the challenge statement and to incorporate it into a Statement of Requirements
- technical roles such as ICT partner, enterprise architect, digital strategy, cybersecurity, privacy, accessibility, risk, AI assurance, and innovation specialists may provide information about the current state, non-functional requirements or constraints and may contribute to scope-writing and review activities
- legal advisors, who may be engaged to review market-facing documents at a later stage, will need to be made aware of how innovation requirements might differ from technical requirements.
Buying teams should engage approvers as early as possible with a focus on helping them understand how innovation scope might differ from technical requirements. This builds confidence in how the Statement of Requirements is being completed and can speed up approvals later.
Next steps
What a Statement of Requirement should look like to attract innovation
Document a Statement of Requirements resources
What a Statement of Requirements should look like to attract innovation.