4.1 利益相关者期望开发流程

系统工程引擎建立了系统设计与产品实现的基础，而利益相关者期望开发流程是系统工程引擎的起始流程。这个流程的主要目的是辨识出谁是利益相关者，明晰利益相关者准备如何使用产品。通常可以通过运行使用用例（有时被称为使命任务设计参考）和运行使用构想达到这个目的。

4.1.1 流程描述

图4.1-1所示是利益相关者期望开发流程的典型流程框图，图中给出了利益相关者期望开发所需考虑的典型输入、输出和活动。

4.1.1.1 流程的输入

利益相关者期望开发流程需要的典型输入包括如下内容。

● 初始的客户期望 ：包括来自客户的、针对不同层级产品的需要、目的、目标、期盼、能力要求和其他约束条件。对于顶层产品（最终的目标产品），是指客户最初提出的对应产品需要的期望。对于产品结构中其他层级的目标产品，是指在向上一层级交付此目标产品时，接收者对此产品的期望。

● 其他利益相关者期望 ：指除客户之外的关键利益相关者的期望。例如，此类利益相关者可能是一个试验团队，负责接收低层级交付的产品（目标产品及配套产品），也可能是培训人员，负责指导与本层级产品相关的运行使用人员和管理人员。

● 客户传承的需求 ：指客户从更高层级传承的或从更高层级分配的需求（如上一层级需求）。这些需求能够帮助建立本层级的客户期望。

4.1.1.2 流程中的活动

1.辨识利益相关者

利益相关者是指受产品或项目影响的，或与产品/项目有利益关系的群体或个人。参与到项目/产品运作中的关键人物称为关键利益相关者。客户通常是关键利益相关者之一。在产品分解结构中不同层级工作的系统工程师可能会面对不同的客户。例如，在系统顶层，客户可能是购买产品的某个人或某个组织。对于在产品分解结构中自顶层向下三到四个层级工作的系统工程师，客户可能是某个将单元产品集成到更大组装产品的团队负责人。不论系统工程师在产品分解结构的哪个层级工作，重要的是了解客户所期望的是什么。

还有其他与产品存在利益关系的团体，这些团体通过提出宽泛而宏观的约束条件对项目施加影响，客户的需求应当在这些约束条件下满足。这些团体可能受项目产品及产品使用方式的影响，或负责产品寿命周期内的保障服务。诸如议会、NASA顾问委员会、工程负责人、维护人员、使命任务合作方都属于此类团体。在流程中尽早识别并列出利益相关者非常重要，特别是识别对项目有重大影响的主要利益相关者。

通常，系统的客户和用户容易被识别出。辨识出其他关键利益相关者可能会较为困难，他们会随着项目的类型及项目所处的阶段而有所不同。表4.1-1给出了在整个寿命周期各个阶段应当予以考虑的利益相关者的示例。

2.理解利益相关者期望

完全并清晰理解客户和其他关键利益相关者对项目/产品的期望，是系统工程流程中最重要的一步。这一步为所有其他系统工程工作奠定了基础。其有助于确保所有团体基于一个相同的共识，确保所生产的产品能够使客户满意。当系统的客户、其他利益相关者及系统工程师之间针对产品能够展现出的功能、特征、行为、外观和性能达成一致意见，便能够确定更多的客户期望，并有助于避免在寿命周期的后期出现新的重要需求。

通过会谈/讨论、调查研究、市场分析、互通邮件、任务说明书、初步的客户需求集或其他手段，利益相关者指出其需要的是什么，如项目的最终状态或项目的目标产品，或为项目目标增加约束的范围。这些约束范围可能包括（资源）消耗、交付时间、性能目标、运行使用约束条件、培训目标，以及其他非定量约束条件，如组织管理需求和地缘政治目标。这些信息需要进行评审、总结和记录存档，使得所有团体能够就期望的问题达成一致。

图4.1-2显示了在确定利益相关者期望时需要的信息类型，并且描述了信息是如何演化为顶层需求集的。曲线箭头描述的是确认路径，同时图中给出了每一步工作需要定义的信息类型的实例。

