pm-alpha-requirement-analysis

name	pm-alpha-requirement-analysis
description	需求分析四步法。通过用户故事地图还原场景、RICE模型评估优先级、评估技术可行性、执行合规性预审。适用于产品经理在需求评审前进行系统性分析，确保需求完整、可行、合规。当需要分析新需求、评估需求优先级或准备需求评审会议时使用此skill。

需求分析四步法

系统化分析需求，确保完整性、优先级合理、技术可行、合规无风险。

第一步：场景还原（用户故事地图）

用户角色定义

• 主角：谁在使用这个功能？（如：放射科医生、护士、系统管理员）
• 角色动机：他们为什么需要这个功能？
• 使用频率：日常使用还是偶尔使用？
• 技能水平：新手还是专家用户？

用户故事地图结构

┌─────────────────────────────────────────────────────────────┐
│  用户故事地图 - [功能名称]                                    │
├─────────────────────────────────────────────────────────────┤
│ Backbone (主干流程)                                          │
│ ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐  │
│ │  步骤1  │ →  │  步骤2  │ →  │  步骤3  │ →  │  步骤4  │  │
│ └─────────┘    └─────────┘    └─────────┘    └─────────┘  │
├─────────────────────────────────────────────────────────────┤
│  探索 Activities (横向扩展)                                    │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐         │
│  │ 异常处理 │ │ 权限控制│ │ 数据校验│ │ 消息通知│         │
│  └─────────┘ └─────────┘ └─────────┘ └─────────┘         │
├─────────────────────────────────────────────────────────────┤
│  观察 Watch Points (质量维度)                                 │
│  · 性能要求   · 兼容性   · 安全性   · 可用性                  │
└─────────────────────────────────────────────────────────────┘

场景还原检查清单

• 用户故事格式：作为 <角色>，我希望 <目标>，以便 <收益>
• 每个场景都有明确的开始和结束触发条件
• 识别出所有主要用户路径和备选路径
• 标注了关键的非功能需求（性能、安全等）

---

第二步：优先级评估（RICE模型）

RICE评分公式

RICE Score = (Reach × Impact × Confidence) / Effort

参数说明：
- Reach（触达量）：该需求影响的用户数/周期
- Impact（影响力）：对用户/业务的正面影响程度 (0.25/0.5/1/2/3)
- Confidence（置信度）：对估算的自信程度 (50%/80%/100%)
- Effort（工作量）：需要的人/周数

优先级判定标准

RICE Score	优先级	行动
> 100	P0	立即执行，本 Sprint 完成
50-100	P1	高优先级，下个 Sprint 排入
20-50	P2	中优先级，视资源情况安排
< 20	P3	低优先级，可延后或简化

RICE评估表

需求	Reach/周期	Impact	Confidence	Effort(人周)	RICE Score	优先级

---

第三步：技术可行性评估

技术可行性维度

1. 系统架构兼容性

• 与现有系统架构是否兼容？
• 是否需要改造核心模块？
• 是否有技术债务风险？

2. 数据层面

• 现有数据模型是否支持新需求？
• 是否需要数据迁移？
• 数据量级预估（当前/增长/峰值）

3. 集成复杂度

• 第三方系统集成难度
• API 接口是否完备？
• 是否有版本兼容问题？

4. 性能评估

• 响应时间要求能否满足？
• 并发处理能力是否足够？
• 是否需要缓存优化？

技术可行性评估表

评估项	结论	风险等级	建议
架构兼容性	✅ 可行 / ⚠️ 需改造 / ❌ 不可行	高/中/低
数据模型	✅ 可行 / ⚠️ 需改造 / ❌ 不可行	高/中/低
第三方集成	✅ 可行 / ⚠️ 需改造 / ❌ 不可行	高/中/低
性能指标	✅ 可行 / ⚠️ 需改造 / ❌ 不可行	高/中/低

---

第四步：合规性预审

医疗行业合规要点（PACS/RIS场景）

数据安全合规

• 是否符合 HIPAA 隐私保护要求？
• 患者数据脱敏处理方案是否完备？
• 数据访问日志是否完整记录？

医疗器械法规

• 功能变更是否需要重新认证？
• 是否符合 IEC 62304 软件生命周期标准？
• 变更管理流程是否规范？

DICOM标准合规

• DICOM Tag 使用是否规范？
• SOP Class 映射是否正确？
• C-FIND/C-MOVE/C-STORE 支持情况？

合规检查清单

检查项	适用法规	状态	备注
患者隐私保护	HIPAA	✅/⚠️/❌
数据加密传输	HIPAA, SSL	✅/⚠️/❌
操作审计日志	HIPAA	✅/⚠️/❌
DICOM标准符合	DICOM3.0	✅/⚠️/❌
软件变更管理	IEC 62304	✅/⚠️/❌

---

需求分析输出模板

需求概述

一句话描述：这个需求是什么，为谁服务，解决什么问题

详细分析

1. 场景还原

• 用户故事：作为...[角色]，我希望...[功能]，以便...[收益]
• 主要流程：[描述核心使用路径]
• 边界情况：[列出异常场景]

2. 优先级评估

• RICE Score：[分值]
• 优先级：[P0/P1/P2/P3]
• 评估依据：[说明理由]

3. 技术可行性

• 总体结论：[可行/需改造/不可行]
• 主要风险点：[列出关键技术风险]
• 建议：[给出技术实现建议]

4. 合规性

• 安全评估：[通过/有条件通过/不通过]
• 需要关注：[列出合规风险点]

评审材料清单

• 需求文档初稿
• 用户故事地图
• RICE评估表
• 技术可行性报告
• 合规性检查表