系统需求定义概述

3.3.1　系统需求定义概述

1.系统级运行需求定义

在一个项目生命期的先期概念阶段，将定义和文档化与新系统能力相关联的业务（或任务）需求。一个任务是一项特殊定义的作业，它需要利用某个系统并以此支持一个或多个组织的职责。相应地，业务能力需求定义可认为是描述机构的运行作业或问题，而且这些问题通过现有能力或完全使用非技术性手段在目前是无法解决的。对于这种能力上的缺陷，MNS认为最好是建立新系统并作为解决业务能力缺陷的方案。一般说来，MNS文件将由客户机构写出，而且应当在非常高的级别上用系统用户的语言来表达。一旦拟就草案，必须由官方来正式确认MNS的有效性，而且获得资金支持，才能开始进一步的开发工作。信息安全工程小组应当知道，各个MNS在可用资源方面存在争议，并非所有的MNS都可得到批准和采用。

业务需求引导“可选择系统评审”（Alternate System Review，ASR）过程中开发的一些可选择系统概念。这些需求将进一步分解为正在审核中的可选择系统概念的高级系统需求。这些系统需求一般在用做选定系统的初始运行需求文件（Initial Operational Requirements Document，IORD）中用文档加以确认。在这个级别上，需求文档主要是有关功能和性能的文档，它们应该包含尽可能少的设计限制，而且应当避免将设计规范和实现规范作为一部分引入正式的运行需求集合中。

2.系统级需求分析和规范

系统级需求分析和规范是为了确定系统每个主要功能的安全需求和其他需求，并用无歧义的可试验术语说明这些需求。这些术语能表征所需能力、操作适用性必须达到的性能级别以及必须满足的任何限制。需求分析也包括评审全套需求，以保证其完全性，识别相互依赖性和解决任何冲突，保持所获得的特殊系统规范的恰当平衡。过度规范的需求一般可导致降低灵活性、对潜在可行解决方案的排斥性、增加复杂性、较高的开发和支持费用、较低的可靠性，较多的定制需求和产生其他不希望有的影响。太不规范的需求则可能使系统对其预期应用不可认证，或难以按合同对开发进行管理，缺少某些必要能力（由于规范中未具体指定或存在不希望有的属性），而导致使用受到约束和限制。

需求分析的结果将通过运行需求文档（Operational Requirements Document，ORD）进行文档化，并应该在“系统规范”中以更详细的方式文档化。“系统规范”必须以用户和广大技术专家可以理解的术语清楚、准确地阐述对系统的技术和业务需求，将需求分配给重要的功能领域，用文件形式确认设计限制，定义功能领域之间或之中（系统内部的和外部）的接口。“系统规范”常常附有一个SOW文档，它是通过合同采购所获得系统的法律性强制执行的技术需求文件。

多数的需求定义活动一旦通过适当的阶段评审，经必要的折中决策和风险分析并得到有关决策者的批准后，便被认为已经完成。在某些情况下，连续的需求分析可能需要对先前产生的顶级需求文件作些修正。这些修正的示例可能包括一些新需求，它们可以是由于环境变化，由于正式批准的折中决策，或由于通过系统工程过程获得的对高层运行需求的更好评估而产生的。系统工程决策数据库应当保存这些变化以及它们的基本原则，同时还应对改进的需求作仔细研究，以确定它们是否导致项目进度、费用、风险或其他参数的提高（或降低）；或它们是否引入冲突或同其他系统需求产生别的相互依赖性，应当避免随意变更。在所建议的需求变化被批准纳入系统“现行”需求集合之前，这些问题必须全部得到解决。

当需求集合是完整的并被批准后，“功能基线”也就确定了。“功能基线”由最初批准的文档组成。它描述系统的功能、性能、互操作性、接口需求，以及为了说明这些具体需求的作用所需的验证。在开发工作的后期，也要为“配置项目”（CI）定义“功能基线”。

3.系统需求定义和可跟踪性

“需求分析”被定义为对系统特有特性的确定。这种确定基于对客户需求、要求和目标、业务、人、产品和过程的预期使用环境、限制和效率等的分析。这种活动的输出应当是一组恰当的需求陈述，对用户是可理解并得到用户同意的；这组需求的陈述对广泛的阅读群是完整的、清晰的和准确的，而且是可以通过试验、论证、检查或分析（包括仿真模拟）进行验证的。需求可以是正面的，也可以是负面的，即是说它们不仅可以阐述用户期望系统要做的事，而且可以阐述用户期望系统不应显示的或不想要的行为或特性。恰当地选择和使用自动化工具，常常有助于分析者在整个系统工程过程中发现、确定、分解、管理和验证系统需求。

应当在需求验证可跟踪模板（Requirements Verification Traceability Matrix，RVTM）内保持整体层次性需求陈述的可跟踪性。对于大型需求集合，自动化工具用于跟踪数据的维护和验证；对于简单工程项目，人工维护RVTM就可满足要求。当需求被充分分解时，它们将被分配给功能和物理系统组件，包括正式控制的配置项和其他组件，同时也被分配给测试和评估规划，以建立工程的一致性。可跟踪分析必须保证每个原始的需求（或是对其“父系”需求进行了详细规范的“子系”需求集）被覆盖在系统验证（即测试、论证、检查、分析）的适当阶段和适当类型之中。满足了所有系统需求的系统，才被认为是有效的系统。需求的可跟踪性，尤其是对功能性和物理性设计的验证、测试程序和物理配置中的后期应用的需求可跟踪性，应当由与负责系统开发者/集成者无关的人员来认真地完成或至少是由他们进行审计。对较大型和较关键的项目，选择一个有经验的独立的系统验证和证实（IV&V）小组进行需求跟踪是合适的。

应当用一份完整的系统需求文件来考虑和定义几种类型的需求。一般说来，这些需求包括功能和性能需求、接口和互操作性需求、设计限制以及导出的需求。

（1）功能需求

表示必须完成的业务、行动或活动。

（2）性能需求

表示必须运行的业务或功能的程度，通常用质量（高低）、数量（多少）、覆盖范围（距离、范围）、及时性（怎样响应、响应的频度）或实现情况（可用性、平均无故障间隔时间）来度量。性能需求最初是利用用户需求、目标和/或需求陈述，通过需求分析和折中研究来定义的。性能需求要针对每个已识别客户（用户和供给商）的业务和每一项基本（系统工程）功能进行定义。

（3）接口需求

表示功能的、性能的、电气的、环境的、人员和物理的需求与限制，它们存在于两种或多种功能、系统元素、CI或系统之间的共同边界上。

（4）互操作性需求

表示规定系统、单元或人员所需要的能力，他们用这种能力向别的系统、单元或人员提供服务，或从别的系统、单元或人员处接受服务，以及用这些服务进行交流以达到有效协调运行。

（5）导出的需求

一般是在初级产品或过程方案合成期间和相关折中研究与验证期间被定义的典型特征。所谓导出，是将一些显然的东西变成一些成熟的系统概念，这些概念被反复地研究、定义和评估，因此常常不可能立即通过MNS或ORD对其源需求进行直接跟踪。但是，它们却是系统实现其预定功能所必不可少的。因此，一旦确定，就必须在系统的总体需求层次内用文档进行识别。

（6）设计限制

它是开发者/集成者在分配性能需求和/或合成系统元素时必须遵守的边界条件。这些设计限制作为先前决策的结果可以是外部强加的（如安全、环境），也可能是内部强加的。这些先前的决策限制了后继的设计选择。这种限制的示例包括：形式、装配、功能、接口、技术工艺、材料、标准化、费用和时间。