第八章 需求工程之理解用户需求

用例和用户故事

• 用例描述一系列系统和外部角色之间的交互，让该角色能够由此获取一些价值
• 用例名通常使用动宾短语形式
• 选择强调并且具有描述性的名字能够清晰表达出用例为用户交付的价值
• 在敏捷开发项目中，用户故事是一个“从迫切需要该功能的人（通常是系统用户或客户）角度触发的一个短小而简单地额描述。”
• 作为<用户类型>，我想要<一些目标>，以便于<某种原因>。
• 用户故事的用户类型不（不仅限于人）对应与用例中的角色

用户故事与用例的区别

应用程序	示例用例	对应的用户故事
化学品跟踪系统	申请化学品	作为一个药剂师，我想要申请化学品，以便我可以做实验。
机场登机厅	办理登记手续	作为一个旅客，我想要办理登记手续，以便可以飞到我的目的地
灰机系统	开发票	作为一个小企业主，我想开发票，以便可以给某位客户开账单
在线书店	更新客户资料	作为一个客户，我想更新我的资料，以便可以在未来使用新的信用卡结账

用户故事与用例处理方式

• 业务分析师与客户代表合作，理解系统执行该用例时对话如何进行。
• 业务分析师通过用例模板收集用例，结构化这些信息。
• 在获取需求时，参考模板可以帮助参与者发现所有的相关信息。
• 通过用例说明，业务分析师可以获得开发人员必须实现的功能需求。
• 测试人员可以确定测试方法来判断用例是否正确实现。
• 一个用例可以一次迭代完成也可以分步迭代。
• 在敏捷项目时，用户故事可以做为一个占位符供开发人员、客户代表和业务分析师之间发起沟通。
• 沟通揭示了开发人员必须了解的额外信息。
• 通过沟通来打磨用户故事，引出一个更小但更有针对性的足以描述各个系统功能模块的故事集合。
• 在一个敏捷迭代中，过大的用户故事（称为“史诗”）会被切分为更小的故事，以便在一个迭代中实现。
• 用例为项目参与者提供用户故事所缺乏的结构和上下文
• 用例分析可以揭示多个用例设计类似的异常（或其他共性）问题，在应用程序中，这也许会被视为一个一致性错误处理策略。这样的共性问题很难通过用户故事来收集。

用例方法

• 用例描述的是系统和某个外部角色之间的一系列交互，这些交互为该角色提供了价值。
• 在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述
• 一个角色是指与系统交互执行某个用例的人或软件系统或硬件设备。
• 系统内部有事情发生时，谁或什么会收到通知？
• 谁或什么为系统提供信息或服务？
• 谁或什么帮助系统响应完成一个任务？
• 用例图是对用户需求的一种概要性可视化表达。

用例示例图

用户和角色

• 每个角色被系统视为一个特定用例的参与者
• 用户是真实的人或系统或硬件
• 角色是抽象的，仅用于用例执行

用例和使用场景

• 用例描述的是一个分散的、独立的活动，某个角色可以执行它来实现一些有价值的收益。
• 用例可能包含着一个共同目标的若干相关活动。
• 场景描述的是系统使用的方法。
• 用例时相关使用场景的一个集合，场景是用例的特定实例。
• 探索用户需求时，可以从一个通用的用例开始开发更多具体的使用场景，也可以从一个特定场景示例归纳出整个用例。
• 用例的基本要素
  • 一个唯一的id和一个简洁的名称（指明用户目标）
  • 一个简短的文字说明，用来描述用例的意图
  • 开始执行用例的触发条件
  • 用例开始需要满足的零个或多个前提条件
  • 一个或多个后置条件，描述用例成功完成后系统的状态
  • 一个由编号的步骤列表展示了角色与系统之间的交互顺序，一个从前置条件项后置条件的对话。

