大话软件工程：需求分析与软件设计（二十三）
附录A 能力提升训练
软件工程知识体系（非技术部分的分析与设计）已经全部介绍完了，因为所有阶段的成果都要以工程化的方式交付，所以前面介绍的内容主要是软件工程中的框架、方法、步骤、模板、标准等以“动手”为主的内容。严格地说，软件的分析与设计是一种“创新”的工作，因为碰到的所有问题都没有一样的，即使是属于同类客户（同一行业、同一领域），但是也没有一模一样的企业决策者、管理者以及执行群体，因此，在掌握前述知识和方法体系中条条框框的同时，还需要训练观察、思考的能力，这是解决复杂问题的基础。相对于软件工程的知识体系来说，提升观察与思考能力需要的时间会更长一些，优秀的软件工程师（需求、设计、开发），必须要做到眼（观察）、脑（思考）和手（写绘）三者协同工作，才能做出一个完美的成果。
A.1 观察能力的训练
做好初级的分析与设计工作，只需要掌握软件工程内的知识基本上就可以做到了。但是要做好大型、复杂、创新项目的调研、分析和设计工作，只靠软件工程中介绍的知识还不够用，因为：
（1）软件工程是指导“按照知识框架的内容，工程化、标准化地去做出资料”。
（2）而“大型、复杂、创新”的项目就意味着它们不是能“一眼看穿、看透”的研究对象，因而不能上来就直接动手用模板做设计，而是要先“用眼观察、用脑思考”，通过观察、思考得出信息后，再动手按照软件工程中的方法、模板等去做具体的分析与设计。
有了正确的观察、思考能力，不但可以避免走错方向，而且可以大幅度地缩短分析与设计的时间。但与用“手”做的工作相比较，观察和思考是使用“眼和脑”，所以后者做的工作就会相对抽象一些、难一些，因为对眼和脑的工作无法给出相应的模板、标准和工具。如何观察、思考是个大课题，这里介绍基于作者长期实践经验总结的三个观察与思考问题的方法，即：绘画式、多角度、系统化。
A.1.1 绘画式看问题
第一种方法称为：绘画式看问题。观察和思考研究对象，借鉴画家在作画时的观察与思考方法很有帮助，因为绘画的过程是画家反复地进行思考→观察→绘制→调整的过程，与软件的需求调研、需求分析、设计开发的过程十分相似。
画家在绘制一幅大型的作品时（如同面对一个复杂的大型系统），他的思考与观察方法是一个非常重要的技术，这个方法可以粗分为三种，即：远看、虚看和近看。绘制不同的部位时，需要反复运用这三种方式交替进行。
【方式1】远看，拉开距离看全貌（整体构图）。
1．画家在对画进行构图时，站在与画布保持一定距离的地方，这个距离可以让画布上的全部内容收入到画家的眼中，有利于进行整体的构图。没有这个距离，就看不到画布的全貌，关键要素的摆放位置就找不准，各种关键要素之间的关系就难以确定。
2．软件工程师在面对一个复杂的分析系统时，不要在研究的初期就快速地进入到对细节的讨论，而是要先确认分析对象的范围、各个重要要素之间的位置、粗略的关联关系，例如，项目包括哪些业务板块、各个业务板块中有哪些核心系统（主营业务、辅助业务、支持业务）等。最终系统的方向、规划，以及生命周期（近、中、远）取决于此。
【方式2】虚看，确认画的布局与脉络（关键主线）。
1．画家在远距离观察时，画家会有意识地眯起眼睛观察画，由于眯眼后进入到眼睛里的光线就会减少，画的细节部分和灰暗色部分的内容就被过滤掉了，过滤掉细节和灰色部分后就容易地观察到画的布局重点、主要脉络（用行话说，就是由画中高光的部分形成的点、线、面）。
2．软件工程师在处理复杂问题时，如果全程都是“睁大眼睛看”，就有可能将非重点或至少在分析的初期不是重点的问题放大，把所有大小的问题都同等看待，这样做的结果反而是看不到要突出的重点，甚至因为经验不足、客户强势的原因造成了过度解释次要问题，从而造成讨论的跑题，甚至出现方向性的错误。最终系统的主线、逻辑、重点、协同等取决于此。
【方式3】近看，走进对象看细节（局部表现）。
1．画家研究细节的时候才走到离画布足够近的地方，观察画的各个细节部分的表现是否到位。
2．软件工程师在分析对象的细节（界面、字段、规则、算式、数据等）时，要做深入的了解、咨询、分析、验证等工作。最终系统的成败决定于细节，但此话只有在方向、主线等全正确的前提下才能成立。
“绘画式地看问题”的观察方式在解决问题时起什么作用呢？运用上述三个观察方式，检查一下你在做分析时的观察方式是否正确。假定有一个软件项目需要进行分析。
1．首先，掌握全局项目分析的初始，首先要把握全局，找到目标、主线、重点等。检查：
● 你是否与客户之间保持了一定的“距离”？这个距离可以让你冷静、全面地进行观察。
● 你是否尚未了解全局就已进入了对细节的争论？这是造成讨论无果、偏题的重要原因。
2．其次，把握脉络在项目进入讨论前期，一定要明确项目里面重点之间的位置、关系（脉络），检查：
● 你是否时刻都清楚你讨论的题目以及要达到的目标是什么？
● 你是否把握住达成目标有多少个重点？是否找到了这些重点构成的脉络、主线？
3．最后，熟悉细节在对核心部分进行分析的阶段，要精确地给出业务逻辑、算法、规则，检查：
● 在理解业务的核心部分时，你是否有能力进行收集业务需求的细节？
● 对细节的描绘是否专业？是否能做到严谨、精细、标准、没有遗漏？
如同画家一样，软件工程师在观察问题的过程中，不要始终睁大眼睛看，要学会在某个阶段有意识地漏掉一些暂时不重要的内容，只有这样才能抓问题的重点。这一点非常重要，有一些经验的人往往由于对已经看到的内容“割舍不下”，将重要与暂时不重要的问题同时提起，这样容易造成沟通效率低、跑题，甚至结果不收敛的问题。软件工程师要学会和理解一个非常重要的概念：不重要≠不必要！很多在详细设计期的非常重要的细节，在分析初期并不重要。在分析需求、建立概念架构阶段，能够做到“适当忽略细节、突出重点”的是高手行为，初期就做得面面俱到的反而是新手行为。
A.1.2 多角度看问题
第二种方法称为：多角度看问题。两个人因为某个对象的特征进行激烈争论，各自都说从自己的角度看到的对象是正确的，但是如果能够换个角度看，可能双方就可以理解对方坚持的理由，所以在争论某个事情时，如果双方都认为“这么简单的问题你还不明白吗”时，一定要快速地意识到可能就是发生了站在不同视角观看同一个对象的情况。
在做某个项目需求分析时，可能客户会召集数个部门的负责人进行说明，由于不同部门有着不同的视角，对同一问题的描述不尽相同，为了获得客户的真实需求，就应该站在不同的角度提出问题、分析问题，确认每一个说法的背后可能存在着什么。例如：
（1）不同层级：针对同一个目标，用企业不同层级（决策层、管理层、执行层）的关注视角，对目标进行交叉对比，以检验是否一致。
（2）不同部门：针对同一目标，用企业同一层（如管理层）的不同部门负责人的关注视角，对目标进行交叉对比，以检验是否一致。
（3）不同岗位：针对同一目标，用同一部门的不同岗位的关注视角，对目标进行交叉对比，以检验是否一致。
【案例1】视角不同，发现问题的原因。
在很多的咨询场合，问题的原因（why）是藏在表象（what）的后面，如果调研人员只是从正面提出问题，“你在干什么？你怎么干的？（what）”，忽视了从反面提出问题“你为什么这样干？（why）”，这样的结果就可能遗漏重大的需求。
（1）调研人员从正面提问题“你在干什么？怎么干的？”回答者一般都会将自己所做的事情按照自己的视角讲一遍，往往不容易暴露出问题（因为他做这个事情已经习以为常了）。
（2）调研人员从侧面提问题“为什么这样干？”从这个视角看问题，可能的结果是：回答不出来，或是回答中牵出来很多不确定的问题，而这些恰恰是可能隐藏了问题的真相和解决问题的钥匙，这些不确定如果不解决有可能成为软件验收时的定时炸弹！
【案例2】视角不同，找到的要素不同。
软件工程师与客户站在“软件窗口”的两侧（软件窗口=界面），看到的内容不同。
（1）从客户业务的视角看“软件窗口（正面）”。不同行业、企业、部门、岗位会使用不同的软件功能，因此从客户业务的视角看软件，会有无数的功能。
（2）从软件实现的视角看“软件窗口（背面）”。
软件系统的构成是与业务无关的，它是通过用有限控件来组合出可以覆盖无限多的业务，因为不论是什么业务，在系统构成的视角看都是一样的。因此，观察对象时的视角变化会极大地影响你的分析结论和呈现的结果。换角度看问题说起来容易做起来难，因为要掌握“换角度”的能力，要知道换到哪个角度去看问题。
A.1.3 系统地看问题
第三种方法称为：系统地看问题。系统地看问题的基本思路可以用骨科检查的一个例子说明：病人因为腰痛走不了路到医院来看医生，但是医生诊断的结果是：问题不是出在腰上，而是膝盖出了问题造成的腰部疼痛。这个例子说明，我们在需求调研、需求分析或是设计时，对难解的问题一定要能够系统地去看待，从而找出造成问题的真正原因。
先做观察和思考，然后再与经验匹配
理论和方法掌握的不多，但是经验比较丰富的人，在看问题时的思维比较固化，在碰到新的或是复杂的课题时，首先不是用眼、脑去观察和思考，而是习惯性地先从自己的经验中找对标物，去匹配哪些内容与自己做过的项目相符。遇到新问题时，建议不要马上就与经验进行匹配，而是要利用你的眼睛和大脑进行观察和思考。此时，
（1）你的眼睛要具有“调整光圈”的能力，可以全看清楚（光的射入量最大），也可以虚掉一下不重要的细节，找到核心。
（2）通过变换不同的角度，看到客户所说事物的不同面。
（3）思考what（表面）和why（原因、动力）的关系。
对收集到的这些信息进行整理，并找出对象的核心、脉络、主线，这些都清楚了，再与自己的经验库进行匹配。要注意：经验与知识不同，经验的复制首先要确认两者的背景环境是否一致，只有背景环境一致才有可能复制成功。
A.2 软件设计师的三字经
在前面软件工程的不同阶段中讲到了各类不同的方法，这里将讲过的内容总结概括为三个字：拆、组、挂。这三个字就是对需求工程与设计工程中讲到的核心理念的抽提，也是本书对软件工程师技能的概括。
A.2.1 拆：理解对象的钥匙
需求工程中的核心工作是对需求进行分析，得出系统需要的功能。从收集原始需求到确定要实现的功能需求，这之间对原始需求进行了多次的拆分，通过不断地拆分、转换最终找到了符合进行信息化建设的要素。“拆”的能力不仅限于需求工程，它在软件工程的各阶段都适用。
（1）基础原理：分离原理（业务、管理、…）、组合原理（要素、逻辑、模型），基干原理（组件、机制）、知识体系（业务、设计、技术）等。
（2）软件工程：工程构成（需求、设计、开发、测试、运维）、工程分解（概要、详细、应用）、工作分解（架构、功能、数据）等。
（3）需求工程：企业构成（业务、管理、组织、物品）、需求分类（目标、业务、功能）、记录方式（现状构成、访谈记录、既存表单）等。
（4）设计工程：功能分类（活动、字典、看板、表单）、业务组件（窗体、窗口、界面、控件）、业务逻辑（关联、位置、包含）、数据逻辑（键、表、式）、数据分类（过程、基础、管理、加工）等。
上述软件工程中所有的“分类”就是对拆分后要素的归集，同一分类中的内容具有共性，处理的方法有规律。可以说，“拆”分水平的高低是判断一个软件工程师能力的最基本参考，因为解决任何复杂问题的开始都是做分析，分析的第一道工序就是理解问题，而理解问题的最佳方法就是先将复杂问题拆开，只有将问题拆开才能看到问题的构成。拆分的目的就是将大型的、复杂的对象拆分为小的要素，例如按照个性与共性的不同进行分离。这种做法就如同是将处在黑盒状态的问题转换成为白盒状态，让内部的关联暴露出来一样，逐一地对小的、单一的要素进行研究则问题的复杂性就大为降低了，这就是常说的“化繁为简”。遇到简单的问题用简单的方法解决，遇到复杂的问题先化解为简单的问题，然后再用简单的方法去解决（这样就没有复杂问题了）。
这里需要注意的是，有一些经验丰富的软件工程师，他们没有掌握这个思想，由于他遇到的场景多，所以常常会犯“越分析结果越复杂”的错误，因为遇到复杂问题时他的反应是找出已有的全部经验去对接、解释，这样做出的结果往往会非常复杂。也有一些经验丰富的人会将“复杂”的结果表现形式理解为是经验多的象征，这样的解决方法会给后续的设计工作带来麻烦。分离原理，给出了如何“拆”、拆成什么内容的理论、方法和标准。
A.2.2 组：表达业务的手法
业务设计部分的核心工作是对业务进行设计，给出优化、完善的业务处理形式，从功能需求到完美的业务处理形式，这中间进行了多次的“组合”，通过不同形式的组合最终将散乱的需求形成了业务架构、功能和数据层面的标准设计。在业务设计中使用到了大量的组合方式。
（1）架构：业务架构（框架、分解、流程）等。
（2）功能：关联图（区、线、点）、记录4件套（原型、定义、规则、逻辑）等。
（3）数据：数据规划（整体、领域、功能）等。
这里为什么使用这个“组”字呢？因为这里倡导的是工程化的设计方式、工业化的生产方式，最终完成的系统是否能够实现这个目标首先在业务阶段就要进行解耦的设计，完成解耦后的要素通过逻辑关系“组”合起来，形成了业务处理的体系。既然是“组”合起来的，那么就可以在需求发生变化时将它们分开，再进行另外形式的组合。例如，对架构层的内容进行分层、分区、分段的架构，对功能层的界面内的要素进行组合、对数据层的数据表进行关联等，都是“组”的行为，业务设计的“组”，为后续实现系统的复用、共享、灵活应变奠定了基础。组合原理，给出了用什么“组”，怎么组的理论、方法和标准。
A.2.3 挂：随需应变的机关
业务设计得完美，同时对系统的实现也必须同样完美，只有如此才能最大限度地体现出信息化管理的价值。信息化管理的最大价值之一就是系统具有“可以复用、随需应变”的能力。这里的“挂”是指将构成系统的要素用“挂接”的方式进行关联，例如，既然是可以“挂接”当然就没有“锁死”在一起，这样就具有了应变的基础。信息系统在设计时要充分地考虑未来在运行中的应变性、复用性，这些指标关系着系统使用的生命周期，应变性强的系统就“活得长”，要想系统支持应变就要进行松耦合的设计，但是如果对满足松耦合设计的成果在开发时用编码做成了固化的系统，那么前面松耦合设计的努力就白费了。因此在应用设计时就要尽量地将构成系统的要素设计成可以独立存在的“零件”，将零件之间的连接设计成一个可以支持挂接的“机制”，利用这个“机制”将“零件”挂接起来，形成一个可以拆、挂的系统连接方式，即“组件+机制”的方式。注：关于应用设计的必要知识这个设计需要业务设技术两方面的设计知识，它不是一个单纯的技术设计问题。基干原理，给出了用什么“挂”，怎么挂的理论、方法和标准。
好产品的标准：应变能力强
完成的系统要具有两个应变能力：随需应变，随时应变。
（1）随需应变：当需求发生变化时，系统可以在不大拆大改的前提下进行改动。
（2）随时应变：需求发生变化时，可以快速地在短时间内完成需求改动。具有“随需应变、随时应变”这两个能力的产品就是好产品。因为对客户的业务来说，“变是常态，不变是暂时的”，因此每个软件设计师都要确立这样的信念，具有长生命周期的系统，应变能力是第一重要的，因此，“三字经：拆、组、挂”要从需求分析开始，直至完成开发，始终要牢记在脑中。
A.3 空间能力的训练
未来信息化系统的发展都是朝着可视化、可触摸操作的方向发展的，但是现在从事企业信息化的分析与设计者大多数还是停留在二维表达、二维思考的水平上，有的甚至还是一维表达和一维的思考水平上，这与现在企业管理信息化所面对的业务处理的复杂性、软件硬件技术的发展速度、客户的需求等都是不匹配的，简单的一维、二维方式都不足以完成从思考、分析、设计和表达出结果的要求。
A.3.1 在大脑中建立图形
在交流讨论时，参与的双方可以做到一边听着对手的说明一边同时在自己的脑中将“语言”转换成“图形”。反之，在自己向对方进行说明时先在脑中形成一个“图形”，然后带有“画面感”地向对方进行说明。如果双方都可以在接收到对方的信息后在脑中形成图形，那么就说明图形取得了明显的效果。
A.3.2 三维空间的概念
企业管理信息化发展到了今天，软件工程师遇到的问题越来越多、越来越复杂，系统构成的要素越来越广泛，这就需要软件工程师观察、思考、表达的维度要增加到三维（最低），否则就难以表达出分析和设计的含义。三维表达可以提升软件工程师“大视角、大思考、大架构”的能力。
（1）美术知识：如绘画、雕塑等→提升观察、表达的能力。
（2）建筑知识：如平立剖、结构图等→提升空间、整体、架构的能力。
（3）机械知识：如机械原理、三视图等→提升机制、复用等的理解能力。
A.3.3 三维绘画：建立空间感
虽然三维图形有很多的好处，但是毕竟随着维数的增加，绘图的难度也随着增加。设计师在二维的平面（纸张、计算机屏幕）上绘制一维、二维的图形是没有问题的，但是三维空间的利用有三种场合：语言、思考、图形。
（1）语言：用语言进行描绘，让听者感受到三维的空间。
（2）思考：思考时在大脑中形成三维空间，可以看到“虚拟事物”的不同层面。
（3）图形：利用三维图形，表达三维的信息。可以看出，在这三种表达场合中图形是相对简单的，最难的表达是第一种的语言表达。可以这样说，判断一名高级软件设计师的表达能力，图形的三维表达是基础要求。
1．图形的三维空间
先从最简单的三维图形开始训练，绘制三维图形需要分三步完成，下面以绘制架构用模型中的“分层图”为例进行绘制的说明。
1）第一步，建立三维坐标X轴：为一条水平线；Y轴：为一条垂直线；Z轴：为一条45°斜线。
2）第二步：画出立方体连接这三条坐标线的端点，使之形成一个虚拟的立方体空间。
3）第三步：绘制三维图形在这个空间中绘制分层图中的各个“层”，分层图上所有的线条都必须与某个坐标轴线是平行的，如“管理板块”这个层。边①要与X轴平行；边②要与Z轴平行。如果是绘制简单的立方体图形，基本就是画与三维坐标平行的线条即可完成，当然熟练之后是不需要每次都画坐标轴的。
2．思考的三维空间
思考与图形的表达有关联性，在大脑中先打下草稿再画出来、还是先画出来再思考因人而异。有了绘制图形三维图的方法后，思考的三维空间实际上就是在大脑中绘制虚拟的立方体和思考对象。思考的三维空间训练可以先闭上眼睛，在大脑中想象出一个“正方体”的空间，方法如同绘制图形一样。第一步：在大脑中开拓一个“空间”。第二步：在这个空间里，建立三维坐标、立方体。第三步：想象出思考对象的三维模型，置于立方体的中间。第四步：在立方体中的空间里让模型旋转，进行观察、思考、分析。
A.3.4 三维思考的意义
构建复杂的企业管理信息系统，要对业务进行调研、分析、架构、设计等一系列的工作，拆分的要素越多、业务的逻辑越复杂、需要考虑的维度越多，梳理和表达的形式就变得非常重要了。很多复杂的问题不是两个要素之间的简单关联，可能是n个要素的交叉关联，多个系统的交叉关联，因此二维的形式也不足以表达，这时候三维表达的形式就显得非常有效了。软件工程中建立了“点、线、面、体”等的基本概念，进行三维的“空间”思考和设计打下了基础。
三维思考是进行大型、复杂系统的分析与设计时做的“能力储备”，在某种意义上也是一种“赋能”。因为具有三维空间的思考和表达能力的人，要比只具有一维、二维能力的人在理解和解决复杂问题时的水平高出很多。是不是经常听别人说过这句话：“太复杂了，我的脑子都不够使了”，可以理解为他只能理解一维或是二维的复杂问题，因为过于复杂的问题在他脑子中就无法进行建模了。关于三维，再看看其他的行业，如建筑业、制造业等都是三维表达。有人说：因为他们是具象的、复杂的，同时在现实中就是处在三维空间里。未来企业向着数值化、信息化的方向发展，大量的软件、硬件都会融合到一张图上来，研究对象的构成会变得越来越复杂，因此需要软件工程师的思维和表达也越来越复杂，如果没有三维的概念，就很难理解和表达这些要素的关系了。
A.4 思考与未来
企业管理类系统经常会提到要做到复用、共享等要求，从发展的趋势看，未来传统上的各种企业管理系统分类的边界会消失，同时信息系统本身也会向着智能化的方向发展。
A.4.1 管理系统边界的消失
企业正在逐渐走向信息化、数字化，由于采用了软件平台、数据平台等概念，使得各类软件系统可以互联互通，又由于硬件技术的进步，客户端从PC发展到各类移动终端，各类的公有云和企业的私有云使得所有的软件、硬件、数据都可以无限制地自由连接、流动。软件应用SaaS化，以及应用功能的碎片化的概念，都让传统的大而全的解决方案的理念、软件产品按照业务处理内容划分的概念改变了。也就是说，未来考虑需要什么数据、采用什么样功能时不必考虑它们是属于什么产品或是系统，软件与软件、软件与硬件、硬件与硬件之间都可以通过数据的交互实现联通，在企业构建的信息平台之上，只要符合标准就可以自由地增加功能、共享数据。
在这样的变化过程中，从事业务分析和设计的软件工程师们需要有怎样的变化呢？上述变化对分析和设计方面带来的影响，从本质上看就是一个字“活”，就是要灵活，这个“活”就体现在软件最终要做的像制造业和建筑业一样：实现构件化。只要软件从业务分析、设计、实现的过程中都可以做到真正意义上的构件化，做出来的软件就可以满足上述变化的需要。反过来再回顾一下本书的内容，从始至终强调以下几个关键词。
1．设计的工程化
所谓的设计工程化，就是采用工程化的设计方式，所有的设计都要结构化、图形化、标准化，要做到可以精确地传递和继承，例如，对设计分阶段（概要、详细、应用）和分层（架构、功能、数据）形成结构，对功能划分与定义，以及功能规格书的标准化记录格式等。工程化的设计方式，也为设计资料提供了可以复用的基础。
2．开发的工业化
所谓的开发工业化就如同工业制造一样，将产品分为不同粒度的零件，然后通过零件的组合形成不同规格的产品，例如，业务功能是由字段和规则构成，组件是由控件构成，“组件+机制”可以构成系统等。这些理念和方法都是为了实现后续开发的工业化而做的准备，反之，如果不在非技术设计阶段推进这些做法，到了技术实现阶段再考虑就晚了。工程化的设计方式与工业化的开发方式，为产品和功能提供了可以复用的基础。到了软件实现的环节，不论什么业务对象，甚至可以说企业管理软件和物联网软件从软件构件的视角来看是没有什么根本的区别的。
A.4.2 企业管理智能化
“智能化”的实现需要信息技术，由于信息技术的进步，智能化一词在很多领域被广泛地使用，并且都在不同程度上进行了推进。但是目前在企业管理方面的进展尚不明显，已经导入了信息系统的企业中还有很大一部分仅仅是“手工替代”的水平，即：将手工作业换成了“电子化作业”，实现的数据的汇总，即使是比较先进的企业也还远未达到智能化管理。
从软件工程的构成上看，实现企业管理智能化的重点是在应用设计阶段所做的工作，应用设计是将优化后的业务设计成果与计算机技术相结合的部位，因此，强化对应用设计的研究是实现管理智能化的基础。
小结
从方法论的视角对软件工程的内容进行了归集和提升，从企业管理信息化的发展未来看，需要从事业务分析和设计的软件工程师，特别是担当顶层设计、总规划和架构的负责人，更需要掌握观察、思考的方法，有了“观察、思考和表达”三个手段后，就可能实现“将复杂问题拆分为简单的问题，并从简单的问题中抽提出规律，从而找出可以解决复杂问题的普遍方法”（参见分离原理、组合原理和基干原理，它们的构成很简单，对应的方法也不难）。对业务部分的分析与设计，难点在于总是在与未知的人交流未知的问题，找出以前没有使用过的解决方案，它的乐趣也在于总是要用“创新”的方法解决难点，为客户带来价值。对业务部分的分析与设计，在软件工程中是将繁杂的客户需求梳理归集到可以进行软件开发的重要工作，而且是对这个过程由不特定到特定的收敛作用最大的部分，现实中的业务种类、形态非常多，不可能全用一种模式完美地解决掉，因此就需要软件设计师掌握更多的跨界知识、方法，它既是业务部分分析与设计的难处，同时也是乐趣之所在。
