初始阶段PPT课件

1、初始不是需求阶段初始不是需求阶段 初始阶段初始阶段是建立项目共同设想和基本范围的 比较简短的起始步骤 。 它包括： 10的用例进行分析； 关键的非功能需求的分析； 业务案例创建； 开发环境的准备。 第1页/共124页4.1 什么是什么是初始阶段？ 在项目启动前，我们需要回答下列问题: 该项目的vision（设想/愿景） 和business case（业务案例） ? 是否可行? 购买 or 构造? 成本的大致估计; 是$10K，100K，1000K? 项目继续还是停止?第2页/共124页目的目的 该阶段的目的不是定义所有的需求，而是做 适当的调研（to do just enough invest

2、igation） 何谓“适当的”： 对新系统的整体目的和可行性形成一个合理的意见。 确定是否值得深入研究。 相对时间比较短，例如耗时一周到几周。 实际上，许多项目中，如果初始阶段超过1周，初始就失去了意义，因为初始阶段只需确定这个项目是否值得认真研究，而不是真正去深入研究。第3页/共124页 建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么。 确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案。 针对主要的场景，确定或者演示至少一个备选的系统结构。 对整个项目估计总成本和计划 (更详细的估计将安排在细化阶段中) 。 估计可能的风险 (不可

3、预计性的来源）。 为项目准备支持环境。第4页/共124页一句话概括一句话概括 初始初始： 预见项目的范围、设想和业务案例。 初始阶段要解决的问题： 涉众是否就项目设想基本达成一致；项目是否值 得继续进行认真研究？ 类比：石油行业中，勘探一个新地域经历以下几个步骤：1）确定是否有足够的证据或业务案例来证明可以进行勘测钻探。2）如果有，则进行测量和钻探。3）提供油田范围和预算信息。4）其他更多的步骤。第5页/共124页4.2 初始阶段会创建的制品初始阶段会创建的制品 设想和业务用例（Vision and Business Case）描述高阶目标与约束、业务案例，并提供执行摘要。 用例模型（Use-

4、Case Model）描述功能需求。在初始阶段，确定大部分用例名称，详细分析10%的用例。 补充性规格说明（Supplementary Specification）描述其他需求，主要是非功能性需求。初始阶段，多考虑关键的非功能性需求，其对架构将会产生主要影响。 词汇表（Glossary）关键领域术语和数据字典。 风险列表和风险管理计划（Risk List&Risk Management Plan）描述风险（业务、技术、资源和进度）及应对和缓解的方法。第6页/共124页 原型和概念验证（Prototypes and Proof-of-concepts） 澄清设想，验证技术思路。 迭代计划（Ite

5、ration Plan）描述第一个细化迭代的任务。 阶段计划和软件开发计划（Phase Plan & Software Development Plan）对细化阶段的持续时间和工作量进行粗略估计。工具、人员、教育和其他资源。 开发案例（Development Case）就待定项目，对UP步骤和制品进行定制的描述。在UP中，通常会为特定项目进行定制。在初始阶段可能要进行一些编程，其目的是创建”概念验证原型“，通过面向UI的原型澄清一些需求，以及为关键的”显示阻塞“技术问题做一些编程实验。第7页/共124页是否意味大量文档？是否意味大量文档？ 这些制品是可选的。有选择的创建有价值的制品。如其价值未

6、证实，则放弃。 形成初始的、概略的文档。而不是创建完整的规格说明。 创建制品重点不在于文档或图本身，而是其中蕴含的思想、分析和前期的准备。 会使用一些UML用例图，但绝不会引入大量图形。初始阶段，主要以文字方式表达需求。在即将进行作战的时候，我经常发现之前制定的计划根本派不上用场，但制定计划这项工作却是必不可少的。艾森豪威尔第8页/共124页以下初始阶段的任务是否正确以下初始阶段的任务是否正确 初始阶段持续几周或更长。 初始阶段定义大部分需求。 期望初始阶段的预算和计划是可靠的。 定义架构。 认为正确的工作顺序应该是：定义需求，设计架构，实现。 没有业务案例或设想制品。 详细编写所有用例。 没

7、有详细编写任何用例。第9页/共124页第第 5 章章 进化式需求进化式需求第10页/共124页5.1 需求需求 需求 每一个人都有需求。 在不同的时间我们有不同的需求。 需求驱动了软件过程。 正式的定义 “需求就是系统（更广义的说法是项目）必须提 供的能力和必须遵从的条件“。 在变更不可避免，涉众意愿不明朗的情况下，UP推崇用“一种系统的方法来寻找、记录、 组织和跟踪系统不断变更的需求” 。 通过迭代巧妙地进行需求分析，而不是草率和随意为之。第11页/共124页需求需求涉众涉众 （Stakeholder ） 涉众是与要建设的业务系统相关的一切人和事。 涉众是所有会受到项目结果重大影响的人。因而

8、必须用所提供的解决方案来满足不同的需要。 许多涉众都是系统的用户（间接或者直接），还有许多涉众是系统的经济型买主或支持者。 了解涉众的组成及其特定需要是开发有效解决方案的关键。 客户（或客户代表）客户（或客户代表） 用户（或用户代表）用户（或用户代表） 投资者投资者 股东股东 生产经理生产经理 买方买方 设计员设计员 测试员测试员 文档编写员等文档编写员等 第12页/共124页需求需求需求管理需求管理 需求管理是一种系统化的方法： 获取，记载、组织和跟踪系统的需求。 为客户和项目团队之间针对不断变化的需求建立 和维护协议。 挑战： 寻找、沟通和记住什么是真正需要的，并能够清 楚讲解给客户和开发

9、团队的成员。第13页/共124页需求需求功能需求功能需求 功能需求 系统必须提供的服务的描述，系统应该如何响应 特定的输入，系统在特定的情景下的行为。 举例： 用户能够搜索所有的数据集合或者从中选择一部分进行搜索。 系统需要为用户提供合适的浏览器从文档库中读取文档。 每一个订单需要分配一个唯一标识符，用户可以永久保存起来。第14页/共124页需求需求非功能需求非功能需求 对系统提供服务或者功能的约束，如时间约束，开 发过程的约束，标准等等。 许多需求是非功能性的，只能够描述系统的属性或 者系统环境的属性。 举例： 可靠性、可用性、有效性、可靠性、可用性、有效性、 可维护性、可移植性等可维护性、

10、可移植性等 。第15页/共124页5.2 进化式需求和瀑布式需求进化式需求和瀑布式需求 瀑布式定义的特性实际使用情况瀑布式定义的特性实际使用情况软件属于具有高变更率软件属于具有高变更率（25%）的新产品开发领）的新产品开发领域，具有大量新奇事物，域，具有大量新奇事物，需要大量的发现和探索。需要大量的发现和探索。项目第一天就开始竭项目第一天就开始竭力编程？力编程？迭代和进化式需求分析，迭代和进化式需求分析，引人频繁的涉众参与评估引人频繁的涉众参与评估和对局部结果的反馈。和对局部结果的反馈。第16页/共124页5.3 寻找需求可以采用的方法寻找需求可以采用的方法 除了变更，我们需要去寻找需求。 例

11、如： 与客户一同编写用例； 开发者和客户共同参加需求讨论会； 请客户代理参加焦点小组以及向客户演示每次迭代的成果以求得反馈。 UP欢迎任何能够带来价值并提高用户参与度的需 求启发方法。第17页/共124页5.4 需求的类型和种类需求的类型和种类 采用FURPS+ 模型 GRA92, 缩写FURPS 描述了需求的主要类别： 功能性（Functionality）：特性、功能、安全性。 可用性（Usability）：人性化因素、帮助、文档。 可靠性（Reliability ）：故障频率、可恢复性、 可预测性。 性能（Performance ）：响应时间、吞吐量、 准确性、有效性、资源利用率。 可支持

12、性（Supportability）：适应性、可维护 性、国际化、可配置性。第18页/共124页 FURPS+中的“+” 号意味着还有一些其他的约束，如: 实现（Implementation）：资源限制、语言和工具、硬件等。 接口（Interface）：强加于外部系统接口之上的约束。 操作（Operation）：对其操作设置的系统管理。 包装（Packaging)：例如物理的包装盒。 授权（Legal）：许可证或其它方式。第19页/共124页 质量属性（质量需求），包括可用性、可靠性、性能和可支持性。 进行架构分析时，质量属性对系统架构由极大影响，高性能、高可靠性需求将影响软件和硬件构件的选择及

