软件需求提取与分析精品文稿.ppt

《软件需求提取与分析精品文稿.ppt》由会员分享，可在线阅读，更多相关《软件需求提取与分析精品文稿.ppt（50页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、软件需求提取与分析第1页，本讲稿共50页需求分析的重要性需求分析的重要性 需求分析的目标是为系统设计和实现提供足够的指导和信需求分析的目标是为系统设计和实现提供足够的指导和信息支持。如果需求分析不充分，则设计和实现很难进行；如果息支持。如果需求分析不充分，则设计和实现很难进行；如果设计和实现中涉及的内容无法与需求建立对应关系，则显得多设计和实现中涉及的内容无法与需求建立对应关系，则显得多余。对论文而言，就是失败之作。余。对论文而言，就是失败之作。软件开发类论文评价的基本标准之一：需求与设计和软件开发类论文评价的基本标准之一：需求与设计和实现的一致性，即任何需求必须在设计和实现中得到体现，实现的

2、一致性，即任何需求必须在设计和实现中得到体现，任何设计与实现必须与需求有对应关系。任何设计与实现必须与需求有对应关系。第2页，本讲稿共50页需求分析概述需求分析概述 在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。需求获取和需求分析的工具都是采用数据流图和数据字典。明确地指出需求

3、获取和需求分析的工具都是采用数据流图和数据字典。明确地指出需求分析报告主要用于用户交流。需求分析报告主要用于用户交流。在统一过程和在统一过程和UMLUML提出后，特别是软件迭代开发方法提出后，提出后，特别是软件迭代开发方法提出后，把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具和建立的模型都完全不同。需求捕捉阶段主要采用用例模型捕捉功能和建立的模型都完全不同。需求捕捉阶段主要采用用例模型捕捉功能需求，需求

4、分析阶段主要采用对象模型，建立领域对象间的协作关系。需求，需求分析阶段主要采用对象模型，建立领域对象间的协作关系。需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组织自己的文档，不用于与用户交流。织自己的文档，不用于与用户交流。第3页，本讲稿共50页需求分类需求分类 （1）功能性需求）功能性需求-系统应该提供什么功能。系统应该提供什么功能。（2）非功能需求）非功能需求-系统的特定特性或约束。系统的特定特性或约束。软件需求软件需求功能需求功能需求非功能需求非功能需求质量属性质量属性约束约束运行期质量属性运行期质量属性开发期质量

5、属性开发期质量属性第4页，本讲稿共50页软件运行期质量软件运行期质量 用户在使用软件过程中对软件质量的要求，包括：用户在使用软件过程中对软件质量的要求，包括：易用性易用性：指软件系统容易使用的程度。：指软件系统容易使用的程度。性能性能：指软件系统及时提供相应服务的能力。性能包括响应：指软件系统及时提供相应服务的能力。性能包括响应时间、吞吐量、持续高速性。时间、吞吐量、持续高速性。安全性安全性：指软件系统同时兼顾向合法用户提供服务，以及：指软件系统同时兼顾向合法用户提供服务，以及防止非授权使用的能力。防止非授权使用的能力。持续可用性持续可用性：指软件长时间无故障运行的能力。如有的系统要求：指软件

6、长时间无故障运行的能力。如有的系统要求提供提供7*247*24小时服务就是持续可用性的要求。小时服务就是持续可用性的要求。可伸缩性可伸缩性：指当用户数量和数据量增加时，软件系统维持高：指当用户数量和数据量增加时，软件系统维持高服务质量的能力。服务质量的能力。互操作性互操作性：指本软件系统与其它软件系统交换数据和相互：指本软件系统与其它软件系统交换数据和相互调用服务的难易程度。调用服务的难易程度。可靠性可靠性：软件系统在一定时间内无故障运行的能力。：软件系统在一定时间内无故障运行的能力。鲁棒性鲁棒性：也称健壮性、容错性。有时也把持续可用性、鲁棒性也归：也称健壮性、容错性。有时也把持续可用性、鲁棒

7、性也归类为可靠性。类为可靠性。第5页，本讲稿共50页软件运行期质量软件运行期质量 为保证软件的可维护性而在软件开发过程中应该关注的软件为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性，有时将其称为隐含质量属性。包括：质量属性，有时将其称为隐含质量属性。包括：可扩展性可扩展性：为适应新需求或需求变化为软件增加功能的能：为适应新需求或需求变化为软件增加功能的能力。有时称为灵活性。力。有时称为灵活性。可重用性可重用性：重用软件系统或其一部分的能力的难易程度。：重用软件系统或其一部分的能力的难易程度。可测试性可测试性：对软件测试以证明满足需求规约的难易程度。在：对软件测试以证明满足需求规约

