By Quick answer: How do I write requirements for an app?
- Start with why — the problem, the goal and how you'll measure success.
- Name the users — two or three specific types, not 'everyone'.
- Write user stories — 'As a…, I want…, so that…' with acceptance criteria.
- Draw the scope line — what's in version one, and what explicitly isn't.
- Add the invisible needs — performance, security, privacy, accessibility, integrations.
Key takeaways
- Requirements describe what and why; leave the how to the people building it.
- Acceptance criteria turn vague wishes into things a tester can pass or fail.
- An explicit 'out of scope' list prevents more disputes than any contract clause.
- Wireframes beside the stories remove most ambiguity about screens.
- Treat the document as living: version it and record decisions as you go.
Most app projects that go over budget did not fail in code. They failed in a sentence — "users can manage their bookings" — that meant one thing to the founder and another to the developer. A requirements document is how you find those sentences before they cost money. It does not need to be long. It needs to be specific enough that two people reading it would build the same thing.
What goes in it
| Section | What to write | Why it matters |
|---|---|---|
| Problem and goal | The problem, who has it, and what success looks like | Every later decision is judged against this |
| Success metrics | Two or three numbers you will track | Turns "launch" into a measurable outcome |
| Users | Two or three specific user types | Features make sense only for someone |
| User stories | Needs from each user's point of view | The core of the document |
| Acceptance criteria | Testable conditions for each story | Defines "done" |
| Scope | In for version one; explicitly out | Prevents scope creep and disputes |
| Non-functional needs | Speed, security, privacy, accessibility, devices | The invisible requirements that break launches |
| Integrations | Payments, maps, login, CRM, analytics | Often the biggest hidden cost |
| Constraints | Budget, deadline, platforms, languages | Lets builders propose realistic trade-offs |
| Open questions | What you don't know yet | Honest gaps beat confident guesses |
Atlassian's guidance on product requirements makes the same point in a different way: focus on the user problem and the purpose, and keep the document collaborative rather than handed down1.
Writing user stories that work
The classic format is: As a type of user, I want an action, so that a benefit2.
Vague
"Users can manage bookings."
Useful
"As a clinic patient, I want to reschedule an appointment from my phone up to 4 hours before it, so that I don't have to call the clinic."
The useful version names the user, the action, a limit and the reason. A developer can build it; a tester can test it.
Acceptance criteria: define "done"
Write criteria as Given / When / Then — the Gherkin format many teams also use for automated tests3:
- Given a patient with an appointment more than 4 hours away, when they tap Reschedule, then they see available slots for the next 14 days.
- Given an appointment less than 4 hours away, when they open it, then Reschedule is disabled with a note to call the clinic.
- Given a successful reschedule, then the patient and clinic both receive a confirmation within one minute.
Draw the scope line
The most valuable page in many requirements documents is the out of scope list. Write it plainly: "Version one will not include payments, multiple clinics, or a doctor app." Everyone now knows what a fixed quote covers.
Don't forget the invisible requirements
- Performance — key screens load in under 2 seconds on a mid-range Android phone on 4G
- Devices — minimum Android and iOS versions; phone and tablet?
- Offline — what must work without a connection?
- Security — login method, roles, data encryption, admin access
- Privacy — what personal data you collect, why, consent, deletion; India's DPDP Rules apply
- Accessibility — target WCAG 2.2 level AA for text contrast, touch targets and screen readers4
- Languages — English only, or Hindi and regional languages too?
- Analytics — the events you need to measure success
The free template
Copy this into a document and fill it in:
1. Overview
Problem · Goal · Success metrics (2–3) · Target launch date · Budget range
2. Users
User type · What they need · Context (device, connectivity, language)
3. User stories
ID · As a / I want / so that · Priority (must, should, could) · Acceptance criteria
4. Scope
In for version one · Out of scope · Later ideas
5. Non-functional
Performance · Devices · Offline · Security · Privacy · Accessibility · Languages
6. Integrations and data
Payments · Login · Maps · Notifications · Analytics · Admin panel · Data to migrate
7. Constraints and risks
Deadline · Budget · Regulations · Dependencies
8. Open questions and decisions log
Question · Owner · Decision · Date
Common mistakes
Describing solutions
"Add a dropdown" constrains designers. "Choose one of 12 cities quickly" lets them find the best answer.
Everything is a must
If every feature is priority one, nothing is. Rank ruthlessly.
No wireframes
A rough sketch beside each story removes half the questions. See how to make a wireframe.
Writing it alone
Review it with a developer and a designer before you send it for quotes.
With a clear document in hand, you can compare agencies fairly — our list of questions to ask an app development company helps with the next step.
Key terms, defined
PRD — product requirements document, the what and why of a product. SRS — software requirements specification, a more formal technical document. User story — a need from the user's point of view. Acceptance criteria — testable conditions for a story to be done. Non-functional requirement — a quality such as speed, security or accessibility. Scope creep — uncontrolled growth in what a project includes.
Frequently asked questions
What should an app requirements document include?
The problem and goals, success metrics, target users, user stories with acceptance criteria, scope for version one and an out-of-scope list, non-functional requirements (performance, security, privacy, accessibility), integrations, platforms, constraints such as budget and deadline, open questions, and links to wireframes.
What is the difference between a PRD and an SRS?
A product requirements document (PRD) focuses on the user problem, goals and features from a product view. A software requirements specification (SRS) is more technical and formal, detailing system behaviour, interfaces and constraints. Small teams often combine both in one practical document.
How long should an app requirements document be?
As short as possible while still being testable — often 5 to 15 pages for a first version. Length is not quality; precise user stories, acceptance criteria and a clear scope line matter far more.
What is a user story?
A short description of a need from the user's point of view: 'As a [type of user], I want [action] so that [benefit].' Each story has acceptance criteria that define when it is done.
What are acceptance criteria?
The specific, testable conditions a feature must meet to be accepted. They are often written as 'Given [context], when [action], then [result]', which makes them easy to turn into test cases.
Do I need a requirements document to get an app quote?
You will get far more accurate and comparable quotes with one. Agencies quoting from a one-line idea must guess, and guesses become change requests and cost overruns later.
Sources
- Atlassian — Product requirements documents
- Mountain Goat Software — User stories
- Cucumber — Gherkin reference (Given/When/Then)
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2
- Checked October 23, 2026. Figures that change — fees, salaries, prices — are reviewed every six months; if something is out of date, tell us.
Where to go from here
- How to make a wireframe in 30 minutes — the picture that goes with the words
- Questions to ask an app development company — once your document is ready to share
- Career guidesHow to write product requirements and PRDs in 2027: problem and goals, scope and non-goals, requirements and acceptance criteria, success metrics and living documentsHow to write product requirements and PRDs in 2027: problem, goals, scope, non-goals, requirements, acceptance criteria, success metrics and keeping docs alive.
- Product managementPRD template: how to write a product requirements document your team will readA PRD template for product teams: problem, goals, users, solution, requirements, metrics, risks and decisions — plus a one-page version and writing tips.
- Career guidesHow to write user stories and acceptance criteria in 2027: As a / I want / So that, INVEST, splitting stories, given–when–then and Definition of DoneHow to write user stories in 2027: the As a / I want / So that format, INVEST, splitting stories, given–when–then acceptance criteria and Definition of Done.
- App developmentApp development agreement: 12 clauses that protect youThe 12 clauses every app development agreement in India needs — scope, IP assignment, payments, acceptance, warranty, handover and disputes.
- AI & vibe coding14 copy-paste AI skills for product managers, for ChatGPT, Claude and Gemini14 free copy-paste AI skills for product managers — one-page PRD and user story writer and more — each with an output preview and the exact text to paste.
- Product managementProduct manager resume: examples, bullet formulas and a template that gets interviewsWrite a product manager resume that gets interviews: an outcome-first bullet formula, before-and-after examples, a one-page template and tips.
Get the ideas, not the noise.
Sign up with Google and we’ll send you short UX psychology tips by email — why people tap, stall and leave, and what to do about it. Unsubscribe anytime. Prefer something to keep? Get the free Laws of UX guide as a PDF.
Make sure the first screen makes sense.
A behavioral UX audit of your app or SaaS product: why users hesitate, stall and leave, and a prioritized fix list. Fixed price, 2–4 weeks.