软件分析与设计笔记 01：课程地图与从需求到设计的主干

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，场景与图示都是自己编、自己画的，参考的主要是 UML 规范、敏捷宣言、Scrum Guide、ER 模型与规范化相关的公开文献这类一手资料。理解有偏差的地方欢迎指出。

0 先说清楚这门课要解决的问题

0.1 三句没法直接开工的话

只要参与过一点实际项目，大概都听过这几句话：

• 「需求先做起来，细节以后再补。」
• 「这里加个按钮就行。」
• 「性能要快。」

这些话没法直接开工，因为它们都缺同一样东西：可以被验证的判断标准。

0.2 三个要回答的问题

所谓软件分析与设计，就是把这类模糊的期望，一步步变成有边界、可验证、能被实现的东西。整个过程可以拆成三个问题：

1. 要做什么 —— 需求从哪里来？谁说了算（也就是利益相关者，stakeholder）？怎么判断它真实、完整、在范围内？
2. 怎么表达 —— 用什么模型把需求写清楚，让用户、分析师、开发看到的是同一件事？
3. 结构怎么定 —— 这些模型怎么变成能写代码、能建表、能长期维护的结构？

后面 27 篇笔记，都是围绕这三个问题展开的。这一篇先把地图铺开。

0.3 这份系列怎么读（三种读法）

不同的人来读这份笔记，目的不一样，所以入口也不一样：

三者的共同点是：每篇末尾都有带答案的自测题，读完做题才算过了一遍。

1 主干链路：从需求到设计

这张图是整份系列的骨架。它有一条重要性质：每一环的输出就是下一环的输入。

1.1 第一阶段的九个环节

• 事实调查（Fact Finding）产出的是访谈记录、观察结论这类原始材料；
• 范围界定（Scoping）把这些材料收成「做什么、不做什么」；
• 用户故事（User Story）把范围拆成一条条能验收的语句；
• 用例建模（Use Case Model）再把用户故事翻译成「谁、在什么条件下、对系统做什么」，一个用例下通常还挂着几条具体走法（scenario）；
• 活动图（Activity Diagram）把用例的流程画到能看清分支和例外；
• 实体与工作流（Entity / Workflow）从流程里抽出业务概念，形成领域模型（Domain Model）；
• 前端设计（UI / UX Design）把流程落到具体的界面与屏幕流程；
• 非功能需求（Non-Functional Requirement, NFR）补上「做得多好」；
• 测试（Testing）给出「怎么证明它做到了」。

1.2 第二阶段的八个环节

第二阶段换了一个视角：

• 数据库分析（Database Analysis）把业务概念变成实体、关系与基数（Cardinality），最后画成实体关系图（Entity Relationship Diagram, ERD）；
• 规范化（Normalization）把表结构调整到减少冗余、避免更新异常；
• 逻辑数据模型（Logical Data Model, LDM）在第三范式之上补出完整的关系；
• 面向对象（Object Orientation）提供另一套组织方式：对象、类、封装、继承、多态；
• UML 的类图（Class Diagram）与顺序图（Sequence Diagram）是这套方式的表达工具；
• 分析建模（Analysis Modelling）回答「每个用例由哪些对象协作完成」；
• 设计建模（Design Modelling）回答「这些对象怎么落到数据库、数据访问层和框架上」；
• 设计原则（Design Principles）与重构（Refactoring）负责让结构长期不烂。

2 两个阶段分别在做什么

最后两行是我自己的总结，也是这份笔记反复会回到的判断口径：需求阶段用「用户能不能确认」验收，设计阶段用「开发能不能实现」验收。很多项目出问题，是拿错了尺子 —— 比如用「代码能跑」去验收需求。

3 学习节奏：21 个单元怎么走

3.1 21 个单元与 27 篇笔记的对应

课程本身是按天推进的，每天一个主题加一次动手练习。我把它们整理成 21 个单元，对应到这份系列的笔记，方便你按顺序跟踪自己的进度：

最后一行是加餐。27、28 两篇不是课程内容，是考前的专项训练：27 拿一份完整案例把整份卷子从头走到尾，28 讲每个 UML 符号在 draw.io 里怎么落笔。它们不属于主链，但考试前最值得看。

3.2 怎么用这份节奏表

如果你是跟着课程走的，建议把「同样的练习自己重做一遍」当成标准动作：读笔记只需要一小时，把练习做出来才真正掌握。为此每篇末尾都留了带答案的自测题。

4 一个完整交付物里有什么

4.1 九项交付物清单

一门分析与设计课程最后要交的东西，通常叫用户需求规格说明书（User Requirement Specification, URS）—— 其实就是把上面那些环节的产出装订在一起。清单大致固定：