开发利益相关者期望与明确使命任务授权和使命任务战略目标同时开始。使命任务授权随使命任务类型不同而改变。例如，科学试验使命任务通常根据NASA科学试验使命任务主管部门的战略规划启动，而空间探索使命任务可能根据美国总统行政指令启动。理解使命任务的目标有助于确保项目团队朝一个共同的目标努力工作。这些目标形成了使命任务开发的基础，所以需要清晰地定义和关联。

项目团队还应当对可能面对的约束条件进行验证。约束条件是需要满足的条件。有时约束条件是由外部因素决定的，如轨道力学因素、某个必须使用的已经存在的系统（外部接口）、法规约束或其他技术状态因素；有时约束条件是由整个预算环境造成的。运行使用构想和约束条件同样需要包含在利益相关者期望开发流程中。这些内容共同确定系统应如何运行使用以达到使命任务目标。

在开发利益相关者期望完备集的过程中，系统工程师需要与工作在各个领域的团体交流，如轨道碎片领域、空间资产保护领域、人因系统集成领域、质量保证领域和可靠性领域。确保能够获取期望的完备集将有助于避免在寿命周期的后期出现“意外”特征。例如，空间资产保护可能需要对上行链路的指令做额外加密，需要对射频系统做额外的遮蔽或过滤，需要使用不同的频段，或其他设计变更，这些都可能使已经开发的系统增加额外成本。

3.确定需要、目的和目标

为了定义目的和目标，有必要引导出利益相关者心目中的需要、要求、期盼，以及对能力、外部接口、前提条件和约束条件的要求。达成一致认可的目的和目标集可能是一个长期艰巨的过程。在整个系统工程流程中，主动与利益相关者反复交互，是使所有参与项目的团体在应该做和如何做方面达成一致理解的有效途径。弄清楚谁是主要利益相关者及谁拥有决策权，对帮助解决可能的冲突非常重要。

通过确定需要解决的问题及问题的范围，得到相应的需要、目的和目标（NGO，简称“目标要求”），这为确保参与流程的每个人（需求制订者、客户和其他利益相关者）在项目初始阶段达成一致提供了适当的机制。目标要求并不是约定的需求或设计方案。

目标要求中的“需要”定义为回答如下问题：我们试图去解决什么问题？目标要求中的“目的”处理如下问题：满足“需要”必须去做什么？也就是说，客户要求系统去做什么。目标要求中的“目标”是对“目的”的扩展，是将特定期望记录归档的基础和手段。为了解释为什么存在所述需要、目的和目标，应当能够提供相关客观依据，所有做出的前提假设，以及那些对理解和管理目标要求有用的信息。

对目标要求的清晰描述，能够针对从需要到目的、从目的到目标提供清晰的可追溯性。例如，如果设定的目的无法满足需要，或设定的目标与目的不符，它们就不能作为内容列入综合目标要求集。这种可追溯性有助于确保团队给出的期望确实是所需要的。

下列定义来源于Larson等人所著的《应用空间系统工程》[Larson 2009]，用于帮助读者理解本手册中的“目标要求”所包含的含义。

● 需要 。用来启动其他所有相关工作的单一陈述语句，它与系统被期望解决但还没有解决方案的问题相关。对需要的陈述是单一的。如果试图给出的需要不止一个，则必须在两两之间做权衡，这很容易导致至少某一项利益相关者的期望无法得到满足，甚至可能导致多项期望无法得到满足。

● 目的 。对需要的精细化，形成系统期望的一个特定集合。目的为用于描述那些在问题评估时已辨识出的关键问题的处理手段。目的不一定采用定量化的或可度量的形式，但应当能够评价系统是否达到了这些目的。

● 目标 。系统输出必须达到的指定的水准值。每个目标都应当与特定的目的相关联。通常情况下，目标应当满足四项判定准则。（1）它们应当有足够的独特性并提供清晰的指向，因此开发者、客户和试验者能够理解它们。它们应当明确指向期望的结果，并反映出系统需要做什么，但不需要明确如何得出解决方案。（2）它们应当是可度量、定量化和可验证的。项目需要能够监控系统对每一项目标的成功实现过程。（3）它们可以具有挑战性但应当是可达的，目标设定值应当是现实的。其中可能包括“待确定”的目标，直到权衡研究完成、运行使用构想固化且技术成熟才能确定。目标应当是可行的，使得需求能够合规陈述，系统能够设计完成。（4）它们应当是结果导向的，聚焦于期望的输出和结果，而非达成目标所使用的方法。重要的是应当牢记，目标不是需求。目标在系统开发的A前阶段确定，这有助于系统需求集的逐步形成，但正是需求自身决定了系统设计，并在系统设计转入制造之前得到验证。

