SEUNIT需求工建

1、Unit 3Unit 3软件工程基础软件工程基础冯耀霖冯耀霖主题主题需求工程概述需求工程概述需求获取需求获取用户需求分析用户需求分析系统需求分析系统需求分析需求验证需求验证需求管理需求管理 什么是需求什么是需求什么是需求工程什么是需求工程需求工程的重要性及困难需求工程的重要性及困难名人名言名人名言开发软件系统最困难的环节就是准确说明开发什么，开发软件系统最困难的环节就是准确说明开发什么，最困难的概念性工作就是编写出详细的软件需求。最困难的概念性工作就是编写出详细的软件需求。构建一个软件系统最困难的工作是确定构建什么。构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样

2、，在出错之后会其他任何工作都不会像这部分工作那样，在出错之后会如此严重地影响随后实现的系统，并且在以后修复竟会如此严重地影响随后实现的系统，并且在以后修复竟会如此的困难。如此的困难。 Frederick Brooks 在传统软件工程的软件生命周期中，涉及软件需求在传统软件工程的软件生命周期中，涉及软件需求的阶段称作需求分析，是生命周期中的一个早期阶段。的阶段称作需求分析，是生命周期中的一个早期阶段。随着软件系统的复杂度越来越高、规模越来越大，需求随着软件系统的复杂度越来越高、规模越来越大，需求的分析与定义在整个软件开发与维护过程中越来越重要，的分析与定义在整个软件开发与维护过程中越来越重要，直

3、接关系到软件的成功与否。根据美国权威机构直接关系到软件的成功与否。根据美国权威机构Standish Group对对23000个软件项目进行的研究结果个软件项目进行的研究结果表明，表明，28%的项目彻底失败，的项目彻底失败，46%的项目超出经费预的项目超出经费预算或者超出工期，只有约算或者超出工期，只有约26%的项目获得成功。而在这的项目获得成功。而在这些高达些高达74%的不成功项目中，有约的不成功项目中，有约60%的失败是源于的失败是源于需求问题。也就是说，有近需求问题。也就是说，有近45%的软件项目最终因为需的软件项目最终因为需求的问题而最终导致失败。求的问题而最终导致失败。实践表明，单纯的

4、需求分析已经不能很好地解决软件实践表明，单纯的需求分析已经不能很好地解决软件工程中的工程中的“需求需求”问题，需求活动已不再仅限于软件开发问题，需求活动已不再仅限于软件开发的最初阶段，而是贯穿于软件的整个生命周期。为此，有的最初阶段，而是贯穿于软件的整个生命周期。为此，有人提出了需求工程人提出了需求工程(Requirement Engineering，RE)的的概念，自概念，自20世纪世纪90年代以来，需求工程成为研究的热点年代以来，需求工程成为研究的热点之一。从之一。从1993年起每两年举办一次需求工程国际研讨会年起每两年举办一次需求工程国际研讨会(ISRE)，自，自1994年起每两年举办一

5、次需求工程国际会议年起每两年举办一次需求工程国际会议(ICRE)，一些关于需求工程的工作小组相继成立，使需，一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展，逐渐形成了软件工程的一求工程的研究得到了迅速进展，逐渐形成了软件工程的一个子领域。个子领域。需求工程涉及的需求分三个层次：需求工程涉及的需求分三个层次：业务需求业务需求-用户需求用户需求-系统需求系统需求业务需求业务需求( business requirement)：是需求层次：是需求层次中的底层，是目标软件系统基于的业务规则和业务逻辑，中的底层，是目标软件系统基于的业务规则和业务逻辑，描述了用户利用目标软件系统需要完成

6、的任务。描述了用户利用目标软件系统需要完成的任务。用户需求用户需求(user requirement)：由业务需求所决：由业务需求所决定，描述了用户（广义）对目标软件的愿景（期望值）。定，描述了用户（广义）对目标软件的愿景（期望值）。即用户需求表述了用户即用户需求表述了用户希望目标软件做什么希望目标软件做什么。系统需求系统需求(System requirement)：也称软件需求，：也称软件需求，是目标软件系统需要达到的功能和性能目标。即系统需求是目标软件系统需要达到的功能和性能目标。即系统需求表述了目标软件系统表述了目标软件系统应该做什么应该做什么。【观点观点】用户就是上帝吗？用户就是上帝吗

7、？用户需求，依据的是用户需求，依据的是“用户是上帝！用户是上帝！”的传统观念。的传统观念。然而，现代的项目管理理论已突破了这种传统观念，用户然而，现代的项目管理理论已突破了这种传统观念，用户至上已不再是唯一的选择。事实上，一个项目成功的标志至上已不再是唯一的选择。事实上，一个项目成功的标志并不完全取决于必须满足用户的需求，有时发起人或业主并不完全取决于必须满足用户的需求，有时发起人或业主的需求才是最重要的，是必须满足的。例如，的需求才是最重要的，是必须满足的。例如，Apple的乔的乔布斯说，他开发布斯说，他开发iPhone从没有考虑过用户的需求，他不从没有考虑过用户的需求，他不会让会让iPho

8、ne去适应用户的需求，而是引导用户来适应去适应用户的需求，而是引导用户来适应iPhone。（大意）。（大意）（举例影视项目）（举例影视项目）因此严格来说，用户需求更应该是因此严格来说，用户需求更应该是干系人干系人（项目的利（项目的利益相关者）需求，需求分析人员必须分析各种干系人的需益相关者）需求，需求分析人员必须分析各种干系人的需求，而不仅仅只是分析用户的需求。求，而不仅仅只是分析用户的需求。1.2 什么是需求工程什么是需求工程需需求求开开发发需需求求管管理理需求获取需求获取需求分析需求分析编写规约编写规约需求验证需求验证基线管理基线管理变更管理变更管理需求跟踪需求跟踪需求工程需求工程图图3-

