第一节 军事需求分析的主要内容

IEEE软件工程词汇表（1997年）为“需求”作了如下定义：1）用户解决问题或达到系统目标所需要的条件；2）为满足一个协约、标准、规格或其他正式制定的文档、系统或系统构件所需要满足和具有的条件或能力；3）对上述条件或能力的文档化描述。^[1]而军事信息系统的需求一般可以分为三个层次——作战需求、用户需求和系统需求。本质上，这种层次划分是从作战应用、系统用户以及系统开发者三个角度来阐述军事需求。从作战应用角度来说，军事需求是“为完成或支持作战功能所需要的任务、作战要素和信息流的描述”，它强调作战要素、任务、使命和活动，是一个高层次的研发目标。从系统用户角度来说，军事需求强调需要系统协助用户干什么事，它反映了用户特性以及系统支持用户完成任务而需要进行的军事活动。从系统开发者角度来说，军事需求定义了系统必须实现的系统功能，包括系统功能需求、性能需求、约束条件和其他非功能需求，是在开发过程中对系统的约束。

兵棋系统通常不会直接进入作战指挥控制的链路，更多的是训练或检验作用，因此，需要结合军事指挥信息系统需求分析的三个层次进行有针对性的探讨。同时，根据实践经验来看，在作战需求、用户需求和系统需求这三个层次之上，还需要加入一项更为全局和综合性的内容，以便参与兵棋系统研发的军事人员和技术人员可以更全面地把握其需求。因此，兵棋系统的军事需求分析可以分为确定兵棋研发目标、分析研究作战问题、构建用户运用场景和明确兵棋系统功能等四部分内容。

一、确定兵棋研发目标

显而易见，无论是手工兵棋还是计算机兵棋，抑或不同层级的兵棋，确立研发目标是兵棋设计的第一步，也是最重要的一步，研发目标定位是否准确，描述是否清晰，直接决定兵棋总体设计，甚至最终研发能否取得成功，以及设计与研发过程的顺利程度。但是这一步骤的有效落实，实际上往往非常困难。

影响兵棋项目研发目标定位的因素是多方面的，军队单位研发专业兵棋，主要的影响因素包括上级任务要求、研发队伍能力、可用资源支持等方面，其中上级任务要求是核心，研发队伍能力是关键，研发资源支持是重要条件。一个适当的研发目标是这些影响因素综合作用的结果，如果上级任务要求的条件不具备或不充分，则项目往往难以成功，因此，研发目标通常是任务和条件的平衡。不论是哪种性质的兵棋，确定其研发目标时均应综合考虑这些因素。

一是上级任务要求。这是军队单位与地方公司研发兵棋的最大区别所在。地方公司研发兵棋是一种商业行为，利润是他们优先考虑的因素，虽然对于某些实力雄厚的公司来说，可以承受短期的纯投入，但如果在可预见的时间内，看不到盈利的希望，通常不会再作无谓的投资。而军队单位研发兵棋，通常的表现形式是上级下达任务，是作为一项上级任务来完成的。上级任务的制约主要包括两个方面，任务的定位和时间。兵棋研发的总体目标或中长期目标，往往会受到军事斗争形势变化的影响，随着军事斗争军队任务的转变，做出相应的调整。而对于一款具体兵棋的研发任务，首先需要关注的是上级的基本定位，这是上级意图的直接体现，也是确定研发目标的基本遵循。同时，军事任务通常有很强的时效性，时效性是军事任务的重要因素，有时甚至会成为影响兵棋研发目标的首要因素。为了符合时效性的要求，必要时可能需要降低兵棋某些方面的要求，譬如减少一部分不甚重要的功能，或者是降低不太关键的性能指标。当然，也可能将任务要求进行分解，区分缓急，按照“急用先建”的基本思路，划分多个相对独立的阶段来完成最终的研发目标。

