需求分析(传统结构化方法)

2.2需求分析需求分析是通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。

2.2.1需求分析的目的与意义需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。

有效的需求分析通常都具有一定的难度。

需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。

此外，为了方便后续的评审和测试等工作，需求的描述应该尽量做到：具体、详细、可以测量和可以实现，并且基于时间。

2.2.2需求分析的步骤2-3所示。

需求涉及的方面：在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。

在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。

在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。

在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。

1. 获取需求，识别问题开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。

开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。

遗漏需求是最难修订的需求错误。

获取需求是需求分析的基础。

为了能有效地获取需求，开发人员应该采取科学的需求获取方法。

在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。

问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。

通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。

采用这种方法时，调查问卷的设计很重要。

一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。

开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。

但是，对开放式问题进行汇总和分析的工作会比较复杂。

封闭式问题的答案是预先设定的，用户从若干答案中进行选择。

封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。

访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。

为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。

在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。

由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。

当然，进行详细的记录也是访谈过程中必不可少的工作。

访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。

关注用户的行为而不是他们的言语。

为了深入地了解用户需求，有时候开发人员还会以用户的身份直接参与到现有系统的使用过程中，在亲身实践的基础上，更直接地体会现有系统的弊端以及新系统应该解决的问题，这种需求获取方法就是实地操作。

通过实地操作得到的信息会更加准确和真实，但是这种方法会比较费时间。

当用户本身对需求的了解不太清晰的时候，开发人员通常采用建立原型系统的方法对用户需求进行挖掘。

原型系统就是目标系统的一个可操作的模型。

在初步获取需求后，开发人员会快速地开发一个原型系统。

通过对原型系统进行模拟操作，开发人员能及时获得用户的意见，从而对需求进行明确。

利用原型系统获取需求的方法的示意图如图2-4所示。

2. 分析需求，建立目标系统的逻辑模型在获得需求后，开发人员应该对问题进行分析抽象，并在此基础上从高层建立目标系统的逻辑模型。

模型是对事物高层次的抽象，通常由一组符号和组织这些符号的规则组成。

常用的模型图有数据流图、E-R图、用例图和状态转换图等，不同的模型从不同的角度或不同的侧重点描述目标系统。

绘制模型图的过程，既是开发人员进行逻辑思考的过程，也是开发人员更进一步认识目标系统的过程。

3. 将需求文档化获得需求后要将其描述出来，即将需求文档化。

对于大型的软件系统，需求阶段一般会输出三个文档：系统定义文档（用户需求报告）；系统需求文档（系统需求规格说明书）；软件需求文档（软件需求规格说明书）。

对于简单的软件系统而言，需求阶段只需要输出软件需求文档（即软件需求规格说明书）就可以了。

软件需求规格说明书主要描述软件的需求，从开发人员的角度对目标系统的业务模型、功能模型和数据模型等内容进行描述。

作为后续的软件设计和测试的重要依据，需求阶段的输出文档应该具有清晰性、无二义性和准确性，并且能够全面和确切地描述用户需求。

4. 需求验证需求验证是对需求分析的成果进行评估和验证的过程。

为了确保需求分析的正确性、一致性、完整性和有效性，提高软件开发的效率，为后续的软件开发做好准备，需求验证的工作非常必要。

在需求验证的过程中，可以对需求阶段的输出文档进行多种检查，比如，一致性检查、完整性检查和有效性检查等。

同时，需求评审也是在这个阶段进行的。

2.3 结构化需求分析的方法结构化需求分析是20世纪70年代由Yourdon、Constaintine及DeMarco提出的一种面向数据流的需求分析方法。

它基于"分解"和"抽象"的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。

"分解"是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。

图2-5演示了对目标系统X进行自顶向下逐层分解的示意图。

能，而最底层是对每个模块实现方法的细节性描述。

可见，在逐层分解的过程中，起初并不考虑细节性的问题，而是先关注问题最本质的属性，随着分解自顶向下进行，才逐渐考虑越来越具体的细节。

这种用最本质的属性表示一个软件系统的方法就是"抽象"。

