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
包含内容:
# 需求规格说明书: [项目名称]
## 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
最佳实践
- 用户中心: 始终从用户角度思考需求
- INVEST 原则: 用户故事应独立、可协商、有价值、可估算、短小、可测试
- 5 Why 方法: 深入挖掘需求的根本原因
- 可视化: 使用图表和模型辅助理解
- 迭代完善: 需求是演进的，持续优化
- 追溯性: 确保需求可追溯到业务目标
常见问题
Q: 如何处理冲突的需求？
A:
- 识别冲突的根本原因
- 与相关干系人讨论
- 评估业务影响
- 寻找折中方案
- 必要时升级决策
Q: 需求变更如何处理？
A:
- 记录变更请求
- 评估影响（范围、时间、成本）
- 与干系人讨论
- 更新需求文档
- 通知相关团队
Q: 如何判断需求是否完整？
A: 使用以下检查清单:
- WHO: 谁需要？
- WHAT: 需要什么？
- WHY: 为什么需要？
- HOW: 如何实现（高层级）？
- WHEN: 什么时候需要？
- VALUE: 业务价值是什么？
示例
输入:
/requirements-analysis "创建一个用户认证系统，支持邮箱和手机号登录"
输出:
- 需求规格说明书 (
docs/requirements/requirements-spec.md) - 用户故事 (
docs/requirements/user-stories.md) - 验收标准 (
docs/requirements/acceptance-criteria.md) - 干系人分析 (
docs/requirements/stakeholders.md)
注意事项
- 避免过度设计: 只记录必要的需求细节
- 保持灵活性: 需求可能会变化，文档要易于更新
- 沟通优先: 文档是沟通的工具，不是目的
- 持续验证: 定期与干系人确认理解正确
- 版本控制: 需求文档应该版本化