二是研发队伍能力。兵棋研发所涉及的专业领域繁多，技术难度大，对兵棋研发人员的能力素质提出了很高的要求。一支能力素质全面的兵棋研发队伍是兵棋研发成功的关键因素，中等规模以上和具有一定复杂程度的兵棋研发队伍中通常应包括以下四类专业人才：项目管理人员、军事专家、软件技术专家、技指合一人才。每一类别的人员多少取决于项目的规模和复杂程度，项目规模越大越复杂，则每一类别需要的人员越多，而人员达到一定规模后，还需进一步区分层次或专业。需要注意的是，这里所说的研发队伍是指参与兵棋项目研发的所有人员的集合，并不只是软件研发人员。通常，兵棋研发的任务受领方不管是军队科研院所，还是军事院校，或者是作战部队，都难以保证自身具备所需要的四类人才。因此，通常需要联合组建课题组，由其中某个单位担负总体职责，再从多个相关单位引入人才。中等规模以上和具有一定复杂程度的兵棋研发项目，课题组的人才优先顺序为项目管理人员、技指合一人才、军事专家、技术专家，总体单位自身拥有的人才越是顺序靠前，则兵棋研发通常就会越顺利。不过，无论是直接进入课题组的军事专家，还是临时外请的军事专家，在兵棋研发的整体性、全局性、关键性问题上应该始终处于主导地位。

三是研发资源支持。兵棋研发是创新性很强的复杂系统工程，需要整合各种资源形成合力，其中，除了必要的保密场地、设施设备之外，最为关键的还是经费支持。首先，在确定兵棋研发目标时，必须考虑能够得到的经费支持，综合考虑预定的经费支持力度和上级任务要求、研发队伍能力，确定兵棋的范围、复杂程度、功能完备性、性能要求、界面设计要求等。固然，在军队体系中，上级的任务要求通常有条件要完成，没有条件也要创造条件去完成。但是，兵棋研发作为复杂的创新活动，有其自身的规律和要求，不是简单的多加班、多花力气就能干出来的。当然，财力只是一个重要的外部保障条件，而不是决定性条件，它对研发目标的影响从属于前两个因素。需要注意的是，兵棋系统的需求在研发过程中会面临不断的变更，而需求变更则意味着要增加额外的工作量，额外的工作量就意味着需要增加资源的消耗。斯坦迪什咨询公司的研究表明：IT项目的实际成本是原始估算的189%。所以，在尽可能明确兵棋系统目标的基础上，兵棋项目的研发预算一定要留有余地，以便应付各种各样的变化。

有了目标定位后，还需要准确、清晰地描述出来，如果在研发初始对此重视不够，到兵棋进入试用阶段时，就会发现研发出来的兵棋只能用于某种特定的情况，即只是达到了用户的部分要求，而没有完全实现用户的期望。原因固然是多方面的，但往往最基本的原因之一就是最初的研发目标描述得不够准确、不够清晰。对研发目标的准确描述，可以结合具体的需求一起表述，也可以单独表述，但不管是以何种方式进行描述，某些关键性的问题或要求必须以准确的语言表达出来，使用户和所有参与研发的人员对此都没有疑义。例如，某款兵棋的目标定位是“满足想定训练”，这个目标描述就不够清晰和准确。满足哪个层次的想定训练，是战役级的，还是战术级的，还是战役战术通用？是院校用，还是部队用，还是两者都能用？是完全以同一身份并行作业，还是分组轮流作业？很显然，不同的选择会导致不同的兵棋需求。如果这些问题不搞清楚，则后续的兵棋研发，每个人都会按照他自己的想法去理解目标的含义，看似认识一致，实际上却相差甚远，从而导致研发过程协调任务量大大增加，更严重的是，最后研发成功的兵棋不能满足需要。

