下载掌阅APP，畅读海量书库
立即打开
在本节讨论中，术语“需求”专指NASA强制规定的“需要……”形式的陈述。本节集中讨论对包含在NPR 7123.1中的相关需求（NASA系统工程需求规范）的剪裁。
NASA承认其需求描述规范应当适合每一项工程和项目的独有特点，从而保证使命任务能够以经济有效的方式取得成功。为达到这一目标需要用到剪裁流程。
NPR 7123.1将“剪裁”定义为“在NASA系统工程需求规范设定的需求中，通过对需求做出缩减，找出与相应工程和项目目标匹配并适合于所容许风险和约束的需求描述”。剪裁可能导致产生针对系统工程需求的免责说明或允偏说明（见NPR 7120.5第3.5节），并在下一版本的系统工程管理计划（如以合规矩阵的形式）中记录和归档。
既然NPR 7123.1是为了适应工程和项目，而且是在不考虑规模和复杂性的情况下编写的，NPR的需求描述中便留下了可观的解读空间。为此，引入术语“客户定制”并将其定义为“对所推荐系统工程的成功经验进行修订，以便用于完成自身的系统工程需求描述。”客户定制并不需要免责说明或允偏说明，但进行客户定制时的显著变化应当记录在系统工程管理计划中。
剪裁和客户定制是重要的系统工程工具，利用这些工具依据NASA系统工程需求规范建立适合于工程和项目的需求，是可接受和可预期的。尽管剪裁被期望适用于各种规模的工程和项目，但小型项目面对的机遇和挑战并不等同于诸如航天飞机、国际空间站、哈勃深空望远镜、火星科学试验室等传统大型项目所面对的机遇和挑战。
即使小型项目的技术内容普遍更精细、更集中，当这类项目在用于演示验证先进技术或用于提供“某种类型”的能力时，它们也同样需要面对挑战。与此同时，它们具有竞争性的低成本预算和严格的进度安排，这决定了精致的和新颖的项目管理与系统工程实施途径。剪裁和客户定制使得工程和项目能够在费用和进度的约束条件下成功实现其技术目标。其关键是做到有效剪裁，从而使以往总结的经验教训和成功经验能够得到反映。针对项目的特定需要，系统工程需求的剪裁和系统工程成功经验的客户定制有助于消除不必要的开支，同时获得所需要的收益。为做到这一点，项目管理团队、客户/利益相关者、NASA中心管理机构和独立评审单位必须了解可接受的风险水平并达成共识。然而，即使有了这些基础，对于特定的项目来说，适当剪裁系统工程需求和定制NPR 7123.1中成功经验的实际过程仍然是复杂的、艰辛的。对于任何项目来说，有效的途径和有经验的指导都可以使剪裁过程更系统、更有效。
《NASA软件工程手册》的第6章给出了针对软件项目的系统工程需求如何进行剪裁的指南。
NPR 8705.4《NASA载荷的风险分类》试图针对工程和项目确定风险分类。该文献为判定准则建立了控制基线，使得用户能够为NASA载人和无人发射系统及运输工具的载荷确定风险分类水平。该文献同时也是了解和定义剪裁判定准则的起点。
可接受剪裁的范围取决于工程/项目的若干特征，如下是部分示例：
（1）使命任务类型。例如，载人空间飞行使命任务的需求要远比小型无人使命任务的需求严格。
（2）使命任务关键性。指在实现NASA总局战略规划中使命任务的关键性。可能不允许对那些必须绝对成功的关键使命任务NPR需求描述进行剪裁。
（3）可接受的风险水平。如果NASA总局和客户有意愿接受更高等级的失败风险，则某些NPR需求可以放弃。
（4）国家意义。对于国家有重大意义的项目，可能不允许对NPR需求描述进行剪裁。
（5）复杂性。高度复杂的使命任务可能需要更多的NPR需求相互重叠，以便保证系统兼容程度，而对于相对简单的使命任务可能不需要如此高的严格程度。
（6）使命任务期限。具有较长运行期限的使命任务比仅有较短期限的工程/项目需要更严格地遵从NPR需求。
（7）使命任务的成本。较高成本的使命任务可能需要更严格地遵从NPR需求，以确保对工程/项目的适当控制。
（8）发射约束。如果存在某些发射方面的约束，则项目可能需要更多地遵从NASA总局的需求。
NPR 7123.1中引入了合规矩阵（参见NPR 7123.1附录H的H.2节），用于帮助工程和项目验证它们是否满足特定的NPR需求。合规矩阵用于确定工程/项目是否符合或有意图遵从NPR的需求，或用于判断对NPR需求的剪裁。合规矩阵在使用中可以帮助辨别在进行客户定制时，能够达到满足NPR需求描述要求的主要方式（包括正式的和严格的），还可以用于与利益相关者就客户定制问题进行交流。随着请求剪裁的时间不同，剪裁流程（该流程可能在工程和项目寿命周期的任何时刻发生）有可能导致出现对NPR需求的允偏说明和免责说明。需求的允偏说明和免责说明可以分别提交给授权管控机构，也可以通过合规矩阵的形式提交。合规矩阵附属于系统工程管理计划共同提交审批。如果做不到这一点，如没有系统工程管理计划，该计划的内容与其他文档共同形成相关的项目工作计划，则合规矩阵也应当写入这份项目工作计划中。
图3.11-1给出了一个空间飞行项目在概念上的剪裁流程。相关管理人员（如项目负责人/项目主审人/任务主管等）组成一个项目管理团队，将对NPR需求的剪裁结果编入合规矩阵。为适当地进行项目分类，团队（包括首席工程师、责任系统工程师、安全性和使命任务质量保证师）需要了解项目需求的组成要件，如项目的需要、目的、目标，以及相应的风险水平。
图3.11-1 概念化的空间飞行产品需求剪裁流程
通过一个迭代的流程，项目管理团队使用合规矩阵，根据整个NPR需求剪裁出适合项目的需求。如果能够提供带有操作指南的剪裁工具，则可以使剪裁流程更加容易。NASA的某些中心（包括兰利研究中心和马歇尔航天飞行中心）开发的用于各中心内部的剪裁工具也能够适用于其他中心。来自行业主题专家的指导应当能够帮助寻求确定特定项目的合适剪裁量。合规矩阵中提供每项NPR需求的客观依据，以帮助对剪裁的理解。一旦剪裁完成，且剪裁的需求及其客观依据被记录到合规矩阵中，所得到的剪裁结果便被提交到相应的主管部门审批。
剪裁经常出现在下述三个方面：
（1）删除对特定工程/项目不适用的需求项。
（2）删除负担过重的需求项（实现该项需求的代价可能是，在项目中利用不同的资源所引起的风险增长远高于不满足该项需求的风险）。
（3）采取某种方式改变需求的范围，使项目能够在实现需求的代价与不满足需求的风险之间取得平衡。
客户定制方面的系统工程成功经验包括以下内容：
（1）调整17个系统工程流程中每一个流程的实施途径。
（2）针对规定进行的评审，调整评审的审议程序和时间安排。
针对每个项目或工程，NPR 7123.1中的每一项需求都要评估其可用性。例如，如果项目完全是在NASA内部开发的，NPR 7123.1第4章
中约定的需求便不再适用；如果所开发的系统不包含软件，则NPR需求中用于开发和维护软件的部分便全部不再适用。
根据项目和工程的不同，某些需求范围的缩减可能是恰当的。例如，尽管官方发布的项目管理指令性文件（如NPR 7120.5、7150.2、7120.7、7120.8）要求在用于工程/项目时可能需要形成若干个独立文档，但NASA系统工程需求规范并不要求额外的独立文档。对于小型项目，许多计划可以仅用若干页文本或若干幅图描述。在这种类型的项目中，任何要求各项计划独立成文档的NPR需求都显得过于累赘。在这种情况下，相关信息可以简单地作为一部分写入项目工作计划或系统工程管理计划中。如果适用的项目管理指令性文件（如NPR 7120.5或NPR 7120.8）要求文档独立，则需要编制工程/项目的免责说明/允偏说明。当然，如果NPR需求和NASA中心的期望皆未要求独立文档，则项目可以自行决定如何记录信息且不需要免责说明和允偏说明。在系统工程管理和项目管理的合规矩阵中能够获取信息存档的方式，有助于项目管理的清晰性。
针对特定类型的工程/项目（见表3.11-1），官方的项目管理指令性文件确定了所需的或推荐的寿命周期。寿命周期定义了各种评审的程序和时机。然而，涉及评审的正规性及如何实施，大多数情况是自行决定。NPR 7123.1中附录G给出了相关扩展指南，包括评审启动条件和顺利通过评审的判定准则。一般情况下，工程/项目会以某种方式将这些准则按客户要求定制化，使之对工程/项目更有意义。当然，NASA系统工程需求规范不需要这种客户定制模式提供免责说明和允偏说明。但是，如果与NASA技术规程需求所要求的评审要素有所不同，则需要对需求文档做剪裁处理。
表3.11-1 工程/项目的类型示例
续表
注：①依据对NASA战略规划的重要程度。
②核心使命任务控制基线。
如果确定工程/项目不需要进行某项评审，则需要有免责说明或允偏说明。当然，NASA系统工程需求规范并未指定实施这些评审的最低限量。例如，某小型项目可能会决定将系统需求评审和系统定义评审（或使命任务定义评审）结合起来。只要两项评审的相应工作全部完成，NASA系统工程需求规范便不要求免责说明或允偏说明。（注意：即使NASA系统工程需求规范不要求，免责说明或允偏说明仍可能在官方的项目管理需求中有要求。）这里客户定制和剪裁应当保存在合规矩阵中，或写入评审计划/系统工程管理计划中。
除非官方项目管理指令性文件中有要求，否则可以通过客户定制使评审活动适应工程/项目的类型，而评审的正规性不会受到影响。对于大型项目，合适的做法应该是进行历时数周的非常正式的评审，使用正式的评审对象必纠偏差报告流程/需纠偏差报告流程，产生评审概要和详细的汇报演示，汇报的对象包括评审委员会和预评审委员会。对于小型项目，相同的评审可能在数小时内完成，只是一个有若干利益相关者参加的室内评审会，其中的问题和活动简单记录在Word文档或PowerPoint文件中。
NASA系统工程流程所需作为里程碑评审使用的汇报演示文稿模板，可以在NASA系统工程网络实践内部社区网站上获取。
表3.11-1给出了基于相关系统相应各类使命任务的示例，使命任务可分解为若干类型各不相同的项目，从非常复杂的类型A到极其简单的类型F。示例中在进行项目剪裁时，将特定项目安排在某个特殊类型中应被视为某种指导意见，而不是固定不变的特征化。许多项目符合多个类型的特征，因此在剪裁过程中，允许对那些更简单且对风险更开放的项目做较多的剪裁，而对那些复杂性和缓解风险起主导作用的项目做较少的剪裁。各个项目类型的剪裁准则和定义可能随使命任务所在的NASA中心及主管部门的不同而发生变化，这取决于哪种类型更适合他们对使命任务的认识。表3.11-2给出另一个示例，说明工程/项目所要求的文档资料应如何实现剪裁和客户定制。一般规律是越简单的项目，需要的文档资料越少，实施越少的正式评审。项目的产品数量也应当作为考虑因素。
表3.11-2 NPR 7120.5中要求的项目产品的剪裁示例
续表
NASA系统工程需求规范中的允偏说明和免责说明可以分别提交给需求负责单位，或汇入根据NPR 7123.1附录H所建立的相应合规矩阵。如果某个NASA中心要求对系统工程需求规范进行剪裁并作为该中心的标准，则可参照NPR7123.1附录H的H.1节制定，并且提交首席工程师办公室审批该中心提出的流程请求或流程变更。如果由某个NASA中心负责的工程/项目需要对系统工程需求规范进行剪裁，则可以使用NPR7123.1附录H中H.2节的合规矩阵。针对这些情况，免责说明/允偏说明需要得到NASA中心主任或其指定代理人的批准。
不论是NASA中心的要求还是工程/项目的要求，剪裁的结果及其客观依据应当反映在系统工程管理计划的最新版本中，并且应得到需求负责单位的正式批准。经过批准的免责说明/允偏说明可以在整个项目团队内部和各层级管理人员之间交流。如果需要在工程/项目内部进行独立评审，则可以对期望和评估准则进行适当修改。表3.11-3给出了依据NRP7123.1的附录H中H.2节合规矩阵进行剪裁的示例。
表3.11-3 使用合规矩阵的示例
续表