8、的难易程度。在实际工作中主要指进行单元测试，插桩测试的难易程度。实际工作中主要指进行单元测试，插桩测试的难易程度。可维护性可维护性：在修改：在修改BugBug、增加功能、提高质量属性等而定位、增加功能、提高质量属性等而定位修改点并适时修改的难易程度。修改点并适时修改的难易程度。可移植性可移植性：将软件系统从一个运行环境转移到另一个运行环境：将软件系统从一个运行环境转移到另一个运行环境的难易程度。的难易程度。易理解性易理解性：设计被开发人员理解的难易程度。：设计被开发人员理解的难易程度。任何一个开发期质量属性的满足都可能增加软件开发成本。任何一个开发期质量属性的满足都可能增加软件开发成本。第6页

9、，本讲稿共50页约束约束 约束不是行为，是设计或项目的限制条件，强调其限制性，新约束不是行为，是设计或项目的限制条件，强调其限制性，新系统的开发无法回避这些事实或因素。约束主要包括：系统的开发无法回避这些事实或因素。约束主要包括：系统开发的资源约束系统开发的资源约束：如网络环境、操作系统、数据库管：如网络环境、操作系统、数据库管理系统、开发工具、硬件等。新系统的开发必须考虑这些资源理系统、开发工具、硬件等。新系统的开发必须考虑这些资源的有效利用和限制。的有效利用和限制。接口约束接口约束：本系统关联的系统是哪些，新系统可能接受其它：本系统关联的系统是哪些，新系统可能接受其它系统提供的数据作为输入

10、，其输出数据作为其它系统的输入。系统提供的数据作为输入，其输出数据作为其它系统的输入。操作约束操作约束：系统操作环境中的管理要求。如身份认证必须通：系统操作环境中的管理要求。如身份认证必须通过第三方认证机构的认证，以网络为基础的业务处理，在网络不过第三方认证机构的认证，以网络为基础的业务处理，在网络不通的情况下如何处理业务等。通的情况下如何处理业务等。政策约束政策约束：行业标准，企业标准，法律法规、政府规章等。：行业标准，企业标准，法律法规、政府规章等。第7页，本讲稿共50页需求的层次性需求的层次性 组织的不同层次人员对需求不同，通常有三个层次：组织的不同层次人员对需求不同，通常有三个层次：业

11、务需求业务需求：组织要达到的目标：组织要达到的目标业务目标业务目标 用户需求用户需求：用户使用系统来做什么：用户使用系统来做什么 行为需求行为需求：开发人员需要实现什么：开发人员需要实现什么 高管人员希望软件系统能帮助他们达到业务目标。高管人员希望软件系统能帮助他们达到业务目标。系统实际使用者希望系统提供的能力能辅助他们更好地完成日常系统实际使用者希望系统提供的能力能辅助他们更好地完成日常业务工作。业务工作。开发人员为满足用户诸多需求而觉察到的需求。开发人员为满足用户诸多需求而觉察到的需求。高层管理人员的需求与系统实际使用人员的需求可以起到相互验高层管理人员的需求与系统实际使用人员的需求可以起

12、到相互验证和印证的作用。如果不关注证和印证的作用。如果不关注“高层管理人员高层管理人员”的要求，系统开发就的要求，系统开发就没有明确的目标，系统的功能将是零散而脆弱的，极易受到变更的冲没有明确的目标，系统的功能将是零散而脆弱的，极易受到变更的冲击。不满足开发人员的要求，软件的开发、维护和移植变得非常困难。击。不满足开发人员的要求，软件的开发、维护和移植变得非常困难。第8页，本讲稿共50页需求提取内容需求提取内容 确定业务目标确定业务目标 确定业务范围和业务流程确定业务范围和业务流程 建立用例模型建立用例模型 建立用例规约建立用例规约 确定非功能需求确定非功能需求第9页，本讲稿共50页确定业务目

13、标确定业务目标 业务目标系统开发中占有非常重要的位置，它明确规定了建立该软业务目标系统开发中占有非常重要的位置，它明确规定了建立该软件系统的最终目的。业务目标是客户方高层对未来系统的期望。通过确件系统的最终目的。业务目标是客户方高层对未来系统的期望。通过确定业务目标可以避免系统解决的问题的层次太低而很快过时。定业务目标可以避免系统解决的问题的层次太低而很快过时。项目业务目标要避免太抽象、太空洞，如项目业务目标要避免太抽象、太空洞，如“实现实现XXXX信息化信息化”。一个项目管理系统的业务目标定义为：一个项目管理系统的业务目标定义为：帮助项目经理更好地控制项目帮助项目经理更好地控制项目 帮助项目