在兵棋的设计过程中，确立总体研发目标的最初过程需要各方面的密切合作：军事需求方、兵棋研发方、兵棋受训方（也就是最终的推演者）。一款兵棋的研发，所要做的不仅仅是确立兵棋研发的目标，还要制订一系列的途径（或者说是方法）来使兵棋满足这些预定目标。最初的研发目标往往只是意向性的，比较概略。这种情况下，兵棋研发方就需要帮助军事需求方（或者是兵棋的“立项决策者”）来分析、明确、分解兵棋的设计目标；而且兵棋研发方往往在行政上也隶属于军事需求方。这种情况下，兵棋研发方在某种程度上，需要协助兵棋军事需求方来确定具体的研发目标。在这一过程中，兵棋研发方，需要围绕着军事需求方的概略目标，具体确立兵棋推演需要得到哪些结果以及能够得到哪些结果。当然，确定兵棋的研发目标，也不是一步到位的，往往需要结合后面几方面的分析反复进行调整。但是最终只有兵棋的军事需求方、研发方，以及推演者代表，在兵棋的研发目标以及如何实现预定目标的方法途径上达成一致，兵棋才能够成功“立项”，并获得相应的经费支持，兵棋研发才能真正地展开。

二、分析研究作战问题

作战需求通常包括军事信息系统的作战任务和使命，以及完成这些作战任务所需进行的作战活动和具有的功能。军事信息系统的作战需求主要可以通过使命任务分解、作战样式分析以及指挥体制分析等形式进行描述。对于兵棋系统而言，虽然与作战的耦合不如指挥信息系统那么紧密，但研发目的仍然是作战使用，每一款兵棋都必然与一定的作战问题相关。在兵棋总体研发目标的分析确定中，通常已经基本界定了所针对的作战问题以及兵棋的训练（检验）目的，但仅仅是概括性的总体描述，包括作战样式、作战类型、指挥级别以及训练（检验）的层级、对象等。除此之外，还需要对兵棋所涉及的作战问题进行全面分析，通常包括以下几个方面：

一是作战目的。作战目的是作战问题分析的基础，主要用来约束兵棋推演的终点条件，也可叫胜利条件，即兵棋推演到什么程度可以结束。同时，它还影响兵棋的数据规模、评估指标、讲评依据等方面。由于兵棋是双方或多方的博弈，因此，对立的双方或多方的作战目的是对立的。通常需要先分析红方的作战目的，再依次分析蓝方及其他方的作战目的，最终综合形成多方胜利条件集合。比如说，一款登陆作战兵棋，其作战目的可以是“抢滩成功”、“建立登陆场”、“完成登陆作战”等，不同的作战目的显然在兵棋的规模、复杂程度、数据、评估等诸多方面有明显的差异。作战目的越小，则涉及的地幅小，需要的兵力少，涉及的行动少，推演的时间短，因此，兵棋的规模也小，复杂程度降低，讲评和评估也会相应简单。反之亦然。

二是作战编成。作战编成是兵棋推演双方可使用的作战力量的集合，主要用来确定兵棋要设计的双方棋子的数量、种类，以及双方的指挥层级。需要注意的是，作战编成的分解通常需要逐级进行，最终分解到兵棋设计的最基本要素——最小分辨率作战单位。随着兵棋系统总体设计的深入，其作战单位最小分辨率可能会进行调整，至少是部分调整，此时需要重新根据作战单位最小分辨率来分解作战编成。同时，不同的训练课题、不同的训练阶段可能会根据需要对作战编成提出不同的要求，比如在联合登陆作战训练兵棋中，为增加“抢滩登陆”这个训练问题的难度，推演组织者要求提供的航空兵火力支援力量少于典型条件，这时候通常不应该采用缩小空中作战编成的方式，而是通过限制推演者对航空兵的使用来实现。通俗的说，在兵棋分析和设计之初，必须要按照双方在推演中可能需要使用的最大作战编成来进行分析，为兵棋提供最大程度的适用性。

三是作战阶段。对抗双（多）方作战阶段的典型划分，对于总体理解作战行动，确定重点推演的阶段和行动具有重要意义。回合制推演的兵棋中，作战阶段的划分对于具体确定兵棋推演的回合长度也具有决定性意义。通常，一款兵棋只有一种回合长度，但如果涉及的作战阶段有若干个，不同的作战阶段作战行动的时间跨度相差很大，而且每个阶段的重要程度不一样时，可能需要设定多种回合长度。同样，以联合登陆作战兵棋为例，其涉及的作战阶段可能区分为装载上船、海上航渡、抢滩上陆、建立和巩固登陆场、岛上作战等，其中，装载上船、海上航渡阶段，行动类型相对简单，而且时间跨度较大，而抢滩上陆、建立巩固登陆场和岛上作战等阶段，所涉及的行动种类多、时间短、关系复杂，因此，可以把各个作战阶段的回合长度进行不同的区分，这样既可以突出作战重点，又可以保证内容的完整。当然，这还要和训练的要求结合起来考虑。

