软件工程技术--第三章需求分析

第三章需求分析

需求分析

需求分析的任务是要准确地定义新系统的目标，准确回答“系统必须做什么”的问题，并用需求规格说明书规范的形式准确地表达用户的需求。

虽然在可行性研究阶段，对用户需求有了初步了解，但对需求的了解是概括的、粗略的，许多细节被忽略了。可行性研究是决定“做还是不做”，而不是对需求进行定义。而需求分析阶段则需要充分理解用户需求，通过分析得出对新系统完整、准确、清晰、具体的要求。

需求分析的结果是否正确，关系到软件开发的成败和软件产品的质量，正确的需求分析是整个系统开发的基础。

需求分析实际上分为两个阶段：需求理解获取阶段和需求表达阶段。前一个阶段在充分了解需求的基础上，建立起系统的逻辑模型；后一个阶段把需求文档化，用软件需求规格说明书的方式把需求表达出来

3.1需求获取的方法

在需求分析过程中，需求获取阶段是开发人员和用户交往最多的阶段。

所以，开发人员与用户之间要进行充分和有效的沟通，需要采取科学的需求获取方法与技巧。

需求分析的基本任务是软件人员和用户一起完全弄清用户对系统的确切要求

1.需求获取的基本原则

深入浅出

需求获取要尽可能全面、细致。调研获取的需求是个全集，而目标系统真正实现的是个子集。分析时的调研内容并不一定都要纳入到新系统中，但全面、细致的调研既有利于弄清系统全局，又有利于以后的扩充。

以流程为主线

在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构和处理规则等，这样便于交流沟通。流程的描述既要有宏观描述，也要有微观描述。

2.需求获取的途径和方法

1.问卷调查

2.访谈和会议

3.市场调查

4.实地操作

5.建立原型

3.需求调研的步骤

要获取用户需求，就需要深入企业现场调研，需求调研的步骤如下：

（1）调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。

（2）调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。

（3）对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层和决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。

（4）对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。

（5）若需求基线符合要求，则需求分析完毕；反之返回到前面某一步。如此循环多次，直到需求分析使双方满意为止。

3.2需求分析的步骤

1.需求获取

此阶段的工作是需求获取、问题识别，即收集并明确用户需求的过程。

首先，系统分析员要研究可行性研究报告和软件项目实施计划。主要是从系统的角度来理解软件，确定对目标系统的综合要求，即软件的需求。还要提出这些需求实现的条件，以及需求应达到的标准。也就是解决待开发系统需要==“做什么”，“做到什么程度”==的问题。

这些需求包括：（1）功能需求：（2）性能需求：（3）环境需求：（4）可靠性需求：（5）安全保密性需求：（6）用户界面需求：（7）资源使用需求：（8）软件成本消耗与开发进度需求：（9）预计系统可达到的目标：

在功能方面：
- 需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。
在性能方面：
- 需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。
在运行环境方面：
- 需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。
在界面方面：
- 需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。

2.分析建模

获取到需求后，要把来自用户的信息加以分析，通过“抽象”建立待开发的系统逻辑模型。模型是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。为待开发系统建立模型，有助于人们更好地理解问题，常用的建模方法有数据流图、实体联系图（E-R图）、状态转换图、用例图、类图、对象图等。

3.需求描述

需求描述就是指编制需求分析阶段的文档。即将已经过分析的需求清晰、全面、系统、准确地描述成正式的文档——软件需求规格说明书。

软件需求规格说明书以开发人员的角度，对开发系统的业务模型、功能模型、数据模型等内容进行描述，明确地表达了用户与系统分析员对软件系统的共同理解，将作为概要设计和详细设计的基线。

对于复杂的软件系统，此阶段除产生软件需求规格说明书（称软件需求文档，主要描述软件部分的需求）外，还要产生系统定义文档（即用户需求报告）和系统需求文档（即系统需求规格说明书）。

4.需求验证

需求验证就是验证（复查）需求分析的成果，也称综合评审。需求验证就是对需求的正确性进行严格的验证，确保需求的一致性、完整性、清晰性、现实性和有效性，确保设计与实现过程中的需求可回溯性，并进行需求变更管理。

一般情况下，需求验证以用户、系统分析员、系统设计人员和管理人员共同参与的会议形式进行，最后由评审负责人签字。

3.3需求分析的任务

需求分析的任务是明确用户对系统的确切要求。

需求分析是发现、逐步求精、建模、规格说明和复审的过程。

需求分析的具体任务

1.确定目标系统的具体要求

(1)确定系统的运行环境要求：硬件、软件

(2)系统的性能要求：存储容量、安全性、响应时间等

(3)确定系统功能：确定目标系统必须具备的所有详细的功能。

2.建立目标系统的逻辑模型

建模的基本目标是：
- 描述用户需求
- 为软件的设计奠定基础
- 定义一组需求，用以验收产品。
模型分为：
- 数据模型:用实体—关系图，描述对象之间的关系
- 功能模型:用数据流图，描述数据在系统中如何变换
- 行为模型:用状态转换图，描绘系统的各种行为模式（状态）和不同状态的转换

3.4需求分析常用的方法：

