需求分析及用例编写入门.pptVIP

需求分析及用例编写入门 目录 Use Case 四十年 利用Use Case收集需求 案例：考勤卡 用例模式 Use Case 40年 --------1967 萌芽 1967-1987 发展 1987-1992 成熟 1992—— 广泛应用 Iva Jacobson 经典著作 ？——1967 萌芽 1967年Ivar Jacobson在定义爱立信AXE项目时开始使用Usage Scenarios来非形式化的描绘系统的结构。 开始使用场景，或者讲故事的模式，对需求进行非形式化描述 出现了最早形式的顺序图 1967-1987 发展 出现了 实体对象(entity/domain object)，用来描述用例和实体的关系，后来被取消了。 开始使用built-on来描述用例之间的关系，后来发展为 generalization和extend关系。 开始使用process来描述用例的实现，即活动图的前身。 开始出现block来对系统进行划分，后来发展成为子系统/模块。 1987年，Ivar Jacobson向OOPSLA87会议投稿时，在论文中第一次提出Use Case. 1978-1992 成熟 出现了inheritance（后来被修改为generalization）、extend、include来描述用例之间的关系. 明确用例、用例实现以及用例描述之间的关系。用例描述包括： 一段简单的介绍 一个控制流程 基本流程和可选流程 子流程 前置条件和后置条件 用例被用来指导分析、设计和测试 1992年，软件工程巨著：面向对象的软件工程——用例驱动的方法 发表 1992-今 广泛使用 作为UML标准的一个组成部分，Use Case开始被软件工程广泛使用 1994年，为了解决用例粒度问题，Ivar 提出一个用例应该有明确的“measurable value”和“particular actor”两个概念，并指出一个业务流程的主用例应该控制在20个以内。 1995年Rational公司并购Objectory AB，完成RUP的开发 1997年UML1.0正式发布，1998年发布UML1.3 2003年UML2.0发布 Ivar Jacobson UML之父，在Use Case的首倡者 Objectory 方法的发明者，也是瑞典 Objectory AB 公司的创始人 欧洲10大富人 经典著作 利用Use Case收集需求 准备收集需求 什么是好需求 寻找合适的人 开发一个可理解的需求 详细和完整地描述需求 如何检测不好的需求 准备收集需求 为系统建立一个清晰的前景 确定谁是这个系统的决策权威 什么是好需求？ 找到可以帮助你理解这个系统的人。 倾听这些涉众的描述，并从他们的角度来理解系统。 利用一个容易理解的模型来描述用户希望如何使用这个系统以及系统为他们提供的什么价值。 详细的描述系统和客户以及系统和外部系统之间的交互。 重构这个详细描述以保证它是可读易懂的。 寻找合适的人 领域专家 终端用户 涉众 开发一个可理解的需求 识别出使用这个系统的人群。 确定这些人群是如何从这个系统中获取价值。 用一个简单易懂的视图来描述这些用户以及他们如何使用系统。 寻找参与者 下列小组都是不同的参与者： 银行客户和出纳是不同的参与者，因为在银行系统中，他们有着非常不同的需求和权限。例如，客户不能看到别的客户的纪录。 推销员和配销职员是不同的参与者，因为他们对销售跟踪系统有不同的需求和访问方式。 学生和注册主任是不同的参与者，因为他们对课程注册系统有不同的需求和权限。 以下的小组不需要区分成不同的参与者： 在一个为选举收集选票的系统中，共和党人和民主党人不需要分成不同的参与者。对投票者来说，党派的区别可能是重要的，但是这并不影响他们如何使用这个系统。 在记录定量医疗数据，如心跳、血压和体温的系统中，没有必要将医生和护士分成不同的参与者。他们都能够获取和记录这些信息，在执行这个活动方面，他们没有什么不同。 在大多数游戏系统中，男人和女人没必要分成不同的参与者。 寻找用例 Well-focus: 这个用例是否能够带来一个单一的、离散的好处？ 你是否可以利用20-30个单词来描述这个好处？而且不用“和”与“与”。 用户是否能够仅通过在一次会话就能够完成这个用例？ 你能否想象在一个连贯的测试计划中，这个用例将是一个测试用例？ 有效和独立的： 用户是否获取有效的信息或者在某种可度量的程度上改变的系统。 用户是否可以执行这个用例，然后在有效的时间内停止使用这个系统？实际的情况可能并不是这样，但必须是可行的。 参与者和用例的关系 注册 用户 会员 详细完整地描述用例 用例描述：说明一个用例的概况和特征，例如，前置条件、后置条件、性能需求、保密要求以及部署约束 一个或者