1. 访谈脚本与访谈记录 —— 你问了什么，对方怎么答；
2. 关键用户画像 + 客户旅程图（Customer Journey Map） —— 你选定的代表性用户是谁，他走完一件事要经过哪些步骤、在哪里受挫；
3. 一组用户故事 —— 通常 10 条左右，覆盖主流程；
4. 用例模型 —— 系统的功能边界，参与者（Actor）与用例（Use Case）的对应关系；
5. 活动图 —— 每个重要用例一张，包含分支与例外；
6. 屏幕设计 —— 关键用例的界面草图与页面之间的跳转；
7. 非功能需求 —— 性能、安全、可靠性；
8. 测试用例与测试数据 —— 不止一条，要覆盖异常输入；
9. 一份面向决策者的提案 —— 讲清楚现状问题、引入的技术、以及对用户的理解。

这份清单可以直接当自查表用：哪一项写不出来，说明对应的环节没做到位。

5 这份系列笔记的固定结构

5.1 贯穿全系列的那一个案例

为了让概念落地，从 04 篇起，整个系列用的是同一个案例：

片区家电维修派单系统（派单宝） —— 客户报修 → 客服派单 → 工程师接单上门 → 回填工单 → 仓管备料 → 片区经理看板。

角色：客户、客服（小林）、工程师（老陈）、仓管（小周）、片区经理（王姐），以及外部的「配件供应商库存系统」。

痛点：派单靠电话、工程师到现场才发现没配件、客户不知道几点上门、经理月底手工汇总。

选它的理由有三个：

• 四类图都能自然生成：有判断分支、有外部系统、有 CRUD 界面、有可量化痛点；
• 贴近真题的形态：真题就是「一个长案例串起四五个小问」；
• 每一步都能算：电话量、缺料率、上门时长都有具体数字，可以被数据验证。

案例覆盖不到的地方，各篇会另起一个补充案例（比如 23 篇讲继承映射时就换成了「维修单 / 保修单」）。这是故意的 —— 一个案例讲不了所有情况。

5.2 每篇的固定骨架

为了让你能按节奏跟踪，每篇都是同一套结构：

• 开头：这一环要解决什么具体麻烦（从场景讲起，不从定义讲起）；
• 中间：概念、判断标准、可操作的做法，配自绘图示；
• 「画这一笔」引用块（涉及作图的篇目）：这个知识点在 draw.io 里具体怎么落笔；
• 末尾：本节自测（6–8 题）+ 参考答案（每题标出对应小节）+ 术语表。

5.3 术语的写法约定

专业英语名词第一次出现时写作 English（中文），之后统一用英文，方便你在读英文文档和 UML 工具时对得上号。

本节自测

1. 需求阶段和设计阶段，「做完了」的验收标准有什么本质区别？
2. 「系统要快」为什么不能算一条合格的需求？要补上哪些信息才成立？
3. 用户画像（persona）和用户故事（user story）是什么关系？
4. 用例模型（use case model）和活动图（activity diagram）分别回答什么问题？
5. 一份交付物里同时有 ERD 和类图，它们的关注点差别在哪？
6. 这份系列为什么坚持用同一个贯穿案例？它的代价是什么？
7. 如果你只有一天准备考试，按 §0.3 的读法应该先读哪两篇？为什么？

参考答案

1. 需求阶段用「用户能不能确认」验收，设计阶段用「开发能不能实现」验收。很多项目出问题是拿错尺子 —— 用「代码能跑」去验收需求（§2）。
2. 因为它缺可验证的判断标准：要补上指标 + 条件 + 阈值三样，例如「早高峰查进度 95 分位 ≤ 2 秒」（§0.1，详见笔记 15）。
3. 画像回答「他是谁」（目标、行为、环境、痛点、限制），故事是从画像的某一栏推出来的一条可验收的诉求。每条故事都应该能指回画像的某一栏（笔记 05、07）。
4. 用例模型回答「系统做什么、谁在用」（功能边界）；活动图回答「一个用例的流程怎么走」（分支、并行、泳道）（§1.1，笔记 08）。
5. ERD 关注数据怎么组织（实体、关系、基数，为建表服务）；类图关注行为怎么归属（类、属性、操作、关系，为代码服务）。同一个业务概念在两边可能长得不一样（笔记 09 §6、18）。
6. 因为一个案例能让读者看到同一条信息在十几个环节里怎么被反复使用 —— 从一条投诉到一张表、一个类。代价是有些知识点这个案例天然没有（比如继承），所以各篇会另起补充案例（§5.1）。
7. 先读 27 和 28。因为 27 是一整份卷子的完整演算（读案例→列角色→画图→填表→自检），28 是符号在 draw.io 里怎么落笔。这两篇把「会什么」直接转成「能拿多少分」，突击效率最高（§0.3）。

术语表