The short answer
A web app requirements document is a short, plain-language description of who uses the application, what each of them needs to do, what the app must not do, and how you will know it works. It does not need to be long. It needs to be specific enough that two developers reading it would build roughly the same thing and quote roughly the same price.
Write it before you ask anyone for a number. Without it, every quote you receive is priced against a different imagined project, and the cheapest one is usually the one that understood the least.
What goes in it
Eight sections cover almost every project. Keep each one short.
| Section | What it answers | Example |
|---|---|---|
| Problem and outcome | Why this is being built and what changes if it works | Clients email for status updates. We want those requests to drop and the answers to be self-serve |
| Users and roles | Who logs in and what each can see or do | Client, account manager, administrator |
| Core workflows | The handful of jobs the app must support end to end | Client signs in, sees current jobs, downloads a document, asks a question |
| Data | What records exist, their fields, where they come from | Client, project, document, message, with an existing spreadsheet as the source |
| Integrations | Which outside systems, in which direction, and who owns access | Accounting system, one way, nightly, our finance team holds the credentials |
| Non-functional needs | Performance, devices, availability, retention, accessibility | Usable on a phone, records retained seven years, screen reader accessible |
| Out of scope | What this version deliberately does not include | No payments, no mobile app, no client self-registration |
| Success measures | How you will judge it in three months | Status emails cut by half, all active clients signed in at least once |
Write workflows as user stories
Describe each thing a user needs to do in one sentence, then list what must be true for it to count as finished. That second part, the acceptance criteria, is what turns an opinion into a test.
A worked example:
- Story. As a client, I can download the latest version of a document so that I do not have to email my account manager for it.
- Acceptance criteria. Only documents belonging to my own account are listed. The newest version is shown first with its date. Older versions are available but marked as superseded. Downloads are recorded with a timestamp. If a document is removed, the link no longer works and the page explains why.
Notice how much of that is permission and edge-case detail. Those lines are exactly where budgets are won or lost, and writing them down before quoting prevents the argument that starts with "we assumed you meant".
Write the stories in the order someone would do them in real life, and include the unhappy paths: what the user sees when a file is too large, when a payment fails, when they have no records yet, and when someone else edited the same record first. Empty states and error states are real screens that have to be designed and built, and leaving them out of the document is the most common reason a finished app feels unfinished.
The requirements people forget
Functional lists are usually fine. What gets missed is everything around them, and each of these changes the price:
- Roles and permissions in detail. Not just who logs in, but what each role cannot see.
- Devices and browsers. If field staff use phones in poor signal, say so now.
- Volume. Records today, expected growth, largest file, busiest hour.
- Availability expectations. What happens if it is down for an hour on a weekday, and who is called.
- Data retention and deletion. How long records are kept and how someone's data is removed on request.
- Audit trail. Which actions must be traceable to a person and a time.
- Accessibility. State the standard you expect, because retrofitting is expensive. Our web accessibility guide covers the basics.
- Notifications. Who gets told what, through which channel, and how often.
Data and integrations
List every system the app touches and answer four questions for each: what data moves, in which direction, how often, and what happens when the other side is unavailable. That last one is the question nobody asks and everyone pays for later.
Also say who owns access. Many schedules slip because the vendor's API credentials took three weeks to approve and nobody started the request. If existing data has to move in, attach a real export sample, not a description of one. Messy data is normal, and seeing it early is the difference between an accurate estimate and a surprise. Our explainer on what an API is is useful background if the integration conversation is new to you.
Say what is out of scope
An out-of-scope list is the most valuable paragraph in the document. It protects the budget and it forces the conversation about phases while it is still cheap to have.
Write it as a plain list: no payments in version one, no public sign-up, no mobile app, no reporting beyond a simple export, no migration of records older than a set date. Add a short line saying these may come later, so nobody reads it as never. If you are unsure what belongs in the first version, our guide on scoping a web app MVP covers how to choose, and custom software versus off the shelf is worth reading before you commit to building anything at all.
A skeleton you can copy
Open a document and fill in these headings. Two to five pages is plenty for most first versions.
- Problem, outcome and success measures
- Users and roles, with a line on what each cannot do
- Core workflows, as stories with acceptance criteria
- Data model: records, key fields, sources, volumes
- Integrations: system, direction, frequency, owner, failure behavior
- Non-functional requirements: devices, performance, availability, retention, audit, accessibility
- Out of scope for this version
- Constraints: deadline and why, budget range, existing systems that must stay
- Open questions, with a name against each one
How to use it when you ask for quotes
Send the same document to everyone and ask each of them to quote against it, flag anything they would do differently and list what they assumed. The responses tell you as much as the prices: a developer who comes back with sharp questions about permissions and failure cases has read it, and one who returns a number the same afternoon has not.
Then compare like for like using our guide on comparing web development quotes. Keep the document alive after the project starts, because it becomes the reference you point at when someone asks whether a change is in scope.
Next step
If you would rather talk it through than write it alone, send us what you have, even if it is a few paragraphs and a spreadsheet. We will turn it into a requirements outline you can send to anyone, and tell you what a sensible first version contains. Use the contact page, or see the web application development page for how we scope a build. For a budget range while you write, try the web app cost calculator.