3.1 需求分析的任务

3.1.1 需求分析的概念

开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。需求分析虽处于软件开发过程的初期阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的。随着软件系统复杂性的提高及规模的扩大，需求分析在软件开发中的所处的地位愈加突出，从而也愈加困难。

1.需求分析的难点

(1)问题的复杂性。用户需求所涉及的因素很多，如系统功能和运行环境。

(2)交流障碍。需求分析涉及人员较多，分别具备不同的背景知识，处于不同的出发点，造成了相互之间交流的困难。

(3)不完备性和不一致性。用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾，需求分析要消除其矛盾，形成完备及一致的定义。

(4)需求易变性。用户需求的变动往往会影响到需求分析，导致系统的不一致性和不完备性。

2.需求分析的基本原则

(1)必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映数据域三方面的控制信息。

(2)可以把一个复杂问题按功能进行分解并可逐层细化。

(3) 建模。建立模型可以帮助分析人员更好地理解软件系统的信息、功能、行为，这些模型也是软件设计的基础。

3.1.2 需求分析的基本任务

1.问题识别

(1) 功能需求：明确所开发的软件必须具备什么样的功能。

(2) 性能需求：明确待开发的软件的技术性能指标。

(3) 环境需求：明确软件运行时所需要的软、硬件的要求。

(4) 用户界面需求：明确人机交互方式、输入输出数据格式。

2. 分析与综合，导出软件的逻辑模型

分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。

3. 编写文档

(1) 编写“需求规格说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。

(2) 编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。

(3) 编写确认测试计划，作为今后确认和验收的依据。

(4) 修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。

3.2 结构化分析方法

结构化分析（Structured Analysis,简称SA），是面向数据流进行需求分析的方法。SA也是一种建模活动，该方法使用简单易读符号，根据软件内部数据传递、变换的关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。

3.2.1 自顶向下逐层分解的分析策略

面对一个复杂的问题，分析人员不可能一开始就考虑到问题的所有方面以及全部细节，采用的策略往往是分解，把一个复杂的问题划分成若干小问题，然后再分别解决，将问题的复杂性降低到人可以掌握的程度。

3.2.2 描述工具

SA方法利用图形等半形式化的描述方式表达需求，简明易懂，用它们形成需求说明书中的主要部分。描述工具是：

(1)数据流图：描述系统由哪几部分组成，各部分之间有什么联系等等。

(2)数据字典：定义了数据流图中每一个图形元素。

(3)描述加工逻辑的结构化语言、判定表、判定树：详细描述数据流图中不能被再分解的每一个加工。

3.2.3 SA分析步骤

SA方法利用图形等半形式化的描述方式表达需求，简明易懂，用它们形成需求说明书中的主要部分。描述工具是：

(1)了解当前系统的工作流程，获得当前系统的物理模型。通过对当前系统的详细调查，了解当前系统的工作过程，同时收集资料、文件、数据、报表等，将看到的、听到的、收集到的信息和情况用图形描述出来。也就是用一个模型来反映自己对当前系统的理解，如画系统流程图。

(2)抽象出当前系统的逻辑模型。物理模型反映了系统“怎么做”的具体实现，去掉物理模型中非本质的因素，抽取出本质的因素，构造出当前系统的逻辑模型，反映了当前系统“做什么”的功能。

(3)建立目标系统的逻辑模型。分析、比较目标系统与当前系统逻辑上的差别，明确目标系统到底要“做什么”，从而从当前系统的逻辑模型导出目标系统的逻辑模型。

(4)作进一步补充和优化。为了对目标系统做完整的描述，还需要对得到的逻辑模型做一些补充.

3.3 数据流图(DFD)

数据流图，简称DFD，是SA方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。

下图是一个飞机机票预订系统的数据流图，它反映的功能是： 旅行社把预订机票的旅客信息 (姓名、年龄、单位、身份证号码、旅行时间、目的地等)输入机票预订系统。系统为旅客安排航班，打印出取票通知单(附有应交的账款)。旅客在飞机起飞的前一天凭取票通知单交款取票，系统检验无误，输出机票给旅客。

3.3.1 基本图形符号

数据流图有四种基本图形符号：

1.：箭头，表示数据流；

2.〇：圆或椭圆，表示加工；

3.= ：双杠，表示数据存储；

4.□：方框，表示数据的源点或终点。

(1) 数据流。数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。

(2)加工(又称为数据处理)。对数据流进行某些操作或变换。每个加工也要有名字，通常是动词短语，简明地描述完成什么加工。在分层的数据流图中，加工还应编号。

