2. 分层架构基础
需求分析这件事，说白了就是搞清楚「到底要做什么」。我见过太多项目，架构图画得漂漂亮亮，代码写得飞起，结果上线后用户说「这不是我要的」。嗯，问题就出在需求分析这一步没走扎实。
这一章我们聚焦三个核心动作：写用户故事、排优先级、画全景图。这三板斧抡好了，后面的分层设计才有根基。
用户故事：不只是「As a… I want… So that…」
用户故事的标准模板大家都会背：
As a <角色>
I want <功能>
So that <价值>但我在项目中踩过坑——团队把用户故事写成了「功能清单」。比如：
- ❌ 用户故事：用户能上传文件。
- ✅ 用户故事：作为项目成员，我希望上传设计文档，这样团队可以共享评审。
看出区别了吗？前者只说了「做什么」，后者说清了「谁做、做什么、为什么做」。这个「为什么」特别重要，它直接决定了后续架构设计的取舍。
举个例子，我在做一个电商后台时，运营提了个需求：「导出订单报表」。我追问了一句「为什么需要导出？」——原来他们是要手动发给财务对账。那其实更好的方案是「自动推送对账数据到财务系统」。你看，故事写清楚了，方案就变了。
MoSCoW 优先级排序：别什么都想要
需求永远做不完，资源永远不够用。MoSCoW 方法是我最常用的排序工具，没有之一。
| 分类 | 含义 | 占比建议 | 我的经验 |
|---|---|---|---|
| Must have | 没有这个功能，系统不能上线 | ≤ 60% | 通常来自核心业务流程 |
| Should have | 很重要，但可以找替代方案 | 约 20% | 比如批量操作、高级筛选 |
| Could have | 锦上添花，有最好没有也行 | 约 15% | 比如数据导出格式美化 |
| Won't have | 明确本期不做 | 约 5% | 要写进「未来规划」文档 |
排序的时候，我建议拉上产品、开发、测试三方一起过。为什么？因为视角不同。开发觉得「这个功能实现成本高」，产品觉得「这个功能用户呼声大」，测试觉得「这个功能容易出 bug」。三方一碰撞，优先级就清晰了。
建立需求全景图：一张图看清全局
用户故事写好了，优先级排完了，接下来要画一张「全景图」。这张图不是为了好看，而是为了回答三个问题：
- 所有需求之间是什么关系？
- 哪些需求属于同一个业务域？
- 需求的全貌有多大？
我习惯用「需求地图」的方式来组织。下面这张 SVG 图展示了一个典型电商后台的需求全景结构：
这张图的价值在哪？我举个例子。有一次我们做物流系统，产品经理一口气提了 40 个需求。我把它们按业务域分组，画成全景图，发现「运费计算」这个域下面有 8 个需求，其中 5 个是 Must have。而「物流追踪」域下面只有 2 个需求，还都是 Could have。那资源往哪倾斜？一目了然。
- 发现遗漏：某个业务域下面需求太少，可能是没想透。
- 识别冲突：两个需求看似独立，其实依赖同一个底层服务。
- 指导架构：业务域的边界，往往就是未来微服务或模块的边界。
实战流程：三步走
说了这么多，具体怎么落地？我总结了一个三步走的流程：
- 第一步：写故事
- 产品经理牵头，开发、测试参与
- 每个故事必须包含角色、功能、价值
- 控制在 1-2 句话，别写成需求文档
- 第二步：排优先级
- 用 MoSCoW 方法给每个故事打标签
- Must have 不超过总量的 60%
- Won't have 要明确记录，别丢
- 第三步：画全景图
- 按业务域分组
- 标注优先级
- 识别依赖关系