mcpField
R
requirements-specification

requirements-specification

github.com/nicepkg开发28852 次安装40 周前更新
代码仓库

关于 requirements-specification

requirements-specification 是帮助产品和工程团队把客户洞察整理为可执行规格的技能指南。内容涵盖用户故事、验收标准、需求文档结构及范围管理。

主要功能

  1. 01按 INVEST 原则编写用户故事
  2. 02用 BDD 格式定义验收标准
  3. 03组织需求文档结构
  4. 04区分 MVP 与后续范围
  5. 05检查需求清晰度与可测试性

适用场景

  1. 01把客户需求转化为工程任务
  2. 02为功能编写可验证的验收条件
  3. 03评估变更对项目范围的影响

安装

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

$npx skills add https://github.com/nicepkg/ai-workflow --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