fengqiliu 需求分析四步法
系统化分析需求，确保完整性、优先级合理、技术可行、合规无风险。
第一步：场景还原（用户故事地图）
用户角色定义
- 主角：谁在使用这个功能？（如：放射科医生、护士、系统管理员）
- 角色动机：他们为什么需要这个功能？
- 使用频率：日常使用还是偶尔使用？
- 技能水平：新手还是专家用户？
用户故事地图结构
┌─────────────────────────────────────────────────────────────┐
│ 用户故事地图 - [功能名称] │
├─────────────────────────────────────────────────────────────┤
│ 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评估表
- 技术可行性报告
- 合规性检查表