(3)数据存储(又称为文件)，指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。

(4)数据源点或终点，是本软件系统外部环境中的实体(包括人员、组织或其他软件系统)，统称外部实体。一般只出现在数据流图的顶层图。

3.3.2画数据流图的步骤

(1)首先画系统的输入输出，即先画顶层数据流图。顶层流图只包含一个加工，用以表示被开发的系统，然后考虑该系统有哪些输入数据、输出数据流。顶层图的作用在于表明被开发系统的范围以及它和周围环境的数据交换关系。下图为飞机机票预订系统的顶层图。

(2)画系统内部，即画下层数据流图。不再分解的加工称为基本加工。一般将层号从0开始编号，采用自顶向下，由外向内的原则。画0层数据流图时，分解顶层流图的系统为若干子系统，决定每个子系统间的数据接口和活动关系。例如，在上面的机票预订系统按功能可分成两部分，一部分为旅行社预订机票，另一部分为旅客取票，两部分通过机票文件的数据存储联系起来，0层数据流图如图3-4。

(3)注意事项。

①命名。不论数据流、数据存储还是加工，合适的命名使人们易于理解其含义。

②画数据流而不是控制流。数据流反映系统“做什么”，不反映“如何做”，因此箭头上的数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。

③一般不画物质流。数据流反映能用计算机处理的数据，并不是实物，因此对目标系统的数据流图一般不要画物质流。

④每个加工至少有一个输入数据流和一个输出数据流，反映出此加工数据的来源与加工的结果。

⑤编号。如果一张数据流图中的某个加工分解成另一张数据流图时，则上层图为父图，直接下层图为子图。子图及其所有的加工都应编号

⑥父图与子图的平衡。子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，此即父图与子图的平衡。

⑦局部数据存储。当某层数据流图中的数据存储不是父图中相应加工的外部接口，而只是本图中某些加工之间的数据接口，则称这些数据存储为局部数据存储。

⑧提高数据流图的易懂性。注意合理分解，要把一个加工分解成几个功能相对独立的子加工，这样可以减少加工之间输入、输出数据流的数目，增加数据流图的可理解性。

3.3.3流程图的实例--销售管理系统

某企业销售管理系统的功能为：

(1)接受顾客的订单，检验订单，若库存有货，进行供货处理，即修改库存，给仓库开备货单，并且将订单留底；若库存量不足，将缺货订单登入缺货记录。

(2)根据缺货记录进行缺货统计，将缺货通知单发给采购部门，以便采购。

(3)根据采购部门发来的进货通知单处理进货，即修改库存，并从缺货记录中取出缺货订单进行供货处理。

(4)根据留底的订单进行销售统计，打印统计表给经理。

根据上述的功能描述，画出如下的数据流程图。

3.4 数据字典(DD)

数据字典(Data Dictionary,简称DD)就是用来定义数据流图中的各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型，是需求规格说明书的主要组成部分。

3.4.1数据字典的内容以及格式

数据字典的任务是对于数据流图中出现的所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

数据字典有以下四类条目：数据流、数据项、数据存储、基本加工。

数据词典中所有的定义应是严密的、精确的，不可有半点含混，不可有二义性。

1.数据流条目

数据流条目给出了DFD中数据流的定义，通常列出该数据流的各组成数据项。在定义数据流或数据存储组成时，使用的符号如3-1表：

举例：定义数据流组成及数据项。

机票=姓名+日期+航班号+起点+终点+费用

姓名={字母}

航班号=“Y7100”...“Y8100”

终点=[上海|北京|西安]

数据流条目主要内容及举例如下：

数据流名称：订单

别名：无

简述：顾客订货时填写的项目

来源：顾客

去向：加工1“检验订单”

数据流量：1000份/每周

组成：编号+订货日期+顾客编号+地址+电话+银行账号+货物名称+规格+数量

2.数据存储条目

数据存储条目是对数据存储的定义，如：

数据存储名称：库存记录

别名：无

简述：存放库存所有可供货物的信息

组成：货物名称+编号+生产厂家+单价+库存量

组织方式：索引文件，以货物编号为关键字

查询要求：要求能立即查询

3.数据项条目

数据项条目是不可再分解的数据单位，，其定义格式如下：

数据项名称：货物编号

别名：G-No,G-num,Goods-No

简述：本公司的所有货物的编号

类型：字符串

长度：10

取值范围及含义：

