第二章软件需求分析 一、复习要求 1.了解软件需求的目标和任务 2.了解软件软件需求的获取方法 3.了解可行性研究的方法和可行性研究报告的主要内容。 4.掌握结构化分析方法。 5.了解支持需求分析的原型化方法 6.了解需求规格说明和需求评审的主要内容。 二、内容提要 1.软件需求分析的目标和任务 软件需求分析的目标是深入描述软件的功能和性能,确定软件设计的约束和软件同其它 系统元素的接口细节,定义软件的其它有效性需求 需求分析阶段研究的对象是软件项目的用户要求。一方面,必须全面理解用户的各项要 求,但又不能全盘接受所有的要求,另一方面,要准确地表达被接受的用户要求。只有经过 确切描述的软件需求才能成为软件设计的基础 通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考,需求分析的任 务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的 问题。其实现步骤如图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 的论述，功能 教师 学生 管带 学生 选课 课程 外部实体 外部实体 外部实体 外部实体 目标 系统 输入信息 输入信息 输出信息 输出信息