9、1 需求工程组成需求工程组成需求工程大致可以分为需求开发和需求管理两个部分，需求工程大致可以分为需求开发和需求管理两个部分，如下图所示。如下图所示。需求开发包含了需求工程中技术层面的活动，主要分需求开发包含了需求工程中技术层面的活动，主要分为：为：需求获取需求获取、需求分析需求分析、编写需求规约编写需求规约和和需求验证需求验证四项四项活动或说四个阶段。它们在逻辑上存在先后顺序关系，而活动或说四个阶段。它们在逻辑上存在先后顺序关系，而在实际工作中通常是迭代进行的。在实际工作中通常是迭代进行的。其目的是通过对业务需其目的是通过对业务需求和用户需求的获取和分析，定义出详细的系统需求，即求和用户需求的

10、获取和分析，定义出详细的系统需求，即需求开发要解决的是目标软件系统需求开发要解决的是目标软件系统“需要做什么需要做什么”的问的问题。题。需求管理包含了需求工程中管理层面的活动，它贯穿需求管理包含了需求工程中管理层面的活动，它贯穿需求工程的全过程，其目的是为了应对需求的变更，因为需求工程的全过程，其目的是为了应对需求的变更，因为软件工程有一个定律：软件工程有一个定律：需求是一定会变的需求是一定会变的。需求管理一般。需求管理一般可分为可分为需求变更管理需求变更管理、基线管理基线管理和和需求跟踪需求跟踪三项活动。三项活动。需求工程？需求工程？需求工程就是涉及需求的所有相关活动的总称。需求工程就是涉及

11、需求的所有相关活动的总称。需要明确的是需求工程应该是一个迭代的过程。由于需要明确的是需求工程应该是一个迭代的过程。由于市场环境的易变性以及用户对于需求描述的模糊性，需求市场环境的易变性以及用户对于需求描述的模糊性，需求往往很难做到一步到位。需求工程不仅仅是属于软件生命往往很难做到一步到位。需求工程不仅仅是属于软件生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。它应该随着项目的深入而不断地变化。需求工程一般由项目经理和资深的系统分析员领衔。需求工程一般由项目经理和资深的系统分析员领衔。1.3 需求工程的

12、重要性与困难需求工程的重要性与困难需求工程贯穿于软件的整个生命周期。在软件项目需求工程贯穿于软件的整个生命周期。在软件项目还未正式立项前，事实上就开始了需求工程还未正式立项前，事实上就开始了需求工程可行性可行性研究，可行性研究报告可以说就是需求工程产生的第一研究，可行性研究报告可以说就是需求工程产生的第一个项目文档。需求工程产生的需求规约既是软件生命周个项目文档。需求工程产生的需求规约既是软件生命周期中第一个里程碑，又是项目开发人员、项目管理人员期中第一个里程碑，又是项目开发人员、项目管理人员和客户三者必须遵守的一根基线，是三者共同工作的基和客户三者必须遵守的一根基线，是三者共同工作的基础，是

13、软件设计和实现的依据，是软件测试的准则，也础，是软件设计和实现的依据，是软件测试的准则，也是供方交付合同软件产品和需方验收产品的依据。是供方交付合同软件产品和需方验收产品的依据。可以说，需求是软件产品的根源，需求工程结果的可以说，需求是软件产品的根源，需求工程结果的优劣对软件产品的质量影响最大，就像一条河流，如果优劣对软件产品的质量影响最大，就像一条河流，如果源头被污染了，那么整条河流都会被污染。需求工程造源头被污染了，那么整条河流都会被污染。需求工程造成的错误在后续的设计和实现中会发散式的传播。成的错误在后续的设计和实现中会发散式的传播。 然而，需求工程又是软件工程中最复杂的过程之一，然而，

14、需求工程又是软件工程中最复杂的过程之一，主要原因在于：主要原因在于：(1)应用领域的广泛性，使得需求工程的实施与各个应用领域的广泛性，使得需求工程的实施与各个应用领域的特征密切相关，而系统分析员（需求工程师）应用领域的特征密切相关，而系统分析员（需求工程师）又不可能对各个领域的业务都熟悉。又不可能对各个领域的业务都熟悉。(2)非功能性需求建模技术的缺乏，及其与功能性需非功能性需求建模技术的缺乏，及其与功能性需求的错综复杂的联系，大大增加了需求工程的复杂性。求的错综复杂的联系，大大增加了需求工程的复杂性。(3)沟通上的困难，由于系统分析员、客户等各方面沟通上的困难，由于系统分析员、客户等各方面人

15、员有不同的着眼点和不同的知识背景，以及客户与系统人员有不同的着眼点和不同的知识背景，以及客户与系统分析员之间对同一问题存在着理解上的差异和习惯用语的分析员之间对同一问题存在着理解上的差异和习惯用语的不同，给需求工程的实施增加了人为的困难。不同，给需求工程的实施增加了人为的困难。(4) 需求变更是常态。需求变更是常态。图图3-22 用户需求分析的目的用户需求分析的目的业务模型的业务模型的UML建模概述建模概述用户需求的分析建模过程用户需求的分析建模过程需求获取需求获取(requirement elicitation)是在问题及其是在问题及其最终解决方案之间架设桥梁的第一步。这部分的主要工作最终解

