How to use it
- 01
Start from a bad day
Describe what goes wrong now, in concrete terms. A problem stated as an event, such as a job that sat unnoticed, gives a developer far more to work with than a list of wished-for features.
- 02
Follow one real case
For the main workflow, pick an actual recent case and write down each step in order, including who did it. Software is built around these steps, so accuracy here matters more than polish.
- 03
Write down the exceptions
List the cases that break the usual pattern and who deals with them today. Teams often leave these out because they are awkward, and they are exactly what a system has to handle well.
- 04
Check it with a colleague
Before sharing the outline, ask someone who does the work to read it. They will spot the missing step in a minute, and their agreement will matter when the software arrives.
What a requirements outline contains
A first requirements document does not specify screens. It describes the work clearly enough that a development team can ask good questions and propose a sensible first release.
| Part | What it settles | Why it matters |
|---|---|---|
| The problem | What is wrong today and what it costs | Gives the project a purpose to test every feature against |
| People and roles | Who uses the software and where | Determines permissions, devices and the number of interfaces |
| Workflows | The steps of the work, and its exceptions | Forms the core of what gets built |
| Information | Records, existing data and reports | Defines the data model and the migration effort |
| Connections and rules | Other systems and the constraints that apply | Exposes integration and compliance work early |
| Qualities | How the software must behave | Affects architecture decisions that are expensive to change |
| Limits | Deadlines, budget range and who leads | Lets a team propose a first release you can approve |
A worked example
A calibration laboratory replacing its whiteboard
The example is an invented laboratory that tracks customers' instruments on a whiteboard. Load it into the builder to read the whole outline. Three parts of it are worth a closer look.
- The problemCustomers ask where their equipment is and nobody can say without walking to the lab. One sentence, and the purpose of the system is clear to anyone.
- The exceptionsFailed instruments awaiting a customer decision, jobs waiting for a reference standard, urgent jobs. These three lines describe most of the status logic the software needs.
- The measure of successAny member of staff can answer a status question in under a minute. A developer can design towards that, and the laboratory can check it after launch.
Nothing in the outline mentions a screen or a database. It is still enough for a team to sketch the stages of a job, the roles and a customer view, and to return with informed questions.
What this tool does not do
An outline written in an hour is a beginning. It is honest to be clear about where it stops.
- It is not a full specification. Detailed requirements are worked out with the team that will build.
- It cannot tell you whether custom software is the right answer. Sometimes a packaged product fits.
- It gives no estimate of cost or time, since both depend on decisions still to be made.
- Your answers are held in this browser only, and you can clear them whenever you wish.
What to do with the finished document
Give the outline to the teams you are considering and ask what they would build first, and why. If you would like our view, we reply to outlines with questions and a suggested first release. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
Do I need to know anything technical to fill this in?
No. The builder asks about work, people and information, which you know better than any developer. Avoid prescribing technology unless you have a real constraint, such as a system that must stay. Describing what the software has to achieve leaves a team free to propose the simplest way of achieving it.
How detailed should the workflow be?
Detailed enough that someone outside your team could follow a case from start to finish. Name who does each step and what they need to know to do it. Ten to fifteen steps is typical for a main workflow. If you find yourself writing far more, you are probably describing two workflows, and the second field is there for that.
Should I list features as well?
You can add them in the workflow or the success field, but treat them as suggestions. Features chosen before the workflow is understood are often the wrong ones. A team that reads a clear description of the work will usually propose features you had not thought of, and question some that you had.
What comes after this outline?
A conversation, then a fuller document. Our software requirements document template shows what the next level of detail looks like, and the guide on replacing spreadsheets with software may help if that is your starting point.