第二章软件需求分析 一、复习要求 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 的论述，功能 教师 学生 管带 学生 选课 课程 外部实体 外部实体 外部实体 外部实体 目标 系统 输入信息 输入信息 输出信息 输出信息
模型使用了数据流图来表达系统内数据的运动情况,而数据流的变换则用结构化英语、判定 表与判定树来描述。 数据流图 图27是描述储户携带存折去银行办理取款手续的数据流图。从图中可以看到,数据流 图的基本图形元素有四种,如图28所示。 检验出的问题 储户取款单 存折 取款 信息 付数、付款信息(登录 月 日历 图2.7办理取款手续的数据流图 加工。输入数据在此进行变换产生输出数据,其中要注明加工的名字。 数据输入的源点( Source)或数据输出的汇点(Sink)。其中要注明源点 或汇点的名字。 数据流。被加工的数据与流向,箭头边应给出数据流名字,可用名词 或名词性短语命名。 数据存储文件。也必须加以命名,用名词或名词性短语命名。 图28DFD的基本图形符号 在数据流图中,如果有两个以上数据流指向一个加工,或是从一个加工中引出两个以上 的数据流,这些数据流之间往往存在一定的关系。为表达这些关系,在这些数据流的加工可 以标上不同的标记符号。所用符号及其含意在图29中给出。 A 有A则有B或C, C当A或B有一个 C 或两者都有 存在,就有C 有A则有B与C,A 当A与B都存在 C两者同时有 就有C ④有A则有B或C但 不会同时有B与C 图2.9表明多个数据流与加工之间关系的符 分层数据流图 为了表达数据处理过程的数据加工情况,用一个数据流图是不够的。稍为复杂的实际问 题,在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次
6 模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定 表与判定树来描述。 ▪ 数据流图 图 2.7 是描述储户携带存折去银行办理取款手续的数据流图。从图中可以看到，数据流 图的基本图形元素有四种，如图 2.8 所示。 图 2.7 办理取款手续的数据流图 图 2.8 DFD 的基本图形符号 在数据流图中，如果有两个以上数据流指向一个加工，或是从一个加工中引出两个以上 的数据流，这些数据流之间往往存在一定的关系。为表达这些关系，在这些数据流的加工可 以标上不同的标记符号。所用符号及其含意在图 2.9 中给出。 图 2.9 表明多个数据流与加工之间关系的符号 ▪ 分层数据流图 为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问 题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次
结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的数 据流图反映这种结构关系,能清楚地表达和容易理解整个系统。 图2.10给出分层数据流图的示例。数据处理S包括三个子系统1、2、3。顶层下面的第 层数据流图为DFD/L1。第二层数据流图DFD/L21、DFD/L22及DFD/L23分别是 子系统1、2和3的细化。对任何一层数据流图来说,我们称它的上层图为父图,在它下一层 的图则称为子图 DFD/LO DFD/LI (12-1 3,2)+(33 FD/ L2. DFD/L2. 2 DFD/ L2. 3 图2.10分层数据流图 画数据流图的基本步骤概括地说,就是自外向内,自顶向下,逐层细化,完善求精。检 查和修改的原则为 ①数据流图上所有图形符号只限于前述四种基本图形元素 ②顶层数据流图必须包括前述四种基本元素,缺一不可。 ③顶层数据流图上的数据流必须封闭在外部实体之间。 ④每个加工至少有一个输入数据流和一个输出数据流。 ⑤在数据流图中,需按层给加工框编号。编号表明该加工处在哪一层,以及上下层的 父图与子图的对应关系 ⑥规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输 出数据流必须一致。此即父图与子图的平衡 ⑦可以在数据流图中加入物质流,帮助用户理解数据流图 ⑧图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性 短语”,表明流动的数据是什么。加工的名字应当是“名词十宾语”,表明做什么事情。 ⑨数据流图中不可夹带控制流。 ⑩0初画时可以忽略琐碎的细节,以集中精力于主要数据流。 加工规格说明 加工规格说明用来说明DFD中的数据加工的加工细节。加工规格说明描述了数据加工 的输入,实现加工的算法以及产生的输出。另外,加工规格说明指明了加工(功能)的约東 和限制,与加工相关的性能要求,以及影响加工的实现方式的设计约束。必须注意,写加工 规格说明的主要目的是要表达“做什么”,而不是“怎样做”。因此它应描述数据加工实现 加工的策略而不是实现加工的细节。 目前用于写加工规格说明的工具有结构化英语、判定表和判定树 针对实时系统的Ward&Mlor扩展 这种扩展可以适应实时系统提出的以下要求:①在时间连续的基础上接收或产生数据
7 结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数 据流图反映这种结构关系，能清楚地表达和容易理解整个系统。 图 2.10 给出分层数据流图的示例。数据处理 S 包括三个子系统 1、2、3。顶层下面的第 一层数据流图为 DFD／L1。第二层数据流图 DFD／L2.1、DFD／L2.2 及 DFD／L2.3 分别是 子系统 1、2 和 3 的细化。对任何一层数据流图来说，我们称它的上层图为父图，在它下一层 的图则称为子图。 图 2.10 分层数据流图 画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。检 查和修改的原则为： ① 数据流图上所有图形符号只限于前述四种基本图形元素。 ② 顶层数据流图必须包括前述四种基本元素，缺一不可。 ③ 顶层数据流图上的数据流必须封闭在外部实体之间。 ④ 每个加工至少有一个输入数据流和一个输出数据流。 ⑤ 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的 父图与子图的对应关系。 ⑥ 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输 出数据流必须一致。此即父图与子图的平衡。 ⑦ 可以在数据流图中加入物质流，帮助用户理解数据流图。 ⑧ 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性 短语”，表明流动的数据是什么。加工的名字应当是“名词＋宾语”，表明做什么事情。 ⑨ 数据流图中不可夹带控制流。 ⑩ 初画时可以忽略琐碎的细节，以集中精力于主要数据流。 ▪ 加工规格说明 加工规格说明用来说明 DFD 中的数据加工的加工细节。加工规格说明描述了数据加工 的输入，实现加工的算法以及产生的输出。另外，加工规格说明指明了加工（功能）的约束 和限制，与加工相关的性能要求，以及影响加工的实现方式的设计约束。必须注意，写加工 规格说明的主要目的是要表达“做什么”，而不是“怎样做”。因此它应描述数据加工实现 加工的策略而不是实现加工的细节。 目前用于写加工规格说明的工具有结构化英语、判定表和判定树。 ▪ 针对实时系统的 Ward & Mellor 扩展 这种扩展可以适应实时系统提出的以下要求：① 在时间连续的基础上接收或产生数据
流;②贯穿系统的控制信息和相关的控制处理;③在多任务的情况下可能会遇到同一个加 的多个实例:④系统状态以及导致系统状态迁移的机制 图2.11给出的扩展的图形符号可以让分析员在描述数据流和加工的同时,描述控制流和 控制加工。这些符号可以与原来的数据流图的图形符号混用。 ---·控制项或事件。时间上间隔发生的数据流,取布尔值或离散值。 艹连续数据流。时间上连续发生的数据流,用做加工的输入或输出 控制加工。由事件驱动的控制处理过程,接受控制和输入,产生控制作为输 控制存储。为一个或多个控制提供事件源或事件存储服务的库 加工。同一个加工的多个对等的实例。在多任务系统中当产生多个加工时使 用。它相当于一些进程。 图2.11Wad& Mellor开发的针对实时系统的扩展的结构化分析符号 例如,图2.12给出一个基于计算机的水温控制系统的处理。水温测量仪连续传送水温数 据给温度监控加工模块,该加工将水温与允许波动范围进行比较,输岀校正数据给温度调节 装置 温度 水温测量仪 温度 监视与 温度校正值 调整 度设置 图2.12时间连续的数据流与普通数据流 图213给出一个制造车间的数据和控制流的顶层流图。事件可以作为普通数据加工的输 入数据流,控制也可以接收普通的输入数据流 、每个部件的状态 机器人 动作警告 部件状态缓冲器 初始化 位串 起动/停止 处理激 活信号 控与操 机器人动作记录 作界面 移位命 操作设置 操作命令 令处理 定位命令 图2.13使用ward& Mellor符号的数据流和控制流 Hatley和 Pirbhai对结构化分析技术的扩展 ward& Pirbhai方法主要关注面向控制的规格说明,而不是扩充数据流图的图形符号
8 流；② 贯穿系统的控制信息和相关的控制处理；③ 在多任务的情况下可能会遇到同一个加 工的多个实例；④ 系统状态以及导致系统状态迁移的机制。 图 2.11 给出的扩展的图形符号可以让分析员在描述数据流和加工的同时，描述控制流和 控制加工。这些符号可以与原来的数据流图的图形符号混用。 图 2.11 Ward & Mellor 开发的针对实时系统的扩展的结构化分析符号 例如，图 2.12 给出一个基于计算机的水温控制系统的处理。水温测量仪连续传送水温数 据给温度监控加工模块，该加工将水温与允许波动范围进行比较，输出校正数据给温度调节 装置。 图 2.12 时间连续的数据流与普通数据流 图 2.13 给出一个制造车间的数据和控制流的顶层流图。事件可以作为普通数据加工的输 入数据流，控制也可以接收普通的输入数据流。 图 2.13 使用 Ward & Mellor 符号的数据流和控制流 ▪ Hatley 和 Pirbhai 对结构化分析技术的扩展 Ward & Pirbhai 方法主要关注面向控制的规格说明，而不是扩充数据流图的图形符号。 控制项或事件。时间上间隔发生的数据流，取布尔值或离散值。 连续数据流。时间上连续发生的数据流，用做加工的输入或输出。 控制加工。由事件驱动的控制处理过程，接受控制和输入，产生控制作为输 出。 控制存储。为一个或多个控制提供事件源或事件存储服务的库。 加工。同一个加工的多个对等的实例。在多任务系统中当产生多个加工时使 用。它相当于一些进程。 水温测量仪 温度 监视与 调整 温度 温度设置范围 温度校正值 每个部件的状态 部件状态缓冲器 位串 部件监 控与操 作界面 操作命令 机器人 初始化 控制 起动∕停止 信号 移位命 令处理 动作警告 操作设置 处理激 活信号 机器人命令文件 机器人动作记录 定位命令
他们建立控制流图(CFD)以区别于数据流图①DFD)。在控制流图中的加工与数据流图中相同, 但传递的是控制流而不是数据流。在控制流图中引入实短线“|”表示对控制规格说明的引用 图2.14给出他们建立的实时系统模型。用数据流图表示对数据和操作数据的加工;用控制流 图表示事件在加工之间如何流动,说明导致各个加工激活的外部事件 莫型 加工模 输入数据流 输出数据流 数据流图 加工激活者 加工规格说明 控制模型 数据条件 控制流图 输出控制流 输入控制流 控制规格说明 图214数据与控制之间的关系 (3)行为建模 行为建模给出需求分析方法的所有操作原则,但只有结构化分析方法的扩充版本才提供 这种建模的符号。 状态一迁移图 利用如图2.15所示的状态一迁移图(STD)或状态一迁移表来描述系统或对象的状态,以 及导致系统或对象的状态改变的事件,从而描述系统的行为 状态 事件 t1 S t4 (a)状态迁移图 (b)状态迁移表 图215状态一迁移图与其等价的状态一迁移表例 每一个状态代表系统或对象的一种行为模式。状态一迁移图指明系统的状态如何相应外 部的信号(事件)进行推移。在状态一迁移图中,用圆圈“O”表示可得到的系统状态,用 箭头“→”表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的 名字。如图215(a)所示,系统中可取得的状态=S1,S2,S3,事件=t1l,t2,t3,t4。事件 t将引起系统状态SI向状态S3迁移,事件口将引起系统状态S3向状态S2迁移,等等。 图2.15(b)就是与图215(a)等价的状态一迁移表。 另外,状态一迁移图指明了作为特定事件的结果(状态)。在状态中包含可能执行的行
9 他们建立控制流图(CFD)以区别于数据流图(DFD)。在控制流图中的加工与数据流图中相同， 但传递的是控制流而不是数据流。在控制流图中引入实短线“|”表示对控制规格说明的引用。 图 2.14 给出他们建立的实时系统模型。用数据流图表示对数据和操作数据的加工；用控制流 图表示事件在加工之间如何流动，说明导致各个加工激活的外部事件。 图 2.14 数据与控制之间的关系 (3) 行为建模 行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供 这种建模的符号。 ▪ 状态—迁移图 利用如图 2.15 所示的状态—迁移图(STD)或状态—迁移表来描述系统或对象的状态，以 及导致系统或对象的状态改变的事件，从而描述系统的行为。 图 2.15 状态—迁移图与其等价的状态—迁移表例 每一个状态代表系统或对象的一种行为模式。状态—迁移图指明系统的状态如何相应外 部的信号（事件）进行推移。在状态—迁移图中，用圆圈“○”表示可得到的系统状态，用 箭头“→”表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的 名字。 如图 2.15(a) 所示，系统中可取得的状态＝S1，S2，S3，事件＝t1，t2，t3，t4。事件 t1 将引起系统状态 S1 向状态 S3 迁移，事件 t2 将引起系统状态 S3 向状态 S2 迁移，等等。 图 2.15(b) 就是与图 2.15(a) 等价的状态—迁移表。 另外，状态—迁移图指明了作为特定事件的结果（状态）。在状态中包含可能执行的行 加工模型 数据流图 加工规格说明 控制模型 控制流图 控制规格说明 输出控制流 输入数据流 输出数据流 输入控制流 加工激活者 数据条件
为(活动或加工) 如果系统比较复杂,可以把状态一迁移图分层表示。例如,在确定了如图216所示那样 的大状态S1,S2,S3之后,接下来就可把状态S1,S2,S3细化。在该图中对状态Sl进行 了细化。此外,在状态一迁移图中,由一个状态和一个事件所决定的下一状态可能会有多个 实际会迁移到哪一个是由更详细的内部状态和更详细的事件信息来决定的。此时,可采用状 态迁移图的一种变形,如图2.17那样,使用加进判断框和处理框的记法。 Isit C2 NP3 P4YC1、C2:判断条件 P1~P5:处理内容 图2.16状态迁移图的网 图2.17状态迁移图的变形 Petri网 Petri网,简称PNG( Petri Net Graph)。它适用于描述相互独立、协同操作的处理系统, 即并发执行的处理系统。在软件需求分析与设计阶段都可以使用 Petri网是一种有向图,它有两种结点:“O”表示系统的状态。“一”或“|”表示系 统中的事件。图中的有向边表示对事件的输入,或从事件输出:“一”表示对事件的输入 “”表示事件的结果,即从事件的输出 图2.18用 Petri网描述了在一个多任务系统中的两个进程PRl和PR2使用一个公共资源 R时,利用原语LOCK(对资源加锁)和 UNLOCK(对资源解锁)控制R的使用,保证进程 间的同步的例子。 进程1 进程2 pl等待R p7R空闲等待Rp4 处理 处理21 t2 p6 处理12 处理22 图2.18进程同步机制的PNG 图中每个进程是一个数据对象,它有三个状态:等待资源(pl或p4),占用资源执行 的处理(p2或p5),不占用资源执行的处理(p3或p6),另外系统有一个状态:资源空闲 (p7)。在有的状态中有一个黑点“⊙”,称为标记或令牌,表明系统或对象当前正处于此 状态。当作为一个事件的输入的所有状态都得到或保有令牌时,才能引起该事件“激发”。 使得系统和对象的状态向前推移,完成系统和对象的某些行为 控制规格说明 控制规格说明从两个方面给出系统的行为。其一是状态一迁移图(STD),它是行为的“顺
10 为（活动或加工）。 如果系统比较复杂，可以把状态—迁移图分层表示。例如，在确定了如图 2.16 所示那样 的大状态 S1，S2，S3 之后，接下来就可把状态 S1，S2，S3 细化。在该图中对状态 S1 进行 了细化。此外，在状态—迁移图中，由一个状态和一个事件所决定的下一状态可能会有多个。 实际会迁移到哪一个是由更详细的内部状态和更详细的事件信息来决定的。此时，可采用状 态迁移图的一种变形，如图 2.17 那样，使用加进判断框和处理框的记法。 图 2.16 状态迁移图的网 图 2.17 状态迁移图的变形 ▪ Petri 网 Petri 网，简称 PNG (Petri Net Graph)。它适用于描述相互独立、协同操作的处理系统， 即并发执行的处理系统。在软件需求分析与设计阶段都可以使用。 Petri 网是一种有向图，它有两种结点：“○”表示系统的状态。“—”或“┃”表示系 统中的事件。图中的有向边表示对事件的输入，或从事件输出：“ ”表示对事件的输入； “ ”表示事件的结果，即从事件的输出。 图 2.18 用 Petri 网描述了在一个多任务系统中的两个进程 PR1 和 PR2 使用一个公共资源 R 时，利用原语 LOCK（对资源加锁）和 UNLOCK（对资源解锁）控制 R 的使用，保证进程 间的同步的例子。 图 2.18 进程同步机制的 PNG 图中每个进程是一个数据对象，它有三个状态：等待资源（p1 或 p4），占用资源执行 的处理（p2 或 p5），不占用资源执行的处理（p3 或 p6），另外系统有一个状态：资源空闲 （p7）。在有的状态中有一个黑点“”，称为标记或令牌，表明系统或对象当前正处于此 状态。当作为一个事件的输入的所有状态都得到或保有令牌时，才能引起该事件“激发”。 使得系统和对象的状态向前推移，完成系统和对象的某些行为。 ▪ 控制规格说明 控制规格说明从两个方面给出系统的行为。其一是状态—迁移图(STD)，它是行为的“顺