# Restaurant ordering system LG / Build Brief · Guided template draft · 2026-10-21 Status: 6 unresolved blocking decisions; 7 requirements still need review. ## Project 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 and success Audience: 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\. Platform: web Requested timeline: Not specified Budget supplied by project owner: Not specified ## Out of scope - Delivery\-driver routing and loyalty rewards ## Assumptions to verify - This is a first\-release planning draft; proposed requirements and tests need owner review\. - No implementation stack, external pricing or delivery commitment has been independently verified\. ## User journeys ### Customers, kitchen staff, restaurant managers and the group operator 1. Customer chooses a restaurant 2. Customer adds items and pays 3. Kitchen receives the order 4. Staff update the order status ## Requirements and acceptance criteria ### R01 · Browse the menu for a selected restaurant Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Deliver this visitor\-specified capability: Browse the menu for a selected restaurant - [ ] Given a user permitted to perform this task, when they complete “Browse the menu for a selected restaurant”, then the intended result is visible and can be checked against an agreed worked example\. - [ ] When required information is missing or invalid, the system explains the problem and preserves any valid work already entered\. ### R02 · Place and pay for an order Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Deliver this visitor\-specified capability: Place and pay for an order - [ ] Given a user permitted to perform this task, when they complete “Place and pay for an order”, then the intended result is visible and can be checked against an agreed worked example\. - [ ] When required information is missing or invalid, the system explains the problem and preserves any valid work already entered\. ### R03 · Show incoming orders on a kitchen screen Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Deliver this visitor\-specified capability: Show incoming orders on a kitchen screen - [ ] Given a user permitted to perform this task, when they complete “Show incoming orders on a kitchen screen”, then the intended result is visible and can be checked against an agreed worked example\. - [ ] When required information is missing or invalid, the system explains the problem and preserves any valid work already entered\. ### R04 · Manage menus per restaurant Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Deliver this visitor\-specified capability: Manage menus per restaurant - [ ] Given a user permitted to perform this task, when they complete “Manage menus per restaurant”, then the intended result is visible and can be checked against an agreed worked example\. - [ ] When required information is missing or invalid, the system explains the problem and preserves any valid work already entered\. ### R05 · View order history across five locations Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Deliver this visitor\-specified capability: View order history across five locations - [ ] Given a user permitted to perform this task, when they complete “View order history across five locations”, then the intended result is visible and can be checked against an agreed worked example\. - [ ] When required information is missing or invalid, the system explains the problem and preserves any valid work already entered\. ### R06 · Recover from an interrupted workflow Priority: must · Owner review: pending · Effort: not estimated · Dependencies: R01 Define and implement safe failure handling for the primary workflow, including duplicate submission and connection loss\. - [ ] An interrupted operation reports its state and offers a recovery action\. - [ ] Repeating a completed action does not accidentally create a second completed operation\. ### R07 · Support accessible use Priority: must · Owner review: pending · Effort: not estimated · Dependencies: none Make the primary workflow operable by keyboard, label its controls and communicate errors in text\. - [ ] A user can complete the primary workflow with a keyboard and visible focus\. - [ ] Inputs have programmatic labels, and errors identify both the problem and the affected input\. ## Proposed architecture — requires engineering review ### Interface A responsive browser interface for the primary workflow and its recovery states\. Rationale: A first\-release proposal\. Confirm supported devices, connectivity and accessibility needs before choosing an implementation\. ### Application boundary Server\-side operations validate requests and enforce permissions before applying changes\. Rationale: Business rules should remain consistent across interfaces and integrations\. ### Data A transactional data store for the core records, with explicit ownership, retention and backup decisions\. Rationale: The final schema depends on the confirmed workflow\. The entities below are starting proposals\. ### Payments A payment\-provider boundary with persisted payment states, idempotent requests and verified event handling\. Rationale: Avoid duplicate financial operations and reconcile outcomes when a request is interrupted\. Provider selection remains open\. ## Proposed data model ### WorkItem Proposed representation of the core workflow record\. Rename and expand it to match the confirmed domain\. Fields: id, status, createdAt, updatedAt ### User Proposed identity and role reference; authentication and access rules still need review\. Fields: id, role, createdAt ### Payment Proposed payment state and reconciliation record; payment\-card details stay with the provider\. Fields: id, workItemId, providerReference, amountMinor, currency, status, idempotencyKey ### Location Proposed location boundary\. Which records belong to a location must be confirmed\. Fields: id, name, status ## Implementation milestones ### 01 · Resolve the blocking decisions The project owner confirms scope, data boundaries and failure behaviour\. An engineer reviews the proposed requirements and tests\. Requirements: Planning / scope decision ### 02 · Deliver a complete vertical slice Demonstrate the primary workflow in a test environment, including validation and recovery states\. Requirements: R01, R06 ### 03 · Complete the agreed release scope Deliver the remaining first\-release requirements and run their acceptance criteria\. Requirements: R02, R03, R04, R05 ### 04 · Verify and hand over Review accessibility, permission boundaries and operational recovery\. Record test evidence before release approval\. Requirements: R07 ## Decisions ### BLOCKING · What data is stored, and how long should it be kept? Why it matters: Include personal or sensitive information, deletion rules and who controls access\. Answer: UNRESOLVED ### BLOCKING · What must happen when the main workflow fails? Why it matters: Consider lost connections, duplicate submissions and recovery without losing work\. Answer: UNRESOLVED ### BLOCKING · Who can access or change what? Why it matters: Roles and permissions affect the data model, tests and every protected workflow\. Answer: UNRESOLVED ### BLOCKING · How should payments, refunds and failed attempts work? Why it matters: Payment states, retries and reconciliation must be defined before implementation\. Answer: UNRESOLVED ### BLOCKING · Which data is shared, and which belongs to one location? Why it matters: Location boundaries affect authorisation, reporting and operations\. Answer: UNRESOLVED ### OPEN · Which existing tools or systems must it connect to? Why it matters: Name required integrations and whether access is already available\. “None” is a useful answer\. Answer: UNRESOLVED ### BLOCKING · Who signs off the first release, and how will they test it? Why it matters: A named owner and a realistic test setting make the handoff easier to execute\. Answer: UNRESOLVED ## Complexity and planning estimate Complexity: undetermined. Complexity needs engineering review of the proposed requirements, integrations and open decisions\. Add effort estimates per requirement to calculate a planning total\. Cost drivers: - Number of workflows and user roles - User accounts - Payments - Multiple locations - Data migration, testing and launch operations Must/should requirements: 0 hours entered; 7 unestimated. Hourly rate supplied by owner: not specified. Planning labour cost: incomplete. Team capacity: not specified. Planning duration: incomplete. Arithmetic uses owner-entered effort and rates only, excludes could-priority requirements, ongoing services, tax and unmodelled work. This is a planning aid, not a supplier quote or delivery commitment.