需求工程课件：第65章 用户需求获取活动的展开.ppt

基于用例/场景模型展开用户需求获取主要内容1.用户需求获取活动的展开2.场景/用例3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项用户需求获取活动的展开目标分析oo分析结构化分析场景/用例分析注意事项n要保持项目范围，不能有需求遗漏q参照系统特性，围绕系统边界设计获取活动计划n多轮次获取n根据内容合理安排获取方法n及时组织已获取需求，为后续获取提供指导多轮次获取要点n前景与范围阶段q准备：背景资料获取与分析q第一轮：问题分析（深入）q第二轮：高层解决方案制定（确认）n用户需求获取阶段q准备：明确主题与内容，准备材料q第一轮：明确任务与任务中主要问题（深入）q第二轮：明确任务细节，澄清困难内容（技巧、困难）q第三轮：明确解决方案（确认）n示例获取方法安排n面谈：常规方法n集体面谈：快速方法n头脑风暴：“发明”需求n不确定性：原型n情景性：观察n示例需求的组织n模型驱动方法（场景/用例模型）q整理和归类需求获取行为得到的信息 n模型是进行信息整理和归类的很好的框架依据q指导和组织需求获取行为的开展n模型可以用于指导后续需求获取行为的开展 q为详细信息的分析提供背景基础和上下文知识 n模型驱动方法则是侧重于前期需求阶段的方法，是传统需求分析方法的一个很好的补充 n承上启下q展开上一层（业务需求）q准备下一层的展开（系统级需求）主要内容1.用户需求获取活动的展开2.场景/用例1.基本概念2.组织特点3.层次性3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项为什么需要“用例与场景”n需求获取内容的处理？q获取笔录：权宜之计n用户需求+问题域特性n混杂，不清晰等特性q用例与场景n场景为单位n问题域特性  或者  用户需求+问题域特性n组织清晰场景n[Zorman1995]将场景定义为对系统和环境行为的局部描述n[Plihon1998]将场景定义为对行为或者事件序列的描述，序列中的行为和事件是系统需要完成的一个任务的特殊示例。

n[Jarke1996]认为场景包含有行为序列和行为发生的环境，环境描述了行为的主体、客体和上下文设置n以上的描述都不足以作为场景的准确定义，人们也很难给场景下一个非常准确的定义[Rolland1998a]场景n场景q具有重点描述真实世界的特征，它利用情景、行为者之间的交互、事件随时间的演化等方式来叙述性的描述系统的使用 用例与场景n以场景为单位组织用户需求（和问题域特性）n很受实践者欢迎q易于接受q易于使用q用例驱动！n方法多样，差异性很大q也可以用来处理 业务需求 和  系统级需求q还可以用来处理  设计问题、测试问题……场景n场景的用途主要内容1.用户需求获取活动的展开2.场景/用例1.基本形式2.组织特点3.层次性3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项ID:用例的标识，通常会结合用例的层次结构使用X.Y.Z的方式名称:对用例内容的精确描述，体现了用例所描述的任务，通常是“动词＋名词”用例属性包括创建者、创建日期、更新历史等参与者:描述系统的主参与者、辅助参与者和每个参与者的目标描述:简要描述用例产生的原因，大概过程和输出结果优先级:用例所描述的需求的优先级触发条件:标识启动用例的事件，可能是系统外部的事件，也可能是系统内部的事件，还可能是正常流程的第一个步骤前置条件:用例能够正常启动和工作的系统状态条件后置条件:用例执行完成后的系统状态条件正常流程:在常见和符合预期的条件下，系统与外界的行为交互序列分支流程:用例中可能发生的非常见的其他合理场景（该段经常与异常流程合并为扩展流程）异常流程:在非预期的错误条件发生时，系统对外界进行响应的交互行为序列相关用例:记录和该用例存在关系的其他用例。

