Application requirements: a guide, example and free template

Describe your needs without technical vocabulary: users, journeys, rules, data and acceptance criteria. A booking example and a free text template to adapt to your project.

An application requirements document describes the problem to solve, the people involved and the expected outcomes. It helps you compare proposals and check what has been built. You can write it without knowing programming languages: your first job is to explain the uses, business rules and circumstances that would make the project fail.

Download or copy the free requirements document template. This text file opens in a browser or editor and can be copied into Word or Google Docs. It includes sections to complete, an acceptance checklist and a fictional example. No email address is required.

Start with the problem, not the screens

Write the need in one sentence from the perspective of the person experiencing it. ‘My customers need to book a time slot without calling me’ gives a clearer objective than ‘I want a modern calendar’. Add the current situation: who answers calls, where appointments are recorded and which errors occur.

Then define how you will recognise an improvement. In our fictional booking example, the objective might be for customers to choose from published availability and for the manager to find every booking in one place. Any numerical targets should start from your measured situation, not a promise found elsewhere.

Describe users and their journeys

Name every role and its permissions. The customer views slots and books. The manager opens availability and cancels a booking. A colleague can view the schedule without changing the times. Specify whether an account is needed and how someone regains access.

Then describe the full journey: a customer opens the page, chooses a slot, enters her details, confirms, then receives a summary. Ask the missing questions: what happens if someone else has just booked? If the email fails? If she wants to cancel? These exceptions are part of the requirements; they should not be discovered only after delivery.

Write the rules and the limits of the first version

In this example, a slot accepts a single booking and lasts thirty minutes. The customer can cancel until twenty-four hours before the appointment; after that, they contact the manager. These are fictional choices to illustrate the method, to be replaced with your own rules.

Also list what can wait: online payments, SMS reminders, subscriptions and a mobile app. A website usable on a phone may cover the initial need. Every new idea goes into a separate list, along with the reason to add it. That keeps the scope clear for both you and the person building it.

Inside Maestro · built-in Tablée demo · captured September 6, 2026

Make every requirement verifiable

An acceptance criterion describes a starting situation, an action and an observable result. For booking: given an available slot, when a customer confirms with valid contact details, a single booking appears in the schedule and the slot is no longer offered.

Second criterion: when two customers try to confirm the same slot, only one obtains the booking; the other receives an explanation and can choose another time. Third criterion: a colleague with viewing permissions only cannot change availability, even by trying to access the corresponding action directly.

For a speed requirement, state the page, device, connection and measurement conditions agreed with the person delivering the project. ‘Fast’ cannot be verified; a threshold without test conditions can be debated endlessly. Attach a person responsible for checking and expected evidence to each criterion: a described test, screenshot or recorded result.

Do not forget data and operations

Describe the information to retain, its origin, who can view it and when it must be deleted. Identify files to migrate and necessary connections. If you are starting from a workbook, identify the rules hidden in its columns before you replace Excel with an application.

Also specify who will own the hosting accounts, domain and code repository, who will receive alerts and who will fix incidents. Ask how to export data, restore a backup and transfer maintenance. These questions influence the project cost as much as the visible features do.

Keep the document alive without complicating it

Date each version, record decisions and keep unresolved questions visible. Before a significant change, ask about its effect on the schedule, budget and acceptance criteria. Have the journeys reviewed by the people who will actually use the application.

You can start with a few pages and complete the downloadable template as answers arrive. With a service provider or within Maestro's workflow, this document becomes a basis for discussion and approval. It describes what you want to achieve; technical choices then make it possible.