软件工程之软件需求分析

• 一、需求分析任务
• • 1.用户需求
  • 2.系统需求
  • • （1）功能需求
    • （2） 数据需求
    • （3） 其他需求
• 二、需求分析过程
• 三、用户需求获取
• • 1.研究用户
  • 2. 从调查中获取用户需求
  • 3.通过原型完善用户需求
• 四、结构化分析建模
• • 1.功能层次模型
  • 2.数据流模型
  • • （1）数据流图特点
    • （2）数据流图的用途
    • （3） 数据流细化过程
    • （4） 数据流图中符 的命名
    • （5）数据流图中的数据字典
  • 3.数据关系模型(ER图)
  • • （1）数据实体
    • （2）数据关系
    • （3）数据属性
  • 4.系统状态模型
  • • （1）状态图特点
    • （2）状态图应用举例
• 五、需求有效性验证
• • 1.需求验证内容
  • • （1）有效性验证
    • （2） 一致性验证
    • （3）完整性验证
    • （4）现实性验证
    • （5）可检验性验证
  • 2.需求验证方法
  • • 1. 需求评审
    • 2. 需求原型评价
    • 3. 基于 CASE 工具的需求一致性分析
• 六、需求规格定义
• 小结:
• • 1. 需求分析任务
  • 2. 需求分析过程
  • 3. 用户需求获取
  • 4. 结构化分析建模
  • 5. 需求有效性验证
  • 6. 需求规格定义

软件需要解决的是用户所面临的现实问题，但是，这些现实问题需要由软件技术人员来解 决。情况往往是，开发软件的技术人员精通计算机技术，但并不熟悉用户的业务领域；而用户 清楚自己的业务，却又不太懂计算机技术。因此，对于同一个问题，技术人员和用户之间可能 存在认识上的差异。也因此，在软件技术人员着手设计软件之前，需要由既精通计算机技术又 熟悉用户应用领域的软件系统分析人员，对软件问题进行细致的需求分析。 需求分析是软件工程过程中一个重要的里程碑。在需求分析过程中，软件系统分析人员通 过研究用户在软件问题上的需求意愿，分析出软件系统在功能、性能、数据等诸多方面应该达 到的目标，从而获得有关软件的需求规格定义，其信息流如图 4-1 所示。

需求分析是在软件系统分析人员的操作下进行的，在这个过程中，用户和开发者之间需要 达成的是对系统的一致性需求认识。实际上，可以把软件系统分析人员看成是软件用户与软件 开发技术人员之间的信息通道，其作用是使用户对软件问题的现实描述，能够有效地转变为开 发软件的技术人员所需要的对软件的技术描述，以方便技术人员对软件的技术构建

（3）系统需求是面向技术人员的。因此，它不仅需要从需求原型中提取系统模型，而且需 要对系统模型进行细节化处理，例如：数据流细化、数据字典分解、类模型的定义等，由此获 得对系统的详细的技术性需求说明。

（4）对需求框架、系统模型和需求细节等文档进行有效性验证，由此产生出用户方、开发 方都能接受的关于软件的需求规格说明书。

三、用户需求获取

优秀软件总是能够最大限度地满足用户需求。因此，有效获取用户需求，是实施软件开发 时需要完成的第一项工作。

1.研究用户

