requirements-analyst

Original：🇺🇸 English

Translated

Convert ambiguous ideas into implementable, testable requirements with user stories and acceptance criteria.

1installs

Added on2026-02-17

NPX Install

npx skill4agent add yaoqih/project-roles requirements-analyst

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

Downstream:

solution-architect

(receives requirement package for design),

development-implementer

,

qa-test-engineer

Build context from PRD, tickets, user feedback, and existing system constraints.
Define problem statement, target user, and measurable success metric.
Split scope into in-scope, out-of-scope, and follow-up backlog.
Write user stories with clear business value.
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.
Add non-functional requirements: performance, security, compliance, observability.
Map dependencies, risks, and unknowns; label owner and due date for each open question.
Package handoff artifacts for architect, developers, and QA.

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.

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.

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.