The starting brief
I want an ordering system for five restaurants with online payments and kitchen screens. Each restaurant needs to manage its own menu and orders, while I need an overview of the whole business.
- People
- Customers, kitchen staff, restaurant managers and the group operator
- Success
- A customer places an order and the correct kitchen receives it without manual re-entry.
- Outside this first release
- Delivery-driver routing and loyalty rewards
Requirements to review
- Browse the menu for a selected restaurant
- Place and pay for an order
- Show incoming orders on a kitchen screen
- Manage menus per restaurant
- View order history across five locations
Decisions that shape the implementation
When does the kitchen receive an order?
Define whether a payment authorisation, capture or confirmed webhook makes the order actionable. A customer returning to the confirmation page must not create a second kitchen ticket.
Who owns a restaurant’s menu?
Specify whether managers can change only their location’s menu or shared items too. Prices, availability and opening hours need a clear scope, including what happens to a basket when a price changes.
What happens during a retry?
Choose an idempotency rule for checkout, a reconciliation process for delayed payment events and a recovery workflow for a disconnected kitchen screen. Define who can cancel or refund an order.
Acceptance tests worth writing
- Submitting the same checkout twice creates one paid order and one kitchen ticket.
- A manager from one restaurant cannot read or change another location’s orders.
- The customer can see the confirmed restaurant, items, total and current order state.
- A kitchen reconnecting after a network failure retrieves missed orders without duplicates.
How to use this specification
Walk through one complete order with restaurant staff before agreeing the scope. Decide whether collection, delivery, tips, tax, refunds and allergy information belong in the first release. The starting example excludes delivery-driver routing and loyalty rewards.
Review the guided draft’s assumptions, requirements and open decisions with the people who will use the system. Record effort estimates only after an engineer has examined the scope. A downloaded brief is a starting document, not approval to build or deploy software.
Download the working files
The JSON file can be imported through Build Brief’s “Import project” control. Markdown works in document editors and Git repositories; CSV gives you a requirements matrix; the agent task includes an explicit review-first engineering handoff.
Template edition: 21 October 2026. Published by Leemer Group. Guided drafting runs without an AI request; all generated proposals remain marked for review.