software-requirement-generation

name	software-requirement-generation
description	用于根据功能规范、功能说明、产品草案、原始需求输入生成软件需求文档。适用于需求拆解、表格化功能需求编写、验证准则整理、数据与配置约束梳理、待确认项整理。
argument-hint	输入功能规范、产品草案或原始需求，生成结构化软件需求文档
user-invocable	true

软件需求文档生成 Skill

何时使用

• 输入是一份功能规范、产品草案、特性说明、功能清单、会议纪要，需要产出正式软件需求文档时
• 需要把模糊业务描述转换为可开发、可联调、可测试、可验收的软件需求时
• 需要补充工程化实现约束，但又要明确区分哪些是工程化补足、哪些是待确认项时

核心目标

把输入材料整理成一份可直接进入架构、开发、测试阶段的软件需求文档，要求：

• 结构完整
• 需求粒度足够细
• 每条需求可单独实现和单独验收
• 明确区分 原始需求、工程化补足、待确认
• 输出可被后续质量门禁直接检查

强制规则

1. 先识别软件类型、运行环境、目标用户和外部依赖。
2. 必须按用户场景拆功能，不按技术模块堆砌。
3. 一个用户可感知动作或一个可独立验收结果，单独形成一条需求。
4. 每条需求必须包含需求描述、验证准则、验证方式，且可直接转入设计或测试。
5. 无法稳定推断的内容必须标记为 [待确认]，禁止编造参数。
6. 仅对实现必需、测试必需、联调必需的信息使用 [工程化补足]。
7. 文档应优先使用模板中的表格表达功能、数据、配置、非功能和约束要求。
8. 不写实现方案、不写类设计、不写线程模型、不写接口报文字段级细节。

生成步骤

1. 阅读输入材料，提取业务目标、范围、角色、触发条件、系统响应。
2. 依据 需求方法论参考 做场景识别和工程化补足判断。
3. 使用 需求文档模板 组织输出。
4. 输出需求表时检查拆分粒度，避免把多个独立动作混写成一条。
5. 输出完成后，自检：
   • 每条需求是否可独立实现
   • 验证准则是否可转测试用例或评审项
   • 如存在共享资源、重复触发或异步回调，是否已补充并发冲突处理需求
   • 是否存在未标记来源的主观假设
   • 是否存在遗漏章节
6. 交给质量门禁进行复核，未通过前不得作为最终输出物。

输出要求

默认输出文件名建议为 需求文档.md，内容应遵循模板章节顺序。 如果调用方要求输出到指定路径，应遵循调用方路径。

输出风格

• 中文
• 术语一致
• 以需求语言表述，不写实现代码
• 尽量使用表格表达需求、数据项、配置项、约束和追踪关系
• 待确认项集中汇总，并在正文中同步标记