资源描述
第8章 理解用户需求,本章主要介绍: 使用用例法描述和获取用户需求 使用事件-响应表方法来描述和获取用户需求,1,8.1 用 例 法,需求分析员们一直利用使用场景(usage scenario)来获取需求。 场景(scenario):是对系统的单个使用实例的描述。 以场景为中心的方法称为用例法。 注意：不要强行把所有需求都归入用例。用例可以揭示大部分功能需求，但通常不是全部。 用例描述了系统与外部角色之间的一系列交互。 角色(actor):指与系统交互以实现某种目的的人、软件系统或硬件设备。角色的另外一个名称是用户角色(user role)。 用例是目前广泛应用的统一软件开发过程的核心。 用例转变了需求开发的角度，传统的需求获取方式是询问用户需要用系统做什么，而现在则是讨论用户需要实现什么。用例更接近目标。 用例图(user-case diagram)提供了对用户需求的高级可视化表示。,2,图8.1 化学品跟踪管理系统用例图,方框系统边界 椭圆用例 小人图角色 连线角色与用例的交互,3,8.1.1 用例与使用场景,用例：是角色为达到某种重要目标而执行的一种离散、独立的活动。 用例是一组相关的使用场景，场景则是用例的一个特定实例。 用例描述中的基本内容包括： 唯一标识； 一个用例名，简要的说明用户的任务，采用“动词+对象”的形式； 用自然语言书写简短的文字描述； 一组前置条件，只有满足条件才能使用用例； 后置条件，描述用例成功完成后的系统状态； 一组带编号的步骤，描述从前置条件到后置条件过程中，系统与角色间的一系列会话步骤与交互。,4,每项用例都有一个场景被确定为事件的主干过程，也称为主过程、基本过程、普通流、主场景、主要的成功场景。 用例中的其他有效场景则被描述为分支过程或次要场景。 妨碍任务成功的条件称为异常，异常有时被视为一种分支过程。 用例中包含用例,8.1.1 用例与使用场景,如图8.2所示。流程图和活动图显示使主干过程分支为分支过程的判断点和判断条件。 用户可以将一系列用例串联成一宏用例来描述大型的任务,5,用例举例：酒店管理用例描述,用例编号：uc-1 宏用例名：酒店管理 创建人：大卫 最后修改人：大卫 角色：酒店管理员 描述：酒店管理员通过系统查询客房情况和今日房价，为住宿客户提供基本信息，在登记中保存客户的基本信息，在退房时计算房价和还房间 前置条件：酒店管理员登陆系统 后置条件：相关信息被保存 主干过程：查询客房情况，登记客户信息，安排客房，退房结账，删除退房客户信息，更新信息，计算当日收益，打印报表。 异常：客户信息有问题； 客户要求更换房间； 客户损坏了房间设施 备注：无,6,8.1.2 确定用例,可采用以下几种方法确定用例： 通过用例获取讨论会，明确有哪些角色，然后确定他们各自参与了哪些业务过程。确定哪些外部事件是系统必须响应的，将它们与参与的角色和特定用例关联起来。 用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色。 从已有的功能性需求推导出可能的用例。,7,8.1.3 编写用例,在调查阶段，应该首先考虑基本用例。 基本用例：是对某项任务或某种交互所作的简化、概括、抽象的描述，与技术和实现无关，基本用例体现了进行这种交互的真正目的或意图。 （具体用例：讨论用户与系统交互时采取的具体动作。） 1.常用方法 需求分析员将角色的每个动作和系统的每个响应记在便笺上，将便笺贴到活页挂图上，用这种方式引导讨论会的进行。 另一种方式是将用例模板从电脑投影到大屏幕上，在讨论过程中填完这份模板。,8,8.1.3 编写用例,图8.5 给出了用例开发过程中的事件序列。根据讨论会的结果，需求分析员为用例写出用例详细描述。,图8.5,9,2.用例详细描述 用例的核心是角色-系统会话步骤： 一种是在用例描述中进行会话步骤描述； 二是通过两列表格来描述用例会话。,8.1.3 编写用例,10,申领化学品用例描述,11,12,13,14,两列表格来描述用例会话 以申领化学品为例,15,8.1.4 用例与功能性需求,功能性需求是让用户得以执行用例并达成目标的系统行为。功能性需求是由软件开发人员实现的 用例是从角色的角度来描述系统行为，省略了很多细节。 因此，对实现用例时需要的详细的功能性需求，需求分析员应该给出详细的描述。 记录与用例相关的功能性需求有几种方式： 1. 只使用用例 是把功能性需求包含在每个用例描述中，另外还需要一个单独的补充说明来记录非功能性需求，以及所有不与特定用例相关的功能性需求。,16,8.1.4 用例与功能性需求,2.使用用例与软件需求规格说明 是写一个比较简单的用例描述，同时把从用例中推导出的功能性需求记录在软件需求规格说明中。 3. 只使用软件需求规格说明 根据用例或特性来组织软件需求规格说明，并把用例和功能性需求都记录在软件需求规格说明中。,17,8.1.5 用例的好处,使用用例能够让用户更清楚地了解新系统可以提供的功能。 用例法还有助于为需求划分优先级。优先级最高的功能性需求源自优先级最高的用例。优先级高的用例具有以下特征： 描述了系统实现的核心业务过程之一； 很多用户经常使用； 由重点用户类提出； 提供了为符合规定所需的功能； 其他系统功能依赖于该用例的存在。 用例法还有技术方面的好处，能够揭示重要的域对象，以及相互间的职责。,18,8.1.6 使用用例时应避免的问题,与所有的软件工程方法一样，用例法的应用也经常会误入歧途。要避免下面这些问题： 用例过多。 用例过于复杂 。 在用例中包含用户界面设计。 在用例中包含数据定义。 用户无法理解用例。 新的业务流程。 滥用包含和扩充关系。,19,8.2 事件响应表,另一种组织和记录用户需求的方法是确定系统必须响应哪些外部事件。 事件：是在用户环境中发生的某种变化或活动。 事件响应表(也称为事件表或事件列表)列出了所有这类事件和系统应对每个事件做出的反应。 如图8.7所示，有几种不同类型的系统事件，说明如下：,20,系统事件的类型,1.用户(人)执行的动作，该动作将激发用户与软件的会话。 2.控制信号、数据读取、或从外部硬件设备收到的中断信号。 3.由时间触发的事件。,图8.7系统事件-响应示例,21,汽车挡风雨雪刷系统的事件响应表,22,事件-响应表记录的是用户-需求层的信息。如果表中定义并标明了事件、状态和响应（包括异常条件）的所有可能组合，它还可以作为这部分系统的功能性需求的一部分。,我们的目标是将需求定义得足够精确，以便开发人员知道究竟要开发什么。,23,课 后 小 结 场景和角色的概念 使用用例来描述需求 记录与用例相关的功能性需求的种方式 用例的好处 使用用例时应避免的问题 事件-响应表描述需求,24,思考题： 参考图8.1 模板为你当前的项目写一个用例，用例中应该包括主干过程和异常。,25,
展开阅读全文