在建立软件抽象模型过程中，用户可以被当作为一个抽象概念，泛指诸多从系统获得服务 的系统以外的对象，例如：软件使用机构，软件操作人员，以及从软件获得信息服务的其他系 统或设备。也就是说，可以把用户看作为系统的外部应用接口。但从软件的商业服务角度来看， 用户则主要是指购置软件的机构、使用软件的部门、操作软件的人。 软件是为用户开发的，为了使软件能够更好地为用户服务，在软件需求阶段，软件开发者 应该尽量充分地和用户进行沟通，了解用户的意图。例如，用户希望软件为他提供哪些方面的 服务，用户在操作软件时有哪些工作习惯，喜欢什么样的工作界面等。 软件往往需要为各种不同的用户服务，例如，用户机构负责人、使用软件的部门主管、软 件操作人员，他们都是用户，但由于所处位置不同，因此会有不同的需求。软件操作人员大多需要较长时间地操作软件，因此他们会特别关心软件的工作方式、界面布局；使用软件的部门 主管则一般不会直接操作软件，但他需要从软件中得到年度 表之类的打印数据，因此比较关 心软件能够提供哪些方面的 表， 表格式如何等。 用户情况是复杂的，为了更好地研究用户，有必要对软件用户做一些分类，例如：按软 件需求层次不同，将用户分为高层用户、中层用户和基层用户；按使用软件时间长短不同， 将用户分为熟练用户和非熟练用户；按是否直接操作软件系统，将用户分为直接用户和间接 用户。

2. 从调查中获取用户需求

（1）仓库管理系统将被计划部门、仓库管理部门、采购部门、销售部门的相关工作人员使 用。其中，计划部门制定商品计划，涉及：设置商品类别、登记商品、制定商品 损计划和进 行商品流通数据汇总；仓库管理部门完成仓库的日常管理，涉及：商品入库、出库、 损和查 询等多项操作；采购部门可以查询商品库存情况、打印商品定货 表；销售部门可以查询商品 库存情况和提交商品定货请求。

（2）由于不同部门有不同的任务，因此系统需要提供针对部门的权限管理机制和针对工作人员的登录注册机制。系统将通过一位系统管理员进行部门授权与工作人员注册管理。

（3）进入仓库管理系统的工作人员需要有惟一的个人身份标识，它既是工作人员登录系统 时的身份验证依据，也是工作人员在进行商品操作时的经手人标记。尽管工作人员的姓名也可 以用做其身份标识，但不同的工作人员有可能会出现姓名重复，因此有必要为工作人员设置一 个专门的身份标识码。

（4）仓库以商品品种为基本单位进行管理，所有商品都要由计划部门按品种进行登记，涉 及商品编码、名称、类别、库存下限值等数据。其中，商品库存量初始值为零。

（5）仓库商品涉及入库、出库、 损这三种流通方式。凭采购部门填写的入库单进库，凭 销售部门填写的出库单出库，凭计划部门制定的 损计划 损。商品的任何流通都需要以流水 方式记录到商品流通表中，并对商品库存量进行更新。当商品出库、 损时，必须考虑到该商 品的当前库存量是否能够满足操作需要。出库、 损后，若商品库存量低于库存下限值，将自 动产生定货请求。

（6）可以按商品类别或品种进行商品库存情况和当月商品流通情况的查询。另外，仓库管 理系统需要自动在月底对商品流通数据进行盘查，包括：按月打印商品流通分类汇总 表，并 按月备份商品流通数据，然后将已备份的商品流通数据进行合计整理。

四、结构化分析建模

人在求解问题时，首要需要做的是理解问题，并且对问题理解得越透彻，则这个问题就越 容易解决。所谓模型，就是为了理解问题而对问题做的一种符 抽象。可以把模型看作为一种 思维工具，利用这种工具可以把问题规范地表示出来。 模型一般由一组图示符 和组织这些符 的规则组成。因此，分析时期的建模，就是针对 用户需求、系统需求等，采用图示方式进行直观描述。 软件问题往往是复杂的，而建模可以使问题简化。人的头脑每次只能处理一定数量的信息， 模型通过把系统分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。分析 时期建立软件模型的作用是多方面的，可以通过模型实现由用户需求向系统需求的过渡，并可 通过模型获得对系统需求的更具细节性的推论。实际上，分析时期产生的模型还可以被引用到 系统设计中去，作为设计前导。 为了开发复杂的软件系统，往往需要从不同角度去构造系统模型。例如，用于描述系统功能组织结构的层次模型，用于描述系统中数据加工流程的数据流模型，用于描述数据实体及其 关系的数据关系模型，用于描述系统行为过程的系统状态模型等。

