常见软件需求风险

• 需求模糊性风险

• 需求变更风险

• 需求冲突风险

• 技术可行性风险

需求模糊性风险

• 定义：需求描述缺乏技术细节和量化指标

• 典型场景：
• 产品需求：实现图片的高效缓存
• 问题分析：未明确以下要素
• 缓存层级设计（内存+磁盘双缓存机制）
• 缓存淘汰策略（LRU/LFU的选择）
• 图片格式支持范围（是否包含WebP动图、HEIC格式）

• 后果评估：后期新增格式支持需重构缓存模块，造成开发返工，开发周期增加3-5人日

需求变更风险

• 典型场景：支付模块需求变更
• 初始需求：仅需集成支付宝SDK
• 迭代变更：新增微信支付、银联云闪付需求
• 架构冲击：
• 原有支付接口需支持多通道动态切换
• 安全键盘模块需适配不同支付协议
• 对账系统需处理多平台交易流水

• 兼容性解决方案：

• 成本分析：未采用策略模式的情况下，每次新增支付方式需修改核心代码，维护成本提升200%

需求冲突风险

• 模块间冲突案例：
• 需求A：消息推送模块要求使用Firebase Cloud Messaging（依赖GMS服务）
• 需求B：国内市场适配需求要求支持华为Push Kit（需移除GMS依赖）

• 技术矛盾点：

• 解决方案：

• 实施成效：双方案共存使安装包体积仅增加0.8MB，推送到达率提升至双端均超95%

技术可行性风险

• 定义：需求超出当前技术栈或设备能力

• 经典案例：
• 需求：在低端设备实现4K视频实时滤镜处理
• 技术矛盾：
• Mali-G51 GPU的渲染能力仅支持1080p@30fps
• OpenGL ES 3.0不支持部分高级着色器验证方法：

• 结果：测得单帧处理时间＞33ms（无法满足30fps需求）

常见需求风险分析方法论

• 5W2H需求澄清法——针对需求模糊性风险

• 变更影响树分析——针对需求变更风险

• 模块依赖矩阵——针对需求冲突风险

• 快速原型验证法——针对技术可行性风险

5W2H需求澄清法——针对需求模糊性风险

变更影响树分析——针对需求变更风险

• 案例：支付模块变更影响模型

• 需求变更：新增Apple Pay接入

• 影响分析树：

模块依赖矩阵——针对需求冲突风险

• 推送服务冲突分析

• 解决方案：

快速原型验证法——针对技术可行性风险

• AR导航模块可行性验证——四步验证流程：

1. 设备能力检测：

2. 性能基准测试：

3. 功耗测试数据：

4. 决策建议：在中低端设备上降级为2D导航模式