16、决方案之间架设桥梁的第一步。这部分的主要工作是通过多种途径获取业务需求和用户需求，并确认所获取是通过多种途径获取业务需求和用户需求，并确认所获取内容的真实性。内容的真实性。需求获取可能是需求工程中最困难、最易出错及最需需求获取可能是需求工程中最困难、最易出错及最需要交流沟通的方面，被认为是需求工程中的焦点。决定需要交流沟通的方面，被认为是需求工程中的焦点。决定需求获取成功的因素包括策略、方法、态度、性格和行为等，求获取成功的因素包括策略、方法、态度、性格和行为等，其中最重要的是建立通畅的通信途径，即在系统分析员与其中最重要的是建立通畅的通信途径，即在系统分析员与各类干系人之间，尤其是在系统分析

17、员与客户及最终用户各类干系人之间，尤其是在系统分析员与客户及最终用户之间建立良好的沟通渠道和方式，以保证能顺利地获取正之间建立良好的沟通渠道和方式，以保证能顺利地获取正确的需求。确的需求。2.1 干系人干系人涉众涉众（Stakeholder）：）：主要是指与项目利益相关的个人或组织。主要是指与项目利益相关的个人或组织。软件项目的主要干系人有：软件项目的主要干系人有： 客户客户：是购买或委托开发软件产品的个人或组织。显：是购买或委托开发软件产品的个人或组织。显然，客户的需求是非常重要的，如产品的功能、成本、质然，客户的需求是非常重要的，如产品的功能、成本、质量、进度等需求。量、进度等需求。 最终

18、用户最终用户：是直接使用软件产品的个人或组织。典型：是直接使用软件产品的个人或组织。典型的需求如产品好用、能创造价值。的需求如产品好用、能创造价值。 业主业主：项目的出资方投资者，一般是项目产品的产：项目的出资方投资者，一般是项目产品的产权人。它不一定是客户。比如，假设某客户的网络化建设权人。它不一定是客户。比如，假设某客户的网络化建设是由一家国际风险投资机构投资的，它本身并不管理客户，是由一家国际风险投资机构投资的，它本身并不管理客户，它只是从资本上拥有这个系统并从系统的运营收入中获得它只是从资本上拥有这个系统并从系统的运营收入中获得回报。回报。 了解业主的需求是必须和重要的，业主的出资是这

19、个了解业主的需求是必须和重要的，业主的出资是这个项目存在的基础。若目标软件不符合业主的需求，撤回投项目存在的基础。若目标软件不符合业主的需求，撤回投资，那么再好的愿景也是空的。资，那么再好的愿景也是空的。 发起人发起人：发起人是项目的承建者或立项的决策者，俗：发起人是项目的承建者或立项的决策者，俗称项目团队的称项目团队的“老板老板”，如公司的，如公司的CEO。老板的需求是非。老板的需求是非常重要的。老板关心的是通过这个项目，能否赚到钱，是常重要的。老板关心的是通过这个项目，能否赚到钱，是否能积累核心竞争力，是否能树立品牌，是否能开拓市场。否能积累核心竞争力，是否能树立品牌，是否能开拓市场。老板

20、的需求将很大的影响一个项目的运作模式，技术选择，老板的需求将很大的影响一个项目的运作模式，技术选择，架构建立和范围确定。架构建立和范围确定。比如，老板试图通过这个项目打开一个市比如，老板试图通过这个项目打开一个市场，树立起品牌，不惜成本，那么，系统分析员需要尽可能的深入挖场，树立起品牌，不惜成本，那么，系统分析员需要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构，选择那些掘潜在业务，建立扩展能力很强，但成本较高的业务架构，选择那些较新，但风险较高的技术。反之，如果老板只想通过这个项目赚更多较新，但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，系统分析员就需要引导客

21、户压缩业务范围，选择风险小的成熟的钱，系统分析员就需要引导客户压缩业务范围，选择风险小的成熟技术，甚至不用考虑业务架构，考虑系统的可维护性，而较少考虑系技术，甚至不用考虑业务架构，考虑系统的可维护性，而较少考虑系统扩展能力。统扩展能力。 一个业主满意但老板不满意的项目，恐怕也不是一个一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？成功的项目吧？ 供方业务伙伴供方业务伙伴：供方又称供应商或承包方，一般：供方又称供应商或承包方，一般是根据合同为项目提供组件或服务的外部公司。业务伙伴是根据合同为项目提供组件或服务的外部公司。业务伙伴也是外部公司，但他们与本企业间存在特殊的关系。这种也是外

22、部公司，但他们与本企业间存在特殊的关系。这种特殊关系可能是通过某个认证过程建立的。业务伙伴为项特殊关系可能是通过某个认证过程建立的。业务伙伴为项目提供专业技术，或提供安装、定制、培训或支持等特定目提供专业技术，或提供安装、定制、培训或支持等特定服务。服务。比如在网上图书馆系统中，借阅人借书时需要交费，若交费比如在网上图书馆系统中，借阅人借书时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上图书馆系统的一个是通过网上银行支付的，则网上银行就成为了网上图书馆系统的一个业务伙伴。业务伙伴。 供方和业务伙伴的需求对系统来说不起决定性意义，供方和业务伙伴的需求对系统来说不起决定性意义，但会起

23、到限制作用。最终在目标系统中，这种需求将体现但会起到限制作用。最终在目标系统中，这种需求将体现为标准、协议和接口。为标准、协议和接口。 2.2 需求获取方法需求获取方法除了从已有的有关资料（如招标书、合同）中获取需除了从已有的有关资料（如招标书、合同）中获取需求外，常用的需求获取方法有：访谈、问卷调查、建立原求外，常用的需求获取方法有：访谈、问卷调查、建立原型、现场体验等。型、现场体验等。1. 访谈访谈访谈是最直接的需求获取方法。访谈对象一般是客户访谈是最直接的需求获取方法。访谈对象一般是客户单位的中高层管理人员、领域专家、业务骨干以及项目的单位的中高层管理人员、领域专家、业务骨干以及项目的发

