需求分析_ch08_理解用户需求.pptVIP

化学品跟踪管理系统项目正在召开第1次需求获取讨论会，了解化学家使用系统来做什么。与会者包括：需求分析员Lori，她也担任协调人；代表化学家的代言人Tim；化学家用户类的另外两位代表Sandy和Peter；以及开发负责人Helen。Lori在开场白中感谢了大家的参与，然后便直奔主题。 “Tim,Sandy,Piter提出了15个用例，化学家在使用我们的系统时会执行这些用例。”她告诉讨论组。“我们将在最近几次讨论会上研究这些用例，明确在系统中实现哪些功能。既然你们把‘申领化学品’定为最优先的用例，Tim也已经为它写了一个简短的说明，那我们从它开始吧。Tim，请你谈谈如何想通过系统申领化学品。” “首先，”Tim说，“你应该知道只有得到实验室经理授权的人才能申领化学品。” “不错，这听起来像是一条业务规则，”Lori答道，“这有一幅挂图专门用来记录业务规则，因为我们没准儿还会发现其他业务规则。看来我们必须验证用户是否在被授权的名单上。”Lori早已为“申领化学品”这个用例准备了一幅活动挂图，一边说一边在“前置条件”一栏中写下：“用户通过身份鉴别”和“用户被授权可以申领化学品。”她接着问：“用户发出请求之前还需要满足其他的前置条件吗？” “在我向厂家订购某种化学品之前，需要了解库房中是否有这种化学品，”Sandy说。“所以，当我准备发出请求时，当前库存的数据库必须在线，这样才不会浪费时间。” Lori在先决条件中填上了这一项，在接下来的30分钟，她引导讨论组完成了关于如何申领一种化学品的讨论。她用了好几幅挂图，分别记录关于先决条件、后置条件、用户与化学品跟踪管理系统间交互步骤等信息。Lori提出问题：如果用户不是向库房申领化学品，而是向厂家订购，用例会有什么不同?她还问大家什么地方可能出错，系统应如何处理每个错误情况。半小时后，讨论组就用户如何申领化学品达成里一致的理解。于是他们转向了下一个用例。 设计实用软件的一个必要前提是清楚用户打算用它来做什么，多年来，需求分析员一直利用使用场景来获取需求，场景是对系统的单个使用实例的描述。 将以使用场景为中心的方法归纳为用例法，用于需求获取和建模。用例描述了系统与外部角色之间的一系列交互。角色指与系统交互以实现某种目的的人、软件系统或硬件设备。 用例源于面向对象的开发方法，然而，采用其他方法也可以使用用例，因为用户不在乎你如何开发软件。 用例转变了需求开发的角度，传统的需求开发获取方式是询问用户他们需要用系统做什么，而现在则是讨论用户需要实现什么。用例法 的目标是描述用户需要通过系统执行的所有工作。 用例图提供了对用户需求的高级可视化表示。理论上最终得到的用例集应涵盖用户希望获得的所有系统功能，实际上这是不可能的，但用例能比其他方法获取的需求更接近这一目标。 用例是角色为达到某种重要目的而执行的一种离散、独立的活动，是一组相关的使用场景，场景则是用例的一个特定实例。 用例描述中的基本内容包括： 唯一的标识 一个用例名，简要地说明用户的任务，采用“动词+对象”的形式 用自然语言书写的简短的文字描述 一组前置条件，只有满足这些条件才能使用用例 后置条件，描述用例成功完成后的系统状态 一组带编号的步骤，描述从前置条件到后置条件过程中，系统与角色的一系列会话步骤与交互 每项用例都有一个场景被确定为事件的主干过程，其他有效场景被描述为分枝过程。流程图和活动图能够显示使主干过程分枝为分枝过程的判断点和判断条件。 如果某个分枝过程本身就是一个独立的用例，可以通过该用例插入主工作流来扩充主干过程。 有时多个用例都包含一组相同的步骤，为了避免重复，可以定义一个单独的用例来包含这些相同的功能，然后由其他用例来包含这个子用例。 妨碍任务成功的条件成为异常。 在很多系统中，用户可以将一系列用例串联成一个宏用例来描述大型的任务。要做到这一点，前一用例的后置条件必须满足后一用例的前置条件。 可采用以下方法确定用例 首先明确角色，然后确定他们各自参与了哪些业务过程 确定哪些外部事件是系统必须响应的，将他们与参与的角色和特定用例关联起来 用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色 从已有的功能性需求推导出可能的用例。如果不能从某些功能性需求推导出任何用例，则要考虑是否真正需要它们 用例的讨论可以从确定该用例的受益角色、编写用例的简短描述开始。 然后定义用例的前置条件和后置条件，它们是用例的边界，用例的所有步骤都发生在这两道边界之间。 询问执行这项任务时应如何与系统交互，这样可以得出角色动作和系统响应序列，作为用例的主干过程 同样，可以定义分支过程和异常。 描述完用例后，如果没有人提出额外的改进、异常或特殊要求，就转入另一个用例。 不要指望通过一次马拉松式的讨论来完成所有的用例，或准确说明每个