How to Write an App Requirements Document

What an app requirements document is for

A requirements document is the shared reference that lets a business, a designer and a development team agree on what an app must do before anyone draws a screen. It is not a contract stuffed with feature lists. The best ones read like a clear description of who uses the app, what they need to get done, and how you will know it works. Tepia uses a client’s document as the starting point for Discovery, not as a replacement for it.

It matters most when you are moving an existing process or a legacy system into an app. The old system quietly does dozens of things, from a nightly export to a warning that appears when a customer is on credit hold, and if the document does not list them, the new app will not do them. Writing them down now is the easiest moment you will ever have to catch them.

The sections every requirements document needs

Use this structure whether the app is a customer product, an internal tool or a mobile front end for an older system. Tepia’s Discovery deliverables follow the same order, so nothing you write is wasted.

How to write user stories and acceptance criteria

User stories keep a document focused on outcomes. Write each one from a real role’s point of view with a reason attached: as a dispatcher, I want to see which technicians hold a backflow certification, so that I only assign certified staff to those jobs. The reason is what lets designers and engineers find a better solution than the one you first imagined. Tepia writes dozens of these during Discovery and groups them by role.

Acceptance criteria turn a story into something testable. Use the given, when, then format and cover the unhappy paths: no signal, a duplicate entry, a user without permission, or a record changed by someone else at the same moment. A story without criteria is a wish; with them, a tester and a manager can agree it is finished.

• Avoid solution words like dropdown or popup, and describe the decision the user is making instead.
• Replace fast and easy with numbers, such as search results in under two seconds on a phone.
• Mark each story must have, should have, could have or not in this release.
• Number every story so design, testing and support can refer to it later.

Common mistakes, especially when replacing a legacy system

The most damaging mistake is describing the new app while forgetting the old one. Tepia asks clients to list every report, export, scheduled job and integration the current system runs, then marks which ones the app must keep. A forgotten nightly file to the accounting system stays invisible until month end.

• Writing the document alone. Requirements written only by management miss what front line users actually do, so interview at least two people in each role.
• Copying the old screens. Screens built a decade ago reflect old constraints. Describe the task, not the layout.
• Leaving out non functional needs. Offline use, device types, accessibility and data retention shape the architecture and are hard to add late.
• Skipping the out of scope list. Without it, every meeting adds a feature.
• Treating the document as final. Version it and update it as Discovery answers the open questions.

If you are planning a first release, our guide on planning an MVP shows how to cut a long story list down to what proves the idea, and a product design sprint can test the riskiest stories with users in days.

How Tepia approaches app requirements

Your requirements document feeds directly into each of Tepia’s six phases.

1. Discovery: system investigation of any tool being replaced, user interviews by role and a third party integration review, turning your document into an Investigation Summary, an Interview Summary and a numbered set of User Stories with acceptance criteria.
2. Design: a design questionnaire, moodboards, a style guide and detailed wireframes mapped to story numbers, so every screen traces back to a requirement.
3. Development and Testing: Alpha and Beta schedules organized by story, with test plans for functional, user acceptance and non functional requirements such as offline sync and accessibility.
4. Training: hands on sessions built from the same user stories, so staff practice the tasks the document described.
5. Launch: data migration and transition from the old system, checked against the data and integration sections of your document.
6. Support: new needs arrive as feature requests in the same story format, so the document stays current after launch.

A strong document often puts Discovery at the short end of its usual 1 to 3 months; development and QA then typically run 2 to 6 months, with about a month for launch. See Tepia’s app development process or send Tepia your draft for feedback.

Frequently asked questions