面向数据流的结构化分析方法(SA)
面向数据结构的Jackson方法(JSD)
面向数据结构化数据系统开发方法(DSSD)
面向对象的分析方法（OOA）

结构化需求分析方法

结构化分析方法分析策略

结构化分析（Structured Analysis，简称SA）方法是一种面向数据流的分析方法，适用于大型的数据处理系统。由于利用图形来表达需求会使文档清晰、简明、易于学习和掌握，所以软件分析人员仍在广泛使用这种传统的分析方法。

结构化分析方法总的指导思想是“自顶向下，逐步求精”，它的两个基本原则是“抽象”和“分解”，即按照功能分解的原则，对系统进行逐层分解，直到找到所有满足功能要求的可实现软件元素为止。

结构化分析方法描述工具

数据流图（DFD）：它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。

数据流图（DFD）是软件系统的逻辑模型，仅仅描绘数据在软件中流动（从输入移动到输出）的过程中所经受的变换（即加工处理）。

数据流图（DFD）与系统流程图、程序流程图不同，数据流图是从数据角度来描述一个系统，而流程图是从对数据进行加工的工作人员的角度来描述系统。

结构化分析方法分析步骤

数据流图的绘制方法

1.根据数据流图的四种成分：数据源点或终点，处理，数据存储和数据流；

为了避免在数据流图上出现线条交叉，同一个源点、终点或文件均可在不同位置多次出现，这时要在源(终)点符号的右下方画小斜线，或在文件符号左边画竖线，以示重复。

数据流和数据存储都是数据，只是状态不同。数据存储是处于静止状态的数据，数据流是运动着的数据。

2.然后依据“自顶向下、从左到右、由粗到细、逐步求精”的基本原则进行绘制。

数据流图的设计原则

数据流图的三大设计原则：

（1）父图与子图的平衡原则：子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，此即父图与子图的平衡。

（2）数据守恒原则：对任何一个加工来说，其所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据。

（3）守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，即使它们的组成成分相同。

需求分析的图形工具

数据词典（DD）：明确定义数据流图中的数据和加工。它是数据流条目、数据存储条目、数据项条目和基本加工条目的汇集。
- 数据字典的主要任务是: 对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。
数据词典的条目主要分为四大类：数据项，数据流，数据存储，数据处理。

数据项（数据元素）

描述：图中的每一个数据结构都是由数据项构成的，数据项是数据处理中最小的，不可再分割的单位，它直接反映事物的某一特征。对于这些数据元素也必须在数据字典中给出描述。

描述不可再分解的数据单位，包括：名称、别名、取值范围和取值含义、数据类型及长度(精度)、描述。

数据流

主要说明数据流由哪些数据项组成，数据在单位时间内的流量，以及数据的来源和去向等。

主要包括：数据流名：

说明：简要介绍作用即它产生的原因和结果。

数据流来源：即该数据流来自何方。

数据流去向：去向何处。

数据流组成：数据结构。

数据处理（加工）

也称加工说明，主要说明加工的输入数据、输出数据及加工逻辑等。

主要包括：处理名:

**处理编号:**反映该处理的层次

简要描述:处理逻辑及功能简述

数据存储

主要说明文件由哪些数据项组成，及文件存储的方式和存取频率等。

包括：数据文件名：

简述：存放的是什么数据。

输入数据:

输出数据:

**数据文件组成:**数据结构。

存储方式:顺序，直接，关键码。

存取频率:

数据词典的实现

(1)人工方法。(2)自动方法。(3)人工和自动混合的方法。

注意：不论通过哪种途径实现的数据词典都应尽量做到以下几点：

(1)没有冗余：主要指数据定义不能重复。在规格说明书的其他组成部分中已出现的信息不能重复。

(2)查阅方便：通过名字可以方便地查阅数据词典中的每个定义。

(3)定义的书写方法简单、方便、严谨，而且可读性强。(4)建议采用卡片形式书写。

实体关系图

实体关系图（Entity-Relationship Diagram），简称E-R图，由矩形框、菱形框、圆形及连线组成。使用实体关系图描述系统的数据模型。

数据模型中包含3种相互关联的信息:数据对象、数据对象的属性、数据对象的关系。

数据对象（实体）：可以触及的客观对象学生、课程、职工……等是实体定义：客观存在并可以相互区分的客观事物。
数据对象的属性（属性）：实体所具有的某一特性称为属性。
数据对象的关系（联系）
状态转换图

状态转换图（State Transform Diagram，STD）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

**状态转换图的状态有三种包括初态(即初始状态) 、终态(即最终状态)和中间状态。**在一张状态转换图中只能有一个初态，而终态则可以有0至多个。

事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。

需求分析评审的主要内容如下：

（1）一致性。所有需求必须是一致的，任何一条需求不能和其他需求相矛盾。

（2）完整性。需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

（3）现实性。指定的需求应该是用现有的软硬件技术基本上可以实现的。对硬件技术的进步可以预测，

对软件技术的进步则很难预测，只能从现有技术水平判断需求的现实性。

（4）有效性。必须证明需求是正确而有效的，确实能解决用户所面对的问题。