军事信息系统的体系需求论证方法分析 *

高 斌 ，贺 庆

(中国电子科学研究院，北京100041)

0 引 言

随着军事信息系统的不断发展，系统之间的连接越来越复杂，交互越来越频繁和紧密，以往强调单系统、单平台的发展模式已经难以满足成体系、快速发展的需要。军事信息系统发展也逐步从强调功能的系统工程转变为强调能力的体系工程[1-2]。

经过多年对体系工程的研究[3-6]，体系工程概念已基本达成共识。体系工程是通过设计、开发和集成复杂大系统来完成特定任务，实现能力、使命或期望结果的理论方法和技术。从体系的研制构建过程来看，体系工程包括体系需求论证、架构设计、标准研制、综合集成和评估分析等过程。本文重点针对体系需求论证开展研究。

体系需求论证是指运用有效的方法与技术开发任务需求，确定体系建设能力目标，并用规范化文档形式进行描述、定义目标体系的所有外部特征的一项复杂的过程。与系统需求的相对确定性不同，体系需求论证是不断变化的，要根据外部环境变化和内部系统演化而持续迭代。

军事领域的体系需求论证，面向军事人员和战场，具有复杂性、易变性、对抗性等特征。美军经历从“基于威胁”向“基于能力”的转变，强调对己方军事作战能力的建设，以对抗不确定的未知威胁[7]；英军强调“精明需求”，重点关注对体系全寿命周期的需要，而不只是最初的采购需求[8]。

当前，开展需求论证工作依然面临需求获取难、描述不统一、验证手段缺乏等问题[9]。针对该问题，本文开展了体系需求论证理念、方法、论证过程等方面的研究，以实现从体系用户的任务需要到能力需求的转换。

1 体系需求论证理念

理念是对思想、观念的总结，是客观事物的本质反应。体系需求论证的理念对军队建设、兵力运用、战法设计等产生了深远影响。军事领域的体系需求论证理念主要有基于威胁、基于能力和基于效果等，在实践中经常综合多种理念开展需求论证。

1.1 基于威胁的需求分析

基于威胁的需求分析理念，以面临的现实安全威胁为驱动力，从假想敌可能发起的军事威胁为出发点，以打赢或阻止战争为目的，以一个或几个想定为背景，通过全面或局部力量间的对比分析，规划己方所需力量。该理念源于应对安全威胁的现实需要，有赖于安全威胁情况刺激，是情况刺激-反应模式，具有被动性、维持性等特点，适用于弱国面临安全威胁大的强国，或者是处于冷战状态下的大国等情况，但该理念在面对不确定性较大的对手时有一定的局限性。

1.2 基于能力的需求分析

基于能力的需求分析理念[10]，着眼期望塑造的能力，从不确定的多元威胁出发，在一定的经济条件约束下，对广泛挑战和多变环境所需要的军事作战能力进行分析，意在明确需要什么能力来对抗未知威胁，达到“以不变应多变”效果。该理念源于战略目标的牵引，是为了达到某种战略目标而谋求塑造能力的发展，是目标牵引-塑造模式，具有主动性、创新性等特点，适用于安全环境相对宽松的大国或者强国，尤其是崛起的大国，往往着眼于国家战略目标，追求与之相适应的军事发展战略。

1.3 基于效果的需求分析

基于效果的需求分析理念[11-12]，以获得期望的作战结果或对敌人造成期望作战效果为目标，通过协调、增效和累积等方式运用己方军事力量，达成敌方系统失能。这种理念以作战结果为导向，反向提出我方的作战运用方式，具有前瞻性、结果性、对抗性等特点，适用于对抗性较为激烈的战术行动中，在保障作战任务完成的前提下，通过最优使用我方作战力量，尽可能减少己方损失。

2 体系需求论证方法

体系需求论证包括需求获取、需求描述与建模、需求验证等阶段，每一个阶段都有相应的论证方法，通过综合运用不同方法，获取准确需求。

2.1 需求获取方法

需求获取是指通过各种途径收集和征询，得到建设新体系或者其他相关信息，以及任务清单和部分能力约束和要求的过程。随着体系规模的扩大，需求获取活动不再仅限于体系开发的初期阶段，它贯穿于整个体系开发的生命过程，常用方法有用户访谈法、问卷调查法和快速原型法等。

用户访谈法是需求论证人员与用户通过面对面交流与沟通的形式，进行事实发现和信息聚集，通常采取召开会议的形式进行座谈或调研等。问卷调查法是指就用户需求中的一些个性化的、待进一步明确的需求，通过发放问卷调查表的方式，达到彻底弄清楚项目需求的方法。采用本方法，可有效地获得大量不同岗位和专业人员的需求。快速原型法即把体系主要功能和接口快速开发制作为“原始样机”，以可视化的形势展现给用户，及时征求意见和建议，从而明确无误地确定用户需求。三种方法的优缺点及适用情况如表1所示，可根据实际情况综合使用三种方法。