24、起人。发起人。在进行访谈之前，系统分析员要首先确定访谈的目的，在进行访谈之前，系统分析员要首先确定访谈的目的，进而准备一个访谈要点即问题列表，预先准备好希望通过进而准备一个访谈要点即问题列表，预先准备好希望通过访谈解决的问题。访谈解决的问题。 访谈过程中应注意以下事项：访谈过程中应注意以下事项：要使用清晰和准确的语言，尽量不要使用计算机的要使用清晰和准确的语言，尽量不要使用计算机的专业术语。专业术语。避免提出强制性、引导性和偏见性的问题。避免提出强制性、引导性和偏见性的问题。避免冗长和复杂的问题。避免冗长和复杂的问题。切忌针对对方所谈内容的嘲讽和批评。切忌针对对方所谈内容的嘲讽和批评。少说多听

25、，大部分时间是倾听和记录。少说多听，大部分时间是倾听和记录。该方法的主要缺点是成本较高。该方法的主要缺点是成本较高。2. 问卷调查问卷调查这种方法，问卷的设计很重要，要合理地控制开放式这种方法，问卷的设计很重要，要合理地控制开放式问题和封闭式问题的比例。问题和封闭式问题的比例。开放式问题开放式问题其答案不受限制，可使被访者尽可能地阐述其答案不受限制，可使被访者尽可能地阐述自己的真实想法。但对开放式问题的汇总和分析的工作会比较复杂。自己的真实想法。但对开放式问题的汇总和分析的工作会比较复杂。封闭式问题封闭式问题其答案是预先设定的，被访者从若干答案中其答案是预先设定的，被访者从若干答案中进行选择。

26、封闭式问题便于对问卷信息进行归纳和整理，但是会限制进行选择。封闭式问题便于对问卷信息进行归纳和整理，但是会限制被访者的思维。被访者的思维。该方法一般效果不佳。该方法一般效果不佳。3. 现场体验现场体验这是为搞清某种较复杂业务活动的现状而采取的方法。这是为搞清某种较复杂业务活动的现状而采取的方法。通过现场的亲自观察甚至动手操作，可直接体验到现有系通过现场的亲自观察甚至动手操作，可直接体验到现有系统的业务流程以及目标软件系统应解决的问题。这种方法统的业务流程以及目标软件系统应解决的问题。这种方法最易沟通，同时调查结果最准确、最可靠、最真实、还可最易沟通，同时调查结果最准确、最可靠、最真实、还可减少

27、后面与客户打交道的时间。缺点是费时。减少后面与客户打交道的时间。缺点是费时。4. 建立原型建立原型如果用户本身对需求的了解不太清晰，通常可采用建如果用户本身对需求的了解不太清晰，通常可采用建立原型系统的方法对用户需求进行挖掘，原型系统就是目立原型系统的方法对用户需求进行挖掘，原型系统就是目标系统的一个可操作的模型。在初步获取需求后，开发人标系统的一个可操作的模型。在初步获取需求后，开发人员可快速开发一个原型系统，通过对原型系统进行演示或员可快速开发一个原型系统，通过对原型系统进行演示或者让用户操作原型系统，能及时获得用户的意见，从而对者让用户操作原型系统，能及时获得用户的意见，从而对用户需求进

28、行明确。用户需求进行明确。3 用户需求分析的目的用户需求分析的目的业务模型的业务模型的UML建模概述建模概述用户需求的分析建模过程用户需求的分析建模过程3.1 用户需求分析的目的用户需求分析的目的 用户需求分析是需求分析的起点，特别是对为客户定用户需求分析是需求分析的起点，特别是对为客户定制的软件产品，这一环节是必不可少的。在实际工作中这制的软件产品，这一环节是必不可少的。在实际工作中这一环节往往被忽视，需求分析似乎就是系统（软件）需求一环节往往被忽视，需求分析似乎就是系统（软件）需求分析。实际上，用户需求分析才是需求分析中最重要的事分析。实际上，用户需求分析才是需求分析中最重要的事情。实践表

29、明，在那些因需求而失败的软件项目中，多为情。实践表明，在那些因需求而失败的软件项目中，多为没做好用户需求分析或者是就没做业务需求分析。没做好用户需求分析或者是就没做业务需求分析。要为某个现实问题开发软件产品，特别是为客户定制要为某个现实问题开发软件产品，特别是为客户定制MIS、ERP（企业资源计划）、电子商务等各种信息系统，（企业资源计划）、电子商务等各种信息系统，开发者必须要了解客户现有的业务系统，对现有系统的业开发者必须要了解客户现有的业务系统，对现有系统的业务需求务需求业务规则和业务逻辑，有深入的理解，在此基业务规则和业务逻辑，有深入的理解，在此基础上才能分析出正确的用户需求。础上才能分

30、析出正确的用户需求。用户需求分析的目的在于：用户需求分析的目的在于：了解目标组织（将要在其中部署目标软件系统的组了解目标组织（将要在其中部署目标软件系统的组织）的结构及机制。织）的结构及机制。了解目标组织的现有业务系统的业务规则和业务流了解目标组织的现有业务系统的业务规则和业务流程。程。了解目标组织及其业务系统当前存在的问题并确定了解目标组织及其业务系统当前存在的问题并确定改进（重组业务流程）的可能性。改进（重组业务流程）的可能性。确保客户、目标组织和开发团队就业务系统达成共确保客户、目标组织和开发团队就业务系统达成共识。识。导出支持客户和目标组织所需的用户需求。导出支持客户和目标组织所需的用

