软件工程导论—需求分析

文章目录

• • • 1. 需求分析概述
    • • 1.1. 软件需求的概念
      • 1.2. 需求分析的准则
      • 1.3. 需求分析的任务和步骤
    • 2. 需求获取的常用方法和步骤
    • 3. 分析建模
    • • 3.1. 结构化分析模型
      • • 3.1.1. 结构化分析模型概述
        • 3.1.2. 实体联系图 E-R图
        • 3.1.3. 数据流图 DFD
        • 3.1.4. 结构化分析方法
      • 3.2. 面向对象分析模型
    • 4. 软件需求说明 SRS
    • • 4.1. 需求规格说明
      • 4.2. 验证软件需求

1. 需求分析概述

1.1. 软件需求的概念

软件需求就是用户对目标软件系统的期望。

为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获
得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望,
并且给开发者带来烦恼。

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答”系统必须做什么”这个问题，最终的成品是一份”软件需求规格说明书”。

通常来说，用户的需求包含了以下几个方面：

1. 功能需求
   这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能
2. 性能需求
   性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
3. 可靠性和可用性需求
   可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4. 出错处理需求
   这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么。需要注意的是，这类错误并不是由该应用系统本身造成的。
5. 接口需求
   接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求、硬件接口需求、软件接口需求、通信接口需求。
6. 约束
   设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台。
7. 逆向需求
   逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，人们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。
8. 将来可能提出的要求
   应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

1.2. 需求分析的准则

尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都遵守下述准则。

1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型
   主要使用ERD工具，即实体—联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形；
2. 必须定义软件应完成的功能，这条准则要求建立功能模型
   主要使用DFD工具，即数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，是建立功能模型的基础；
3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型
   主要使用STD工具，即状态转换图，指明了作为外部事件结果的系统行为，描绘了系统的各种行为模式(称为”状态”)和在不同状态间转换的方式，是行为建模的基础；
4. 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

1.3. 需求分析的任务和步骤

需求分析的任务有：

1. 建立分析模型
2. 编写需求说明

需求分析的步骤有：

1. 问题分析
2. 需求描述
3. 需求评审

关于需求分析的任务，可以用下图来表示建立分析模型的过程：

结构化分析模型常用的分析工具有

1. DFD、DD、PSPEC
   数据流图（DFD） 是描述系统信息在系统中的流动和处理的逻辑模型，它可以是用来交流信息的工具，也可以是结构化分析和设计的工具；
   数据字典（DD） 是 DFD中所有元素的定义的集合，它的内容包括：数据流、数据存储和处理。DD一般用作分析阶段的交流工具和数据库设计的基础；
   加工说明（PSPEC） 用来详细说明DFD中的每个加工（处理）。

2. CFD、CSPEC、STD
   控制流图（CFD）和控制加工图（CSPEC） 适用于实时系统的分析，相互配合使用；
   状态转换图（STD） 通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为模型。状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
   一个典型的状态转换图框架如图所示：
   

   数据规范化
   软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

   通常用”范式(Normal Forms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。

   但通常来说在实际设计数据库时只采用到第三范式就足够了，范式并非越高越好，要结合实际情况使用，原因是：

   1. 范式级别越高，存储同样数据就需要分解成更多张表，对数据库的编程就越麻烦；
   2. 随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差；
   3. 范式级别提高则需要访问的表增多，导致性能下降,

   3.1.3. 数据流图 DFD

   DFD是描述系统信息在系统中的流动和处理的逻辑模型，它可以是用来交流信息的工具，也可以是结构化分析和设计的工具。

   如下面的顶级DFD所示，展示的是一个”教材购销系统”的外部界面，该图中有两个外部实体”学生”、“书库管理员”，”学生”把购书单交给系统，然后从系统拿到领书单；书库管理员从系统获取到缺书单，然后给系统发送进书通知。
   

   3.1.4. 结构化分析方法

   结构化方法的基本思想和主要原则在系统分析中的应用所形成的一系列具体方法和有关工具的总称。所谓结构化，就是用一组规范的步骤、准则和工具来进行某项工作。

   它主要是为了解决早期软件开发过程中存在的一些主要问题，例如：

   1. 工作阶段划分不明确，各阶段的工作缺乏规范的章程、方法、表达工具与标准。用户参与程度低，用户与专业人员对话缺乏有效手段；
   2. 系统分析、设计工作不深入，工作任务集中在了系统实施阶段；
   3. 系统实施采用”自底向上”的方法，系统总体功能与目标的实现难以保证。

   结构化分析方法的基本思路是基本思路：把整个系统开发过程分成若干阶段，每个阶段进行若干活动，每项活动应用一系列标准、规范、方法和技术，完成一个或者多个任务，形成符合给定规范的产品。

   在进行结构化分析时，主要遵循如下原则

   1. 用户参与
   2. “先分析、后编码”：重视调查、分析、论证，逻辑方案设计；
   3. “自顶向下”：”自顶向下”是主导原则，”自底向上”是辅助原则；
   4. 工作成果描述标准化：文档化、图形化。

   3.2. 面向对象分析模型

   面向对象分析模型可以用下面一张图来概括：
   

   
   可以看出，面向对象分析模型分为三个部分：类/对象模型、对象-关系模型、对象-行为模型

   面向对象分析模型常用的分析工具有

   1. 用例图、类对象图
   2. 对象-关系图，用来表示静态关系
   3. 对象-行为图，用来表示动态关系

   在掌握以上分析工具的基础上，按照下面的步骤进行面向对象分析

   1. 定义系统的用例
   2. 领域分析，建立类对象模型
   3. 建立对象-关系模型
   4. 建立对象-行为模型
   5. 编写SRS

   4. 软件需求说明 SRS

   4.1. 需求规格说明

   写需求规格说明的目标是为了便于用户、分析人员、设计人员进行交流，并且支持目标软件系统的确认，控制系统进化过程(追加需求)

   4.2. 验证软件需求

   需求分析阶段的工作结果是开发软件系统的重要基础,大量统计数字表明，软件系统中15%的错误起源于错误的需求。

   为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证
   这些需求的正确性。一般说来，应该从下述4个方面进行验证。

   1. 一致性。所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾；
   2. 完整性。需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能；
   3. 现实性。指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的；
   4. 有效性。必须证明需求是正确有效的，确实能解决用户面对的问题。

   声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！