Arcade Ticketing: BA Evidence Pack

1. Process comparison

View the workflow diagram and text equivalent

Scope: broken machines, game-card issues, refunds, prize-counter problems, and facility incidents at one location. Payment processing, customer self-service, integrations, and software configuration are outside this pack.

Safety first: for an immediate hazard, staff would secure the area and follow the emergency procedure before documenting the incident when safe. The ticket would record the response; it would not replace it.

Simulated current state and proposed future state
Step / need	Simulated current state	Proposed future state and role	Control / exception
P-01 Intake	Staff use conversations, paper, calls, and messages; required details vary.	Reporting staff capture category, location, description, and urgency in one ticket.	Reject incomplete intake. Record immediate-hazard response after the area is safe.
P-02 Triage	Urgency and responsibility depend on who hears the report.	Shift lead confirms impact and priority, then assigns a team and named owner.	Unclear routing remains with the shift lead until an owner accepts it; safety concerns get immediate operational attention.
P-03 Work and approval	Work and refund decisions may be communicated outside the original report.	Owner records investigation and actions. An authorized manager approves or rejects a refund before fulfillment is recorded.	Requester cannot approve their own refund. Rejection records a reason and customer communication.
P-04 Pending	Parts, vendor, and customer dependencies are difficult to distinguish from idle work.	Owner records the dependency, next action, and review date while retaining ownership.	Shift lead reviews overdue pending tickets; receipt of the dependency returns work to In Progress.
P-05 Resolve and verify	A verbal completion update may be the only evidence that an issue was fixed.	Owner records the resolution. Shift lead verifies restoration or customer-facing completion before closure.	Failed verification returns the ticket to In Progress with a reason. Resolved is not the same as Closed.
P-06 History and reporting	Scattered reports make backlog and completion measures inconsistent.	System preserves dated changes and shows ticket-level backlog and closure counts to authorized managers.	Closed history remains intact. A recurring issue creates a linked new ticket rather than overwriting the old record.

Proposed routing and status rules

Machine issues route to maintenance; game-card and prize-counter issues to guest services; refunds to the shift lead for manager approval; facility incidents to facilities. These are role assumptions for validation in discovery. The shift lead owns unassigned tickets and reassignment decisions.

Lifecycle: New → Triaged → Assigned → In Progress → Resolved → Closed. Pending is an optional branch from In Progress and returns there when work resumes. Approval is a separate decision field; a refund awaiting approval stays In Progress. Failed verification returns Resolved to In Progress.

Proposed priority definitions: Critical = immediate safety concern, with emergency response first; High = service unavailable with no workaround; Normal = degraded service or an available workaround. These labels define triage order only. Response-time targets require stakeholder agreement.

2. Requirements register

All entries are Proposed / awaiting stakeholder review. Must = needed for the proposed pilot controls; Should = useful for pilot evaluation. Review roles below are fictional responsibilities, not recorded approvals.

Proposed pilot requirements
ID / type	Requirement	Rationale	Priority / review role
REQ-01 Data	Require one of the five categories, a location, a nonblank description, and urgency on submission. Assign a unique ticket ID, reporter, and created timestamp.	P-01: give each report a usable common record.	Must · Shift lead
REQ-02 Safety	Display the emergency-first instruction at intake. For an immediate-hazard report entered when safe, require response notes and shift-lead acknowledgment before resolution.	P-01: keep ticketing subordinate to emergency response.	Must · Operations manager
REQ-03 Workflow	Record confirmed impact, priority, team, and named owner before In Progress. Log reassignment actor, time, and reason. Keep unclear routing with the shift lead.	P-02: prevent work from becoming ownerless.	Must · Shift lead
REQ-04 Approval	For refunds, require a transaction reference, positive requested amount, and reason. An authorized manager other than the requester must record a decision and approved amount before fulfillment; reject fulfillment above that amount.	P-03: make authorization separate from fulfillment.	Must · Operations manager
REQ-05 Workflow	Allow Pending only with a reason (parts, vendor, or customer input), next action, review date, and retained owner. Flag it for the shift lead when that date has passed.	P-04: make blocked work reviewable.	Must · Shift lead
REQ-06 Closure	Require action notes and a resolution code (restored, fulfilled, declined, or duplicate) to resolve. Require shift-lead verification, verifier, and timestamp to close. Failed verification must return to In Progress with a reason.	P-05: distinguish an attempted fix from confirmed completion.	Must · Shift lead
REQ-07 Audit	Preserve actor, timestamp, old value, and new value for status, ownership, and approval changes. Prevent staff from editing history or closed records; create a linked new record for recurrence.	P-06: preserve the basis for review and reporting.	Must · Platform owner
REQ-08 Access	Staff may view their own reports and tickets assigned to their team; shift leads and authorized managers may view location-wide tickets. Restrict refund decisions to authorized managers. Use transaction references, never full payment-card numbers.	P-03 / P-06: restrict sensitive work and unnecessary data collection.	Must · Security reviewer
REQ-09 Reporting	Show counts by category, owner, and status as of a displayed refresh time. Open backlog includes every status except Closed. Period closures use closed timestamp and the half-open interval [start, end), in the agreed location time zone.	P-06: provide reproducible backlog and closure measures.	Should · Operations manager
REQ-10 Usability	Allow keyboard-only intake and correction. Identify invalid fields in text, associate each message with its field, and retain valid entries after a validation error.	P-01: help staff complete intake without losing work.	Must · Staff representative

