A mobile app requirements document for a first version is two to four pages. It covers the user, the one job they want done, the walk-through in numbered steps, the screens, roles, integrations, platforms, what is left out, and what "done" means. You need no technical language and no paid template. A filled-in example for a made-up plant shop is below.
One user, one job
Pick one type of person and one job, from arrival to done: a salon client who wants to book a haircut, pay a deposit and get a confirmation. Not "customers" in general. If you cannot say it in one sentence, the first version is trying to do too much.
Write a walk-through, not a feature list
"Booking, payments, reminders, admin dashboard" tells a builder almost nothing. Write numbered steps instead: the client opens the link, picks "Haircut", sees free times, taps Thursday 3:30, enters a phone number, pays the deposit, sees a confirmation. Now you can count screens and spot gaps. What if 3:30 is taken a second later? What if the payment fails? Write one for the main user and a short one for whoever runs the business.
In and out
Write what is out of version one: "No customer accounts, guests book with a phone number." "No discount codes." "Web only, no iPhone app." Mark each as out for now or out for good. Ask of every item: could the first user finish the job without it? If yes, it is a nice-to-have. Be strict.
What silently eats time
- Logins and account recovery. Can version one avoid accounts?
- Payments and refunds. Part refunds, failed payments and receipts are the work.
- Admin screens. With no admin, every edit needs a developer.
- Notifications. Each needs wording, triggers and an off switch.
- Empty and error states. What shows before there is data, or when the internet drops?
- App store review. Apple's App Review page says a submission that fails review comes back with the guidelines it did not follow.
- Data import. Moving in an old spreadsheet is messier than it looks.
- Roles and permissions. Two kinds of user means rules on who can see and change what.
Do some things by hand first, such as approving sign-ups or sending invoices. If only ten people use it this month, is doing it by hand annoying or impossible? If annoying, do it by hand.
Fixed scope or fixed time
Fix the scope and let the date follow, or fix the date and let the scope shrink. You cannot fix both and add features. Changes will come once you see the real thing. Write each one down, say what it touches, then swap it for something similar in size, add it with an agreed change to the quote, or move it to version two.
Example: reorder app for a plant shop
A made-up business. Copy the headings and replace the contents. For cost and time, see app development cost in India and how long an app takes to build.
1. Summary. A reorder app for a plant shop's regular business customers, such as cafes and small offices. One job: a customer reorders last month's plants in under two minutes. Why: reorders now come by phone and chat, and get lost. Success: most regular customers reorder through the app within the first month.
2. Users and roles.
- Customer: a cafe or office manager. Sees past orders, reorders, changes quantities, picks a delivery day, pays, sees order status.
- Owner: sees new orders, marks them packed and delivered, edits products and prices, opens or closes delivery days. The only admin.
3. Main walk-through.
- The customer opens the app and signs in with a phone number and a code sent by text.
- Home shows "Last order" with items and quantities.
- She taps "Reorder" and the cart fills with the same items.
- She changes quantities or removes items. Out-of-stock items are greyed with a note.
- She picks a delivery day from the open days.
- She pays by UPI or card, or chooses pay on delivery if the owner has enabled it for her.
- She sees a confirmation and gets a text.
Owner: gets a notification, opens the order list, marks an order packed, then delivered. If payment fails, the cart is kept and she can retry. If an item sells out before payment, she is told before paying.
4. Screens. Sign in, home with last order, cart, delivery day, payment, confirmation, order history. Owner (web, not in the app): order list, order detail, product and price editor, delivery days.
5. Integrations. A payment gateway for UPI and cards. A text message provider. No accounting link: the owner exports the day's orders as a sheet.
6. Platforms. iPhone and Android phones, portrait only. Name the oldest phone and OS version that must work. Owner admin in a laptop browser. No tablet layout.
7. Out of scope. For now: staff logins per customer, discount codes, subscriptions, invoices (made by hand), delivery tracking, multiple languages. For good, unless asked: reviews.
8. Done means.
- A customer can sign in, reorder, pick a day, pay and get a confirmation on a listed phone.
- A failed payment keeps the cart.
- The owner sees a new order and can mark it packed and delivered.
- A price change shows on the next order.
- Three real customers have used it for a week.
9. After launch. Hosting and all accounts in the owner's name. The builder fixes bugs for an agreed period.
10. Open questions. Do customers pay at order, on delivery, or both? Is there a minimum order? How are damaged plants and refunds handled? Does the owner already have product photos and a price list?
Before you ask for quotes
With a document like this, two studios give quotes you can compare. Ask each who owns the code and accounts at the end: see questions to ask a web developer before hiring.
A project with us starts with an intro call, then a written scope and a quote. Tell us about your project.
Frequently asked questions
How do I write a software requirements document?
Start with the user and the one job. Write the walk-through in numbered steps, list the screens, roles and integrations, then write what is out of scope and what "done" means in checkable terms. List open questions instead of guessing.
What is an SRS document, with an example?
An SRS (software requirements specification) is a detailed document listing every function, rule and constraint. A first version rarely needs the formal one. The example above is a lighter version, and also works as a product requirements document (PRD).
What is an MVP?
The smallest first version that lets a real user finish the one job you chose. Everything else goes on the out list, or is done by hand while you learn whether people want it.
How long should a requirements document be?
Two to four pages for a first version. If it runs far past that, move the extra ideas to a version two list.