需求分析-ch08-理解用户需求课件

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

3a.申领人要求申领另一种化学品

4a.系统从新开始主干过程

3b.申领人要求退出

4b.系统结束用例1.0E.2买不到该化学品（发生于主干过程步骤5）系统显示信息：“没有厂商销售这种化学品。”系统询问申领人打算继续申领另一种化学品还是退出

3a.申领人要求申领另一种化学品

4a.系统从新开始主干过程

3b.申领人要求退出

4b.系统结束用例需求分析第8章：理解用户需求用例“申领化学品”的描述不是任何时候都需要详尽的用例描述，简略用例只是一段文字，叙述用户的目标及用户与系统的交互。详尽用例在以下情况很有用：在整个项目开发过程中，用户代表不能始终与开发人员密切合作。应用程序很复杂，具有较高的系统故障风险。用例描述是开发人员收到的最底层的需求细节。试图根据需求开发全面的测试用例地域分割较远的小组，合作时需要一份详细、共享的小组记录需求分析第8章：理解用户需求编写用例软件开发人员实现的不是业务目标需求或用例，而是功能性需求。功能性需求是让用户得以执行用例并达成目标的系统行为。有些软件专业人士认为用例就是功能性需求。然而，直接把用例交给开发人员去实现，结果都遇到了麻烦。用例是从角色的角度来描述系统行为，他们只看到系统对外部可见的行为，省略了很多细节，还有很多功能性需求未包含在角色与系统的会话步骤中。将用户对需求的意见解释为开发人员的相应任务，是需求分析员对项目的众多贡献之一。记录与用例相关的功能性需求的方式：只使用用例：把功能性需求包含在每个用例的描述中，不过还是需要一个单独的补充说明来记录非功能性需求，以及所有不与特定用例相关的功能性需求。用例与软件需求规格说明：写一个相当简单的用例描述，同时把从用例中推导出的功能性需求记录在软件规格说明中，用这种方法，需要在用例和相关的功能需求之间建立起可追溯关系。只使用软件需求规格说明：根据用例或特性来组织软件规格说明，并把用例和功能性需求都记录在软件需求规格说明中。需求分析第8章：理解用户需求用例与功能性需求用例之所以有用，在于它以任务和用户为中心。与以功能为中心的方式相比，使用用例能让客户更清楚地了解新系统可以提供的功能。用例能帮助需求分析员和开发人员理解用户业务和应用领域。根据用例法可推导出让用户能够执行某些已知任务的功能性需求，这有助避免出现“孤立功能”。用例法有助于为需求划分优先级。用例法还有技术方面的好处，能够揭示重要的域对象，以及相互间的职责。需求分析第8章：理解用户需求用例的好处用例过多：如果陷入用例爆炸性增多的困境，可能是抽象程度不够。用例过于复杂：无法控制业务的复杂度，但可以控制如何用用例来表达它们。正确的做法是用主干过程描述完成用例成功的路径，用分支过程描述其他通向成功的逻辑分支，用异常描述通向失败的分支处理。在用例中包含用户界面：讨论用例时应着重考虑角色与系统间概念上的交互，用户界面的细节等到设计阶段再考虑。在用例中包含数据定义：这种做法是项目参与者很难找到所需数据定义，还会造成重复定义。用户无法理解用例：表明用例中存在问题，应该站在用户角度而不是系统角度来编写用例。新的业务流程：如果所开发的软件用来支持尚不存在的新业务流程，用户很难为其提供用例。这时，需求获取不是为业务流程建模的问题，而是创造一个新流程的过程。这样做的风险很大，应该在业务流程改造之后再对新的系统进行设计