1.功能层次模型

功能层次模型图使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系 统所具有的功能层级关系。 实际上，不仅可以使用层次图清晰地说明系统的功能组成关系，也可以使用功能层次图对 系统的功能关系进行调整，从而使系统的诸多功能得到更加合理地分配。

2.数据流模型

（1）数据流图特点

数据流模型由 DeMarco 于 1978 年提出，并随着他的结构化分析思想一起被广为流行。数据流图用于描述系统对数据的加工过程，其图形符 是一些具有抽象意义的逻辑符 。表 4-1 所列是数据流图的基本符 。 在软件定义时期，数据流图被用来描述系统的逻辑加工步骤。由于数据流图能够为有待开发的系统提供一种简洁的逻辑图形说明，能够方便用户对系统分析的理解，因此，它也被用做 开发者和用户之间的信息交流工具。

（2）数据流图的用途

可以依靠数据流图来实现从用户需求到系统需求的过渡。例如，可以将用户需求陈述中的 关键名词、动词提取出来，其中的名词可以作为数据流图中数据源、数据存储，而动词则可以 作为数据流图中的数据加工进程。

数据流图也能够方便系统物理模型与逻辑模型之间的转换，可以将 3.1.3 节中系统流程图 经过符 转换而获得系统的数据流图，例如图 3-3 的系统流程图，通过转换符 可以得出图 4-6 的数据流图。数据流图的这个特点表明，可以基于系统的基本物理框架而抽取它的逻辑模型。

（2）系统可以从“档案工资表”和“业绩工资表”这两个数据存储读取数据，然后通过“计算工资”的处理产生出“工资数据”数据流。这个数据流将被存入到“工资数据表”中。

（3）数据属性

数据属性是指在数据实体与数据关系上所具有的一些特征值。例如，教师的编 、姓名、 性别、职称、学历，是教师实体的属性；学生的学 、姓名、性别、专业、班级，是学生实体 的属性；课程的课 、课名、学分、计划课时量，是课程实体的属性。而学习的成绩，则是学 习关系的属性；讲授的实际课时量，则是讲授关系的属性。 在数据关系图中，数据实体用矩形表示，数据关系用菱形表示，数据属性用椭圆形表示。 其中，能够用来标记实体的关键属性则通过在属性名称上加下划线来表示。 图 4-11 是教师、学生、课程这三个实体之间存在的教学关系的数据关系图的描述。

4.系统状态模型

（1）状态图特点

状态图于 1987 年由 Harel 首先提出，其使用状态、事件等图形符 来描述系统的行为活 动，用以反映系统因某个外部事件的干预而由一个可能的状态转换到另一个状态。表 4-7 所列 为状态模型图中一些常用的图形符 及其描述。

（2）状态图应用举例

下面是一台全自动洗衣机的大致活动过程：

（1）在洗衣机接通电源以后，洗衣机将进入待命状态。

五、需求有效性验证

需求有效性验证是指对已经产生的需求结论所要进行的检查与评价，它是需求分析过程中 一个必不可少的环节。 需求分析是软件开发过程中一个非常关键的阶段。它是软件设计、实现的基础，同时也是用户对软件产品进行确认的基本依据。但是，需求分析过程中产生出来的结论难免存在问题。 例如，某项功能被遗漏了，某些功能之间发生了操作上的冲突，某些数据字节数不够大等。更 加重要的是，这些问题看起来或许并不显眼，但它所影响的是软件系统的整体构造。 实际情况往往是：需求分析中的小问题，假如是在后续的开发过程中或是在系统开发出来 并投入使用以后才被发现，就会导致代价巨大的返工。因此，在需求分析结果出来以后，需要 对其进行严格的有效性验证，由此尽早地发现需求文档草稿中存在的问题。

1.需求验证内容

