软件需求实践笔记

总括

一、项目管理非常重要，但是项目管理人才极为缺乏
二、美国已经从较低级的软件实现摆脱出来，进入了设计和营销的境界（掌握产品生产的重点）；
三、美国将软件外包给印度，硬件外包给台湾。而中国的硬件也在崛起，但是在软件行业，中国和其他国家的差距太大了，    

且不说在软件行业中处于核心地位的操作系统、数据库。即便是应用软件，中国的软件水平也实在低的可怜。
四、不同于现在企业推崇的各种管理思想，软件企业的管理思想主要是针对项目的管理，确保项目的成功。


项目需求

一、通常的项目管理角色包括：项目经理、项目复审员、变更控制经理、企业流程分析师、业务模型设计师、需求分析员、

需求复审员、系统分析员…在一个成功的项目里，多种角色职责明确，分工合作，共同完成项目的设计实施。
二、RUP（Rational Unified Process 瑞理统一过程，本文采用了众多的RUP的思想）把一个项目分成10个核心工作流程

（Core Workflows）和4个阶段（Phases）。
三、在先启阶段，需求是重中之中，包括了RUP的工作流程中的业务建模、需求、一部分的分析、测试计划、配置和变更管

理


需求是根本
以下是需求过程不科学的典型例子：
　　1.开发人员在用户处呆了两三天就埋头开发；
　　2.用户告诉开发人员我要开发一个XX系统，但是我很忙，你先开发一个让我看看；
上面的这两种态度都意味着项目的不成功，应该说上面的开发人员和用户都应该对此负责。
需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。当然，由于用户不是专业人士，开发者有权

利告诉用户应该采用何种态度来对待项目的需求。


需求是变化的
没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上

既然需求都是不稳定的，那么何以建立起稳定的企业信息系统呢？

要回答这个问题，首先要比较面向过程和面向对象的开发方法的差别，
面向对象就是面向世界，世界上的任何事物都是对象，因此面向对象是很自然的思想，是符合我们的思维习惯的。

需求是不稳定的，那么需求之中是不是没有稳定的东西呢？有的，就是对象。

面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。

这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种

开发的方法就被称为OOAD（Object Orient Analysis & Design 面向对象的分析和设计），而分析出的企业对象就被称为

Common Business Object。

在RUP中定义了需求工作流程的工作目的：
　　1.客户和其他涉众*在系统的工作内容方面达成并保持一致。
　　2.使系统开发人员能够更清楚地了解系统需求。
　　3.定义系统边界（限定）。
　　4.为计划迭代的技术内容提供基础。
　　5.为估算开发系统所需成本和时间提供基础。
　　6.定义系统的用户界面，重点是用户的需要和目标。
　　* 涉众：涉众是所有会受到项目结果重大影响的人。如客户（或客户代表） 用户（或用户代表） 、投资者 、股东 、

生产经理 、买方 、设计员 、测试员 、文档编写员等


用简单的话来说明需求过程，就是确定系统该做些什么以及该符合什么条件。

科学的需求过程有一整套完整的理论、工具、方法来实现。就像任何企业要盈利都必须要有业务和伴随业务的管理一样，需

求过程也分为需求分析过程和需求管理过程。

业要保证业务的开展就必须要有管理，而需求分析过程也同样离不开需求管理。

对于大型的项目，管理的不足就会暴露出来，而直接的后果就是项目的失败。

很多人认为需求管理的目的是为了控制需求过程，这是没有错，但是在RUP的思想中，更重要的思想是迭代*。迭代的目的是

为了发展，为了进化，为了完善。所以RUP中的软件生命周期是分为多个迭代周期的。 * 迭代：迭代包括产生产品发布（稳

定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素

发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作

流程。


需求分析过程主要做的事情无非就是获取涉众对系统的要求，可是需求是多变的，而你不可能告诉客户等到他们把一切都固

定下来再开发软件。所以需求管理过程做的事情就是保证需求变更的可管理性。


《软件需求》一书中有对需求层次的详细定义：
　　软件需求包括三个不同的层次-- 业务需求、用户需求和功能需求--也包括非功能需求。业务需求（business

requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求

