企业官网建设流程全解析

这本书在圈子里挺有意思，有人把它当UML工具书，翻两章就搁下了；有人把它当"武功秘籍"，每隔一年重读一遍，都能推翻一点自己之前的设计习惯。我属于后者。《大象：Thinking in UML（第2版）》在前言里就说得很直白——UML不是画图工具，是思考工具。全书一路铺垫到第9章"获取需求"，终于进入实战环节：怎么把一个模糊的业务想法，一步步变成能指导开发的用例模型。而第9章第1、2节"定义边界"和"发现主角"，正是整个需求获取阶段踩下的第一脚油门。

这两个词乍一听都特别简单：边界嘛，画个框；主角嘛，画几个小人站在框外面。可真到自己上手做需求分析，很多人当场就卡住：边界框该画多大？哪些人算主角？"管理员"到底算不算？为什么我画出来的用例图，评审的时候需求方总说"不对味儿"？这些问题十有八九出在同一个源头——对"边界"和"主角"的理解只停留在"画图"层面，没搞清楚这两个概念在整个需求模型里的位置。这篇文章我就把自己反复读这几节的心得，加上实际做需求分析时验证过的方法，一次说清楚。

1. 先画一条"线"：定义边界这件事的本质

1.1 边界到底在划分什么

系统边界，英文叫System Boundary，在用例图里就是那个方方正正的大框。很多初学者觉得它就是个装饰，把用例往框里一丢、把主角往框外一摆，完事。但书里对边界的定位远不止于此——它是整个需求模型的"责任合同"。

边界回答的问题只有一个：这个系统"管到哪算完"。边界以内的区域，是系统必须承担的责任，这些责任后续要转化成具体的功能、接口、数据存储；边界以外的区域，是系统要打交道的环境，后续要定义成主角、外部接口和协作关系。换句话说，边界内外不是"图上的位置"不同，而是"建模待遇"完全不同。框里面的东西，开发团队要对它负责；框外面的东西，开发团队只能通过交互去影响它，不能直接控制它。

我用一个生活化的例子说明这件事。你请人代管房子，合同里一定写清楚"管哪几间房、管到什么程度"。代管人不会去修邻居家的屋顶，也不会帮你决定窗帘的颜色。系统边界就是这份合同上最粗的那条分界线，它决定了系统"管什么"和"不管什么"。边界画得太大，系统背上一堆不该管的业务，开发量翻倍还做不好；边界画得太小，需求方真正想要的功能全被推到框外面，模型怎么画都是散的。

从UML建模的角度看，用例图的三要素——边界、主角、用例——是一个互相咬合的整体。边界定不下来，用例就没有归属感，主角也不知道该站在哪里。很多团队用例图越画越乱，根子上往往就是边界的"责任合同"没签明白。

1.2 业务边界与系统边界：两个"圈"不能混着画

书里在"获取需求"这部分花了不少篇幅区分两件特别容易被混在一起的事：业务建模和系统建模。我见过太多团队，一上来就画系统用例图，把"报销审批""请假流程"直接当系统用例怼进边界框里。这样画不是不行，但容易犯一个隐蔽的错误——把"业务上要做的事"和"系统要承担的事"混为一谈。

业务建模阶段，我们以"组织"为边界。这个组织（比如某个部门、某家公司）负责哪些业务，边界外是客户、供应商、合作伙伴。这个阶段画出来的叫业务用例图，里面的用例描述的是业务目标，比如"完成报销付款""获取客户订单"。系统建模阶段，我们以"系统"为边界。这个软件系统要承载哪些功能，边界外是使用者和外部系统。这个阶段画出来的叫系统用例图，里面的用例描述的是系统功能，比如"提交报销单""审批报销单"。

这两个"圈"不画混的关键在于顺序。书中主张的路线是先业务、后系统。先通过调研把业务看清楚，画出业务用例模型；再沿着"业务流程→系统支持点"的映射关系，把业务中需要软件辅助或自动化的部分挑出来，作为一个候选的系统用例集合；最后围着这些候选用例，圈出系统边界。

我自己落地这套思路时，一般按四步走：

1. 搜集业务素材，不碰系统，只记录业务现实——谁发起、谁处理、谁审核、谁用结果。
2. 以组织为边界，画出业务用例图。
3. 从业务用例里圈出"需要系统支撑"的候选功能，摆进系统边界。
4. 根据系统负责人的期望，反复调整边界大小——这一步通常要来回几轮。