31、户需求。需要强调的是，现有的正常运转的业务流程对于计需要强调的是，现有的正常运转的业务流程对于计算机来说不一定是合适的。为了最大限度的利用计算机，算机来说不一定是合适的。为了最大限度的利用计算机，必须要深入了解现有的业务流程和业务规则，可能的话必须要深入了解现有的业务流程和业务规则，可能的话需要对现有业务流程加以自动化改造，当然这必须得到需要对现有业务流程加以自动化改造，当然这必须得到客户的认可。有人认为只有客户的认可。有人认为只有ERP这种大系统才需要对业这种大系统才需要对业务流程进行重组，但是实际上不论是部门级的务流程进行重组，但是实际上不论是部门级的MIS系统，系统，还是社会级的电子商务

32、系统，都需要对业务流程进行改还是社会级的电子商务系统，都需要对业务流程进行改造，所不同的只是改造的程度。造，所不同的只是改造的程度。用户需求分析的结果文档是用户需求分析的结果文档是用户需求规约用户需求规约，要交由，要交由客户签字认可，或其内容嵌入在可行性研究报告中。客户签字认可，或其内容嵌入在可行性研究报告中。在用户需求分析过程中，为便于与客户进行交流，在用户需求分析过程中，为便于与客户进行交流，需要建立可视化的业务模型。需要建立可视化的业务模型。3.2 业务模型的业务模型的UML建模概述建模概述 业务模型描述的是业务范围，与后续的软件需求模业务模型描述的是业务范围，与后续的软件需求模型描述的

33、软件范围是不同的。建立业务模型是为了理解型描述的软件范围是不同的。建立业务模型是为了理解目标组织现有的业务系统，相当于对现有业务系统的整目标组织现有的业务系统，相当于对现有业务系统的整理和重现，在充分理解的基础上可以对现有的业务流程理和重现，在充分理解的基础上可以对现有的业务流程进行适当的改造，但它必须尊重事实，符合实际，而且进行适当的改造，但它必须尊重事实，符合实际，而且尽量使用客户能理解的语言，一般不要使用计算机专业尽量使用客户能理解的语言，一般不要使用计算机专业语言，不要考虑计算机逻辑，语言，不要考虑计算机逻辑，即业务模型不依赖于任何即业务模型不依赖于任何计算机平台，或说计算机平台，或说

34、业务模型与计算机系统无关业务模型与计算机系统无关（除非现（除非现有业务系统已经是一个计算机应用系统）。业务模型将有业务系统已经是一个计算机应用系统）。业务模型将在客户和开发方之间建立这样的共识：要建立的目标软在客户和开发方之间建立这样的共识：要建立的目标软件系统所面对的问题域就是这个样子的。件系统所面对的问题域就是这个样子的。很多时候业务范围并不等于软件功能范围，这不仅仅很多时候业务范围并不等于软件功能范围，这不仅仅是有些业务不适合计算机实现，即使可以用计算机实现的，是有些业务不适合计算机实现，即使可以用计算机实现的，但根据运行环境等硬件因素，一些业务环节也可能被排除但根据运行环境等硬件因素，

35、一些业务环节也可能被排除在软件功能范围之外。在软件功能范围之外。使用面向对象方法和使用面向对象方法和UML建立业务模型是当前的主流建立业务模型是当前的主流业务建模方法。使用业务建模方法。使用UML建立业务模型要用到用例图、建立业务模型要用到用例图、活动图和类图，它们可从不同视角描述业务模型，从而构活动图和类图，它们可从不同视角描述业务模型，从而构建成一个完整的业务模型。建成一个完整的业务模型。下面是在业务模型的下面是在业务模型的UML建模中的两个重要概念：业建模中的两个重要概念：业务角色和业务用例。务角色和业务用例。业务角色业务角色（business actor）在业务模型中，业务角色一般定义

36、为与现有业务系在业务模型中，业务角色一般定义为与现有业务系统统交互交互的一切人、物和事。的一切人、物和事。在在RUP方法中，业务角色实际上有方法中，业务角色实际上有“业务主角业务主角”和和“辅助角色辅助角色”之分。之分。业务主角业务主角是业务用例的启动者，有是业务用例的启动者，有明确和完整的业务目标，是业务用例的服务对象明确和完整的业务目标，是业务用例的服务对象。而辅。而辅助角色既非业务用例的启动者和服务对象，也无完整的助角色既非业务用例的启动者和服务对象，也无完整的业务目标。业务目标。比如在网上商店系统中，购物人是业务主角，购物人比如在网上商店系统中，购物人是业务主角，购物人购物时需要交费，

37、若交费是通过网上银行支付的，则网上银行就成购物时需要交费，若交费是通过网上银行支付的，则网上银行就成为了网上商店系统的一个辅助角色，而非业务主角。辅助角色与业为了网上商店系统的一个辅助角色，而非业务主角。辅助角色与业务用例有关联，但它将不会出现在系统需求模型中。务用例有关联，但它将不会出现在系统需求模型中。业务主角与业务主角与辅助角色在用例视图中的表达是不同的，它们都与业务辅助角色在用例视图中的表达是不同的，它们都与业务用例关联，但关联的方向不一样，业务主角的关联线的用例关联，但关联的方向不一样，业务主角的关联线的箭头指向业务用例，而辅助角色的关联线的箭头指向的箭头指向业务用例，而辅助角色的关

38、联线的箭头指向的则是辅助角色。则是辅助角色。 业务用例业务用例（business usecase）一个业务用例是业务系统提供的一个一个业务用例是业务系统提供的一个服务项目服务项目。业务用例有以下几个特征：业务用例有以下几个特征：业务用例是相对独立的业务用例是相对独立的。这意味着它不需要与其它。这意味着它不需要与其它用例交互而可以独自完成业务角色所需要的服务，也就是用例交互而可以独自完成业务角色所需要的服务，也就是说业务用例从行为上说是完备的。对于业务用例，这个特说业务用例从行为上说是完备的。对于业务用例，这个特征是很明显的。征是很明显的。业务用例的执行结果对角色来说是可观测的和有意业务用例的执