表1 需求获取方法优缺点比较

2.2 需求描述与建模方法

需求描述与建模是通过规范化的方法和手段，建立体系需求模型，将已获取的需求准确地表现出来，便于达成一致的理解，减少二义性，提供直观、通用、标准的图表信息。已有大量文献[13-17]提出了多种需求描述与建模方法，满足描述建模需要。本文通过归纳，将需求描述建模方法总结为结构化描述法和面向对象描述法等。

结构化描述方法采用自顶向下分层解决的方法进行分析、描述和构造模型，按照特定功能划分为不同模块，通过对每个不同的模块进行描述，实现对体系的整体描述，一般应用IDEF图进行描述。该方法具有较严密的逻辑性及较高的精确性，能有效地将一个较复杂体系逐层分解为更小的体系或系统，其描述方法直观易懂，便于用户交流。但缺点是由于被分解成的模块体系结构依赖于上层的业务划分，对业务需求变化具有高度的敏感性，需求变更与追踪管理工作量很大。

面向对象描述方法继承面向对象的编程思想，通过使用对象和类两种描述方式，进而实现对用户需求的描述。一般用UML对需求进行描述。该方法优点是以自然方式描述客观世界，容易把握分析重点，系统功能和定义的操作实现简便，采用集成的思想提高了资源的可重用率。但缺点是开发的冗余较多，开发效率不高，实例化的对象依据客观边界划分，很难保证描述的准确性。

2.3 需求验证方法

需求验证用于确定论证成果在逻辑上是否一致，在性能和行为上是否可行，在效能上是否满足用户要求并达到最优，重点进行语法验证、一致性验证、逻辑合理性验证、完备性验证和规范性验证，一般使用需求评审法和需求模型执行方法[18-19]。

需求评审法通过组织成立由用户、研发人员、测试人员组成的评审小组，以会议的方式对成果进行仔细检查，解决需求文档中二义性，消除模糊性。该方法简单易行，但难以处理大型、复杂的需求文档，且由于审查过程涉及庞大的群体，花费时间长。

需求模型执行方法可分为形式化验证和逻辑性验证。形式化验证能解决需求文档中不一致和二义性；逻辑性验证往往依赖于可执行验证技术，将信息流、数据流等内容在用户描述并建立起来的需求模型中进行模拟运行，再通过从用户处得到的业务逻辑流程和规则来检验其模型的正确性。

3 体系需求论证组织过程

体系需求论证过程是一个反复不断迭代的过程，涉及多方的利益相关者：既涉及最终运用体系完成其业务职能的使用方，也涉及对体系建设过程进行规划监督的管理方，更有体系建设的研制方。因而，既要兼顾使用方对于体系的业务使用要求，又要兼顾技术发展所产生新的实现途径需要，将业务需求和技术需求结合起来，共同驱动需求论证过程。需求论证过程包括明确利益相关者的业务期望需求和定义研制方的技术实现需求。

3.1 业务期望需求

明确利益相关者的业务期望需求是体系工程的初始工作，确认谁是利益相关者，以及准备如何使用体系满足其业务职能需要。一般通过用例想定、设计参考使命任务和运用使用构想实现，主要流程包括确定利益相关者和明确利益相关者期望两大步骤，其典型过程如图1所示。

图1 明确利益相关者业务期望需求流程

确定利益相关者的明确利益相关者：待建设的体系工程可能来自组织或上级领导指示的要求，利益相关者就是那些受到本项使命任务结果影响或某种程度上对结果负有责任的组织或个人。利益相关者可以分为使用者和其他关注团体。其中，使用者是那些直接接受体系的人，或是直接受益人；其他关注团体通过提出宽泛约束对项目施加影响，在这些约束下满足使用者的需求，例如，装备管理组、规划顾问组、体系工程负责人等。

明确利益相关者的业务期望需求：需要明确利益相关者对指定项目的最终状态或目标产品是什么，或为项目目标增加约束范围来确定。这些约束范围可能包括(资源)消耗、交付时间、性能目标，及其他非定量约束。经过使命任务授权、使命任务目标、运行使用目标、成功准则、设计动因等一系列步骤，明确体系的目标，表达体系最终用户的需求，明确利益相关者期望、运行使用构想、辅助产品保障策略和效能指标等。

3.2 技术实现需求

定义研制方的技术实现需求是把利益相关者的期望转换成对体系问题的定义，再转换成经认定的技术需求，便于组织开展研制。以“需要”形式陈述的需求能够用于定义体系分解结构模型和相关附属体系的设计方案。需求定义对利益相关者需求、系统开发需求和底层产品/组件需求等三方面需求进行论证，逐渐形成层产品/组件需求文档。通过初步评估利益相关者期望，以理解待解决的技术问题并建立设计边界，流程如图2所示。

图2 技术需求定义流程

