（4383期）requirements-analysis – 从想法到文档，结构化需求分析

从想法到文档，结构化需求分析 专业需求分析师，通过结构化对话将模糊想法转化为完整需求文档，支持EPIC分解、多维度优先级排序及验收标准定义。 使用说明 核心用法 requirements-analysis 是一款面向软件工程与产品管理领域的专业需求分析技能。它采用系统化对话流程，引导用户从初始想法逐步构建完整的需求规格说明。 主要功能模块 对话式需求提取：通过预设的开放式问题链（5W1H框架），将"一句话需求"扩展为包含业务背景、用户场景、价值度量的完整描述。 分层需求分解：支持从 EPIC（业务计划）→ 需求（功能/能力）→ 用户故事的三级分解结构，采用 INVEST 原则编写用户故事。 多维度优先级排序：内置 5 种成熟方法—— - MoSCoW：快速四象限分类（必须有/应该有/可以有/不会有） - RICE：数据驱动评分（Reach×Impact×Confidence / Effort） - 价值-成本矩阵：可视化优先级决策 - Kano 模型：识别基本型/期望型/兴奋型需求 - 加权评分：自定义多维度评估 文档生成：输出结构化需求文档，包含功能性/非功能性需求、验收标准（Given-When-Then 格式）、利益相关者矩阵及依赖关系图。 显著优点 降低认知负荷：将复杂的需求工程方法论封装为可执行的对话流程，无需用户具备专业 BA 背景 可追溯性设计：强制建立 EPIC-需求-用户故事的层级关联，便于变更影响分析 多方法覆盖：根据场景灵活选择优先级策略，避免单一方法的局限性 标准化输出：内置完整模板体系，确保文档格式一致、要素齐全 潜在局限 依赖用户配合度：需要用户持续投入多轮对话，对于希望"一次性出结果"的场景体验不佳 行业适配性：模板偏向通用软件开发，特定领域（如硬件嵌入式、医疗合规系统）需额外定制 估算客观性：优先级排序中的 Effort、Confidence 等参数仍依赖主观判断，可能存在偏差 适合人群 产品经理：快速梳理 PRD 框架 敏捷教练：引导团队完成需求梳理（Backlog Refinement） 项目经理：识别利益相关者、制定交付计划 初创团队创始人：将模糊商业想法转化为可开发的需求规格 常规风险 范围蔓延风险：虽内置变更控制提醒，但对话式交互可能诱导过度细化 文档维护成本：生成的详细文档若未与实际开发同步更新，易造成"文档漂移" 验收标准歧义：Given-When-Then 格式对非技术用户存在学习门槛，可能产生表述不一致 原始说明 专业需求分析师，通过多轮对话将简短想法转化为详细需求文档。使用此技能当用户需要：(1) 分析和记录需求，(2) 将 EPIC 分解为需求和用户故事，(3) 对多个需求进行优先级排序，(4) 识别利益相关者和依赖关系，(5) 定义验收标准，(6) 创建需求文档。支持单个需求分析、EPIC 分解、MoSCoW/RIC...