ailearneryang 软件需求文档生成 Skill
何时使用
- 输入是一份功能规范、产品草案、特性说明、功能清单、会议纪要，需要产出正式软件需求文档时
- 需要把模糊业务描述转换为可开发、可联调、可测试、可验收的软件需求时
- 需要补充工程化实现约束，但又要明确区分哪些是工程化补足、哪些是待确认项时
核心目标
把输入材料整理成一份可直接进入架构、开发、测试阶段的软件需求文档，要求：
- 结构完整
- 需求粒度足够细
- 每条需求可单独实现和单独验收
- 明确区分 原始需求、工程化补足、待确认
- 输出可被后续质量门禁直接检查
强制规则
- 先识别软件类型、运行环境、目标用户和外部依赖。
- 必须按用户场景拆功能，不按技术模块堆砌。
- 一个用户可感知动作或一个可独立验收结果，单独形成一条需求。
- 每条需求必须包含需求描述、验证准则、验证方式，且可直接转入设计或测试。
- 无法稳定推断的内容必须标记为 [待确认]，禁止编造参数。
- 仅对实现必需、测试必需、联调必需的信息使用 [工程化补足]。
- 文档应优先使用模板中的表格表达功能、数据、配置、非功能和约束要求。
- 不写实现方案、不写类设计、不写线程模型、不写接口报文字段级细节。
生成步骤
- 阅读输入材料，提取业务目标、范围、角色、触发条件、系统响应。
- 依据 需求方法论参考 做场景识别和工程化补足判断。
- 使用 需求文档模板 组织输出。
- 输出需求表时检查拆分粒度，避免把多个独立动作混写成一条。
- 输出完成后，自检：
- 每条需求是否可独立实现
- 验证准则是否可转测试用例或评审项
- 如存在共享资源、重复触发或异步回调，是否已补充并发冲突处理需求
- 是否存在未标记来源的主观假设
- 是否存在遗漏章节
- 交给质量门禁进行复核，未通过前不得作为最终输出物。
输出要求
默认输出文件名建议为 需求文档.md，内容应遵循模板章节顺序。 如果调用方要求输出到指定路径，应遵循调用方路径。
输出风格
- 中文
- 术语一致
- 以需求语言表述，不写实现代码
- 尽量使用表格表达需求、数据项、配置项、约束和追踪关系
- 待确认项集中汇总，并在正文中同步标记