四是作战行动。作战行动分析是作战问题分析的核心，既用于确定兵棋的规则条目、详略程度等，又影响到各种推演指令的输入参数及交互方式，并会影响态势显示的信息内容及重点。以兵棋规则为例，作战行动的分析包括两层含义：一是作战行动的完整性。整个作战问题中包含了哪些作战行动，而且这些作战行动都要分解到以最小分辨率单位来执行的程度，兵棋规则要包含所有的作战类型。要描述什么样的作战行动，就需要有什么样的规则来支撑。二是作战行动的重要性。这个重要性不是指作战行动本身的重要性，而是作战行动相对于训练（检验）问题的重要性。比如说，在现代战争的联合登陆作战兵棋中，夺取“三权”无疑是至关重要的，但如果兵棋训练的重点是海上破障和抢滩登陆，那么夺取“三权”的行动虽然不可缺少，但可以简略描述之。由于训练目的不同，有些作战行动只需作简要的描述即可，有些作战行动需要进行尽可能详细的描述，在制定兵棋规则时，要根据需要来具体确定规则的详略程度。推演指令的输入参数及交互方式，态势显示的信息内容及重点，也同样需要根据作战行动分析的完整性和重要性来进行设计。作战行动的分析，还对该兵棋推进的时间分辨率——步长起到决定性影响，步长通常是根据所有作战行动中消耗的最短时间来确定。

另外，在作战问题分析中，可能会涉及兵棋通用性的问题。在目前的技术条件下，全通用型的兵棋是难以实现的。而且需要注意处理好通用性与专业性的矛盾，通用性越好的兵棋，专业性通常会越差。如果是某一作战层级的联合作战兵棋，可以参照我军“联合作战基本理论”中明确的作战样式、作战行动逐层进行分析，先针对最典型的作战样式，分析典型的作战阶段及可能的作战行动；再针对其他作战样式，分析典型的作战阶段及可能的作战行动；最终，综合归并形成总的作战行动分析，同一种作战行动需要包含不同作战样式、不同作战环境下所有的影响参数。

三、构建用户运用场景

用户需求是指在作战需求指导下，用户使用系统必须要完成的军事任务或活动，包括信息需求、运行或操作需求和其他要求、约束等。兵棋的军事需求分析中，可以参照用户需求分析的基本思路，来构建用户运用的场景。根据对兵棋系统运用流程的分析，对兵棋推演流程中的主要任务进行概要描述，并通过记录和整理形成结构化、形象化的场景描述。通过构建用户运用场景，既便于以兵棋推演为主线，系统梳理、整合军事人员脑海中比较零散的想法，总体形成直观的画面感；也便于军事人员与技术人员以形象化的场景描述作为媒介进行沟通，初始形成共同的语境。通常可按照总体运用场景和几个关键场景来分析构建。

一是总体运用场景。根据具体的推演方式，总体运用场景可分为集团式推演场景和编组式推演场景。而根据具体的推进方式，总体运用场景又可分为实时制推演场景和回合制推演场景。当前设计的兵棋系统，通常需要既支持集团式推演，也支持编组式推演。回合制推演，相对于实时制推演，其组织实施更为复杂。

集团式推演运用场景如图3.1所示，即各对抗方只有一个推演员或一个推演组，某一对抗方的各类角色，如各个军兵种、各个级别的指挥职能均由同一个推演组承担，推演组通过协同研讨的方式形成决策，并通过操作终端录入。想定作业通常适合于采用这种推演方式。

编组式推演运用场景如图3.2所示，即可以按照作战指挥层级及岗位将推演人员进行统一编组。各个推演人员根据不同的席位指派负责本方不同的推演单位，共同完成全部的推演对抗任务。战役战术演习训练通常采用这种推演方式。