39、行结果对角色来说是可观测的和有意义的义的。例如，在传统的（不开架）图书馆业务系统中，例如，在传统的（不开架）图书馆业务系统中，“借书借书”是一个业是一个业务用例，务用例，“借阅人借阅人”是业务主角，借书业务由借阅人启动，在借书过程中还是业务主角，借书业务由借阅人启动，在借书过程中还有一个不可缺的操作有一个不可缺的操作书库管理员从书库中取书，但书库管理员从书库中取书，但“从书库取书从书库取书”虽然虽然是借书业务的一个必需组成部分，但它却不应该作为业务用例出现，因为这是借书业务的一个必需组成部分，但它却不应该作为业务用例出现，因为这是一个后台操作，具体的取书过程对借阅人来说是不可观测的，借阅人也无

40、是一个后台操作，具体的取书过程对借阅人来说是不可观测的，借阅人也无需关心。需关心。一个业务用例必须由一个业务主角激发一个业务用例必须由一个业务主角激发。不存在没。不存在没有业务主角激发的业务用例，业务用例不应该自动启动，有业务主角激发的业务用例，业务用例不应该自动启动，也不应该主动激发另一个业务用例。例如从也不应该主动激发另一个业务用例。例如从ATM取钱是取钱是一个有效的用例，而一个有效的用例，而ATM吐钞却不是。如果吐钞却不是。如果ATM无缘无无缘无故吐钞的话，每个人的生活都无忧矣。故吐钞的话，每个人的生活都无忧矣。用例名必然是以动宾短语形式出现的用例名必然是以动宾短语形式出现的。即用例必须

41、。即用例必须有一个动作和动作的受体。有一个动作和动作的受体。3.3 用户需求分析建模过程用户需求分析建模过程 一个完整的一个完整的UML业务模型是由使用多种业务模型是由使用多种UML图构建的图构建的不同的视图所组成。整个分析建模过程一般可划分为如下不同的视图所组成。整个分析建模过程一般可划分为如下6个步骤：个步骤：分析干系人，建立分析干系人，建立业务角色视图业务角色视图用例图用例图分析角色需求，建立分析角色需求，建立业务用例视图业务用例视图用例图用例图分析业务流程，建立分析业务流程，建立业务场景视图业务场景视图活动图活动图分析用例流程，建立分析用例流程，建立用例场景视图用例场景视图活动图活动图

42、分析用例场景，建立分析用例场景，建立业务实体视图业务实体视图类图类图编写用户需求文档编写用户需求文档上述的步骤并非一次性顺序完成的，通常需要多次迭代上述的步骤并非一次性顺序完成的，通常需要多次迭代。 【案例案例】网上图书馆网上图书馆系统分析员通过对某图书馆的调查，获取了如下需求信息：系统分析员通过对某图书馆的调查，获取了如下需求信息：该图书馆原本是一个传统的图书馆，传统的借书方式要求读者亲该图书馆原本是一个传统的图书馆，传统的借书方式要求读者亲自来到图书馆，这显得非常不方便。随着藏书的增加和读者群的增长，自来到图书馆，这显得非常不方便。随着藏书的增加和读者群的增长，有大量的读者到图书馆，使得图

43、书馆的场地不足，工作人员也不够了。有大量的读者到图书馆，使得图书馆的场地不足，工作人员也不够了。所以想到借助网络，让读者通过网络借所以想到借助网络，让读者通过网络借/ /还书，这样可以省掉大量的还书，这样可以省掉大量的场地维护和工作人员的薪水支出。同时计算机可以方便的检索目录，场地维护和工作人员的薪水支出。同时计算机可以方便的检索目录，让读者可以足不出户借到需要的书。为了把书送到借阅人手里，该图让读者可以足不出户借到需要的书。为了把书送到借阅人手里，该图书馆已经联系了书馆已经联系了A A特快专递公司和特快专递公司和B B城市物流公司，初步达成协议，由城市物流公司，初步达成协议，由他们往返借阅人

44、和图书馆之间把图书送达和收回。他们往返借阅人和图书馆之间把图书送达和收回。读者在网上出示和验证借书卡，找到他们需要的书，提交申请，读者在网上出示和验证借书卡，找到他们需要的书，提交申请，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，图书管理员确认后，就会通知物流公司来取书，当读者拿到书之后，物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中，读者是需要付费的。还书也是基本同样的过程。个过程中，读者是需要付费的。还书也是基本同样的过程。 你是你是OOOO分析员吗分析员吗？在获取与分析用户需求时有两种做法，

45、在获取与分析用户需求时有两种做法，您选择哪一种呢？您选择哪一种呢？最先弄清楚有多少部门，最先弄清楚有多少部门，多少岗位，然后找到每一多少岗位，然后找到每一个岗位的业务代表，问他个岗位的业务代表，问他们类似的问题：你平时都们类似的问题：你平时都做什么？这件事是谁交办做什么？这件事是谁交办的？做完了你需要通知或的？做完了你需要通知或传达给谁吗？做这件事情传达给谁吗？做这件事情你都需要填写些什么表格你都需要填写些什么表格吗？吗？.最先弄清楚有多少业务最先弄清楚有多少业务流程，先画出业务流程图，流程，先画出业务流程图，然后顺藤摸瓜，找出业务然后顺藤摸瓜，找出业务流程中每一步骤的参与部流程中每一步骤的参

