需求分析师Skill：用结构化对话把模糊想法变成可测试的 SRS 与用户故事
- 它是什么：需求分析师Skill（英文名 requirements-analyst，技能ID 13461）是一个面向需求分析场景的 Copilot 代理，专门负责需求定义、用户故事创建、规格说明与接受标准定义。
- 它怎么工作：通过「一次只问一个问题」的结构化访谈收集信息，再按模板生成 SRS、功能需求书、非功能需求书、用户故事与可追溯性矩阵。
- 它的硬性规范：接受标准统一采用 EARS 格式，需求强制分配可追溯 ID，并在交付前通过完整性、一致性、可行性、可测试性四类检查。
- 它的协作能力：会读取
steering/目录下的项目内存文件（structure.md、tech.md、product.md），并在完成后回写 product.md，让后续架构、API、测试等代理共享同一份上下文。 - 它的交付形态：每个文档同时产出英文版（
.md）与日文版（.ja.md），一次完整流程通常落盘 10 个文件。
一、该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 需求分析师Skill |
| 技能英文名 | requirements-analyst |
| 技能ID | 13461 |
| 技能类型 | Copilot 代理（需求分析专业角色） |
| 可用工具权限 | 读取、写入、编辑、Bash |
它解决什么问题
软件开发中最贵的返工，往往不是写错代码，而是「需求没写清楚」。常见的四个痛点正好对应它的四个能力：需求散落在聊天记录和会议纪要里难以沉淀；功能描述停留在「要快、要好用」这类不可验证的表述；接受标准缺失导致测试无法判定通过与否；需求与设计、测试之间没有追溯链路，改一处不知影响几处。需求分析师Skill 就是把这条链路的第一步标准化、模板化、可复用化。
一键安装的思路与步骤
「一键安装」的本质，是把一个预置好的专业角色（含角色定义、访谈脚本、文档模板、检查清单、输出规范）挂载到你的 AI 编程/协作环境中，之后用一句触发词就能调用，不必每次手写长提示词。
- 准备前提：需要一个支持技能（Skill）/ 代理（Agent）机制并允许挂载技能的环境；由于本技能需要读取项目文件并写入需求文档，安装后需确认其拥有「读取、写入、编辑、Bash」四类工具权限。
- 找到安装入口：在技能市场或技能库中按英文名
requirements-analyst或技能ID13461检索并安装（具体入口、命令与安装路径以官方说明为准）。 - 确认项目上下文（推荐）：在项目根目录准备
steering/目录及structure.md、tech.md、product.md三个文件。技能说明中明确：这三个文件存在时必须先读取，是「项目的记忆」；不存在则跳过，也可后续用@steering引导生成。 - 验证是否生效：新建会话，输入包含触发术语的请求，例如「帮我做一份用户注册功能的需求分析，接受标准用 EARS 格式」。若技能已生效，它会以需求分析师角色开场，并严格按「一次只问一个问题」的方式开始访谈；若没有进入该角色，通常是技能未启用或触发词不明确。
适合在什么阶段接入：项目立项、需求评审前、外包交接前、遗留系统改造补文档时，都是它的高效区间。
二、该技能的主要功能和特点
- 六阶段结构化访谈：初次访谈（项目名称、目的、目标用户、预计用户数、发布日期、系统集成）→ 功能需求访谈（按重要性列出 3~5 个主功能并逐个深挖使用者、操作、预期结果）→ 非功能需求访谈（性能、安全、可用性、可扩展性）→ 优先级排序 → 信息确认 → 成果物生成。
- 严格的「一问一答」纪律：每次只问一个问题并等待回答，禁止一次性抛出问题清单。这一点显著降低了需求方一次面对十几个问题时的敷衍与漏答。
- EARS 格式接受标准：支持 WHEN（事件驱动）、WHILE（状态驱动）、IF…THEN（错误处理）、WHERE、SHALL 等模式，把「系统要快」变成可判定的语句，并配套 Given-When-Then 便于 BDD 测试。
- 五类标准交付物：软件需求规格书（SRS）、功能需求书、非功能需求书、用户故事、可追溯性矩阵，全部按内置模板输出。
- 双语落盘与分阶段生成：先英文版再日文版，逐个文件生成并报告进度（如「[1/10] 已保存」），单个文档超过 300 行时自动拆分为多部分，避免一次性长输出失败导致成果丢失。
- 需求验证检查清单：覆盖完整性、一致性、可行性、可测试性、可追溯性，交付前逐项确认。
- 优先级方法论内置：MoSCoW（必须有 / 应该有 / 可以有 / 不会有）与 Kano 分析（基本品质 / 一元品质 / 魅力品质），把「都重要」变成有排序的需求池。
- 项目内存联动：任务前读取
steering/三份上下文，任务后将核心功能、用户故事、非功能需求回写到steering/product.md及其日文版，让多代理协作保持一致。 - 工作流引擎衔接：作为 Stage 1（需求）的执行者，可用
musubi-workflow next requirements进入本阶段、musubi-workflow next design流转到设计阶段，并用musubi-workflow feedback design requirements -r "解决需求模糊性"建立从设计或测试回到需求的反馈回路。
和普通做法比强在哪：通用 AI 对话也能写需求，但往往「一次给一坨」、缺少模板约束、没有追溯 ID、更不会维护项目共享上下文。这个技能把方法论（EARS、MoSCoW、Kano、可追溯性）固化在流程里，输出是可交接的工程文档，而不是聊天记录。
三、如何使用该技能？
步骤 1：明确触发方式
在会话中使用触发术语即可唤起，包括：需求、EARS格式、用户故事、功能需求、非功能需求、SRS、需求分析、规格、接受标准、需求验证。
输入示例：
帮我做「内部预约系统」的需求分析，功能需求用 EARS 格式定义接受标准，最后输出 SRS 和用户故事。
步骤 2：确认项目内存（可选但推荐）
技能启动后会提示参考 steering/structure.md、steering/tech.md、steering/product.md，以及 steering/rules/ears-format.md（EARS 格式指南）和 steering/templates/requirements.md（需求模板）。若已有这些文件，直接确认「继续」即可。
步骤 3：按访谈节奏逐题回答
技能会以 【问题 1/6】项目名称是什么？ 的形式提问，每题后等待你的回答。示例回答只需一句话：
电商网站
功能需求阶段建议按重要性顺序给出 3~5 个功能，例如：用户注册/登录、商品搜索、购物车与支付、评论、管理后台；随后它会针对每个功能追问「谁使用」「做什么操作」「预期结果是什么」。
步骤 4：确认信息汇总
访谈结束后，技能会输出项目概要、功能需求、非功能需求、优先级四块汇总，并询问是否有修正。此处是纠正偏差的最佳时机，例如补充「支付失败需要重试机制」。
步骤 5：批准生成成果物
确认后它会列出生成计划（通常 5 类文档 × 2 语言 = 10 个文件），然后逐个生成并报告进度。输出目录按规范组织：
./docs/requirements/srs/./docs/requirements/functional/./docs/requirements/non-functional/./docs/requirements/user-stories/./docs/requirements/traceability-matrix-{YYYYMMDD}.md
文件命名同样有约定，例如 srs-{project-name}-v{version}.md、functional-requirements-{feature-name}-{YYYYMMDD}.md。
步骤 6：核对检查清单与优先级
交付前逐项确认阶段完成条件：SRS 已创建、功能需求以 EARS 定义、非功能需求已定义、用户故事已创建、需求已分配可追溯性 ID、已获利益相关者批准。
步骤 7：衔接下一阶段
用 musubi-workflow next design 流转到设计阶段；若后续设计发现需求模糊，用 musubi-workflow feedback design requirements -r "解决需求模糊性" 回到需求环节修正。
注意事项：技能说明中的文档语言策略是「英文版 + 日文版均为强制」，因此中文项目若只需要中文文档，需要在访谈开始或生成前明确提出调整要求，具体支持情况以官方说明为准。
四、同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 需求分析师Skill（requirements-analyst） | 需求定义阶段的专用 AI 代理 | 六阶段访谈、EARS 接受标准、SRS/用户故事/非功能需求/可追溯矩阵、MoSCoW 与 Kano、项目内存读写、工作流衔接 | 需在支持技能机制的环境安装，授予读取/写入/编辑/Bash 权限；上手即用访谈引导 | 从 0 到 1 立项、外包交接、遗留系统补文档 | 优势：流程与方法论固化，输出可直接交接的工程文档；不足：交付文档默认英文+日文双语，需按项目调整；强依赖访谈质量 |
| 通用 AI 对话助手 | 通用问答与文本生成 | 自然语言写作、头脑风暴、文档草拟 | 门槛最低，无需安装 | 快速草拟、临时补充 | 优势：灵活、快；不足：缺少固定模板与追溯 ID，容易一次输出大段内容难以核对，不维护项目共享上下文 |
| 需求/缺陷管理平台（如 Jira、Azure DevOps 等，以官方说明为准） | 需求与任务的存储、跟踪系统 | 工作项管理、看板、迭代跟踪、报表 | 需要配置项目与权限，团队协作成本较高 | 需求已成型后的跟踪与执行 | 优势：状态流转与团队协同强；不足：不负责「从模糊想法生成结构化需求」，仍需人力撰写 SRS 与接受标准 |
| 传统文档模板（Word / Excel / 自建 Markdown 模板） | 人工撰写的文档载体 | 结构固定、可离线、易于审阅 | 门槛低但极耗人力 | 采购、合规等重文档场景 | 优势：格式可控；不足：无访谈引导、无一致性校验、无自动追溯，质量完全依赖个人经验 |
选型建议：需求尚未成型、需要把口头描述转成规范文档时优先用需求分析师Skill；需求已确定、需要跨团队跟踪执行时交给需求管理平台；两者可以串联——用本技能产出 SRS 与用户故事，再导入管理平台拆解任务。
五、该技能的典型应用场景与实际体验情况
场景 1：产品经理从 0 到 1 立项
角色：产品经理。痛点：脑子里有想法，但写 SRS 时总是漏掉非功能需求，评审时被架构师反复追问性能与安全指标。使用方式：以「电商网站」为项目名启动访谈，按 6 个基础问题回答，再逐条深挖 3~5 个主功能，最后在非功能阶段勾选「响应速度 2 秒以内」「多因素认证」「高可用 99.9% 以上」。体验：上手难度低，访谈节奏自然，最大价值是把「我没想到要写」的部分补上；注意在信息确认阶段认真核对，否则错误会顺着模板扩散到 10 个文件。
场景 2：外包或跨团队交接
角色：甲方技术负责人、外包团队。痛点：口头需求无法验收，争议时没有依据。使用方式：把功能需求的接受标准固定为 EARS 格式，产出可追溯性矩阵，把每条需求 ID 与实施、测试对应。体验：可追溯矩阵是争议场景下的关键交付物，EARS 语句让「通过/不通过」变成可判定事实；注意需求变更要走反馈流程而不是直接改文档，否则追溯链会断。
场景 3：遗留系统改造补文档
角色：接手老系统的开发负责人。痛点：代码在跑，文档为零，没人说得清非功能指标。使用方式：先在 steering/ 补齐 structure.md、tech.md、product.md，再让技能基于现有信息反向梳理功能与非功能需求。体验：项目内存机制让输出更贴合既有架构与命名约定，减少「凭空发明需求」；注意此时访谈答案多为推断，需标注待确认项。
场景 4：敏捷团队补全用户故事
角色：Scrum Master / 开发。痛点：用户故事只有一句「作为用户我要搜索商品」，没有接受标准，测试无从下手。使用方式：直接说「帮我把商品搜索整理成用户故事，接受标准用 EARS 格式」，输出「作为…我想要…以便…」加 WHEN/WHILE/IF…THEN 三类接受标准，并附 Given-When-Then。体验：单个故事的补全成本很低，配合故事点估算可直接进迭代；注意故事粒度需自己把控，过大时应拆分后再交给技能。
六、该技能能为用户带来的价值
效率层面：把原本分散在多次会议、反复追问和文档排版中的工作，收敛为一次结构化对话 + 一次批量生成。一次完整流程通常产出 5 类文档、约 10 个文件（含双语版本），并且是分阶段落盘、进度可见，中断也不至于全部重来。
质量层面：EARS 格式消除了「易用」「快速」这类不可验证表述；检查清单从完整性、一致性、可行性、可测试性、可追溯性五个维度做交付闸门；MoSCoW 与 Kano 让优先级从主观争论变成分类判断。
门槛层面：不需要熟记 SRS 章节结构、不需要背 EARS 语法、不需要自己搭追溯矩阵模板，新人也能产出格式合规的需求文档，把「方法论学习成本」转嫁给技能。
长期价值：steering/product.md 的持续回写让项目积累可复用的组织记忆，后续架构、API、数据库、测试等角色都基于同一份上下文工作，减少每个会话重复解释项目的开销；需求阶段与设计、测试之间的反馈回路，也让变更管理有了明确入口。
七、常见问题 FAQ
Q1：这个技能怎么安装？
在支持技能/代理机制的环境中按英文名 requirements-analyst 或技能ID 13461 检索安装，确认已授予读取、写入、编辑、Bash 权限，然后用「需求分析」「EARS 格式」等触发词验证是否进入需求分析师角色。具体安装入口与命令以官方说明为准。
Q2：收费吗？ 技能本身的价格、是否随所在平台订阅提供、调用是否消耗额度，均取决于发布方与承载平台的政策，请以官方说明为准。本文不对价格作任何承诺。
Q3：中文项目适合用吗？会不会只输出英文和日文？ 技能说明中的文档语言策略是英文版与日文版双重强制，因此在中文项目中使用时，建议在访谈开始就明确说明「文档用中文输出」，或在生成前调整语言要求。是否支持自定义语言以官方说明为准，切勿默认它会自动输出中文文档。
Q4：它和 Jira 这类需求管理平台是替代关系吗？ 不是。需求分析师Skill 负责「把模糊想法变成规范需求文档」，偏生成与定义；需求管理平台负责「把已确定的需求跟踪到交付」，偏存储与流转。推荐串联使用：先产出 SRS、用户故事与可追溯性矩阵，再导入平台拆解任务与验收。
Q5：生成的需求文档能直接用吗？质量如何保证？ 文档结构、格式与追溯 ID 由技能保证，但内容准确性取决于访谈回答的完整度。建议做三件事：一是在信息确认阶段逐项核对项目概要与优先级；二是交付前跑一遍完整性、一致性、可行性、可测试性检查清单；三是组织利益相关者正式批准——技能说明中也把「获得利益相关者批准」列为阶段完成条件之一。