14、经理更有效地分配资源帮助项目经理更有效地分配资源 帮助项目成员之间更流畅地协作帮助项目成员之间更流畅地协作 通过细化业务目标，列出一组高度概括的功能性需求。如业务目标通过细化业务目标，列出一组高度概括的功能性需求。如业务目标“帮助项目经理更好地控制项目帮助项目经理更好地控制项目”的特性有：的特性有：任务管理任务管理 跟踪进度跟踪进度 查看报表查看报表 任务分配和重分配任务分配和重分配第10页，本讲稿共50页确定业务范围和业务流程确定业务范围和业务流程 业务目标的实现需要通过具体的业务领域（有时也称业务目标的实现需要通过具体的业务领域（有时也称职能域）以及具体的业务及业务流程来体现，使业务目标职

15、能域）以及具体的业务及业务流程来体现，使业务目标落实到实处。这将引起企业组织机构的调整和业务流程重落实到实处。这将引起企业组织机构的调整和业务流程重组，以满足业务目标的要求。组，以满足业务目标的要求。业务（有时也称业务过程）：是需要做的相对独立的工作（或业务（有时也称业务过程）：是需要做的相对独立的工作（或任务）。任务）。业务流程：是完成工作所经历的业务活动及顺序。业务流程：是完成工作所经历的业务活动及顺序。业务活动：是基本的、不可再分的最小功能单元（通常业务活动：是基本的、不可再分的最小功能单元（通常指一个人在一个地点一个不可间断的时间内可以完成的工作）指一个人在一个地点一个不可间断的时间内

16、可以完成的工作）。第11页，本讲稿共50页建立用例模型建立用例模型 所谓用户需求，就是用户希望软件系统能为他做什么。用所谓用户需求，就是用户希望软件系统能为他做什么。用例图技术是捕捉用户需求最合适的技术。用例名是用户需求最例图技术是捕捉用户需求最合适的技术。用例名是用户需求最直观、最简便的反映。业务流程分析将捕捉到大部分用例，但直观、最简便的反映。业务流程分析将捕捉到大部分用例，但不是全部用例，还需要补充一些与管理人员相关、但与具体业不是全部用例，还需要补充一些与管理人员相关、但与具体业务活动不一定直接相关的用例和与信息查询相关的用例。务活动不一定直接相关的用例和与信息查询相关的用例。第12页

17、，本讲稿共50页建立用例规约建立用例规约 用例是用户用例是用户“希望如何做希望如何做”的行为需求。这里的的行为需求。这里的“如何做如何做”是从用户角度看他们是从用户角度看他们“希望如何做希望如何做”，而不是软件系统，而不是软件系统是如何做，所以还是属于需求捕捉的内容。用户是如何做，所以还是属于需求捕捉的内容。用户“希望如何希望如何做做”是软件系统是软件系统“如何做如何做”的依据。的依据。在用例规约中，将详细定义用户对用例运行期间的质在用例规约中，将详细定义用户对用例运行期间的质量要求和约束。量要求和约束。不一定所有用例都要建立用例规约。有的用例使用不一定所有用例都要建立用例规约。有的用例使用“

18、用例简用例简述述”就足够了。如果一个用例基本事件流对需求分析人员来就足够了。如果一个用例基本事件流对需求分析人员来说不是很清楚，而且可能涉及到非功能要求，就需要用说不是很清楚，而且可能涉及到非功能要求，就需要用“用用例规约例规约”来详细描述。来详细描述。第13页，本讲稿共50页确定非功能需求确定非功能需求 通过对用例规约的分析和总结，归纳出系统的非功能需求，通过对用例规约的分析和总结，归纳出系统的非功能需求，特别是用户对系统运行期的质量需求和约束。用例规约是系统特别是用户对系统运行期的质量需求和约束。用例规约是系统运行期质量需求和约束的主要来源。一般来说，开发期质量属运行期质量需求和约束的主要

19、来源。一般来说，开发期质量属性需求主要来自系统开发人员和维护人员，通过成为隐含的非性需求主要来自系统开发人员和维护人员，通过成为隐含的非功能需求。功能需求。要善于抓住对用户来说至关重要的非功能需求，这种非功能需求要善于抓住对用户来说至关重要的非功能需求，这种非功能需求往往决定系统的命运。如特殊的性能问题、特殊的安全性问题、典型往往决定系统的命运。如特殊的性能问题、特殊的安全性问题、典型的运行机制问题。的运行机制问题。若存在与其它系统的交互，互操作性是必须考虑的。若存在与其它系统的交互，互操作性是必须考虑的。特定的约束对系统的制约是架构设计必须考虑的问题。特定的约束对系统的制约是架构设计必须考虑

