Contents
A good requirements document is not 80 pages long. It is as long as it needs to be for a developer to understand what the app must make possible, for whom, and why. It is what makes quotes comparable across providers and what avoids the “that’s not what I had in mind” moment at the end of the project.
Here is the outline I recommend, in eight sections. You do not need to know everything: an incomplete section is better than an invented one. Filling the gaps is exactly what the scoping phase is for.
1. Context and objective
In a few lines: who are you, what problem do you want to solve, and how will you know the project has succeeded?
- What current situation is causing problems (spreadsheet, unsuitable tool, manual tasks)?
- What result do you expect: saving time, avoiding errors, selling more, keeping better track of your clients?
- One or two success indicators, even rough ones (“no more re-entering orders”, “quotes sent the same day”).
2. Users
List each type of user and what they need to be able to do. This is often the most useful section of the document.
| User | What they need to do | On which device |
|---|---|---|
| Sales rep | Create a quote, follow up on prospects | Computer and phone |
| Manager | Approve quotes, see the figures | Computer |
| Client | View and accept a quote | Phone |
3. Features
Describe the features from the user’s point of view, not the technical one. A simple formula works well: “As a [user], I want to [action] so that [benefit]”.
Then rank them on three levels:
- Essential: without it, the app is useless.
- Important: useful soon, but can wait for a second version.
- Later: good ideas to keep for the future.
This ranking is your best lever on the budget: the first version contains only the essentials.
4. Data
What information does the app need to manage (clients, products, quotes, jobs…)? Where does it come from today? Do you need to import historical data?
Attach a sample of your current files: an extract from your spreadsheet often says more than a long description.
5. Connections with your other tools
Accounting software, online payment, calendar, email, website, existing CRM: list the tools the app needs to exchange data with, and in which direction (send, receive, or both).
6. Constraints
- Deadline: a fixed date (trade show, season, end of a software contract)?
- Budget: a range, even a wide one, makes it possible to propose the right solution rather than the most complete one.
- Security and personal data: sensitive data, hosting in France or in Europe?
- Field use: does it need to work without a network connection?
7. Look and feel
No need for a mock-up: your logo, your colors and two or three examples of apps you find pleasant to use are enough. Mock-ups will be produced during the project and approved before development.
8. After launch
Who will administer the app? Is training needed? What level of maintenance do you want? These questions determine the choice of hosting and the annual budget.
Mistakes to avoid
- Describing the solution instead of the need: “a green button in the top right corner” rather than “approve a quote in one click”.
- Making everything priority 1: if everything is essential, nothing is.
- Copying existing software: you would pay a lot for a clone of something you could rent.
- Forgetting secondary users: the accountant, the client, the person covering during vacations.
My advice: write a first version in an hour, even an imperfect one, in your own words. We complete it together during scoping, and that finalized document becomes the basis for the firm quote.