一、三道筛子

业务分析：现实是怎么运作的——看全部，8 条。 需求定义：软件要承担哪一部分——砍到 5 条。 设计：用哪些类来实现——还是 5 条，换了名字。 条目数的变化只在第一到第二阶段，这一步就是 9.1 说的【判断】。

二、每一阶段的产物

业务分析 → 业务流程图：不出现任何软件词汇，画的是人的工作。 需求定义 → 用例图：框里是软件做的，框外是人做的（9.8 会画）。 设计 → 类图：概念类加上技术类（9.9 会画）。

三、为什么要分三段而不是一段

因为三种人看的东西不同：业务方看流程，产品看用例，开发看类图。 混在一起做，就会用程序语言跟业务方讨论业务——讨论必然崩。 分开做，每一段都只跟该跟的人确认，错了也容易回退。

四、这三段最容易错在哪

第一段就写字段：还没搞清业务，先想表结构，结果表结构绑死了业务理解。 第三段还在改需求：设计时发现需求缺项，说明第二段没做透。 跳段：直接从需求跳到代码，中间省掉的正是【判断哪 5 个该留】。

五、动手 Demo：通过业务分析、需求定义和设计来填补沟壑

同一个业务，三个阶段各留几条。 看条目数在哪一步减少、哪一步不变。

stages = [("业务分析", "现实是怎么运作的", 8),
          ("需求定义", "软件要承担哪一部分", 5),
          ("设计", "用哪些类来实现", 5)]
for name, q, n in stages:
    print(name, n)
# 8 / 5 / 5：减只发生在第一步，第三步只是换语言

实跑输出：

--------------------------------------------------------------------
通过业务分析、需求定义和设计来填补沟壑
--------------------------------------------------------------------

  三个阶段，**同一个业务过一次比一次窄的筛子**：

  阶段         回答什么问题           条目数
  -------------------------------------------
  业务分析     现实是怎么运作的       8
  需求定义     软件要承担哪一部分     5
  设计         用哪些类来实现         5

      业务分析留下的              8 条（最大）
      需求定义砍到                5 条
      设计阶段                    5 条（换了名字，数目不变）

  **筛子的方向很清楚**：业务分析看【全部现实】，需求定义看【软件那一块】。
  **设计阶段条目数不再减**——它只是把同一批东西换成程序语言。
  **三个阶段各自的产物**：业务流程图／用例图／类图。

实测：业务分析 8 条、需求定义 5 条、设计 5 条。 砍只砍一次——设计阶段条目不再减，它换的是名字不是数量。 三个阶段三种产物：业务流程图／用例图／类图。

30 秒实验

1. 把你手上的需求按三个阶段各写一版，看条目数在哪一步掉得最多。
2. 找出你项目里【第一段就在想表结构】的痕迹。

常见误区

1. 以为三阶段是流程形式主义。它对应三种人、三种语言。
2. 以为设计阶段还会继续砍需求。设计只换语言，不砍内容。

• ☐ 9.4 建模是顺利推进这三个阶段的工作的技术

相关笔记

• 计算机擅长固定工作和记忆工作 — 为什么判断必须人做
• 建模是顺利推进这三个阶段的工作的技术 — 用什么把三段串起来
• 在上游工程中化为通用的归纳整理法 — 同一份结构的三次使用
• 🧩 面向对象是怎样工作的 · 索引