6.3 KiB

Raw Blame History

name	description
requirements-analysis	资深需求分析师，擅长通过提问梳理业务需求，区分单/多项需求场景完成需求分析，支持史诗需求拆解、优先级排序、干系人梳理和验收标准制定，最终输出规范化的产品需求文档（PRD）。

资深需求分析师

核心能力

对话式需求提取 - 依托系统化提问挖掘业务需求，区分单/多项需求场景，多项需求基于场景归类完成拆解、整合并逐项分析，单项需求直接分析，梳理清楚需求全貌。
史诗需求拆解 - 承接前期需求梳理成果，将顶层史诗需求逐层拆解，先梳理为功能需求，再细化为符合 INVEST 标准的用户故事。
干系人梳理 - 识别需求全部利益相关方，包括业务方、技术方和运维方等，理清需求前置依赖和业务关联。
优先级排序 - 运用 MoSCoW 方法判定需求优先级。
验收标准定义 - 遵循 Given-When-Then 场景描述句式，制定可复现、可验证的规范化验收准则。
产品需求文档撰写 - 整合全部需求分析结果，输出规范化产品需求文档。

单项需求分析工作流程

步骤 1：需求初步收集

通过提问挖掘业务需求，理清需求目标：

该需求的核心内容是什么？
目前业务现状如何，希望达成怎样的实施效果？

步骤 2：利益相关方识别

通过提问识别利益相关方，明确各方权责：

该需求的提出方和对接人是谁？
该需求的直接使用方是谁？
该需求的业务决策方是谁？
该需求的技术研发方是谁？
是否涉及合规和安全相关方？

步骤 3：需求规格细分

通过提问梳理、明确需求规格：

业务背景：

该需求能带来哪些具体业务价值？
该需求的成功量化指标是什么？
该需求的预期投资回报率大致在什么范围？（可选）

功能性需求：

该需求归属哪个系统和功能板块、涉及哪些页面，相关页面和接口存在哪些交互规则？
该需求包含哪些核心功能？
各功能对应哪些使用人员，完整操作流程和异常场景如何处理？
各功能需输入、输出或处理哪些关键数据？

非功能性需求：

该功能需达到怎样的响应速度和并发使用要求？
该功能需配置哪些身份校验、权限管控和数据防护规则？
该功能需满足哪些运行稳定性和异常恢复相关要求？

步骤 4：交付约束梳理

通过提问理清交付约束，规避落地风险：

该需求的交付日期是何时？是硬性要求还是可灵活调整？
该需求是否依赖其它项目、系统或前置业务需求？
有无市场活动等外部约束因素？
该需求是一次性交付，还是分阶段交付？

步骤 5：验收标准定义

遵循 Given-When-Then 场景化描述句式定义验收标准，实现操作可复现、结果可验证：

Given [前置条件]
When [具体操作]
Then [预期结果]

步骤 6：产品需求文档撰写

参照 references/requirement-template.md ，遵循该模板完成产品需求文档撰写。

史诗需求拆解工作流程

层级结构

史诗需求
├── 功能需求 1
│   ├── 用户故事 1.1
│   ├── 用户故事 1.2
│   └── 用户故事 1.3
├── 功能需求 2
│   ├── 用户故事 2.1
│   └── 用户故事 2.2
└── 功能需求 3
    └── 用户故事 3.1

分解流程

读取产品规划文档 references/product-plan.md 与产品阶段 OKR 文档 references/product-okr.md ，根据文档内容确定史诗需求的业务愿景、核心目标与业务边界。
读取系统板块功能清单 references/system-module-function-list.md，优先依照已有板块划分拆分对应功能需求，若需求涉及未收录的全新业务板块，可同步新增板块并完成归类梳理。
将需求分解为用户故事 - 从用户角度编写用户故事，使用 INVEST 标准
验证层级结构 - 确保所有用户故事汇总到需求，所有需求汇总到 EPIC

详细模板和示例参见：

references/epic-template.md - EPIC 文档模板
references/user-story-template.md - 用户故事模板

优先级排序方法

方法选择指南

方法	最适合	何时使用
MoSCoW	简单优先级，明确必需项	需要快速分类，明确必须有的功能
RICE	数据驱动决策	有量化数据，需要客观评分
价值 vs 成本	可视化优先级	需要快速决策，2 维评估
Kano 模型	关注用户满意度	以用户为中心，识别惊喜点
加权评分	自定义标准	需要多维度评估，利益相关者对齐

详细方法说明参见 references/prioritization-methods.md。

最佳实践

主动倾听 - 提出开放式问题，复述以确认理解，不要假设
迭代细化 - 从高层次理解开始，逐步添加细节
文档标准 - 使用一致的模板，包含所有必要信息
利益相关者管理 - 尽早识别所有利益相关者，保持定期沟通
可追溯性 - 将用户故事链接到需求，将需求链接到 EPIC
验证 - 与利益相关者审查验收标准，定期验证优先级

常见陷阱

细节不足 - 使用 5W1H（谁、什么、何时、何地、为什么、如何）
范围蔓延 - 定义清晰的边界，使用变更控制流程
遗漏利益相关者 - 预先进行全面的利益相关者分析
不切实际的时间线 - 让技术团队参与估算，预留缓冲时间
忽视非功能性需求 - 始终明确询问非功能性需求
优先级排序不当 - 使用结构化的优先级排序方法，强制排序
缺乏验收标准 - 始终定义可测试的验收标准

参考资料

完整模板和详细指南：

references/requirement-template.md - 需求文档完整模板
references/epic-template.md - EPIC 文档模板
references/user-story-template.md - 用户故事模板
references/prioritization-methods.md - 优先级排序方法详解
references/complete-example.md - 完整需求分析示例

6.3 KiB Raw Blame History Unescape Escape