强调一下最后一步。边界不是一次画死的，它是被"系统负责人"的意愿约束的。同一段业务，A公司愿意为"填报+审批+统计"整套流程建系统，B公司只想先做一个"审批留痕"，边界自然不一样。书里反复提醒的也正是这一点：边界是一个动态的概念，它依赖你调研得到的信息，依赖干系人的决策，不是一个从教科书里抄来的固定框。

2. 发现主角：边界之外的"活角色"

2.1 主角不是用户，用户也不是主角

定义完边界，接着就要找站在边界外、和系统打交道的"活角色"——主角。UML里的英文原文是Actor，这一版中文翻译成"主角"其实挺传神。它不是"用户"的同义词。

Actor和"用户"最大的区别是：用户是现实世界里的人，属于某个组织，有具体的岗位和姓名；Actor是模型里的一个抽象角色，它描述的是一类"与系统发生交互的立场"。一个人可以对应多个Actor，比如同一个人既是"报销申请人"又是"审批人"，只要他同时扮演两个交互立场，他在用例图里就是两个主角。反过来，一个Actor也可以对应多个人，比如"审批人"可以由部门主管、总监分别担任，但他们都属于同一个Actor。

既然主角不是人，那怎么找？书里把它归纳成一套"主角自检"思路，我在实践中改写成五个问题：

• 谁直接使用系统的主要功能？
• 谁需要系统提供的服务来完成自己的工作目标？
• 谁负责系统的日常运行、维护和管理？
• 系统需要从哪些外部系统或设备获得数据？
• 谁会消费系统产出的信息或结果？

这五个问题里，第5个最容易被忽略。要特别注意：消费信息的人不一定是主角，除非他直接操作系统。我遇到过一个经典案例：老板要看项目工时统计，但他自己不登录系统，让财务导出Excel发给他。那老板就不是主角，财务才是。因为"导出统计报表"这个用例是财务发起的，老板只是报表的读者，他没有直接和系统产生交互。

2.2 从业务主角到系统主角：一个翻译过程

书里在"发现主角"这一节还把主角细分成了业务主角（Business Actor）和系统主角（System Actor），这个划分很多人读的时候一带而过，但它其实特别重要。

业务主角站在"业务边界"外面，比如客户、供应商、合作方。系统主角站在"系统边界"外面，直接操作系统。需求获取阶段要做的，是先从业务模型里把业务主角找全，这一步保证你不漏人；再沿着"业务流程→系统支持点"的映射，把业务主角翻译成系统主角，这一步保证你找出来的人都能和系统挂上钩。

举个例子。"客户下单"这个业务，如果系统是"客户自助下单的商城App"，那么客户既是业务主角，也是系统主角——他本人直接操作App。但如果业务是"客户打电话给客服中心下单"，那么客户只是业务主角，客服才是系统主角。要是把客户画进系统用例图，挂在"提交订单"用例下面，模型和现实就对不上了——因为实际点击"提交订单"按钮的人，是客服，不是客户。

这就是业务主角到系统主角的"翻译"过程。翻译的时候要特别留意：哪些业务主角会直接和系统交互，哪些要通过中间人。直接交互的保留，间接交互的替换成中间人。

2.3 主角识别的经典三个坑

读第9章的时候，我把自己以前画过的一堆用例图翻出来对照了一遍，发现错误高度集中。这里把我踩过和见过最多的三个坑列出来：

第一个坑：把"管理员"画成万能主角。几乎每张初学者用例图上都有一个"管理员"，下面挂着一大串"用户管理""权限管理""数据维护"。你要是追问一句"这个管理员具体是哪个岗位的人"，往往答不上来。正确做法是把"管理员"拆成具体角色，比如"系统配置员""安全审计员"，或者直接把配置职能归到真实岗位上。一个笼统的管理员主角，会让角色的职责边界变得特别模糊。

第二个坑：把组织、部门当主角。"财务部""人事部""物流部"被画进用例图，这又是把业务主角和系统主角混了。系统面前，交互的永远是"岗位上的某个人"或者"某个外部系统"，不是一个抽象的部门。要画就画"财务部门的成本会计专员"或"财务系统"，后者更常见。

第三个坑：漏掉外部系统和定时触发。需要对接的ERP系统、短信网关、银行支付接口，甚至"每天凌晨两点自动跑批"的时间触发，都是合法主角。很多人画用例图只考虑人，把所有非人的交互全忽略掉，结果开发阶段才发现一堆接口没人提需求，集成时返工到崩溃。非人主角和人工主角在用例图上的地位一样高，它们同样会发起用例、同样需要被建模。

