A requirements template for people who are not developers

Most requirements templates are written by engineers for engineers. This one is for the person with the idea. It covers what goes in each section, why a developer needs it, and what happens when it is missing.

Why the document matters more than the idea

A developer cannot build an idea. They can build a description of one. Everything that is not written down gets decided later — by whoever is holding the keyboard, at your expense, usually in the form of a change request.

A requirements document is how you decide those things before the quote rather than after it. It is also the single best way to make quotes comparable, because every supplier is finally pricing the same thing.

The sections, in plain English

1. The problem

Who has it, how they solve it today, and why that is not good enough. Two or three sentences. If you cannot write this, nothing else will be right.

2. The people

Every type of user — customers, staff, admins — and what each needs to do. Different people usually mean different screens and permissions, which is where cost hides.

3. What it must do

The functional requirements: numbered, one behaviour each. "A customer can book a slot and receive an email confirmation" — not "a great booking experience".

4. How well it must do it

Non-functional requirements: how many users, how fast, which devices, what uptime. These are invisible in a demo and expensive to add later.

5. What it connects to

Payments, accounting, calendars, email, your existing systems. Each connection is real work and must be priced.

6. Data and compliance

What personal data it holds, whose, and which rules apply. In the UK, GDPR applies to almost anything that stores names and emails.

7. What is out of scope

What this version will not do. The most underused section in any brief, and the one that stops a project growing without permission.

8. Budget and timing

A range you can live with and a date that matters. Suppliers scope differently when they know the constraint.

A worked example: one requirement, done badly and well

Too vague to price: "Users should be able to manage their bookings easily."

Priceable: "A logged-in customer can see their upcoming bookings, cancel one up to 24 hours before the slot, and receive an email confirming the cancellation. Cancellations inside 24 hours are refused with a message explaining why."

The second version tells a developer about accounts, a list view, a rule, an email and an error state. The first tells them nothing, so every supplier will imagine something different — and price it differently.

Questions people ask next

How long should a requirements document be?

As long as it takes to remove the guesswork, and no longer. For a small project that can be two or three pages. Length is not the goal; every requirement being testable is.

What is the difference between functional and non-functional requirements?

Functional requirements are what the software does ("sends a confirmation email"). Non-functional are how well it does it ("pages load in under two seconds on a phone"). Both affect cost.

Do I need a requirements document for a small project?

Especially for a small project. A small budget has the least room to absorb a misunderstanding, and a one-page brief is enough to prevent most of them.

Can someone write it for me?

Yes. A Moksy Blueprint is a requirements document generated from plain-English questions about your idea, covering scope, functional requirements, data model, security, budget and risks — and on paid plans it is checked by an accredited reviewer before you rely on it.

Have your requirements written for you

Answer plain questions about your idea — no jargon — and Moksy writes the requirements document for you: every section above, filled in for your project. Share it, get quotes from it, or build from it.