13、其配置。第20页/共124页5.5 UP制品如何组织需求制品如何组织需求 关键的UP需求制品 用例模型一组使用系统的典型场景。主要用于功能（行为的）需求。 补充规格说明基本上是用例之外的所有内容。主要用于所有非功能需求，例如性能或许可发布。 该制品也用来记录没有表示(或不能表示）为用例的功能特性，例如报表生成。 词汇表定义重要的术语，数据字典记录了关于数据的需求，例如有效性规则，容许值等。对象属性、操作调用的参数、报表布局等。 第21页/共124页 设想概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档 ，用以快速了解项目的主要思

14、想。 业务规则领域规则，描述了凌驾于某一软件项目的需求或政策，这些规则是领域货业务所要求的，并且许多应用应该遵从这些规则。例如政府的税收法规。 UP中，制品可以存储在Web页、板报、各种可以想象到的载体上，在线的RUP含有制品模板，但这些模板只是可选的辅助工具，可以忽略。第22页/共124页第第6章章 用用 例例第23页/共124页6.1 用例概述用例概述什么是用例? “一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”（RUP）。 描述了从参与者（Actor）角度看系统（黑盒子）做了什么 WHAT。 用例是文本形式的情节描述,广泛应用于需求的

15、发现和记录工作中。第24页/共124页 用例的好处 从用户的角度获取操作性需求。 对系统的功能进行清晰而一致的描述。 系统测试的基础。 提供了从功能需求跟踪到系统中真正的类和操作的能力。第25页/共124页用例用例举例举例用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。摘要形式用例实例：处理销售处理销售： 顾客携带所购商品到达收银台。 收银员使用POS系统记录每件商品。系统连续显示累计总额，并逐行显示细目。 顾客输入支付信息，系统对支付信息进行验证和记录。系统更新库存信息。 顾客从系统得到购物小票，然后携带商品离开。上述用例不是图形，而是文本。常见错误就是注重于次要的UML用

16、例图，而非重要的用例文本。 第26页/共124页UP制制品品影影响响力力示示例例 p46第27页/共124页6.2 定义：参与者、场景和用例定义：参与者、场景和用例 参与者（actor） 是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如：收银员。 场景(scenario) 是参与者和系统之间的一系列特定的活动和交互。也称为用例实例（use case instance）。场景是使用系统的一个特定情节或用例的一条执行路径。例如：使用现金成功购买商品的场景，或者由于信用卡付款而拒绝照成的购买失败场景。 用例(use case) 就是一组相关的成功和失败场景集合，用来描述参与者如何

17、使用系统来实现其目标。例如：处理退货（主成功场景，交替场景 ）。第28页/共124页用例示例用例示例 处理退货-非正式形式的格式 主成功场景 顾客携带商品到收银台退货，收银员POS系统记录并处理每件退货 交替场景: 如果客户之前使用信用卡付款，而信用卡账户退还交易被拒绝，则告知顾客并使用现金退款。 如果系统中未查找到该商品的标识码，则提示收银员并建议手工输入标识码（可能标识码已经损坏）。 如果系统检测到与外部记账系统通信失败，则 第29页/共124页6.3 用例和用例模型用例和用例模型 UP在需求科目中定义了用例模型（Use-Case Model）。 这是所有书面用例的集合；这是系统功能性和环

18、境的模型。 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。 第30页/共124页6.4 动机：为什么使用用例动机：为什么使用用例 石头问题我要一块石头差不多，但我要小一点的很好，不过我要蓝色的嗯，没有那么小咳，还是原来那个好了难捕获 易变第31页/共124页对策对策难捕获难捕获易变易变 从用户视角看问题从用户视角看问题合理的结构合理的结构用例用例用例的各个成分将强迫你思考真正的需求！第32页/共124页动机：为什么使用用例动机：为什么使用用例 用例： 使工作保持简单的好方法。 使领域专家或需求提供者自己编写（或参与编写）用例成为可能。 强调了用户的目标和观点。 与查询系统特

19、性清单相比更强调以客户为中心。 用例的优越性在于能够根据需要对复杂程度和形式化程度进行增减删节。 第33页/共124页6.5 定义：用例是功能需求吗？定义：用例是功能需求吗？ 用例是： 需求，主要是说明系统如何工作的功能性或行为性需求。 FURPS+中的F。用例强调了”F”(功能性和行为性)。 在UP中，用例被推荐作为发现和定义需求的核心机制。 用例定义了系统行为的契约。 用例是真正的需求（尽管不是所有的需求）。第34页/共124页6.6 定义：参与者的三种类型定义：参与者的三种类型 什么是参与者：什么是参与者：是任何具有行为的事物，在所讨论系统（System under Discussion

20、,SuD）调用其他系统的服务时，还包括其自身。 参与者会出现在用例文本的活动步骤中。 参与者不仅是所扮演的角色，也可以是组织、软件和计算机。 第35页/共124页参与者的三种形式参与者的三种形式相对于SuD，有三种外部参与者： 主要参与者： 具有用户目标，并通过使用SuD的服务完成。通常用来发现驱动用例的用户目标。 协助参与者： 为SuD提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。协助参与者通常是为了明确外部接口和协议。 为何确定协助参阅者？为了明确外部接口或利益。 幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，

21、政府收税机构。通常是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。第36页/共124页参与者代表一个角色参与者代表一个角色 非具体的某个人或者某系统，某硬件。?第37页/共124页一个用户可以充当多种角色一个用户可以充当多种角色CharlieCharlie asstudentCharlieasprofessorProfessorStudent第38页/共124页6.7 表示法：表示法： 用例的三种常用形式用例的三种常用形式 不同形式化程度或格式编写 摘要简洁的一段式概要，通常用于主成功场景。 何时使用 在早期需求分析过程中，为快速了解主体

22、和范围使用。可能只需要几分钟编写。 非正式非正式的段落格式。用几个段落覆盖不同场景。 何时使用？同上。 详述详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。 何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构和高价值的用例。 第39页/共124页6.8 示例：详述风格的处理销售示例：详述风格的处理销售 详述用例是结构化的，它展示更多细节，并且更为深入。 最为广泛的格式（alistair.cockburn.us上的模板）： 用例名称：以动词开始 范围：界定了所要设计的系统 级别：用户目标级别或子功能级别（重用，如信用卡支付）。

23、主要参与者：调用系统，使之交付服务 涉众及其关注点列表：关注该用例的人及其需要。重要！能够让我们更清楚详细的系统职责 前置条件：值得告知读者的，开始前必须为真的条件 成功保证：值得告知读者的，成功完成必须满足的条件第40页/共124页 主成功场景：典型的、无条件的、理想方式的成功场景 扩展：成功或失败的替代场景 特殊需求：相关的非功能需求 技术和数据变元素：不同的I/O方法和数据格式 发生频率：影响对实现的调查、测试和时间安排 杂项：例如未解决问题。第41页/共124页第42页/共124页第43页/共124页第44页/共124页第45页/共124页第46页/共124页第47页/共124页第48

24、页/共124页第49页/共124页第50页/共124页第51页/共124页6.9 各小节的含义各小节的含义 绪言元素 范围 界定了系统。 级别：用户目标级别或子功能级别（重用，如信用卡支付）。 主要参与者：调用系统服务来完成目标的主要参与者。 涉众及其关注点列表：关注该用例的人及其需要。重要！能够让我们更清楚详细的系统职责。 前置条件：值得告知读者的，开始前必须为真的条件。 成功保证（后置条件）：值得告知读者的，成功完成必须满足的条件。第52页/共124页 主成功场景：典型的、无条件的、理想方式的成功场景。描述了满足涉众关注点的典型成功路径。通常不包括条件或分支。将所有条件和分支延迟到扩展部分

25、进行说明。场景记录以下三种步骤：1）参与者之间的交互。2）确认过程（通常由系统完成）。3）系统完成的状态变更（例如，记录或更改某事物）。第53页/共124页 扩展（或替代流程）：扩展通常占据了文本的大部分篇幅。扩展部分描述了其他所有场景或分支，包括成功和失败路径。 扩展场景是主成功场景的分支，因此能够以对应的步骤1N标识。编号3a,3b。 扩展由条件和处理两部分组成。 尽可能使用系统或参与者能够检测到的事件作为条件。如：5a系统检测到与外部税务计算系统服务的通信障碍。5a外部税务计算系统工作不正常。扩展可以针对一个步骤，也可针对一系列步骤，当一组步骤中出现相同条件时，可以表示：3-6a顾客要求

26、收银员从所购商品中去掉一项：1收银员输入商品ID并将其删除。2系统删除该项目并显示更新后的累计额。第54页/共124页 如果想描述任何步骤都可能发生的扩展条件，标识*a,*b。 执行其他用例场景 使用下划线标识所执行的第二个用例。第55页/共124页 特殊需求：相关的非功能需求、质量属性或约束。其中包含需要考虑的和必须包含在内的质量属性（如性能、可靠性和可用性）和设计约束（通常对于I/O设备）。 技术和数据变元表：需求分析通常会出现一些技术变元，这些变元是关于必须如何实现系统的，而不是实现系统那些功能。不同的I/O方法和数据格式。第56页/共124页第57页/共124页6.10 其他格式其他格

27、式 两栏或对话的格式。 不存在最好的格式。 各小节可以增加或删除，标题名称也可以更换，关键在于以各种格式详细地编写主要成功场景及其扩展。第58页/共124页第59页/共124页6.11 准则：以无用户界面的本质风格编写用准则：以无用户界面的本质风格编写用例例 以本质风格编写用例，摒除用户界面并且关注参与者的意图。 具体风格用例文本涵盖对用户界面的决策。在早期需求工作中应该避免。 第60页/共124页举例举例1.管理员标识自己的身份2.系统对此身份进行验证31.管理员在对话框中输入ID和口令（见图3）2.系统对管理员进行验证3.系统显示“编辑用户”界面（见图4）4. 假设在假设在 管理用户管理用

28、户 用例中需要标识身份和认证用例中需要标识身份和认证第61页/共124页系统认证系统认证这个系统认证这个系统认证编写简洁的用例，删除噪音词汇第62页/共124页系统记录销售系统记录销售1. 系统将销售信息写入系统将销售信息写入数据库。数据库。2. 系统对销售信息生成系统对销售信息生成SQL INSERT语句。语句。编写黑盒用例，不对系统内部工作、构件或设计进行描述，通过职责描述系统。 第63页/共124页采用参与者和参与者目标的视点 l用例创立者Ivar Jacobson:一组用例实例，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。 需求分析的两个态度：关注系统的

29、用户或参与者来编写需求，需求其目标和典型情况。关注理解参与者所考虑的有价值结果。第64页/共124页6.13 如何发现用例？如何发现用例？发现用例的基本过程如下：选择系统边界寻找主要参与者为每个参与者确定他们的目标定义满足用户目标的用例第65页/共124页如何发现用例如何发现用例选择系统边界选择系统边界 系统的边界用来说明构建的用例模型的应用范围。 描述了系统被包含在内的“信封”。 比如一台自助式售货机，系统内功能：售货、供货、提取销售款等功能，自动售货机之外的情况不考虑。 在许多情形下，系统边界是显而易见的。 但也并非总那么容易。 严格划分哪些由系统自动实现，哪些由其他系统或人工实现比较困难

30、。系统最初规模应有多大也应该考虑。 一般做法是先识别基本功能集，以此为基础定义一个稳定的精确定义的系统架构以后再不断地扩充系统功能，逐步完善。第66页/共124页如何发现用例如何发现用例寻找主要参与者和目标寻找主要参与者和目标 参与者是与系统交换数据的实体。参与者可以是用 户，外部的硬件或者另外一个系统。 准则： 首先集体讨论主要参与者，因为这样可以为将来 的研究建立框架。第67页/共124页 通俗地讲，参与者就是我们所要定义系统的使用者。 寻找参与者可以从以下问题入手，这些问题有助于我们抽象出系统的参与者： 系统开发完成之后，有哪些人会使用这个系统？ 系统需要从哪些人或其他系统中获得数据？

31、系统会为哪些人或其他系统提供数据？ 系统会与哪些其他系统相关联？ 系统是由谁来维护和管理的？ 可以从角色的角度出发考虑角色需要系统完成什么样的功能从而建立角色需要的用例。第68页/共124页 还可以通过事件分析发现参与者和目标：确定外部事件。 比如：输入销售商品这个外部事件的源参与者是收银员，目标是处理销售。 特殊的参与者系统时钟 需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。 我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。 第69页/共124页 系统边界决定了参与者第70页/共124页 在建模参与者过程中，记住以下要点： 参与

32、者对于系统而言总是外部的，因此他们在你的控制之外。 参与者直接同系统交互，这可以帮助定义系统边界。 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人和特定的事物。 一个人或事物在系统发生交互时，可以同时或不同时扮演多个角色。 第71页/共124页如何组织参与者和目标？两种方法：1.绘制为用例图，以目标作为用例名称2.首先写出参与者-目标列表，复审并精华之，然后绘制用例图。第72页/共124页第73页/共124页如何发现用例如何发现用例定义用例定义用例 一般而言，为每一个用户目标定义用例。 用例名称以动词开头。 将CRUD (create, retrieve, update, de

33、lete)这些分散的目标合并成一个CRUD用例: Manage 定义用例需要交流和参与 领域专家的参与非常重要。 迭代开发。第74页/共124页 发现有效用例 用例的粒度问题 大用例 我们的企业需要拓宽销售渠道。 整个系统就只有一个用例! 小的用例 输入口令。 系统中可能有成百上千个用例! 我们必须权衡。第75页/共124页 可以利用测试发现有用的用例 经验方法 老板测试 EBP测试 规模测试“一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”（RUP）。第76页/共124页老板测试 老板是付钱的人。 老板必须看到可量化的价值。你的老板问:”你

34、整天都做了什么？“你回答：”登录系统！“”登录系统“不会通过老板测试！这意味着该用例与达到可量化价值的结果没有太大关系，这也许是更低级别目标的用例，但不是需求分析所适用的级别。第77页/共124页EBP测试 EBP（Elementary Business Process）即基本业务过程，定义如下： 一个人于某个时刻在一个地点所执行的行为，用以响应业务事件。该任务能够增加可量化的价值，并且以持久状态留下数据。 例如：批准信用卡的信用额度；确定订购价格。l用例不是单独的一小步，如：删除一条商品项目或打印文档。相反，主场景应该是5-10个步骤。l用例不能持续数日或多个会话过程，例如“就供应者合同进行

35、谈判“。l用例是在一个会话过程中完成的任务。l用例可能只需要几分钟或一个小时就能完成。第78页/共124页规模测试 用例通常应该包括多个步骤 在详细描述的情形下，应该需要3-10页文本例如：输入商品ID ？第79页/共124页实例 就供应者合同进行协商。 用时长，适合做业务用例，而非系统用例。 处理退货。 能够通过老板测试；看上去与EBP类似；规模合适。 登录 如果一天都在登录，老板会不满意。 在游戏板上移动棋子。 单一步骤，不能通过规模测试。第80页/共124页 任何东西都有例外 EBP 原则也不是圣经。 有些时候我们会把多个用例中的公共部分单独成为用例。例如：“信用卡支付”。“认证用户”

36、可能无法通过老板测试，但是其步骤比较复杂，需要引起重视进行细致的分析。第81页/共124页6.14 应用应用UML: 用例图用例图 在UML里, 用例图是表达用例和活动者及其之间关系的载体。 用例图是模型图，用例图可包含用例，活动者以及它们之间的关系，这些关系可以是：include(包含）包含）extend （扩展）（扩展）generalization（泛化）（泛化） 用例图的用途是为软件系统、软件子系统、类的动态行为建模。它从两个方面对其建模对象的内容进行描述，即： 描述它们的边界。描述它们的边界。 对它们进行需求分析。对它们进行需求分析。第82页/共124页图 部分用例语境图第83页/共1

37、24页用例图用例图准则准则 绘制简单的用例图，并与参与者-目标列表关联。 制图。 不要倚重于制图，保持其简短 用例之重在于编写文本，用例图和用例关系在编写用例工作中是次要的。 初学者（或学院派的用例创建者）通常会犯的错误是：将用例图和图例关系作为当务之急，而不是编写文本。 世界级用例专家都对用例图和用例关系不予重视，而是着重于编写文本。第84页/共124页第85页/共124页6.15应用应用UML: 活动图活动图 活动图：有助于使工作流和业务过程可视化的图。 因为用例涵盖过程和工作流分析，活动图成为编写用例文本的有用的辅助措施。第86页/共124页Monopoly系统的用例图系统的用例图6.1

38、6 示例： Monopoly游戏不能通过老不能通过老板测试？板测试？观察者观察者 而不是而不是游戏者游戏者第87页/共124页用例：用例：Play Monopoly Game第88页/共124页6.17 在迭代方式中使用用例在迭代方式中使用用例 用例是UP和其他众多迭代方法的核心，UP提倡用 例驱动开发。 用例驱动 功能需求首先记录在用例（用例模型）中。 用例是迭代计划的重要部分，是预算的关键输入。 用例实现（use-case realization)驱动设计。 用例影响了用户手册和测试。 功能或系统测试应该符合用例的场景。 为重要用例的最常用场景创建UI”向导“或快捷方式可以方便执行常用任务

39、。第89页/共124页第90页/共124页编写用例的过程和语境设置第91页/共124页在迭代方式中使用用例在迭代方式中使用用例 初始阶段编写用例 确定目标和涉众，推测项目范围。 参与者-目标-用例表。 绝大部分需要关注的，复杂的，具有风险的用例采用摘要的形式编写。 其中的10%-20% 的用例代表了复杂的核心功能，需要构建核心架构或者在某些方面具有风险，采用详细的格式进行描述：如处理销售，处理退货。第92页/共124页 细化阶段编写用例 多次时间定量的迭代。 绝大部分的需求被识别和描述清楚。 在每一次迭代中，会有一次需求会议。 早期的会议关注于最重要用例的子集。 精化用户目标和用例列表。 以详述形式编写和重新编写更多的用例。 在细化阶段结束时，80-90%的用例被详细描述。第93页/共124页 构造阶段编写用例 在这个阶段可能涉及编写一些次要的用例，也可能