可以把所获取到的利益相关者的期望看作是初步的，它们将在运行使用构想的开发过程中得到进一步细化，并最终得到利益相关者的认可。

4.建立运行使用构想和保障策略

在构建了初步的利益相关者期望之后，接着是开发系统的运行使用构想，从而能够进一步确保技术团队全面理解利益相关者期望，确定最终产品能否满足这些期望，以及确保这样的理解能够被利益相关者认可。如果发现理解上的偏差或陈述上的模糊，这样做能够引导对初步的利益相关者期望集合做进一步细化。这些对系统未来行为的设想和构思，在不需要说明（设计方案）如何满足需要的条件下定义了所期望的系统，因此在理解利益相关者期望时不需要考虑系统的方案实施和运行使用。运行使用构想还描述了系统的行为特征及人们与系统交互的方式。保障策略则包括关于系统制造、试验、部署、运行、维护和处置的条款。

关于开发运行使用构想的更多内容，可参见本手册4.1.2.1节中的讨论。附录S给出了一个开发运行使用构想的参考提纲。运行使用构想的特定章节会随项目的范围和目的而不同。

5.以可接受的陈述方式定义利益相关者期望

一旦开发完成运行使用构想，所有的偏差和模糊之处已经得到处理和解决，在技术团队和利益相关者之间关于系统/产品的期望/意图是什么已经达成共识，因而可以形成正式的利益相关者期望文件资料。期望文档的内容通常包括目标要求、使命任务成功判定准则和设计导向；这些可以采用纸质文件、电子表格、系统模型及其他适合于产品的形式存在。

设计导向在极大程度上依赖于运行使用构想，包括运行使用环境、运行轨道和使命任务期间的需求。对于科学试验类使命任务，设计导向至少应包括使命任务启动日期、持续时间和预定轨道，还包括其他执行使命任务需考虑的因素。如果考虑有多个轨道可选择，则每个轨道需要单独的构想。对于探索类使命任务，为保证探索成功应当考虑目的地、持续时间、运行使用操作序列（包含系统技术状态变更）、宇航员操作界面、维护与维修活动、必须的训练、目的地探险活动等。

6.从效能指标角度分析期望陈述

使命任务成功判定准则中定义了使命任务必须成功完成的内容。这些内容可能表现为科学试验型使命任务、载人的探索型使命中的探索行动构想、技术演示验证型使命任务的技术目标。成功判定准则同时定义了使命任务构想和探索活动的度量指标应当达到何种满意程度。成功判定准则紧扣利益相关者期望、工程性需求和约束条件，应用于高层级的需求。

效能指标（MOE）用于对成功的度量，该指标针对由利益相关者期望引出的系统目标，确定该目标的相应完成程度。效能指标从利益相关者的视角出发，展现评判准则是否满足，能否使利益相关者认定项目取得成功。这种情况下，效能指标评判准则与使命任务/项目成功评定准则有相同含义。效能指标在目标要求或利益相关者的其他期望形成文档后开发获得。关于效能指标的更多内容，可参见本手册的6.7.2.6节。

7.确认所定义的期望陈述具有双向可追溯性

目标要求或其他利益相关者的期望同样都是期望集的来源。根据在产品层级中所处的不同位置，相应期望可能被追溯到某个目标要求或某个高层级产品的需求，追溯到相关机构的战略规划或其他来源。后续流程中的功能和需求仍会追溯到这些目标要求。采用需求管理工具、模型或其他应用软件，对于获取和追溯期望与需求特别有用处。

8.获得利益相关者对所确认期望集的认可

一旦利益相关者与技术团队针对利益相关者期望和运行使用构想的表达方式达成一致，便得到正式签署的或其他形式的认可。为了得到这样的认可，通常会根据系统的范围和复杂性举行一次正式的或非正式的系统构想评审（参见6.7节）。利益相关者期望（如目标要求）、效能指标和运行使用构想根据需要被展示、讨论和细化，以达成最终的一致。这样的共识展现了双方已经同意产品进入开发阶段。

