Guidance

How to write your requirements for Digital Outcomes and Specialists services

How to write requirements for agile projects.

What you can buy

You can find specialist services for digital projects through the Digital Outcomes and Specialists framework on the Digital Marketplace.

Digital Outcomes and Specialists services include:

  • digital outcomes, for example a booking system or an accessibility audit
  • digital specialists, for example a product manager or developer
  • user research labs
  • user research participants

Read about team capabilities for digital outcomes and digital specialist roles.

See the G-Cloud buyers’ guide if you need to buy cloud services, for example web hosting or accounting software.

Telling suppliers about your requirements

All requirements are published on the Digital Marketplace where anyone can see them.

When you buy Digital Outcomes and Specialists services, the information you provide in your requirements will help suppliers:

  • decide if they’ll apply
  • provide evidence to show how well they can meet your needs
  • suggest solutions that best solve your problem

You need to say:

  • what you’re trying to achieve and why
  • who your users are and what they need to do

Getting other people to help you

Lots of people can help you write requirements. Before you start, consider talking to:

  • users
  • suppliers
  • your colleagues
  • the Crown Commercial Service (CCS)

Users

You should do user research to help you learn what users need and why.

Suppliers

Talking to potential suppliers can help you write clearer requirements. This is sometimes called early market engagement or pre-tender market engagement (PTME). You can see a list of suppliers on the Digital Marketplace.

Read more about talking to suppliers before you buy.

Your colleagues

People who can help you write your requirements include:

  • your procurement team, who can help decide on timescales
  • your technical team, who can help if things such as security levels or existing technical platforms are important
  • your service or product manager, who can help identify user needs

CCS

CCS can also advise on the best way to buy services. They can show you relevant examples of requirements you can use to help write yours. CCS can also review your draft requirements. You can phone 0345 410 2222 (Monday to Friday, 9am to 5pm) or email cloud_digital@crowncommercial.gov.uk for help.

Essential elements of your requirements

When you write your requirements on the Digital Marketplace, you need to answer different questions for different types of services.

Digital outcomes

If you need a digital outcome, you’ll be asked to tell suppliers about the situation or problem. They’ll then propose a solution that meets your needs.

Digital specialists

If you need a digital specialist, you’ll have to ask suppliers to provide a specialist for a specific piece of work. The specialist can’t work outside the scope of your written requirements.

You can only post requirements for 1 specialist role at a time. For example if you want to find 3 developers, you must post 3 separate requirements – 1 for each developer.

User research participants

If you need to find user research participants, you’ll have to tell suppliers about the types of participants you want to test your service with. They’ll then tell you if they can meet your needs and how much it will cost.

User research labs

If you need a user research lab, you’ll be asked to tell suppliers what facilities you need and when. They’ll then tell you what they can do and how much it will cost.

The details you provide will help you shortlist suppliers that best meet your needs.

If you want to share links in your requirements, always include the full URL. You shouldn’t shorten URLs. Only link to your organisation’s website.

Digital outcomes requirements

This outcomes requirements template shows the information you’ll be asked to provide when you buy a digital outcome.

Your requirements must include:

  • what you want to call your requirements
  • region where the supplier will work, for example Northern Ireland
  • address where the supplier will work, for example the town or city
  • organisation the supplier will work for, for example Department of Work and Pensions
  • why this work is being done, for example an organisation or policy goal
  • the problem you want to solve
  • the citizen or ‘end user’ that this work is being carried out for, and what they want to do
  • phase the work is currently in: discovery, alpha, beta, or live
  • existing team the supplier will be working with
  • working arrangements, for example the supplier should be onsite 3 days a week for face-to-face meetings
  • latest start date, for example when the supplier must start work
  • how you’ll pay the supplier
  • the essential skills or experience the supplier must have, for example have experience working with low digital literacy users
  • any skills or experience you would like the supplier to have, for example provide evidence of delivering at scale
  • how many suppliers you want to evaluate
  • the importance you place on each criteria, for example 50% on technical competence, 20% on cultural fit and 30% on price
  • methods you’ll use to assess shortlisted suppliers, for example written proposal and face-to-face presentation

You should also think about including:

  • details of work that’s already been done, for example a discovery phase or early market engagement
  • any security clearance the supplier must have when they start work
  • expected contract length
  • any terms or conditions you want to add to the standard contract
  • budget range, for example if it’s split between different stages of the work
  • how and when you’ll run an optional question and answer session (so you can talk to specialists and quickly answer any questions they have about the brief)

Digital specialists requirements

This specialists requirements template shows the information you’ll be asked to provide when you specify work for a specialist.

Your requirements must include:

  • what you want to call your requirements
  • type of specialist you need, for example agile coach
  • region where the specialist will work, for example Northern Ireland
  • address where the specialist will work, for example the town or city
  • organisation the specialist will work for, for example Lewisham Council
  • what the specialist will do (the specialist can only work on the responsibilities you define here), for example develop and maintain responsive websites
  • existing team the supplier will be working with
  • working arrangements, for example the specialist should be onsite 3 days a week for face-to-face meetings
  • latest expected start date, for example when the specialist must start work
  • the essential skills or experience the specialist must have, for example 2 years’ experience writing software in Python
  • any skills or experience you would like the specialist to have, for example have worked with the NHS
  • how many suppliers you want to evaluate
  • methods you’ll use to assess specialists, for example interview, references or presentation
  • the importance you place on each criteria, for example 50% on technical competence, 20% on cultural fit and 30% on price
  • how long your requirements will be open for: 1 or 2 weeks

