Requirements Analysis Skill

分析需求: $ARGUMENTS

技能概述

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

使用场景

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

工作流程

步骤 1: 理解业务背景

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

•
收集基本信息
- •项目/功能名称
- •业务目标
- •目标用户群体
- •预期收益
•
识别干系人
- •谁是需求的提出者？
- •谁会使用这个功能？
- •谁会影响决策？
- •谁会受到结果影响？
•
分析现有系统（如适用）
- •当前系统如何处理？
- •存在什么问题？
- •需要保留什么？

步骤 2: 收集需求

使用以下方法收集需求：

•
干系人访谈
- •准备访谈问题
- •记录干系人反馈
- •识别隐性需求
•
用户故事编写
- •识别用户角色
- •编写用户故事
- •定义验收标准
•
功能需求识别
- •列出所有功能需求
- •按模块或优先级分组
- •识别需求依赖关系
•
非功能需求定义
- •性能要求
- •安全要求
- •可用性要求
- •可维护性要求
- •兼容性要求

步骤 3: 创建需求文档

使用以下模板创建文档：

主要文档:

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

步骤 4: 验证需求

使用需求检查清单验证：

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

步骤 5: 获取批准

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

输入要求

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

必需信息

•业务目标或功能描述

可选信息

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

输出文档

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

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

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

包含内容:

markdown

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

## 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

格式:

markdown

## 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

质量门禁

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

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

下一步

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

bash

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

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

最佳实践

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

常见问题

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

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

Q: 需求变更如何处理？

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

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

A: 使用以下检查清单:

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

示例

输入:

bash

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

输出:

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

注意事项

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