《需求提取与分析.doc》由会员分享，可在线阅读，更多相关《需求提取与分析.doc（62页珍藏版）》请在三一办公上搜索。
1、目录第1部分 需求概述11.1需求分析概述11.1.1需求定义11.1.2需求分析概述11.2需求分类21.2.1软件运行期质量21.2.2软件开发期质量31.2.3约束31.2.4不同类型需求对设计的影响31.3需求的层次性41.4需求的易变更性41.5需求捕捉的工具41.6需求分析内容51.6.1确定业务目标51.6.2确定业务领域范围及业务流程51.6.3建立用例模型51.6.4建立用例规约61.6.5确定系统非功能需求6第二部分 需求提取与需求建模72.1需求建模基本概念72.1.1参与者72.1.2用例72.1.3场景82.1.4用例规格说明92.2用例建模122.2.1识别系统主要
2、参与者122.2.2识别系统的业务和业务流程122.2.3业务流程描述工具活动图132.2.4建立基本用例模型142.2.5建立用例之间的关系152.3应用实例某汽车制造厂车辆订购用例模型162.2.1参与者分析162.3.2车辆订购业务流程分析业务建模172.3.3车辆订购基本用例模型182.3.4车辆订购用例模型优化192.4系统顺序图21第3部分 分析与领域建模233.1分析的基本任务233.2 领域模型的基本概念233.2.1领域模型233.2.2领域模型的表示233.2.3领域概念类识别253.2.4规格说明概念类273.3领域模型的重要性283.3类对象间的关系293.3.1继承关
3、系（Inheritance）293.3.2聚合关系303.3.3关联关系303.3.4关联类313.3.5受限关联313.3.6与时间间隔有关的属性的处理323.4建立领域模型323.5领域模型的优化323.6领域概念类的属性333.7使用包来组织领域模型333.8领域概念类与设计类、软件类的表示差别333.9应用实例343.9.1候选概念类提取343.9.2概念类间关系的建立353.9.3产品订购领域模型353.9.4产品订购包模型363.10 ER模型与领域模型之间的内在联系361数据库设计概述381.1数据库设计的基础性381.2 数据库设计模型381.3 基本概念381.4数据库设计的
4、内容391.5数据库设计中的误解392数据库概念模型设计402.1实体的识别412.2实体间联系的识别412.3概念模型设计应遵从的原则422.4应该注意的问题422.3数据库概念模型设计实例432.3.1五征产品订货432.3.2东风销售管理473数据库逻辑模型设计523.1转换原则523.2数据库逻辑设计应用实例533.2.1五征产品计划单数据库逻辑设计533.2.2东风汽车订购数据库逻辑设计543.2.3东风汽车销售数据库逻辑设计544数据库优化设计554.1表的合并554.3表的纵向分解564.4表的横向分解574.5中间表的使用585数据库索引585.1理论基础-数据库表索引的组织5
5、85.2数据库索引的建立585.3序列号的利与弊59第1部分 需求概述1.1需求分析概述1.1.1需求定义软件需求是“用户到底需要软件为他/她做什么”。IEEE对需求的定义：1.用户所需的解决某个问题或达到某个目标所要具备的条件或能力；2.系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力；3.上述第一项或第二项中定义的条件和能力的文档表述。RUP对需求的定义：需求描述了系统必须满足的条件或提供的能力，它可以是直接来自客户需要，也可以来自合同、标准、规范或其它有正规约束力的文档。根据上面的定义，需求的本质是：系统必须提供的能力和必须满足的条件。需求的表示形式是：
6、系统“应该做什么的规格说明”。需求分析的目的是：揭示系统应该做什么并达成一致。需求的最根本的挑战在于：交流并记录什么是真正需要的，并能够清楚地向用户和开发团队的成员讲解。1.1.2需求分析概述需求分析是软件工程学的经典术语之一，名符其实的含义是对用户需求进行分析，旨在产生一份明确、规范的需求定义。从这个意义上讲“分析是解决做什么而不是解决怎么做的问题”是无愧无挑剔的。通常用“做什么”和“怎么做”来区分“分析”和“设计”，但人们在“做什么”和“怎么做”的问题上总会出现理解上的含糊不清。问题的根源在于人们对软件工程中“分析”这个术语的含义有不同的理解-有时把它作为“需求分析”的简称，有时是指“系统
7、分析”，有时则作为需求分析和系统分析的总称。但迄今为止的各种分析方法（包括结构化分析和面向对象分析）中，真正属于需求分析的内容所占的分量并不大，更多的内容是给出一种系统建模方法（包括一种表示法和相应的建模过程指导），告诉分析员如何建立一个能够满足（由需求定义所描述的）用户需求的系统模型。分析员大量的工作是对系统的应用领域进行调查和研究并抽象地表示这个系统。确切地讲，这些工作应该叫做系统分析，而不是需求分析。它既是对“做什么”问题的进一步明确，也在相当程度上涉及到“怎么做”的问题。在一般的需求论述中，需求分析包括需求调研和需求分析。需求调研是需求获取（或捕捉）的过程，所以把需求调研称为“需求获取
8、”或“需求捕捉”，需求分析的目的和结果是对需求进行准确定义。所谓“准确定义”是弄清用户的真正需求，包括企业决策层的期望（开发目标）和直接使用系统的用户的需求（决策层人员可能不直接使用系统，但对系统的期望更大、更高，系统更应该努力去实现决策层的意图），把这些需求用文字和图表的形式描述出来，并且其描述没有二义性。但一般的自然语言很难做到无二义性描述，没有理论指导也可能使需求描述带有任意性，用特定的分析方法和对应的建模工具来“准确定义”需求以减少二义性，是普遍采用的方法。用这些分析方法和工具定义需求的过程称为“建模”，用结构化分析方法建立的需求模型称为系统的逻辑模型（功能模型），用面向对象分析方法建
9、立的模型称为领域（对象）模型。这些模型往往不是用于与用户交流，主要是用于系统开发人员之间的交流。在建立模型过程中和所建立的模型已经“在相当程度上涉及到怎么做的问题”，建模元素的选择和粒度的把握都与“怎么做”有关，只是在一个非常高的抽象层上考虑“怎么做”的问题，或者说是在意识上参杂了今后“怎么做”的因素。建立得好的需求分析模型与设计模型有很好的映射关系，也是在很大程度上考虑了今后“怎么做”的问题。在传统的软件工程中，需求分析作为软件生存周期的一个阶段，尽管有需求获取和分析的两个任务，这两个任务没有严格地划分时间段，在需求获取过程中要进行分析，在分析过程中要不断地进行调研和完善。那时，没有严格地区
10、分需求获取的工具是什么，需求分析的工具是什么，都是采用数据流图和数据字典。这两个任务总是交叉重复地进行，直到所建立的系统需求模型（数据流程图系统逻辑模型）达到用户要求为止，需求提取的工具和分析的工具都是相同的工具。而且也明确地指出需求分析报告主要用于用户交流，作为用户和开发者之间的契约，是需求验收的依据。在统一过程和UML提出后，特别是软件迭代开发方法提出后，把需求和分析分成了两个不同的阶段，有时也叫需求获取（或需求捕获）和需求分析，每个阶段有完全不同的目标和任务，包括建模工具和建立的模型都完全不同。需求捕捉阶段主要采用用例模型捕捉功能需求，需求分析阶段主要采用对象模型，建立领域对象间的协作关
11、系。但是，虽然把需求捕捉和需求分析划分为两个阶段，但它们却是相互伴随、交叉进行的，很难有区分的界限。需求获取所建立的模型主要用于与用户交流，需求分析模型是开发组织自己的文档，根本无法用于与用户交流，也不用于与用户交流。随着软件工程研究的发展，软件组件技术的广泛使用，软件的敏捷构造越来越受到关注。软件敏捷构造的核心是保持软件组件与领域业务的一致性，即组件与业务对齐。如果做到了组件与业务对齐，企业业务的重组只需要对软件组件间的关系重定义，这正是软件工程要达到的理想目标。要做到这一点，对软件需求提出了很高的要求需要从组织或领域体系结构要识别和捕捉领域需求。1.2需求分类需求可分为两类：（1）功能性需
12、求-系统应该提供什么功能。（2）非功能需求-系统的特定特性或约束。软件需求功能需求非功能需求质量属性约束运行期质量属性开发期质量属性系统的特定特性主要指系统的质量属性。系统质量属性可分为软件运行期质量属性和软件开发期质量属性。1.2.1软件运行期质量软件运行期质量指用户在使用软件过程中对软件质量的要求，包括易用性（人性化因素、帮助等）、性能（响应时间、吞吐量、准确性、有效性、资源利用率）、安全性、可伸缩性、持续可用性、互操作性、可靠性和鲁棒性。通常把软件运行期质量称为软件外部质量，即用户能够直接感受到的质量。易用性：指软件系统容易使用的程度。性能：指软件系统及时提供相应服务的能力。性能包括响应
13、时间（也称速度）、吞吐量（单位时间处理的交易数）、持续高速性（保持持续高速处理的能力-在网络系统中，这点是很难的）。一个系统可能保证典型操作的快速响应，但不一定能保证持续高速。性能和效率是同一问题的“表”、“理”的两个方面，性能为“表”，效率为“里”。效率指软件系统对CPU处理器和存储器这两大资源的处理效率。安全性：指软件系统同时兼顾向合法用户提供服务，以及防止非授权使用的能力。持续可用性：指软件长时间无故障运行的能力。如有的系统要求提供7*24小时服务就是持续可用性的要求。可伸缩性：指当用户数量和数据量增加时，软件系统维持高服务质量的能力。互操作性：指本软件系统与其它软件系统交换数据和相互调
14、用服务的难易程度。可靠性：软件系统在一定时间内无故障运行的能力。鲁棒性：也称健壮性、容错性。指软件系统在用户进行了非法操作、相连的软硬件系统发生了故障、以及其他非正常情况的时候，系统仍能正常运行的能力。有时也把持续可用性、鲁棒性也归类为可靠性。这时的可靠性就不是特指某种能力，而是一般意义下的可靠性。在软件开发过程中，需要对上述特性中特别指出的特性进行特殊设计，特别是要通过架构设计来保证，即成为架构设计关注的重点。1.2.2软件开发期质量软件开发期质量：为保证软件的可维护性而在软件开发过程中应该关注的软件质量属性，包括软件的可扩展性、可重用性、可移植性、易理解性、易测试性和可维护性。软件开发期质
15、量属性称为“软件内部质量属性”，即不深入到软件代码内部是无法觉察到的软件质量属性。这部分软件质量属性往往不会被用户通过需求的形式提出，而是软件开发团队应该自觉地保证，所以有的学者将其称为隐含质量属性。可扩展性：为适应新需求或需求变化为软件增加功能的能力。有时称为灵活性。可重用性：重用软件系统或其一部分的能力的难易程度。可测试性：对软件测试以证明满足需求规约的难易程度。在实际工作中主要指进行单元测试，插桩测试的难易程度。可维护性：在修改Bug、增加功能、提高质量属性等而定位修改点并适时修改的难易程度。可移植性：将软件系统从一个运行环境转移到另一个运行环境的难易程度。易理解性：设计被开发人员理解的
16、难易程度。任何一个开发期质量属性的满足都可能增加软件开发成本。1.2.3约束系统的约束是需求获取的重要内容。约束不是行为，是设计或项目的限制条件。这些限制条件也属于需求，但通常称为约束来强调其限制性。这些约束是在系统开发前已经存在的一些事实或因素，新系统的开发无法回避这些事实或因素。约束主要包括：系统开发的资源约束：如网络环境、操作系统、数据库管理系统、开发工具、硬件等。新系统的开发必须以这些现有资源为基础，软件架构（特别是系统的运行架构和物理架构）必须考虑这些资源的有效利用和限制（实现技术的限制）。接口约束：如与本系统关联的系统是哪些，其接口约束是什么。新系统可能接受其它系统提供的数据作为输
17、入，其输出数据作为其它系统的输入。操作约束：如系统操作环境中的管理要求。如身份认证必须通过第三方认证机构的认证，以网络为基础的业务处理，在网络不通的情况下如何处理业务等。政策约束：行业标准，企业标准，法律法规、政府规章等。在现行的软件开发中，软件需方单位的信息化往往不是从零开始，而是有相当的基础，他们对新系统的开发具有极大的约束。如开发的系统是某个大系统的子系统，大系统已经开发了一部分，该子系统必须满足于已开发部分的相互约束关系，必须为后续子系统奠定某些基础。新开发的系统可以直接从某个或某些现有系统中获得原始数据等。这些都是新系统开发最重要的约束。1.2.4不同类型需求对设计的影响功能需求影响
18、软件架构，而软件架构必须适应功能需求的变化。但功能需求并不决定软件架构。质量需求主要影响系统的架构设计，在功能需求确定的情况下，系统架构设计主要针对非功能需求。在软件设计中，软件架构设计对功能性需求的主要考虑是高适应性。约束性需求将直接影响系统的架构设计；此外，有的约束性需求将转化为功能需求，如“银行系统必须执行统一的利率”是对开发银行系统的一条约束，该约束使待开发的系统必须提供调整利率的使用功能；约束还可能转化为质量束性需求，如系统预期用户的计算机应用水平普遍不高，因此要求待开发的系统有较高的易用性。实践证明，忽略质量属性和约束性要求，必然导致系统失败。结论：软件架构要主动适应功能需求的变化
19、，要从根本上支持软件质量属性要求，必须遵守约束的限制。1.3需求的层次性组织的不同层次人员对需求有不同的要求。由不同层次人员的需求构成需求的三个层次：业务需求：组织要达到的目标业务目标用户需求：用户使用系统来做什么行为需求：开发人员需要实现什么对高层管理人员而言，希望软件系统能帮助他们达到业务目标。对系统实际使用人员而言，希望系统提供的能力能辅助他们更好地完成日常业务工作。对开发人员来说，为了满足用户诸多需求、或满足不同用户需求、或满足不同层次用户需求，而觉察到的需求（如果不补充这些需求，要满足用户觉察到的需求就显得比较困难）。高层管理人员的需求与系统实际使用人员的需求可以起到相互验证和印证的
20、作用。通过实际使用者的需求来印证达到高层管理人员的业务目标要求，从中可以发掘出一些需求。用管理者的业务目标要求来验证实际使用者需求的范围和合理性（业务流程）。需求层次的关注在于在需求之间建立起“可跟踪性”，避免因遗漏需求而造成软件“达不到要求”，也避免开发人员一厢情愿地为用户“制造”没有实际意义的无用功能。从需求的层次性看，需求并不完全是“用户的要求”，除了直接使用系统的“用户”的要求外，还包括并不直接使用系统的“高层管理人员”的要求，和开发系统的开发人员的要求。在系统开发过程中，他们的要求同样要得到满足。如果不关注“高层管理人员”的要求，系统开发就没有明确的目标，系统的功能将是零散而脆弱的，
21、极易受到变更的冲击。不满足开发人员的要求，软件的开发、维护和移植变得非常困难。开发人员、开发管理人员和维护人员非常关心开发期质量属性，但最终用户不会提出、一般也提不出这类质量要求。通常称这类质量属性为隐含质量需求。运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类质量属性，这些质量属性直接影响用户对软件产品的满意度。可以认为，运行期质量需求来自使用系统的用户，开发期质量需求更多来自系统维护人员，即开发的系统更便于维护。1.4需求的易变更性需求的变更是最让人头痛的事。任何需求变更意味着时间和金钱的消耗。同时需求变更引起对系统的修改将降低开发期质量属性的质量，并引入更多bug，从而降
22、低运行期质量属性的质量。软件架构设计的重要目标是：使软件架构能支持业务功能在一定范围内“随需应变”。不同需求的易变更性不同：功能需求最容易变化。在架构设计中，应划分少量长期稳定的功能，同时也应区分功能点本身趋于稳定，只是功能行为常常变化的功能。质量属性需求最为稳定。约束性需求的稳定性则稍差。技术趋势发生变化、法律法规重新界定和用户组织调整改组等都可能引起约束性需求变更。1.5需求捕捉的工具（1）传统工具-业务流程图和数据流程图对于复杂的系统，如管理信息系统，先通过业务流程图对业务过程进行描述，再将其转换为数据流程图。数据流图是系统业务功能及其数据流动的描述，是系统的逻辑模型。（2）UML提供的
23、工具-活动图和用例模型活动图可以有效地描述业务流程。用例模型包括用例图和用例规格说明。用例捕捉功能需求，其非功能性记录在用例规格说明中。后面只考虑UML描述工具。1.6需求提取内容1.6.1确定业务目标一个项目要被开发，要拨款立项，一定有它的业务目标。对于一个系统开发，业务目标占有非常重要的位置，它明确规定了建立该软件系统的最终目的。业务目标是组织或客户方的高层对未来系统的期望。业务目标的确定需要从企业信息化的全局来考虑和规划，使其开发的系统成为企业信息化系统中相对独立的、支持全局应用的、不可替代的重要组成部分。避免开发的系统解决的问题的层次太低，随着对信息化的要求的提高而很快过时。项目业务目
24、标通常由需方高层领导参与确定。要避免业务目标太抽象、太空洞，如“实现XX信息化”。一个项目管理系统的业务目标定义为：帮助项目经理更好地控制项目帮助项目经理更有效地分配资源帮助项目成员之间更流畅地协作还可以通过进一步细化业务目标，对每个业务目标列出一组高度概括的功能性需求。这种高度概括的功能性需求通常称为“特性”，表明“为了达到所期望的业务目标，未来系统应该在大方向上具有哪些方面的特性，每个特性再有一组功能来支撑。”如业务目标“帮助项目经理更好地控制项目”的特性有：任务管理跟踪进度查看报表任务分配和重分配对应每个特性的功能可以用“用例”来描述，即一个特性对应一组用例。1.6.2确定业务领域范围及
25、业务流程业务目标的实现需要通过具体的业务领域（有时也称职能域）以及具体的业务及流程来体现，使业务目标落实到实处。这将引起企业组织机构的调整和业务流程重组，以满足业务目标的要求。1.6.3建立用例模型所谓用户需求，就是用户希望软件系统能为他做什么。用例图技术是捕捉用户需求最合适的技术。用例名是用户需求最直观、最简便的反映。业务流程分析将捕捉到大部分用例，但不是全部用例，还需要补充一些与管理人员相关、但与具体业务活动不一定直接相关的用例和与信息查询相关的用例。1.6.4建立用例规约用例从一个较高层次描述了用户功能需求，解决了软件系统要“做什么”的问题，但还需要知道用户“希望如何做”的行为需求，否则
26、还是不知道如何开发系统。这里的“如何做”是从用户角度看他们“希望如何做”，而不是软件系统是如何做，所以还是属于需求捕捉的内容。用户“希望如何做”是软件系统“如何做”的依据。因此，用例规约中对系统行为的描述是以用户为中心展开的，便于与用户交流。在用例规约中，将详细定义用户对用例运行期间的质量要求和约束。不一定所有用例都要建立用例规约。有的用例使用“用例简述”就足够了。如果一个用例基本事件流对需求分析人员来说不是很清楚，而且可能涉及到非功能要求，就需要用“用例规约”来详细描述。在需求分析阶段可以通过用例界面的“预设计”可以更好地描述用例。真正设计是从实现角度来考虑问题，“预设计”是从与用户交流角度
27、来考虑问题。用例实现：用例实现不是真正编码实现用例对应的功能，而是考虑为了实现用例定义的功能，需要哪些类，以及这些类的对象之间如何交互来完成最终的功能。用例实现是从功能需求向设计方案过渡的纽带，通过分析一组关键用例的用例实现，可以获得未来系统的理想化的职责模型。这个职责模型是规划架构机制、满足高质量属性要求的基础。用例规约也称用例规格说明。1.6.5确定系统非功能需求通过对用例规约的分析和总结，归纳出系统的非功能需求，特别是用户对系统运行期的质量需求和约束。用例规约是系统运行期质量需求和约束的主要来源。一般来说，开发期质量属性需求主要来自系统开发人员和维护人员。第二部分 需求提取与需求建模2.
28、1需求建模基本概念需求提取的建模包括业务建模和用例建模。业务建模是确定项目对应的业务领域所包含的业务和业务流程，并用所选择的业务流程描述工具进行描述。用例建模是以用例为基本单位来描述用户的功能需求。与用例模型相关的概念包括：参与者，用例，场景2.1.1参与者参与者：直接与系统交互的外部事物所扮演的角色。该定义强调了3点：参与者对系统而言是外部的；参与者直接与系统交互，即参与者要直接使用系统来支持他的业务工作。强调参与者所扮演的角色，而不是特定的人或事物。一个特定的人可能扮演几种角色，可以作为系统的多个参与者。时间可以作为参与者，通常用时间发生器来表示。有些系统的功能是通过系统设定的时间来驱动的
29、。这里的参与者主要指系统业务功能的使用者。系统管理员不是这种意义的参与者。因为他不是使用系统功能完成与单位业务有关的工作。他使用系统的辅助功能实现对特定的人及其角色的管理，使参与者在自己角色范围内使用系统。每个参与者使用一个具有业务意义的名称命名。为了把系统的用户都考虑到，有时使用“主要参与者”和“次要参与者”的提法，主要参与者使用系统实现自己的业务目标。次要参与者为系统提供服务。系统管理员就是系统的次要参与者，其目标就是管理主要参与者，使他们按照事先的约定使用系统，保证系统有效运行。需求获取的首要任务就是识别主要参与者。主要参与者驱动了用例。用例总是有参与者开始的。用例从参与者的角度来编写的
30、。识别参与者是需求提取的首要任务，谁是系统的客户，他们需要系统做什么，他们希望在什么时候、什么地点做什么，这些都是系统设计要考虑的重要因素。2.1.2用例用例就是需求。从根本上说，用例就是功能需求。用例是一种被广泛使用的用于发现和记录需求的机制。被认为是一种最好地理解需求和描述需求的技巧。在统一过程中，用例被推荐作为发现和定义需求的主要方法。用例为项目相关人员提供了一种简单而易懂的机制来了解目标和系统需求。用例图描述的是软件系统为用户或外部系统提供的（系统级）服务，清晰地界定了系统的功能范围，有利于从宏观上反映系统功能的大局。1、用例的定义用例：参与者想要系统做的事情。具体表现为用户如何使用系
31、统来达到其目标的一组情节。例如在超市，“处理销售”的用例描述为：一个顾客携带欲采购的商品到达收费口。收银员使用系统输入商品信息，系统给出商品的清单和累加值。顾客交款。收银员输入支付信息，系统对付款信息进行计算，更新库存信息，并给出余额信息；系统打印购物清单。顾客得到收据，然后携带商品离开。只有对用例表现出的情节进行真实、完整、准确地描述，才能捕捉到对系统需求有价值的东西。2、用例的粒度参与者想要系统做的事情有大有小，有抽象的事情，有具体的事情。参与者想要系统做的什么样的事情那些可以作为一个用例，哪些事情又不能算一个用例。这实际上涉及到用例的粒度问题。指导原则1：在进行需求获取时，应专注于“基本
32、业务过程”（EBP）级别的用例。基本业务过程：由一个人在某个时间某个地点执行的一项任务，这个任务是对某一个业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致。用例不是类似“删除一个记录”或“打印一个清单”这样简单的小步骤。用例也不是一个需要好几天和很多对话才能完成的工作，例如“谈判一个供货合同”，它是能够在一个对话、几分钟或一个小时的时间就可以完成的任务。依照UP的定义，用例强调了能够增加可见的或可度量的业务价值，而且能够使系统和数据处于稳定和一致的状态中（表示该做的一件事做完了）。用例没有层次结构的概念，即用例就是系统参与者要系统帮助干的一件不可细分的事情，不存在把一个
33、用例分解成粒度更小的用例。后面讲到用例优化时，可能存在从用例中抽象出更小的用例，主要是从实现角度考虑，对用例进行某种优化措施，为系统设计提供更多的信息。EBP级别的用例就是用户对系统的业务功能需求。在进行需求获取时，我们应主要关注EBP级别的主要用例，通常称他们为基本用例。用例建模主要考虑EBP级别的用例。比基本用例粒度小的用例可能完不成“可度量的业务价值”的一件事情，比基本用例粒度大的用例可能需要多个参与者去完成或多个时间段去完成。为了获得EBP级别的用例，必须非常熟悉用户的业务流程，用户任何一项有意义的业务活动，如果需要系统的支持，就构成了一个EBP级别的用例。用例的命名必须具有明显的业务
34、领域特征，而不是计算机化的语言。3、用例与目标参与者都有自己的目标，并使用系统来帮助自己实现目标。一个EBP级别上的用例通常被称为一个用户目标级别上的用例，以强调用例应该帮助系统的用户实现自己的目标。（这里强调“用户目标级别”，不是企业目标、组织目标、系统目标）。“防盗”是企业级目标，不是用户级目标，因此不是一个EBP。“向系统证明身份并被验证”也不是一个EBP，因为它没有增加可见的或可以度量的业务价值。“登录”是一个次要目标，是为其它有用的事情服务的。如“我今天登录了20次”不会留下任何有价值的东西。“用户管理”是系统目标，不是用户级目标。4、可观察的返回值每个用例的实例产生了对特定参与者而
35、言可观察的返回值。可观察的返回值实际上是告诉参与者是否实现了其业务价值。如果一个用例不会告诉参与者任何东西，对参与者来说，它没有任何价值，这肯定不是参与者的目标要求。2.1.3场景场景：参与者与系统之间的一系列特定的活动和交互，通常称为“用例的实例”。场景是使用系统的一个特定情节或用例的一条执行路径。一个用例就是一个描述参与者使用系统来达到目标的一组相关的成功场景和失败场景的集合。例如，客户在超市选择购买的商品后到收银台验货和付款中，“收银员扫描仪录入商品数据顾客交款收银员退余款打印购物清单”是一个场景；同样，“收银员扫描仪录入商品数据顾客交卡收银员刷卡打印购物清单”也是一个场景；“收银员扫描
36、仪录入商品数据顾客交卡收银员刷卡（卡中钱不足时）顾客交款收银员退余款打印购物清单”还是一个场景。场景可分为主要场景和次要场景。一个用例只有一个主要场景，但可以包含多个次要场景。每个场景表示参与者达到其目标的一个情节。在主要场景中，如果与某一步所希望的事件不同，就会引出一个次要场景。2.1.4用例规格说明用例不是图表，而是文本文档。用例图表示对用例的抽象描述，用例规范化文档（用例规格说明）是对用例的详细描述，在UP中称为详述用例。用例图和详述用例就像数据流图和数据字典一样，被同时使用，共同构成用例模型。用例规范化文档是领域模型、设计模型、部署模型、设计模式选择的依据。用例描述主要包括主要成功场景
37、和扩展。主要成功场景：描述了能够满足项目相关人员兴趣的典型的成功路径，通常称为基本流程。扩展：描述与基本流程不一致的方面，如达到目标的不同选项。扩展也称为次要场景。主要场景一定对应一个基本的成功场景，主要场景中没有出错处理的内容。次要场景的基本目的是对应一个不同于主要场景某个点的不同的选项，其中可能包含出错处理。用例规格说明的格式有多种多样，表示的形式有单列式和双列式。单列式将参与者与系统的交互按步骤顺序列出。双列式将参与者的行为和系统的职责分开各列一列。表1-1的格式是常见的一种用例规格说明的格式。表1-1 用例规格说明格式表用例编号：用例名称主要参与者项目相关人员及其兴趣前置条件后置条件（
38、成功后的保证）主要成功场景（或基本流程）扩展（或替代流程）特殊需求技术与数据的变化列表发生频率待解决的问题下面“处理销售”用例规格说明就是这种风格。用例1：处理销售主要参与者：收银员项目相关人员及其兴趣：收银员：希望能够准确、快速地输入，而且没有支付错误，因为收银员如果少收了钱就要从他的薪金中扣除相应的金额。售货员：希望自动更新销售提成。顾客：希望购买过程能够省力，并得到快速的服务。希望得到购买证明，以便退货。公司：希望准确地记录交易，并满足顾客的要求。希望保证支付授权服务的信息被记录。希望有一定的容错性，即使某些服务暂时不可用（如远程信用卡验证）也能允许收款。希望能够自动启动，快速地更新账目
39、和库存信息。政府税务机关：希望能从每笔交易中提取税金。可能存在多个税务机关，如国家级、市级和县级。支付授权服务：希望按照正常的格式和协议收到数字授权的请求。希望准确计算给商店的应付款。前置条件：收银员必须已经被识别和授权。后置条件：存储销售信息；准确计算税金；更新账目和库存信息；记录提成；生成收据；记录支付授权的许可。主要成功场景：1.顾客携带购买的商品或服务到达POS机收费口。2.收银员开始一次新的销售。3.收银员输入商品标识。4.系统记录单件商品，并显示该商品的描述、价格和累加值。收银员重复34步，直到处理完所有商品。5.系统显示总值并计算税金。6.收银员请顾客付款。7.顾客支付，系统处理
40、支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的记账系统（进行记帐和提成）和库存系统（更新库存）。9.系统打印收据。10.顾客带着商品和收据离开。扩展：*a.任何时刻，发生以下状况，系统将失败： 为了支持恢复操作和正确地记帐，要保证所有交易的敏感状态和事件都能够从场景中的任何一步中恢复。1.收银员重启系统、登录，请求恢复上次状态。2.系统重建之前的状态。 2a.系统恢复过程中检测到异常： 1.系统向收银员指示错误，记录此错误，并进入一个清空状态。 2.收银员开始一次新的销售。3a.非法标识 1.系统指示错误并拒绝输入。3b.有多个具有相同类别的商品（其数量不是一个，而是多个），
41、不需要跟踪每个商品的唯一身份： 1.收银员可以输入商品类别的标识和数量。3-6a.顾客要求收银员从已输入的商品中去掉一个商品： 1.收银员输入商品标识并将其删除。 2.系统显示更新后的累加值。3-6b.顾客要求收银员取消交易： 1.收银员在系统中取消交易。3-6c收银员暂停销售： 1.系统记录销售信息。收银员能够在任何一台POS终端上恢复操作。4a.系统生成的商品价格不是顾客想要的价格（顾客抱怨太贵，要求减价）： 1.收银员重写价格。 2.系统显示新的价格。5a.系统检测到与外部的税金计算系统的通信故障： 1.系统要POS机节点上重启此业务，并继续。 1a.系统检测到服务无法重启。 1.系统指
42、示错误发生。 2.收银员可以手工计算税金并输入，也可以取消此销售。5b.顾客声称他们符合打折条件（例如，雇员或优先顾客）： 1.收银员发出打折请求。 2.收银员输入顾客的个人身份信息。 3.系统按照打折条款给出折扣价值。5c.顾客要求使用信用卡结帐： 1.收银员发出信用卡结帐请求。 2. .收银员输入顾客的个人身份信息。 3.系统按从信用卡上扣除货款。6a.顾客想用现金支付，但随身现金不足： 1a.顾客使用替代的支付手段。 1b.顾客告诉收银员：他要取消此销售，收银员在系统上取消此销售。7a.现金支付： 1.收银员输入收取的现金数额。 2.系统给出应找的余额，并弹出现金抽屉。 3.收银员放入收
43、取的现金，并拿出应找的余额给顾客。 4.系统记录现金支付。7b.信用卡支付： 1.顾客输入信用卡帐号。 2.系统向外部的信用卡授权服务系统发送支付授权请求，并请求批准此支付。 2a.系统检测到与外部系统的通信故障： 1.系统向收银员指示发生了错误。 2.收银员请求顾客更换支付方式。 3.系统收到批准付款的指示，并向收银员指示付款被批准。 3a.系统收到拒绝付款的指示： 1.系统向收银员指示付款被拒绝。 2.收银员请求顾客更换支付方式。4.系统记录信用卡支付，其中包括支付的批准。5.系统给出信用卡支付的签名输入机制。6.收银员要求顾客做出一个信用卡支付签名。顾客签名。7c.支票支付7d.记帐支付
44、7e.顾客出示优惠卷：1.在付款之前，收银员记录每张优惠卷，并从系统中扣除相应的价值。系统记录已使用的优惠卷以备记帐之用。1a.输入的优惠卷并不适用任意购买的商品。1.系统向收银员指示错误。9a.有的商品有回扣： 1.系统给出回扣表格，并为每个回扣商品提供回扣收据。9b.顾客要求礼物收据（不显示价格）： 1.收银员请求礼物收据，系统给出礼物收据。特殊要求：使用大型平面显示器上的触摸屏界面。文本信息要能够在1米之外看清。90%的信用卡授权机构的响应应在30秒内收到。在访问远程服务（如库存系统）失败的情况下保证可靠的恢复操作。支持多种语言显示。在步骤3和步骤7中可以插入新的业务规则。技术与数据的变
45、化列表：3a.商品标识可以用跳马扫描或键盘输入。3b.商品标识可以是UPC、EAN、JAN或SKU等不同的编码方式。7a.信用卡帐号信息可以使用读卡器或键盘输入。7b.记录在纸面收据上的信用卡支付签名。但我们预测，两年内会有许多顾客希望使用数字签名。发生频率：可能持续发生。待解决的问题：什么是税法的变化？研究远程服务的恢复问题。不同的业务需要什么样的定制？收银员是否必须退出系统后带走他们的现金抽屉？顾客是否可以直接用读卡机，而不必收银员代劳？内容解释： 1、用例应该包含什么？ 答案：用例应该包含满足所有的项目相关人员兴趣的内容。以相关人员的兴趣作为视点来观察，会为我们提供一种彻底的、系统化的程
46、序，用来发现和记录所有必须的行为。2、前置条件：规定了用例中的一个场景开始之前必须为“真”的条件。前置条件在用例中不会被检验，如收银员已经成功“登录”或“收银员已经被识别和授权”。3、后置条件：用例成功结束后必须为“真”的条件。这一“保证”应该满足所有项目相关人员的需要。4、主要成功场景：也称为“基本流程”，描述了满足相关人员兴趣的典型的成功路径，通常不包括任何条件和分支。5、扩展：比成功场景更重要，更复杂，不满足基本流程中的部分都要进行描述。6、特殊要求：主要描述与用例相关的非功能要求。7、技术和数据的变化列表：记录在技术上可能有变化的内容，往往描述的是“应该怎样做”，但它们对设计决策有重要影响。2.2用例建模用例模型是所有用例的集合，是系统功能和环境的模型用例模型设计步骤：识别系统主要参与者识别待开发系统所涉及的业