业务规则:可能会影响用例执行的业务规则特殊需求:和用例相关的其他特殊需求，尤其是非功能性需求假设:在建立用例时所做的假设待确定问题:一些当前的用例描述还没有解决的问题n①它只考虑其他内容与功能需求之间的联系，却无法描述其他内容相互之间的联系，例如质量需求的相互依赖、界面需求的跳转、对外接口需求与质量需求的联系……n②它只考虑了存在联系的事实，却无法分析联系的合理性，例如有无遗漏功能需求、数据需求及业务规则是否充分、质量需求是否可行……n所以，虽然用例/场景的优点非常明显，但它毕竟只是一种组织形式，不能寄希望于单凭用例/场景模型解决所有问题[Gottesdiener2002]，目标模型、面向对象分析模型或结构化模型等其他的模型形式仍然是必要的主要内容1.用户需求获取活动的展开2.场景/用例1.基本形式2.组织特点3.层次性3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项ID3 名称商品库存管理优先级高参与者及目标（主参与者）总经理：库存分析，减少商品积压、缺货和报废（辅助参与者）收银员：记录销售及退货中的商品出入库情况（辅助参与者）业务经理：记录商品的批量入库与出库。

 用例描述系统准确记录商品的入库、出库、销售及退货信息，并以此为基础掌握库存实时数据，分析和预测未来商品出库量，发现未来可能出现的积压、缺货和报废，提醒总经理进行处理 主流程1.业务经理：商品入库2.收银员：销售处理，售出的商品出库3.总经理：库存分析，发现商品积压、缺货和报废 分支流程2a、收银员：退货处理，退回的商品入库2b、业务经理：商品批量出库 ID1.1名称销售处理优先级高参与者收银员，目标是快速、正确地完成商品销售，尤其不要出现支付错误触发条件 顾客携带商品到达销售点前置条件 收银员开始一个新的销售后置条件 准确完成支付过程，记录销售过程正常流程 1.收银员输入销售商品，系统记录并显示商品列表2.收银员结束销售，系统计算和显示总价3.收银员输入支付现金，系统计算并显示找零4.收银员完成支付，系统记录销售信息，并打印收据扩展流程 1-2a收银员可以删除一个已经输入的商品1.系统将该商品信息从记录中删除1-3a收银员可以取消销售过程1.系统放弃之前工作，结束销售处理业务规则 总价=∑商品单价×数量找零=支付数额-总价商品时的条形码符合……特殊需求 商品列表、总价、找零信息的显示要1米外可见。

输入商品可以使用键盘，也可以使用扫描仪ID1.1 名称 销售处理优先级高参与者及目标收银员，目标是快速、正确地完成商品销售，尤其不要出现支付错误触发条件顾客携带商品到达销售点前置条件收银员开始一个新的销售后置条件存储销售记录，包括购买记录、商品清单和付款信息；更新库存；打印收据正常流程1.收银员输入商品标识2.系统记录商品，并显示商品信息，商品信息包括商品标识、描述、数量、价格、特价（如果有商品特价策略的话）和本项商品总价3.0.5秒后系统显示已购入的商品清单，商品清单包括商品标识、描述、数量、价格、特价、各项商品总价和所有商品总价收银员重复1-3步，直到完成所有商品的输入4.收银员结束输入，系统计算并显示总价5.收银员请顾客支付账单6.顾客支付，收银员输入收取的现金数额7.系统给出应找的余额，收银员找零8.系统记录销售信息、商品清单和账单信息，并更新库存，打印收据扩展流程1a、非法标识：1.系统提示错误并拒绝输入1b、有多个具有相同商品类别的商品（如5把相同的雨伞）1.收银员可以手工输入商品标识和数量……业务规则总价=∑商品单价×数量找零=支付数额-总价商品时的条形码符合……会员积分=现金账单/10特殊需求1、系统显示的信息要在1米之外能看清2、输入商品可以使用键盘，也可以使用扫描仪。

扫描仪的接口是……3、如果在一个销售任务在第8步更新数据过程中发生机器故障，系统的数据要能够恢复到该销售任务之前的状态主要内容1.用户需求获取活动的展开2.场景/用例3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项基于场景/用例的方法n场景方法的分类场景定位n场景的形式：场景的表达模式  q描述（Description） n表示法的正规性 q非形式化语言、半形式化语言和形式化语言n媒介形式（Medium）q叙述性的自由文本、结构化文本、强限制文本、表格、图表、图像等   q外观n动态、静态、交互场景定位n场景的内容q主要关注点 n关于现在的 ，关于未来的 ，关于解决方案的 q环境范围 n系统内部，系统外部，系统和环境的交互q抽象层次 n具体的、抽象的、混合的q覆盖范围 n功能需求，非功能需求 q粒度 n整个业务过程；某个任务的完成过程；某个交互行为的详细处理步骤 q示例类型 n正常流程 ，异常流程 场景定位n场景的目的q描述（descriptive）n需求的文档化，n需求协商q探索（exploratory）n需求获取 n需求建模与分析 q解释（explanatory） n需求的验证 场景定位n场景的生命周期用例定位n用例q相关场景集合的叙述性的文本描述 q用例的概念是[Jacobson1992]最先在Objectory方法中提出的nUML将用例定义为“在系统（或者子系统或者类）和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务”[Rumbaugh2004]。