而对于回合制推进的兵棋而言，还需要进一步在总体运用场景中体现其推演的控制过程。回合制编组推演的场景模拟如图3.3所示。

图3.1 集团式推演运用场景示意

图3.2 编组式推演运用场景示意

图3.3 回合制编组推演运用场景示意

二是推演准备场景。在兵棋推演总体场景下，需要对推演准备工作进行细化和梳理，形成推演准备场景，如图3.4所示。

图3.4 兵棋推演准备场景示意

不同的兵棋系统，其应用目的不同、运用对象、推演层级不同，系统推演准备的工作自然也可能存在差异。但是，兵棋系统推演准备的内容归根到底是录入各种数据，建立保存想定，并完成推演的初始化工作。数据主要包括地图数据、棋子模板数据、作战编成数据、规则数据和用户数据等，其中棋子（注记）模板数据是某种作战单位或地物类型在兵棋中的抽象，可以为想定作战编成的编辑提供模板。在此基础上，通常需要完成想定情况设置、推演席位设置、初始态势设置等初始化工作。

三是推演实施场景。在兵棋推演总体场景下，基于推演准备工作，对推演实施进行细化分析，即可形成推演实施场景，如图3.5所示。

图3.5 回合制推演实施场景示意

回合制推演的实施过程，除了需要像实时制推演一样进行导调控制之外，还需要逐个回合进行推进。推演的基本流程是在对抗各方分析态势、定下决心、输入指令并提交的基础上，对当前回合的行动进行裁决，视情进行导调干预后推进到下一回合推进，完成态势同步，再次进入下一回合的循环。在每一次回合推进时，系统需要将当前的裁决结果和动态干预后的信息同步到数据库中并同步发送给双方受训者。

四是推演总结场景。组织实施兵棋推演，通常都会有一定的具体目的，因此，在推演后需要进行总结。在总结中，除了态势回放之外，有时候还需要进行复盘推演。由此可以形成推演总结场景，如图3.6所示。

图3.6 推演总结场景示意

需要特别注意的是，无论是方案评估检验，还是演习训练或想定训练的兵棋推演，总结阶段都是必不可少的，最终收获的成果大多都是在推演总结阶段才涌现出来。只重视兵棋推演过程，忽视推演总结工作，那就是典型的“买椟还珠”。但是，在推演总结阶段，兵棋系统的功能并非是向各参演方提供现成的分析结论，而是提供有价值的工具手段和信息数据，各参演方在此基础之上进行定性分析，再得出结论；即使随着人工智能的发展，未来的兵棋系统直接为各参演方提供的分析结论也仅能作为参考。

四、明确兵棋系统需求

系统需求通常定义了军事信息系统为完成相应作战活动所必须实现的功能，使得用户在其支持下，能完成作战需求所赋予的军事活动和任务。系统需求的具体内容，除功能需求之外，通常还包括性能需求、约束条件和其他非功能需求等。而兵棋的系统需求，主要是在总体研发目标和作战问题分析的基础上，结合所构建的运用场景，进一步较为全面地分析兵棋的主要功能、性能要求、基本结构、交互方式、应用需求等。必要时，还需要针对系统数据接口、通信环境、配套设施要求等进行分析描述。

一是功能分解。兵棋的主要功能是兵棋最重要的需求。根据前面所确立的兵棋研发目标，先确定总体功能，即兵棋是为解决什么问题而建立。依据总体功能再进行细分，直到用户和开发队伍对功能的描述不再有疑义为止。通常可以按照推演流程，区分为推演准备、推演实施、推演总结等几个阶段进一步细分，也可以按照推演参与人员的职责，区分为推演准备人员、推演组织（导调）人员、推演参训（运用）人员等几种角色进行功能细分。在明确功能需求时，通常需要最终用户、富有经验的军事人员、老练的军事分析家、训练的组织者和技术总体的负责人共同合作，确保对功能的描述为各方所认可，且认识一致。这往往难以一蹴而就，需要多次反复，而且需求分析的负责人应具有良好的沟通和协调能力，才能很好地综合各方面的想法，最终形成具有约束力的功能需求。这也是后面建立兵棋系统功能架构的重要基础。

