软件需求与分析教程(第五章)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第5章 确定产品前景与项目范围
业务需求位于需求链中的最顶层，这种需 求定义了软件系统的前景与范围。 用户需求和软件功能需求都必须符合业务 需求设定的前景和目标。 如果项目没有一个明确定义的方向，或者 不能让每个人充分理解这个方向，就必然 会走向失败。
2
5.1 通过业务需求定义前景
产品前景(product vision)将所有涉众统一到一个方向上。 前景描述了产品用来干什么，它最终会是什么样子。 前景关系到整个产品。当产品的战略定位或信息系统的 业务目标随时间发生改变时，前景也会随之变化，但这 种变化相对缓慢。 范围则只与一个特定的项目，或实现产品功能下一增量 的某次迭代相关，如图5.1所示。
6
5.2 前景与范围文档
解决方案的前景
(1)前景声明
用一个简洁的前景声明概括新产品的长期目标和意图。 用一个简洁的前景声明概括新产品的长期目标和意图。
(2)主要特性来自百度文库
为新产品的每一项主要特性或用户功能进行固定的、 为新产品的每一项主要特性或用户功能进行固定的、 惟一的命名或编号， 惟一的命名或编号，突出其超越原有产品或竞争产品 的特性。 的特性。
要采用阶段性的开发方式， 要采用阶段性的开发方式，需要决定推迟实现哪些 特性，并为后续的版本做出时间安排。 特性，并为后续的版本做出时间安排。
(3)限制与排除
定义项目包含的需求与不包含的需求之间的界线。 定义项目包含的需求与不包含的需求之间的界线。
8
5.2 前景与范围文档
业务背景 这一部分概述一些项目的业务问题，包括简要描述主要的 涉众类别，以及说明项目的管理优先级。 (1)涉众简介
(3)假设与依赖
记录构思项目和编写前景和范围文档过程中涉众所提 出的每一项假设。 出的每一项假设。
7
5.2 前景与范围文档
范围与限制 项目的范围定义了所提出的解决方案的概 念和范围。
(1)第一个版本的范围
概述计划在产品的第一个版本中实现的主要特性。 概述计划在产品的第一个版本中实现的主要特性。
(2)各后续版本的范围
前景和范围文档让你能够对是否应该将某 项被提议的特性或需求包括在项目中做出 判断。 一种是被提议的需求明显在范围之外。 另一种可能是需求显然是在定义好的项目 范围之内。 第三种可能是被提议的新需求不再范围之 内，但它很有价值，因而需要对项目范围 做出调整以容纳这一新的需求。
11
下一步
在你的项目中找几位涉众，请他们每人用本章介绍 的关键字模板写一个前景声明。看看他们所写的前 景相似程度如何。消除所有分歧并提出一个所有涉 众都赞成的统一的前景。 无论你是刚刚启动一个项目或是正处在项目开发期 间，都请根据图5.2中的模板写一份前景和范围文档， 然后让小组的其他成员检查这份文档。这样也许会 发现项目组成员对项目前景和范围的理解并不一致。 立刻解决这个问题，不要让它无限制地发展下去， 等待只会让问题变得更难解决。这个练习还能告诉 你如何对模板进行修改，让它最大限度地满足你们 组织内的项目的需求。 12
(1)背景 (2)业务机遇 (3)业务目标与成功标准 图5.2 (4)客户与市场需求 (5)业务风险
1. 业务需求 1.1 背景 1.2 业务机遇 1.3 业务目标与成功标准 1.4 客户与市场需求 1.5 业务风险 2. 解决方案的前景 2.1 前景声明 2.2 主要特征 2.3 假设与依赖 3. 范围与限制 3.1 第一个版本的范围 3.2 各后续版本的范围 3.3 限制与排除 4. 业务背景 4.1 涉及简介 4.2 项目优先级 4.3 操作环境
产品目录
版本 1.0 的 项目范围
版本 1.1 的 项目范围
版本 1.2 的 项目范围
版本 n 的 项目范围
3
5.1.1 相互矛盾的业务需求
开发者希望带为顾客提供一个激动人 心的高科技新方向。 而零售商需要的却只是一个简单的、 可直接投入使用的系统。 顾客则注重方便性和功能。 不同的目标、约束和成本因素构成了 这三方的制衡关系，导致了不一致的 业务需求。
(2)项目优先级
要想更有效地进行决策，涉众必须就项目的优先级达成一 要想更有效地进行决策， 致。
(3)操作环境
描述系统将用于什么环境，定义关键的可用性、可靠性、 描述系统将用于什么环境，定义关键的可用性、可靠性、 性能和完整性需求。 性能和完整性需求。 9
5.3 关 联 图
对范围的描述确立了正在开发的系统与周围所有 事物之间的界线和联系。关联图(context diagram)用图形方式说明了这一界线。 图5.3给出了化学品跟踪管理系统的关联图的一部 5.3 分。
对每类涉众的说明都应提供如下信息： 对每类涉众的说明都应提供如下信息：
从产品得到的主要价值或利益， 从产品得到的主要价值或利益，产品如何才能产生较高的客户满 意度。 意度。 可能对产品采取的态度。 可能对产品采取的态度。 感兴趣的主要特性和功能。 感兴趣的主要特性和功能。 必须遵循的已知约束。 必须遵循的已知约束。
化学家 要求提供 厂商目录 化学容器 对化学品 厂商目录 的需求 信息 库存报告 化学容器 库存更新 化学品仓库
采购人员 厂商订单状态 化学口厂商 的请求 化学口使用 报告 要求提供 使用报告 劳保部门 化学口 跟踪 管理系统
培训报告 请求 危险品 扫描条码 培训报告
条码阅读器
培训数据库
10
5.4 保持范围的适度
4
5.1.2 业务需求与用例
业务需求决定了应用的广度与深度。
广度(breadth)指应用能完成哪些业务工作(即 用例)。 而深度(depth)则说明将各项用例实现到何种程 度。
业务需求会影响用例及相关功能需求的实 现优先级。 业务需求对于需求的实现方式也有很大影 响。
5
5.2 前景与范围文档
前景与范围文档用于将业务需求收集整理到一个 文档中，为后续的开发工作打好基础。进行商业 软件开发的组织则常常创建市场需求文档(Market Requirements Documentation，简称MRD)。 图5.2给出了前景和范围文档的一个模板。 业务需求
业务需求位于需求链中的最顶层，这种需 求定义了软件系统的前景与范围。 用户需求和软件功能需求都必须符合业务 需求设定的前景和目标。 如果项目没有一个明确定义的方向，或者 不能让每个人充分理解这个方向，就必然 会走向失败。
2
5.1 通过业务需求定义前景
产品前景(product vision)将所有涉众统一到一个方向上。 前景描述了产品用来干什么，它最终会是什么样子。 前景关系到整个产品。当产品的战略定位或信息系统的 业务目标随时间发生改变时，前景也会随之变化，但这 种变化相对缓慢。 范围则只与一个特定的项目，或实现产品功能下一增量 的某次迭代相关，如图5.1所示。
6
5.2 前景与范围文档
解决方案的前景
(1)前景声明
用一个简洁的前景声明概括新产品的长期目标和意图。 用一个简洁的前景声明概括新产品的长期目标和意图。
(2)主要特性来自百度文库
为新产品的每一项主要特性或用户功能进行固定的、 为新产品的每一项主要特性或用户功能进行固定的、 惟一的命名或编号， 惟一的命名或编号，突出其超越原有产品或竞争产品 的特性。 的特性。
要采用阶段性的开发方式， 要采用阶段性的开发方式，需要决定推迟实现哪些 特性，并为后续的版本做出时间安排。 特性，并为后续的版本做出时间安排。
(3)限制与排除
定义项目包含的需求与不包含的需求之间的界线。 定义项目包含的需求与不包含的需求之间的界线。
8
5.2 前景与范围文档
业务背景 这一部分概述一些项目的业务问题，包括简要描述主要的 涉众类别，以及说明项目的管理优先级。 (1)涉众简介
(3)假设与依赖
记录构思项目和编写前景和范围文档过程中涉众所提 出的每一项假设。 出的每一项假设。
7
5.2 前景与范围文档
范围与限制 项目的范围定义了所提出的解决方案的概 念和范围。
(1)第一个版本的范围
概述计划在产品的第一个版本中实现的主要特性。 概述计划在产品的第一个版本中实现的主要特性。
(2)各后续版本的范围
前景和范围文档让你能够对是否应该将某 项被提议的特性或需求包括在项目中做出 判断。 一种是被提议的需求明显在范围之外。 另一种可能是需求显然是在定义好的项目 范围之内。 第三种可能是被提议的新需求不再范围之 内，但它很有价值，因而需要对项目范围 做出调整以容纳这一新的需求。
11
下一步
在你的项目中找几位涉众，请他们每人用本章介绍 的关键字模板写一个前景声明。看看他们所写的前 景相似程度如何。消除所有分歧并提出一个所有涉 众都赞成的统一的前景。 无论你是刚刚启动一个项目或是正处在项目开发期 间，都请根据图5.2中的模板写一份前景和范围文档， 然后让小组的其他成员检查这份文档。这样也许会 发现项目组成员对项目前景和范围的理解并不一致。 立刻解决这个问题，不要让它无限制地发展下去， 等待只会让问题变得更难解决。这个练习还能告诉 你如何对模板进行修改，让它最大限度地满足你们 组织内的项目的需求。 12
(1)背景 (2)业务机遇 (3)业务目标与成功标准 图5.2 (4)客户与市场需求 (5)业务风险
1. 业务需求 1.1 背景 1.2 业务机遇 1.3 业务目标与成功标准 1.4 客户与市场需求 1.5 业务风险 2. 解决方案的前景 2.1 前景声明 2.2 主要特征 2.3 假设与依赖 3. 范围与限制 3.1 第一个版本的范围 3.2 各后续版本的范围 3.3 限制与排除 4. 业务背景 4.1 涉及简介 4.2 项目优先级 4.3 操作环境
产品目录
版本 1.0 的 项目范围
版本 1.1 的 项目范围
版本 1.2 的 项目范围
版本 n 的 项目范围
3
5.1.1 相互矛盾的业务需求
开发者希望带为顾客提供一个激动人 心的高科技新方向。 而零售商需要的却只是一个简单的、 可直接投入使用的系统。 顾客则注重方便性和功能。 不同的目标、约束和成本因素构成了 这三方的制衡关系，导致了不一致的 业务需求。
(2)项目优先级
要想更有效地进行决策，涉众必须就项目的优先级达成一 要想更有效地进行决策， 致。
(3)操作环境
描述系统将用于什么环境，定义关键的可用性、可靠性、 描述系统将用于什么环境，定义关键的可用性、可靠性、 性能和完整性需求。 性能和完整性需求。 9
5.3 关 联 图
对范围的描述确立了正在开发的系统与周围所有 事物之间的界线和联系。关联图(context diagram)用图形方式说明了这一界线。 图5.3给出了化学品跟踪管理系统的关联图的一部 5.3 分。
对每类涉众的说明都应提供如下信息： 对每类涉众的说明都应提供如下信息：
从产品得到的主要价值或利益， 从产品得到的主要价值或利益，产品如何才能产生较高的客户满 意度。 意度。 可能对产品采取的态度。 可能对产品采取的态度。 感兴趣的主要特性和功能。 感兴趣的主要特性和功能。 必须遵循的已知约束。 必须遵循的已知约束。
化学家 要求提供 厂商目录 化学容器 对化学品 厂商目录 的需求 信息 库存报告 化学容器 库存更新 化学品仓库
采购人员 厂商订单状态 化学口厂商 的请求 化学口使用 报告 要求提供 使用报告 劳保部门 化学口 跟踪 管理系统
培训报告 请求 危险品 扫描条码 培训报告
条码阅读器
培训数据库
10
5.4 保持范围的适度
4
5.1.2 业务需求与用例
业务需求决定了应用的广度与深度。
广度(breadth)指应用能完成哪些业务工作(即 用例)。 而深度(depth)则说明将各项用例实现到何种程 度。
业务需求会影响用例及相关功能需求的实 现优先级。 业务需求对于需求的实现方式也有很大影 响。
5
5.2 前景与范围文档
前景与范围文档用于将业务需求收集整理到一个 文档中，为后续的开发工作打好基础。进行商业 软件开发的组织则常常创建市场需求文档(Market Requirements Documentation，简称MRD)。 图5.2给出了前景和范围文档的一个模板。 业务需求