第 2章 需求分析
3.1 需求分析的任务需求分析的 任务就是准确地回答,系统必须做什么?” 这个问题,是通过系统分析员与用户一起商定,清晰,准确,具体地描述软件产品必须具有的功能,性能,运行规格等要求 。 软件需求分析阶段的目的是澄清用户的要求,并把双方共同的理解明确地表达成一份书面文档 —— 软件需求规格说明书 。
第 2章 需求分析需求分析的 具体任务包括：
（ 1）确定软件系统的综合需求
（ 2）分析系统的数据需求
（ 3）导出软件系统的逻辑模型
（ 4）修正系统开发计划
（ 5）开发原型系统
（ 6）验证软件需求分析的正确性
（ 7）编写软件需求规格说明书第 2章 需求分析
3.2 需求分析的过程需求分析阶段可分为四个过程：调查研究、
分析与综合、书写需求分析的文档和评审。
（ 1） 调查研究系统分析员协同程序员向用户做需求调查，
阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或 IPO图表示出来 。
第 2章 需求分析
（ 2） 分析与综合分析员需从数据流和数据结构出发,逐步细化所有的软件功能,找出系统中各元素之间的联系,接口特征和设计上的限制,分析它们能否满足功能要求,是否合理 。 依据功能需求,
性能需求,运行环境需求等,剔除其中不合理的部分,增加其需要的部分 。 最终综合成系统的解决方案后,给出目标系统的详细逻辑模型 。
第 2章 需求分析
（ 3） 书写需求分析的文档把分析的结果用正式的文档记录下来,作为最终软件配置的一个组成成分 。 应该完成下述四份文档资料：系统规格说明,数据需求,
用户系统描述,修正的开发计划 。
（ 4） 需求分析评审作为需求分析阶段的复查手段,在需求分析的最后一步,应该对功能的正确性,完整性和清晰性,以及其他需求给予评价 。
第 2章 需求分析
3.3 需求分析的原则
（ 1）能够表达和理解问题的信息域和功能域。
（ 2）能够对问题进行分解和不断细化，建立问题的层次结构。
（ 3）能够给出系统的逻辑视图和物理视图。
第 2章 需求分析
3.4 结构化分析方法结构化分析方法 （ Structured Analysis,简称
SA方法 ） 是 70年代中期提出的一种面向数据流,
自顶向下,逐步求精进行需求分析的方法 。
结构化分析方法适用于分析大型的数据处理系统,特别适用于企事业管理系统 。
结构化分析方法通常与设计阶段的结构化设计方法 （ Structured Designed,简称 SD方法 ） 衔接起来使用 。
第 2章 需求分析结构化分析方法中使用的工具主要包括：
数据流图,数据字典,结构化英语,判定表和判定树 。
其中数据流图用以表达系统内数据的运动情况；数据词典用以定义系统中的数据；结构化语言,判定表和判定树都是用以描述数据流的加工的工具 。
第 2章 需求分析一,数据流图数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。
1、数据流图的基本图形元素
（ 1）数据流：是一组数据。在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名。
（ 2）加工：是对数据流执行的某种操作或变换。在数据流图中加工用圆圈表示，在圆圈内写上加工名。
（ 3）文件：是按照某种规则组织起来的、长度不限的数据。在数据流图中文件用一直线表示，在线段旁注上文件名。
（ 4）数据流的源点和终点：在数据流图中用方框表示，在框内写上相应的名称。
第 2章 需求分析
2,由外向里画数据流图的步骤
（ 1） 确定系统的输入输出：由于系统究竟包括哪些功能可能一时难于弄清楚,可使范围尽量大一些,把可能有的内容全部都包括进去 。
此时,应该向用户了解,系统从外界接受什么数据,,,系统向外界送出什么数据,等信息,
然后,根据用户的答复画出数据流图的外围 。
第 2章 需求分析
（ 2） 由外向里画系统的顶层数据流图首先,将系统的输人数据和输出数据用一连串的加工连接起来 。 在数据流的值发生变化的地方就是一个加工 。 接着,给各个加工命名 。 然后,
给加工之间的数据命名 。 最后,给文件命名 。
（ 3） 自顶向下逐层分解,绘出分层数据流图对于大型的系统,为了控制复杂性,便于理解,
需要采用自顶向下逐层分解的方法进行,即用分层的方法将一个数据流图分解成几个数据流图来分别表示 。
第 2章 需求分析二,数据字典数据字典的任务就是对于数据流图中所出现的所有被命名的图形元素在数据字典中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释 。
数据字典的内容包括：图形元素的名字,别名或编号,分类,描述,定义,位置等 。
数据字典中所有的定义都应是严密的,精确的,不可有半点含混,不可有二义性 。
数据词典中常用符号的含义第 2章 需求分析三,加工逻辑描述工具
1,结构化英语 （ Structured English）
结构化英语是一种介于自然语言和形式化语言之间的半形式化语言 。 它是在自然语言的基础上加了一些限制而得到的语言,它使用有限的词汇和有限的语句来描述加工逻辑 。
结构化英语的词汇表由英语命令动词,数据字典中定义的名字,有限的自定义词和控制结构关键词组成 。
结构化英语举例第 2章 需求分析
2.判定表在某些数据处理中,某数据流图的加工需要依赖于多个逻辑条件的取值,就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的 。 这时使用判定表来描述比较合适 。
一张判定表通常由四部分组成,左上部列出的是所有的条件,左下部为所有可能的操作,右上部分表示各种条件组合的一个矩阵,右下部分是对应于每种条件组合应有的操作 。
判定表举例第 2章 需求分析
3.判定树判定树是判定表的变种,它也能清晰地表达复杂的条件组合与所对应的操作之间的关系 。 判定树的优点在于它无须任何说明,一眼就能看出其含义,易于理解和使用 。
判定树举例加工逻辑描述工具的选择：
a.不太复杂的判断逻辑，使用判断树比较好；
b.复杂的判断逻辑，使用判断表比较好；
c.若一个处理逻辑既包含了一般的顺序执行动作，又包含了判断或循环逻辑，则使用结构化语言比较好。
第 2章 需求分析
3.5 原型化方法一,软件原型的分类
（ 1） 废弃 （ throw away） 型：先构造一个功能简单而且质量要求不高的模型系统,针对这个模型系统反复进行分析和修改,从而形成比较好的设计思想,据此设计出更加完整,准确,一致,可靠的最终系统 。 系统构造完成后,原来的模型系统就被废弃不用 。
（ 2） 追加 （ add on） 型：先构造 — 个功能简单而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充,修改,逐步追加新需求,最后发展成为最终系统 。
第 2章 需求分析二、快速原型开发模型原型生存期的模型模型的细化
（ 1） 快速分析在系统分析员和用户的紧密配合下,快速确定软件系统的基本需求 。 根据原型所要体现的特性 （ 或界面形式,或处理功能,或总体结构,或模拟性能等 ）,描述基本规格说明,以满足开发原型的需要 。
第 2章 需求分析
（ 2） 构造原型在快速分析的基础上,根据基本规格说明,尽快实现一个可运行的系统 。 此时主要考虑原型系统应充分反映的待评价的特性,对最终系统在某些细节上的要求,如安全性,健壮性,异常处理等可忽略 。
（ 3） 运行和评价原型这是频繁通信,发现问题,消除误解的重要阶段 。 其目的是验证原型的正确程度,进而修改原有的需求并开发新需求 。
第 2章 需求分析
（ 4） 修正和改进对原型系统根据修改意见进行修改 。 若原型运行的结果未能满足规格说明中的需求,则反映出对规格说明存在着不一致的理解或实现方案不够合理 。 若因为严重的理解错误而使正常操作的原型与用户需求相违背时,则有可能会产生废品 。
如果发现是废品应当立即放弃 。
（ 5） 判定原型完成经过修改或改进的原型,如果获得参与者一致认可,则原型开发的迭代过程可以结束 。 为此,
应判断有关应用的实质是否已经掌握,迭代周期是否可以结束等 。
第 2章 需求分析
（ 6） 判断原型细部是否说明判断组成原型的细部是否需要严格地加以说明 。 原型化方法允许对系统必要成份进行严格的详细的说明,例如将需求转化为报表,给出统计数字等 。 对于这些不能通过模型进行说明的成份,
如果必要,需提供说明,并利用屏幕等工具进行讨论和确定 。
（ 7） 原型细部的说明对于所有那些不能通过原型说明的项目,仍需通过文件加以说明 。 严格说明的成份要作为原型化方法的模型编入字典,以得到 — 个统一,连贯的规格说明 。
第 2章 需求分析
（ 8） 判定原型效果考察用户新加入的需求信息和细部说明信息,
看其对模型效果有什么影响？ 是否会影响模块的有效性？ 如果使模型效果受到影响,甚至导致模型失效,则要进行修正和改进 。
（ 9） 整理原型和提供文档整理原型的目的是为进一步开发提供依据 。
原型的初期需求模型是一个自动的文档 。
3.1 需求分析的任务需求分析的 任务就是准确地回答,系统必须做什么?” 这个问题,是通过系统分析员与用户一起商定,清晰,准确,具体地描述软件产品必须具有的功能,性能,运行规格等要求 。 软件需求分析阶段的目的是澄清用户的要求,并把双方共同的理解明确地表达成一份书面文档 —— 软件需求规格说明书 。
第 2章 需求分析需求分析的 具体任务包括：
（ 1）确定软件系统的综合需求
（ 2）分析系统的数据需求
（ 3）导出软件系统的逻辑模型
（ 4）修正系统开发计划
（ 5）开发原型系统
（ 6）验证软件需求分析的正确性
（ 7）编写软件需求规格说明书第 2章 需求分析
3.2 需求分析的过程需求分析阶段可分为四个过程：调查研究、
分析与综合、书写需求分析的文档和评审。
（ 1） 调查研究系统分析员协同程序员向用户做需求调查，
阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或 IPO图表示出来 。
第 2章 需求分析
（ 2） 分析与综合分析员需从数据流和数据结构出发,逐步细化所有的软件功能,找出系统中各元素之间的联系,接口特征和设计上的限制,分析它们能否满足功能要求,是否合理 。 依据功能需求,
性能需求,运行环境需求等,剔除其中不合理的部分,增加其需要的部分 。 最终综合成系统的解决方案后,给出目标系统的详细逻辑模型 。
第 2章 需求分析
（ 3） 书写需求分析的文档把分析的结果用正式的文档记录下来,作为最终软件配置的一个组成成分 。 应该完成下述四份文档资料：系统规格说明,数据需求,
用户系统描述,修正的开发计划 。
（ 4） 需求分析评审作为需求分析阶段的复查手段,在需求分析的最后一步,应该对功能的正确性,完整性和清晰性,以及其他需求给予评价 。
第 2章 需求分析
3.3 需求分析的原则
（ 1）能够表达和理解问题的信息域和功能域。
（ 2）能够对问题进行分解和不断细化，建立问题的层次结构。
（ 3）能够给出系统的逻辑视图和物理视图。
第 2章 需求分析
3.4 结构化分析方法结构化分析方法 （ Structured Analysis,简称
SA方法 ） 是 70年代中期提出的一种面向数据流,
自顶向下,逐步求精进行需求分析的方法 。
结构化分析方法适用于分析大型的数据处理系统,特别适用于企事业管理系统 。
结构化分析方法通常与设计阶段的结构化设计方法 （ Structured Designed,简称 SD方法 ） 衔接起来使用 。
第 2章 需求分析结构化分析方法中使用的工具主要包括：
数据流图,数据字典,结构化英语,判定表和判定树 。
其中数据流图用以表达系统内数据的运动情况；数据词典用以定义系统中的数据；结构化语言,判定表和判定树都是用以描述数据流的加工的工具 。
第 2章 需求分析一,数据流图数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。
1、数据流图的基本图形元素
（ 1）数据流：是一组数据。在数据流图中数据流用带箭头的线表示，在其线旁标注数据流名。
（ 2）加工：是对数据流执行的某种操作或变换。在数据流图中加工用圆圈表示，在圆圈内写上加工名。
（ 3）文件：是按照某种规则组织起来的、长度不限的数据。在数据流图中文件用一直线表示，在线段旁注上文件名。
（ 4）数据流的源点和终点：在数据流图中用方框表示，在框内写上相应的名称。
第 2章 需求分析
2,由外向里画数据流图的步骤
（ 1） 确定系统的输入输出：由于系统究竟包括哪些功能可能一时难于弄清楚,可使范围尽量大一些,把可能有的内容全部都包括进去 。
此时,应该向用户了解,系统从外界接受什么数据,,,系统向外界送出什么数据,等信息,
然后,根据用户的答复画出数据流图的外围 。
第 2章 需求分析
（ 2） 由外向里画系统的顶层数据流图首先,将系统的输人数据和输出数据用一连串的加工连接起来 。 在数据流的值发生变化的地方就是一个加工 。 接着,给各个加工命名 。 然后,
给加工之间的数据命名 。 最后,给文件命名 。
（ 3） 自顶向下逐层分解,绘出分层数据流图对于大型的系统,为了控制复杂性,便于理解,
需要采用自顶向下逐层分解的方法进行,即用分层的方法将一个数据流图分解成几个数据流图来分别表示 。
第 2章 需求分析二,数据字典数据字典的任务就是对于数据流图中所出现的所有被命名的图形元素在数据字典中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释 。
数据字典的内容包括：图形元素的名字,别名或编号,分类,描述,定义,位置等 。
数据字典中所有的定义都应是严密的,精确的,不可有半点含混,不可有二义性 。
数据词典中常用符号的含义第 2章 需求分析三,加工逻辑描述工具
1,结构化英语 （ Structured English）
结构化英语是一种介于自然语言和形式化语言之间的半形式化语言 。 它是在自然语言的基础上加了一些限制而得到的语言,它使用有限的词汇和有限的语句来描述加工逻辑 。
结构化英语的词汇表由英语命令动词,数据字典中定义的名字,有限的自定义词和控制结构关键词组成 。
结构化英语举例第 2章 需求分析
2.判定表在某些数据处理中,某数据流图的加工需要依赖于多个逻辑条件的取值,就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的 。 这时使用判定表来描述比较合适 。
一张判定表通常由四部分组成,左上部列出的是所有的条件,左下部为所有可能的操作,右上部分表示各种条件组合的一个矩阵,右下部分是对应于每种条件组合应有的操作 。
判定表举例第 2章 需求分析
3.判定树判定树是判定表的变种,它也能清晰地表达复杂的条件组合与所对应的操作之间的关系 。 判定树的优点在于它无须任何说明,一眼就能看出其含义,易于理解和使用 。
判定树举例加工逻辑描述工具的选择：
a.不太复杂的判断逻辑，使用判断树比较好；
b.复杂的判断逻辑，使用判断表比较好；
c.若一个处理逻辑既包含了一般的顺序执行动作，又包含了判断或循环逻辑，则使用结构化语言比较好。
第 2章 需求分析
3.5 原型化方法一,软件原型的分类
（ 1） 废弃 （ throw away） 型：先构造一个功能简单而且质量要求不高的模型系统,针对这个模型系统反复进行分析和修改,从而形成比较好的设计思想,据此设计出更加完整,准确,一致,可靠的最终系统 。 系统构造完成后,原来的模型系统就被废弃不用 。
（ 2） 追加 （ add on） 型：先构造 — 个功能简单而且质量要求不高的模型系统,作为最终系统的核心,然后通过不断地扩充,修改,逐步追加新需求,最后发展成为最终系统 。
第 2章 需求分析二、快速原型开发模型原型生存期的模型模型的细化
（ 1） 快速分析在系统分析员和用户的紧密配合下,快速确定软件系统的基本需求 。 根据原型所要体现的特性 （ 或界面形式,或处理功能,或总体结构,或模拟性能等 ）,描述基本规格说明,以满足开发原型的需要 。
第 2章 需求分析
（ 2） 构造原型在快速分析的基础上,根据基本规格说明,尽快实现一个可运行的系统 。 此时主要考虑原型系统应充分反映的待评价的特性,对最终系统在某些细节上的要求,如安全性,健壮性,异常处理等可忽略 。
（ 3） 运行和评价原型这是频繁通信,发现问题,消除误解的重要阶段 。 其目的是验证原型的正确程度,进而修改原有的需求并开发新需求 。
第 2章 需求分析
（ 4） 修正和改进对原型系统根据修改意见进行修改 。 若原型运行的结果未能满足规格说明中的需求,则反映出对规格说明存在着不一致的理解或实现方案不够合理 。 若因为严重的理解错误而使正常操作的原型与用户需求相违背时,则有可能会产生废品 。
如果发现是废品应当立即放弃 。
（ 5） 判定原型完成经过修改或改进的原型,如果获得参与者一致认可,则原型开发的迭代过程可以结束 。 为此,
应判断有关应用的实质是否已经掌握,迭代周期是否可以结束等 。
第 2章 需求分析
（ 6） 判断原型细部是否说明判断组成原型的细部是否需要严格地加以说明 。 原型化方法允许对系统必要成份进行严格的详细的说明,例如将需求转化为报表,给出统计数字等 。 对于这些不能通过模型进行说明的成份,
如果必要,需提供说明,并利用屏幕等工具进行讨论和确定 。
（ 7） 原型细部的说明对于所有那些不能通过原型说明的项目,仍需通过文件加以说明 。 严格说明的成份要作为原型化方法的模型编入字典,以得到 — 个统一,连贯的规格说明 。
第 2章 需求分析
（ 8） 判定原型效果考察用户新加入的需求信息和细部说明信息,
看其对模型效果有什么影响？ 是否会影响模块的有效性？ 如果使模型效果受到影响,甚至导致模型失效,则要进行修正和改进 。
（ 9） 整理原型和提供文档整理原型的目的是为进一步开发提供依据 。
原型的初期需求模型是一个自动的文档 。
