下载掌阅APP，畅读海量书库
立即打开
技术需求开发流程是把利益相关者的期望转换成对问题的定义，然后转换成经过校验的技术需求完备集，这些需求以“需要能……”的形式陈述，这种陈述方式可用于产品分解结构模型开发和相关配套产品的设计方案开发。技术需求开发流程是一个递归和反复迭代过程，在该流程中开发利益相关者的需求、产品需求和低层级产品/组件的需求。需求应该能够描述所有的输入和输出，以及描述输入/输出之间的必要关联关系。这些关系包括各种约束条件，系统与运行使用人员、维护人员之间的交互，以及系统与其他系统之间的交互。需求文档用于组织在客户、利益相关者和技术团体之间与需求相关的沟通。
技术需求开发流程的活动应用于定义系统所有层级的技术需求，形成包括从工程层、项目层、系统层到底层产品/组件的需求文档。
注： 设计团队绝对不能完全依赖接收到的需求进行系统设计和建造，这一点极其重要。与利益相关者不断地进行反复交流是确保相互之间对每一项需求取得一致理解的基础。否则，设计人员可能会因为对需求的理解差异而承担造成误解的风险，或设计出非所期望的解决方案。与利益相关者的反复交流是项目确认活动中极为重要的部分。设计团队应不断确认所开发的是正确的产品，确认能够得到正确的结果。
图4.2-1所示是技术需求开发流程的典型流程框图，图中给出了实施技术需求开发流程需要考虑的典型输入、输出和活动。
图4.2-1 技术需求开发流程的典型流程框图
技术需求开发流程中需要的典型输入应该包括如下内容：
（1）设定控制基线的利益相关者期望：指位于产品结构本层级的已达成共识的利益相关者期望（如需要、目的、目标、前提假设、约束条件、外部接口）的集合。
（2）设定控制基线的运行使用构想：描述系统在寿命周期的各阶段如何运行使用，以满足利益相关者的期望。它从运行使用的视角刻画系统特征，有助于加深理解系统的目的、目标和约束条件。其中包括适合于项目的运行使用场景、运行使用用例和使命任务设计参考。运行使用构想的形式有文档、图形、视频、模型和仿真。
（3）设定控制基线的配套产品保障策略：描述在利益相关者期望开发流程中明确的配套产品，以及如何满足目标产品开发、试验、生产、运行及处置的需要。配套产品保障策略还包括对目标产品如何在寿命周期全过程得到保障进行的描述。
（4）效能指标：效能指标在利益相关者期望开发流程中确定，作为利益相关者认为必须满足的度量指标，应以此为依据认定项目的成功，即满足成功判定准则。
其他在决定技术需求时可能有用的输入包括：
人因/系统功能分配：描述系统硬件和软件与所有人员的交互关系，以及描述这些交互的支撑结构。当运行使用人员成为整个系统的关键部件时，在所参与的系统中人因的作用和责任应当被清晰地理解。此类输入应当包括使命任务所需的所有人因/系统交互关系，如系统组装、地面操作、后勤保障、飞行中维修和地面维修及飞行中执行任务等。
1.定义约束条件、功能期望和行为期望
首先对顶层需求和期望进行评估，以理解待要解决的技术问题（问题的范围），并确立设计方案的边界。典型情况下应进行如下活动来确立边界：
●设计方案开发需要遵从的约束条件，这些约束条件限制了系统将如何运行使用。通常在进行权衡分析时，约束条件是不能改变的。
●辨识出已经在设计流程控制下并且不能再变更的那些要素。这有助于在寻求潜在设计方案时缩小进行权衡分析的范围。
●辨识系统需要进行交互的外部系统和配套系统，并构建物理接口和功能接口（如机械的、电子的、热学的、人因的接口等）。
●针对在运行使用构想中明确的系统预期使用范围，定义功能期望和行为期望。运行使用构想描述系统如何运行使用和可能的使用用例场景。
2.确定需求
随着对约束条件、物理接口/功能接口、功能期望/行为期望的全面理解，需求可以通过建立性能指标和其他技术标准做进一步明确。所期望的性能指标表述为需求的定量部分，用来表示每个产品需要将功能完成到的程度。
注： 需求也许来自未被重视的利益相关者，这些需求可能并不直接支持当前的使命任务及其目标，但却可以为获得有益于NASA或国家的额外利益与信息提供机会。在流程的早期，系统工程师应当能够帮助确定系统的潜在应用领域，收集与核心使命任务不直接相关的独特信息。通常情况下，外围组织在流程接近结束之前并不能意识到系统的目标与能力。
3.以可接受的陈述方式定义需求
最后，需求应该被定义为可接受的以“需要……”形式陈述的语句。每条陈述仅含一个“需要……”形式的语句，且是完整语句。需求定义的客观依据同样应当明晰，确保对需求的来源和背景的理解。应当明确关键主导性需求，这是在系统实现过程中能够对费用和进度产生重大影响的需求。关键主导性需求具有优先权和首要性。充分了解关键主导性需求对于系统设计的影响可以更好地管理需求。
关于如何写好需求和检验清单的指南参见本手册附录C，关于如何进行需求确认参见本手册附录E。良好可读的需求文档能够为利益相关者和技术团队双方带来特定的益处，如表4.2-1所示。
表4.2-1 良好可读的需求能带来的益处
4.技术需求的确认
需求定义的一项重要工作是，根据利益相关者的期望、使命任务目标与约束条件、运行使用构想、使命任务成功判定准则，对需求进行确认。需求的确认主要包括如下6个步骤。
（1）需求的书写是否正确无误。确认并更正以“需要……”形式陈述需求时的格式错误和编辑错误。
（2）需求在技术层面上是否正确。在将需求提交给所有的利益相关者评审之前，技术团队内部训练有素的评审人员要尽可能多地辨识出并去除技术性错误。评审人员应当对需求陈述做如下检查：①需求对于设定控制基线的利益相关者期望是否具有双向可追溯性；②形成需求的前提假设是否合理；③需求是否对产品的设计方案和实施方案起到重要作用并与之保持一致，使之满足产品当前寿命周期阶段的成功评定准则。
（3）需求是否令利益相关者满意。所有利益相关者团体应当能识别出需求缺陷并将其去除。
（4）需求是否可行。所有的需求都应当在技术上有意义，且有可能实现。
（5）需求是否能够得到验证。所有的需求都应当以同一风格陈述且含有充足的信息，如此方有可能在产品实现之后对需求进行验证。
（6）需求是否存在冗余或过分描述。所有的需求都应当是独一无二的（不会与其他需求有冗余），而且有必要与系统的功能、性能和行为相匹配。
需求确认的结果常常是决定项目能否推进到逻辑分解流程和方案设计流程的关键因素。项目团队应该做好以下准备工作：（1）证明项目需求是完备的和可理解的；（2）证明评价标准与需求是一致的，并且与运行使用构想和后勤保障构想是一致的；（3）证实需求和效能指标与利益相关者的需要一致；（4）证明运行使用构想及所构想的系统架构可以支撑使命任务需要、目的、目标、前提假设、指导方针和约束条件；（5）证明管理需求变更的流程已经建立并在项目的知识库中记录归档，且已经与利益相关者交流。
5.定义系统性能指标和技术性能指标
性能指标（MOP）定义为当系统在预设的环境中部署和运行使用时，应当展现出的性能特征。性能指标可以从效能指标中推出，但是从供应商的角度看，它更侧重于技术方面。通常需要多个定量的和可度量的性能指标来满足同样是定量的效能指标。当涉及系统验证和验收时，性能指标反映那些被认为有利于达成效能指标的系统特征。
技术性能指标（TPM）定义为系统的物理特征和功能特征，这些特征与那些被认为是使命任务成功中关键的性能指标相关，技术性能指标便是依据这些性能指标设定的。在系统实现过程中，通过将系统参数的实际值（或最佳估计值）与早期对当前时刻的预计值做比较，对技术性能指标进行监控，同时还可以确定未来时刻的设计值。技术性能指标用于认定系统的开发进展，确定那些可能危及满足关键系统需求或使项目面临费用和进度风险的缺陷。
关于系统性能指标和技术性能指标、它们相互之间的作用关系及其与效能指标的关系，更多的信息及相应示例，可参见本手册的6.7.2.6.2节。
6.确立技术需求控制基线
一旦明确系统技术需求，经过确认符合标准（清晰、正确、完整、可达）需求，而且得到客户和关键利益相关者的认可，便可设定它们的控制基线并将控制基线置于技术状态管理之下。通常需要组织系统需求评审，对所有需要做出的变更听取评审意见，获得对系统需求集的一致认可，从而便设定了系统技术需求的控制基线。关于系统需求评审的更多信息可参见6.7节。
7.获取工作产品
在上述活动中生成的工作产品包括所做出的关键决策、支持决策的客观依据和前提假设，以及开展这些活动中总结的经验教训。
技术需求开发流程典型的输出应包括如下内容。
● 经确认的技术需求 ：这是个被认可的需求集，包括对于待解决问题做出完整描述的需求，以及经客户和利益相关者确认与认可的其他需求。所获取的需求应当编写成文档，如系统需求文档、项目需求文档、接口需求文档和软件需求规范等。
● 系统性能指标 ：指所确定的系统定量度量指标。如果达到系统设计方案的设定值，则有助于确保一个或多个效能指标得到满足。每项效能指标可能对应两个以上的性能指标。更详细的信息可参见6.7.2.6.2节。
● 技术性能指标 ：指系统的性能度量指标集。通过将性能参数当前能达到的实际值与预期值或需要性能参数在此时达到的值做对比，然后对性能指标进行监控和调整。技术性能指标用于认定系统开发的进展和确定系统缺陷。更详细的信息可参见6.7.2.6.2节。
项目需求的完备集包括向产品分解结构的低层级分解和分配需求，用于设计相应单元，包括产品与系统边界外产品交互的需求。在产品分解结构内分配的需求包括功能需求（需要执行什么功能）、性能需求（这些功能必须执行到何种程度）和接口需求（产品与产品间交互的需求）。与系统边界外相关联的需求包括环境、安全性、人因等方面的需求，包括那些非功能性需求及来自NASA设计与建造标准的需求。图4.2-2给出了需求流动的概览，包括需求的类型、需求的拥有者或责任方（有权批准免责说明）。
图4.2-2 需求的流动、类型和所有权
功能需求、性能需求和接口需求对于项目非常重要，但若要构成保证项目成功所必需的全部技术需求的需求集，这些还不够。为空间部段设计的单元，在项目运行使用环境中应当能够生存并持续工作。这些环境影响因素可能包括辐射的、热学的、声学的、机械载荷的、污染的、微波射频的因素和其他因素。此外，可靠性方面的需求将影响系统在健壮性、故障容错性和功能冗余方面的设计选择，进而影响设计方案的故障管理。安全性方面的需求将影响系统在保证各类功能冗余方面的设计选择。图4.2-3给出了本章所描述需求类型的组织架构。
图4.2-3 需求类型的组织架构
1.功能需求
对于产品全寿命周期中所有预期的应用，需要指定每项应用中产品的功能需求。功能分析可用于获取并描述产品的功能需求和性能需求。基于所建立的评定标准（如相似的功能特性、性能指标等），需求被划分为若干个组，以便于需求分析聚焦。功能需求和性能需求被划入需求的功能分组，并被分配到子级功能、目标、人员和流程。此时需要考虑对时间敏感的功能顺序。每项已明确的功能采用输入、输出、失效模式、失效后果和接口需求的形式，自顶向下进行描述，以便能够在更强的功能组合中确认所分解的功能。功能按照逻辑顺序进行分配，因此，系统任何指定的运行使用任务（包括应急场景下的应用）都能够通过系统的端到端路径进行追踪，从而反映出为了实现目标，系统应当完成的所有功能的顺序关系。
询问如下类型的问题将有助于形成运行使用构想和运行使用场景：系统需要执行何种功能。这些功能需要在什么运行使用和环境条件下执行、由谁执行、在何处执行、执行多长时间等。通过思考这些问题经常能揭示出额外的功能需求。
注：
●功能需求用于定义为达到系统目标需要实现的功能。
●性能需求用于定义系统功能需要执行到何种程度。
2.性能需求
性能需求是对系统功能需要执行到何种程度的量化定义。与功能需求相同，通过询问如下类型的问题将有助于形成运行使用构想和运行使用场景，并描绘出性能需求：系统功能的执行所需要的频度和程度、需要达到的精度（如需要怎样精确的度量指标）、应形成哪些定性和定量输出、在什么强度（如最大同时数据请求）或环境条件下执行、需要持续多长时间、在什么取值范围内和有多少偏差许可，以及在多少最大通量和带宽容量内执行。
功能需求和性能需求示例
初始功能陈述
推力矢量控制器需要能够控制飞行器俯仰和偏航方向。
该陈述描述推力矢量控制器必须执行的高层功能。技术团队需要将该陈述转换为面向设计的功能需求和性能需求。
功能需求及相应的性能需求
●推力矢量控制器需要能够以最大角度（9±0.1）°万向转动引擎。
●推力矢量控制器需要能够以最大角速率（5±0.3）°/s万向转动引擎。
●推力矢量控制器需要能够提供（40 000±500）磅（1磅≈0.4536kg）动力。
●推力矢量控制器需要具有（20±0.1）Hz的响应频率。
在可能的情况下，使用如下方式定义性能需求：
（1）门限值（系统执行使命任务需要的最小可接受值）；
（2）性能需要达到的控制基线水平。
对低于门限值的情况，需要对项目进行需求降准。有时设计中超出门限值的额外功能特性可能只需要很少或不需要额外成本。当这种情况发生时，客户和项目团队可能会同意将新的功能特性作为已设定控制基线需求的一部分。通过门限值和控制基线来指定性能需求，可以为系统设计人员提供一个权衡空间，在其中研究考察不同的设计方案。
所有定性的性能指标期望值应该经过分析并转换为定量的性能需求。权衡研究通常可以帮助对性能需求的量化。例如，权衡分析可以显示，对性能需求的略微放松是否会产生系统费用的显著下降，或资源消耗的稍许增加是否会产生更显著、更有效的系统性能表现。提出性能需求的合理依据应当与需求同时记录在案，以便在性能需求可能要发生变更时，能够理解当时提出该项需求的原因和初衷，应当对能够通过权衡分析进行量化或做出变更的性能需求建立独立标识。关于权衡分析的更详细信息，参见6.8节“决策分析”。
注： 应当注意性能需求不要制定得过于严格。例如，对于必须在使用充电电池情况下才能够运行的系统，如果性能需求指定充电时间需要少于3h，而充电时间最多可以放宽到12h，则潜在的解决方案将可能会被排斥掉。同样，如果性能需求指定质量必须在±0.5kg以内，而±2.5kg也足以达到目标，这样可能会导致产品价值未增加而费用却大幅度增长。
3.接口需求
为系统（包括其配套系统）定义所有的接口需求是一项重要的工作。其中，外部接口形成沟通产品和周边世界的边界。接口的类型包括运行使用指令和控制指令接口、计算机之间的接口、人机接口、机械接口、电气接口、热学接口和数据接口。相关场景图（参见附录F）是一个定义接口的可用工具，用于描述产品及其所有外部接口。一旦系统组件被定义，需要开发出能够显示系统的主要组件、组件间互联关系和外部接口的框图，据此给出组件和组件之间交互的定义。
应当考虑与产品整个寿命周期所有阶段相关联的接口，如与试验设备、运输系统、综合后勤保障系统、制造设备设施、地面操作人员、用户和维护人员之间的接口。
在执行完成技术需求开发流程之后，需要重新审视接口框图，并且精确改进已记录在案的接口需求，改进的接口需求应包含最新辨识的内部和外部接口的需求信息。关于接口需求的更多内容可参见6.3节。
本节讨论功能需求之外的需求子集，此类需求横向作用于系统之间，而不是沿着产品分解结构纵向分解。本节提供了有关环境需求、安全性需求、人因工程需求和可靠性需求的示例。这些都是横向关联需求类型的代表，而根据工程或项目的范围和性质，可能有许多领域和学科会提出此类需求。
每个设计单元都应该能够在项目运行环境中生存并持续工作。环境要求包括对辐射、热学、声学、机械负载、污染、射频等方面因素的限制。安全性需求推动设计选择能够提供多种功能冗余。人因工程需求确保人类的能力和局限性被充分考虑，从而确保系统的正常运行使用。其他非功能性需求（有时被称为系统的“……性”）也可能影响设计选择。这些非功能性需求可能包括通常会转化为横向关联需求的可生产性、可靠性、可维护性、可用性、可升级性及其他设计和建造标准等。
1.环境需求
每个空间使命任务都有独自的环境需求集，通常应用于飞行阶段的单元。此时系统工程的关键功能是，针对特定的使命任务辨识外在环境和内在环境，对预期的环境进行分析和量化建模，针对预期环境开发设计指南，根据预期环境确立关于性能余量的完整概念体系。
如果使用环境包络线，应该考虑系统在地面试验、存储、运输、发射、部署，以及在寿命周期起始到终止的常规运行使用中，可能遭遇到的所有状况。从使命任务环境中派生出的需求应该包括在系统需求里。
应当予以考虑的相关外部环境和内部环境包括加速度、振动、震动、静态负载、声环境、热环境、污染、宇航员引发的负载、辐射的总剂量/辐射影响后果、单个事件影响、表面电荷和内部电荷、轨道碎片、大气的（氧原子）控制和品质、姿态控制系统扰动（大气阻力、重力梯度、太阳压强）、磁场环境、发射时压力梯度、微生物的生长、地面和在轨微波辐射频率。
对于在项目中可能受使命任务环境影响的各个单元，需求结构中应当说明在运行使用中所应用工程学科的专门需求。这些学科领域中的系统单元需求集中在电磁干扰和电磁兼容性、接地、辐射和相关屏蔽、污染防护、可靠性、人类健康和环境保护等方面。
2.安全性需求
NASA广泛使用的术语“安全性”包含了人员（公众和职员）的安全性、环境的安全性及资产的安全性。安全性需求有两类：确定的安全性需求和基于风险信息的安全性需求。确定的安全性需求是对系统采取的行动或实际效果定性或定量地给出门限值的定义；在与使命任务相关的设计中，部件和系统及其相关活动，以及其他与安全相关的活动都应满足确定的安全性需求。
确定的安全性需求包括如下示例：安全性设备的引入（如在系统中使用防止液压升降机/液压臂的延伸超过预设安全高度和长度极限的物理栓件）；系统输入变量取值许可范围的限制；在系统某种运行模式或使用状态下，对输入命令做限制性检查，以确保它们在指定的安全性限制或约束范围内（如飞机只有在起飞升空的状态下，收回起落装置的指令才是被许可的）。
人类的错误可能引起安全性灾难，因此安全性评估应包括对于灾难及纠错行动的考虑。对那些标识为“安全性至关重要”的组件，相应的故障管理需求包括：（1）功能冗余或故障容错要求，从而允许系统在出现一个或多个故障时仍能满足运行使用需求，或通过简化系统功能特性要求保证其处于安全状态（如双冗余故障容错的计算机处理器、安全状态下的备份用处理器）；（2）如果某些特定的指标值（如温度）超过设定安全极限，能够探测到异常并自动关闭系统；（3）对于使用特定计算机语言编写的安全性至关重要软件，使用专用的安全性需求子集；（4）使用警示或报警装置；（5）根据使命任务和有效载荷分类，明确安全性技术规程。
基于风险信息的安全性需求是在考虑（至少是部分考虑）与安全性相关的技术性能指标及其相应不确定性的基础上建立的。此类安全性需求的示例为：在确定置信水平下宇航员的损失概率不超过设定的 p 值。需求也有可能建立在人类对环境灾害、机械灾害和电子灾害所能够承受的极限基础上。满足安全性需求需要辨别和排除危险，降低危险引起事故发生的可能性，或在可接受水平上降低危险及其引发相应事故的影响。
关于安全性的更多信息，可参见NPR 8705.2《空间系统的人因评级要求》、NPR 8715.3《NASA通用安全性工程需求》、NASA-STD-8719.13《软件安全性标准》。
3.人因工程需求
在航空、航天、无人使命任务和其他NASA相关工作中，人类作为运行使用人员和维护人员，是使命任务和系统设计的关键组成部分。人类的能力和局限性应该以某种方式反映到设计中，这种方式与材料特性和电子元件特性反映在设计中的方式相同。对于载人空间飞行，许多人类因素需求来自NASA-STD-3001《NASA空间飞行载人系统标准》，并在其伴随手册NASA-SP-2010-3407《人因集成设计手册》中给出进一步解释。
与人类因素相关的目标和约束包含在需求开发期间的系统各项计划中。在每个载人系统组件中，与人类因素相关的问题、设计风险和权衡分析被记录归档为项目需求的一部分，这样在设计阶段就可以充分解决这些问题。
在利益相关者中，不仅要纳入那些指定系统如何构建的人员，还要纳入那些在系统投入运行时将使用系统的人员，这样既可以自上而下生成系统需求（需要建成什么样的系统），也可以自下向上生成系统需求（预期系统如何发挥作用）。
所有硬件和软件方面的需求都应考虑人因在系统中的作用及人类被期望执行的任务类型。区分被动的乘客和主动的操作者，是重大设计决策的导向，而航天机组人员的数量将对后续关于宜居空间和存储容积的决策产生影响，也会对关于宇航员进行系统操作和维护可用时间的决策产生影响。
相应的系统设计方案需定义系统在保障人类活动方面的运行环境条件，以及可能影响人类用户的任何因素。这项需求可能需要指定可接受的大气条件，包括大气的温度、压力、成分和湿度，或指出噪声、振动、加速度和星体引力的可接受范围。针对这些需求可能还要指出何时需要使用防护服，或如何适应正常操作范围之外的不利情况、紧急情况。
适当的系统设计方案不仅需要考虑环境因素（如物理环境或可用技术），还需要考虑作为系统组件的人类因素（如身体条件和认知能力）。举例来说，航空和航天旅行中人类可能出现疲劳和自我控制方面的问题，而这些会严重影响人类的表现，应当考虑在设计需求之内。
4.可靠性需求
可靠性可以定义为一个设备、产品或系统在特定的运行使用条件下和在给定的时间内不出现故障的概率。可靠性是系统固有的设计特征，作为在运行使用和维护保障成本方面及系统效能方面的主要影响因素，可靠性在确定系统费效关系中起着关键作用。
可靠性工程是一个重要的专业学科，对达成经济有效的系统目标产生可观影响。可靠性工程主要在系统工程实践过程中完成，通过主动设计和管理实现特定的设计特征，确保系统在整个使命任务过程中能在可预计的物理环境中运行使用。可靠性工程的另一个作用是为系统的设计权衡、试验计划、运行使用和综合后勤保障计划提供独立的可靠性预计结果。
可靠性需求确保系统（含分系统，如软件和硬件）能够像整个使命任务过程中所期望的那样在可预计的环境和条件下运行使用，并确保系统有能力经受住一定数量和类型的失效、误差或故障（如经受住振动，预期的数据传输率、指令和/或数据错误，独立事件扰动，温度变化达到设定的极限等）。
环境可能包括地面（运输和处理）、发射、在轨（地球轨道或其他轨道）、行星间飞行、再入和着陆等相应的运行使用环境。此类环境也可能作用到某种运行模式或状态下的软件中。可靠性可能受到人为错误及工程系统（机械的、电气的、液压的等）故障的影响。可靠性应考虑人为错误的可能性（与人因系统集成相互协调，参见7.9节），因而需使用专题试验来验证假设。可靠性强调设计需求和验证需求，以满足相应运行使用水平的需要，满足在所有预期环境和条件下对故障和/或失效的容差限度。可靠性需求针对系统故障/失效的预防、检测、隔离和恢复等功能，以及针对相关运行使用人员/航天机组的告警，为设计方案选项提供输入。
需求的分解自顶层需求开始，按系统的层次结构进行。顶层需求来自总统行政指令、使命任务管理部门、工程管理部门、NASA机构、客户和其他利益相关者。这些顶层需求可以划分为功能需求和性能需求两类，并在系统内针对各个组成部分（单元和子系统）进行分配。分配的需求又在单元和子系统中进行进一步分解和分配。这个分解和分配过程持续进行，直到获得能够进行设计的完整系统需求集。在每一个层级（系统层、子系统层、组件层等）的分解中，在推进到下一层分解之前，全部派生需求的合集应当根据利益相关者的期望或较高层级的需求进行确认。
需求的可追溯性应能达到系统最低层级，确保每个需求都是满足利益相关者期望所必需的。如果需求没有被分配到更低层级或未能在更低层级实现，将可能导致设计方案无法满足目标而成为无效设计。反过来，低层级的需求如果不能被上层需求追溯到，将可能导致无法证明的超范围设计。需求的层级分解流程如图4.2-4所示。
图4.2-4 需求的层级分解流程
图4.2-5所示的是典型科学试验使命任务下，科学试验的必要需求自顶向下逐渐分解和分配的例子。理解需求之间的关联关系并记录归档非常重要，这会降低出现误解的可能性、降低出现不满意设计方案的可能性，以及降低相关成本和进度增加的可能性。
在阶段A和阶段B中，可能会出现需求的变更和约束的变更。所有的变更都必须进行全面评估，以确定其对上一层级需求和下一层级需求的影响。同样，所有的变更也应遵从作为正式变更控制流程一部分的评审环节和正式审批环节，这样可以维护需求的可追溯性，确保任何变更的影响都针对系统所有部分进行了完整评估。如果使命任务规模巨大且牵涉多个NASA中心或横跨其他组织和机构，则需要实施更加正式的变更控制过程。
图4.2-5 科学试验的必要需求自顶向下逐渐分解和分配
在开发系统需求的时候，获取需求陈述是重要的，获取与每个需求相关联的元数据同样重要。元数据是阐明和连接需求的必要支撑信息。
在开发每一项需求时，还应全面考虑需求的验证方法及如何实施所选的验证方法。某些工程/项目会以提出验证需求的形式获取各种需求验证方法。验证的方法包括产品试验、外观检视、定量分析和功能演示。在确定验证方法期间发现的任何新的需求或衍生的需求都应当记录归档。例如，新的需求可能是需要一个额外测试端口，以便在系统集成和试验期间能够直观地观察内部信号的输出。如果需求无法进行验证，结果就是要么不再将其视为需求，要么需求陈述需要重写。例如，陈述为“组件X需要最小化噪声”的需求是模糊的，无法进行验证。如果将需求重新陈述为“组件X的噪声水平需要保持在Y分贝以下”，那么显然这样的陈述是可以验证的。表4.2-2给出了需求元数据类型的示例。如果缺少需求元数据的信息，可能导致NASA和承包商在成功验证需求方面产生不同的期望。
表4.2-2 需求元数据类型
客观依据
客观依据应当是最新的，且应当包含以下信息。
● 需求的理由 ：通常提出需求的理由不清晰，而且在形成需求文档的过程中若不记录，则可能丢失。理由可能指向一个约束或指向运行使用构想。如果存在清晰的上层需求或存在能够解释理由的权衡研究结果，则理由应当可以作为参照。
● 归档的前提假设 ：如果在记录归档的需求中，假设技术开发计划已经完成，或技术开发使命任务已成功完成，则应当归档此前提假设。
● 归档的关系 ：与所预期的产品运行使用（如期望利益相关者如何使用此产品）的关联关系应当归档。该项工作可以与运行使用构想同步完成。
● 归档的设计约束 ：在设计过程中，由决策的结果带来的约束条件应当归档。如果需求陈述的是实施方法，则客观依据应当陈述为什么所做出的决策是将解决方案限制在所提出的单一实施方法内。
需求数据库是个极其有用的工具，能够用于获取需求和相关元数据，能够用于展现需求之间的双向可追溯性。需求数据库随时更新变化，可存储和提供与需求相关的状态信息，如需求的待确定状态/待分解状态、需求分解的日期、需求验证的当前状态。每个项目都应该决定自身需要获取什么元数据。需求数据库通常处于中心地位，从而便于整个项目团队使用。关于需求验证矩阵的示例，可参见附录D。
1.应用标准的重要性
标准为建立覆盖整个工程和项目的公共技术需求提供可信的基础，从而避免需求不兼容的情况，并确保至少满足最低程度的需求。如果能得到有效应用，公共标准还能够降低产品实现和运行成本、能够降低产品检查成本及通用产品供应成本等。标准是基于经验教训总结和最佳实践经验建立的。通常，标准（和规范）应用于产品全寿命周期，建立设计需求和余量、材料和加工工艺规范、测试方法和接口规范（如设计和建造标准）。标准不是封闭的，应当作为要求（或指南）应用在设计、制造、确认、验证、接收、使用和维护中。
2.标准选择
NASA在技术标准方面的政策在NPD 7120.10《NASA工程和项目技术标准》中给出，其中说明标准的选取、剪裁、运用和控制。总体上看，在NASA工程和项目标准中权限的顺序如下：
（1）（美国）法律规定的标准（如环境标准）；
（2）（美国）国内或国际工业界共同认可的通用标准；
（3）其他的（美国）政府标准；
（4）NASA技术标准。
NASA也可以指定限定性标准或“核心”标准，要求所有工程在技术可行的情况下必须应用这些标准。放弃指定核心标准需要得到NASA总局的审议和许可，除非另行授权指定审议和许可单位。标准解释权归与之相应的技术权威单位所有。