20、的问题。第14页，本讲稿共50页需求建模方法需求建模方法 需求提取的建模包括业务建模和用例建模。需求提取的建模包括业务建模和用例建模。业务建模是确定项目对应的业务领域所包含的业务建模是确定项目对应的业务领域所包含的业务和业务流程，并用所选择的业务流程描述工具业务和业务流程，并用所选择的业务流程描述工具进行描述。进行描述。用例建模是以用例为基本单位来描述用户的功能需求。用例建模是以用例为基本单位来描述用户的功能需求。与用例模型相关的概念包括：参与者，用例，场景与用例模型相关的概念包括：参与者，用例，场景第15页，本讲稿共50页需求建模需求建模-参与者参与者 直接与系统交互的外部事物所扮演的角色。

21、直接与系统交互的外部事物所扮演的角色。参与者对系统而言是外部的；参与者对系统而言是外部的；参与者直接与系统交互，直接使用系统来支持其业务。参与者直接与系统交互，直接使用系统来支持其业务。强调参与者所扮演的角色，而不是特定的人或事物。强调参与者所扮演的角色，而不是特定的人或事物。时间可以作为参与者，通常用时间发生器来表示。时间可以作为参与者，通常用时间发生器来表示。参与者主要指系统业务功能的使用者。系统管理员不是这种意参与者主要指系统业务功能的使用者。系统管理员不是这种意义的参与者。因为他不是使用系统功能完成与单位业务有关的工义的参与者。因为他不是使用系统功能完成与单位业务有关的工作。他使用系统

22、的辅助功能实现对特定的人及其角色的管理，使作。他使用系统的辅助功能实现对特定的人及其角色的管理，使参与者在自己角色范围内使用系统。参与者在自己角色范围内使用系统。每个参与者使用一个具有业务意义的名称命名。每个参与者使用一个具有业务意义的名称命名。需求获取的首要任务就是识别主要参与者。需求获取的首要任务就是识别主要参与者。识别参与者是需求提取的首要任务，谁是系统的客户，他们需识别参与者是需求提取的首要任务，谁是系统的客户，他们需要系统做什么，他们希望在什么时候、什么地点做，这些都是系要系统做什么，他们希望在什么时候、什么地点做，这些都是系统设计要考虑的重要因素。统设计要考虑的重要因素。第16页，

23、本讲稿共50页需求建模需求建模用例用例 用例是参与者想要系统做的事情。具体表现为用户如何使用系统用例是参与者想要系统做的事情。具体表现为用户如何使用系统来达到其目标的一组情节。来达到其目标的一组情节。例如在超市，例如在超市，“处理销售处理销售”的用例描述为：一个顾客携带欲采的用例描述为：一个顾客携带欲采购的商品到达收费口。收银员使用系统输入商品信息，系统给出商品购的商品到达收费口。收银员使用系统输入商品信息，系统给出商品的清单和累加值。顾客交款。收银员输入支付信息，系统对付款信息的清单和累加值。顾客交款。收银员输入支付信息，系统对付款信息进行计算，更新库存信息，并给出余额信息；系统打印购物清单

24、。顾进行计算，更新库存信息，并给出余额信息；系统打印购物清单。顾客得到收据，然后携带商品离开。客得到收据，然后携带商品离开。只有对用例表现出的情节进行真实、完整、准确地描述，才只有对用例表现出的情节进行真实、完整、准确地描述，才能捕捉到对系统需求有价值的东西。能捕捉到对系统需求有价值的东西。第17页，本讲稿共50页需求建模需求建模用例的粒度用例的粒度 指导原则指导原则1 1：在进行需求获取时，应专注于：在进行需求获取时，应专注于“基本业务过程基本业务过程”（EBPEBP）级别的用例。）级别的用例。基本业务过程：由一个人在某个时间某个地点执行的一项任基本业务过程：由一个人在某个时间某个地点执行的

25、一项任务，这个任务是对某一个业务事件的反应，而且可以增加可度量务，这个任务是对某一个业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致。的业务价值，并且能够保持数据状态的一致。用例没有层次结构的概念，即用例就是系统参与者要系统帮用例没有层次结构的概念，即用例就是系统参与者要系统帮助干的一件不可细分的事情，不存在把一个用例分解成粒度更助干的一件不可细分的事情，不存在把一个用例分解成粒度更小的用例。小的用例。EBPEBP级别的用例就是用户对系统的业务功能需求。在进行需求获级别的用例就是用户对系统的业务功能需求。在进行需求获取时，应主要关注取时，应主要关注EBPEBP级别的主要

26、用例，通常称他们为基本用例。级别的主要用例，通常称他们为基本用例。比基本用例粒度小的用例可能完不成比基本用例粒度小的用例可能完不成“可度量的业务价值可度量的业务价值”的一的一件事情，比基本用例粒度大的用例可能需要多个参与者去完成件事情，比基本用例粒度大的用例可能需要多个参与者去完成或多个时间段去完成。或多个时间段去完成。用例的命名必须具有明显的业务领域特征用例的命名必须具有明显的业务领域特征第18页，本讲稿共50页需求建模需求建模用例与目标用例与目标 参与者都有自己的目标，并使用系统来帮助自己实现目标。一个参与者都有自己的目标，并使用系统来帮助自己实现目标。一个EBPEBP级别上的用例通常被称

