From vibeflow
Generates structured Software Requirements Specifications (SRS) aligned with ISO/IEC/IEEE 29148. Guides iterative questioning to elicit functional, non-functional, and constraint requirements.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vibeflow:vibeflow-requirementsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
将原始想法转化为结构化、高质量的软件需求规格说明书 (SRS),通过系统化的获取、质疑和验证流程 — 对齐 ISO/IEC/IEEE 29148 和 EARS 需求语法。
将原始想法转化为结构化、高质量的软件需求规格说明书 (SRS),通过系统化的获取、质疑和验证流程 — 对齐 ISO/IEC/IEEE 29148 和 EARS 需求语法。
在你展示 SRS 并获得用户批准之前,不得调用任何设计技能、实现技能、编写任何代码、搭建任何项目,也不得采取任何设计/实现行动。无论项目多简单,此规则适用于每个项目。每个项目都需要经过此流程。一个待办列表、一个单函数工具、一个配置变更 — 全部如此。"简单"项目恰恰是未经审查的假设造成最多浪费的地方。SRS 可以很短(真正简单的项目几句话即可),但你必须展示它并获得批准。
你必须按顺序完成以下步骤:
docs/changes/<change-id>/requirements.md 并提交vibeflow-design(含 UCD 内联,如需)终止状态是进入 vibeflow-design。 不要调用其他阶段。
python scripts/get-vibeflow-paths.py --json,读取 docs/changes/<change-id>/brief.md 获取问题定义和边界.vibeflow/workflow.yaml 了解所选模板的严格度级别python scripts/map-change-impact.py --project-root . --source requirements,读取:
docs/overview/CURRENT-STATE.mddocs/templates/srs-template.md.md 文件且至少包含一个 ## 标题使用 AskUserQuestion 以分轮多问题方式获取需求 — 每轮涵盖一个主题领域,最多 4 个相关问题。对每个领域遵循 捕获 -> 质疑 -> 澄清 循环。
提问方式:
AskUserQuestion 调用获取轮次(根据项目上下文调整顺序和分组):
单次 AskUserQuestion 调用(最多 4 个问题):
对每个能力域,每轮问(最多 4 个问题):
相关能力共享工作流时合并到同一轮。大的能力域拆分到多轮。
按相关性分 1-2 轮批量探测 NFR:
| 类别(ISO 25010) | 探测 |
|---|---|
| 性能 | 响应时间目标?吞吐量?并发用户? |
| 可靠性 | 可用性目标?恢复时间?数据丢失容忍度? |
| 易用性 | 无障碍要求?可学习性标准? |
| 安全性 | 认证方式?授权模型?数据加密? |
| 可维护性 | 模块化约束?测试覆盖率目标? |
| 可移植性 | 平台限制?浏览器支持? |
| 可扩展性 | 当前负载?目标负载?增长时间线? |
跳过明显不相关的类别。规则:每个 NFR 必须有可度量的标准。"快" -> "在 1000 并发用户下 p95 响应时间 < 200ms"。
合并为一轮(最多 4 个问题):
必要时问一轮:
何时停止: 当你能描述每个功能能力、其验收标准、所有带可度量阈值的 NFR、所有约束和假设 — 无需猜测时,进入步骤 3。
将捕获的需求组织到以下类别:
| 类别 | ID 前缀 | 描述 |
|---|---|---|
| 功能 | FR-001 | 可观测的系统行为 |
| 非功能 | NFR-001 | 带可度量标准的质量属性 |
| 约束 | CON-001 | 限制解决方案空间的硬限制 |
| 假设 | ASM-001 | 假定为真的信念;记录失效风险 |
| 接口 | IFR-001 | 外部系统契约 |
| 排除 | EXC-001 | 明确不在范围内 |
对每个功能需求应用 EARS(Easy Approach to Requirements Syntax)模板:
| 模式 | 模板 | 适用场景 |
|---|---|---|
| 普遍性 | 系统应当 <动作>。 | 始终有效的行为 |
| 事件驱动 | 当 <触发条件> 时,系统应当 <动作>。 | 响应用户/系统事件 |
| 状态驱动 | 当处于 <状态> 时,系统应当 <动作>。 | 行为依赖模式/状态 |
| 异常行为 | 如果 <条件>,则系统应当 <动作>。 | 错误处理、容错 |
| 可选 | 当 <功能/配置> 启用时,系统应当 <动作>。 | 可配置/可选能力 |
对每个需求还需编写:
对于现有项目改动,必须把 CURRENT-STATE.md 中“当前变更关注点”的结果吸收到需求文档中,至少明确:
Current StateAffected AreasOut of Scope对照 8 项质量属性(IEEE 830 / ISO 29148)运行系统化质量检查:
对每个需求验证:
| # | 属性 | 检查 | 红线信号 |
|---|---|---|---|
| 1 | 正确 | 追溯到已确认的干系人需求? | 孤立需求(镀金) |
| 2 | 无歧义 | 两个读者会写出相同的测试用例? | 模糊词:"快"、"健壮"、"用户友好"、"直觉"、"灵活" |
| 3 | 完整 | 所有输入、输出、错误情况、边界已定义? | "包括但不限于..."、无界列表 |
| 4 | 一致 | 与其他需求无矛盾? | 时间冲突、格式冲突 |
| 5 | 有排序 | 有 MoSCoW 优先级? | 所有都是"高优先级" |
| 6 | 可验证 | 能写出通过/失败测试? | "系统应易于使用"(无指标) |
| 7 | 可修改 | 在且仅在一处表述? | 跨章节重复 |
| 8 | 可追溯 | 有唯一 ID + 来源链接? | 缺少 ID 或孤立 |
在展示前扫描完整 SRS 中的这些反模式并修复:
| 反模式 | 检测信号 | 修复 |
|---|---|---|
| 模糊形容词 | "快"、"大"、"可扩展"、"可靠" 无数字 | 用可度量标准量化 |
| 复合需求 | "和"/"或"连接两个不同能力 | 拆分为独立需求 |
| 设计泄露 | 实现词汇:"类"、"表"、"端点"、"算法" | 重写为可观测行为 |
| 无主体被动语态 | "数据应被验证" — 谁来验证? | 添加明确主体:"系统应..." |
| TBD / TBC | 未解决占位符 | 与用户解决或标记为开放问题 |
| 缺少否定 | 仅指定正面情况 | 添加错误/边界/安全情况 |
| 不可测 NFR | NFR 无可度量阈值 | 添加具体指标 + 度量方法 |
对非简单项目,逐节展示并获得审批:
逐节展示。等待用户反馈。整合变更后再进入下一节。
简单项目(< 5 个功能需求):合并所有章节为单次审批步骤。
将审批通过的 SRS 保存到 docs/changes/<change-id>/requirements.md。
读取步骤 1 中找到的模板:
Date、Status、Standard、Template 路径)SRS 文档保存并提交后:
vibeflow-design| 项目规模 | 功能需求数 | 深度 |
|---|---|---|
| 微型 | 1-5 | 单页 SRS,合并审批步骤 |
| 小型 | 5-15 | 标准 SRS,2-3 个审批章节 |
| 中型 | 15-50 | 完整 SRS 含所有章节,逐节审批 |
| 大型 | 50-200+ | 完整 SRS + 接口规格 + 领域模型 |
| 合理化借口 | 正确响应 |
|---|---|
| "太简单不需要 SRS" | 运行轻量 SRS(单次审批步骤) |
| "用户已经描述了他想要的" | 用户描述是原始输入;SRS 添加结构、完整性、可测试性 |
| "我可以在设计时弄清需求" | 需求定义 WHAT;在 HOW 中发现它们会导致返工 |
| "NFR 不适用于此项目" | 每个项目至少有隐含的性能/可靠性需求 — 使其显式 |
| "术语表是显而易见的" | 对谁显而易见?定义用户和开发者可能有不同理解的每个术语 |
| "我先从正常路径开始" | 错误情况、边界和否定场景必须现在捕获 |
调用者: vibeflow-router(requirements 阶段)
链接到: vibeflow-design(SRS 审批后)
产出: docs/changes/<change-id>/requirements.md
npx claudepluginhub ttttstc/vibeflow --plugin vibeflowElicits requirements through structured questioning and generates high-quality SRS documents aligned with ISO/IEC/IEEE 29148 when no prior specs exist.
Drafts or audits SRS with requirement IDs, functional requirements, acceptance criteria, constraints, NFR hooks, and traceability.
Orchestrates Problem-Based SRS methodology from business context through functional requirements with full traceability. Coordinates skills for business context, customer problems, software glance, customer needs, software vision, and functional requirements.