抽象是一种人类处理复杂问题的基本方法。

分解和抽象是结构化需求分析的基本指导思想。

在结构化需求分析的过程中，通常还需要借助数据流程图、数据字典、E-R图、结构化语言、判定表、判定树等工具。

接下来我们介绍数据流图、数据字典和E-R图的相关知识。

2.4结构化需求分析的工具2.4.1数据流图数据流图（Data Flow Diagram，DFD）是描述系统中数据流的图形工具，是一种用来表示信息流和信息变换过程的图解方法，可以标识一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。

数据流图把软件系统看成是由数据流联系的各种功能的组合，在需求分析的过程中，可以用来建立目标系统的逻辑模型。

结构化需求分析采用的是"自顶向下，由外到内，逐层分解"的思想，开发人员要先画出系统顶层的数据流图，然后再逐层画出低层的数据流图。

顶层的数据流图要定义系统范围，并描述系统与外界的数据联系，它是对系统架构的高度概括和抽象。

底层的数据流图是对系统某个部分的精细描述。

数据流图的目的是在用户和系统开发人员之间提供语义的桥梁。

--Kenneth Kozar按照Gane-Sarson法，在绘制数据流图的过程中，主要用到了4个基本符号，如表2-1所示。

表2-1数据流图的基本符号1 SA 法概述SA 法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。

1．SA 法的基本思想结构化分析（Structured Analysis，简称SA 法）是面向数据流的需求分析方法，是70年代由Yourdon,Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。

结构化分析方法的基本思想是“分解”和“抽象”。

分解：是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。

图4 是自顶向下逐层分解的示意图。

顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层是从抽象到具体的逐层过渡。

抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个自系统的方法就是“抽象”。

2．SA 法的步骤⑴建立当前系统的“具体模型”；系统的“具体模型”就是现实环境的忠实写照，即将当前系统用DFD 图描述出来。

这样的表达与当前系统完全对应，因此用户容易理解。

⑵抽象出当前系统的逻辑模型；分析系统的“具体模型”，抽象出其本质的因素，排除次要因素，获得用DFD 图描述的当前系统的“逻辑模型”。

⑶建立目标系统的逻辑模型；分析目标系统与当前系统逻辑上的差别，从而进一步明确目标系统“做什么”，建立目标系统的“逻辑模型”（修改后的DFD 图）。

⑷为了对目标系统作完整的描述，还需要考虑人机界面和其它一些问题。

3．SA 法的描述工具⑴分层的数据流图⑵数据词典⑶描述加工逻辑的结构化语言、判定表或判定树。

2 数据流图数据流图（Data Flow Diagram，简称DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。

1．数据流图的图符数据流图有以下4 种基本图形符号：箭头表示数据流，圆或椭圆表示加工。

双杠或者单杠表示数据存储，矩形框表示数据的源点或终点，即外部实体。

⑴数据流是数据在系统内传播的路径，由一组成固定的数据项组成。

除了与数据存储（文件）之间的数据流不用命名外，其余数据流都应该用名词或名词短语命名。

数据流可以从加工流向加工，也可以从加工流向文件或从文件流向加工，也可以从源点流向加工或从加工流向终点。

⑵加工也称为数据处理，它对数据流进行某些操作或变换。

每个加工也要有名字，通常是动词短语，简明地描述完成什么加工。

在分层的数据流图中，加工还应有编号。

⑶数据存储指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。

流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可理解为从文件读数据或得到查询结果。

⑷数据源点和终点是软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体。

一般只出现在数据流图的顶层图中。

还有一些辅助的图例:例1：画出图书预定系统的DFD 图。

现有一图书预定系统，接收由顾客发来的订单，并对订单进行验证，验证过程是根据图书目录检查订单的正确性，同时根据顾客档案确定是新顾客还是老顾客，是否有信誉。

经过验证的正确订单，暂存放在待处理的订单文件中。

对订单进行成批处理，根据出版社档案，将订单按照出版社进行分类汇总，并保存订单存根，然后将汇总订单发往各出版社。