在需求有效性验证过程中，为了确保软件需求的正确性，需要对需求文档草稿从有效性、 一致性、完整性、现实性等几个方面进行有效性验证。

（1）有效性验证

需求有效性验证用于确认每一项需求定义都能符合用户的实际需要。由于一个软件系统在 其运行过程中一般需要面对许多不同的用户，他们分别会有一些不同的个性需求意愿，因此， 有效性验证还包括对用户需求个性差异的协商。

（2） 一致性验证

一致性验证用于检查发现在需求文档中可能存在的需求冲突，例如，同一个功能出现了不 同的描述或存在相互矛盾的规程约束。

（3）完整性验证

完整性验证用于检查发现用户确实需要的，但没有写入需求文档中一些功能、约束等，以 使最终确定下来的需求文档能够更加完整的体现用户的需求意愿。

（4）现实性验证

现实性验证用于检查需求文档中所提出的功能、性能、安全等方面的需求，哪些还不能够 利用现有技术加以实现，以确保用户的一系列需求都能够具有现实意义，都能够最终实现。

（5）可检验性验证

可检验性验证用于判断需求文档中的各项需求是否有适合于用户操作的检测方法，可以使 得当系统开发完成并交付用户使用时，开发人员能设计出一组合适的检查方法来进行用户需求 检验，由此最大限度地保证用户的需求意愿能够得以实现。

2.需求验证方法

在进行需求有效性验证时，需要有一定的方法、工具提供支持。例如，需求评审、需求原 型评价和基于 CASE 工具的需求一致性分析等。

1. 需求评审

需求评审是传统的需求检查手段，采用专门评审小组的方式实施对需求文档的有效性评 价。其评审工作的开展需要有开发人员、用户的共同参与，他们一同检查文档中的不规范之处 和遗漏之处，一起讨论需求中存在的问题，并需要对一些需求分歧进行协商。 需求评审可以是非正式的也可以是正式的。其中，非正式评审一般是在正式评审之前进行 的准备性工作。非正式评审往往由项目负责人召集，由尽可能多的项目相关人员一起参与讨论， 然后就诸多需求结论是否正确给出一个基本判断。 在非正式评审结果产生以后，接着需要进行正式的需求评审。这时，软件开发机构需要拿 着经过非正式评审的需求文档访问用户，逐条地向各个用户解释需求含义。 在正式评审过程中，软件评审小组一般需要针对以下问题进行专门的检查与评价：

（1）一致性：需求文档对需求的描述是否有不一致的地方p>

（2）完整性：是否还有需要的但没有写到需求文档中的功能p>

（3）可检验性：需求描述是否可实际测试p>

（4）可读性：需求描述能否被用户读懂p>

（5）可跟踪性：是否清晰地记录了需求的出处p>

（6）可调节性：需求是可调节的吗需求出现变更，能否不对系统带来太大的影响p>

2. 需求原型评价

本章 4.3.3 节主要说明了如何使用需求原型完善用户的需求，但在这个过程中也包括对用 户需求的有效性验证。例如，可以根据需求文档为用户创建一个可以运行的系统模型，使用户 通过模型进行更加接近实际的系统需求检验。 需求原型主要用来提供给用户评价，以方便用户进行需求确认。为了使需求原型评价更加 有效，分析人员有必要从不同方面对用户评价作些引导。例如，为了启发用户的评价行为，可 以针对界面原型提出以下问题：

（1）界面所显示的功能是你所期望的吗p>

（2）有遗漏的功能吗p>

（3）有多余的功能吗p>

（4）你感觉界面复杂吗p>

