软件需求与分析教程（第八章）.pptVIP

第8章 理解用户需求 需求分析员们一直利用使用场景(usage scenario)来获取需求(McGraw和Harbison 1997)。场景(scenario)是对系统的单个使用实例的描述。 本章介绍如何使用用例和事件-响应表这两种方法来获取用户需求。 8.1 用 例 法 用例描述了系统与外部角色之间的一系列交互。 角色(actor)指与系统交互以实现某种目的的人、软件系统或硬件设备(Cockburn 2001)。角色的另外一个名称是用户角色(user role)。 用例源于面向对象的开发方法，用例是目前广泛应用的统一软件开发过程的核心(Jacobson、Booch和Rumbaugh 1999)。 用例转变了需求开发的角度，用例更接近目标。 用例图(user-case diagram)提供了对用户需求的高级可视化表示。 8.1.1 用例与使用场景 用例是角色为达到某种重要目标而执行的一种离散、独立的活动。 每项用例都有一个场景被确定为事件的主干过程(normal course)，也称为主过程、基本过程、普通流、主场景、主要的成功场景和快乐之路(happy path)。 用例中的其他有效场景则被描述为分支过程(alternative course)或次要场景(secondary scenario)(Schneider和Winters 1998)。 8.1.1 用例与使用场景 如图8.2所示。流程图和活动图能够显示使主干过程分支为分支过程的判断点和判断条件。 8.1.2 确定用例 可采用以下几种方法确定用例(Ham 1998；Larman 1998)： 首先明确有哪些角色，然后确定他们各自参与了哪些业务过程。 确定哪些外部事件是系统必须响应的，将它们与参与的角色和特定用例关联起来。 用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色。 从已有的功能性需求推导出可能的用例。 8.1.3 编写用例 将基本用例(essential use case)定义为“……对某项任务或某种交互所作的简化、概括、抽象的描述，与技术和实现无关，……体现了进行这种交互的真正目的或意图。” 需求分析员将角色的每个动作和系统的每个响应记在便笺上，将便笺贴到活页挂图上，用这种方式引导讨论会的进行。 另一种方式是将用例模板从电脑投影到大屏幕上，在讨论过程中填完这份模板。 8.1.3 编写用例 图8.5 获取用例的方法。 8.1.4 用例与功能性需求 软件开发人员实现的不是业务需求或用例，而是功能性需求。功能性需求是让用户得以执行用例并达成目标的系统行为。 记录与用例相关的功能性需求有好几种方式： 1. 只使用用例 是把功能性需求包含在每个用例描述中，不过你还是需要一个单独的补充说明来记录非功能性需求，以及所有不与特定用例相关的功能性需求。 8.1.4 用例与功能性需求 2. 用例与软件需求规格说明 是写一个相当简单的用例描述，同时把从用例中推导出的功能性需求记录在软件需求规格说明中。 3. 只使用软件需求规格说明 根据用例或特性来组织软件需求规格说明，并把用例和功能性需求都记录在软件需求规格说明中。 8.1.5 用例的好处 使用用例能够让用户更清楚地了解新系统可以提供的功能。 用例法还有助于为需求划分优先级。优先级最高的功能性需求源自优先级最高的用例。优先级高的用例具有以下特征： 描述了系统实现的核心业务过程之一。 很多用户经常使用。 由重点用户类提出。 提供了为符合规定所需的功能。 其他系统功能依赖于该用例的存在。 用例法还有技术方面的好处，能够揭示重要的域对象，以及相互间的职责。 8.1.6 使用用例时应避免的问题 与所有的软件工程方法一样，用例法的应用也经常会误入歧途(Kulak和Guiney 2000，Lilly 2000)。要避免下面这些问题： 用例过多。 用例过于复杂 。 在用例中包含用户界面设计 。 在用例中包含数据定义。 用户无法理解用例。 新的业务流程。 滥用包含和扩充关系。 8.2 事件—响应表 事件—响应表(也称为事件表或事件列表)列出了所有这类事件和系统应对每个事件做出的反应。 如图8.7所示，有几种不同类型的系统事件，说明如下： 用户(人)执行的动作，该动作将激发用户与软件的会话。 控制信号、数据读取、或从外部硬件设备收到的中断。 由时间触发的事件。 用表8.1中的模板为你当前的项目写几个用例，用例中应该包括所有的分支过程和异常。确定能够让用户成功完成每个用例的功能性需求。检查你现在的软件需求规格说明是否已包含所有这些功能性需求。 列出能够激励系统以某种方式运行的外部事件。生成一个