(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario

）说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务

，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。


    对应到RUP的工作流程，业务需求其实是RUP的业务建模流程（Business Modeling），在这个流程中，参与者主要是业

务流程分析员（Business-Process Analyst）。主要的目的是对企业目前的业务流程进行评估，并根据要进行的项目，确定

进行何种程度的业务建模（你要做一个ERP项目就意味着你必须优化业务流程，而上一个部门级MIS项目就没有必要用牛刀了

）。然后你会得到一个叫做业务前景（Business Vision）的东西，其实就是项目成功后会是个什么样子，并在涉众范围内

达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，

业务需求就是需求过程的宪法，任何需求不得与之相违背。
　　
    到了用户需求层次上（RUP的需求工作流程），重心就转移到如何收集用户的需求上，即确定角色和角色的用例，需求

分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。一般来说，在过去作需求分析

的时候，更多依靠的是阅读企业的文件，但是企业的文件往往有局限性，例如落后于当前的业务，不够明确，依赖于管理水

平的高低，所以后来获取需求的方法逐渐倾向组织访谈会（Interview）。
　　

    功能需求依赖于用户需求，可以说是用户需求在系统上的一个映射（Mapping）。开发者思考的角度从用户转移到开发

者。在这个层次上，为用户做一个软件原型是一个很不错的主意。直到现在，用户对软件还是没有一个实实在在的概念，如

果你给用户一个原型，用户就会说，"哦，我的XX系统原来就是这样的。"这就避免了用户在软件开发完成后才看到软件所带

来的一些风险。是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，很多时候，用一些非正规的方

法来生成原型：如果你要开发一个WEB系统，让你的美工做几个页面给用户看看，如果你做一个C/S系统，做一个界面给用户

，都已经足够用了，甚至你完全可以在黑板上画一画你将来的软件的面貌都可以。用户大都是比较友善的，不要把问题想的

过于复杂。


需求标准

明确(Clear)、完整 (Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪、可修改等等。

除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机

的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
　　打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属

于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。
　　完整：再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想

象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题

，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程

的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。
　　一致：一致性也是一个比较大的概念，很难用几句话讲清楚。简单的来说，就是用户需求必须和业务需求一致，功能需

求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目

标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。
　　可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进

行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划

的输入和参照。这就要求需求分析是可测试的。什么是可测试呢?quot;我们要用新的系统完成报表自动化处理"，你觉得这

个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无

法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事

实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。






软件和需求的实践（2）

质量检测逐渐倾向于生产过程，在过程中监测产品质量。这种方法比起前一种方法进步了很多，但是它需要对生产全过程进

行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。

软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。


需求过程

需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理

需求分析的这个过程，我们可以称它为需求工程


需求过程和CMM

软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一

种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。（更详

细的定义和说明请参看《CMM白皮书》）。

需求开发的内容

需求过程和软件生命周期模型

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进

入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布

（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是

一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实

质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可

以发布的产品，这个产品是最终产品的一个子集。

快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就

解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只

是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先

对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原

型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大

的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内



RUP和XP
　　RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想

集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心

工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分

到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以

RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那

样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。



XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent

Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的

成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈

（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众

多的方法来支持软件开发。


制定了大量的规则的RUP方法被称为重量级（Heavyweight）的方法，而像XP这样只制定少量的规则来规范行为的方法被称为

轻量级（Lightweight）的方法（实际上，现在有一种倾向称这种方法为Agile方法的）。近来，也看到一些文章在讨论两种

方法孰优孰劣。例如：XP兴起，RUP不适合中国国情等。我想，这和以前大家讨论C++和Java谁好的性质是一样的。方法都有

两面性，只有最适合的方法，没有最好的方法。我在实践中也感觉到，国外的理论确实不能照搬于中国，毕竟中国人的人文

环境和国外相差太大了。不过，RUP不适合的，我想，XP也未必会适合。如果说，有人把RUP的一整套东西生搬硬套，导致了

最后项目失败的结果的话。这种行为无异于刻舟求剑。

在我看来，RUP就像是一个软件工程思想和方法的大百科全书。在其中，你可以看到诸子百家的论调，可以了解软件工程的

整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁，你可以想想，那是一

种什么景象。XP，更强调团队的充分交流，最大限度的发挥人的创造力。它并不制定大量的规则来限制人的行动（必要的规

范是必须遵守的），开发的团队中的每一个人都能自由的发挥想象力，毕竟，软件是创造性的劳动（这听起来像是共产主义

实现了一般）。至少，国内的公司都应该学习XP的一条规则：一周只工作40小时。相比较之下，RUP比较适合大企业、大项

目，因为大的团队往往需要法制；XP适合于小团队，比较能够发挥小团队的创造力。但是在实际中，也有例外的情况。例如

XP 方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。

需求的实践（3）
Customer Oriented，而不是Program Oriented

1. UML
UML（统一建模语言，Unified Modeling Language）是一种面向对象的建模语言。在软件工业化方面做出了杰出的贡献。被

OMG（Object Management Group）采纳为业界标准。
UML就是解决上面这个问题的一个相当有代表性的例子。UML的实质，就是一种沟通方法，就象是英语能够解决把世界各地的

人交流的问题一样。

1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和OMT-2 统一起来，并于1995年10月

发布了第一个公开版本，称之为统一方法UM 0.8（Un ified Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这

一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML

0.91，

着重强调的是一种标准的建模思想，但它并不是一种标准建模过程

UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了结构（Structural）模型和行

为（Behavioral）模型。结构模型（又称为静态模型）强调系统的对象结构，如对象的类（Classes）、接口（Interfaces

）、属性（Attributes）和关系（Relations）；行为模型（动态模型）关注的是系统对象的行为动作，如对象的方法

（Methods）、交互（Interactions）、协作（Collaborations）和状态（State Histories）。以此为基础，UML为UML表示

符提供了完整的语义定义。UML的表示符包括了下面的几种主要的图：类图（Class Diagram），用例图（Use Case Diagram

），顺序图（Sequence Diagram），协作图（Collaboration Diagram），状态图（State Diagram），活动图（Activity

Diagram），部署图（Deployment Diagram）语义由于我们的讨论重点并不是UML语言，我们只是简单的介绍UML的实际应用

，如果大家对UML有兴趣，可以参看《UML1.3白皮书》。


迭代式需求分析

软件工程不断的向前发展，其中的一些新兴的方法论中的佼佼者就是XP。（关于XP的介绍请参看我的上一篇文章）。XP对需

求的影响在于：开发方和客户方已经不再是客户关系，而是战略合作关系。客户将作为领域专家参加整个开发过程，并提供

现场（on-site）指导。
XP 大概的流程是：领域专家组（包括开发方和客户方）将会提出需要开发的功能，体现为素材卡片（Story Card）。项目

经理配合将素材卡片分配到每个迭代周期。各个素材卡片都会有一个小型的开发团队（由分析人员、开发人员、品保人员组

成）来负责。每次迭代周期都会得到一个可发布、可供客户使用的产品。通过把整个项目划分为多个迭代周期，可以：
较短的迭代周期容易预测，资源分配计划可以做的非常细致；
给客户提供了一种实际使用的感觉，并且客户可以通过实际使用发现自己潜在的需求，提交需求，在随后的迭代周期中安排

实现；
不断的有最终产品推出，团队能够保持较高的士气；
不同的小组可以同时处于不同的迭代周期中，降低了传统开发方法中常常出现瓶颈的风险；
不可否认，XP作为新生代的方法，有它的优势所在。可是要指出的是，在中国，能够采用XP方法企业可以说是屈指可数。这

个问题大家经常都可以看到评论，这里就不罗嗦了。不过，有一种开发环境，还是有天然的使用XP方法的优势的。就是内部

开发。例如很多的大型企业、银行、事业单位都有自己的软件开发部门。这种和客户关系特别亲密，使用XP方法就有他的优

势。只是，目前影响这种开发方式的主要原因，却是在体制上的。

需求的实践（4）
业务建模时期（上）



1. 业务建模是什么
业务建模（Business Modeling），业务建模是一个复杂的过程，对其下一个准确的定义是困难的事情。在RUP的词汇表中将

其解释为：
"包含您可用来对业务进行可视化建模的所有建模方法。这些是您可用于执行业务工程的方法的子集。"
从定义中可以看出，它是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务

组织建模，改进业务流程，领域建模等方面。

随着企业的发展，就会发现企业需要变化以适应市场变化，业务发展的时候，原有的一系列应用系统却成了企业发展的拦路

虎，这使得企业不得不回到手工的时代。
针对这种情况，有没有相应的解决之道呢？解决的方法就是从业务建模入手，而不是从较低层次（部门级或以下）入手。通

过用例分析技术，建立企业的业务模型，进行适当的切割，选取稳定的软件架构，分析出企业的业务实体（Business

Entity 企业中微小不可分的事物，抽象或具体的，如帐户，契约等，又被称为Business Object），以此为基础，组装出组

件（Component），落实到相应的三层结构，建立针对特定功能区域的应用系统。


3. 需求和业务建模


业务建模是需求工程中最初始的阶段，也是整个项目的初始阶段。需要指出的是，业务建模时间的跨度在不同的项目中有很

大的差别的。在有些项目中，例如大型ERP系统，可能需要几个月的时间。而对于普通的项目，业务建模的时间可能仅仅需

要几天的时间。

①不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来，然后再回到业务建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉众是所有会受到项目结果重大影响的人。


4. 业务建模时期的主要任务
项目涉众的共同愿景：要想项目成功，可离不开项目涉众的支持。在项目一开始，不论是项目涉众还是开发人员，对项目的

任务、范围都是模糊不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必

要在项目射入之前，现在项目涉众中竖立一个共同的愿景。


共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都

列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致的时候为止。在共同远景的竖立过程中，其实有两件事情

也已经同时做了，项目范围（scope）和高阶（high-level）需求。

DFD图比较容易为客户所接受。

高阶需求：这个部分我们在下面会详细讨论。既然是高阶需求，就不能讨论过多的细节。在讨论高阶需求的时候，尽量保证

快速的讨论出系统的概貌，建立需求模型，得到项目涉众的一致通过。
取得支持：为了保证需求计划的顺利进行，取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利

和义务，以及开发人员的权利和义务。在这个方面，具体的我不想多说，大家可以参考『软件需求』的第二章。主要的就是

"涉众有改变需求的权利，同时要承担向开发人员讲解需求的义务。"开发人员的权利和义务正好和涉众相反。
业务建模会议：所有的这一切都通过业务建模会议进行，和其它会议不同的是，这个会议需要所有的项目涉众参加，如果不

能获取所有项目涉众的意见，那就不是完美的。会议中最重要的工具就是白板，一位出色的速记员也是必须的。


建模原理

5. 业务建模中的用例
业务用例以及业务用例实例在RUP中的定义如下：
A business use-case instance is a sequence of actions performed in a business that produces a result of

observable value to an individual actor of the business. A business use case defines a set of business use-

case instances. A business use case has a name.
业务用例实例是在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。

业务用例
业务角色和业务主角的概念也很容易让人摸不着头脑。其实看它们的英文愿意会更容易理解它们的区别：Business Worker

，Business Actor。Worker有工人的意思，而Actor有参与者的意思。所以它们的区别就是一个在内部，一个在外部。业务

角色是实现业务用例的人，业务主角是和业务有关的人。例如，对银行的押汇业务而言，客户就是业务主角，他和业务有关

。而押汇人员就是业务角色，因为他们是实现业务用例的人。在RUP中，二者定义如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other

workers and manipulates business entities while participating in business use-case realizations.
业务角色代表业务中的一个或一组角色。参与业务用例实现时，一个业务角色和其他角色进行交互，并操纵业务实体
A business actor represents a role played in relation to the business by someone or something in the

business environment.
业务主角代表了与业务有关的角色，此角色由业务环境中的某个人或物来担任。

业务实体，在一些文章中被称为商业对象（Business Object）。
在RUP中，业务实体被定义为：
A business entity represents a "thing" handled or used by business workers.
业务实体代表业务角色处理或使用的"事物"。





6. 建立业务用例模型
业务用例模型（business use-case model），在RUP中定义为：
The business use-case model is a model of the business intended functions. The business use-case model is

used as an essential input to identify roles and deliverables in the organization.
业务用例模型是说明业务预期功能的模型。作为一个核心输入模型，业务用例模型用于确定组织的各个角色和可交付工件。



从业务用例模型的定义可以看出，它是企业最核心，最概括的业务说明。它主要是由业务用例和业务主角构成的，其主要目

的是说明客户和合作伙伴是如何开展业务的，它描述业务的主要方式是通过业务用例的方式。

②业务规则（Business Rules）：业务规则是必须遵守的政策或条件的声明。（Business Rules are declarations of

policy or conditions that must be satisfied.）

业务用例模型是和企业业务最贴近的计算机模型。它的很多思想和企业日常经营如出一辙。在企业的日常活动中，业务的种

类可能有很多种。在一些讲述ERP思想的文章中，通常会强调三类：
一种是和主营业务密切相关的工作，例如银行的营业部、信贷部、押汇部等。这种工作通过人的劳动，将一种资源转变为另

一种资源，产生价值。
一种是管理型的工作，例如公司的管理层，财务部门等。这种工作本身并不产生价值，但是它通过指导、管理、检测第一种

工作，加大第一种工作的产出价值。
还有一种称为支持工作，例如系统管理、安全等。它并不是很重要，具有支持其他工作的性质。

有很多业务用例是由业务主角触发的，RUP中也把和业务主角有关联关系的业务用例称为核心业务用例（Core Business Use

Case）。这强调了构建业务模型的目的是为了提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。



7. 在业务建模中使用关系
泛化关系（Generalization）：根据我的理解，可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization

一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似，但是它们在使用环境和产生目的方面

都有相异之处。


8. 方法的选择
以上的原理我采用了UP的方法。但是除了UP方法，还有XP、FDD等方法。所以在做业务建模的时候，也要根据不同的方法选

择适当的工件。
待续……