Mobile app specification: testable example
A mobile app requirements document describes the problem, users, scope, constraints and acceptance criteria for the delivery. Start with a short brief to make decisions, then specify the journeys that need a clear commitment.
A short requirements template for your first discussion
| Field | Your answer |
|---|---|
| User and problem | Who encounters which difficulty, and in what context? |
| Intended result | Which complete task should the person be able to finish? |
| Scope | What belongs in this version, and what does not? |
| Constraints | Which devices, access rules, data and connected systems matter? |
| Acceptance | Which scenario will verify the result? |
| Handover | Who receives the code, accounts and operating instructions? |
Use the mobile app requirements generator to organize your answers. A short brief helps while you are exploring options. A detailed specification becomes useful when you need agreement on journeys, integrations and acceptance conditions. A longer document does not replace a clear decision.
If you are taking over an existing product, begin with the mobile app audit. A reproducible finding helps you avoid turning an untested assumption into a redesign requirement.
How to use the worked example below
The fictional Climato example covers the business problem, selected scope, ten acceptance criteria, the distinction between compliance and product behavior, and a detailed reusable outline. Start with the criteria for your main journey. You do not need every feature in the example.
A specification document is not meant to guess all the answers before the first workshop. It is meant to ask the right questions, make decisions visible and turn "the app must work" into criteria you can test yourself.
I will show you a fictional example of scoping for a field service app, then the corresponding acceptance tests. The example is deliberately concrete: it illustrates how to link each product requirement to an observable check, without turning the document into a simple list of screens.
The problem before the solution
Imagine an industrial equipment maintenance company, let's call it "Climato". Today, a technician leaves with a paper form, takes photos, then re-enters everything at the office. Result: data entry errors, billing delays and no real-time visibility for the manager.
The specification starts with this problem, not with "an app with a photo button". You write:
Technicians must be able to create, modify and close an intervention report on site, even without network, then synchronise the data upon return without creating duplicates.
This observable result becomes the filter for all features. You don't tick boxes; you link each requirement to a business behaviour.
The scope chosen for this example
The technician views their interventions, writes a report and adds a photo if useful. The manager assigns interventions and reviews reports. The MVP does not include payment, internal messaging, or continuous geolocation. This exclusion counts as much as the list of retained features.
Before development, the team must choose which reports can remain on a device, for how long, and under what conditions it allows offline consultation. It must also decide who resolves a conflict and who can delete a report. The tests below assume these decisions are in the document.
If you are still hesitating between a technical demonstration and a first usable product, compare the prototype and the MVP. The MVP risk scanner can then help you make the unknowns visible.
The 10 acceptance criteria to test
Here is how to turn critical functions into acceptance tests. Each criterion is a sentence your team can tick during a validation session, with an associated test scenario.
1. Offline capture without loss
Criterion: If the technician has no network, they can create a report, attach photos and save everything. When connection returns, the report is synchronised automatically.
Test: Enable airplane mode. Create a report, add three photos. Check that the report remains editable and that no data is lost.
2. Resume without duplicate
Criterion: After a network interruption during synchronisation, the application resumes the transfer without duplicating the report, photos or signatures.
Test: Start synchronisation, cut the network halfway, restore it. Check that there is only one report and that all photos are correctly associated.
3. Handling conflicting modifications
Criterion: If two users modify the same report at the same time, the authorised user compares the versions and chooses the resolution; no change is silently overwritten.
Test: Open the same report on two devices in offline mode. Modify the "observation" field differently, synchronise both. Check that a resolution screen appears and that the user chooses the final version.
4. Photo permission denied
Criterion: If the user refuses access to the camera or gallery, the application explains why the permission is necessary, offers an alternative and continues to work for other functions.
Test: Refuse the permission. Check the explanatory message, test text entry without a photo. The permission must not be requested again on every action.
5. Principle of permission minimisation
Criterion: The application requests only the permissions strictly necessary, at the moment the function is used for the first time, rather than asking for access unrelated to the current journey.
Test: Install the application on a blank device. Check that no permission is requested before an action justifies it. Example: location is only requested for the route, not to open the report.
6. Deletion of local data
Criterion: When a technician deletes a report locally before synchronisation, no residual trace (photo, temporary file) is found in the application's storage.
Test: Create a report with photos, delete it in offline mode. Ask the technical team to check the test storage and associated files using the tools appropriate for the platform. A simple check of the visible list is not enough.
7. Deletion of server-side data
Criterion: When a manager deletes a report in the back office, the mobile application is informed and the report disappears from the local list after synchronisation.
Test: Delete a report in the admin interface. Synchronise the device. Check that the report no longer appears and that a retention rule is noted in the documentation.
8. Technician departure and access assignment
Criterion: When a technician leaves the company, their account can be deactivated without deleting the history of already synchronised reports. Create a separate named account for their replacement, with the necessary rights.
Test: Deactivate a user in the back office. Check that their reports remain accessible to the manager and that mobile login is refused. Create a new user with the same role and check they can access ongoing interventions.
9. Permission screen without confusion
Criterion: The application clearly distinguishes the technical permission request from the system and the collection of GDPR consent, where applicable. The journey explains their difference and collects separate consent when this legal basis is necessary.
Test: Launch an action that requires the camera and a processing consent. Check that the journey distinguishes the two decisions, respects refusal and does not present a system authorisation as consent to all processing.
10. Verifiable synchronisation log
Criterion: Each report displays the date and status of its last synchronisation. The technician can see if the report is up to date without reconnecting to the server.
Test: Create a report offline, then synchronise. Check that the status changes from "pending" to "synchronised" and that the timestamp is correct.
Compliance vs product: do not mix the two
Criteria 4, 5, 8 and 9 touch on data protection and permission management. These are not just technical choices. The French Data Protection Authority (CNIL) points out that system permissions do not collect GDPR consent: they only give technical access. Depending on the processing, you must determine the appropriate legal basis and, when consent is necessary, collect it correctly. The CNIL explains this difference between technical permission and consent.
In your specification, separate product requirements from compliance requirements. An acceptance test verifies behaviour; it does not validate legal compliance. For that, refer to the CNIL's recommendations and your data protection officer. The example above shows how rules such as permission minimisation translate into testable criteria, without claiming to cover all obligations.
The specification template to reuse
You can start from the following structure, which you will fill with your context:
- Context: activity, current problem, people involved and consequence.
- Expected result: what the user will be able to accomplish and how you will validate usefulness.
- Users: profiles, rights, devices, context and usage constraints.
- Priority journeys: three to five complete scenarios, from trigger to result.
- Scope: MVP functions, next phase and out-of-scope items.
- Platforms: iOS, Android, tablet, web, minimum versions and phone capabilities.
- Data: data collected, purpose, retention, deletion, permissions and actors who access it.
- Integrations: systems, APIs, owners, documentation and synchronisation direction.
- Quality: acceptance criteria, test devices, accessibility, languages and volumes.
- Delivery: code, accounts, mockups, documentation, deployment, warranty and maintenance.
- Organisation: decision-maker, contacts, availability to test and validation circuit.
- Constraints: deadline, dependencies, budget or scope scenarios.
For each acceptance criterion, write the observable behaviour and the test to execute, as in the Climato example. You will then have a precise basis to discuss the scope and prepare the acceptance.
What Doved Studio does with your specification
I do not turn your first list into an automatic quote. I check the main journey, note the decisions that change the architecture and distinguish the necessary from what can wait. Acceptance criteria become our common tool: you know exactly what to test, and I know what to deliver.
You can bring these decisions together in the specification generator. Then bring your main journey and one still ambiguous criterion to Doved Studio: we bring together product scoping, design and development to clarify what needs to be delivered. Also include code handover, account ownership and documentation in the expected deliverables.
Frequently asked questions
Do you have to write all acceptance tests before development?
No. You can start with the criteria that correspond to critical journeys. The studio will complete the edge cases during scoping. The important thing is to have a verifiable basis before acceptance.
What is the difference between an acceptance test and a compliance test?
An acceptance test verifies that the application behaves as expected (e.g. no duplicate after synchronisation). A compliance test verifies respect for a legal obligation (e.g. GDPR consent). The first relates to the product, the second to legal matters.
Does this example describe a real client?
No. Climato is a fictional example created to illustrate how to structure a specification. It does not describe a client engagement.
Can I use this template for other sectors?
Yes. The structure remains valid for a logistics, home healthcare or maintenance application. Adapt permissions and data to your sector-specific obligations.