27、为一个用户目标级别上的用例，以强调用例应该级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户实现自己的目标。（这里强调帮助系统的用户实现自己的目标。（这里强调“用户目标级别用户目标级别”，不是，不是企业目标、组织目标、系统目标）。企业目标、组织目标、系统目标）。“防盗防盗”是企业级目标，不是用户级目标，因此不是一个是企业级目标，不是用户级目标，因此不是一个EBPEBP。“向系统证明身份并被验证向系统证明身份并被验证”也不是一个也不是一个EBPEBP，因为它没有增加，因为它没有增加可见的或可以度量的业务价值。可见的或可以度量的业务价值。“登录登录”是一个次要目标，是为其

28、是一个次要目标，是为其它有用的事情服务的。如它有用的事情服务的。如“我今天登录了我今天登录了2020次次”不会留下任何有价不会留下任何有价值的东西。值的东西。“用户管理用户管理”是系统目标，不是用户级目标。是系统目标，不是用户级目标。第19页，本讲稿共50页需求建模需求建模可观察的返回值可观察的返回值 每个用例的实例产生了对特定参与者而言可观察的返回值。每个用例的实例产生了对特定参与者而言可观察的返回值。可观察的返回值实际上是告诉参与者是否实现了其业务价可观察的返回值实际上是告诉参与者是否实现了其业务价值。如果一个用例不会告诉参与者任何东西，对参与者来说，值。如果一个用例不会告诉参与者任何东西

29、，对参与者来说，它没有任何价值，这肯定不是参与者的目标要求。它没有任何价值，这肯定不是参与者的目标要求。第20页，本讲稿共50页需求建模需求建模场景场景 场景：参与者与系统之间的一系列特定的活动和交互，通常称为场景：参与者与系统之间的一系列特定的活动和交互，通常称为“用例的实例用例的实例”。场景是使用系统的一个特定情节或用例的一条。场景是使用系统的一个特定情节或用例的一条执行路径。执行路径。一个用例就是一个描述参与者使用系统来达到目标的一组相关一个用例就是一个描述参与者使用系统来达到目标的一组相关的成功场景和失败场景的集合。例如，客户在超市选择购买的商的成功场景和失败场景的集合。例如，客户在超

30、市选择购买的商品后到收银台验货和付款中，品后到收银台验货和付款中，“收银员扫描仪录入商品数据收银员扫描仪录入商品数据顾客交顾客交款款收银员退余款收银员退余款打印购物清单打印购物清单”是一个场景；同样，是一个场景；同样，“收银收银员扫描仪录入商品数据员扫描仪录入商品数据顾客交卡顾客交卡收银员刷卡收银员刷卡打印购物清单打印购物清单”也是一个场景；也是一个场景；“收银员扫描仪录入商品数据收银员扫描仪录入商品数据顾客交卡顾客交卡收银员刷卡收银员刷卡（卡中钱不足时）顾客交款（卡中钱不足时）顾客交款收银员退余款收银员退余款打印购物清单打印购物清单”还还是一个场景。是一个场景。场景可分为主要场景和次要场景。

31、一个用例只有一个主要场场景可分为主要场景和次要场景。一个用例只有一个主要场景，但可以包含多个次要场景。每个场景表示参与者达到其目景，但可以包含多个次要场景。每个场景表示参与者达到其目标的一个情节。在主要场景中，如果与某一步所希望的事件不标的一个情节。在主要场景中，如果与某一步所希望的事件不同，就会引出一个次要场景。同，就会引出一个次要场景。第21页，本讲稿共50页需求建模方法需求建模方法识别主要参与者识别主要参与者 系统主要参与者就是系统的业务用户。在这里，我们反复强调系统主要参与者就是系统的业务用户。在这里，我们反复强调“业务用户业务用户”，因为开发一个软件系统的目的就是为他们的业务工作，因

32、为开发一个软件系统的目的就是为他们的业务工作服务的，这是系统的价值所在。服务的，这是系统的价值所在。在识别系统主要参与者时的首要工作就是列出所有系统最终用户。在识别系统主要参与者时的首要工作就是列出所有系统最终用户。任何人，只要他需要使用系统来行使自己的任何人，只要他需要使用系统来行使自己的“职责职责”，哪怕只有一，哪怕只有一小点小点“职责职责”，他就是系统的主要参与者。，他就是系统的主要参与者。主要参与者不是具体人，而是抽象的职能名。但也不能太抽象了，主要参与者不是具体人，而是抽象的职能名。但也不能太抽象了，以致无法辨认他们的脚色。以致无法辨认他们的脚色。有的主要参与者的大部分业务工作都可能