You should also think about including:

  • any security clearance the specialist must have when they start work
  • expected contract length
  • any terms or conditions you want to add to the standard contract
  • budget range
  • how and when you’ll run an optional question and answer session (so you can talk to specialists and quickly answer any questions they have about the requirements)

Participant recruitment requirements

This participant recruitment template shows the information you’ll be asked to provide when you specify work for participant recruitment.

Your requirements must include:

  • what you want to call your requirements
  • region where the research will take place, for example Northern Ireland
  • address where the research will happen, for example the town or city
  • organisation the supplier will work for, for example Lewisham Council
  • number of research rounds
  • number of participants per round
  • research dates
  • how often you want to do research
  • any evening or weekend research you want to do
  • supplier responsibilities, for example provide a host during research sessions
  • description of participants, for example any skills, behaviour or attributes the participants should or shouldn’t have
  • the essential skills or experience the supplier must have, for example experience recruiting participants with low digital literacy
  • any skills or experience you would like the supplier to have, for example have experience recruiting users for government research
  • how many suppliers you want to evaluate
  • how you want suppliers to demonstrate their skills, for example proposal or case study
  • the importance you place on each criteria, for example 40% on technical competence, 40% on availability and 20% on price

You should also think about including:

  • access restrictions at location
  • budget range
  • how and when you will run an optional question and answer session (so you can talk to suppliers and quickly answer any questions they have about the requirements)

You won’t need to ask suppliers to pay incentives or travel and subsistence costs. They agreed to this when they applied to offer user research recruitment services. You shouldn’t handle any cash payments to participants or pay for participants who don’t attend on the day.

User research lab requirements

This research lab requirements template shows the information you’ll be asked to provide when you specify work for a user research lab.

Your requirements must include:

  • what you want to call your requirements
  • region where the research will take place, for example Northern Ireland
  • address where the research will happen, for example town or city
  • organisation the supplier will work for, for example Lewisham Council
  • facilities needed
  • expected start date
  • research dates
  • how often you want to do research
  • when the sessions should take place, for example weekdays or weekends
  • how long suppliers will have to respond
  • the importance you place on each criteria, for example 70% on technical competence and 30% on price

You should also think about including:

  • expected contract length
  • budget range
  • how and when you’ll run an optional question and answer session (so you can talk to suppliers and quickly answer any questions they have about the requirements)

Writing clear requirements

Carefully written requirements can help a supplier understand what you need and propose their best solution.

Be agile

Long detailed briefs take a long time to write. They can also be confusing because they often don’t help suppliers get a good understanding of your requirements.

A classic waterfall request for proposal (RFP) doesn’t fit with agile development processes because requirements, timescales and deliverables (the work that needs to be done) are too rigidly specified.

Agile moves away from a rigid brief that specifies everything upfront. There are no long invitations to tender and functional specifications.

Don’t include too much detail as the scope of an agile project is defined by your requirements. They should provide suppliers with enough information to propose the best solution for your needs, and nothing more.

Buy what you need, when you need it

You should break work into phases such as discovery, alpha, beta, and live to:

  • minimise risk
  • learn about what works and what doesn’t
  • iterate your requirements as you go
  • ensure you have the right skills and expertise for each stage
  • ensure that your service or project is digital by default

You should buy a discovery phase separately from later phases of work. You can’t evaluate supplier proposals for later phases until you’ve decided the approach you’re going to take.

You should decide whether to break up later phases of work based on the size and the complexity of what’s needed.

If you’re buying a small piece of work which is low risk and low value, you may decide to buy services that cover many phases of work.

Use plain English

Keep your language clear and concise. You should:

  • keep your average sentence length between 15 and 20 words
  • make sentences active, rather than passive
  • try to stick to a subject-verb-object sentence structure, for example:
    • use: Fred joined the company today
    • don’t use: The company was joined by Fred today
  • spell out acronyms the first time you use them
  • avoid jargon and terminology, if you have to use it, explain it
  • put any internal project codes you want to include at the end of your requirements title so suppliers can quickly see what you need

Questions from suppliers

After you’ve published your requirements, suppliers may want to ask questions about them.

You should make sure that:

  • you answer all questions from suppliers
  • all suppliers can see all the questions that have been asked, and the answers
  • you remove any supplier information from the questions and answers you publish
  • you reply within the time you specified when you wrote your requirements

Read more about how to answer supplier questions.

Using waterfall methods

Suppliers who have been accepted onto the Digital Outcomes and Specialists framework have declared they can work in an agile way. You need to say in your requirements if you’ll be using waterfall methods. Only use waterfall processes where you can show they better meet user needs.

If your requirements can’t be public

If there are parts of your requirements which contain confidential or sensitive information which can’t be shared publicly, then you should:

  • write a high level summary of your requirements which can be published
  • provide an email address in your requirements so suppliers can contact you for more information share the same information with all suppliers

Read more about

Published 18 April 2016
Last updated 10 August 2016 + show all updates
  1. Specialists' requirements can now be open for 1 or 2 weeks.
  2. You can only post requirements for 1 specialist role at a time, eg if you want to find 3 developers, you must post 3 separate requirements – 1 for each developer.
  3. First published.