APPLICATION REQUIREMENTS DOCUMENT TEMPLATE Maestro · Template version: September 6, 2026 Guide: https://www.bemaestro.fr/en/journal/cahier-des-charges-non-technique HOW TO USE Copy this document into your preferred editor. Replace the fields in square brackets. Write “to be decided” where an answer is missing, with an owner and a decision date. Remove the fictional example before sharing your version. This template describes a product need; it does not replace a service contract. 1. PROJECT IDENTITY AND DECISIONS Project name: [name] Project owner: [name and role] Document version and date: [version / date] Person who approves scope: [name] People consulted: [users, operations, service provider] Status: [draft / for review / approved] Decision log: - [date] [decision] [reason] [approver] [consequences] 2. PROBLEM AND OBJECTIVE Today, [person] needs to [task], but [observable obstacle]. Consequence: [error, duplicate entry, delay, observed cost]. How is the problem handled today? [tool and steps] What evidence do we have? [examples, dated observations, available measurements] Expected outcome: [what should become possible] Success indicator: [measurement, current situation, target to justify] When and how will it be measured? [method and owner] Alternatives considered: [improve existing tool / off-the-shelf software / build] Why this project? [reasons and limitations of alternatives] 3. USERS AND PERMISSIONS Complete for each role: - Role: [clear name] - Tasks performed: [list] - Information they can view: [list] - Allowed actions: [create / edit / approve / delete / export] - Prohibited actions: [list] - Data scope: [their own / their team / entire organization] - Access: [no account / personal account / invitation / other] - Access removal or recovery: [expected procedure] Do not assume hiding a screen is enough to prevent an action: specify the checks to perform with each role. 4. FIRST VERSION SCOPE Essential for first use: - [feature]: [need covered and person concerned] Useful later: - [feature]: [reason to defer it] Explicitly excluded: - [feature, platform, or connection not planned] Dependencies before starting: [access, content, data, decisions] Criterion for postponing or abandoning the project: [concrete condition] 5. USER JOURNEYS TO BUILD Identifier: [P-01] Name: [action performed by a person] User: [role] Starting situation: [information and state already available] Steps: 1. [user action] 2. [expected application response] 3. [next action] Final outcome: [what the person gets] Cases to handle: - Missing or invalid input: [behavior] - Simultaneous action by another person: [behavior] - Lost connection or unavailable service: [behavior] - Cancellation or correction: [behavior] - Insufficient permission: [behavior] Duplicate this section for each essential journey. 6. BUSINESS RULES Identifier: [R-01] Rule in one sentence: [when..., then...] Allowed example: [values and result] Rejected example: [values and expected explanation] Exceptions: [which ones, who can authorize them] Who confirms this rule? [name] Affected journeys: [identifiers] Also describe rules embedded in formulas, colors, comments, and working habits around the old tool. 7. DATA AND DOCUMENTS For each item of information: - Name and meaning: [e.g. order identifier] - Required? [yes / no / under what condition] - Format and allowed values: [text, date, list, amount and currency] - Source: [manual entry, import, external service] - Who can view or edit it? [roles] - Retention and deletion: [rule to approve] - Required export: [format, content, permissions] Confidential data to protect: [categories, without real sensitive examples] Fictional data available for testing: [test dataset] Owner of privacy questions: [name or role] Services that will receive the data: [confirm with the builder] 8. MIGRATING EXISTING DATA Sources to migrate: [files, databases, documents] Known volume and measurement date: [item count and size] Stable identifiers: [how to find an item unambiguously] Duplicates and missing fields: [handling rules] First import sample: [ordinary cases and exceptions] Checks: [item counts, totals, relationships, dates, exceptions] Approval owner: [name] Initial backup retained: [location and owner] Target switchover date: [date and prerequisites] Authoritative source during transition: [tool and editing rules] Condition for returning to the old tool: [issue and decision-maker] Reapplying changes since the backup: [procedure] Old tool after switchover: [read-only / archived / other] 9. CONNECTIONS, DEVICES, AND USABILITY External connections: [service, operation, data exchanged, account owner] Behavior if a connection fails: [message, recovery, alert] Devices and browsers to support: [prioritized list] Keyboard use, readability, and accessibility needs: [situations to check] Expected performance: [action, agreed threshold, device, connection, conditions] Required availability: [hours and consequences of an interruption] Languages and formats: [languages, dates, numbers, time zones] 10. ACCEPTANCE CRITERIA Identifier: [CA-01] Related journey and rule: [P-01 / R-01] Given: [starting situation and test data] When: [action] Then: [observable result and absence of unwanted effects] Verified by: [person] Evidence: [scenario executed, screenshot, test result] Status: [to test / passed / needs fixing] Date and version tested: [date / version] Include criteria for errors, permissions, and simultaneous actions, not just the journey where everything goes well. 11. DELIVERY, OPERATIONS, AND EXIT Expected deliverables: [application, code, documentation, exports, training] Account ownership: [domain, hosting, code repository, services] Access to hand over to the owner: [list, no passwords in this document] Backups: [content, agreed frequency, owner, restoration test] Incidents: [contact channel, owner, agreed response time] Maintenance: [fixes, updates, scope, cost to specify] Exit or change of provider: [code, data, documents, and access to recover] Known limitations at delivery: [list and acceptance decision] 12. BUDGET, SCHEDULE, AND APPROVAL Build budget: [cap or range to confirm] Recurring costs to price separately: [hosting, services, maintenance, AI usage] First journey to deliver: [identifier] Stages and approvers: [stage / target date / owner] User availability for testing: [time slots] Procedure for a new request: [description, impact, agreement before implementation] Open questions: [question / owner / expected date] Document approval: [name / date / version / any reservations] FICTIONAL EXAMPLE TO REPLACE: APPOINTMENT BOOKING Problem: customers call to book, and the manager copies the appointments into a calendar. They want to publish availability and receive bookings in the same place. First version: view slots, book, confirm, cancel, and manage the schedule. No online payments or text messages. Roles: the customer books; the manager opens slots; a colleague views the schedule without changing availability. R-01: a thirty-minute slot accepts only one booking. R-02: the customer can cancel up to twenty-four hours before the appointment. After that, the application asks them to contact the manager. These durations illustrate a business choice, not a universal rule. P-01: the customer views available slots, chooses one, enters their contact details, and confirms. The booking appears in the schedule. The slot is no longer offered. A confirmation is prepared for the customer; a delivery failure must be visible to the manager without deleting the booking. CA-01: given an available slot, when a customer confirms with valid contact details, then exactly one booking appears in the schedule and the slot is no longer offered. CA-02: when two customers confirm the same slot simultaneously, only one booking is accepted. The other person receives an explanation and can choose another slot. CA-03: when a read-only colleague tries to edit a slot, the action is denied and availability stays unchanged, including when they try to access the action directly without using their screen. Open questions: which contact details are necessary? How long should they be kept? Who receives an alert if a confirmation is not sent? How can a booking error be corrected after the cancellation deadline?