9.设定利益相关者期望的控制基线

形成一致的利益相关者期望集（目标要求和效能指标）及运行使用构想，在此情况下便确立了控制基线。此后的任何变更都需要（根据产品的性质）经历正式的或非正式的审批流程，审批流程既涉及利益相关者，又涉及技术团队。

10.获取工作产品

除了利益相关者期望的开发、记录归档和设定控制基线之外，通过本流程还应当获得前面讨论的运行使用构想和效能指标，以及其他工作产品。工作产品可能包括所做出的关键决策、支撑决策的客观依据和前提假设，以及活动实施中总结出的经验教训。

4.1.1.3 流程的输出

利益相关者期望开发流程的典型输出包括如下内容。

● 经确认的利益相关者期望 ：指位于产品结构本层级的已达成共识的期望集合。通常期望的表达形式是已识别的需要、目的和目标，以及约束条件和前提假设。利益相关者期望可采用的表达形式还包括模型和其他图形形式。

● 运行使用构想 ：描述系统在全寿命周期各阶段如何运行使用以满足利益相关者期望。其从运行使用的角度刻画系统的特征，有助于促进对系统目的、目标和利益相关者其他期望的理解。运行使用构想的形式包括运行使用构想文档、模型或使命任务设计参考。

● 配套产品的保障策略 ：包括在目标产品的制造、试验、部署、运行使用与维护、退役处置期间可能需要的任何特殊规定。它们标志着为了生成目标产品，需要什么样的保障及需要开发什么样的配套产品。

● 效能指标集 ：一组基于利益相关者期望开发的效能指标。这些度量指标代表了那些对系统成功起关键作用的期望，系统未能满足这些指标要求可能会导致利益相关者将系统视为不可接受的。

其他可能产生的输出包括如下内容：

● 人因 / 系统功能分配 ：描述系统硬件/软件与所有人员的交互关系，并描述这些交互的支撑结构。在许多设计（如载人空间飞行）方案中，人类操作者是整个系统的关键部件，因而在所参与的系统中，人因的作用和责任应当被清晰地理解。此类输出应当包括使命任务所需的所有人因/系统交互关系，如系统组装、地面操作、后勤保障、飞行中的维修和地面维修、飞行中的执行任务等。

4.1.2 利益相关者期望开发流程指南

4.1.2.1 运行使用构想

运行使用构想是获取利益相关者期望的重要内容，用于确定系统需求和确定项目的架构。运行使用构想是系统中与用户相关联的需求开发和结构开发的出发点，是此后各类系统描述文档的开发基础，这些文档包括运行使用计划、发射和转移轨道计划、运行使用手册；运行使用构想同时为系统的长期运行使用计划开发活动提供基础，这些活动包括确定运行使用设施、人员安排和网络化进度安排。

运行使用构想是开发系统需求中的重要原动力，因而应当在系统设计过程早期予以考虑。通过考察运行使用构想及其用例，经常能揭示出可能会被忽视的需求和设计功能。例如，新增添一项系统需求“在使命任务某个特殊阶段允许进行通信”，可能需要在航天器的专门位置增设一部天线，而这在既定的使命任务中可能并不需要。运行使用构想应当包括所有重要的运行使用场景，包括已知的非计划内的运行使用场景。为了开发可用的、完备的运行使用场景集，应当考虑那些重要的故障模式下和退化模式下运行使用的情形。运行使用构想还是对整个寿命周期中人力资源目标进行特征化，在人因和系统之间进行功能分配的重要助手。在梳理并实现使命任务目标的过程中，对于需要交付的系统，应当明确什么时候做出以下决策：运行使用人员的贡献是什么，以及系统应当做什么。

开发出综合的运行使用构想对于制定整个寿命周期的采办策略至关重要。正如本手册7.1节“与合同相关的工程技术”中所述，在某些采办策略中，系统工程开发阶段的合同与系统运行使用阶段的合同分开签订。以能够经济、有效地完成使命任务目标的方式协调和整合两阶段合同的责任可能完全落在NASA自己身上。即使是在仅限开发的项目中，也应该以着眼长远的战略观点来制定运行使用构想，并且应该处理那些设定的和非设定的性能、维护、后勤等需要考虑的因素。拥有长远的观点有助于确保在开发阶段得到的结果能够与更高层级的概念化运行使用和成本框架相适应。

