实用需求开发过程简述ppt课件

1、实用需求开发过程综述要旨 学会“以目标为基础、以用例为中心的三次迭代式需求分析的过程 领会“初始、细化、构造与移交四步走的路线第一次迭代初始）：学会进行项目目标分解、进第一次迭代初始）：学会进行项目目标分解、进行项目目标可研分析，构造提交项目目标模型，形行项目目标可研分析，构造提交项目目标模型，形成项目大纲成项目大纲第二次迭代细化）：学会进行用例图建模，进行第二次迭代细化）：学会进行用例图建模，进行客户需求分析，构造提供软件功能模型，形成客户客户需求分析，构造提供软件功能模型，形成客户需求文档需求文档第三次迭代构造）：学会对用例进行第三次迭代构造）：学会对用例进行“三位三位一一体的描述方式，分

2、析软件用例的动态行为，构造提体的描述方式，分析软件用例的动态行为，构造提交用例的业务流程图、实体类图、原型图，形成产交用例的业务流程图、实体类图、原型图，形成产品需求说明书。品需求说明书。需求验证移交）：学会从需求类型与属性角度评需求验证移交）：学会从需求类型与属性角度评估需求的质量，移交产品需求说明书估需求的质量，移交产品需求说明书初始：目标建模早期需求分析）初始：目标建模早期需求分析）目标方法在实际项目中的运用 第一步:建立业务目标到软件功能目标的转化模型 第二步：建立业务限制因素到软件非功能目标的转化 第三步：建立软件功能目标与非功能目标之间的双向束定关系第一步：业务目标建模第一步：业务

3、目标建模6项目目标业务目标1业务目标2业务目标业务目标m软件目标1软件目标2软件目标软件目标n软件目标3包含或派生角色划分包图每一个需求用一个包来表示，称为需求包。包与包之间用每一个需求用一个包来表示，称为需求包。包与包之间用组成关系关联起来。需求包可以逐层分解，构成分层用例组成关系关联起来。需求包可以逐层分解，构成分层用例需求结构。需求结构图有两种形式：需求结构。需求结构图有两种形式：计划订购书店信息系统书库管理入库出库盘库报损员工信息管理工资管理员工勤绩管理日常事务管理图书销售图书管理书店信息系统需求结构图 书店信息系统需求结构图 入库出库盘库报损书库管理员工信息管理员工勤绩管理员工工资管

4、理书库管理日常事务管理计划订购图书销售书店信息系统需求结构第二步：业务限制因素分析第二步：业务限制因素分析9限制因素限制因素1限制因素2限制因素限制因素m非功能目标1非功能目标2非功能目标非功能目标n非功能目标3包含或派生包含或派生第三步：两种底层目标的束定非功能目标1非功能目标2非功能目标非功能目标m功能目标1功能目标2功能目标功能目标n功能目标3束定束定为包进行用例建模细化：用例建模细化：用例建模用例建模的基本原理 软件目标是用例建模的依据。软件目标是用例建模的依据。 软件目标是用例引入的主要来源。软件目标是用例引入的主要来源。 用例图描述用例建模的结果。一个系用例图描述用例建模的结果。一

5、个系统的全部用例图构成该软件包的需求模统的全部用例图构成该软件包的需求模型。型。用例 用例用例(Use Case)(Use Case)是用户与系统之间，为是用户与系统之间，为达到确定目的所进行的一次交互活动。达到确定目的所进行的一次交互活动。用户向系统提供某些交互要求，系统向用户向系统提供某些交互要求，系统向用户反馈可见的结果。用例是系统功能用户反馈可见的结果。用例是系统功能需求的反映，一个用例描述用例的一项需求的反映，一个用例描述用例的一项功能。功能。 用例是系统功能需求的反映。用例是系统功能需求的反映。参与者用例边境包含关系用例图用例图(Use Case Diagram)(Use Case

6、 Diagram)用来描述软件系统向交互活用来描述软件系统向交互活动参与者提供的一组相关的功能。在一个用例图中，有动参与者提供的一组相关的功能。在一个用例图中，有一个或多个参与者与一个或多个用例相互关联。一个或多个参与者与一个或多个用例相互关联。参与者计划管理订单管理合同管理到货管理计划订购采购员计划员书目管理供书商管理事务管理功能用例图 办公员员工基本信息管理事务管理员工工资管理员工勤绩管理日常事务管理事务管理分解功能用例图 编辑员工基本信息浏览员工基本信息输出员工信息员工基本信息管理员工工资计算员工工资发放员工工资管理编辑员工勤绩信息员工勤绩统计员工勤绩管理浏览员工勤绩信息办公员包含关系依

7、赖关系构造：用例的动态行为分析构造：用例的动态行为分析用例分析是软件行为分析的手段用例分析是软件行为分析的手段 诸如：在线支付用例的三位一体描述 业务流程图 实体类图 界面原型图 : 客户在线购书支付界面在线购书管理器在线支付管理器图书库存信息用户支付记录图书销售记录1: 用户身份ID4: 确认在线支付购物车书目11: 用户选择确认支付方式18: 用户购书页面更新2: 获取用户购物车信息3: 返回用户购物车信息5: 确认在线支付购物车书目17: 返回购书成功信息8: 确认请求购书支付12: 请求支付9: 返回在线支付方式列表10: 返回支付方式列表6: 确认图书是否有库存7: 确认满足13:

8、确认户支付14: 返回确认支付成功15: 更新图书销售记录16: 返回更新后的购物车信息用例规约用例说明用例说明(UseCase Explanation)(UseCase Explanation)是对功能用例图中的用例做出的说明。是对功能用例图中的用例做出的说明。在用例说明中，需要描述用例的编号、称号、参与者和用例的功能以及在用例说明中，需要描述用例的编号、称号、参与者和用例的功能以及交互过程。（说明文本格式目前尚未统一，下表仅供参考。）交互过程。（说明文本格式目前尚未统一，下表仅供参考。） 用例卡模版称号。名称无疑应该表明用户的意图或用例的用途，如称号。名称无疑应该表明用户的意图或用例的用途

9、，如“研究班招生研究班招生”。 标识符标识符 可选可选 。唯一标识符，如。唯一标识符，如 UC1701 UC1701，在项目的其他元素如类模型中可用它来引用这个用例。，在项目的其他元素如类模型中可用它来引用这个用例。 阐明。概述用例的几句话。阐明。概述用例的几句话。 参与者参与者 可选可选 。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但在没有用例图时，它有助于增加对该用例的理解。有助于增加对该用例的理解。 形状形状 可选可选 。指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。

10、指示用例的状态，通常为以下几种之一：进行中、等待审查、通过审查或未通过审查。 频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。频率。参与者访问此用例的频率。这是一个自由式问题，如用户每次录访问一次或每月一次。 前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足。 后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足。 被扩展的用例被扩展的用例 可

11、选可选 。此用例所扩展的用例如果存在）。扩展关联是一种广义关系，其中扩展用例接。此用例所扩展的用例如果存在）。扩展关联是一种广义关系，其中扩展用例接续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带续基用例的行为。这是通过扩展用例向基用例的操作序列中插入附加的操作序列来实现的。这总是使用带有有 的用例关联来建模的。的用例关联来建模的。 被包含的用例被包含的用例 可选可选 。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例。此用例所包含用例的列表。包含关联是一种广义关系，它表明对处于另一个用例之中的用例所描述的行为的包含关系。这总是

12、使用带有之中的用例所描述的行为的包含关系。这总是使用带有 的用例关联来建模的。也称为使用的用例关联来建模的。也称为使用或具有或具有 (has-a) (has-a) 关系。关系。 假设假设 可选可选 。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检验这些假设，或者将它们变为决策的一部分，或者将它们添加到操作的基本流程或可选流程中。它们变为决策的一部分，或者将它们添加到操作的基本流程或可选流程中。 基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作基本操作流程。参

13、与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常进行时用例的工作方式，所以通常称其为适当路径方式，所以通常称其为适当路径 (happy path) (happy path) 或主路径或主路径 (main path) (main path) 。 可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。的路径。 修改历史记录修改历史记录 可选可选 。关于用例的修改时间、修改原因和修改人的详细信息。关于用例的修改时间、修改原因和修改人的详细信息。 风险风

14、险 可选可选 。如果存在，则为与此用例的开发相关的问题或操作项目的列表。如果存在，则为与此用例的开发相关的问题或操作项目的列表。 决策。关键决策的列表，这些决策通常由您的决策。关键决策的列表，这些决策通常由您的 SME SME 作出，并属于用例的内容。将这些决策记录下来对于作出，并属于用例的内容。将这些决策记录下来对于维护团体记忆库维护团体记忆库 (group memory) (group memory) 是相当重要的。是相当重要的。软件(产品)需求说明书1. 引言1.1 项目简介1.2 编写说明1.3 参考资料2. 目的 2.1 概述2.2 业务目标 2.2.1 总目标 2.2.2 业务目标

15、 2.2.3 限制性因素3. 软件功能结构 3.1 软件包结构图 3.2 软件包的说明4. 软件功能规约 4.1 概述 4.2 软件包的用例模型 4.3 用例规约分析说明5 软件功能限制因素 5.1 概述 5.2 非功能需求 5.3 设计约束需求6. 风险分析 6.1 软件面临的主要风险 6.2 风险的处理策略7. 遗留问题最终完整产品需求说明书目录样例最终完整产品需求说明书目录样例 移交：通过验证发布需求移交：通过验证发布需求需求验证的方法几种需求验证的基本方法。几种需求验证的基本方法。1) 1) 自查法自查法自查法由需求分析人员对自己所确定的用例需求进行审核和验证，自查法由需求分析人员对自

16、己所确定的用例需求进行审核和验证，纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种纠正需求中存在的问题。自查法又可以分为多种具体方法。第一种是小组审查法，即由一名分析人员向开发小组中其他人员介绍用例是小组审查法，即由一名分析人员向开发小组中其他人员介绍用例需求，小组中的成员进行提问，由介绍人进行解答。需求，小组中的成员进行提问，由介绍人进行解答。 2) 2) 用户审查法用户审查法分析人员可以把分析人员可以把 提交给用户，有条件时可以同时提交给用户，有条件时可以同时编写一份针对此需求的编写一份针对此需求的 并提交给用户，用户找出并提交给用户，用户找出不满意或认为不能实现的需求，双方再对这些有争议的需求进行讨不满意或认为不能实现的需求，双方再对这些有争议的需求进行讨论，最后达成一致认识。论，最后达成一致认识。 3) 3) 专家审查法专家审查法 专家审查法是指聘请业务领域、用例、政专家审查法是指聘请业务领域、用例、政策、法律等方面的专家对用例需求进行审查。策、法律等方面的专家对用例需求进行审查。 4) 4) 原型法原型法 原型法是对存在的有争议或拿不准的需求，原型法是对存