需求分析---软件架构师武器库中的天眼系统
在软件架构中，需求分析决定了系统的核心设计方向。
然而，现实中的需求往往存在以下问题：
需求被二次加工：产品经理或业务方可能直接提供“解决方案”（如“我们需要一个聊天功能”），而非原始需求（如“用户需要实时协作沟通”）。
需求边界模糊：未拆分的需求可能导致架构过度耦合，后续难以扩展。
技术可行性被忽视：某些需求在业务层面合理，但技术实现成本极高，需早期识别。
因此，架构师必须像天眼系统一样，穿透表层需求，直达问题本质。
以下为具体的需求分析流程
1 获取表层需求：从产品经理或领导那里输入进来。
2. 刨根问底：挖掘根源需求
2.1 什么是根源需求？
根源需求（Root Requirement）是用户或业务最本质的目标，而非具体实现方式。例如：
表层需求：“我们需要一个消息红点提醒功能。”
根源需求：“用户需要及时感知重要更新，避免遗漏关键信息。”
若架构师仅实现“红点功能”，可能错过更优方案（如推送通知、未读计数等）。
2.2 如何识别根源需求？
5 Why 分析法：
Q1: 为什么需要这个功能？ → “提升用户活跃度。”
Q2: 为什么当前活跃度低？ → “用户看不到新内容。”
Q3: 为什么用户看不到？ → “信息入口太深。”
最终根源需求可能是“优化信息展示层级”，而非单纯增加红点。
用户旅程映射（User Journey Mapping）：
通过分析用户完整操作路径，找到痛点。例如，电商App的“购物车流失率高”可能源于结算流程复杂，而非购物车本身设计问题。
业务目标对齐：
与业务方讨论KPI（如留存率、转化率），确保需求与核心指标挂钩，避免“伪需求”。
2.3 案例：某社交App的“已读回执”需求
初始需求：“增加消息已读状态显示。”
根源需求分析：
用户真正诉求：确保消息被对方看到，而非单纯“已读”。
更优方案：
弱化“已读”标签（避免社交压力）。
提供“紧急消息”强提醒功能。
架构影响：
原始方案仅需修改消息状态存储。
优化方案需重构通知系统，但长期体验更佳。
3. 需求拆分与组合：构建清晰边界
3.1 为什么需要拆分需求？
原始需求通常是宏观的，如“做一个电商App”，需拆分为：
用户认证
商品浏览
订单支付
物流跟踪
拆分后，架构师能更精准地：
识别核心模块（如支付必须高可用）。
确定技术边界（如用户认证是否依赖第三方SDK）。
3.2 拆分方法论
业务能力建模（Business Capability Mapping）：
将系统分解为独立业务能力单元，例如：
电商核心能力：商品管理、交易、履约。
辅助能力：评论、推荐。
用例（Use Case）分解：
每个功能点拆分为具体交互场景，例如“支付”可拆分为：
正常支付流程
优惠券抵扣
支付失败处理
组合优化：
拆分后的需求需重新组合，确保：
模块间低耦合（如订单系统不直接依赖物流详情）。
粒度适中（如“用户系统”不宜过细，避免微服务过度拆分）。
3.3 案例：短视频App的“视频推荐”需求
原始需求：“提升视频推荐准确率。”
拆分后：
用户兴趣建模（历史行为分析）。
视频内容标签化（NLP处理）。
实时推荐算法（协同过滤+深度学习）。
架构决策：
兴趣建模可离线计算（批处理）。
实时推荐需高性能流处理（如Flink）。
4. 技术方案融合：从需求到可落地架构
4.1 技术可行性评估
需求必须与技术现实结合，例如：
业务需求：“支持千万级并发聊天。”
技术约束：
移动端长连接保活成本高。
需权衡：自研IM vs 第三方服务（如融云）。
4.2 行业方案借鉴
避免重复造轮子，例如：
支付系统可参考支付宝/微信的架构设计。
图片加载可采用Glide/SDWebImage优化策略。
4.3 案例：跨平台移动端架构选型
需求：“iOS/Android双端功能一致，降低开发成本。”
技术方案对比：
方案 优势 风险
原生开发 性能最佳 双倍人力
Flutter 代码复用 生态局限
React Native 热更新 性能瓶颈
最终决策：核心模块用原生，UI密集型页面用Flutter。
最后强调以下：天眼系统的终极目标
需求分析不仅是“收集需求”，而是：
穿透表象，直达本质（根源需求）。
结构化拆分，降低复杂度（模块化）。
技术驱动业务，而非被业务绑架（可行性融合）。
只有具备“天眼”视角的架构师，才能设计出既满足当下，又适应未来的移动端系统。