id和名称：	UC-4 申请化学品
创建人	Lorj 创建日期：2013年8月22日
首要角色	申请发起人 次要角色：买家、化学品仓库、培训数据库
描述：	申请人输入名称或化学品ID也可以通过导入结构化学绘图工具来制定自己需要的化学品。系统也给申请人提供了从化学品仓库获取或有申请人从供应商那订货的选择
触发条件	申请人表示他需要一种化学品
前置条件	1.用户的身份通过认证 2.用户被授权申请化学品 3.化学品数据库在线
后置条件	1. 申请被存储到CTS中 2. 申请被发送给化学品仓库或某个买家
正常流程	4.0从化学品仓库申请化学品； 1.申请人制定所需要的化学品； 2.系统列出化学品仓库中剩余的化学品； 3.系统给申请人提供查看所有化学品容器历史的功能； 4.申请人选择某个特定的容器或是要求供应商订货； 5.申请人输入其他信息来完成申请； 6.系统存储申请并通知化学品仓库
科学流程	4.1 从供应商申请化学品； 1.化学品的申请人搜索供应商目录； 2.系统显示供应商列表提供可用的大小、登记和价格的化学品； 3.申请人选择一个供应商，容器大小、登记和容器的数量； 4.申请人输入其他信息来完成申请； 5.系统存储申请并通知买方
异常	4.1 E1 化学品非商用； 1.系统显示信息：没有化学品供应商； 2.系统询问申请人它是项申请另一件化学品（3a）还是要退出（4a）； 3a.申请人要求申请另一件化学品； 3b.系统启动正常流程； 4a.申请人要求退出； 4b.系统终止用例
优先级	高
使用频率	每位药剂师每周大约5次，化学仓库人员每周200次
商业规则	BR-28，BR-31
其他信息	从所有支持化学绘制的软件包中，系统都可以用标准编码的形式导入一个化学结构
假设	导入的化学结构假定都是有效的。

前置条件和后置条件

• 前置条件定义系统开始执行用例之前必须满足的先决条件。
• 系统应该能够测试所有先决条件
• 先决条件可以描述系统的状态，但不会描述用户的意图
• 检查前置条件可以防止一些错误，终止错误的行为。
• 前置条件是使应用程序更加健壮的方法。
• 后置条件描述用例执行后系统的状态

扩展和包含

• 可以在用例图中展示两个用例之间的关系类型，分别是扩展和包含。
• 包含关系：当可以从两个或两个以上的用例中提取出公共行为时，则可以用包含关系来表示它们。
• 扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以使用扩展关系来表示它们。
• 包含关系中，去掉子用例，则基用例不能执行
• 扩展关系中，去掉子用例，不影响基用例的执行。
  

前置条件和后置条件要对齐

• 在许多应用程序中，用户可以将一系列的用例链接成一个“宏”用例从而描述一个更大的任务。
• 每一个用例都必须使系统保留一个状态，使得用户能够立即开始下一个用例
• 一个用例的后置条件必须满足任务序列中下一个用例的前置条件。
  ![[前置条件和后置条件对其.excalidraw]]

用例和业务规则

• 用例和业务规则是交织在一起的
• 一些业务规则会限制角色执行一个用例的全部或部分
• 也许只有特定的权限级别的用户才可以执行特定的可选流程
• 规则可能施加前提条件，使系统让用户继续进行之前必须先通过测试（条件验证）。
• 业务规则可以通过定义有效的输入或决定如何执行计算来影响正常流程中的特定步骤。
• 说明一个用例时，记录任何已知会影响用例的业务规则的标识符，并且支出用例每个规则会影响用例的哪一部分。

识别用例

• 首先确定角色，然后制定系统所支持的业务过程，并未角色和系统的交互活动定义用例。
• 创建一个特定的场景来说明每个业务过程，然后将这些场景概况为用例，并识别每个用例所设计的角色。
• 使用业务过程描述，“系统必须执行哪些任务来完成这一流程或将输入转换成输出？”这些任务可能就是用例。
• 识别系统必须响应的外部事件，然后将这些实践关联到参与活动的角色和特定用例。
• 使用CRUD分析来确定需要用例创建、读取、更新、删除或控制数据实体。
• 检查关联图，“在系统帮助下每一个外部实体想要达成哪些目标？”

探索用例

• 业务分析师捕捉角色的动作和相应的系统响应。
• 先确定受益于用例的用户，写下简短描述
• 估算使用频率提供了一个早期指标，可以从中了解并发使用和容量需求。
• 然后开始定义前置条件和后置条件（用例的边界）所有用例步骤都发生在这些边界内。
• 询问参与者如何构想与系统交互从而执行任务。
• 最后得出一系列角色行动和系统响应就成为用例的正常流程。
• 在写用例流程中的步骤时，避免使用指向特定用户界面交互的语言。
  

验证用例

• 从用例中推到出软件功能需求
• 不要等到需求规范完成之后再向用户、开发人员和其他关系人征求反馈意见，早期的审阅可以帮助改进之后的需求工作。
• 在需求开发早期，化学品跟踪系统的测试负责人开始从用例创建不依赖于实现和用户特定界面的概念性测试。
• 这些测试帮助团队系统在特定的场景中如何工作大臣共同理解。
• 测试使得业务分析师验证他们是否推到得出让用户执行每个用例所需的功能。
• 早期概念性测试想法比写代码、构件部分系统、执行测试时才发现问题更便宜、更快。
• 类似于敏捷方法中用验收测试来充实用户故事。
• 基于用例获取到的有
  • 功能需求列表
  • 对应的测试和分析模型