3. 从零到一：模拟项目的边界与主角实操

理论说了不少，下面用一个模拟项目从头到尾走一遍。这个案例完全虚构，但流程和真实项目一致，你可以直接照着这个思路在自己的项目里复现。

3.1 项目背景与业务素材

某公司的研发部门，长期以来项目工时统计靠月底手工汇总Excel。员工每天填自己干了哪些项目、干了几小时，月底项目经理一个个收上来核对，再手工调整异常数据。部门主管想看项目人力投入是否超标，得等项目经理统计完才知道。财务要把人力成本摊到每个项目上，每次都找项目经理要数据要很久。

这个部门负责人想建一套"项目工时管理系统"，解决手工汇总的痛点。需求获取阶段刚开始，摆在我们面前的素材还是零散的：

• 员工每天在Excel里填自己干了哪个项目、几个小时；
• 项目经理月底把Excel收上来，人工核对、调整；
• 部门主管要按项目看工时汇总，判断人力投入有没有超标；
• 财务需要按项目工时计算人力成本分摊；
• HR希望新员工入职时，人员基础信息能自动同步，不要人工录入。

注意这些素材全是业务描述，一个"系统"的字眼都没出现。这就是我最想强调的第一步：先别碰系统，先把业务现实记录下来。

3.2 第一步：先画业务用例图

以"研发部门"为业务边界，画业务用例图。业务主角很容易找出来：员工、项目经理、部门主管、财务部、HR。

对应的业务用例大致是：

• 员工填报工时；
• 项目经理收集工时；
• 项目经理核对工时；
• 部门主管查看项目工时投入；
• 财务按项目分摊人力成本；
• HR同步人员信息。

每个用例描述的都是"业务上要达成什么"，不描述"系统怎么实现"。这个阶段的目的是把部门的目标和干系人梳理清楚，为下一步圈定系统边界提供依据。

3.3 第二步：确定系统边界

和部门负责人、管理层确认后，系统边界大致确定为：填报、提交、审批核对、汇总统计、导出成本数据，这几件案子归系统管；人员信息从HR系统自动同步，也归系统管，但走接口。Excel手工汇总这种事，彻底排除在边界外。

画系统用例图时，边界框里面的候选系统用例是：

• 填报工时；
• 提交工时；
• 审批工时；
• 查看项目工时统计；
• 导出工时数据给财务系统；
• 同步人员信息。

边界框外面的系统主角是：员工、项目经理、部门主管、财务系统、HR系统。

注意看这里发生的变化——业务主角"财务部"变成了系统主角"财务系统"，业务主角"HR"变成了系统主角"HR系统"。这就是前面说的"翻译过程"。财务部本身不直接操作系统，财务部的成本核算系统会调用工时数据；HR也一样，人员信息是从HR系统对接过来的。

还有个细节值得多琢磨一下：最初大家都会觉得系统应该有个"管理员"，负责配置项目信息、维护人员权限。但在和部门负责人对了几轮之后，发现这些事现实中本来就是项目经理在承担——项目信息是他建的，人员权限也是他调的。于是模型里没有单独出现"管理员"，而是把"维护项目信息""管理项目成员"这些职责并到"项目经理"这个系统主角下面。这样角色一精简，看图的人一下子就能理解：原来这些配置工作归项目经理管。

3.4 第三步：验证主角与用例的匹配

画完初稿，要做一轮验证，逐条检查三条规则：

• 每个用例至少有一个发起主角；
• 每个主角至少参与一个用例；
• 每个主角都在系统边界外。

对照这个案例："填报工时"的发起主角是员工，成立。"审批工时"的发起主角是项目经理，成立。"查看项目工时统计"的发起主角是部门主管，成立。"导出工时数据"的发起主角是财务系统，成立。"同步人员信息"的发起主角是HR系统，成立。所有主角都在边界外，所有用例都在边界内，模型自洽。

如果检查时发现"用例没有主角"，说明这个功能没人发起，没人要的东西就该删掉；如果发现"主角没有任何用例"，说明这是个伪主角，要么补充用例，要么把它从模型里请出去。这两条规则我每次评审前都会过一遍，性价比极高。

4. 边界和主角出问题时，典型的症状与排查方法

前面讲的是怎么做，接下来这部分是我最想分享的——做错的时候是什么样的。第9章读完，最值钱的不是那一堆概念，而是能识别出自己的模型哪里病了。我总结了几个高频"症状"，对照着排查，基本一查一个准。

