第二章软件需求分析 、复习要求 1.了解软件需求的目标和任务。 2.了解软件软件需求的获取方法 3.了解可行性研究的方法和可行性研究报告的主要内容 4.掌握结构化分析方法。 5.了解支持需求分析的原型化方法 6.了解需求规格说明和需求评审的主要内容。 二、内容提要 软件需求分析的目标和任务 软件需求分析的目标是深入描述软件的功能和性能,确定软件设计的约束和软件同其它 系统元素的接口细节,定义软件的其它有效性需求。 需求分析阶段研究的对象是软件项目的用户要求。一方面,必须全面理解用户的各项要 求,但又不能全盘接受所有的要求,另一方面,要准确地表达被接受的用户要求。只有经过 确切描述的软件需求才能成为软件设计的基础, 通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考,需求分析的任 务就是借助于当前系统的逻辑模型导岀目标系统的逻辑模型,解决目标系统的“做什么”的 问题。其实现步骤如图2.1所示。 怎么做 横型化 抽象化做什么 理 当前系统 物理模型 具体化 实例化 目标系统 物理模型 逻辑模型 解需求表达需求 图2.1参考当前系统建立目标系统模型 2.需求分析的过程 需求分析阶段的工作,可以分成以下四个方面 (1)问题识别 首先系统分析人员要确定对目标系统的综合要求,即软件的需求。并提出这些需求实现 条件,以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、 安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求,并预先估计 以后系统可能达到的目标。此外,还需要注意其它非功能性的需求。如针对采用某种开发模 式,确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等,以及可维护 性方面的需求
1 第二章 软件需求分析 一、复习要求 1. 了解软件需求的目标和任务。 2. 了解软件软件需求的获取方法。 3. 了解可行性研究的方法和可行性研究报告的主要内容。 4. 掌握结构化分析方法。 5. 了解支持需求分析的原型化方法。 6. 了解需求规格说明和需求评审的主要内容。 二、内容提要 1. 软件需求分析的目标和任务 软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它 系统元素的接口细节，定义软件的其它有效性需求。 需求分析阶段研究的对象是软件项目的用户要求。一方面，必须全面理解用户的各项要 求，但又不能全盘接受所有的要求，另一方面，要准确地表达被接受的用户要求。只有经过 确切描述的软件需求才能成为软件设计的基础。 通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任 务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的 问题。其实现步骤如图 2.1 所示。 图 2.1 参考当前系统建立目标系统模型 2. 需求分析的过程 需求分析阶段的工作，可以分成以下四个方面： (1) 问题识别 首先系统分析人员要确定对目标系统的综合要求，即软件的需求。并提出这些需求实现 条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、 安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计 以后系统可能达到的目标。此外，还需要注意其它非功能性的需求。如针对采用某种开发模 式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护 性方面的需求
此外,要建立分析所需要的通信途径,以保证能顺利地对问题进行分析。分析所需的通 信途径如图22所示。 管理人员 软件开发小组 分析人员 软件计划 软件需求规格说明 型 图22软件需求分析的通信途径 (2)分析与综合 问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信息流和信息结构 出发,逐步细化所有的软件功能,找出系统各元素之间的联系、接口特性和设计上的限制 判断是否存在因片面性或短期行为而导致的不合理的用户要求,是否有用户尚未提出的真正 有价值的潜在要求。剔除其不合理的部分,增加其需要部分。最终综合成系统的解决方案, 给出目标系统的详细逻辑模型。 (3)编制需求分析阶段的文档 已经确定下来的需求应当得到淸晰准确的描述。通常我们把描述需求的文档叫做软件需 求说明书。同时,为了确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及 编写初步的用户手册 (4)需求分析评审 作为需求分析阶段工作的复査手段,应该对功能的正确性、文档的一致性、完备性、准 确性和清晰性,以及其它需求给予评价。为保证软件需求定义的质量,评审应以专门指定的 人员负责,并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外, 用户/需求者,开发部门的管理者,软件设计、实现、测试的人员都应当参加评审工作。 3.需求获取技术 需求获取技术包括两方面的工作: 建立获取用户需求的方法的框架 支持和监控需求获取的过程的机制。 获取用户需求的主要方法是调查研究 (1)了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规 格说明,对软件的需求获取是很有必要的 (2)市场调查。了解市场对待开发软件有什么样的要求;了解市场上有无与待开发软件 类似的系统。如果有,在功能上、性能上、价格上情况如何。 (3)访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分 析:访问用户领域的专家所得到的信息将有助于对用户需求的理解
2 此外，要建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析所需的通 信途径如图 2.2 所示。 图 2.2 软件需求分析的通信途径 (2) 分析与综合 问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信息流和信息结构 出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制， 判断是否存在因片面性或短期行为而导致的不合理的用户要求，是否有用户尚未提出的真正 有价值的潜在要求。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案， 给出目标系统的详细逻辑模型。 (3) 编制需求分析阶段的文档 已经确定下来的需求应当得到清晰准确的描述。通常我们把描述需求的文档叫做软件需 求说明书。同时，为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及 编写初步的用户手册。 (4) 需求分析评审 作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准 确性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的 人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外， 用户／需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。 3. 需求获取技术 需求获取技术包括两方面的工作： ▪ 建立获取用户需求的方法的框架； ▪ 支持和监控需求获取的过程的机制。 获取用户需求的主要方法是调查研究。 (1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规 格说明，对软件的需求获取是很有必要的。 (2) 市场调查。了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件 类似的系统。如果有，在功能上、性能上、价格上情况如何。 (3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分 析；访问用户领域的专家所得到的信息将有助于对用户需求的理解
(4)考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题 陈述,对用户需求可以有更全面、更细致的认识 在做调查研究时,可以采取如下的调查方式: 制定调查提纲,向不同层次的用户发调查表。 按用户的不同层次,分别召开调查会,了解用户对待开发系统的想法和建议。 向用户领域的专家或在关键岗位上工作的人个别咨询。 实地考察,跟踪现场业务流程 查阅与待开发系统有关的资料 使用各种调查工具,如数据流图、任务分解图、网络图等。 为了能够有效地获取和理清用户需求,应当打破用户(需方)和开发者(供方)的界限, 共同组成一个联合小组,发挥各自的长处,协同工作 4.可行性研究和可行性研究报告 (1)可行性研究 这是在软件项目计划阶段应该做的事情,包括四个方面的研究: 经济可行性:进行成本/效益分析。从经济角度判断系统开发是否“合算”。 技术可行性:进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复 杂性等出发,判断系统开发在时间、费用等限制条件下成功的可能性 法律可行性:确定系统开发可能导致的任何侵权、妨碍和责任。 方案的选择:评价系统或产品开发的几个可能的候选方案。最后给出结论意见 (2)经济可行性 分析员需要进行成本/效益分析。所谓成本,包括:①购置并安装软、硬件及有关设 备的费用:②系统开发费用;③系统安装、运行及维护的费用;④人员培训费用。而效益 是指:①系统为用户增加的收入或为用户节省的开支,这是有形的效益:②给潜在用户心 理上造成的影响,这是无形的效益。它可以转化为有形的效益。 (3)技术可行性 分析员需要根据系统的功能、性能需求,建立系统模型。然后对此模型进行一系列的试 验、评审和修改。最后由项目管理人员作出是否进行系统开发的决定。 如果开发技术风险很大,或者模型演示表明当前采用的技术和方法不能实现系统预期的功能 和性能,或者系统的实现不支持各子系统的集成,则项目管理人员可以作出停止系统开发的 决定。 (4)方案的选择 分析员考虑问题解决的方案。一般采用将一个大而复杂的系统分解为若干个子系统的办 法来降低解的复杂性。如何进行系统分解、如何定义各子系统的功能、性能和界面,实现方 案不唯一。可以采用折衷的方法,反复比较各个方案的成本/效益,选择可行的方案 (5)可行性研究报告 可行性报告的形式可以有多种,但最重要的内容应当有: 项目背景:①问题描述②实现环境③限制条件 Ⅱ.管理概要和建议:①重要的研究结果②说明③建议④影响 Ⅲ.候选方案:①候选系统的配置②最终方案的选择标准 Ⅳ.系统描述:①系统工作范围的简要说明②被分配系统元素的可行性 V.经济可行性(成本一效益分析):①经费概算②预期的经济效益 Ⅵ.技术可行性(技术风险评价):①技术实力②已有工作基础③设备条件 Ⅶ.法律可行性:①系统开发可能导致的侵权,违法和责任
3 (4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题 陈述，对用户需求可以有更全面、更细致的认识。 在做调查研究时，可以采取如下的调查方式： ▪ 制定调查提纲，向不同层次的用户发调查表。 ▪ 按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议。 ▪ 向用户领域的专家或在关键岗位上工作的人个别咨询。 ▪ 实地考察，跟踪现场业务流程。 ▪ 查阅与待开发系统有关的资料。 ▪ 使用各种调查工具，如数据流图、任务分解图、网络图等。 为了能够有效地获取和理清用户需求，应当打破用户（需方）和开发者（供方）的界限， 共同组成一个联合小组，发挥各自的长处，协同工作。 4. 可行性研究和可行性研究报告 (1) 可行性研究 这是在软件项目计划阶段应该做的事情，包括四个方面的研究： ▪ 经济可行性 ：进行成本∕效益分析。从经济角度判断系统开发是否“合算”。 ▪ 技术可行性 ：进行技术风险评价。从开发者的技术实力、以往工作基础、问题的复 杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。 ▪ 法律可行性 ：确定系统开发可能导致的任何侵权、妨碍和责任。 ▪ 方案的选择 ：评价系统或产品开发的几个可能的候选方案。最后给出结论意见。 (2) 经济可行性 分析员需要进行成本∕效益分析。所谓成本，包括：① 购置并安装软、硬件及有关设 备的费用；② 系统开发费用；③ 系统安装、运行及维护的费用；④ 人员培训费用。而效益 是指：① 系统为用户增加的收入或为用户节省的开支，这是有形的效益；② 给潜在用户心 理上造成的影响，这是无形的效益。它可以转化为有形的效益。 (3) 技术可行性 分析员需要根据系统的功能、性能需求，建立系统模型。然后对此模型进行一系列的试 验、评审和修改。最后由项目管理人员作出是否进行系统开发的决定。 如果开发技术风险很大，或者模型演示表明当前采用的技术和方法不能实现系统预期的功能 和性能，或者系统的实现不支持各子系统的集成，则项目管理人员可以作出停止系统开发的 决定。 (4) 方案的选择 分析员考虑问题解决的方案。一般采用将一个大而复杂的系统分解为若干个子系统的办 法来降低解的复杂性。如何进行系统分解、如何定义各子系统的功能、性能和界面，实现方 案不唯一。可以采用折衷的方法，反复比较各个方案的成本∕效益，选择可行的方案。 (5) 可行性研究报告 可行性报告的形式可以有多种，但最重要的内容应当有： Ⅰ. 项目背景：① 问题描述 ② 实现环境 ③ 限制条件 Ⅱ. 管理概要和建议：① 重要的研究结果 ② 说明 ③ 建议 ④ 影响 Ⅲ. 候选方案：① 候选系统的配置 ② 最终方案的选择标准 Ⅳ. 系统描述：① 系统工作范围的简要说明 ② 被分配系统元素的可行性 Ⅴ. 经济可行性（成本－效益分析）：① 经费概算 ② 预期的经济效益 Ⅵ. 技术可行性（技术风险评价）：① 技术实力 ② 已有工作基础 ③ 设备条件 Ⅶ. 法律可行性：① 系统开发可能导致的侵权，违法和责任
Ⅷ.用户使用可行性:①用户单位的行政管理,工作制度②使用人员的素质 Ⅸ.其它与项目有关的问题:①其它方案介绍②未来可能的变化 可行性研宄报告首先由项目负责人审查(审查内容是否可靠),再上报给上级主管审阅 (估价项目的地位)。从可行性研究应当得出“行或不行”的决断。当然,在以后的开发阶段, 还要其它“行还是不行”的决定 5.结构化分析方法 结构化分析方法最初由 Douglas ross提出,由 DeMarco推广,由Ward和 Mellor以及后 来的 Hatley和 Pirbhai扩充,形成了今天的结构化分析方法的框架 结构化分析方法是一种建模技术。它建立的分析模型如图2.3所示。 数据对象描述 加工规格说明 体 数据流图 关系图 数据 词典 状态一迁移图 控制规格说明 图2.3分析模型的结构 在模型的核心是数据词典,它描述了所有的在目标系统中使用的和生成的数据对象。围 绕着这个核心的有三种图:实体一关系图(ERD描述数据对象及数据对象之间的关系:数据 流图(DFD)描述数据在系统中如何被传送或变换,以及描述如何对数据流进行变换的功能(子 功能);状态一迁移图(STD)描述系统对外部事件如何响应,如何动作。 因此,ERD用于数据建模,DFD用于功能建模,STD用于行为建模。 (1)数据建模 数据模型包括三种互相关联的信息:数据对象,描述对象的属性,描述对象间相互连接 的关系 数据对象:是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不 同特征或属性的信息 数据对象可以是外部实体(如显示器),事物(如报表或显示),角色(如教师或学生), 行为(如一个电话呼叫)或事件(如单击鼠标左键),组织单位(如研究生院),地点(如注 册室)或结构(如文件)。 数据对象只封装了数据,没有包含作用于这些数据上的操作。这与面向对象范型中的类 和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象,其中的某一个对象叫 做该数据对象的一个实例 属性:定义了数据对象的特征。它可用来:①为数据对象的实例命名:②描述这 个实例:③建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号
4 Ⅷ. 用户使用可行性：① 用户单位的行政管理，工作制度 ② 使用人员的素质 Ⅸ. 其它与项目有关的问题：① 其它方案介绍 ② 未来可能的变化 可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报给上级主管审阅 （估价项目的地位）。从可行性研究应当得出“行或不行”的决断。当然，在以后的开发阶段， 还要其它“行还是不行”的决定。 5. 结构化分析方法 结构化分析方法最初由 Douglas Ross 提出，由 DeMarco 推广，由 Ward 和 Mellor 以及后 来的 Hatley 和 Pirbhai 扩充，形成了今天的结构化分析方法的框架。 结构化分析方法是一种建模技术。它建立的分析模型如图 2.3 所示。 图 2.3 分析模型的结构 在模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。围 绕着这个核心的有三种图：实体—关系图(ERD)描述数据对象及数据对象之间的关系；数据 流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子 功能）；状态—迁移图(STD)描述系统对外部事件如何响应，如何动作。 因此，ERD 用于数据建模，DFD 用于功能建模，STD 用于行为建模。 (1) 数据建模 数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接 的关系。 ▪ 数据对象 ：是需被目标系统所理解的复合信息的表示。所谓复合信息是具有若干不 同特征或属性的信息。 数据对象可以是外部实体（如显示器），事物（如报表或显示），角色（如教师或学生）， 行为（如一个电话呼叫）或事件（如单击鼠标左键），组织单位（如研究生院），地点（如注 册室）或结构（如文件）。 数据对象只封装了数据，没有包含作用于这些数据上的操作。这与面向对象范型中的类 和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某一个对象叫 做该数据对象的一个实例。 ▪ 属性 ：定义了数据对象的特征。它可用来：① 为数据对象的实例命名；② 描述这 个实例；③ 建立对另一个数据对象的另一个实例的引用。如学生数据对象的属性可以有学号、 实体— 关系图 数据 词典 状态—迁移图 数据流图 数据对象描述 控制规格说明 加工规格说明
姓名、性别、出生年月、籍贯等。为了唯一地标识数据对象的某一个实例,定义数据对象中 的一个属性或几个属性为关键码(key),书写为id,例如在“学生”数据对象中用“学号”做 关键码,它可唯一地标识一个“学生”数据对象中的实例。 关系:各个数据对象的实例之间有关联。如一个学生“张鹏”选修两门课程“软件 工程”与“计算机网络”,学生与课程的实例通过“选修”关联起来。实例的关联有三种:① 一对一(1:1);②一对多(1m);③多对多(nm)。这种实例的关联称为“基数”。基数表明了 “重复性”。如1位教师带学生班的30位同学,就是1:m的关系。但也有1位教师带0位同 学的情形。所以实例关联有是“可选”还是“必须”之分。用“O”表示关系是可选的,用 “|”表示关系必须出现1次。如图24所示。这表明了关系的“参与性 基数:1位教师 基数:多位学生 管带 教师 学生 参与性:必须的 参与性:可选的 图24基数与参与性 实体一关系图:数据对象及其关系可用ERD表示。图25给出学生选修课程的ERD 及描述学生属性的实体对象表。 学生 选课 数据对象表 学号姓名性别出生年月籍贯… 图25简单的ERD和数据对象表 (2)功能建模和数据流 最初,结构化分析方法仅讨论数据流建模。目标系统被表示成如图2.6所示的数据变换 流程图。系统的功能体现在核心的数据变换中。 外部实体 输入信息 输出信息 外部实体 标 系统 外部实体 输入信息 输出信息 外部实体 图26数据流图(DFD) 功能建模的思想就是用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶冋 下逐层分解,直到找到满足功能要求的所有可实现的软件为止。根据 Demarco的论述,功能 模型使用了数据流图来表达系统内数据的运动情况,而数据流的变换则用结构化英语、判定
5 姓名、性别、出生年月、籍贯等。为了唯一地标识数据对象的某一个实例，定义数据对象中 的一个属性或几个属性为关键码(key)，书写为_id，例如在“学生”数据对象中用“学号”做 关键码，它可唯一地标识一个“学生”数据对象中的实例。 ▪ 关系 ：各个数据对象的实例之间有关联。如一个学生“张鹏”选修两门课程“软件 工程”与“计算机网络”，学生与课程的实例通过“选修”关联起来。实例的关联有三种：① 一对一(1:1)；② 一对多(1:m)；③ 多对多(n:m)。这种实例的关联称为“基数”。基数表明了 “重复性”。如 1 位教师带学生班的 30 位同学，就是 1:m 的关系。但也有 1 位教师带 0 位同 学的情形。所以实例关联有是“可选”还是“必须”之分。用“〇”表示关系是可选的，用 “│”表示关系必须出现 1 次。如图 2.4 所示。这表明了关系的“参与性”。 基数：1 位教师 基数：多位学生 参与性：必须的 参与性：可选的 图 2.4 基数与参与性 ▪ 实体—关系图 ：数据对象及其关系可用 ERD 表示。图 2.5 给出学生选修课程的 ERD 及描述学生属性的实体对象表。 数据对象表 学 号 姓 名 性 别 出生年月 籍贯 …… 图 2.5 简单的 ERD 和数据对象表 (2) 功能建模和数据流 最初，结构化分析方法仅讨论数据流建模。目标系统被表示成如图 2.6 所示的数据变换 流程图。系统的功能体现在核心的数据变换中。 图 2.6 数据流图（DFD） 功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向 下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据 DeMarco 的论述，功能 模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定 教师 学生 管带 学生 选课 课程 外部实体 外部实体 外部实体 外部实体 目标 系统 输入信息 输入信息 输出信息 输出信息