33、需要系统支持，如学校有的主要参与者的大部分业务工作都可能需要系统支持，如学校的的“教务管理员教务管理员”，有的主要参与者可能很少使用系统，如各个，有的主要参与者可能很少使用系统，如各个“审批审批”人员，当别人把所有工作都作了，他只需人员，当别人把所有工作都作了，他只需“审核审核”一下就行一下就行了。在识别主要参与者的过程中，最容易把这些大量的干了。在识别主要参与者的过程中，最容易把这些大量的干“审核审核”或或“审批审批”的主要参与者忽略掉，因为他使用系统的时间很少，就的主要参与者忽略掉，因为他使用系统的时间很少，就认为他不是主要参与者。认为他不是主要参与者。第22页，本讲稿共50页需求建模方法

34、需求建模方法识别系统业务识别系统业务 一个业务（有时呈业务过程）指一件有始有终要干的事。多个业一个业务（有时呈业务过程）指一件有始有终要干的事。多个业务之间可能没有明显的界限，需要对业务领域有深入的了解和丰富务之间可能没有明显的界限，需要对业务领域有深入的了解和丰富的经验积累。的经验积累。如教学管理的业务科分为：如教学管理的业务科分为：教学计划管理教学计划管理 教学安排教学安排 选课管理选课管理 考试管理考试管理 成绩提交成绩提交 成绩更正成绩更正 每个业务都有一个持续的时间区间，可能有多个人相互协作，每个业务都有一个持续的时间区间，可能有多个人相互协作，有多个业务活动按照一定顺序和规则进行。

35、有多个业务活动按照一定顺序和规则进行。第23页，本讲稿共50页用例建模方法用例建模方法业务流程建模业务流程建模 每个业务都有一个持续的时间区间，通过多人相互协作，使多个业每个业务都有一个持续的时间区间，通过多人相互协作，使多个业务活动按照一定顺序和规则进行，由此构成了完整的业务流程。其中的务活动按照一定顺序和规则进行，由此构成了完整的业务流程。其中的每一个业务活动的完成都对应着一个用户目标，实现这些目标的软件功每一个业务活动的完成都对应着一个用户目标，实现这些目标的软件功能都可以抽象为一个能都可以抽象为一个EBP级别的用例。级别的用例。业务流程分析是最关键的需求分析，是系统功能需求的主要来业务

36、流程分析是最关键的需求分析，是系统功能需求的主要来源，可以捕捉源，可以捕捉80%的功能需求。的功能需求。遵循的基本原则：每个业务活动只有一个人在特定的地点和特定遵循的基本原则：每个业务活动只有一个人在特定的地点和特定的时间完成。无论再小的事情，如果要多个人完成、或必须在多个的时间完成。无论再小的事情，如果要多个人完成、或必须在多个时间完成、或可能（必须）在多个地点完成，就要分解成多个业务时间完成、或可能（必须）在多个地点完成，就要分解成多个业务活动。活动。第24页，本讲稿共50页业务流程描述工具业务流程描述工具活动图活动图 椭圆：活动。椭圆：活动。分叉：并发转移分叉：并发转移 汇合：并发后的交

37、汇汇合：并发后的交汇 分支：条件转移分支：条件转移 合并合并 开始状态：可选开始状态：可选 结束状态：可选结束状态：可选 第25页，本讲稿共50页业务流程描述工具业务流程描述工具活动图活动图 泳道：把一个活动图的矩形框垂直分成若干个区域，每个泳道：把一个活动图的矩形框垂直分成若干个区域，每个区域为一个泳道，对应着一个业务参与者。将参与者参与的活区域为一个泳道，对应着一个业务参与者。将参与者参与的活动画在该矩形区域内。动画在该矩形区域内。带有泳道的活动图被认为是业务建模的最优秀的方法和工具。带有泳道的活动图被认为是业务建模的最优秀的方法和工具。学生教师系主任院长教务员第26页，本讲稿共50页业务

38、流程描述工具业务流程描述工具活动图实例活动图实例 学生教师系主任院长教务员提交成绩更改申请提交成绩更改意见更改更改确认更改确认成绩更改成绩更改查阅YN成绩更改业务流程成绩更改业务流程第27页，本讲稿共50页需求建模方法需求建模方法建立基本用例模型建立基本用例模型 如果活动图中每个活动只限于一个泳道，在一个地点一个时间内可如果活动图中每个活动只限于一个泳道，在一个地点一个时间内可以完成，则一个活动就是一个以完成，则一个活动就是一个EBP级的用例。级的用例。所谓基本用例指一个所谓基本用例指一个EBP级别的用例。级别的用例。基本用例模型指由基本用例构成的系统功能模型。基本用例模型指由基本用例构成的系

