需求与规范技能：用户故事撰写、验收标准定义、需求文档结构完整指南

requirements-specification by pluginagentmarketplace/custom-plugin-product-manager

148 周安装量

2 GitHub Stars

安装命令

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

软件工程业务分析产品管理

🇨🇳中文介绍

需求与规范技能

将客户洞察转化为清晰、详细的规范，供工程团队据此构建。掌握用户故事撰写，定义验收标准，并严格管理范围。

用户故事撰写（INVEST 格式）

INVEST 原则

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

用户故事模板

As a [用户角色]
I want [操作/能力]
So that [收益/结果]

Acceptance Criteria:
Given [上下文]
When [用户操作]
Then [预期结果]

好与坏的示例

坏的故事：

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

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

验收标准（BDD 格式）

Scenario: [具体的用户操作]
Given [初始上下文/状态]
When [用户执行操作]
Then [预期结果]
And [附加验证]

示例：密码重置功能

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 和标题
As a... I want... so that...
验收标准（3-8 个场景）
故事点估算
依赖关系
设计参考（线框图/原型）
注释/澄清

用例与流程（10-20 页）

Use Case: [用例名称]
Primary Actor: [用户角色]
Precondition: [操作前状态]

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 页）

实体（User, Post, Comment）
关系（User creates Posts）
属性（Post title, content, creation_date）
主键、外键

UI/线框图（附件）

用户界面原型
用户流程和导航
关键交互

MoSCoW 方法：

必须有（不可协商）

核心功能
没有这些：产品无法工作
必须随这些功能发布
示例：用户登录、基本内容查看

应该有（重要但不关键）

增强用户体验
增值功能
如果时间允许
示例：高级搜索、保存偏好设置

可以有（锦上添花）

润色功能
低优先级
如果有额外时间/预算再做
示例：深色模式、动画

不会有（明确排除在范围外）

为未来明确规划
有助于对利益相关者说"不"
计划在后续版本中实现
示例：移动应用（先发布网页版）

"我们能再加一个...吗？"
"如果...会更好"
"要不要也包含..."
"还有一件事..."

"这是个好主意。我们把它加到 Q2 的路线图中。"
"这会增加 3 周时间。您打算推迟哪个优先级？"
"这超出了当前范围。请记录下来供下一阶段考虑。"

变更请求流程：

记录变更
评估影响（时间、复杂性）
呈现权衡取舍
获取利益相关者决策
更新需求文档
与团队沟通

❌ "提高性能" ✅ "将页面加载时间从 4 秒减少到 2 秒以下"

❌ "构建仪表板" ✅ "构建一个显示过去 24 小时活跃用户且准确率达到 95% 的仪表板"

❌ "修复这个 bug" ✅ "当使用特殊字符搜索时，结果显示错误。修复以处理特殊字符。"

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

模糊的验收标准

❌ "系统应该快速" ✅ "API 响应时间在第 95 百分位 < 200ms"

✓ 每个需求都是可测试的
✓ 没有需求指定实现方式
✓ 依赖关系已识别并记录
✓ 验收标准清晰完整
✓ 工程团队已估算工作量
✓ 提供了设计原型
✓ 数据模型已记录
✓ 考虑了边界情况
✓ 范围明确定义（MVP 与未来）
✓ 已识别成功指标
✓ 时间线现实可行
✓ 已由工程主管审查
✓ 已由设计主管审查
✓ 利益相关者已达成一致

常见错误与解决方案

错误	可能原因	解决方案
故事太大	写成了史诗	故事分解
验收标准模糊	标准模糊	采用 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ı?

模糊的需求 → 澄清会议
范围蔓延 → 权衡矩阵
缺少可行性 → 工程探索

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

🇺🇸English

Requirements & Specification Skill

Transform customer insights into clear, detailed specifications that engineering can build from. Master user story writing, define acceptance criteria, and manage scope ruthlessly.

User Story Writing (INVEST Format)

INVEST Principles

I - Independent (minimal dependencies) N - Negotiable (details can be discussed) V - Valuable (delivers customer value) E - Estimable (team can estimate effort) S - Small (can complete in 1-2 sprints) T - Testable (clear success criteria)

User Story Template

As a [user role]
I want [action/capability]
So that [benefit/outcome]

Acceptance Criteria:
Given [context]
When [user action]
Then [expected result]

Good vs Bad Examples

Bad Story:

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

Problem: Too vague, not testable, too large

Good Story:

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

Acceptance Criteria (BDD Format)

Scenario Template