运行使用构想对所有项目同样重要。对科学试验项目来说，运行使用构想描述系统如何运行使用才能达到使命任务成功度量指标集的要求，这些项目通常由度量指标集中的指标值驱动。对载人空间探索项目来说，运行使用构想似乎更加复杂，通常有更多的运行使用阶段、更多的技术状态变化，以及人类参与交互所需要的额外通信链路。总的来说，系统的功能和目标应当在项目早期就在宇航员和系统之间分派清楚，并在寿命周期的早期阶段进行评估。不论是什么项目，系统运行、维护和保障所需要的人力资源应当在运行使用构想中明确指定，以避免在寿命周期后期阶段出现成本方面的意外。

运行使用构想应考虑运行使用的所有环节，包括在集成、试验、发射直到废弃/处置的过程中那些计划内和非计划内的运行使用。运行使用构想中包含的典型信息有：主要阶段的描述、运行使用时间基线、运行使用场景和/或使命任务设计参考、故障管理策略、人机接口和所需训练水平的描述、系统端到端通信策略、指令集和数据架构、运行使用设施、综合后勤保障（重复补给、维护和组装）、人力资源水平和所需技能、关键事件等。运行使用场景的作用是描述系统运行使用的动态视图，例如，在各种模式下和模式转换情况下如何感知系统是否正常运行，这些模式包括通过外部接口的交互、对预计的风险和故障做出响应、实施故障缓解流程等。对于探索类使命任务，运行使用构想可以由多个使命任务设计参考组成。为适应系统需求而进行的设计分析和性能分析应当满足所有的使命任务设计参考。图4.1-3给出了科学试验型使命任务的典型运行使用构想开发流程，图4.1-4描绘的是一个端到端的运行使用架构示例。关于开发运行使用构想的更多指导信息，可参见本手册附录S。

作为定义系统技术状态、运行使用活动、应急使用场景的基础，运行使用时间基线描述为达到每个运行使用阶段的使命任务目标所需要实施的活动、任务及其他按时间排列的相关要素。根据项目的类型（如科学试验、空间探索、军事行动），时间基线可能相当复杂。

时间基线伴随设计进展而成熟，其开始时表现为主要事件的简单时序，成熟后展示所有核心使命任务模式下或系统交付时的分系统运行使用详细描述。图4.1-5（a）和图4.1-5（b）分别描述探月飞行寿命周期早期的时间基线和使命任务设计参考。图4.1-6给出一个科学试验使命任务寿命周期后期的更加细致、完整的时间基线。

运行使用构想的一个重要内容是对运行使用阶段的划分，需要明确项目阶段D、阶段E和阶段F。针对为达到使命任务目的所需实施的技术状态变更和运行使用活动，运行阶段的明确划分可为此提供时序结构。所明确的每个运行阶段都应包括设施、装备和关键事件。表4.1-2给出了NASA使命任务的典型运行使用阶段的部分通用示例。

4.1.2.2 空间资产保护

当前，航天领域的趋势是在技术不断扩散的情况下，空间探访更容易、空间工程的全球化，以及空间系统和服务的商业化。这些将导致空间环境发生根本性变化。这种根本性变化体现在空间环境中拥挤、争议和竞争情况的加剧，这使得美国空间系统、信息基础设施和地面系统在受到多种形式的威胁时可能会变得更加脆弱。现实情况是，现有的能力中已经有许多可以阻断、瓦解或破坏NASA空间系统及控制这些系统的地面设施。鉴于美国对空间系统的依赖性，美国在2010年发布的PPD-4号 和2013年发布的PPD-21号 总统政策指令中，涉及的最新国家空间政策皆要求保护所有的关键空间系统和支撑性基础设施。

空间资产保护是一项关键的系统工程职能，其中的概念如图4.1-7所示。相应的方法建立在如下基本概念的基础上：

威胁×易损性=漏洞

