字数 9479，阅读大约需 48 分钟
第22讲：搞清楚业主到底要什么？（需求分析与UML）
【老孙开篇寄语】
同学们，欢迎来到“工程篇”的第二站。
上一讲，我们，像一位“总建筑师”，为“智慧邻里”这座软件大厦，规划了它的“建造流程”（SDLC模型）和“结构骨架”（软件架构）。我们，做出了一个至关重要的、“演进式”的架构决策——从一个“模块化的单体”开始，逐步，向“微服务”演进。
蓝图，已经宏伟。但，一个更棘手、更根本的问题，摆在了我们面前：
这座大厦里，到底，要建哪些“房间”？每个房间，要开几扇“窗”？“厨房”的灶台，要多高？“卧室”的灯，要什么颜色？
这些，就是“需求”。
在软件工程的所有活动中，“需求”，是最“靠近钱”的，也是最“靠近人”的。它是所有后续“设计、开发、测试”工作的“源头”。然而，它，也是整个软件开发过程中，**最模糊、最善变、最容易“挖坑”**的环节。
.
无数“雄心勃勃”的项目，最终，之所以，沦为“华而不实”的“烂尾楼”，其根源，往往，不是因为“技术不行”，而是因为，在项目的第一天，就“没搞清楚，客户，到底，要什么”。
今天，我们，就要戴上“侦探”的帽子，拿起“放大镜”，来系统地，学习一门，将“模糊、混乱、甚至互相矛盾”的用户想法，转化为“清晰、准确、可执行”的“需求规格”的科学与艺术——需求工程（Requirements Engineering）。
在这个过程中，我们，还将，正式地，结识一位“伟大的翻译官”——UML（统一建模语言）。它，将为我们，提供一套“世界通用的语言”，来精确地，描绘我们的“需求”和“设计”。
这是一堂，决定我们“智慧邻里”项目，“方向是否正确”的，关键一课。准备好了吗？让我们，潜入用户的“内心深处”，开始这场“需求的探索之旅”！
第一章：上节回顾与热身
1.1 上节核心回顾
在开始今天的“探索”之前，我们先来回顾一下，上一讲，我们作为“总建筑师”，所沉淀下来的“三大架构级心智模型”：
- 1. 心智模型一：“大教堂”与“集市”的永恒张力
- • 我们理解了，瀑布模型，是“大教堂”思想的极致体现；而敏捷开发，则是“集市”思想的现代实践。它们，代表了“确定性”与“不确定性”这两种，截然不同的世界观。
- • 高项认知： 为“智慧邻里”这个“需求模糊、市场多变”的互联网项目，选择“敏捷”的“集市”模式，是我们的必然选择。
- 2. 心智模型二：“康威定律”的组织魔咒
- • 我们深刻地认识到，“组织的沟通结构，决定了系统的设计结构”。架构，从来，都不是一个“纯技术”问题，而是一个“社会-技术”问题。
- • 高项认知： 如果，我们想，最终，演进到“微服务”架构，那么，我们，必须，先“逆康威定律”而行，推动我们的“组织”，先变成“小而美、跨职能”的“微服务”形状。
- 3. 心智模型三：“权衡”是架构的唯一艺术
- • 我们明白了，架构的世界里，没有“银弹”。每一个选择，都是一次“取舍”。
- • 高项认知： 一个成熟的高项经理，他的价值，不在于，他懂不懂“微服务”，而在于，他能否，清晰地，向CEO，解释清楚，不同架构选择背后的“商业逻辑”和“风险收益”，并给出一个“务实的、演进式的”架构路线图。
1.2 上节课后作业精讲
上一讲的第三个作业，是整堂课的“题眼”，也是对你，作为“智慧邻里”项目总负责人，“架构决策能力”的终极考验。
场景复盘：
在架构选型会上，首席架构师（技术理想派），坚持，从第一天，就上“纯粹的微服务”，着眼未来。而核心开发组长（务实主义派），则力主，从“单体架构”开始，快速，推向市场。CEO王总，把皮球，踢给了你，他“既要‘星辰大海’，也要‘真金白银’”。
这，是一个典型的，在“长期利益”和“短期利益”之间，进行“权衡”的，高难度决策。
一份“平庸”的备忘录，会“二选一”，然后，试图，说服CEO。
而一份“优秀”的备忘录，则会，超越“二选一”，提出一个，能“同时满足”双方诉求的“第三条道路”。
现在，看老孙，如何，草拟这份，体现了“演进”与“权衡”智慧的《架构决策建议备忘录》。
备忘录
致： CEO王总
发件人： “智慧邻里”项目总负责人，老孙
日期： 2025年11月20日
主题： 关于“智慧邻里”项目初始架构选型的决策建议
王总，
您好。针对昨日会议上，架构师与开发组长，关于初始架构选型的激烈讨论，我进行了审慎的思考，并结合我们项目“快速验证商业模式，同时，为未来高速发展，预留空间”的核心战略目标，现将我的决策建议，汇报如下。
一、 两种方案，都是“正确”的，但“不完整”
首先，我必须明确，无论是架构师的“微服务优先”方案，还是开发组长的“单体优先”方案，都不是“对”与“错”的问题，而是“在哪个时间点，更合适”的问题。他们，分别，代表了我们项目，在“长期生命力”和“短期生存”这两个维度上的诉求，两者，都至关重要。
- • “微服务优先”方案的价值与风险：
- • 价值（我们的“星辰大海”）： 它，为我们，描绘了一幅“理想”的未来图景——一个高度敏捷、极具弹性、技术异构的“乐高城市”。这，确实，是我们应对未来“千万级用户”和“每周数十次功能更新”的“终极形态”。
- • 风险（眼前的“沼泽地”）：
- 1. 时间成本巨大： 我们团队，目前，缺乏大规模分布式系统的实战经验。光是“服务发现、网关、配置中心”等一系列“市政系统”的搭建、学习和磨合，就可能，耗费我们3-6个月的宝贵时间。届时，我们，可能，连一个核心功能，都无法，交付给市场。
- 2. 组织能力不匹配（康威定律）： 我们现有的“大开发部”组织模式，与微服务所要求的“小而美的、跨职能的”团队结构，存在根本性矛盾。强行上马，必然，导致“沟通地狱”。
- 3. 技术过度设计（Over-Engineering）： 在项目初期，业务模式，尚不清晰，功能边界，仍在探索。过早地，进行服务拆分，很可能，是一种“盲人摸象”式的拆分。我们，极有可能，在6个月后，发现，当初的“服务边界”，切错了，届时，重构的代价，将是巨大的。