软件需求分析生成器

立项时文档从哪来

很多团队在写 SRS（软件需求规格说明书） 时卡在「结构有了、内容填不满」：业务背景与目标用户混在一起，功能点只有口号没有输入输出，非功能需求写成「要快、要安全」，验收时双方对不上口径。需求评审前若缺少可验证的条目，后续设计与测试都会反复返工。

五阶段怎么跑

本技能通过 /srs 或 /需求分析 触发，按阶段采集并在每段结束后让你确认，再进入下一阶段：

• 阶段 1：项目基础信息（名称、类型、背景、痛点、目标用户、环境与约束）；项目名称与核心目标不可为空。
• 阶段 2：业务与用户需求，产出角色-权限-场景对照表与核心流程清单。
• 阶段 3：功能模块与功能点，每条按编号、名称、描述、前置/后置条件、异常处理六要素整理，并标 P0/P1/P2。
• 阶段 4：非功能与接口——性能、安全、可用性等要求量化表述；接口按名称、方式、入参、出参、异常码归档。
• 阶段 5：汇总生成完整 SRS，内置校验（SMART、术语一致、主流程与关键异常不遗漏）后输出 Markdown；可用 --mode=simple|standard|full 等调节粒度。

边界与注意点

可做：业务背景梳理、角色/流程拆解、模块划分、非功能量化、数据/接口梳理、验收标准与结构化文档。

不做：技术架构设计、编码方案、详细排期、高保真原型，也不能替代正式需求评审。你仍需组织评审与签字；本技能产出的是可讨论的规格草稿，而非已批准的基线。