用例定位n场景与用例q用例是静态的结构化文本描述q用例的内容可以是对当前世界的描述，也可以是对将来确定的解系统的内部行为描述，还可以是对一种期待的解决方案的描述q用例可能会被用于描述系统内部的交互，也可能被用于描述系统和环境的交互，还可能会被用于描述行为的环境和背景q用例是类型层次的事件描述，主要用来描述功能需求n可以包含其他类型的需求q用例的内容既包含有正常流程，又包含有异常流程用例定位n场景与用例q用例可以是比较抽象的，用于描述整个业务过程；也可以是比较具体的，用于描述某个任务的完成过程；还可以是非常具体的，描述某个交互行为的详细处理步骤在需求工程的前期，会产生第一种和第二种用例描述，但最终都需要细化为最后一种形式的用例描述q用例可以用于各种目的的应用，包括描述、探索和解释（explanatory）需求获取和需求验证是它在需求工程中的主要应用阶段，它也可以用于需求的建模、交流和协商q场景的各种生命周期特征、应用和处理过程都适用于用例用例模型n用例模型q用例q参与者q关联q系统边界q多用例综合处理n不允许功能分解n抽取共同文本，实现复用n满足文本可扩展性 或 分解复杂文本n复用文本主要内容1.用户需求获取活动的展开2.场景/用例3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项基于场景/用例模型展开需求获取基于场景/用例模型展开需求获取n基于前景与范围建立初始用例模型1.依据系统用例图、目标模型建立初始用例/场景模型n（迭代）展开用例，描述用例规格1.据用例/场景模型指导获取，完善层次结构n选择合适的需求获取方法获得用例的详细描述q面谈、原型、头脑风暴、观察…2.使用用例/场景组织获取内容§用例规格3.分析用例/场景发现仍需获取的需求内容n选择合适的模型分析用例描述q类图、顺序图、实体关系图、业务规则模型……n验证场景/用例模型q评审用例描述•维护用例/场景模型•用新组织或修正的用例/场景完善用例/场景模型•依据用例/场景模型组织需求分析模型建立初始场景/用例模型参见确定前景与范围部分用例展开：指导获取n初始系统用例涉及的主题需要获取。

n概要用例描述中发现的新主题需要获取n具体用例中发现的模糊、不正确、不完备等细节内容需要再获取初始用例n正常流程（触发条件，每天晚上）1车队报勤，包括人员报勤和车辆报勤2如果有新任务，新建用车计划3根据用车计划，开具路单4 为路单开具出门证n扩展流程3a 没有用车计划，也有可能开路单3b开路单的车辆选择也可能不算报勤车辆4没有路单，也有可能单开出门证展开用例n正常流程（触发条件，每天晚上）1车队报勤，包括人员报勤和车辆报勤2如果有新任务，新建用车计划3根据用车计划，开具路单4 为路单开具出门证n扩展流程3a 没有用车计划，也有可能开路单3b开路单的车辆选择也可能不算报勤车辆4没有路单，也有可能单开出门证指导进一步获取编编号号名称名称参与者参与者优先优先级级M1主流程——车队报勤车队领导5M2主流程——新建用车计划调度室5M3主流程——新建路单调度室5M4主流程——新建出门证调度室司机5M5主流程——出门管理司机、门卫5M6主流程——回单操作司机；调度室5E1单独开具出门证调度室车队领导司机5展开展开正常流程1、车队领导请求报勤2、上报本车队所有车辆状态：系统显示车号，用户选择每辆车的状态3、所有车的状态录入后，用户提交，系统记录车的状态4、上报本车队所有人员的状态：系统显示本车队所有人员，用户选择每个人的状态5、如果人员状态为“待派”，系统显示状态为“待派”的本车队车辆列表；用户选择一辆车与此人对应，也可以没有车与带派人对应；用户完成输入后提交分支流程正常流程中步骤2和4：系统默认车辆（人员）状态为前一天的状态；允许用户选择多辆车（多个人），为其设定相同的状态特殊需求1、输入提示：必须填写的项目，输入框后标注*提示，界面最上方提示：*为必填项目2、正常流程2、4中，允许用户多选，即为多个车辆或人设定相同的状态用例展开：组织获取内容n面谈报告q面谈对象：调度人员谈话要点谈话要点被会见者观点被会见者观点主要任务主要任务主要的工作是车辆调度包括：车队报勤、开用车计划、开路单、开出门证具体流程具体流程 基本流程是1.每天晚上，车队会报第二天的勤，包括人员报勤和车辆报勤2.之后如果有新任务，会新建用车计划。

