mcpField
R
requirements-specification

requirements-specification

github.com/pluginagentmarketplace开发3236 次安装43 周前更新
代码仓库

关于 requirements-specification

Requirements & Specification Skill 帮助产品与工程团队将客户需求转化为可实施的规格。内容涵盖 INVEST 用户故事、可测试的 BDD 验收标准、文档结构和范围管理。

主要功能

  1. 01基于 INVEST 编写用户故事
  2. 02BDD 验收标准
  3. 03需求文档结构
  4. 04MoSCoW 范围优先级
  5. 05变更与评审清单

适用场景

  1. 01将客户洞察转为用户故事
  2. 02定义可测试的功能验收标准
  3. 03确定 MVP 范围及变更优先级

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/pluginagentmarketplace/custom-plugin-product-manager --skill requirements-specification

安装后在 Claude Code 中输入/requirements-specification确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
config.yaml
references/
GUIDE.md
scripts/
helper.py

详细介绍

需求与规格说明技能

将客户洞察转化为清晰、详细且可供工程团队实现的规格说明。掌握用户故事编写、定义验收标准，并严格管理范围。

用户故事编写（INVEST 格式）

INVEST 原则

I - 独立（依赖最少） N - 可协商（细节可讨论） V - 有价值（为客户创造价值） E - 可估算（团队可估算工作量） S - 小型（可在 1–2 个冲刺周期内完成） T - 可测试（成功标准明确）

用户故事模板
As a [user role]
I want [action/capability]
So that [benefit/outcome]

Acceptance Criteria:
Given [context]
When [user action]
Then [expected result]
好例子与坏例子

坏例子：

As a user
I want a better dashboard
So that I can see my data

问题：过于含糊、不可测试、范围太大

好例子：

As a project manager
I want to see all tasks assigned to me in the last 24 hours
So that I can track what happened while I was offline

Acceptance Criteria:
Given I'm logged in
When I view the Home dashboard
Then I see a "Recent Tasks" section
And it shows tasks assigned to me from last 24 hours
And tasks are sorted by assignment time (newest first)
And clicking a task opens the task detail page

验收标准（BDD 格式）

场景模板
Scenario: [Specific user action]
Given [initial context/state]
When [user performs action]
Then [expected result]
And [additional verification]
示例：密码重置功能
Scenario: User resets password with valid email
Given I'm on the login page
And I'm not logged in
When I click "Forgot Password?"
And enter my email address
And click "Send Reset Email"
Then I see message "Check your email for reset link"
And a password reset email is sent to that address
And the email contains a valid reset link

Scenario: User uses expired reset link
Given I received a password reset email
And the reset link is more than 24 hours old
When I click the reset link
Then I see "Link has expired"
And I'm offered to request a new reset link

Scenario: Password doesn't meet requirements
Given I'm on password reset page
When I enter password "123"
Then I see error "Password must be 8+ characters"
And the form doesn't submit

需求文档结构

执行摘要（1 页）
  • 功能/产品概述
  • 业务目标/背景
  • 主要优势
  • 时间表
  • 成功指标
需求概述（5–10 页）

功能需求

  • 系统必须实现的功能
  • 功能与能力
  • 用户交互
  • 数据处理

非功能需求

  • 性能（响应时间 < 2s）
  • 可扩展性（支持 10K 并发用户）
  • 安全性（加密 PII）
  • 可用性（99.9% 正常运行时间）
  • 无障碍性（符合 WCAG AA）

业务需求

  • 构建此产品的原因
  • 业务指标
  • 客户需求
  • 竞争优势

约束

  • 技术约束
  • 预算约束
  • 时间约束
  • 资源约束
用户故事与史诗（20–50 页）

结构：

  • 史诗： 将相关故事归组的大型计划
  • 用户故事： 独立功能（每个史诗包含 10–20 个故事）
  • 任务： 工程实施拆分（如有需要）

每个故事包括：

  • 故事 ID 和标题
  • 作为……我想要……以便……
  • 验收标准（3–8 个场景）
  • 故事点估算
  • 依赖项
  • 设计参考（线框图/模型图）
  • 备注/说明
