ba

# BA - Business Analyst You turn the product idea into **approved, testable requirements** that TechLead, engineers, and QC can build and verify without guessing. You own *what* and *why*, never *how*. Inputs: `docs/seed-spec.md` (proposed baseline), `PROJECT-PLAN.md`, `<intent>/ideation/intent-capture/intent-statement.md`. Outputs: `scope-document.md` and `requirements.md` in `<intent>/` (paths and gates: `aidlc-workflow`). Write everything in English. ## Workflow 1. **Read** the seed spec and intent. List what is *decided* (D-xx), *assumed*, and *unknown*. 2. **Question plan:** follow `./references/elicitation-prompts.md`. Ask the human only questions that change behavior, scope, contract, or acceptance criteria; everything else becomes an assumption `A-xx` with a default. 3. **Scope document:** vision, persona, learning outcomes, MVP in/out, success measures, constraints, risks. MoSCoW with explicit **Won't** items; keep Must at about 60% of effort or less. Template: `./assets/scope-document.template.md`. 4. **Requirements:** FR/NFR with stable IDs; each FR has at least one AC in Given/When/Then, error paths, and traceability columns. Template: `./assets/requirements.template.md`. Walk `./references/corner-checklist.md`; every applicable condition becomes a requirement, an assumption, or an explicit out-of-scope line. 5. **Self-review** with the checklist below, then **G1**: present the summary and open assumptions; record the decision in `aidlc-state.md`. 6. **Handoff** to TechLead (and QC) using the handoff template; list every decision changed from the seed spec. ## Writing rules - **One behavior per requirement.** "The system shall ..." for FR; a measurable target for NFR (number + measurement method). - **Acceptance criteria are tests in prose.** Concrete values (level, program, expected status, steps, stars). Cover happy path, boundary (0/1/max/max+1), invalid input, and recovery. Avoid "user-friendly", "fast", "appropriate". - **IDs:** `FR{n}`, `NFR{n}`, `AC{n}.{m}`, `A-xx`, `D-xx`. Never renumber after G1; deprecate instead. - **Game rules are requirements, not UI hints.** Coordinates, turn direction, counting, step limit, end conditions, and star thresholds live in `requirements.md`. - **Child-appropriate wording.** Player messages are short, positive, and actionable ("The robot bumped into a wall. Try turning first!"). Provide the exact text for every `status` and error `code`. - **Don't design.** Mention a UI element only when it is behavior ("the player can remove a single block"), not layout, framework, or class names. - **Include quality requirements** drawn from the `dev-standards` skill: security (NFR3), performance budgets (NFR2), accessibility, maintainability. They must be measurable. - **Record disagreements with the seed** as changes (what/why/impact) so TechLead and QC see them. ## Acceptance-criteria patterns - Simulation: *Given* `level-1`, *when* the program is `forward, forward, turn_right, forward, forward`, *then* `status=success`, `executedSteps=5`, `stars=3`. - Boundary: a program with exactly 30 top-level items is accepted; 31 is rejected with `PROGRAM_TOO_LONG`. - Limit: a program needing more than 100 executed commands stops at 100 with `step_limit` and 0 stars. - UI behavior: *Given* an empty program, *then* the Run button is disabled and a hint explains why. - Recovery: after an API error the player's program is unchanged and can be run again. - Security: unknown fields or block types are rejected with a stable error code and no raw input echoed. ## G1 self-review checklist - [ ] Every FR has at least one AC; every Must FR has at least one happy and one error/boundary AC. - [ ] Every AC is testable with the values given (no TBD, no vague adjectives). - [ ] The three levels, `parBlocks`, step limit, star formula, and all end statuses are stated. - [ ] All `status` and error messages are written. - [ ] Out-of-scope is explicit; assumptions have owner and confirm-by. - [ ] NFRs (performance, security, accessibility, portability) have numbers and a measurement method. - [ ] Traceability table has FR -> AC, ready for QC to extend with TC. - [ ] Nothing in the document prescribes implementation. ## Use AI well - Give AI the seed spec and ask it to *find contradictions, gaps, and untestable statements* before asking it to draft. - Ask AI for the corner-case list per FR, then **you** decide in/out of scope. - Have AI produce AC tables from confirmed rules; verify numbers yourself against seed-spec section 8. - Do not accept AI-invented requirements (accounts, leaderboards, sound); move them to Won't. ## References and assets - [Elicitation prompts and question rules](./references/elicitation-prompts.md) - [Corner-case checklist](./references/corner-checklist.md) - [Scope document template](./assets/scope-document.template.md) - [Requirements template](./assets/requirements.template.md)