Scenario: [Specific user action]
Given [initial context/state]
When [user performs action]
Then [expected result]
And [additional verification]

Example: Password Reset Feature

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

Requirements Document Structure

Executive Summary (1 page)

Overview of feature/product
Business goal/context
Key benefits
Timeline
Success metrics

Requirements Overview (5-10 pages)

Functional Requirements

What the system must do
Features and capabilities
User interactions
Data handling

Non-Functional Requirements

Performance (response time < 2s)
Scalability (support 10K concurrent users)
Security (encrypt PII)
Availability (99.9% uptime)
Accessibility (WCAG AA compliance)

Business Requirements

Why we're building this
Business metrics
Customer need
Competitive advantage

Constraints

Technical constraints
Budget constraints
Timeline constraints
Resource constraints

User Stories & Epics (20-50 pages)

Structure:

Epic: Large initiative grouping related stories
User Stories: Individual features (10-20 stories per epic)
Tasks: Engineering breakdown (if needed)

Each Story Includes:

Story ID and title
As a... I want... so that...
Acceptance criteria (3-8 scenarios)
Story points estimate
Dependencies
Design reference (wireframe/mockup)
Note/clarifications

Use Cases & Flows (10-20 pages)

Use Case Template:

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

Data Models (10 pages)

Entity Relationship Diagram

Entities (User, Post, Comment)
Relationships (User creates Posts)
Attributes (Post title, content, creation_date)
Primary keys, foreign keys

UI/Wireframes (Attached)

User interface mockups
User flows and navigation
Key interactions

Scope Management

MVP vs Nice-to-Have

MoSCoW Method:

MUST Have (Non-negotiable)

Core functionality
Without these: product won't work
Must launch with these
Example: User login, basic content view

SHOULD Have (Important but not critical)

Enhance user experience
Value add
If time allows
Example: Advanced search, saved preferences

COULD Have (Nice-to-have)

Polish features
Low priority
Do if extra time/budget
Example: Dark mode, animations

WON'T Have (Explicitly out of scope)

Clear for future
Helps say "no" to stakeholders
Plan for later version
Example: Mobile app (launching web first)

Scope Creep Prevention

Red Flags:

"Can we just add...?"
"This would be better if..."
"What about also including..."
"One more thing..."

Responses:

"That's a great idea. Let's add it to the roadmap for Q2."
"That would add 3 weeks. What would you deprioritize?"
"That's outside current scope. Document for next phase."

Change Management

Change Request Process:

Document the change
Assess impact (time, complexity)
Present trade-offs
Get stakeholder decision
Update requirements document
Communicate to team

Common Pitfalls

Too Vague

❌ "Improve performance" ✅ "Reduce page load time from 4s to under 2s"

No Success Criteria

❌ "Build dashboard" ✅ "Build dashboard showing active users in last 24h with 95% accuracy"

Missing Context

❌ "Fix the bug" ✅ "When searching with special characters, results show error. Fix to handle special chars."

Over-Specifying

❌ "Use Redux with saga middleware for state management" ✅ "State changes must be traceable and debuggable"

Ambiguous Acceptance Criteria

❌ "System should be fast" ✅ "API response time < 200ms for 95th percentile"

Requirements Review Checklist

✓ Each requirement is testable
✓ No requirement specifies implementation
✓ Dependencies identified and documented
✓ Acceptance criteria clear and complete
✓ Engineering has estimated effort
✓ Design mockups provided
✓ Data models documented
✓ Edge cases considered
✓ Scope clearly defined (MVP vs future)
✓ Success metrics identified
✓ Timeline realistic
✓ Reviewed by engineering lead
✓ Reviewed by design lead
✓ Stakeholder aligned

Troubleshooting

Yaygın Hatalar & Çözümler

Hata	Olası Sebep	Çözüm
Story çok büyük	Epic olarak yazıldı	Story breakdown
AC belirsiz	Vague criteria	Given/When/Then format
Scope creep	Change mgmt yok	Change request process
Missing edge cases	Happy path focus	Edge case workshop

Debug Checklist

[ ] 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ı?

Recovery Procedures

Ambiguous Requirements → Clarification meeting
Scope Creep → Trade-off matrix
Missing Feasibility → Engineering spike

Write clear requirements and avoid 90% of project problems!

Weekly Installs

128

Repository

pluginagentmark…-manager

GitHub Stars

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

cursor111

opencode109

codex105

gemini-cli105

github-copilot97

kimi-cli86

PRD到实施计划转换工具：使用垂直切片法将产品需求文档分解为分阶段开发计划

3,500 周安装