需求原型评价还有利于发现用户的一些潜在需求。因此，在通过原型进行需求验证的时候， 除了需要从用户对原型的评价中确认用户的想法之外，还有必要观察用户对原型的操作，以此 发现用户所需要的而未能表达出来的需求。 用于需求评价的原型一般是抛弃型原型，当需求被确定之后，原型会被抛弃。这种原型能 够快速创建，容易修改，可以加快需求工程速度，降低需求成本。 需求原型也可以是进化型原型，特别是当开发者在需求原型上花费时间太多的时候，就自 然会产生出要把原型进化为目标系统的想法。若要使需求原型能够进化则一般需要满足以下两 个条件：

其一：原型创建工具和目标系统创建工具应该尽量一致，以方便从原型到目标系统的无缝 过渡。例如，使用 Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具作 为原型创建工具。

其二：原型创建时必须考虑到软件的健壮性、可靠性、可维护性，以及工作性能等技术性 要素，以保证原型质量标准和目标系统质量标准是一致的。 以上条件意味着，要使原型能够进化，开发者就要在原型创建时投入更多的时间、精力。 显然这就不得不增大原型创建费用。一般来讲，项目越小则原型进化的价值也就越大。

3. 基于 CASE 工具的需求一致性分析

如果需求文档中的需求元素是用结构化或形式化语言描述的，则可以使用需求 CASE 工具 来进行需求一致性分析。 需求 CASE 工具的工作流程如图 4-15 所示。其中，需求处理器用于处理使用形式化语言描 述的需求，并将产生的需求结果存入需求数据库中。以后，需求分析器可以使用方法规则或符 规则对需求数据库中的需求结果进行一致性检查，并能够根据检查结论产生出关于需求一致性的分析 告。

六、需求规格定义

? 软件用户：提出需求，按照需求规格说明书对软件系统进行验收。

? 项目管理人员：根据需求规格说明书制定项目详细开发计划，安排项目进程。

? 系统开发人员：以需求规格说明书为依据进行系统设计与实现。

? 系统测试人员：以需求规格说明书为依据进行系统有效性测试。

? 系统维护人员：通过需求规格说明书来帮助对系统功能与构造的认识。

小结:

1. 需求分析任务

（1）用户需求 用户需求是用户关于软件的一系列意图、想法的集中体现，是用户关于软件的外界特征的 规格表述。

（2）系统需求 系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅 读的，并将作为软件开发人员设计系统的起点与基本依据。主要包括：功能、数据、性能、安 全等诸多方面的需求问题。

2. 需求分析过程

需求分析是对软件系统的后期分析，需要进行的活动包括：分析用户需求、建立需求原型、 分析系统需求和进行需求验证等。

3. 用户需求获取

（1）用户调查是最基本的用户需求信息收集方法，比较常用的调查方法包括：访谈用户、 开座谈会、问卷调查、 跟班作业、收集用户资料。

（2）需求原型可被用来解决用户对软件系统在需求认识上的不确定性。一般情况下，开发 人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、 表或 数据查询结果。

4. 结构化分析建模

所谓模型，就是对问题所做的一种符 抽象。可以把模型看作为一种思维工具，利用这种 工具可以把问题规范地表示出来。主要的分析模型包括：

（1）功能层次模型。它使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来 表达系统所具有的功能层级关系。

（2）数据流模型。用于描述系统对数据的加工过程，其图形符 是一些具有抽象意义的逻 辑符 ，主要的图形符 包括：数据接口、数据流、数据存储和数据处理。可以依靠数据流图 来实现从用户需求到系统需求的过渡。结构化分析就是基于数据流的细化实现的，它是结构化 分析方法的关键。

（3）数据关系模型。也称为 ER 图，是应用最广泛的数据库建模工具。需要通过数据实体、 数据关系和数据属性这三类图形元素建立数据关系模型。

（4） 系统状态模型。通过系统的外部事件、内部状态为基本元素来描绘系统的工作流程， 这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。

5. 需求有效性验证

需求有效性验证是指对已经产生的需求结论所要进行的检查与评价。 一般需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。 比较常用的需求有效性验证方法与工具包括：需求评审、需求原型评价和基于 CASE 工具的需求 一致性分析。

6. 需求规格定义