Decisions still open

Real discovery must confirm role membership, refund authority limits and currency, location time zone, retention periods, escalation timing, service targets, outage procedures, and the system of record for financial transactions. This sample does not define a production security model or integration design.

3. User stories and acceptance criteria

Given/When/Then statements describe proposed observable behavior. They are specifications, not executed automated tests.

AC-01 · Complete intake · REQ-01

Story: As reporting staff, I want one identifiable report so the next person can act on it.

Given an intake form, when I submit an invalid category or omit a required value, then submission is blocked with a field-specific error. Given valid values, when I submit, then the record has a unique ID, reporter, created timestamp, and the supplied values.

AC-02 · Document safety response · REQ-02

Story: As a shift lead, I want emergency handling documented without delaying the response.

Given intake is open, then an emergency-first instruction is visible. Given a hazard report entered when safe, when response notes or shift-lead acknowledgment are missing, then resolution is blocked; after both are recorded, ordinary resolution checks apply.

AC-03 · Own the work · REQ-03

Story: As a shift lead, I want an accountable owner for each active issue.

Given an untriaged ticket, when impact, priority, team, or owner is absent, then In Progress is blocked. Given all are present, when the shift lead starts work or reassigns it with a reason, then the current owner is visible and the change is dated and attributed.

AC-04 · Authorize a refund · REQ-04

Story: As an operations manager, I want refund authorization recorded before fulfillment.

Given a refund with a transaction reference, positive requested amount, and reason, when an authorized manager other than its requester approves an amount, then fulfillment may be recorded up to that amount. Missing details, self-approval, no approval, a declined decision, or an amount above approval must block fulfillment.

AC-05 · Review blocked work · REQ-05

Story: As an owner, I want a documented dependency so a waiting ticket is not forgotten.

Given In Progress, when I select Pending without its reason, next action, or review date, then the change is blocked. With all fields present, Pending retains my ownership. When the review date passes, then the ticket is flagged to the shift lead; when the dependency arrives, work can return to In Progress.

AC-06 · Verify before closure · REQ-06

Story: As a shift lead, I want evidence that the issue is complete before closing it.

Given action notes and a valid resolution code, when the owner resolves the ticket, then it remains Resolved until shift-lead verification. Missing resolution fields or verification block their respective transitions. Successful verification records verifier and time and allows Closed; failure requires a reason and returns it to In Progress.

AC-07 · Preserve history · REQ-07

Story: As a reviewer, I want prior decisions preserved so I can reconstruct what happened.

Given a changed status, owner, or approval, when I inspect history, then I see actor, time, and old and new values. When staff try to edit history or a Closed record, then the write is denied. A recurring issue can be recorded as a new ticket linked to the original.

AC-08 · Restrict access · REQ-08

Story: As a staff member, I want access appropriate to my assigned work.

Given a staff account, when it requests a ticket neither reported by it nor assigned to its team, then access is denied, including by direct record URL. Its own and team records remain readable. Location-wide access is available to shift leads and authorized managers; only an authorized manager can record a refund decision. Intake requests a transaction reference and warns against recording full payment-card numbers.

AC-09 · Reconcile reporting · REQ-09

Story: As an operations manager, I want counts I can reconcile to individual tickets.

Given a controlled set of dated tickets, when I run the report, then displayed group totals reconcile to included records, Resolved and Pending remain in open backlog, only Closed records count as closed, and the refresh time is shown. Closures at the period start are included; closures exactly at its end are excluded.

AC-10 · Correct intake errors · REQ-10

Story: As reporting staff using a keyboard, I want to correct errors without re-entering valid information.

Given keyboard-only input, when I submit with a required value missing, then I can reach and correct the field, its error is programmatically associated and visible in text, and valid entries remain. When I resubmit, then the valid ticket is saved with a visible confirmation.

4. Planned UAT tests

Every test below: Not Executed. Actual result, evidence, tester, and execution date: not recorded.

Prerequisites: a configured test environment implementing the proposed rules; synthetic tickets only; staff, second-team staff, shift-lead, and manager test accounts. A future tester would record actual results and evidence against each ID, log defects, and rerun failed cases. These materials alone do not demonstrate acceptance.

