“We need a booking app” names a product category, but leaves most decisions open. Who offers the appointments? Can customers cancel? Does a member of staff approve changes? A brief becomes useful when it connects these questions to the work the business actually does. Begin with one representative workflow, then add the roles, constraints and review decisions needed to build it.
On this page
Describe the current workflow and the problem
Write the sequence from the event that starts the work to the result that completes it. Include handovers between people and systems. In an illustrative booking business, a customer requests a time, staff check a shared calendar and confirmation is sent manually. The problem might be conflicting reservations or a lack of visibility for customers. Identify which difficulty matters before proposing a list of screens.
- What information starts the request?
- Who decides whether it can proceed?
- What tells everyone that it is complete?
Give each user a clear responsibility
Separate customer, staff and administrator needs. A customer may view their own bookings; staff may manage a schedule; an administrator may control who has that access. Describe corrections as well as normal actions. If a booking is moved by staff, who sees the change and what happens to the original slot? These rules help the design and development teams discuss the same product.
Draw a first-release boundary
For the booking example, a focused release could let a customer choose an available slot, receive confirmation and find the booking later, while staff can manage availability and handle cancellations. If repeat bookings or loyalty rewards can wait, put them in a separate list with a reason. Do not remove a supporting step that makes the agreed journey usable merely because it is less visible than the main screen.
- Include one complete journey from request to result.
- Include the access and correction tools needed to operate it.
- Give deferred ideas a condition for reconsideration.
List dependencies and mark the unknowns
Identify existing calendars, payment services, customer records and other systems the application may need. Note languages, target devices, migration needs and business constraints. Distinguish a confirmed requirement from a question: “Can the existing calendar provide live availability?” is useful information for a brief. Assuming that it can may hide investigation work and distort the initial scope.
Turn requirements into reviewable examples
Use plain-language acceptance checks. For the illustrative booking workflow: when a customer reserves an available slot, the reservation appears in their account and the staff schedule; if another customer tries to reserve the same single-capacity slot, they cannot receive a second confirmation. Agree how cancellation reopens availability. These examples expose decisions that “booking management” leaves undefined. Name who will review them and approve changes in scope.
- Review complete tasks with representative users.
- Record questions separately from approved requirements.
- Assign one person to resolve conflicting priorities.
Include the move into everyday use
Explain who will administer the application, introduce existing data and support users after launch. Identify the training or handover material that the team needs. Ask how issues will be reported and how updates will be reviewed. These details let the development scope include the practical route from a working demonstration to a product the business can operate.