4.1 症状一：用例图越画越庞大，评审时间越来越长

表现：边界框里塞了几十个用例，评审会上讲半小时还没讲到一半，需求方开始走神，开发开始皱眉头。

原因：大概率是边界画大了，把"配合流程"当成了"系统功能"。很多动作只是业务环节里的信息传递，系统并没有独立承担决策或处理，却被画成了系统用例。

排查方法：回到业务模型，重新问一句——"这个业务动作，系统有没有义务独立完成？"如果系统只是帮忙把消息从A传给B，真正的负责方在外部，那就把这个动作从系统用例里拿出来，放到业务层面描述，或者改成系统与外部主角之间的接口和协作。

4.2 症状二：需求方看了模型说"这不是我要的"

表现：评审会上需求方说"我要的其实是……"，然后你发现他说的功能边界框里根本没有。

原因：边界画小了。最常见的是只画了操作过程，漏掉了信息输出。比如系统的统计功能，只画了"查看统计报表"，漏了"导出报表给外部审计"这个用例。需求方心里的系统是有输出的，模型里的系统只进不出，必然对不上。

排查方法：把主角清单拉出来，一个一个过，看每个主角关心的"结果"有没有对应的用例。主角列表就是干系人列表，他们的核心诉求没有用例承载，边界就是不完整的。

4.3 症状三：开发阶段才发现漏了接口

表现：开发已经进行到集成阶段，突然发现系统需要从某外部系统取数，或者需要给某外部系统推数据。这个接口在需求文档里压根没提。

原因：主角识别漏了非人角色。外部系统在用例图里没有占到一个主角位置，它的交互需求自然没人提。

排查方法：在需求获取阶段就养成一个习惯——系统要获得的数据，来源是什么；系统要输出的数据，去向是什么。把这两个"流向"当成主角对待，和人工主角同等重视。数据流经的每一个外部系统，都要在用例图上占一个位置。

4.4 边界、主角问题速查表

为了方便对照检查，我把上面这些经验整理成一张速查表，每次画完用例图扫一眼，能省不少评审会上的尴尬。

4.5 一个屡试不爽的检视技巧

最后分享一个我自己屡试不爽的技巧：主角回放。

操作方法很简单：想象自己变成了主角清单上的某个人，从他的视角把他的日常工作从头到尾走一遍。比如你是项目经理，你登录系统要做什么？先审核工时，再维护项目信息，再看一眼统计报表——这时候你就去模型里找，这些动作是不是都有对应的用例。走完一个人，再换下一个主角走一遍。

如果某个主角的日常操作在模型里"走到一半走不通了"，那这个模型十有八九有缺陷——要么缺用例，要么边界划分有问题，要么主角本身定义错了。这个方法我在评审前百试百灵，比对着规则硬检查快得多，因为它驱动你从使用者的真实工作流去审视模型，而不是从图的完整性去审视模型。

5. 读书与练习建议

写到这里，最后说点关于怎么读第9章的个人建议。这本书跟普通技术书不一样，不是翻一遍就能吸收的，尤其是"获取需求"这种偏方法的章节。我建议至少读三遍：第一遍通读，知道大概讲了什么；第二遍照着书里的示例项目，自己动手画一遍用例图；第三遍拿一个自己手头的真实项目来套用，遇到卡壳的地方再回头翻书。

配套的练习也很简单：从你身边找一个日常工作流程，比如报销、请假、设备领用。第一步，只收集业务素材，憋住不碰系统，画业务用例图；第二步，定义系统边界，画系统用例图；第三步，识别主角，逐条验证。整个过程不需要任何工具，纸和笔就够了。

练习的时候记住一个原则：克制住"不画系统会死"的手。很多人在第一步就忍不住画系统用例图，然后边界、主角全乱套。真正把业务看清了，系统边界不是"画"出来的，是"浮现"出来的。

我个人在实际项目中反复体会最深的一点是：边界这个词，字面上是一条线，本质上是一种取舍。需求分析中所有的争论，最终都落在两个问题里——"你到底管到哪"和"到底谁来用"。《大象》这本书第9章前两节讲的定义边界和发现主角，恰恰就是把这两个问题摆到台面上，逼着团队正面回答它们。回答清楚了，用例图就是顺手画出来的结果；回答不清楚，图擦一百遍也没有用。这两节内容不多，但值得反复琢磨。