46、与部门或岗位，弄清楚在这一门或岗位，弄清楚在这一步参与者所做的事情和填步参与者所做的事情和填写表单的结果，并关心用写表单的结果，并关心用户是如何把这份表单传给户是如何把这份表单传给到下一个环节的。到下一个环节的。恭喜你，恭喜你，你已经你已经OO啦！啦！很不幸，你还在做很不幸，你还在做面向过程的事情。面向过程的事情。使用使用OOOO方法建立业务模型必须先分析干系人，定方法建立业务模型必须先分析干系人，定义角色。信息系统无论多复杂，无论什么行业，其本义角色。信息系统无论多复杂，无论什么行业，其本质无非是质无非是人人、事事、物物及及规则规则。人是一切的中心人是一切的中心，人人做做事事，做，做事事产生

47、产生物物，规则规则限制人、事、物。限制人、事、物。人人驱动驱动系统，系统，事事体现过程，体现过程，物物记录结果，记录结果，规则规则则是控制。无则是控制。无论论OOOO也好，也好，UMLUML也好，复杂的表面下其实只是一个也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白简单的规则，系统分析员弄明白有什么人有什么人，什么人做什么人做什么事什么事，什么事产生什么物什么事产生什么物，中间有什么规则中间有什么规则，再把再把人、事、物之间的关系定义出来人、事、物之间的关系定义出来，业务需求分析建模，业务需求分析建模也就基本完成了。也就基本完成了。Step1Step1 建立业务角色视图建立业务角色

48、视图从获取的需求信息中，分析出业务系统的所有干系从获取的需求信息中，分析出业务系统的所有干系人，再从这些干系人中找出业务角色，并定义这些业务人，再从这些干系人中找出业务角色，并定义这些业务角色之间的关系。角色之间的关系。使用使用用例图用例图建立该业务角色视图，图建立该业务角色视图，图3-3 （ROS）和和图图3-4。 这张图的意义在于，清楚的表明将来的系统是为谁这张图的意义在于，清楚的表明将来的系统是为谁服务的，他们都是干什么的，有什么特点，有什么关系。服务的，他们都是干什么的，有什么特点，有什么关系。对用例方法来说，这是最基本的出发点。对用例方法来说，这是最基本的出发点。用例，是以用例，是以

49、人为本的。人为本的。 图图3-3 业务角色视图（业务角色视图（ROS）ba_图书管理员ba02_书架管理员ba01_借阅管理员ba03_物流送达人ba04_借阅人图图3-4 业务角色视图业务角色视图Step2Step2 建立业务用例视图建立业务用例视图找出每个业务角色要做的事，或说业务系统为不同找出每个业务角色要做的事，或说业务系统为不同业务角色提供的服务项目，即业务用例。业务用例视图业务角色提供的服务项目，即业务用例。业务用例视图使用使用用例图用例图来实现，可以从两个不同的角度来建立：来实现，可以从两个不同的角度来建立：从每个业务角色的角度，即从每个业务角色的角度，即为每个业务角色建立为每个

50、业务角色建立一个业务用例视图一个业务用例视图。图。图3-5从每项服务业务的角度，即从每项服务业务的角度，即为每项业务建立一个为每项业务建立一个业务用例视图业务用例视图。图。图3-6图图3-5 业务角色的用例视图示例业务角色的用例视图示例ba01_借阅管理员bu01_借出图书bu02_收回图书bu03_颁发借阅证bu04_收回借阅证bu05_查看借阅记录图图3-6 “借书借书”业务的用例视图业务的用例视图ba03_物 流 送 达 人ba04_借 阅 人ba01_借 阅 管 理 员bu08_送 出 图 书bu01_借 出 图 书bu10_借 书ba02_书 架 管 理 员bu07_下 架 图 书从

51、业务角色视角建立的业务用例视图展现了某个业从业务角色视角建立的业务用例视图展现了某个业务角色在系统中参与的所有业务，如图务角色在系统中参与的所有业务，如图3-5。建立这种。建立这种视图便于确保每个业务角色的所有工作不会被漏掉。视图便于确保每个业务角色的所有工作不会被漏掉。从业务视角建立的业务用例视图展现了某项业务是从业务视角建立的业务用例视图展现了某项业务是由哪些用例和哪些角色参与完成的，如图由哪些用例和哪些角色参与完成的，如图3-6。建立这。建立这种视图有助于了解清楚每项业务是如何构成的。种视图有助于了解清楚每项业务是如何构成的。Step3 建立业务场景视图建立业务场景视图针对每项业务的用例

52、视图，分析该业务的业务流程，针对每项业务的用例视图，分析该业务的业务流程，用用活动图活动图详细描述该项业务中的业务角色和用例是如何详细描述该项业务中的业务角色和用例是如何交互来完成这项业务的。交互来完成这项业务的。视图中的每个视图中的每个“活动活动”是一个是一个业务用例业务用例。图图3-7描述了描述了“借书借书”业务的业务流程（场景）。业务的业务流程（场景）。 借阅人借阅管理员物流送达人书架管理员借书下架图书送出图书借出图书图图3-7 “借书借书”的业务场景视图的业务场景视图业务场景视图可能不止一个。同样一项业务，会有很多业务场景视图可能不止一个。同样一项业务，会有很多种不同的业务实现方式，例

53、如借阅图书业务，就有可能第种不同的业务实现方式，例如借阅图书业务，就有可能第一次借书，又还书又借书，一次借书，又还书又借书，VIP客户借书，借书时借证已客户借书，借书时借证已经到期经到期.等等许多种场景。对于这些场景来说，每一个都等等许多种场景。对于这些场景来说，每一个都不能漏掉或省略，至少必须在文档中体现出来，除非已经不能漏掉或省略，至少必须在文档中体现出来，除非已经很明确这个业务场景不包括在系统范围之内。很明确这个业务场景不包括在系统范围之内。一般来说，除了少数的确是独立的业务用例外，如果一般来说，除了少数的确是独立的业务用例外，如果业务用例不能被用在业务场景图中，应该怀疑将其作为一业务用