3.之后根据用车计划，开具路单，同时附带一张出门证分支流程分支流程主要的分支流程1没有用车计划，也有可能开路单2开路单的车辆选择也可能不算报勤车辆3没有路单，也有可能单开出门证用例展开：组织获取内容n用例IDX名称车辆调度优先级 高参与者及目标（主参与者）调度室：安排车队的每日调度计划（辅助参与者）车队领导：管理、批准调度计划（辅助参与者）司机：上报自己车辆的安排触发条件 每天晚上主流程1车队报勤，包括人员报勤和车辆报勤2如果有新任务，新建用车计划3根据用车计划，开具路单4为路单开具出门证分支流程3a 没有用车计划，也有可能开路单3b开路单的车辆选择也可能不算报勤车辆4没有路单，也有可能单开出门证用例展开：分析用例描述使用分析模型分析用例描述1.收银员输入会员编号；2.收银员输入商品；3.系统显示购买信息；收银员重复2-3步，直至完成所有输入4.系统显示总价和赠品信息；5.顾客付款；6.系统找零；7.系统更新数据；8.系统打印收据；9.顾客离开n异常流程？系统顺序图改进类图改进n收银员n会员编号n会员信息？n商品？n所有已输入商品？n总价？n赠品信息？n顾客会员n支付数额？n应找零数额？n销售？n数据？n收据？1.如果是会员，收银员输入客户编号2.系统显示会员信息，包括姓名与积分3.收银员输入商品标识4.系统记录并显示商品信息，商品信息包括商品标识、描述、数量、价格、特价（如果有商品特价策略的话）和本项商品总价5.系统显示已购入的商品清单，商品清单包括商品标识、描述、数量、价格、特价、各项商品总价和所有商品总价收银员重复3-5步，直到完成所有商品的输入6.收银员结束输入，系统计算并显示总价，计算根据总额特价策略进行7.系统根据商品赠送策略和总额赠送策略计算并显示赠品清单，赠品清单包括各项赠品的标识、描述与数量8.收银员请顾客支付账单9.顾客支付，收银员输入收取的现金数额10.系统给出应找的余额，收银员找零11.收银员结束销售，系统记录销售信息、商品清单、赠品清单和账单信息，并更新库存12.系统打印收据（格式为．．．）验证用例规格：CheckList主要内容1.用户需求获取活动的展开2.场景/用例3.场景/用例场景模型4.基于场景/用例模型展开需求获取5.场景/用例模型使用的注意事项场景/用例模型使用的注意事项n1. Don't bother with any other requirements representations.n2. Stump readers about the goal of your use case.n3. Be ambiguous about the scope of your use cases.n4. Include nonfunctional requirements and user interface details in your use-case text.n5. Use lots of extends and includes in your initial use-case diagrams.场景/用例模型使用的注意事项n6. Don't be concerned with defining business rules.n7. Don't involve subject matter experts in creating, reviewing, or verifying use cases.n8. If you involve users at all in use case definition, just "do it."n9. Write your first and only use case draft in excruciating detail.n10. Don't validate or verify your use cases.1. Don't bother with any other requirements representationsnIn short, using multiple views gives you a richer context for eliciting user requirementsnuse cases don't include details found in other models, such as data attributes and business rulesn第11章将详细讨论2. Stump readers about the goal of your use case.nUse cases are designed to model Actor interactions with your software. nHuman Actors don't interact with the system in order to CRUD rows in their databases. They don't think in terms of rows and databases. nRather, Actors think in terms of higher-level goals, such as finding out the discount to give a particular customer; and these goals, in turn, serve business objectives.3. Be ambiguous about the scope of your use cases.nUse-case scope mistakes are typically of two sorts: qEither the use case does not address a single Actor goal,q or the use case does not fall within your project's scope and should never have been detailed in the first place.4. Include nonfunctional requirements and user interface details in your use-case text.nA common mistake teams make with use cases is to incorporate nonfunctional requirements, such as response times and throughput information, and user interface or prototype details such as widget manipulation and references to windows, buttons, and icons.nyou should associate that information to the relevant use cases.5. Use lots of extends and includes in your initial use-case diagrams.nAlthough the use-case diagram with includes and extensions semantics might be useful for certain complex use cases, it is more productive to spend your time specifying use-case text, visualizing relationships within and between use cases, and using multiple requirements models.6. Don't be concerned with defining business rules.na serious misconception: Business rules should be at the heart of your use cases, providing the controls, reasoning, guidance, and decisions behind the processes the use case describes.nIf you don't explicitly define and separate your business rules, they will almost surely end up wrong, missing, or difficult to change.n7. Don't involve subject matter experts in creating, reviewing, or verifying use cases.qDirect end users, Business subject matter experts, CustomersqAt a minimum, end users should verify requirements by doing use-case walkthroughsn8. If you involve users at all in use case definition, just "do it."qUser requirements don't come from thin air.nbusiness goal, reverse-engineer, a list of customer complaints and change requests……qyou need to draft some requirements models, even if they're wrong or incomplete, before gathering users together.9. Write your first and only use case draft in excruciating detail.10. Don't validate or verify your use cases.nreview。