第一位：进口/国产

第2-4位：类别

第5-7位：规格

第8-10位：品名编号

4.加工条目

加工条目是用来说明DFD中基本加工的处理逻辑的，由于上层的加工是由下层的基本加工分解而来，只要有了基本加工的说明，就可理解其他加工。举例如下：

加工名：查阅库存

编号：1.2

激发条件：接收到合格订单时

优先级：普通

输入：合格订单

输出：可供货订单、缺货订单

加工逻辑：根据库存记录

IF 订单项目的数量<该项目库存量的临界值>

THEN 可供货处理

ELSE 此订单缺货，登录，待进货后再处理

ENDIF

3.5 加工逻辑的描述

加工逻辑也称为“小说明”，描述加工逻辑一般用以下三种工具：结构化语言、判定表、判定树。

3.5.1结构化语言

结构化语言是介于自然语言和形式语言之间的一种半形式语言。结构化语言是在自然语言基础上加了一些限定，使用有限的词汇和有限的语句来描述加工逻辑，它的结构可分成外层和内层两层：

(1)外层：用来描述控制结构，采用顺序、选择、重复三种基本结构。

(2)内层：一般是采用祈使语句的自然语言短语，使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不用形容词和副词来修饰。

3.5.2判定表

在有些情况下，数据流图中的某些加工的一组动作信赖于多个逻辑条件的取值。用自然语言或结构化语言都不易清楚地描述出来。而用判定表就能够清楚地表示复杂的条件组合与应做的动作之间的对应关系。

判定表由四个部分组成，如下3-2表所示，构造一张判定表，可采用以下步骤：

(1)提取问题中的条件。

(2)标出条件的取值。

(3)计算所有条件的组合数N。

(4)提取可能采用的动作或措施。

(5)制作判定表。

(6)完善判定表。

表3-2判定表结构

3.5.3 判定树

判定树是判定表的变形，一般情况下它比判定表更直观，且易于理解和使用。

这三种描述加工逻辑的工具各有优缺点，对于顺序执行和循环执行的动作，用结构语言描述。对于存在多个条件复杂组合的判断问题，用判定表和判定树。判定树较判定表直观易读，判定表进行逻辑验证较严格，能把所有的可能性全部都考虑到。可将两种工具结合起来，先用判定表底稿，在经基础上产生判定树。

3.6 IDEF方法

IDEF方法是美国空军在1981年针对集成化计算机辅助制造(Integrated Computer Aided Manufacturing,简称ICAM)工程项目中用于进行复杂系统分析和设计的方法,是在结构化分析与设计技术的基础上提出来的。IDEF是ICAM Definition的缩写。IDEF方法分为三部分。

IDEF0: 用来描述系统的功能活动及其联系，建立系统的功能模型。

IDEF1: 用来描述系统的信息以及其联系，建立系统的信息模型。

IDEF2: 用来进行系统模拟，建立系统的动态模型。

3.6.1 IDEF0的图形表示

IDEF0方法采用简单的图形符号和简洁的文字说明，描述系统在不同层次上的功能。在该方法中，将系统功能称为活动，将表示系统功能的图形称为活动图形。在活动图形中，用方框和箭头表示系统的各种活动及相互间的关系。

3.6.2建立功能模型的基本方法

1.确定建模的范围、观点及目的

在开始为系统建立模型时，首先要确定建模的立足点，包括范围、观点及目的。范围所讨论的对象是什么，它的边界和外部接口是什么；观点指从什么角度去考虑所研究的题；目的指确定所研究问题的意图及理由。

2.建立系统的内外关系图--A-0图

IDEF0方法建立的功能模型是一组有层次关系的图形，以字母A开头的编号来标志图形在层次中的位置。先建立系统的内外关系图，该图用来抽象地描述所研究的问题及其边界或数据接口。图中只有一个活动，活动名概括地描述系统的内容，用进入和离开的箭头表系统与环境的数据接口，确定了系统边界。

3.建立顶层图--A-0图

把A-0图分解为3-6个主要部分得到A0图，它清楚地表达了A--0图在同样信息范围内的细节，从结构上反映了模型的观点，是系统功能模型真正的顶层图。该图中各方框所表示活动的详细含义由低层次的图形说明。

4.建立低层次的图形

按照自顶向下的方法，从A0图开始逐层分解，建立一系列的活动图形，直到最低层为止。

如果您需要写或者学习软件工程，需求分析这块推荐这篇文章，我看了基本上就明白了，很易懂。