• 使用测试来验证功能需求，找出不能被需求集合“执行”的测试以及不能被测试覆盖的需求。
• 敏捷团队一般不用文档记录功能需求，更愿意创建测试验收。
• 项目的需求探索阶段考虑测试是一个很好的主意，但它都只能给你六次啊一个单一的描述，必须相信这是正确的。

用例和功能需求

• 软件开发人员不会实现业务需求和用户需求，实现的是功能需求，即系统的行为
• 用例描述了从用户角度看到的系统外部行为
• 用例并不包含开发人员写软件时所需要的信息。
• 业务分析师明确指定实现每个用例所需要的功能需求。
• 从用户需求视角到开发人员视角的分析师业务分时为项目增加的价值之一。
• 分析师以文档的形式记录这些功能需求到SRS中，SRS是按照产品[[0第一章 软件需求的本质#特性|特性]]组织的。
• 可以用多种方式把用例相关功能记录文档

只用用例

• 如果功能需求不够明显，就在每个用例说明里一一添加
• 仍然需要记录非功能需求和任何无法关联到具体用例的功能。
• 多个用例可能需要相同的功能需求。可以交叉应用出现在多个用例中的功能需求就好。
• 用例可以收集到用户需求文档中。

用例和功能需求

• 简单写下用例并以文档形式写下SRS或需求库中推到出来的各项功能性需求。
• 用例一改变，就可以快速找到受影响的功能需求
• 管理追溯性的最佳方式是需求管理工具。

只用功能需求

• 按用例或[[0第一章 软件需求的本质#特性|特性]]来组织功能需求，在SRS或需求库中同时包含用例和功能需求。
• 大多数用例的写的非常简洁，细节通过一组功能需求来制定说明
• 这种方式得不到一个单独的用户需求文档。

用例和测试

• 如果写的用例说明和功能需求都很详细，可能会有重复，特别是在正常流程中。
• 相处相当完整的用例说明，然后写验收测试来确定系统是否正确处理了用例的基本行为、可选的成功路径和各种可能出错的情形。

用例要避免的陷阱

太多的用例

• 如果用例激增，说明你很可能没有在合适的抽象层上写
• 不要对每个可能的场景都单独创建一个用例
• 用例往往多余也无需求和[[0第一章 软件需求的本质#特性|特性]]，但少于功能需求

高度复杂的用例

• 虽然不能控制业务任务的复杂性，但可以控制如何以用例来表示它们
• 选择一个贯穿于用例的成功路径将其命名为正常流程
• 使用可选流程描述其他指向成功的逻辑分支
• 使用异常来处理导致失败的分支

内含设计的用例

• 用例应该聚焦于用户在系统帮助下需要完成的事，而不是屏幕的界面。
• 强调角色和系统之间的概念性交互
• 如说“协同显示可选项”而不是系统显示下拉列表。
• 不要让UI设计来驱动需求探索。
• 使用界面草图和对话图帮助可视化角色与系统的交互，而不是作为公司的设计规范。

内含数据定义的用例

• 用例探索容易诱发数据讨论，思考交互过程中哪些数据元素作为输入和输出。
• 在项目范围级别的数据字典和数据模型中存储数据定义。

用户不明白的用例

• 如果用户无法将用例关联到他们的业务过程或目标，就会出现问题。
• 从用户的视角写用例，而不是系统视角，让用户审查用例
• 要达成明确而有效的沟通目标，就得尽可能让用例保持简单。

“以使用为中心”的需求有何好处

• 用例和用户故事的魅力来自于他们“以用户为中心”和“以使用为中心”的观点。
• 相对于“以[[0第一章 软件需求的本质#特性|特性]]为中心”的方法，用户对系统有更清晰的期望
• 开发用户需求有助于排定需求优先级
• 最高优先级的功能需求起源于最高优先级的用户需求。
• 用例或用户故事可能由于以下几个原因而具有更高的优先级
  • 描述了系统支持的部分核心业务过程
  • 许多用户会经常使用它
  • 某些受优待的用户类型需要它
  • 符合法规要求
  • 其他系统功能依赖于它的存在
• 用例还有一些技术收益，它们暴露了一些重要的领域对象和彼此的责任。
• 使用面向对象设计方法的开发人员可以将用例转变成对象模型，形成类和序列图等。