Transcript 第三章 需 求 分 析
第5章 需 求 分 析
意义： • 软件需求的深入理解是软件开发工作获得成 功的前提条件，不论我们把设计和编码做得 如何出色，不能真正满足用户需求的程序只 会令用户失望，给开发带来烦恼。
需求分析是软件定义时期的最后一个阶段， 它的基本任务 不是确定系统怎样完成 它的工 作， 而是确定系统必须完成 哪些工作，也就 是对目标系统提出完整、准确、清晰、具体 的要求。并在在需求分析阶段结束之前，由 系统分析员写出软件需求规格说明书，以书 面形式准确地描述软件需求。即： ---- 准确地回答“系统 必须做什么?
”
。
• 在分析软件需求和书写软件需求规格说明 书的过程中，分析员和用户都起着关键的、 必不可少的作用。
需求分析的结构化方法都遵守下述准则：
(1) 必须理解并描述问题的信息域，根据这 条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要 求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这 条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行 分解，用层次的方式展示细节。
软件的需求包括：
• • • • • • 功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求 • 资源使用需求 • 成本消耗需求 • 开发进度需求 • 预先估计以后系统 可能达到的目标
5.1
需求分析的重要性
• 需求分析的输入是软件《合同》或软件《立 项建议书》以及对用户现场的调研、分析和 确认，输出是《用户需求报告》 / 《需求规 格说明书》。
• • • • • 需求分析是软件设计中最为重要的一环，主要表 现在以下几点： （ 1 ）许多大型应用系统的失败，最后均归结到需 求分析的失败： （ 2 ）需求分析的输出文档是《用户需求报告》 （ 3 ）需求分析要占用整个软件开发时间或工作量 的 30 ％左右。 （ 4 ）需求获取中的错误属于软件开发中的早期错 误，它会在后续的设计和实现中进行发散式的传 播。
• • • 需求获取困难的原因 （ 1 ）用户需求具有动态性，即需求的不稳 定性：在整个软件生存周期内，应用软件的 需求会随着时间的进展而有所变化，个别用 户甚至会朝三暮四地变化。 （ 2 ）用户需求具有模糊性，即需求的不准 确性。由于用户的水平不是很高，业务流程 不很规范，所以需求表达不很清楚也不够明 确。
• • （ 3 ）开发者和用户要对需求达成完全一致 的认识，用户要在需求报告上签字，要承担 责任。 （ 4 ）中国的国有企业正处于变动期（体制 改革与企业重组），中国的民营企业正处于 成长期（发展壮大与不完全成熟）。而处于 变动期和成长期的企业需求是不成熟、不稳 定和不规范的，这就给信息系统的需求分析 增加了难度系数。
• 相关的名词解释
• • 需求分析的理论基础 软件需求的概念从根本上讲，软件需求就是 为了解决现实世界中的特定问题，软件必须 展现的属性。这里的问题可能是用户的任务 自动化，或者由软件来完成一个组织的业务 处理，或者控制一个设备等。因此，可能涉 及使用软件的不同层次和不同人员。软件需 求的属性主要是可验证性、优先级和唯一性。
• （ 1 ）可验证性。可验证性是软件需求的基本属性。 软件需求必须是可验证的，否则软件的评审和测 试就没有相应的依据。但在某些情况下，很难对 某些软件需求进行验证或需要的代价很高。软件 需求人员和测试人员应以合理的代价实现需求的 验证。（ 2 ）优先级。软件需求应具有优先级，可 以在有限的资源（资金、人员、技术）情况下进 行取舍。（ 进行管理。 3 ）唯一性。软件需求应唯一地标识出 来，以便在软件配置管理和整个软件生命周期中
• • • 需求来源 （ 1 ）系统目的。系统目的是指软件的整体目的或高层 的目标。这是进行软件开发的动机，但它们通常表达 比较模糊。软件分析师需要仔细地评估这些目标的价 值和成本，对系统的整体目标进行可行性研究。 （ 2 ）行业知识。软件分析师需要获取业务领域内的相 关知识。考虑到大众对于通用的行业知识会一概而过， 一些行业惯例需要软件分析师根据环境进行推断。当 需求发生矛盾时，软件分析师可以利用行业知识对各 种需求进行权衡。
• • • （ 3 ）软件涉众。应充分考虑不同软件涉众的需求。 如果只强调某一角色的需求，忽略其他角色的需求， 往往会导致软件系统的失败。软件分析师应从不同的 角度去识别、表述用户的需求。用户的文化差异、客 户的组织结构，常常是系统难以正常实施的原因。 （ 4 ）运行环境。软件的运行环境包括地域限制、实 时性要求和网络性能等。系统的可行性和软件架构都 依赖于这些环境需求。 （ 5 ）组织环境。软件作为一个组织的业务流程支持 工具，受到组织结构、企业文化和内部政策的影响。 软件的需求也与组织结构、企业文化和内部政策有关。
5.2 需求分析的任务
• 需求分析的任务就是借助于当前系统的逻辑模 型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
1
确定对系统的综合要求
-- 功能需求、性能需求、可靠 性和可用性需求、出错处理需求、 接口需求、约束、 逆向需求、将 来可能提出的要求。
2 分析系统的数据要求 （
1
）输入数据。 （
2
）中间数据。 （
3
）输出数据。
3
导出系统的逻辑模型 在研究现行系统过程中，得到了现行系统的物理 模型和逻辑模型。然后，在现行系统的逻辑模 型上加上目标系统的新的需求来改变现存系统 逻辑模型中可能存在的不合理的部分，以得到 新系统的逻辑模型，最后加上计算机需要的处 理细节的有关内容以得到新系统的物理模型。 在这里所应用的方法和可行性研究中所用的完 全一样，只是可行性研究阶段得出的是新系统 顶层的逻辑模型与物理模型。在这里需要得到 所有层次上的模型，也就是说既有顶层的概括 模型，也有底层的细节模型。
4
修正系统开发计划 通过用户需求的调研与分析，对于新 系统的功能与规模有了更深入的理解，用 户也可能提出一些在可行性研究范围之外 的功能。这些都产生了对成本和进度重新 估算的需要。如果重新估算的成本和进度 显著地不同于可行性研究的结果，应该修 改系统开发计划。
5
开发模型系统 系统开发模型系统是指在需求分析阶 段建造软件“样机”。它的目的主要是显 示系统的功能。
6 写出需求规格说明书 需求规格说明书，又称软件规格说明书，它是 软件需求分析工作的重要成果，是软件开发、 软件验收和软件管理的依据。因此，要特别重 视，不能有丝毫错误或不当。它被当作是用户 和开发人员双方达成的协议书。其中，阐明的 需求是经过分析以后双方对问题的共同理解， 而且是准备组织力量加以实现的。
• • • • 5.3
需求分析的过程
（ 1 ）调查研究 （ 2 ）分析与综合 （ 3 ）书写需求分析的文档 （ 4 ）需求分析评审
5.4
用户需求获取
• 需求收集是需求分析的第一步，需求获取是 一个确定用户的要求是什么的信息收集过程。 开发人员在需求收集时要同各种用户进行交 流，收集各种用户的信息，理解用户的各项 要求。然后开发人员才能对信息进行分析， 澄清一些模糊的要求，向用户解释不合理的 或暂时无法实现的要求，以求得用户的谅解。
用户需求的特点
• • • 现行系统的逻辑模型表达了现行系统的功能目标， 这是设计新系统的重要基础。 用户还希望实现某个特殊的功能、人机界面或操 作方式，系统的环境还可能有某些约束、要求等。 这些需求对新系统的实现起着很大的作用，对软 件的质量、生命力、命运起着不可低估的影响。 实际上，它们与现行系统的逻辑模型一起构成了 整个系统的需求，分析阶段的工作目标就是要实 现这样两个任务。
• • • • • •
用户需求的范围和目标
以下四个要点可作为控制范围大小的原则： （ 1 ）反对随意扩大系统范围边界的做法。 （ 2 ）系统范围大小和目标功能的多少、强弱的确 定，应在用户对项目的热情下降到危及项目开发 的冰点之前完成。 （ 3 ）系统的范围和功能目标中一定要包含边界的 定义及其精心地考虑。 （ 4 ）在确定系统需求范围时，要把效益高的部分 划进来，把效益低的部分划出去。 总之，确定目标和范围的原则就是尽可能地小一 些，保证尽快完成，接口要适应现行环境，要把 立竿见影的部分划进来。
• • • • • • • • • 非功能目标的确定 （ 1 ）灵活性和可维护性 （ 2 ）进度和成本 （ 3 ）效率 （ 4 ）集成 （ 5 ）安全性 （ 6 ）可靠性 （ 7 ）移植性和兼容性 （ 8 ）简明性
需求收集的方式
• 访谈 •
问卷调查
•
场景使用
•
用户资料收集
(1).
访 谈
• • 正式的访谈
---
系统分析员将提出一些事先准备好的具体问题。 非正式的访谈
---
分析员将提出一些用户可以自由回答的开放性问 题，以鼓励被访问人员说出自己的想法。 • 当需要调查大量人员的意见时，向被调查人分发 调查表是一个十分有效的做法。 • 在访问用户的过程中使用情景分析技术往往非常 有效。
所谓情景分析就是对用户将来使用目标系统解 决某个具体问题的方法和结果进行分析。 情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而 便于用户理解，而且还可能进一步揭示出一些分析 员目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技 术能保证用户在需求分析过程中始终扮演一个积极 主动的角色。需求分析的目标是获知用户的真实需 求，而这一信息的惟一来源是用户，因此， 让用户 起积极主动的作用对需求分析工作获得成功是至关 重要的。
用户需求的获取过程
• • • （ 1 ）非形式化方法 （ 2 ）半形式化方法 （ 3 ）形式化方法
• 判定表 5.5
需求分析工具
• 判定树
• • 结构化分析语言 LSA （ Language of Structure Analysis ） 结构化分析语言是一种说明需求分析中加工 基本说明的好工具。它是受结构化程序设计 思想的启发而扩展出来的。结构化分析语言 主要包括祈使语句、判断语句、循环语句或 者三者的复合组成。
• • • • • PSL （ Problem Statement Language ，问题 陈述语言） /PSA （ Problem Statement • Analysis 问题陈述分析） 采用 PSL/PSA 辅助工具产生需求分析文档的步 骤是选用 PSL 写出系统的定义，步骤是： （ 1 ）确定对象和对象模型，并给对象起名字。 （ 2 ）使用对象类型的记号画出系统图 （ 3 ）确定对象之间的关系 （ 4 ）描述系统
需求分析阶段的描述工具
• 层次方框图
• Warnier 图
• IPO 图
改进的
IPO
图
5.6
需求管理
• 需求管理主要活动
• • • • • • 需求管理强调： （ 1 ）控制对需求基线的变动 （ 2 ）保持项目计划与需求一致 （ 3 ）控制单个需求和需求文档的版本情况 （ 4 ）管理需求和联系链，或者管理单个需求 和其他项目可交付产品之间的依赖关系 （ 5 ）跟踪基线中的需求状态
需求管理原则
• • 过程能力成熟度模型（ CMM ）是在软件开 发机构中被广泛用来指导软件过程改进。该 模型描述了软件处理能力的 5 个成熟度级别。 为了达到过程能力成熟度模型的第二级，组 织机构必须具有 6 个关键过程域 KPA （ Key Process Areas ）。需求管理是其中之一， 它的目标是：
• • （ 1 ）为软件需求建立一个基线，提供给软 件工程和管理使用。 （ 2 ）软件计划、产品和活动与软件需求保 持一致。
• • 关于需求管理过程域内的原则和策略，可以 参考： （ 1 ）需求管理的关键过程领域不涉及收集 和分析项目需求，而是假定已收集了软件需 求或者已由更高一级的系统给定了需求。一 旦需求获得并且文档化了，软件开发组和有 关的团队（例如质量保证和测试组）需要评 审文档。
• • （ 2 ）开发人员在向客户及有关部门承诺 （ Commitment 件等。 ）某些需求之前，应该确认 需求和约束条件、风险、偶然因素、假定条 （ 3 ）关键处理领域同样建议通过版本控制 和变更控制来管理需求文档。
需求规格说明的版本控制
• • 版本控制是管理需求的一个必要方面，必须 统一确定需求文档的每一个版本。软件开发 组的每一个成员必须得到需求的当前版本。 当需求发生变更时，应该清楚地把变更写成 文档，并且及时通知所有涉及的人员。为了 尽量减少困惑、冲突和误传，应该仅允许指 定的人员来更新需求。 每一个新版本的需求文档，应该公布其包括 修正版本在内的历史情况。
需求属性
• • • • • （ 1 ）创建需求的时间。 （ 2 ）需求的版本号。 （ 3 ）创建需求的作者。 （ 4 ）负责认可该软件需求的人员。 （ 5 ）需求状态。
• • • • • • （ 6 ）需求的原因和根据。 （ 7 ）需求涉及的子系统。 （ 8 ）需求涉及的产品版本号。 （ 9 ）使用的验证方法或者接受的测试标准。 （ 10 ）产品的优先级或者重要程度。 （ 11 ）需求的稳定性。
需求变更
• • • • • 为了使开发组织能够严格控制软件项目，应 该确保以下事项： （ 1 ）仔细评估已建议的变更。 （ 2 ）挑选合适的人选对变更做出决定。 （ 3 ）变更应及时通知所有涉及的人员。 （ 4 ）项目要按一定的程序来采纳需求变更。
• 变更控制过程
• • 需求变更策略： ①所有需求变更必须遵循变更控制过程；②对于 未获得批准的变更，不应该做设计和实现工作； ③变更应该由项目变更控制委员会决定实现哪些 变更；④项目风险承担者应该能够了解变更数据 库的内容；⑤决不能从数据库中删除或者修改变 更请求的原始文档；⑥每一个集成的需求变更必 须能跟踪到一个经核准的变更请求。
• • 变更控制委员会 变更控制委员会负责决定哪些已建议需求变 更或者新产品特性付诸应用，决定在哪些版 本中纠正哪些错误。广义上，变更控制委员 会对项目中任何基线工作产品的变更都可以 做出决定，需求变更文档仅是其中之一。
• • 变更控制委员会可能包括如下方面的代表： ①产品或计划管理部门；②项目管理部门； ③开发部门；④测试或质量保证部门；⑤市 场部或客户代表；⑥制作用户文档的部门； ⑦技术支持部门；⑧帮助桌面或用户支持热 线部门；⑨配置管理部门。
• • • • 变更控制委员会应该有一个总则，用于描述 变更控制委员会的目的、授权范围、成员构 成、做出决策的过程及操作步骤。总则也应 该说明举行会议的频度和事由。 （ 1 ）制定决策。 （ 2 ）交流情况。 （ 3 ）重新协商约定。
需求跟踪
• 需求跟踪包括编制每个需求同系统元素之间 的联系文档，这些元素包括别的需求、体系 结构、其他设计部件、源代码模块、测试、 帮助文件和文档等。跟踪能力信息使变更影 响分析十分便利，有利于确认和评估实现某 个建议的需求变更所必须的工作。
需求管理工具
• • • • • • ① Caliber — RM ，以数据库为核心； ② DOORS ，以数据库为核心； ③ QSSrequireit ，以文档为核心； ④ RequisitePro ，以文档为核心； ⑤ RTM Workshop ，以数据库为核心； ⑥ Vital Link ，以文档为核心。
• 5.7
需求分析的文档
需求分析的文档其实就是一份产品规格说明 书，软件也需要说明其具有的功能或达到的 性能指标。 软件需求规格说明书通常内容比 较繁杂，它还要描述大量需求间的交互关系。 软件需求规格说明书是对软件系统进行分析、 评估和确认的文档。 复杂的软件系统通常会 产生三个文档：系统定义文档（用户需求报 告），系统需求文档，软件需求文档。简单 的软件产品只需要软件需求文档。
• • • （ 1 ）系统定义文档（用户需求报告）。 （ 2 ）系统需求规格说明书。 （ 3 ）软件需求规格说明书。
• • • •
需求报告和需求规格说明书的差异
（ 1 ）用户需求报告是对外的，需求规格说 明书是对内的。 （ 2 ）用户需求报告是合同的产物，需求规 格说明书是立项建议书的产物。 （ 3 ）由用户需求报告可产生需求规格说明 书。 （ 4 ）需要注意的问题。
• P139~144
用户需求报告
需求规格说明书
• P145~150
需求管理文档
• 《需求变更管理表》是对需求变更过程的跟踪与管 理。需求变更申请人一般为客户、客户代表、产品 经理。需求变更审批人可以是项目经理、研发中心 经理、高层经理。需求管理文档记录了需求分析过 程中，软件企业对需求的管理过程。大量过程管理 记录的积累，为软件企业的软件过程数据库累积了 财富。这些财富信息既为软件企业的科学管理与决 策提供了良好的基础，又为软件企业实施 CMM 4 级 和 5 级评估做好了充分准备。
软件工程思想 ( 林锐
P38
—
P48
)
• 需求分析为什么困难？ • 如何进行需求分析？
• 作 业 选择自己感兴趣的项目写出需求说明书。【如果有时间， 可以完成前面的可行性研究报告，简写即可】