首先，确定设计方案必须遵从的约束条件或体系产品将使用的约束条件，辨识已经在设计控制下并且不能变更的那些单元，有助于缩小对潜在设计方案进行权衡分析的范围。其次，建立体系内各系统交互必需的物理接口和功能接口。随着对约束条件、物理/功能接口和功能/行为期望的全面理解，需求可通过建立性能标准做进一步定义。性能表述为需求的定量部分，用来表示每个产品被期望完成的功能。最后，需求应该被定义为可接受的“需求”阐述，每个阐述仅含一个“需要”的完整语句，最终形成技术需求和技术性能指标。

4 典型案例

为阐述上述所提出的方法和过程的有效性，选取外军岛屿夺控作战[20]为典型实例，从业务期望需求和技术实现需求等进行需求论证。

4.1 案例背景

岛屿夺控作战是在联合指挥所的统一指挥下，联合作战编队对侵占和据守岛屿之敌实施的进攻夺取与有效控制的作战。岛屿夺控作战具有作战进程衔接紧，保持控制权难度大和突击上岛限制多等特点，存在需求变化调整频繁、需求描述不够细致等问题，能够较为充分地体现出体系建设过程中面临的问题。

4.2 论证过程

聚焦外军岛屿夺控作战过程中对于信息系统的建设需要，开展体系需求论证，以期找准需求，并对其需求进行精准描述，牵引和规范后续研制建设，主要包括三个步骤。

(1)明确利益相关者

经过对外军岛屿夺控作战的前期资料收集后，项目组确定外军在执行该项作战任务过程中涉及的海区夺控、岛屿夺占和岛屿防御等阶段。每个阶段涉及的利益相关者也不尽相同。以海区夺控为例进行详细说明。为明确利益相关者，项目组假定目标用户，采用问卷调查法对目标用户进行调研，以逐步明确该项作战阶段中涉及到的关键用户，设计了用户需求说明书和问卷调查表，如图3所示。

一、被调研用户基本信息被调研单位名称被调研用户姓名职位联系电话邮编二、业务调研表业务部门名称职能序号职能名称12…职能序号1职能名称业务描述业务事项名称业务需要哪些数据相关业务标准规范业务关系检查协同分类协同业务名称业务协同关系描述涉及相关部门单位内跨部门协同业务跨单位协同业务三、业务发展方向表序号发展方向描述1(如:整体方向)2(如:工作重点如何加强)3(如:工作难点怎样解决、改善)

经多轮迭代修改，项目组逐渐明确海区夺控阶段中重点活动包括作战海区预警侦察、海上态势融合、威胁评估、作战决策、兵力接敌机动、火力打击和战果评估等作战活动，其主要涉及到的利益相关方包括联合作战指挥所、海军特遣舰队指挥所、水面舰艇突击群指挥所、空中突击群指挥所、掩护兵力群指挥所等，因此可以建立利益相关者列表，如表2所示。

表2 利益相关者列表

(2)明确利益相关者业务期望需求

采用资料收集法，确定利益相关方对于待开发信息系统的期望。经过对外军岛屿夺控作战的材料收集和整理，拟采用结构化的方法对其期望进行描述。利益相关者重点需要执行海区夺控、岛屿夺占和岛屿防御三个阶段，每个阶段在阶段目标和兵力运用上有所不同，但对于情报信息获取、实施指挥控制、作战要素协同运用和作战效果评估等四个方面有共性期望。由于篇幅有限，主要以作战要素协同运用期望中的武器协同运用期望为例进行结构化描述，如图4所示。

图4 武器协同运用结构化描述示例图

(3)定义研制方的技术实现需求

通过详细分析，明确开发系统之间的功能以及功能接口关系。

面向岛屿夺控作战对于军事信息系统的构建需求，应具备信息传输网络化、情报获取多元化、指挥决策智能化、武器控制数字化等特征，能够简化指挥流程，缩短指挥周期,提高作战指挥效能和整体作战的能力。综合考虑，提出信息融合处理、协同指挥决策、联合行动控制、通信保障、安全保密等功能要求，并用结构化方法描述各类功能之间的接口关系。

经过分析设计，形成《岛屿夺控作战需求规格说明》，并采用需求评审法，对设计成果的逻辑性和可行性进行检验。设计了评分标准，总分100分，如表3所示，并组织利益相关方、海上作战专家、架构设计专家、开发专家和测试评估专家等开展需求检验,进一步提高论证成果可行性，降低后期风险。

表3 需求评审评分标准

5 结束语

本文针对大型军事信息系统研制建设过程中存在的需求获取难、描述不统一、验证手段缺乏等问题，基于体系工程过程，研究了一般常用的需求论证的理论和方法，并从业务期望需求和技术实现需求两个方面创新提出了需求论证的组织过程，便于需求论证工作落地实施。此外，以外军岛屿夺控作战为典型案例，阐述了所提出需求论证方法和过程的有效性，进一步验证了上述方法和组织过程。下一步将针对需求论证过程中使用的常用工具展开研究，提高需求论证工作效率。