二是性能指标。与功能需求紧密相关的是兵棋的性能指标需求，大部分的功能如果没有一定的性能要求，就会变得如“鸡肋”一般。性能指标的确定，通常由用户或组训者与技术总体负责人进行磋商确定。单一性能指标的确定，并不是很困难的事情，但总的性能指标往往受到时间、精力、财力等条件的制约，需要根据这些条件对性能指标进行一定的取舍和权衡，牺牲一些性能上的要求，以获得最佳的效费比，或者满足一定的时间限制。这个问题需要兵棋研发的各参与方共同面对，也是最不易获得共识的方面。因此，技术总体负责人要对相关技术有较深入的了解，能够对各种技术的应用代价做出有说服力的评估，以便用户在提高费用以获得高性能，或者降低某些性能以降低费用之间做出合理的选择。对于军事训练或方案检验类的兵棋，要高度重视其稳定性和安全性，根据具体的运用条件来考虑各项性能指标，这也是后面建立兵棋系统技术架构的重要基础。

三是基本结构。对于一个现实的系统来说，系统的结构决定了系统的功能；反过来，设计一个系统，则是功能决定结构。同样，在兵棋设计中，必须从兵棋的功能出发，设计满足功能、性能需要的基本结构。如果功能不能满足需要，性能无法达到基本要求，那么，即使结构再精巧、技术再先进、界面再华美，它仍然不是一个好的系统，甚至是无用的系统。在已经完成功能分解的基础上，有关兵棋的基本架构重点需要明确三个方面的问题：一是兵棋典型的物理部署方式，它决定了兵棋外在的运用结构和特性，也是后面建立兵棋系统物理（部署）架构的重要基础；二是兵棋典型的用户角色区分，它决定了兵棋必须分解为哪些相对独立的子系统（模块），也是后面建立兵棋系统逻辑架构的重要基础；三是兵棋典型的物理应用环境，它主要决定了兵棋的稳定性、灵敏性等性能指标，也是后面建立兵棋系统技术架构，尤其是通信架构的重要基础。

四是交互方式。兵棋的交互方式对其可操作性、友好性具有关键性影响。由于用户（包括组训、受训者等）通常不可能对兵棋系统的内在机理和技术实现都有充分的了解，交互界面是用户了解和使用兵棋的主要媒介，所以界面对于一款兵棋的设计来说，处于十分重要的位置。如果将兵棋功能实现视为兵棋研发是否达标的标志，那么兵棋交互界面则决定着这款兵棋的生命力。但这一点又很容易被用户和研发者所忽视。用户忽视界面，是因为用户的注意力更多地集中于兵棋的功能和性能。而研发者有意无意地忽略界面，既有能力和水平方面的问题，也有研发条件制约的问题。软件行业有一句名言：“用100行代码的代价换取用户少点击一次鼠标，是值得的。”这句话，既道出了交互友好的重要性，也说明了交互的改进所消耗的资源通常是巨大的。最终，在交互这个问题上，需要兵棋用户和研发者形成一种平衡的共识。

五是应用需求。应用是兵棋研发的最终目标，因此，应用需求是兵棋系统所有需求的归结点。大部分的应用需求分别体现在前面所述的需求方面，例如，“能够根据想定需要迅速调换地图”，这是一个功能需求，也是一个应用需求；又如，“兵棋要能够展开不低于100个推演终端，同时容纳不少于15个对抗组并行进行推演”，这是一个性能需求，也是一个应用需求；与组训方式紧密联系的兵棋部署架构、与用户使用兵棋紧密相关的输入输出更是应用需求。因此，兵棋的军事需求本质上是一种应用需求，其他任何形式的需求都是为应用服务的。兵棋的应用需求描述，可能会和功能需求、性能需求等有关内容产生重复，目前还没有一种成熟的理论或规范来进行区分和描述，因此，确定兵棋的应用需求是一个反复征求意见、反复修改的过程。