54、例不能被用在业务场景图中，应该怀疑将其作为一个业务的必要性（它是否应该被包含在其他用例中？或者个业务的必要性（它是否应该被包含在其他用例中？或者它和其他用例应当抽象成一个更高层的用例？）。如果还它和其他用例应当抽象成一个更高层的用例？）。如果还有用例没能用在业务场景中，则应该怀疑是否还有隐含的有用例没能用在业务场景中，则应该怀疑是否还有隐含的业务流程没有获取到。业务流程没有获取到。业务场景图的意义在于，它已经绘制出了一份系统蓝业务场景图的意义在于，它已经绘制出了一份系统蓝图，将来的系统建设很大程度将依据这些场景图进行。图，将来的系统建设很大程度将依据这些场景图进行。经过上面的三个步骤，我们得到

55、了业务角色、业经过上面的三个步骤，我们得到了业务角色、业务用例以及业务场景。务用例以及业务场景。这三项工作成果已经形成了基这三项工作成果已经形成了基本的需求框架，并圈定了业务范围。本的需求框架，并圈定了业务范围。一个有经验的系统分析员往往会在此时暂停需求一个有经验的系统分析员往往会在此时暂停需求调研，而通过评审会、研讨会等形式充分论证这些成调研，而通过评审会、研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家、客户代表、项果的正确性和完备性。求得业务专家、客户代表、项目经理以及其他开发人员等各方的一致认可，将其作目经理以及其他开发人员等各方的一致认可，将其作为为第一份基线第一份基线。当

56、然，第一份基线所包括的内容是非。当然，第一份基线所包括的内容是非常粗的，要达到完整的需求说明还有更多工作要做。常粗的，要达到完整的需求说明还有更多工作要做。 Step4 建立用例场景视图建立用例场景视图针对每个业务用例，应当对用例的实现过程进行场景针对每个业务用例，应当对用例的实现过程进行场景模拟。上一步是业务场景，而用例场景中则应当将计算机模拟。上一步是业务场景，而用例场景中则应当将计算机包括进来，从人包括进来，从人-机交互的视角来模拟业务流程。表达客户机交互的视角来模拟业务流程。表达客户的实际业务在计算机环境下是如何实现的，给客户一个初的实际业务在计算机环境下是如何实现的，给客户一个初步印

57、象，告诉他们将来他们将怎样来做业务。请注意，虽步印象，告诉他们将来他们将怎样来做业务。请注意，虽然计算机已经参与需求描述，但是要尽量避免使用计算机然计算机已经参与需求描述，但是要尽量避免使用计算机术语，因为这时的文档仍然属于用户需求文档，是要与客术语，因为这时的文档仍然属于用户需求文档，是要与客户交流的，太多的计算机术语会大大降低客户对需求的理户交流的，太多的计算机术语会大大降低客户对需求的理解能力。解能力。图图3-8为示例，用为示例，用活动图活动图描述了描述了“借书借书”用例的场景。用例的场景。如果一用例有多个场景，则应当绘制多个场景视图。如果一用例有多个场景，则应当绘制多个场景视图。 借阅

58、人计算机用借阅证登录查找需要的图书放入借书篮确认借阅书目,提交借阅清单放弃定单交纳借阅费创建借阅定单和递交单查看定单号证件有效?放弃借阅借阅结束书目有效?拒绝借阅继续借书?有效有效是借阅费够否?否图图3-8 “借书借书”用例的场景视图用例的场景视图用例场景非常非常的重要，后续工作就得靠用例场景非常非常的重要，后续工作就得靠它们了！它们了！绝对要认真对待，深入调研，不可漏掉绝对要认真对待，深入调研，不可漏掉一个场景，也不可模糊不清。一个场景，也不可模糊不清。 Step5Step5 建立业务实体视图建立业务实体视图什么是业务实体？什么是业务实体？业务实体业务实体一般来说就是调研时客户所提供的各类一

59、般来说就是调研时客户所提供的各类表单表单或或报表报表，但在很多情况下，并非每一份表单就是，但在很多情况下，并非每一份表单就是一个业务实体，所有业务表单也不一定涵盖全了所有的一个业务实体，所有业务表单也不一定涵盖全了所有的业务实体。业务实体。业务实体可从业务用例场景视图中提取业务实体可从业务用例场景视图中提取。观察图。观察图3-8，每一个活动都有类似的命名：出示借阅证、查找需要的每一个活动都有类似的命名：出示借阅证、查找需要的图书、放入借书篮图书、放入借书篮.看出什么来了吗？看出什么来了吗？每个活动都是一每个活动都是一个动作加上一个动作的受体。受体正是我们要寻找的业个动作加上一个动作的受体。受体

60、正是我们要寻找的业务实体，这些名词就是业务实体的来源务实体，这些名词就是业务实体的来源。 观察用例场景，分析出现的名词，我们得到一个观察用例场景，分析出现的名词，我们得到一个个的业务实体，再根据场景分析这些业务实体之间的个的业务实体，再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的关系。实际上就是大家都熟悉的ER模型，但是与数据模型，但是与数据库建模的视角还是有所差别的。数据库库建模的视角还是有所差别的。数据库ER模型要受到模型要受到数据关系范式的限制，而业务实体数据关系范式的限制，而业务实体ER模型则不必理会模型则不必理会这种限制。只要与现实物体符合就这种限制。只要与现实物体符合