化几乎是不可避免的。对这一点可能会感到不可理解， 是最底层的原理。 分析人员在通过前面的分析之后， 建立了功能的层 为什么看起来完整而准确的需求会发生变化？事实上， 这种变化有时来源于分析中出现的盲点， 有时来源于系 统用户的环境发生了变化。 因此必须对需求变化的不可 避免性有清楚的认识， 采取必要的措施在开发过程中消 除这种变化的影响才是首先要考虑的。 需求变化的不可 避免性并不应该影响需求分析工作中所要求的精确和 次关系， 但功能之间的顺序关系、 物质能量关系等还没 有表现出来， 因此必须建立功能的数据结构图。功能的 数据结构图是根据功能／子功能的需要设计的，是依据 功能的分解和求解建立的。通过建立功能的数据结构 图， 可以明确从该系统功能所划分出的子功能及其间的
图 １ 需求分析方法论分类示意图
１．功能分解法 功能分解 ＝ 功能＋ 子功能＋ 功能接口 功能分解法 （ｆｕｎｃｔｉｏｎ ｄｅｃｏｍｐｏｓｉｔｉｏｎ ） 以系统需要 提供的功能为中心来组织系统。首先定义各种功能， 然 后把功能分解为子功能， 同时定义功能之间的接口。对 较大的子功能再进一步分解， 直到可对它给出明确的定 义。功能分解过程需要确定停止层， 以便控制功能分解 的层次和各个功能与方法的意义。 分解底层在用来解决 问题的原理域中确定， 因为一个功能如果能方便的由原 理实现，那就不必进行分解了。但是， 目前还没有系统的 理论方法去确定停止层。因此， 在分解过程中要充分利 用设计人员的知识：如果原理能与已有的部件对应， 或 设计者认为该原理的实际实现已很容易， 则这些原理就
详细。反过来， 需求分析工作越详细、 越精确， 需求的变 化所造成的影响就会越小。
三、 需求分析方法
在系统分析发展的同时， 需求分析也通过自身理论 的发展和对多年经验的总结，得出了几类分析方法， 当 中最有影响的几种方法有功能分解法、 数据流法 （又称 结构化分析方法） 、 信息建模法和８０ 后代后期兴起的面 向对象的分析方法， 其关系如图１ 所示。
２００６ ．７ "国防科技
!余滨 于久程 段采宇
与现实进行对比， 避免出现不切合实际的需求； ４． 充分借鉴国内外的先进方法理论， 借助这些理论 来指导需求分析工作。 因此， 军事需求领域的需求分析必须针对军事领域 的特殊情况， 合理运用需求分析方法， 从获取到的需求 中分析出问题的本质， 这样才能得到最终完整的一致需 求。
３０ 国防科技!２００６
．７
!"#$$%&’()*+,-./0-,/1+
需求工程
ＲＥＱＵＩＲＥＭＥＮＴ
ＥＮ ＧＩＮＥＥＲＩＮＧ
顺序关系， 而且还明确了功能之间的物质能量信息流的 接口， 为各个功能模块的划分提供支持。 从系统所需要的功能出发， 构造的系统能够直接地 反映用户的需求， 所以工作很容易开始。 另一方面， 由于 功能分解法在建模过程中没有考虑现实资源的约束， 造 成了功能分解的随意性， 并且功能结构与现实问题结构 常常难以对应， 所以随着需求工程的深入， 其难度逐渐 增大。 ２．数据流法 ＋ 数据存储＋ 数据流法 ＝ 数据数＋ 数据处理 （加工） 端点＋ 处理说明＋ 数据字典 数据流法 （ｄａｔａ ｆｌｏｗ ａｐｐｒｏａｃｈ ） ， 又称为结构化分 析方法。在介绍数据流法之前， 有一个预备概念是控制 流图 （ｃｏｎｔｒｏｌ ｆｌｏｗ ｇｒａｐｈ 简写为ＣＦＧ ） ， 简称就是流图。 ＣＦＧ 典型的应用是代表类似过程的片断。 典型的流图结 点是基本块 （总是顺序执行的片断） ， 流图的边代表基 本块之间可能存在的控制流， 其中的一个结点被标明为 开始点。 问题域被映射为由数据流、 加工以及文件、 端点等 成分构成的数据流图 （ＤＦＤ） ， 并用处理说明和数据字 典对数据流和加工进行详细说明。所以， 数据流法的基 本策略就是跳跃数据流， 即研究问题域中数据如何流动 以及在各个环节上进行何种处理， 从而发现数据流和加 工 （ｂｕｂｂｌｅ ） 。 数据流法有一些严格的原则， 例如， 数据流从原点 开始出现到终点结束， 在其它成分 （加工和文件） 之间 只能被传输、 转换和存储， 而不允许消失和凭空产生。 这 种严格性可以避免许多错误和疏漏。 数据流法也运用了 逐步求精的原则， 一个加工可以通过细化而分解成一个 下层的数据流图。此外， 该方法还强调开发过程是由问 题到解答、 由总体到局部、 由一般到具体。 数据流法是结构化需求分析的方法， 大多使用自项 向下、 逐层分解的系统分析方法来定义系统的需求。自 顶向下方法提供了从高层次（问题定义 ）到低层次 （编程 实现 ）的分层分解的决策策略和决策方式， 并在具体的 开发方法中给出相应的描述工具和设计步骤。 自顶向下 方法体现了逐步求精和信息集成的原则。 在结构化分析 的基础上， 可以得出系统的规格说明， 由此建立系统的 一个自顶向下的任务分析模型。 规格说明描述了系统的 需求，是联系系统需求分析与系统设计之间的重要桥 梁。 ３．信息建模法 ＋ 属性＋ 关系＋ 父类型／ 信息建模法 ＝ 实体 （对象） ＋ 子类型 关联对象
!"#$$%&’()*+,-./0-,/1+Fra bibliotek需求工程
ＲＥＱＵＩＲＥＭＥＮＴ
ＥＮ ＧＩＮＥＥＲＩＮＧ
军事需求工程技术
之需求分析
一、 概述
在军事需求的过程中，当所有需求被确定下来后， 要对它们进行反复的论证和分析。 需求分析的目的就是 构筑系统的总体框架，明确哪些需求是可行及可接受 的， 并构建整个系统的概念模型， 最终建立一套双方都 同意的、 完整的、 一致的需求。 需求分析阶段的核心任务 就是确定并完善需求。 在需求获取阶段所获得的大量需 求往往是不系统、 不完整的， 甚至个别需求是错误的、 不 必要的， 只有通过提炼、 分析和仔细审查需求， 彼此沟 通， 采用适当的表现形式， 比如绘制业务目标关联图、 绘 制功能结构示意图、 编制数据字典、 编写用户实例等， 明 确需求含义并找出存在错误、 遗漏或不足的地方， 尤其 是要采用特定符号来标识需求的优先级。 在军事需求工程领域， 要进行的需求分析主要有作 战需求分析， 系统需求分析， 技术需求分析等几个方面。 在需求过程的全阶段，需求分析与需求抽取是不可分 割、 互相交错的两个过程。 通过需求抽取， 会从中发现需 求， 然后进行需求分析。由于军事系统自身的建设周期 长， 系统结构复杂， 涉及的因素多等其他原因， 所以要对 军事人员提出的需求进行认真的需求分析， 借助需求分 析来建立正确的需求。 借鉴以往的需求分析经验， 为了更好的在军事需求 工程中进行需求分析， 就要做到以下几点： １． 正确使用现有的分析方法， 避免需求过程中出现 二义性、 不完整性和不一致性； ２． 利用足够抽象的需求分析模型， 来对抽取的问题 进行本质方面的深入分析； ３．因为军事需求随着时间的推移， 本身会发生变化， 所以使用的分析方法还应该具有动态性， 这样能更好的 需求分析的第一步是对所获取的需求进行过滤。并 不是所有的用户需求都可以被满足， 原因可能有技术上 的、 实施费用上的、 系统兼容性要求上的， 等等。技术人 员必须了解所有需求的相关情况及其影响， 对这些因素 进行提前考虑和估算。 对于那些被排除在最终系统之外 的需求， 技术人员有义务帮助用户分析为什么他们提出 的要求是不合理的。 这样做既是为了保证将来整个系统 的完整性、 有效性不受影响， 也是为了保证在随即进行 的系统开发进程中不会因此而产生被动的设计变更。 对 于系统可以接受的需求条目， 需求工程师在此时应当能 够掌握每个需求的验证方法。 最终确认的需求必须具有 “充要性” ， 即： 既是必须需要的， 又是充分需要的。 不应 当有遗漏， 也不应当有冗余， 所有需求条目都应当是清 晰而准确的， 形成有效的文档。由于此文档最终必须经 由用户确认，因此文档在描述上要保持在应用的层次 上， 以便军事人员从他们的角度来理解系统的情况。 分析工作的第二步是构建整个系统的基本框架。为 了更好的进行需求分析， 可以建立系统的概念模型来理 解系统各部分之间的逻辑关系、 运行上下文、 运行环境 以及内部实体之间的控制关系等相对复杂的内容。 但要 注意分析必须在系统所有可能出现的限制条件之内进
二、 需求分析的基本过程
２９
需求工程 !"#$$%&’()*+,-./0-,/1+
ＲＥＱＵＩＲＥＭＥＮＴ ＥＮ ＧＩＮＥＥＲＩＮＧ
行， 包括作战环境下的、 用户组织结构上的、 系统运行环 境上的所有限制。经过严谨的分析， 将系统分解成一系 列子系统或者组件， 系统功能被分配给这些子系统和组 件。分解工作有时被认为是属于军事系统的分析与设 计， 分解设计必须非常谨慎的进行， 因为一旦系统的结 构被确定下来， 改变所带来的花费是很大的。系统内部 各部件结构之间的配合很容易影响系统的外部表现。 常 用的方法是在系统各部分逻辑关系的基础上建立系统 的初步模型， 然后逐步增加系统限制等外部条件来完善 模型。 对于每一个阶段性的模型， 在其建立完成后， 应当 根据掌握的情况对该模型进一步讨论和论证， 决定 是否要对模型进行修改。 这项工作应当是循环进行 的， 直至满意为止。 在实际工作中， 除非是很小的系 统， 此时通常很难对系统所有子系统和部件做出非 常精确的设计。从循环深入的观点看， 每个组件所 承担的需求任务又是一个复杂的系统需求， 有时需 要进行反复的循环深入分析以增加细节， 还可能需 要补充学习系统所在的知识域内的知识以增进对 于需求描述的理解和解释。 所有最终的技术实现细 节都是高层应用需求不断深入和演化的结果。 分析的第三步工作是需求的优化和系统构架 的初步形成。 这一步工作是在第二步的基础上进行 的， 工作的内容是对系统的基本结构作最后的优化 并形成完整的系统结构。 可以将其看作军事系统的分析 与设计工作的前一步。这两个工作是衔接的， 一般没有 明确的边界。 但是， 需要把握的是， 需求分析中不会对系 统做很深的分解； 对于分解过程， 应当细致地进行记录。 记录结果保留以方便对所有可能出现的系统需求变更 进行有效评估。这个过程叫做 “需求跟踪” 。 在整个需求分析的三个步骤中要注意， 分析、 设计 工作完成之前就进行开发是一种不推荐的做法， 几乎所 有这样做的工程中都会在后期开发中出现需求的补充 和修订。 但是， 这样做也不是绝对不允许的， 在整个工程 的压力下， 可以对已经分析透彻并且具有较强独立性的 子系统或功能部件进行先期开发， 但必须对其给后面工 作可能造成的影响有充分的估计和理解。 这里还要提到的一点是， 需求在设计完成后发生变