UAT-01 · Valid intake · AC-01. Setup: staff account and valid inputs for each of the five categories. Action: submit one record per category. Expected: five distinct IDs, correct input values, reporter, and timestamps.
UAT-02 · Invalid intake · AC-01, AC-10. Setup: a populated draft. Action: submit once for each omitted required field, a whitespace-only description, and an unsupported category. Expected: each invalid submission is blocked, the relevant field has a textual error, and valid input is retained.
UAT-03 · Safety path · AC-02. Setup: synthetic facility hazard already made safe in the scenario. Action: inspect intake instructions; attempt resolution with missing response notes, then missing acknowledgment, then both supplied with valid resolution fields. Expected: emergency-first text is visible; incomplete attempts fail; the complete attempt succeeds.
UAT-04 · Routing and reassignment · AC-03. Setup: a New ticket for each category. Action: apply the routing map; try In Progress with each triage field missing in turn, then complete them; reassign with a reason. Expected: incomplete triage is blocked, completed tickets have the expected teams and owners, and reassignment records actor, time, and reason. An unclear route remains with the shift lead.
UAT-05 · Approved refund · AC-04. Setup: synthetic reference TX-DEMO-01, request of 10 test currency units, reason, and a separate authorized manager. Action: approve 10 and record fulfillment of 10. Expected: decision, approver, approved amount, and fulfillment are recorded; no actual payment is sent.
UAT-06 · Refund controls · AC-04, AC-08. Setup: separate refund records. Action: try missing reference, zero amount, missing reason, self-approval, a staff decision, fulfillment without approval, fulfillment after rejection, and fulfillment of 11 against approval of 10. Expected: each prohibited action is blocked and no fulfillment is recorded.
UAT-07 · Pending and review · AC-05. Setup: an owned In Progress ticket and controllable test date. Action: omit each Pending field in turn, then populate all; advance beyond the review date and resume work. Expected: missing fields block Pending, ownership persists, the overdue flag appears to the shift lead, and the record returns to In Progress.
UAT-08 · Successful closure · AC-06. Setup: a completed repair ticket. Action: omit notes and code in separate resolution attempts; supply both; try closing without verification; then verify as shift lead and close. Expected: invalid transitions fail; valid closure records the resolution, verifier, and verification time.
UAT-09 · Failed verification · AC-06. Setup: a Resolved machine issue. Action: record that the machine still fails, first without a reason, then with one. Expected: missing reason is rejected; completed failure returns the ticket to In Progress with its owner and failure reason retained.
UAT-10 · History and recurrence · AC-07. Setup: a ticket with status, owner, and approval changes, subsequently Closed. Action: inspect history, attempt staff edits to history and the closed record, then create a linked recurrence. Expected: history contains actor/time/old/new values; writes are denied; a separate linked ticket exists and original history is unchanged.
UAT-11 · Access boundaries · AC-08. Setup: own, same-team, and other-team tickets plus staff, shift-lead, and manager accounts. Action: try each record from lists and direct URLs with each role; inspect refund inputs. Expected: staff can read own/team records only; leads and managers can read the location; staff cannot decide refunds; inputs request a transaction reference and display the payment-data warning.
UAT-12 · Backlog reconciliation · AC-09. Setup: six tickets, one each New, Triaged, Assigned, In Progress, Pending, and Resolved; add two Closed tickets. Assign known categories and owners. Action: run the report. Expected: open backlog is 6, Closed is 2, category/owner/status breakdowns reconcile to the eight records, and refresh time is visible. These are synthetic test expectations, not business results.
UAT-13 · Period boundaries · AC-09. Setup: agree a test time zone and period; place Closed timestamps just before start, exactly at start, just before end, and exactly at end. Action: filter that period. Expected: exactly the middle two records count as period closures.
UAT-14 · Keyboard error recovery · AC-10. Setup: intake with a keyboard and accessibility inspection tool. Action: navigate all inputs, submit with one required value missing, inspect the error association, correct it, and resubmit. Expected: visible focus and logical navigation, an associated textual error, retained valid entries, and a saved-ticket confirmation.

Proposed exit decision

The operations manager would review recorded evidence for every Must requirement, resolved defects, and retest results before recommending a pilot. Any deferred Should requirement needs an explicit decision. No sign-off, pass rate, or readiness claim is recorded here.

5. Traceability sample

This matrix covers the ten requirements in this public sample. Links demonstrate planned coverage; they do not establish that a requirement has passed validation.

Process need → requirement → acceptance criteria → planned tests
Process need	Requirement	Criteria	Planned tests	Execution
P-01 Intake	REQ-01	AC-01	UAT-01, UAT-02	Not Executed
P-01 Safety	REQ-02	AC-02	UAT-03	Not Executed
P-02 Ownership	REQ-03	AC-03	UAT-04	Not Executed
P-03 Refund control	REQ-04	AC-04	UAT-05, UAT-06	Not Executed
P-04 Dependencies	REQ-05	AC-05	UAT-07	Not Executed
P-05 Verification	REQ-06	AC-06	UAT-08, UAT-09	Not Executed
P-06 History	REQ-07	AC-07	UAT-10	Not Executed
P-03 / P-06 Access	REQ-08	AC-08	UAT-06, UAT-11	Not Executed
P-06 Reporting	REQ-09	AC-09	UAT-12, UAT-13	Not Executed
P-01 Usability	REQ-10	AC-10	UAT-02, UAT-14	Not Executed

Change example: if refund authority changes, review REQ-04 and REQ-08, revise AC-04 and AC-08, update UAT-05, UAT-06, and UAT-11, then record the review decision and rerun affected tests in the future test environment.