如图中的系统工程分析部分所显示的那样。这一概念由罗伯特·鲍尔在其著作《飞机作战生存能力分析和设计基础》中提出，这本著作属于飞机生存学科的开创性工作。当然，这个概念适用于任何系统，包括航天器和信息基础设施系统。诸如尺寸、结构、运行使用构想、通信链路和其他子系统等因素都可能导致系统产生固有的弱点。当这些固有的设计特征被潜在的威胁所针对时，系统的漏洞和弱点就会变得明显。这是在空间系统及其架构的设计方案开发领域的基本认知。图4.1-7中的方法与NASA空间资产保护计划所采用的方法的不同之处在于，在NASA使命任务的开发过程中，会考虑包括故意恶意威胁在内的各种威胁。

这些威胁与其他技术风险相类似，是空间资产保护成为系统工程基本组成内容的原因之一。空间态势感知（Space Situational Awareness，SSA）是空间资产保护的一个基本要素，它能够提供敌对势力和不利环境对美国空间系统所构成威胁的深入了解和认知，对于开发和实施保护措施至关重要。空间态势感知包括空间避撞及感知空间自然环境。

在2010年《美国国家空间政策》发布之前，作为国家资源的好管家，NASA就已经开始致力于保护其空间飞行器和关键基础设施。NASA一直在更新其流程，以反映当前发展方向和投资组合的动态变化。例如，NASA已经通过NPR 7120.5对工程和项目提出实施空间资产保护的要求。工程和项目有责任制定工程/项目自有的保护计划，说明如何通过常规的工程和项目规划流程来实现这些要求并记录计划实施情况。制定工程/项目保护计划的第一步是，参照民用航天系统对空间威胁的归纳，提取那些通常被称为“防护类威胁”且发生可能性大的威胁，并根据NASA风险矩阵标准量表对它们进行分类。“防护类威胁”被定义为任何自然发生或人为的事件、事故或相关系统，此类威胁能够利用空间系统任何组成部分的易感应特性，导致使命任务面临被破坏、退化、毁损或服务被阻断的潜在可能。

下一步是通过将空间系统的易损性与防护类威胁相互匹配，来确定空间系统中的漏洞；同样，考虑到“威胁×易损性=漏洞”，在未能消除漏洞而带来风险的情况下，提出减小风险的防护性策略和对策建议。这个防护流程在每个系统工程流程运用过程中迭代进行，从发布确定控制基线的项目防护计划开始，终止于将项目推进到下一个关键决策点。期望的最终结果是增强的空间系统生存能力，如图4.1-8所示。

NASA关键资产保护已经被整合为系统工程的功能，涉及这项功能实现的有每个项目的首席工程师、系统工程师，以及空间资产保护计划的使命任务系统工程师。未来，项目首席工程师和使命任务系统工程师有望在起草保护计划方面发挥更大的作用。一旦项目中的航天器发射并准备投入运行使用，来自空间飞行运行使用团队的系统工程师将承担这项保护责任。

4.1.2.3 在各阶段辨识利益相关者

利益相关者期望开发流程最常用于A前阶段和阶段A的概念研究和需求开发期间。随着越来越多的利益相关者加入项目中，这个流程在后期各个阶段也很有用处。

在阶段B和阶段C，随着设计方案的开发，可能会识别出更多的利益相关者，包括被项目选中承担系统和子系统设计与实现任务的承包商。项目团队应该针对这些新的利益相关者重新启动利益相关者期望开发流程，以判断那些承包商手中既有的已确定控制基线的产品是否需要进行变更，尤其是在处理那些影响系统需求的变更请求时。

在阶段D，有更多的利益相关者加入项目中，包括装配、集成、试验和运行使用人员。利益相关者期望开发流程在此阶段侧重于记录对运行使用规程的期望、对运行使用人员培训和宇航员培训的期望，以及对后勤保障的期望。

在阶段E，项目开发团队可能要过渡到运行使用团队，此时再次运用利益相关者期望开发流程来明确运行使用人员的期望。该流程同样还可用于系统更新升级时的迭代开发过程中。

在阶段F，可能会出现新的利益相关者来实施项目终止流程，包括档案管理员和拆解人员。对于这些利益相关者需再次运用利益相关者期望开发流程。 u7l/OXd5N3Pr1B9MFlMcgqNz3f0+1mSZu/GPiyRs7eBhz/D7lmraBTlekV6J+uSC