《软件需求最佳实践》这本书如果在我上学时来看，几乎提不起任何兴趣。上学时写软件开发文档，完全是为了交差，追求又臭又长，UML 是用来混凑篇幅的绝佳工具。

没有亲自考虑设计中大型规模的系统或项目，是没法体会到 UML 这套工具的优势的。当你做的系统足够复杂时，你需要有一个工具能帮你分析、描述这个系统的核心逻辑。

但对一个复杂的系统进行需求分析，你往往无从下手。大多时候我们被迫应付着业务方的需求，毕竟产研团队基本是不背业务团队 KPI 的，做好系统，支撑业务就行了。随着时间的变化，系统堆叠的功能越来越多，它越来越没法满足业务多变的需求。

需求的变更导致开发、维护的成本越来越高。我们越来越害怕变化，希望业务能够保持一个高度的稳定，但很多东西是无法控制的，行业市场的变化、组织结构的变化甚至商业模式的变化，都让我们觉得无所适从。

我们希望控制变化的成本，无法评估的变化是一个噩梦，整个项目像陷入一个沼泽地，投入大量的资源，其产出却微乎其微。

大部分的后端系统都是从业务功能模块这个维度分解，系统被划分为 XX 管理、OO 管理等，对后端系统的认识停留在管理就是增、删、改、查等操作，页面设计就是左导航、列表页、详情页。因为对业务缺乏深入的分析了解，导致在这个基础诞生的系统往往也是短命的。

这本书提供一个 SERU 需求分析框架，并辅以案例详细说明。

S ( Subject )：主题域，通过划分每个子业务确定对应系统的边界范围；
E ( Event )：事件，指业务的主要活动及流程
R ( Report )：报表，主要指数据统计类需求
U ( User Case )：用例，需求的最小粒度单位，根据用例确定界面原型及细节。

最关键是在案例详细阐述了 UML 的用法，能把你之前学的组件图、部署图、状态图、时序图、用例等在需求分析中串起来，UML 应该是做后端系统的 PM 非常值得学习的技能之一。

书中讲到的内容也偏架构师方面的内容。以主题域为例，每一个业务都是不同的子系统组合支撑起来的，而子系统间的连接是受制于公司的组织架构的，换句话说，公司的组织架构直接影响其 IT 系统的架构方式。这就是著名的康威定律（ Conway's law ） 。

由于后端系统涉及到组织架构，那后端系统的政治性就无法避免，每一个后端系统都有大量的利益相关者。高层对这个系统的目标和期望、中层的管理需求、基层的使用需求、开发团队的技术能力都决定着这个系统的运作演化方式。

每一个系统其实都是各种利益博弈后的结果，尤其在大公司，几乎一个核心系统就对应着一个小组，假如小组 A 接管了原先小组 B 负责的系统，那小组 B 几乎注定是要被解散的。如果小组 A 内部新开发了一个很 NB 的系统，那小组 A 的内部组织必然分化，小组 A 人手必然扩大，组长及核心人员在公司话语权必然上升。

书中还提到领域模型（ Domain Model ），讲的非常少，能够在深入理解业务的前提下进行建模，想必做需求分析也应该是得心应手的。这本书值得细读的，就是第四、五、六章，其它章节能跳就跳吧。

推荐阅读：架构之路——穿行在产品和业务之间
推荐理由：做后端的 PM 了解一下架构的东西没有坏处，还能涨涨内力。