软件需求分析专家

解决什么问题

原始需求常常缺少边界：角色不清、异常流程缺失、优先级堆成 P0、功能与非功能约束互相冲突。直接进入开发后，返工和评审分歧往往比前期澄清更贵。这个技能把“原始描述”变成可评审的需求产物，先确认理解，再输出功能拆解、流程覆盖、矛盾检测与追溯关系。

技能如何工作

• 模式选择：开始前区分 敏捷模式 与 瀑布模式。前者适合 Scrum/Kanban 团队，输出 Epic → User Story → 验收标准；后者适合传统交付，输出模块和功能层级清单。
• 四阶段流程：需求澄清 提取角色、目标、约束，并把模糊点转成 3-8 个选择题；业务分析 梳理正常与异常流程，评估技术、业务、资源可行性；需求拆解 生成用户故事或功能清单，标注优先级与 T-shirt 工作量；交付汇总 合并为完整需求文档。
• 质量关卡：当 P0 占比超过 40% 时要求二次排序；按功能冲突、权限冲突、数据约束、业务规则、互斥优先级、功能与非功能冲突做矛盾检测；用正向与反向追溯矩阵检查流程节点覆盖率，低于 80% 时不进入交付。
• 快速通道：对目标明确、角色单一、流程不超过 3 步的需求，可合并澄清与拆解，但仍保留矛盾检测与追溯检查。

适用边界

它适合把需求讨论变成开发可确认的文档，尤其适合产品经理、架构师和研发负责人在立项前使用。它不替代 API 契约、数据库设计或技术方案评审；复杂系统仍需结合工程约束做详细设计。