系统需求是指在系统层面上的所有需求，这些需求描述整个系统应履行的功能，以满足利益攸关方的需要和需求，并以文字语句、视图和非功能需求的适当组合来表达；后者表示安全性、安全性、可靠性等级别，这将是必要的。系统需求在系统工程中扮演重要角色，因为：

　　v 形成系统架构和设计活动的基础。

　　v 构成系统集成和验证活动的基础。

　　v 作为验证和利益攸关方验收的参考。

　　v 在整个项目过程中提供各种技术人员之间的沟通方式。

　　利益攸关方需求的获取从概念定义开始，并将通过访谈和任务分析进行初步开发。在系统定义时详细考虑系统需求。在实现了两者之间的一致性之前，任何一个都不能被认为是完整的，正如追溯性所证明的那样，可能需要大量的迭代。

　　需求的定义和目的

　　需求是一种对产品或过程的操作、功能或设计特征或约束进行明确的、可测试的、可测量的和产品或过程可接受性所必需的声明。

　　为了避免与需求相关的大量术语的混淆，考虑以下分类：

　　过程角色或状态：需求在定义过程中所扮演的角色；例如，它在系统块中的位置（如翻译、导出、满足）或它的一致状态（如提议、批准、取消）。

　　抽象层次：需求在定义过程中所处的层次；例如，利益攸关方需求，系统需求，系统要素需求。

　　需求类型：需求本身的性质；例如，功能、性能、约束等。

　　任何单一需求都可能同时处于特定的状态、特定的抽象级别和特定的类型。控制系统需求与利益攸关方需求和逻辑架构的关系

　　澄清一组利益攸关方需求，并将其从需求陈述转换为面向工程的语言，以支持作为系统需求分析基础所需的适当的架构定义、设计和验证活动。

　　系统需求是基于识别和集成与性能和其他质量度量相关的任何解决方案系统所需的功能，并为评估候选解决方案和验证已完成的系统提供基础。系统需求用对架构和设计有用的技术语言表达：明确、一致、连贯、详尽和可验证。当然，必须与利益攸关方密切协调，以确保翻译的准确性和可追溯性。这就产生了一组系统功能和需求，这些功能和需求规定了可测量的特征，可以构成系统实现的基础。

　　逻辑架构定义了系统边界和功能，从中可以导出更详细的系统需求。此过程的起点可能是从利益攸关方需求中识别功能性需求，并使用它来启动架构定义，或者从高级功能架构视图开始，并将其作为构建系统需求的基础。所采取的确切方法通常取决于系统是一个已经理解的产品或服务的进化演进，还是一个新的和前所未有的解决方案（见集成可能的解决方案）。然而，当过程开始时，利益攸关方需求、系统需求和逻辑架构都是完整的，相互一致的，并且在系统生命周期模型的适当点一起进行评估是很重要的。

　　架构和设计期间系统需求的可追溯性和分配

　　需求可追溯性提供了跟踪信息的能力，从利益攸关方需求的起点，到最高层次的需求和系统层次结构所有级别上的其他系统定义要素（参见应用生命周期过程）。当在工程改进或变更请求的情况下执行影响分析时，可追溯性还用于提供对作为输入的变更程度的理解。

　　在架构定义和设计期间，需求从一个层次分配到系统层次结构的较低层次可以使用多种方法来完成——如表1所示。

　　系统需求的赋值类型

　　描述

　　直接赋值

　　来自较高级别的系统需求直接分配给较低级别的系统或系统要素（例如用于油漆产品可见部分的颜色）。

　　间接分配（简单分解）

　　系统需求分布在多个系统或系统元件上，一个更复杂的分配计算的总和等于具有足够余量或容差的更高水平的要求（例如质量要求、功率分配、可靠性分配等）。必须维护每个任务的文档化和配置管理的“任务预算”。

　　间接分配（建模和分解）

　　使用分析或数学建模技术，将系统需求分布到多个系统或系统要素中。由此产生的设计参数被分配到适当的系统或系统要素（有适当的边距）。例如，在分析雷达探测需求的情况下，输出功率、波束大小、频率等低电平参数将分配给适当的硬件和软件要素。同样，必须对分析（或模型）进行文档化和配置管理。

　　派生需求（来自设计）

　　这样的系统需求是在设计活动中开发的，是设计团队决策的结果，而不是利益攸关方团体的结果。这些需求可能包括商用现货（COTS）项目的使用、库存中的现有系统或系统要素、通用组件，以及类似的设计决策，以便为客户产生一个“最具价值”的解决方案。因此，这些派生的需求可能不会直接追溯到利益攸关方的需求，但是它们不会与利益攸关方的需求或约束冲突。

　　系统需求分类

　　根据需求定义方法和/或所应用的架构和设计方法，可以对系统需求进行几种分类。（ISO 2011）提供了一个分类，其总结见表2（其他分类见参考资料）。

　　系统需求类型

　　描述

　　功能需求

　　定性地描述系统功能或在运行中要执行的任务。

　　性能需求

　　从数量上定义一个功能或任务的执行程度、执行的好坏以及执行的条件（例如速率、速度）。这些是系统性能的定量要求，可以单独验证。注意，可能有多个性能需求与单个功能、功能需求或任务相关联。

　　可用性需求

　　定义系统使用的质量（如可测量的有效性、效率和满意标准）。

　　接口需求

　　定义系统如何需要与外部系统（外部接口）交互或交换物质、能量或信息，或者系统内部的系统要素，包括人的要素，如何相互交互（内部接口）。接口需求包括外部系统或支持交互或交换的内部系统要素的物理连接（物理接口）。

　　运营性需求

　　定义系统运行或存在所需的操作条件或属性。这种类型的需求包括：人为因素、人体工程学、可用性、可维护性、可靠性和安全性。

　　模式和/或状态需求

　　定义正在使用的系统的各种操作模式和执行模式转换的事件。

　　适应性的需求

　　定义系统生命周期中潜在的扩展、增长或可伸缩性。

　　物理约束

　　定义适用于组成超系统（SoS）要素的重量、体积和尺寸的约束。

　　设计约束

　　通过设置不可移动的边界和限制（例如，系统应包含遗留的或提供的系统要素，或某些数据应在联机中维护）来定义解决方案设计者可用的选项的限制

　　物流需求

　　确定系统持续使用所需的后勤条件。这些需要包括维护（提供设施、支持水平、支持人员、备件、培训、技术文件等）、包装、搬运、运输。

　　环境条件

　　定义系统在其不同的操作模式下将会遇到的环境条件。这应针对自然环境（如风、雨、温度、动物群、盐、灰尘、辐射等）、诱发和/或自诱发的环境影响（如运动、冲击、噪音、电磁、热等），以及对社会环境的威胁（如法律、政治、经济、社会、商业等）。

　　政策和法规

　　定义可能影响系统运行或绩效的相关和适用的组织政策或法规要求（如劳工政策、向法规机构的报告、健康或安全标准等）。

　　成本和进度限制

　　例如，定义系统单个范例的成本，第一个范例的预期交付日期，等等。