39、统功能模型。在基本用例模型中，除了参与者与用例之间的关联关系外，在基本用例模型中，除了参与者与用例之间的关联关系外，用例之间是相互独立的。这种独立性是用例完整性的体现。用例之间是相互独立的。这种独立性是用例完整性的体现。基本用例模型中的参与者就是系统权限管理中的角色。基本用例模型中的参与者就是系统权限管理中的角色。基本用例模型中的用例是系统权限分配的基本对象。基本用例模型中的用例是系统权限分配的基本对象。参与者与基本用例的关联关系就是系统中角色与资源（功参与者与基本用例的关联关系就是系统中角色与资源（功能模块）之间的映射关系。能模块）之间的映射关系。所以，基本用例模型是系统角色与权限管理设计的

40、依据。每个所以，基本用例模型是系统角色与权限管理设计的依据。每个用例是系统实现的基本功能单元。用例是系统实现的基本功能单元。第28页，本讲稿共50页需求建模方法需求建模方法-基本用例模型基本用例模型用例图用例图 用例图：以用例为基础的系统功能模型的图式表示，是用例模用例图：以用例为基础的系统功能模型的图式表示，是用例模型的抽象描述。型的抽象描述。用例图包括参与者（角色）、系统边界、用例、参与者与用例的关用例图包括参与者（角色）、系统边界、用例、参与者与用例的关联关系。联关系。系统边界用矩形框表示。通过矩形框的边线明确划分系统内系统边界用矩形框表示。通过矩形框的边线明确划分系统内和系统外。和系统

41、外。用例用椭圆表示，椭圆内放用例名。用例放在矩形框内，表示用例用椭圆表示，椭圆内放用例名。用例放在矩形框内，表示是系统内部元素。是系统内部元素。参与者用参与者用“稻草人稻草人”图符表示。参与者放在矩形框外，表图符表示。参与者放在矩形框外，表示参与者是与系统有关的外部元素，是系统的直接使用者。示参与者是与系统有关的外部元素，是系统的直接使用者。系统名放在矩形框内顶部。系统名放在矩形框内顶部。第29页，本讲稿共50页需求建模方法需求建模方法-基本用例模型基本用例模型用例图例用例图例提交成绩更改申请提交成绩更改意见成绩更改查阅更改确认成绩更改学生教务员教师系主任院长第30页，本讲稿共50页需求建模方

42、法需求建模方法-基本用例模型基本用例模型用例规约用例规约 一一个个用用例例在在功功能能上上具具有有完完整整性性。首首先先，从从系系统统的的角角度度而而言言，每每个个用用例例都都必必须须从从输输入入开开始始，直直到到产产生生结结果果输输出出给给参参与与者者，否否则则就就不不成成其其为为一一个个用用例例。其其二二，用用例例刻刻画画系系统统的的功功能能需需求求，但但它它不不是是简简单单地地记记录录功功能能需需求求，而而是是要要完完整整地地描描述述系系统统功功能能，包包括括用用例例执执行行的的步步骤骤、执执行行过过程程中中可可能能产产生生的的诸诸多多变变化化情情况况、错错误误情情况况和和异异常常情情况

43、况。所所以以，用用例例图图只只是是系系统统功功能能的的抽抽象象描描述述，还还必必须须通通过过用用例例规规格格说说明明进进行行详详细描述，才能充分反映用例所包含的内涵。细描述，才能充分反映用例所包含的内涵。第31页，本讲稿共50页需求建模方法需求建模方法用例关联用例关联 用例可以相互关联，用关系来描述用例之间的关联。关系只用例可以相互关联，用关系来描述用例之间的关联。关系只是一种组织机制，用于改善用例的交流和理解，减少文本的重复是一种组织机制，用于改善用例的交流和理解，减少文本的重复说明。说明。在用例建模中，为了使用例更简洁，在用例模型中引入了两在用例建模中，为了使用例更简洁，在用例模型中引入了

44、两种关系：种关系：包含关系（包含关系（includeinclude）（也称使用关系（）（也称使用关系（usesuses）扩展关系（扩展关系（extendextend）第32页，本讲稿共50页需求建模方法需求建模方法-用例关联用例关联包含关系包含关系 包含关系（包含关系（includeinclude或或useuse）指一个用例包含另一个用例。被包）指一个用例包含另一个用例。被包含的用例通常是包含用例的一部分，即是包含用例对应的功能需求的含的用例通常是包含用例的一部分，即是包含用例对应的功能需求的子功能。子功能。在用例模型中，如果发现某些用例具有部分相似的行为。在用例模型中，如果发现某些用例具有部

