用途
Requirements Elicitation 是一个系统化的工作流，用于从残缺或含糊的输入中提取完整、无歧义的规格说明。其核心原则是：需求的质量取决于所提问题的质量，需要透过多个利益相关方视角审视，并在所有完整性维度上验证。该工作流将不完整的描述转化为可执行的综合规格。
适用场景
- 收到简要笔记或不完整的描述
- 为新功能或系统收集需求
- 审查现有规格的完整性
- 陈述需求与可执行规格之间存在缺口
- 利益相关方意图不明或缺少跨职能需求
- 有以假设“填补”缺口的倾向
- 开始任何重要功能实现之前
主要能力
该工作流编排以下原子技能：
- pre-task-checkpoint：引出前的问题框定与分析
- clarifying-questions：对歧义的响应式澄清
- specification-elicitation：主动的5级问题框架
- stakeholder-analysis：多视角分析（8类利益相关方）
- information-completeness：9维信息收集
- conceptual-analysis：理解字面陈述背后的真实意图
- framing-skepticism：挑战内嵌假设
- deliverable-completeness：6维规格验证
- documentation-quality：确保规格增加价值
- evidence-reasoning：基于证据的验证
渐进深度路径
该工作流支持三种深度级别，取决于复杂度和风险：
快速路径（简单功能、低风险）
入口 → 阶段1 → 阶段2（L1-L2）→ 阶段3（快速利益相关方检查）→ 阶段4（维度1-3）→ 阶段5（退出）
适用条件：单利益相关方功能（如内部工具）、领域理解充分、运营复杂度低、跨系统集成极少。时间：30-60分钟。
标准路径（多数功能）
入口 → 阶段1 → 阶段2（L1-L4）→ 阶段3（核心利益相关方）→ 阶段4（全部6个维度）→ 阶段5（质量检查）→ 阶段6（退出）
适用条件：多利益相关方影响、中等复杂度、存在一些集成关注点、标准运营需求。时间：2-4小时。
全面路径（复杂/高风险）
入口 → 阶段1 → 阶段2（L1-L5）→ 阶段3（全部8类利益相关方）→ 阶段4（全部6个维度）→ 阶段4.5（信息完整性9维）→ 阶段5（质量门禁）→ 阶段6（证据验证）→ 阶段7（退出）
适用条件：任务关键型功能、高运营风险、复杂多系统集成、监管/合规要求、新颖或实验性功能。时间：1-2天。
使用方式
阶段1：入口点与问题框定
调用 pre-task-checkpoint，建立基础：
- 检查点1：问题框定——该功能解决什么问题？请求是否是伪装成需求的解决方案？底层需求能否以不同方式满足？利益相关方试图达成什么业务成果？
- 检查点2：熟悉度检查——之前是否实现过类似功能？熟悉领域意味着更高的假设驱动缺口风险。
- 检查点3：框架选择——复杂度级别？选择深度路径。需要哪些原子技能？
- 检查点4：初始范围评估——新功能、增强还是系统？明确陈述与隐含假设分别是什么？可能受影响的利益相关方是谁？
- 检查点5：资源分配——最简引出方法是什么？收集的是实际需求还是假设需求？存在哪些现有文档？
调用 framing-skepticism，挑战任务框架：利益相关方如何框定请求？是作为解决方案还是问题？区分观察与解释，质疑内嵌约束。
退出标准：问题框定建立、深度路径选定、假设浮现。
阶段2：问题驱动引出
调用 specification-elicitation，系统应用5级问题框架：
- 第1级：表面澄清（所有路径）——明确输入/输出、文件类型/格式/大小、基本验收标准、成功标准、核心用户操作。
- 第2级：边缘情况探索（快速及以上路径）——操作失败怎么办？输入无效/恶意怎么办？外部依赖不可用怎么办？速率限制/配额？超时/取消？首次/最后/唯一情况？边缘情况发现框架：已完成？并发？中途失败？数量很多？
- 第3级：约束发现（标准及以上路径）——性能要求（延迟p50/p95/p99、吞吐量、并发用户）、数据要求（量、增长、保留）、可用性要求（SLA、停机窗口、RPO/RTO）、安全要求（数据敏感性、合规、加密）。
- 第4级：横切关注点（标准及以上路径）——认证与授权、错误处理、监控与调试、审计与合规。
- 第5级：利益相关方视角转换（全面路径）——从运维、安全、支持、QA、分析、开发者等视角提出角色特定需求。
问题表述最佳实践：提供多个选项、提供上下文、呈现权衡、询问缺失项、探究后果。
调用 clarifying-questions，对任何含糊回答立即澄清：目标/上下文、范围、成功标准、约束、深度。使假设明确化。
退出标准：所有相关问题级别完成、利益相关方回答记录、假设验证。
阶段3：多利益相关方分析
调用 stakeholder-analysis，从所有受影响利益相关方视角分析需求：
- 快速路径：产品负责人/业务、最终用户、开发者（实现者）
- 标准路径：增加QA/测试、运维/SRE、安全（如适用）
- 全面路径：增加支持/客户成功、数据/分析
对每个利益相关方：识别关注点、提取需求、识别冲突、明确解决冲突。
调用 conceptual-analysis，确保理解实际目的而非仅字面需求。
退出标准：所有相关利益相关方分析完成、冲突识别并解决、从每个视角捕获需求。
阶段4：系统化完整性验证
调用 deliverable-completeness，在六个维度上验证规格：
- 维度1：功能完整性（所有路径）——所有状态、转换和结果覆盖。
- 维度2：数据完整性（所有路径）——所有数据需求明确。
- 维度3：错误与边缘情况完整性（所有路径）——所有失败模式和边界处理。
- 维度4：非功能完整性（标准及以上路径）——性能、安全、可靠性、可操作性。
- 维度5：集成完整性（标准及以上路径）——与其他系统的所有交互明确。
- 维度6：文档完整性——规格增加价值。
限制
资料中未提供关于该工作流的具体工具依赖、平台限制、收费模式或价格信息。该工作流为方法论框架，实际执行效果取决于使用者对原子技能的掌握程度和投入时间。全面路径需要1-2天，可能不适用于时间紧迫的场景。