Mobile App Specification Template: Example, Checklist and Acceptance Criteria

Start with a decision the team can test

A mobile app specification is useful when two people can read it and agree on what the app should do. A catalogue of screens rarely gets you there. “Booking screen” might mean a request that somebody approves, a confirmed reservation, or a temporary hold while payment is processing. Those are different products, even if their mockups look almost identical.

The document should settle those differences before they become arguments about extra work. It does not need to predict every implementation detail. It needs a business goal, clear roles, a complete first journey, explicit exclusions and an observable definition of success. Unknowns belong in the document too, with somebody responsible for answering them.

Start with the editable specification worksheet. It is a plain-text Markdown file that opens in a text editor and can be imported into a document tool. No registration is required. The example below shows how to fill it in; it is a fictional booking product, not a claim about a client project.

A brief, a specification and an estimate do different jobs

A brief explains the idea well enough to start a conversation. A specification turns important decisions into requirements that design, development and testing can use. An estimate describes the work, assumptions and dependencies behind a delivery proposal. None of these documents can replace the other two.

When the idea is still unsettled, use our preparation guide first. It is reasonable to say that payments or the launch country have not been decided. What creates trouble is quietly treating an undecided feature as a finished requirement.

The first useful specification is a working agreement, not a ceremonial document signed and forgotten. Give it an owner and a version. Record decisions when they change, and make sure the estimate and acceptance tests refer to that same version.

The sections your document actually needs

Keep the structure short enough that a founder can review it with the delivery team. Put large supporting files behind links rather than burying the main decisions in attachments.

A requirement should describe behaviour, not simply name a technology. “Use a database” does not tell anyone how cancelled bookings behave. “Keep cancelled reservations visible to the administrator with their cancellation reason” does.

A filled example: booking a small-group class

Our fictional studio currently handles bookings through messages. Its first release serves existing customers in one location. Customers can see a schedule, reserve a place, pay and find the confirmation again. Instructors see the attendance list. An administrator manages classes and cancellations.

The first version excludes memberships, a waiting list, instructor payouts, social features and multiple locations. That does not mean these features are unimportant. The team can test whether the basic booking journey removes the current manual work before expanding it.

Here is the important rule: a reservation is confirmed only after the system receives a valid payment result. While payment is pending, the place is held for a defined period. If that period expires, the place becomes available again. The length of the hold is a business decision to record, not a number the developer should invent.

The specification also needs to explain a late payment result. If the place has already been released, the system must not quietly overbook the class. Record the chosen resolution, the customer message and the administrator action. This example exposes more real work than a dozen polished booking screens.

Turn one feature into acceptance criteria

Write acceptance criteria as conditions someone can observe. The GOV.UK guide to user stories introduces this way of thinking. Your document can use ordinary language; formal syntax is optional.

For our last remaining place, two customers open the class at the same time. The first obtains a valid hold. The second sees that the place is no longer available and is not sent into a payment flow that cannot succeed. When the first payment is confirmed, exactly one reservation appears in the attendance list.

Then test failure. The customer closes the app during payment and opens it again. The app retrieves the actual booking state instead of assuming failure from the missing screen transition. A repeated payment notification must not create another booking, and repeated taps must not start duplicate business operations.

Finally, define the evidence. The tester should be able to inspect the reservation, payment status and relevant application event. A screenshot of a success message alone does not prove that the administrator received a correct booking.

Describe the admin panel before approving the scope

Someone has to run the service after launch. Who cancels a class? Who resolves a disputed payment? Can an instructor change capacity, or only the administrator? If a booking was changed manually, can support see what happened?

These questions often look secondary in a design review because customers never see the screens. Operationally, they are central. A product that requires a developer to edit production data for every cancellation is not ready for ordinary business use.

Record permissions, confirmation for destructive actions and information support can inspect. Link detailed requirements to the admin-panel guide rather than inserting every possible management feature into the first release. Start with actions the team genuinely needs on its first working day.

Make integrations and data ownership explicit

“Connect the scheduling system” is not an integration requirement. Name the system, the responsible contact, the available documentation and whether test access exists. Specify which system is authoritative when the two disagree.

For the class example, decide how a cancelled session reaches the app and what happens when the scheduling service is unavailable. The answer might be a read-only cached schedule and a clear warning that booking is temporarily unavailable. It should not be an optimistic success screen.

Distinguish data the product needs from data it merely could collect. Set out who can access personal information, how account deletion affects operational records and which questions require legal review. Avoid copying a generic retention period into every project. OWASP MASVS is a reference for the technical security review, not a substitute for project-specific requirements.

Include the experience beyond the happy path

A usable specification describes empty schedules, declined payments, lost connectivity, denied permissions and a returning user whose session has expired. These states need understandable messages and a route forward. “Show an error” leaves too much of the product undecided.

Accessibility belongs here too. Can a customer distinguish the selected class without relying only on colour? Does larger text hide the confirmation button? Can a screen reader identify the current booking state? The W3C accessibility introduction is a useful starting reference.

Do not turn this into an endless list of hypothetical failures. Follow the main journey and ask where a person could lose money, access, progress or confidence. Those are the states worth settling early.

Decide what the first release must prove

For the booking example, success is not the number of installed copies. It is whether customers can complete a correct reservation and whether staff can manage it without rebuilding the process in chat.

Choose a small set of events and define their meaning. A booking-completed event should follow a confirmed booking, not the first tap on a button. Keep event names and parameters in the specification so Android, iOS and the backend do not record incompatible versions of the same action.

Before accepting delivery, review a complete journey in a release-like build: installation, sign-in, a successful booking, a failed payment, cancellation and an administrator action. Our testing checklist helps turn those requirements into a repeatable review.

Review changes without losing the original agreement

A specification will change as the team learns. The useful distinction is between clarification, a correction and new scope. Changing a confusing label is not the same as adding instructor payouts or a second country.

When a request appears, record the reason, affected journey, consequences and decision. Remove obsolete wording rather than leaving contradictory instructions in different sections. For larger changes, ask the team to revise its assumptions before development continues.

Appfyl can use this document as the basis for a scope discussion. Browse our published product examples, then bring the worksheet and open questions to the project brief. The useful output is an agreed first version, not a longer document.

Questions people ask