An app requirements document: a filled-in template that shows what to define

The three terms get mixed up in vendor conversations, so it helps to separate them by the question each deliverable answers and by who is supposed to read it.

A (fictional) service company wants to move ticket intake, technician scheduling, status updates and visit summaries into one system. Today these happen over phone calls, messages and separate files. The goal of version one: every ticket has an owner and a clear status, with nobody chasing anyone.

Measures go into the document so you can later tell whether the product did its job — not to promise an outcome. In the example: share of tickets that get scheduled, time to first update, share of visits with a complete summary, and the number of updates still happening outside the system. There is no baseline and no improvement claim here — those are measured only after launch.

This table is usually the section with the biggest effect on the quote: every additional role brings screens, permissions, tests and sometimes a separate app.

new → scheduled → accepted → in_progress → pending_review → closed. Exceptional states: canceled, and waiting_parts when a part is missing. Transitions depend on role: a technician does not close a ticket, a coordinator does not approve a summary. Canceling never deletes history. This state list is what the developer turns into a data model, notifications and reports — which is why it's worth more than ten lines of "the system shall allow".

Billing and payments, a full inventory system, automatic routing, a call center, an end-customer app, full offline operation, AI-based diagnosis, automatic integration with every ERP. Each needs its own decision and pricing. The exclusions section is often the most useful one in the document: it prevents three quotes from pricing three different products.

A screen described only in its "everything works" state is half a screen. In practice most development and testing time goes to empty states, errors and missing permissions — so they appear here from the start.

This is what one requirement looks like when it is written all the way through. Notice that most lines deal with what happens when things don't go to plan — that is exactly what separates a realistic quote from one that grows mid-project.

Preconditions: the user is signed in, the ticket is assigned to them, and the state allows reporting. The summary includes an outcome and work notes; a photo is a field conditional on the spec decision, not automatically required.

A service manager can replace the technician before closure. The change is recorded with user and time. The previous technician loses active access and the new one receives the job according to the defined policy. A screen left open by the previous user does not grant them permission on the next request.

This version requires a network connection for server actions. A local draft can be kept, but full offline operation must not be promised without designing sync, conflicts, expiry and protection on shared devices. Every file has allowed types and sizes, access permissions and a retention policy. Personal data is not written to general logs and not sent to analytics tools.

Before pricing, find out: is there a CRM or ERP, do interfaces and documentation exist, is there a test environment, who holds the credentials, what is the quality of customer data, and who approves changes. In version one you can choose manual entry or a defined import, and leave continuous integration for a later phase. Third-party services and connection details are not considered available until verified.

Code and credentials per the agreement, setup instructions, role documentation, dependency list, test scenarios, release process, backup and restore, and a list of items left for later. Define who pays for infrastructure and accounts, who operates them, and what maintenance covers after launch.

A good requirements document doesn't pretend everything is known. It marks what still needs deciding — which is exactly what lets a vendor price with visible assumptions instead of guessing.

When the quotes arrive, don't compare the final number. For each proposal, mark item by item what's included, what isn't and what's unknown — we have a blank sheet for exactly this, in the guide to choosing a software development company.

What this document does not do: it does not replace a full specification with a designer and developer, it does not decide architecture, and it does not price itself. Once the quotes are in, the next step is usually UX specification and interface design with the chosen vendor — where requirements become screens, flows and a spec you can build from.

And if your next question is what this should cost — our estimate guide breaks the cost drivers down along exactly these sections: number of roles, backend, integrations, testing and uncertainty.