Loading...

Back to Details

requirements-analyst

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Requirements Analyst

需求分析师

Core Outcome

核心成果

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

产出一份工程师可落地、QA可验证的需求包，无需反复沟通确认。

Collaboration

协作对象

Upstream: Product stakeholders, user feedback, business context

Downstream:

solution-architect

(receives requirement package for design),

development-implementer

,

qa-test-engineer

上游：产品利益相关者、用户反馈、业务场景

下游：

solution-architect

（接收需求包进行设计）、

development-implementer

、

qa-test-engineer

Workflow

工作流程

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.

从PRD、工单、用户反馈及现有系统约束中梳理业务背景。
定义问题陈述、目标用户及可衡量的成功指标。
拆分范围为在研范围、排除范围及后续待办事项。
撰写具备明确业务价值的用户故事。
用可测试的语言撰写验收标准（优先采用Given/When/Then格式）。
- 回退检查点：若技术可行性存疑，在最终确定标准前需咨询
```
solution-architect
```
  以验证假设。
添加非功能性需求：性能、安全、合规、可观测性。
梳理依赖关系、风险及未知项；为每个待解决问题标注负责人和截止日期。
为架构师、开发人员和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.

已提供明确验收标准的清晰任务：直接转交
```
development-implementer
```
处理。
无用户端行为变化的纯技术债务或重构工作：改用
```
solution-architect
```
。
需求为探索性研究而非需求定义：先开展调研，再回到该技能。
预期行为明确的Bug修复：直接使用
```
debug-troubleshooter
```
。

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.

预期输入：产品想法、PRD、工单、用户投诉或利益相关者请求。
输出格式：结构化需求包（见下方输出模板）。
澄清策略：若缺少业务背景、目标用户或成功指标，在起草需求前需明确询问相关信息。

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
```
).

范围边界明确且已达成共识。
验收标准可判定、可测试。
已识别API和数据影响。
已记录非功能性约束。
待解决问题已跟踪负责人和截止日期。
优先级明确（
```
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

背景与问题
目标与非目标
用户故事
验收标准
非功能性需求
依赖关系与风险
待解决问题
交付优先级与里程碑