Requirements Analysis Skill

分析需求: $ARGUMENTS

技能概述

本技能帮助你完成软件需求分析，从业务目标出发，系统性地收集、分析和文档化需求，确保项目各方对需求达成共识。

使用场景

• 项目启动: 新项目开始时的需求分析
• 功能新增: 为现有系统添加新功能
• 需求变更: 分析和记录需求变更
• 需求审查: 审查和优化现有需求文档

工作流程

步骤 1: 理解业务背景

首先，了解和分析业务背景：

1. 收集基本信息

   • 项目/功能名称
   • 业务目标
   • 目标用户群体
   • 预期收益

2. 识别干系人

   • 谁是需求的提出者？
   • 谁会使用这个功能？
   • 谁会影响决策？
   • 谁会受到结果影响？

3. 分析现有系统（如适用）

   • 当前系统如何处理？
   • 存在什么问题？
   • 需要保留什么？

步骤 2: 收集需求

使用以下方法收集需求：

1. 干系人访谈

   • 准备访谈问题
   • 记录干系人反馈
   • 识别隐性需求

2. 用户故事编写

   • 识别用户角色
   • 编写用户故事
   • 定义验收标准

3. 功能需求识别

   • 列出所有功能需求
   • 按模块或优先级分组
   • 识别需求依赖关系

4. 非功能需求定义

   • 性能要求
   • 安全要求
   • 可用性要求
   • 可维护性要求
   • 兼容性要求

步骤 3: 创建需求文档

使用以下模板创建文档：

主要文档:

1. docs/requirements/requirements-spec.md - 需求规格说明书
2. docs/requirements/user-stories.md - 用户故事
3. docs/requirements/acceptance-criteria.md - 验收标准
4. docs/requirements/stakeholders.md - 干系人分析

步骤 4: 验证需求

使用需求检查清单验证：

• 清晰性: 需求描述清晰，无歧义
• 完整性: 覆盖所有必要的需求
• 一致性: 需求之间没有冲突
• 可测试性: 每个需求都可以验证
• 可追踪性: 需求可以追溯到业务目标
• 可行性: 技术和时间上可行
• 优先级: 所有需求都有优先级

步骤 5: 获取批准

• 与干系人审查需求
• 处理反馈意见
• 获得正式批准

输入要求

调用此技能时，请提供以下信息：

必需信息

• 业务目标或功能描述

可选信息

• 目标用户群体
• 预算约束
• 时间约束
• 技术约束
• 现有系统文档

输出文档

1. 需求规格说明书 (Requirements Specification)

位置: docs/requirements/requirements-spec.md

使用模板: templates/requirements-template.md

包含内容:

# 需求规格说明书: [项目名称]

## 1. 项目概览
- 项目名称
- 版本
- 日期
- 作者

## 2. 背景和上下文
- 业务问题
- 当前状态
- 期望状态

## 3. 干系人
- 主要干系人
- 次要干系人
- 用户角色定义

## 4. 功能需求
### FR-001: [需求名称]
- 描述
- 用户故事
- 验收标准
- 优先级
- 依赖

### FR-002: ...

## 5. 非功能需求
### 5.1 性能要求
- 响应时间
- 吞吐量
- 并发用户数

### 5.2 安全要求
- 认证要求
- 授权要求
- 数据加密

### 5.3 可用性要求
- 系统可用性
- 界面易用性

### 5.4 可维护性要求
- 代码规范
- 文档要求

### 5.5 兼容性要求
- 浏览器兼容
- 设备兼容
- 系统兼容

## 6. 约束条件
- 技术约束
- 预算约束
- 时间约束
- 法规约束

## 7. 成功标准
- 关键绩效指标 (KPIs)
- 业务指标
- 用户满意度指标

## 8. 风险和假设
- 已识别风险
- 缓解策略
- 假设条件

## 9. 附录
- 术语表
- 参考文档
- 历史记录

2. 用户故事 (User Stories)

位置: docs/requirements/user-stories.md

使用模板: templates/user-stories-template.md

格式:

## US-001: [用户故事标题]

**作为** [用户角色]
**我想要** [功能描述]
**以便于** [业务价值]

### 验收标准
- [ ] 标准 1: Given...When...Then...
- [ ] 标准 2: Given...When...Then...

### 优先级
P0 | P1 | P2 | P3

### 故事点
[估算值]

### 依赖
- 依赖的其他用户故事
- 技术依赖

### 备注
[其他说明]

3. 验收标准 (Acceptance Criteria)

位置: docs/requirements/acceptance-criteria.md

使用模板: templates/acceptance-criteria-template.md

4. 干系人分析 (Stakeholders)

位置: docs/requirements/stakeholders.md

使用模板: templates/stakeholders-template.md

质量门禁

在完成需求分析之前，必须通过以下检查：

• 干系人批准: 所有主要干系人已审查并批准需求
• 需求完整性: 所有功能和非功能需求已文档化
• 用户故事完整: 每个功能都有对应的用户故事
• 验收标准明确: 每个用户故事都有明确的验收标准
• 优先级确定: 所有需求都有优先级标识
• 可行性确认: 技术团队已确认可行性
• 约束识别: 所有关键约束已识别
• 风险评估: 主要风险已识别并制定缓解策略

下一步

需求分析完成后，进入下一阶段：

# 如果是全新项目
/architecture-design

# 如果是功能设计
/product-design

最佳实践

1. 用户中心: 始终从用户角度思考需求
2. INVEST 原则: 用户故事应独立、可协商、有价值、可估算、短小、可测试
3. 5 Why 方法: 深入挖掘需求的根本原因
4. 可视化: 使用图表和模型辅助理解
5. 迭代完善: 需求是演进的，持续优化
6. 追溯性: 确保需求可追溯到业务目标

常见问题

Q: 如何处理冲突的需求？

A:

1. 识别冲突的根本原因
2. 与相关干系人讨论
3. 评估业务影响
4. 寻找折中方案
5. 必要时升级决策

Q: 需求变更如何处理？

A:

1. 记录变更请求
2. 评估影响（范围、时间、成本）
3. 与干系人讨论
4. 更新需求文档
5. 通知相关团队

Q: 如何判断需求是否完整？

A: 使用以下检查清单:

• WHO: 谁需要？
• WHAT: 需要什么？
• WHY: 为什么需要？
• HOW: 如何实现（高层级）？
• WHEN: 什么时候需要？
• VALUE: 业务价值是什么？

示例

输入:

/requirements-analysis "创建一个用户认证系统，支持邮箱和手机号登录"

输出:

1. 需求规格说明书 (docs/requirements/requirements-spec.md)
2. 用户故事 (docs/requirements/user-stories.md)
3. 验收标准 (docs/requirements/acceptance-criteria.md)
4. 干系人分析 (docs/requirements/stakeholders.md)

注意事项

1. 避免过度设计: 只记录必要的需求细节
2. 保持灵活性: 需求可能会变化，文档要易于更新
3. 沟通优先: 文档是沟通的工具，不是目的
4. 持续验证: 定期与干系人确认理解正确
5. 版本控制: 需求文档应该版本化