45、分相似的行为。则可以把这部分相似的行为抽取出来单独作为一个则可以把这部分相似的行为抽取出来单独作为一个“抽象用抽象用例例”供它们使用，由此构成了用例之间的供它们使用，由此构成了用例之间的“包含包含”关系。必须关系。必须强调被包含用例一定是包含用例的一部分，具体体现在：如果包含用强调被包含用例一定是包含用例的一部分，具体体现在：如果包含用例被执行，被包含用例一定被执行。例被执行，被包含用例一定被执行。指导原则：当两个或两个以上独立的用例中有重复的内容指导原则：当两个或两个以上独立的用例中有重复的内容而要想避免这种重复时，可以应用包含关系。而要想避免这种重复时，可以应用包含关系。在上例中，教师在上

46、例中，教师“提交成绩更改意见提交成绩更改意见”和主管责任人和主管责任人“更改确更改确认认”都要先都要先“查询成绩更改单查询成绩更改单”，所以可以把，所以可以把“查询成绩更改单查询成绩更改单”作为两个基本用例的被包含用例。作为两个基本用例的被包含用例。第33页，本讲稿共50页需求建模方法需求建模方法-用例关联用例关联扩展关系扩展关系 每个基本用例，都有一个基本的成功场景。除此之外，可能还每个基本用例，都有一个基本的成功场景。除此之外，可能还有其它成功场景。对其它成功场景，可以用一个扩展用例来描述。有其它成功场景。对其它成功场景，可以用一个扩展用例来描述。扩展关系指一个用例的某个行为可能被另一个用

47、例扩展。扩展关系指一个用例的某个行为可能被另一个用例扩展。如顾客在超市购买商品，一般用现金支付，但还有其他支付，如顾客在超市购买商品，一般用现金支付，但还有其他支付，如储蓄卡、代购卷支付。可以把如储蓄卡、代购卷支付。可以把“现金支付现金支付”作为作为“基本基本”行为，行为，把其他每种支付作为一个把其他每种支付作为一个“特殊特殊”行为。在用例建模中，把这种行为。在用例建模中，把这种“特殊特殊”行为作为扩展用例。行为作为扩展用例。被扩展的用例本身是完整的，扩展用例只是在遇到对应特殊情况被扩展的用例本身是完整的，扩展用例只是在遇到对应特殊情况时才可能被调用执行。时才可能被调用执行。指导原则：对插入基

48、用例的条件或可选行为建模。指导原则：对插入基用例的条件或可选行为建模。如如“提交成绩更改申请提交成绩更改申请”过程中，可以增加过程中，可以增加“保存申请草稿保存申请草稿”和和“读取申请草稿读取申请草稿”可以显得更灵活一些。可以显得更灵活一些。第34页，本讲稿共50页需求建模方法需求建模方法-优化后的用例建模优化后的用例建模提交成绩更改申请提交成绩更改意见成绩更改查阅更改确认成绩更改学生教务员教师系主任院长保存申请草稿读取申请草稿查询成绩更改单Includeextend第35页，本讲稿共50页领域建模领域建模基本任务基本任务 分析的基础是用例模型，最重要的是用例规格说明。分析的基础是用例模型，最

49、重要的是用例规格说明。分析的基本任务是从用例规格说明中提取出重要的业务领域概念，分析的基本任务是从用例规格说明中提取出重要的业务领域概念，建立领域模型。建立领域模型。领域模型是系统分析师对待开发系统所属领域的理解，是领域模型是系统分析师对待开发系统所属领域的理解，是对用例模型中所涉及的对象及其关系的抽象。因此：领域模型对用例模型中所涉及的对象及其关系的抽象。因此：领域模型不是与用户交流的工具，而是对领域抽象的工具，因为领域用不是与用户交流的工具，而是对领域抽象的工具，因为领域用户只能提出要求系统做什么，基本上不知道、也不懂得计算机户只能提出要求系统做什么，基本上不知道、也不懂得计算机领域有关对

50、象的概念。业务流程图和用例模型才是与用户交流领域有关对象的概念。业务流程图和用例模型才是与用户交流的工具。的工具。第36页，本讲稿共50页领域建模领域建模领域模型领域模型 领域是待建软件系统所面对的特定的业务领域。领域是待建软件系统所面对的特定的业务领域。领域模型是对实际业务领域的抽象，它领域模型是对实际业务领域的抽象，它“穿透穿透”用户想要的功用户想要的功能的表象，专注于分析业务领域本身，发掘重要的、最为能的表象，专注于分析业务领域本身，发掘重要的、最为稳固稳固的业务领域概念的业务领域概念，并建立业务领域概念之间的关系。，并建立业务领域概念之间的关系。在领域建模中，一个被管理领域对象就是一个