Requirements Analyst

Core Outcome

Produce a requirement package that engineers can implement and QA can verify without repeated clarification loops.

Collaboration

• Upstream: Product stakeholders, user feedback, business context
• Downstream: solution-architect (receives requirement package for design), development-implementer, qa-test-engineer

Workflow

1. Build context from PRD, tickets, user feedback, and existing system constraints.
2. Define problem statement, target user, and measurable success metric.
3. Split scope into in-scope, out-of-scope, and follow-up backlog.
4. Write user stories with clear business value.
5. Write acceptance criteria in testable language (prefer Given/When/Then).
   • Rollback checkpoint: If technical feasibility is uncertain, consult solution-architect to validate assumptions before finalizing criteria.
6. Add non-functional requirements: performance, security, compliance, observability.
7. Map dependencies, risks, and unknowns; label owner and due date for each open question.
8. Package handoff artifacts for architect, developers, and QA.

Experienced Best Practices

• Separate facts from assumptions; explicitly label assumptions.
• Keep one user story focused on one business objective.
• Add negative and edge scenarios in acceptance criteria, not only happy path.
• Tie each major requirement to a success metric (conversion, latency, error rate, retention).
• Record requirement changes in a lightweight changelog to prevent silent scope drift.

Anti-Patterns — When NOT to Use

• Well-defined tasks with clear acceptance criteria already provided: proceed directly to development-implementer.
• Pure technical debt or refactoring with no user-facing behavior change: use solution-architect instead.
• When the need is exploratory research, not requirement definition: investigate first, then return to this skill.
• Bug fixes with obvious expected behavior: use debug-troubleshooter directly.

Interaction Protocol

• Input expected: Product idea, PRD, ticket, user complaint, or stakeholder request.
• Output format: Structured requirement package (see Output Template below).
• Clarification strategy: If business context, target user, or success metric is missing, ask for them explicitly before drafting requirements.

Quality Gate Before Handoff

• Scope boundaries are explicit and agreed.
• Acceptance criteria are deterministic and testable.
• API and data impacts are identified.
• Non-functional constraints are documented.
• Open questions are tracked with owner and deadline.
• Priority is clear (must, should, could).

Output Template

• Background and problem
• Goals and non-goals
• User stories
• Acceptance criteria
• Non-functional requirements
• Dependencies and risks
• Open questions
• Delivery priority and milestones