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

第三章需求分析

需求分析

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

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

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

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

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