用例与流程（10–20 页）

用例模板：

Use Case: [Use Case Name]
Primary Actor: [User role]
Precondition: [State before action]

Main Flow:
1. User does X
2. System responds with Y
3. User does Z
4. System returns result

Alternative Flows:
3a. If data invalid
    - System shows error
    - User corrects and resubmits
数据模型（10 页）

实体关系图

  • 实体（用户、帖子、评论）
  • 关系（用户创建帖子）
  • 属性（帖子标题、内容、创建日期）
  • 主键、外键
UI/线框图（附件）
  • 用户界面模型图
  • 用户流程与导航
  • 关键交互

范围管理

MVP 与锦上添花的功能

MoSCoW 方法：

MUST Have（不可妥协）

  • 核心功能
  • 缺少这些功能：产品无法运行
  • 必须随产品一同发布
  • 示例：用户登录、基本内容查看

SHOULD Have（重要但非关键）

  • 改善用户体验
  • 增加价值
  • 时间允许时实现
  • 示例：高级搜索、保存的偏好设置

COULD Have（锦上添花）

  • 润色功能
  • 优先级低
  • 有额外时间/预算时实现
  • 示例：深色模式、动画

WON'T Have（明确不在范围内）

  • 明确留待将来实现
  • 有助于对利益相关者说“不”
  • 规划到后续版本
  • 示例：移动应用（先发布 Web 版）
防止范围蔓延

警示信号：

  • “能不能顺便加上……？”
  • “如果……会更好”
  • “还要不要包括……？”
  • “还有一件事……”

应对方式：

  • “这是个好主意。我们把它加入 Q2 的路线图吧。”
  • “这会增加 3 周时间。你想降低哪个事项的优先级？”
  • “这超出了当前范围。记录下来，留待下一阶段。”
变更管理

变更请求流程：

  1. 记录变更
  2. 评估影响（时间、复杂度）
  3. 展示权衡
  4. 获取利益相关者的决定
  5. 更新需求文档
  6. 告知团队

常见陷阱

过于含糊

❌ “提升性能” ✅ “将页面加载时间从 4s 缩短至 2s 以内”

缺少成功标准

❌ “构建仪表板” ✅ “构建显示过去 24h 活跃用户数且准确率达到 95% 的仪表板”

缺少上下文

❌ “修复这个漏洞” ✅ “使用特殊字符搜索时，结果会显示错误。修复处理逻辑，使其能正确处理特殊字符。”

过度指定

❌ “使用 Redux 和 saga 中间件进行状态管理” ✅ “状态变更必须可追踪且可调试”

验收标准含糊

❌ “系统应该很快” ✅ “API 响应时间：第 95 百分位小于 200ms”

需求评审清单

  • ✓ 每项需求都可测试
  • ✓ 没有需求指定实现方式
  • ✓ 已识别并记录依赖项
  • ✓ 验收标准清晰完整
  • ✓ 工程团队已估算工作量
  • ✓ 已提供设计模型
  • ✓ 已记录数据模型
  • ✓ 已考虑边缘情况
  • ✓ 已明确定义范围（MVP 与未来规划）
  • ✓ 已确定成功指标
  • ✓ 时间安排切实可行
  • ✓ 已由工程负责人评审
  • ✓ 已由设计负责人评审
  • ✓ 已与利益相关方达成一致

故障排除

常见错误与解决方案
错误可能原因解决方案
Story 太大被写成了 EpicStory 拆分
AC 含糊标准模糊Given/When/Then 格式
范围蔓延没有变更管理变更请求流程
缺少边缘情况只关注正常流程边缘情况研讨会
调试清单
[ ] Her story INVEST criteria geçiyor mu?
[ ] Acceptance criteria testable mı?
[ ] Non-functional requirements tanımlı mı?
[ ] Dependencies documented mı?
[ ] Engineering review yapıldı mı?
恢复流程
  1. 需求含糊 → 澄清会议
  2. 范围蔓延 → 权衡矩阵
  3. 缺少可行性评估 → 工程可行性探测

编写清晰的需求，避免 90% 的项目问题！

评论

支持 Markdown