INCOSE需求编写指南-第 2 节：需求和要求陈述的特征

定义 Definition:

需求或要求陈述定义了满足生命周期概念、需求、来源或父需求所需的基本能力、特性、约束或质量因素。如果它未包含在需求和要求集合中，则将存在能力或特性方面的缺陷，无法通过实现集合中的其他需求或要求来满足。

The need or requirement statement defines an essential capability, characteristic, constraint, or quality factor needed to satisfy a lifecycle concept, need, source, or parent requirement. If it is not included in the set of needs and requirements, a deficiency in capability or characteristic will exist which cannot be fulfilled by implementing other needs or requirements in the set.

基本原理 Rationale:

生命周期概念中需求的正式转变必须导致满足生命周期概念特定方面的需求，以满足生命周期概念中包含的目标、目的、利益相关者的期望、驱动因素、约束和风险。The formal transformation of a need from a lifecycle concept must result in a need addressing a specific aspect of the lifecycle concept that is necessary in order to meet the goals, objectives, stakeholder expectations, drivers, constraints, risks that are included in the lifecycle concepts.

每个需求，无论是单独地还是与集合中的其他需求组合在一起，都必须足以满足生命周期概念或其他来源的特定方面的意图。“充分”既包含特征“正确”（C8），又对其进行了增强，以确保它不仅是生命周期概念或其他来源的特定方面的“准确表示”，而且足以确保当 SOI 实现需求时，生命周期概念或其他来源的特定方面将得到满足。Each need, individually or in combination with other needs in the set, must be sufficient to satisfy the intent of a specific aspect of the of the lifecycle concept or other source from which it was derived. “Sufficient” both encompasses the characteristic “Correct” (C8) and enhances it to ensure it is not only an “accurate representation of the specific aspect of the of the lifecycle concept or other source but is sufficient to ensure the specific aspect of the of the lifecycle concept or other source will be satisfied when the SOI realizes the needs.

将一个需求转化为一个或多个要求，必然会产生一组要求，其中每个要求都是必需的，并且该集合足以满足转化后的实体的一个或一组需求。The transformation of a need into a one or more requirements must result in a set of requirements that where each is necessary, and the set is sufficient in order to meet a need or set of needs for the entity from which it was transformed.

每个要求，无论是单独地还是与集合中的其他要求组合，都必须足以满足特定的利益相关者的需求、来源或父要求。Each requirement, individually or in combination with other requirements in the set, must be sufficient to satisfy a specific stakeholder need, source, or parent requirement.

如果某项需求连同其兄弟需求（单个父需求的共同子需求）以可接受的裕度（由程序/项目确定）满足其父需求，则该需求被视为充分需求。例如，如果父需求是功能/性能需求，则符合兄弟需求集描述的所需功能和性能水平应确保集成产品符合父需求。充分需求既包含特征“正确”（C8），又对其进行了增强，以确保它不仅是“实体需求的准确表示，而且足以确保当 SOI 满足需求时子需求满足需求。A requirement is considered sufficient if it, along with any siblings (common children of a single parent requirement), satisfies its parent requirement with acceptable margin (as determined by the program/project). For example, if the parent is a functional/performance requirement, compliance with the required functionality and performance level described by the set of sibling requirements should ensure conformance to the parent requirement by the integrated product. Sufficient both encompasses the characteristic “Correct” (C8) and enhances it to ensure it is not only an “accurate representation of the entity need but is sufficient to ensure the need is satisfied by the child requirement when the SOI fulfills the requirements.

通过分解或派生来开发子需求必须产生一组子需求，这些子需求对于满足需求或来源的目的或子需求的开发所针对的分配父需求而言是必要且充分的。子需求集的成员可以存在于父需求所分配到的不同系统元素需求集中。在许多情况下，这些子需求具有依赖关系，其中一个需求的更改可能需要更改其他一个或多个需求。当子需求响应预算数量（性能或质量特性）以及接口需求时，情况确实如此。将这些依赖的子需求链接在一起很重要。有关分配/预算和接口需求，请参阅 NRM 第 6 节。The development of child requirements via either decomposition or derivation must result in a set of child requirements that are necessary and sufficient in order to meet the intent of the need or source from which it is transformed or the allocated parent requirement the child is being developed in response to. Members of the set of child requirements can exist in different system element sets of requirements which the parent requirement was allocated to. In many cases these child requirements have a dependency, where a change in one could require a change in one or more of the others. This is true when the child requirements are in response to a budgeted quantity (performance or quality characteristic) as well as interface requirements. It is important to link these dependent child requirements together. Refer to the NRM Section 6 concerning allocation/budgeting and interface requirements.

实现每项需求和要求都需要资源、精力和成本，包括开发、审查、管理、实施、设计验证、设计确认、系统验证、系统确认和维护。不必要的需求和要求会导致无价值的工作、额外的成本和不必要的风险。因此，只有必要的需求和由此产生的需求才应包含在需求和要求集中。一旦证明每个需求和要求都是必要的，那么这组需求就必须是商定的生命周期概念的充分解决方案，而要求就必须是这组需求的充分解决方案。需求和要求集共同构成了设计输入，设计输出将根据这些输入进行验证和确认。Realization of every need and requirement requires resources, effort, and cost in the form of development, review, management, implementation, design verification, design validation, system verification, system validation, and maintenance. Unnecessary needs and requirements can lead to non-value-added work, additional cost, and unnecessary risk. Only necessary needs and the resulting requirements should therefore be included in the need and requirement sets. Once each need and requirement is proven to be necessary, the set of needs must then be a sufficient solution for the agreed-to lifecycle concepts and requirements must then be a sufficient solution to the set of needs. Together, the sets of needs and requirements form the design inputs to which the design outputs will be verified and validated against.

指导意见 Guidance:

不存在所谓的“自我衍生”需求或要求！需求必须追溯到生命周期概念、驱动因素或约束、系统需求、使命陈述、目标、目的、风险、交易研究或利益相关者期望，这些是在 NRM 和 GtNR 中讨论的生命周期概念和需求定义活动中定义的。There is no such thing as a “self-derived” need or requirement! A need must be traced to a lifecycle concept, driver or constraint, system need, or mission statement, goal, objective, risk, trade study or stakeholder expectation defined during lifecycle concept and needs definition activities discussed in the NRM and GtNR.

必须将需求追溯到某个需求、父级或来源，这些需求、父级或来源可以是一个或多个需求或更高级别的分配的父级需求）、生命周期概念、驱动因素、约束或风险。A requirement must be traced to a need, parent, or source which could be one or more need(s) or higher-level allocated parent requirement(s)), lifecycle concept, driver, constraint, or risk.

如果出现以下情况，则某个需求或要求不是必需的（在需求或要求集中不需要）：A need or requirement is not necessary (not needed in the set of needs or requirements) if:

- 可以删除该需求或要求，而剩余的集合仍将导致满足实体生命周期概念或需求；the need or requirement can be removed, and the remaining set will still result in the entity lifecycle concept or needs being satisfied;

- 通过实施其他需求或要求，可以满足该需求或要求的意图；the intent of the need or requirement will be met by the implementation of other needs or requirements;

- 该需求或要求无法追溯到来源、需求或父要求；或the need or requirement cannot be traced back to a source, need, or parent requirement; or

- 作者无法传达该需求或要求的有效理由（原理）。 the author cannot communicate a valid reason (rationale) for the need or requirement.

一些组织用来限制设计输入需求数量的一种方法是采用“零基”或“最小可行产品 (MVP)”方法。首先仅包括高优先级且对 MVP 至关重要或必不可少的需求和要求。然后，通过根据为实体定义的使命、目标和目的以及驱动因素、约束、风险、生命周期概念和场景审查每项提议的需求和要求，仅添加能增加价值的额外要求。如果需求或要求无法追溯到一个或多个需求、父需求或这些来源之一，则没有必要。为每个需求和要求纳入 NRM 第 15 节中定义的理由和其他属性（例如追溯到来源或父需求）也有助于传达需求或要求的必要性和意图。One approach used by some organizations to limit the number of design input requirements is to take a “zero based” or “minimum viable product (MVP)” approach. Start by only including needs and requirements that are high priority and are critical or essential for an MVP. Then only add additional requirements that add value by reviewing each proposed need and requirement against the mission, goals, and objectives as well as drivers, constraints, risks, lifecycle concepts, and scenarios defined for the entity. If the need or requirement cannot be traced to one or more needs, parent requirement, or one of these sources, it is not necessary. The inclusion of rationale and other attributes defined in the NRM, Section 15, such as trace to source or parent, for each need and requirement also aids in communicating the necessity and intent of the need or requirement.

注意：在根据需求或分配的父项或来源开发子项需求时，子项需求集必须仅限于那些可以证明是必要且足以满足其所追踪到的需求、父项或来源的意图的需求，并且不包括任何不必要的需求。避免镀金和需求与要求蔓延。有关避免镀金的建议，请参阅 NRM 第 4.6.3.4 节和第 6.2.6.3 节，有关管理需求和要求蔓延的建议，请参阅第 14.2.51 节。Caution: When developing child requirements in response to a need or an allocated parent or source, the set of child requirement must be limited to only those that can be proven to be necessary and sufficient to meet the intent of the need, parent, or source to which they are traced and not include any unnecessary requirements. Avoid gold plating and needs and requirements creep. Refer to the NRM, Sections 4.6.3.4 and 6.2.6.3 for advice on avoiding gold plating and Section 14.2.51 on managing needs and requirements creep.

对于以市场为中心的产品开发，许多公司会力求从利益相关者那里获取尽可能多的信息，以帮助定义正在构建的产品。使用需求和要求分析流程，根据需求和要求的普遍性、紧迫性以及满足该需求或要求所实现的价值进行考虑。通过产品管理流程，可以定义一个由具有类似产品需求的利益相关者组成的市场。此时，可以决定在必要时包括哪些需求和要求以满足市场需求。

For market focused product development, many companies will aim to elicit as much information as possible from stakeholders to help define the product being built. A process of needs and requirements analysis is used where they are considered based on their prevalence, urgency, and the value realized by satisfying that need or requirement. Through the process of product management, a market can be defined consisting of stakeholders with similar product needs. At this point, a decision can be made on which needs and requirements to include as necessary to satisfy the market needs.

有助于建立此特征的规则： Rules that help establish this characteristic:

R20 - /唯一性 Singularity/避免目的 AvoidPurpose

R30 - /独特性 Uniqueness/表达一次 ExpressOnce

有助于建立此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A1 - 基本原理 Rationale

A2 - 追溯至父级 Trace to Parent

A3 - 追溯至源头 Trace to Source

A32 –追溯至接口定义 Trace to Interface Definition

A33 - 追溯至相关对等要求 Trace to Dependent Peer Requirements

A34 –优先级 Priority

A35 –关键性或必要性 Criticality or Essentiality

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.1.5 –属性 Attributes;

3.2.1.6 –属性 Attributes;

3.2.2.1 –需求和要求的分析； Analysis From Which Needs and Requirements Are Derived;

4.4.3 –获得利益相关者的同意； Get Stakeholder Agreement;

4.5 –生命周期概念分析和成熟； Lifecycle Concepts Analysis and Maturation;

4.5.3 –使用图表和模型进行分析； User of Diagrams and Models for Analysis;

4.5.7.1 –模型开发、分析和成熟； Model Development, Analysis, and Maturation;

4.6.3.4 –需求可行性和风险； Needs Feasibility and Risk;

4.8 –确定和管理生命周期概念和需求定义输出的基准； Baseline and Manage Lifecycle Concepts and Needs Definition Outputs;

5.1.2 –执行需求验证； Perform Needs Verification;

6.2 –执行设计输入要求定义； Perform Design Input Requirements Definition;

6.2.1 –将需求转化为设计输入要求； Transforming Needs into Design Input Requirements;

6.2.2 –建立可追溯性； Establish Traceability;

6.2.3.6 –接口要求审计； Interface Requirements Audit;

6.2.6.3 –需求可行性和风险； Requirements Feasibility And Risk;

6.3 –确定基准并管理设计输入需求； Baseline and Manage Design Input Requirements;

6.4.7 –使用可追溯性和分配来管理需求； Use of Traceability and Allocation to Manage Requirements;

7.1.2 –执行设计输入需求验证； Perform Design Input Requirement Verification;

7.2.2 –执行设计输入需求验证； Perform Design Inputs Requirement Validation;

14.2.1 –基准需求、需求和规范； Baseline Needs, Requirements, and Specifications;

14.2.7 – 结合分配和可追溯性来管理需求； Combine Allocation and Traceability to Manage Requirements;

定义 Definition:

需求或要求陈述的具体意图和细节量适合于它所指实体的级别（抽象、组织或系统架构的级别）。The specific intent and amount of detail of the need or requirement statement is appropriate to the level (the level of abstraction, organization, or system architecture) of the entity to which it refers.

基本原理 Rationale:

抽象级别是指在需求或要求陈述中所传达的信息的详细程度和具体程度。

Level of abstraction refers to the level of detail and specificity of the information being communicated within a need or requirement statement.

需求的措辞通常以比需求更高的抽象层次来表述。请参阅 R31，Abstraction/SolutionFree 下的示例。The wording of needs is often stated at a higher level of abstraction than is appropriate for a requirement. See the example under R31, Abstraction/SolutionFree.

级别也可以指组织内的级别或架构内的级别——系统、子系统或系统元素。需求和要求可以在组织或系统架构的任何级别上定义；但是，一般来说，需求或要求应在其所指实体的级别上表达。设计输入、设计“什么”要求应说明该实体级别需要说明的内容，而不是“如何”通过设计满足要求。但是，设计输出、构建/编码“如何”要求的目的是向建造者/编码员传达商定的设计，以便它们能够反映实施情况。Levels can also refer to levels within an organization or levels within an architecture – system, subsystems, or system elements. Needs and requirements may be defined at any level of the organization or system architecture; however, as a rule, a need or requirement should be expressed at the level of the entity to which it refers. Design input, design-to “what” requirements should state what needs to be stated for that level of the entity, not “how” the requirement should be met via design. However, design output, build-to/code-to “how” requirements purpose is to communicate to the builders/coders the agreed-to design, so they will reflect implementation.

为了避免混淆，许多组织将设计输出要求称为“规范”，其中通常包括零件清单、图纸、接线图、管道图、标签图和要求、逻辑图、算法、计算机辅助设计 (CAD) 文件或 STL 文件（用于 3D 打印）。就本指南而言，重点是设计输入需求和要求，如图 4 所示。To avoid confusion, many organizations refer to design output requirements as “specifications” that often include parts lists, drawings, wiring diagrams, plumbing diagrams, labeling diagrams and requirements, logic diagrams, algorithms, Computer-aided Design (CAD) files, or STL files (for 3D printing). For the purposes of this Guide, the focus is on design input needs and requirements as shown in Figure 4.

对于实体来说，在错误的层次上表述的需求或要求要么是不正确的，要么可能无法验证，也无法在该层次上得到确认。A need or requirement stated at the wrong level for an entity is either not correct or may not be verifiable nor able to be validated at that level.

有关级别的深入讨论，请参阅 NRM。

Refer to the NRM for an in-depth discussion on levels.

指导意见 Guidance:

有关需求和要求以及它们适用的实体的讨论，请参阅第 1.6 节。有关需求和要求之间的差异，请参阅第 1.7 节。Refer to Section 1.6 for a discussion concerning needs and requirements and the entity to which they apply. Refer to Section 1.7 concerning the differences between needs and requirements.

设计输入需求的详细程度和具体程度不得超过其所陈述实体的级别所需的程度。具体而言，该需求所适用的实体需要与实体所在的组织或架构级别相适应。除非有充分理由，否则需求主语/名词应指代需求所表达级别上的实体（而不是更高或更低）。Design input requirements must not be any more detailed or specific than is necessary for the level of the entity at which they are stated. In particular, the entity for which the requirement applies needs to be appropriate to the level of organization or architecture in which the entity lives. Unless there is a good reason, a requirement subject/noun should refer to the entity at the level the requirement is being expressed (not higher or lower).

设计输入要求避免在给定级别对设计施加不必要的约束。设计输入要求的目标是独立于实现。在某些情况下，陈述实现有充分的理由。当这种情况发生时，必须包括理由，以明确说明为什么需要将特定实现陈述为对设计的约束。The design input requirements avoid placing unnecessary constraints on the design at the given level. The goal for design input requirements is to be implementation independent. There may be cases where there is good rationale for stating implementation. When this happens, the rationale must be included to make it clear why the specific implementation needs to be stated as a constraint to the design.

对于需求，一个有用的问题是“为了什么目的？”或“为什么？”如果需求以实施术语（设计输出）来表达，那么这个问题的答案可能就是真正的需求（设计输入）。A useful question to ask of a requirement is “for what purpose?” or “why?” If the requirement is expressed in implementation terms (design output), the answer to this question may be the real requirement (design input).

应在集成级别上陈述实体的需求和要求，在此级别上将执行系统验证和系统确认以验证实体是否满足该要求。Needs and requirements should be stated for an entity at the level of integration at which system verification and system validation will be performed to verify the entity meets that requirement.

在较高级别实体的要求集中陈述的较低级别实体的要求可能看起来像是实施。在这种情况下，真正的较高级别实体要求可能没有陈述，因此没有正确分配给下一个较低级别实体。在这种情况下，应将要求下移到适当级别的实体要求集，并将缺失的父要求添加到较高级别实体的要求集中。相反，在较低级别实体的要求集中不正确陈述的较高级别实体要求可能会有问题，因为它们可能没有正确分配给架构下一级别的其他实体，导致这些实体的要求缺失。Requirements for lower-level entities stated within the requirements set for a higher-level entity may seem like implementation. I n this case, the real higher-level entity requirement may not be stated and thus not properly allocated to the next lower-level entities. When this is the case, the requirement should be moved down to the appropriate level entity set of requirements and the missing parent requirement added to the higher-level entity’s set of requirements. Conversely, higher level entity requirements stated improperly within a lower-level entity’s set of requirements can be problematic because they may not have been allocated properly to the other entities at the next level of the architecture, resulting in missing requirements for those entities.

如果要求有效但在较低或较高级别的实体中陈述，请确定适当的级别实体并记录该级别实体的要求。If the requirement is valid but stated at a lower or higher-level entity, determine what the appropriate level entity is and document the requirement for that level entity.

一旦编写了下一个级别的实体需求，项目团队就可以进行“调平”练习，这是一种很好的做法，他们查看实体的每个需求并确定它是否处于适当的级别或是否应该移动 下降到较低级别实体的一组要求或上升到较高级别实体的一组要求。It is good practice, once the next level entity requirements are written, for the project team to do a “leveling” exercise, where they look at each requirement for the entity and determine whether or not it is at the appropriate level or should be moved down to a lower-level entity’s set of requirements or moved up to a higher-level entity’s set of requirements.

有助于建立此特征的规则： Rules that help establish this characteristic:

R2 - /准确度 Accuracy/使用主动语态 UseActiveVoice

R3 - /准确度 Accuracy/主语动词 SubjectVerb

R31 - /抽象 Abstraction/解决方案自由 SolutionFree

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

4.5.4 –细节和抽象的层次； Levels of Detail and Abstraction;

4.6.3.2 –适合级别； Appropriate to Level;

4.6.3.4 –需求可行性和风险； Needs Feasibility and Risk;

6.2 –执行设计输入需求定义； Perform Design Input Requirements Definition;

6.2.1 –将需求转化为设计输入需求；Transforming Needs into Design Input Requirements;

6.2.1.4 –适合级别； Appropriate to Level;

6.2.6.3 –需求可行性和风险； Requirements Feasibility and Risk;

6.4.3 –分配 – 需求的向下流动。 Allocation – Flow Down of Requirements.

定义 Definition:

需求陈述必须以清晰的方式书写，以明确利益相关者的意图。需求陈述必须以所有预期利益相关者都只能以一种方式解释需求的方式书写。Need statements must be written such that the stakeholder intent is clear. Requirement statements must be stated such that the requirement can be interpreted in only one way by all the intended stakeholders.

基本原理 Rationale:

需求或要求声明必须符合单一的意图解释。除非双方明确确切的义务，否则很难达成协议。模糊性会导致多种解释，从而可能无法满足利益相关者的期望。A need or requirement statement must lend itself to a single interpretation of intent. An agreement is difficult to enact unless both parties are clear on the exact obligation. Ambiguity leads to multiple interpretations such that the stakeholder expectations may not be met.

编写者、设计者以及在整个生命周期中执行验证和确认活动的人员必须按照“合理人”准则以相同的方式理解需求或要求的意图。歧义会导致对需求或要求的解释与作者的意图不符，从而导致诸如进度延误、预算超支或 SOI 无法通过系统验证而无法用于其预期用途等问题；这可能会导致诉讼和财务损失。The intent of a need or requirement must be understood in the same way by the writer, the designer, and those doing verification and validation activities across the lifecycle following the “reasonable person” guideline. Ambiguity leads to interpretations of a need or requirement not intended by the author leading to problems such schedule slips, budget overruns, or a failure of the SOI to pass system validation and not be accepted for its intended use; which could result in litigation and financial loss.

模糊的需求既不正确，也无法验证。模糊的需求既不可验证（C7），也不正确（C8）。An ambiguous need is not correct nor able to be validated. An ambiguous requirement is not Verifiable (C7) nor Correct (C8).

指导 Guidance:

在撰写需求或要求陈述时，请问是否可以用多种方式进行解释。对于需求，请问是否可以验证，即是否以这样的方式陈述，即可以根据需求陈述的措辞获得证据，证明利益相关者的需求已经得到满足，而无需解释利益相关者的意图或对该意图做出假设。 When writing a need or requirement statement, ask whether it could be interpreted more than one way. For needs, ask whether, it can be validated, i.e., whether it is stated in such a way that evidence can be obtained that the stakeholder need has been met based on the wording of the need statement without having to interpret the stakeholder intent or make assumptions of that intent.

对于一项要求，询问该要求是否可验证，即，是否以这样的方式陈述：可以根据要求的措辞获得证据证明该要求已经得到满足，而无需解释其含义或对其含义做出假设。 For a requirement ask whether the requirement is verifiable, i.e., whether it is stated in such a way that evidence can be obtained that the requirement has been met based on the wording of the requirement without having to interpret the meaning or make assumptions as to the meaning.

通过解决这些问题并应用本指南中的规则，可以减少出现歧义的可能性。 The possibility of ambiguity is reduced by addressing these questions and applying the rules in this Guide.

此外，参与实施需求和由此产生的需求或系统验证和系统确认的各方（利益相关者）参与需求和由此产生的需求的开发、审查和基准化也是有益的。当他们发现需求或要求含糊不清且意图不明确时，他们可以识别问题并建议使用替代的、明确的措辞来表达需求或要求。至少，建议需求或要求所有者带领开发团队和参与系统验证和系统确认的人员对需求或要求集进行演练，以确保理解需求和要求，无论是单个需求还是整体需求。如第 1.8 节所述，此活动称为需求或设计输入要求验证。 Additionally, it is useful for the parties (stakeholders) who are involved in the implementation of the needs and resulting requirements or system verification and system validation to be involved in the development, review, and baseline of the needs and resulting requirements. When they see needs or requirements that are ambiguous and their intent not clear, they can identify the issue and suggest an alternate, unambiguous wording of the need or requirement statement. As a minimum, it is recommended that the need or requirement owner(s) take the development team and those involved in system verification and system validation on a walkthrough of the need or requirement set to ensure that needs and requirements are understood, individually and as a set. As discussed in Section 1.8, this activity is referred to as need or design input requirement validation.

由于语言的限制，完全消除所有歧义可能很困难。在这种情况下，使用属性 A1- 理由来包含上下文信息以更好地理解需求的原因和来源，可以提供对意图的额外洞察，有助于减少歧义。这可能包括支持信息或关于需求如何形成的评论。 Due to the limitations of language, it may prove difficult to completely remove all ambiguity. In this case the use of the attribute, A1- Rationale, to include contextual information to better understand the reason, and source of the requirement may provide additional insight of the intent, helping to reduce ambiguity. This may include supporting information or commentary on how the requirement was formed.

当仅使用文本难以传达复杂需求的意图时，添加图表可能有助于消除歧义。参见 R23。 When text only makes it difficult to communicate the intent of complex requirement, the inclusion of a diagram may help remove the ambiguity. See R23.

可以在 NRM 和 GtVV 中讨论的早期系统验证和设计验证活动中评估单个需求和要求陈述的模糊性。 Ambiguity of individual need and requirement statements can be assessed during early system verification and design verification activities discussed in the NRM and GtVV.

有助于建立此特征的规则： Rules that help establish this characteristic:

R1 - /准确度 Accuracy/句子结构 SentenceStructure

R2 - /准确度 Accuracy/使用主动语态 UseActiveVoice

R3 - /准确度 Accuracy/主谓词 SubjectVerb

R4 - /准确度 Accuracy/使用定义术语 UseDefinedTerms

R5 - /准确度 Accuracy/使用定冠词 UseDefiniteArticles

R6 - /准确度 Accuracy/单位 Units

R7 - /准确度 Accuracy/避免使用模糊术语 AvoidVagueTerms

R8 - /准确度 Accuracy/无逃避条款 NoEscapeClauses

R9 - /准确度 Accuracy/无开放式结尾 NoOpenEnded

R10 - /简洁 Concision/多余的不定式 SuperfluousInfinitives

R11 - /简洁 Concision/单独条款 SeparateClauses

R12 - /无歧义 NonAmbiguity/正确语法 CorrectGrammar

R13 - /无歧义 NonAmbiguity/正确拼写 CorrectSpelling

R14 - /无歧义 NonAmbiguity/正确标点符号 CorrectPunctuation

R15 - /无歧义 NonAmbiguity/逻辑条件 LogicalCondition

R16 - /无歧义 NonAmbiguity/避免 AvoidNot

R17 - /无歧义 NonAmbiguity/倾斜 Oblique

R18 - /单数 Singularity/单句 SingleSentence

R19 - /单数 Singularity/避免组合符 AvoidCombinators

R22 - /单数 Singularity/枚举 Enumeration

R23 - /单数 Singularity/上下文 Context

R24 - /完整性 Completeness/避免代词 AvoidPronouns

R28 - /条件 Conditions/显式列表 ExplicitLists

R32 - /量词 Quantifiers/通用 Universals

R33 - /容差 Tolerance/值范围 ValueRange

R34 - /量化 Quantification/可测量 Measurable

R35 - /量化 Quantification/时间不确定 TemporalIndefinite

R36 - /统一语言 UniformLanguage/使用一致术语 UseConsistentTerms

R37 - /统一语言 UniformLanguage/定义首字母缩略词 DefineAcronyms

有助于建立此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A1 -原理 Rationale

A6 -系统验证或系统确认成功标准 System Verification or System Validation Success Criteria

A8 –系统验证或系统确认方法 System Verification or System Validation Method

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.1.1 –沟通； Communication;

3.2.1.2 –表达能力； Power of Expression;

3.2.1.6 –正式、具有约束力的协议； Formal, Binding Agreement;

4.4.3 –获得利益相关者的同意； Get Stakeholder Agreement;

4.6.3.1 –管理未知数； Managing Unknowns;

4.8 –确定基准并管理生命周期概念和需求定义输出； Baseline and Manage Lifecycle Concepts and Needs Definition Outputs;

5.1.2 –执行需求验证； Perform Needs Verification;

5.2.2 - 执行需求确认； Perform Needs Validation;

6.2.1.5 –管理未知数； Managing Unknowns;

6.3 –确定基准并管理设计输入要求； Baseline and Manage Design Input Requirements;

7.1.2 – 执行设计输入要求验证； Perform Design Input Requirements Verification;

7.2.2 –执行设计输入要求确认； Perform Design Input Requirements Validation;

8.1 –设计定义流程概述， Design Definition Process Overview,

8.2 –早期系统验证和系统确认； Early System Verification and System Validation;

8.4 –设计验证， Design Verification,

14.2.1 –基本需求、要求和规范； Baseline Needs, Requirements, and Specifications;

14.2.4 –管理未知数 Managing Unknowns

定义 Definition:

需求陈述充分描述了满足需求、来源或父需求（从中转化而来）所需的能力、特性、约束或质量因素，而不需要其他信息来理解该需求。The requirement statement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the need, source, or parent requirement from which it was transformed without needing other information to understand the requirement.

基本原理 Rationale:

除非义务完整且不需要进一步解释，否则协议毫无用处。格式良好的要求无需进一步扩展即可实现其意图。例如，接口要求应包括对协议位置的引用，该协议定义了实体需要如何与其接口的实体进行交互（例如，接口控制文档 (ICD) 或数据字典）。此外，基于标准或法规的要求需要包括对其所源自的标准或法规中特定位置的引用。An agreement is not useful unless the obligation is complete and does not need further explanation. A well-formed requirement needs no further amplification to implement its intent. As an example, interface requirements should include a reference to the location of the agreement that defines how the entity needs to interact with the entity to which it interfaces (for example, an Interface Control Document (ICD) or Data Dictionary). Additionally, requirements based on a standard or regulation need to include a reference to the specific location within the standard or regulation from which it was derived.

应该根据每个需求来理解它本身，而不必去理解许多其他需求。Each requirement should be understood in its own right without the overhead of having to understand a number of other requirements.

基线需求声明不应包含待定义 (TBD)、待指定 (TBS) 或待解决 (TBR) 条款。TBx 可用于分析和定义过程中，以指示正在进行的工作，但不应出现在最终需求集中。TBx 指定的解决可能是迭代的，在这种情况下，应该有一个可接受的 TBx 项解决时间范围，由风险和依赖关系决定。如果基线需求集包含 TBx 项的要求，则必须在供应商或供应商协议（例如 SOW）中明确说明谁负责解决这些项目以及何时解决。有关管理未知数的详细讨论，请参阅 NRM 第 14.2.4 节。Baselined requirement statements should not contain To Be Defined (TBD), To Be Specified (TBS), or To Be Resolved (TBR) clauses. TBx can be used during the analysis and definition process to indicate ongoing work but should not be in the final requirement set. Resolution of the TBx designation may be iterative, in which case there should be an acceptable timeframe for the TBx item to be resolved, determined by risks and dependencies. If the baselined set of requirement contains requirements with a TBx item, it must be made clear in supplier or vendor agreements (for example, SOWs) who is responsible to resolve these items and when. Refer to the NRM Section 14.2.4 for a detailed discussion concerning managing unknows.

不完整的需求由于缺少信息（需求未能解决“什么”、“如何好”或“在什么条件下”）而不可验证（C7）或不正确（C8）。An incomplete requirement is not Verifiable (C7) nor Correct (C8) due to missing information (the requirement fails to address either “what”, “how well”, or “under what conditions”.

指导 Guidance:

功能/性能需求必须完整，具有可观察的功能（“什么”）、可衡量的性能（“如何”）和条件陈述（“在什么条件下”，例如触发事件、环境、状态和模式）。由于这些错误或遗漏，此类需求可能不足以满足需求或父需求。To be complete, functional/performance requirements must have observable functions (“what”), measurable performance (“how well”) and a statement of conditions (“under what conditions”, for example, triggering events, environments, states and modes). Such requirements may be insufficient to satisfy the need or parent requirement because of these errors or omissions.

虽然完全理解要求可能需要一些背景信息，但要求陈述本身应该是一个完整的句子，不需要参考其他陈述即可理解其基本形式。但请注意，要求可以参考其他文件（例如，ICD、标准和法规）。在进行这些引用时，请具体到适用的文件部分。仅当标准或法规中的所有要求都适用于您的特定 SOI（这种情况很少见）时，才引用完整的标准或法规。While fully appreciating that a requirement may require some context, the requirement statement itself should be a complete sentence that does not require reference to other statements to be understood in its basic form. Note, however, that a requirement can refer to other documents (for example, ICDs, standards, and regulations). When making these referrals, be specific to the sections of the documents that apply. Refer to a complete standard or regulation only if all the requirements within the standard or regulation apply to your specific SOI (which is a rare occurrence).

注意：在引用标准或法规时，请记住，标准和法规通常是针对与您的 SOI 类似的产品类别（但不一定是您的 SOI 特有的）以更高的抽象级别编写的。直接复制粘贴标准或法规中的要求是错误的。相反，您需要在适当的级别推导特定于您的 SOI 的要求，然后将结果要求追溯到其所来自的标准或法规。另请参阅 NRM 第 6.2、1、2 节，了解有关遵守标准和法规中要求的更详细讨论。Caution: When referring to a standard or regulation, remember that standards and regulations are often written at a higher level of abstraction for a class of products similar to your SOI, but not necessarily your SOI specifically. It is a mistake to just copy and paste a requirement from a standard or regulation. Instead, you will need to derive requirements specific to your SOI at the appropriate level and then trace the resulting requirement(s) to the standard or regulation from which it was derived. Also refer to the NRM Section 6.2,1,2 for a more detailed discussion concerning complying with requirements within standards and regulations.

需求不应通过使用代词来相互指代，对需求的理解也不应假设存在先前或后续需求。当在应用程序或数据库中管理需求时，这一点尤其重要。Requirements should not refer to one another through use of pronouns, nor should the understanding of the requirement assume the existence of a previous or subsequent requirement. This is especially important when requirements are managed within an application or database.

在以某种形式的“文档”包含的一组需求中，每个需求都应该按照其本身的含义来理解，而不必理解需求中传达的上下文或其周围的标题。In a set of requirements contained in some form of “document”, each requirement should be understood in its own right without having to understand the context as communicated in the requirements or headings surrounding it.

通过遵循需求声明的特定模式，需求往往“更完整”，因为这些模式为需求声明应包含的特定信息提供了指导。有关模式的更多信息，请参阅附录 C。By following a specific pattern for a requirement statement, requirements tend to be “more complete”, since these patterns provide guidance for specific information the requirement statement should include. See Appendix C for more information on patterns.

可以在 NRM 和 GtVV 中讨论的早期系统验证和设计验证活动中评估单个需求和要求陈述的完整性。Completeness of individual need and requirement statements can be assessed during early system verification and design verification activities discussed in the NRM and GtVV.

有助于建立此特征的规则： Rules that help establish this characteristic:

R1 - /准确性 Accuracy/句子结构 SentenceStructure

R2 - /准确性 Accuracy/使用主动语态 UseActiveVoice

R6 - /准确性 Accuracy/单位 Units

R7 - /准确性 Accuracy/避免使用模糊术语 AvoidVagueTerms

R9 - /准确性 Accuracy/无开放式 NoOpenEnded

R11 - /简洁性 Concision/单独条款 SeparateClauses

R23 - /单一性 Singularity/上下文 Context

R24 - /完整性 Completeness/避免使用代词 AvoidPronouns

R25 - /完整性 Completeness/使用标题 UseOfHeadings

R27 - /条件 CONDITIONS/明确 EXPLICIT

R33 - /容忍度 Tolerance/值范围 ValueRange

R34 - /量化 Quantification/可测量 Measurable

R35 - /量化 Quantification/时间不确定 TemporalIndefinite

R39 - /统一语言 UniformLanguage/风格指南 StyleGuide

R40 - /模块化 MODULARITY/相关要求 RELATEDREQUIREMENTS

有助于建立此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A12 –使用条件 Condition of Use

A32 - 追踪至接口定义 Trace to Interface Definition

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.1.2 –表达能力； Power Of Expression;

3.2.1.3 –管理需求和要求集； Managing Sets of Needs And Requirements;

3.2.1.6 –正式、具有约束力的协议； Formal, Binding Agreement;

4.4.3 –获得利益相关者的同意； Get Stakeholder Agreement;

4.5 –生命周期概念分析和成熟； Lifecycle Concepts Analysis and Maturation;

4.6.3.1 –管理未知数； Managing Unknowns;

4.8 –确定基准并管理生命周期概念和需求定义输出； Baseline and Manage Lifecycle Concepts and Needs Definition Outputs;

5.1.2 –执行需求验证； Perform Needs Verification;

6.2.1 –将需求转化为设计输入要求； Transforming Needs into Design Input Requirements;

6.2.1.2 –每种类型需求、功能/性能的考虑因素； Considerations For Each Type Of Requirement, Functional/Performance;

6.2.1.5 –管理未知数； Managing Unknowns;

6.2.3.6 –接口要求审计； Interface Requirements Audit;

6.3 – 确定基准并管理设计输入要求； Baseline and Manage Design Input Requirements;

7.1.2 – 执行设计输入需求验证； Perform Design Input Requirements Verification;

7.2.2 –执行设计输入需求验证； Perform Design Input Requirements Validation;

8.1 –设计定义流程概述， Design Definition Process Overview,

8.2 –早期系统验证和系统确认； Early System Verification and System Validation;

8.4 – 设计验证， Design Verification,

14.2.1 – 基线需求、要求和规范； Baseline Needs, Requirements, and Specifications;

14.2.4 – 管理未知数 Managing Unknowns

定义 Definition:

利益相关者的需求或要求声明应该阐明单一的能力、特性、约束或质量因素。The stakeholder need or requirement statement should state a single capability, characteristic, constraint, or quality factor.

基本原理 Rationale:

从生命周期概念到需求的正式转变可以是多对一、一对一或一对多的转变，但是，最终的需求陈述必须分别代表单一的想法、方面或期望。The formal transformation from a lifecycle concept to a need can be a many-to-one, one-to-one or a one-to-many transformation, however, the resultant need statement(s) must each represent a single thought, aspect or expectation.

类似地，从需求、来源或分配的父要求到要求的正式转变可以是多对一、一对一或一对多的转变，因此最终的需求陈述必须分别代表一个想法、方面或期望。Similarly, the formal transformation from a need, source, or allocated parent requirement to a requirement can be a many-to-one, one-to-one, or a one-to-many transformation so the resultant requirement statement(s) must each represent a single thought, aspect or expectation.

与需求和要求定义相关的几个流程活动的有效性，例如分解、派生、分配、可追溯性、验证和确认，取决于能否识别单一陈述。例如，当某项需求涉及单一功能、特性、约束或质量因素时，为该需求定义的系统验证信息可能更加精确。具有多种想法的需求或要求很难分配并追溯到父级或来源。The effectiveness of several process activities associated with needs and requirements definition, such as decomposition, derivation, allocation, traceability, verification, and validation, depends on being able to identify singular statements. For instance, the system verification information defined for a requirement can be far more precise when that requirement addresses a single capability, characteristic, constraint, or quality factor. A need or requirement with multiple thoughts is difficult to allocate and to trace to a parent or source.

非单一需求或要求既不可验证（C7），也不正确（C8）。A nonsingular need or requirement is neither Verifiable (C7) nor Correct (C8).

需求模式是确保奇点的有效方法（参见附录 C）。Requirements patterns are useful ways to ensure singularity (see Appendix C).

指导 Guidance:

将需求或要求陈述限制在一种品质、特性、能力、功能或约束上。了解这些陈述如何符合项目的分配和可追溯性理念。Keep the need or requirement statement limited to one quality, characteristic, capability, function, or constraint. Understand how the statements fit into the allocation and traceability philosophy for the project.

使用项目标准模式来编写需求和要求。Use the project standard patterns for writing needs and requirements.

尽管单个需求或要求应该由单个功能、品质或约束组成，但可能存在需要满足该要求的多个条件。Although a single need or requirement should consist of a single function, quality or constraint, it may have multiple conditions under which the requirement is to be met.

避免使用“和”这个词，R19，当它将多个想法（句子中的短语）联系在一起时，每个想法可能被分配和验证的方式不同。在需求或要求陈述中出现连词“和”应该总是促使作者考虑该陈述是否是单数。Avoid the use of the word “and”, R19, when it ties together multiple thoughts (phrases in the sentence), each of which may be allocated and verified differently. The presence of the conjunction “and” in a need or requirement statement should always prompt the writer to consider whether or not the statement is singular.

使用“和”也有例外。一些组织允许使用“和”来连接两个始终一起分配、跟踪和验证的操作。例如，可能要求将点燃的火柴熄灭并丢弃到容器中。鉴于这两个操作需要始终一起执行（您永远不会只执行一个操作而不执行另一个操作），组织可能允许在单个要求中传达这两个操作。但是，在这种情况下，最好将这两个操作与逻辑“AND”结合起来 - 参见 R15。There are exceptions to the use of “and”. Some organizations allow the use of “and” to join two actions that will always be allocated, traced, and verified together. For example, there may be a requirement for a lit match to be extinguished and disposed into a container. Given that these two actions need to always be performed together (you would never do one action without the other), organizations may allow both actions to be communicated within a single requirement. In that case, however, it would be best to combine the two actions with a logical “AND”—see R15.

有助于建立此特征的规则：Rules that help establish this characteristic:

R9 - /准确性 Accuracy/无开放式结束 NoOpenEnded

R18 - /单一性 Singularity/单句 SingleSentence

R19 - /单一性 Singularity/避免组合符 AvoidCombinators

R20 - /单一性 Singularity/避免目的 AvoidPurpose

R21 - /单一性 Singularity/避免括号 AvoidParentheses

R22 - /单一性 Singularity/枚举 Enumeration

R23 - /单一性 Singularity/上下文 Context

R39 - /统一语言 UniformLanguage/风格指南 StyleGuide

定义 Definition:

该需求或要求可以在实体约束（例如：成本、进度、技术、法律、道德、安全）内以可接受的风险实现。The need or requirement can be realized within entity constraints (for example: cost, schedule, technical, legal, ethical, safety) with acceptable risk.

基本原理 Rationale:

同意承担不可行的需求或要求是毫无意义的。同意无法在可接受的风险和约束条件下实现的需求或要求通常会导致项目成本超支和进度延误。本质上无法实现的需求和要求（例如 100% 可靠性）充其量只是浪费时间，最坏的情况是导致不必要的昂贵解决方案。There is little point in agreeing to an obligation for a need or requirement that is not feasible. Agreeing to a need or requirement that cannot be realized with acceptable risk within constraints often results in project cost overruns and schedule slips. Inherently unachievable needs and requirements, such as 100% reliability, are at best a waste of time, and at worst lead to needlessly expensive solutions.

不可行的需求或要求无法满足，因为An infeasible need or requirement cannot be satisfied because

a. 它违反了物理定律， it breaks the laws of physics,

b. 它违反了适用管辖区的法律或法规， it violates laws or regulations in an applicable jurisdiction,

c. 它与其他要求相冲突且无法同时满足，或 it conflicts with another requirement and cannot be concurrently satisfied, or

d. 由于技术不成熟或与生命周期阶段相关的项目成本和进度的裕度不足，导致项目风险过大。 it leads to excessive program risk because of technical immaturity or inadequate margin with respect to program cost and schedule as a function of lifecycle phase.

不可行的需求或要求既不可验证（C7），也不正确（C8）。

An infeasible need or requirement is neither verifiable (C7) nor correct (C8).

指导 Guidance:

如果与单个系统元素的其他需求或要求（即一组实体需求或要求）一起考虑，则该需求或要求不会在实体的生命周期内造成不可接受的成本、进度或风险影响，则认为该需求或要求是可行的。The need or requirement is considered feasible if, when considered along with other needs or requirements for a single system element (i.e., a set of entity needs or requirements), it does not cause an unacceptable cost, schedule or risk impact during the entity’s lifecycle

可行意味着存在满足需求的可能可行解决方案。如需求和要求的定义所述，要求是从需求转化而来的。考虑到这一点，如果组织尚未定义一组可行的生命周期概念并评估关键技术的成熟度，那么从这些概念得出的需求可能不可行，从这些需求转化而来的要求也不会可行。Feasible implies the existence of a possible feasible solution to satisfying a requirement. As stated in the definitions for needs and requirements, requirements are transformed from needs. With this in mind, if the organization has not defined a feasible set of lifecycle concepts and assessed the maturity of the critical technologies, then the needs derived from those concepts may not be feasible nor will be the requirements transformed from those needs.

因此，在大多数情况下，如果不对需求来源和要求转化的拟议生命周期概念进行基础评估和分析，则很难确定需求或要求是否可行。在将需求纳入集合之前，必须根据驱动因素和约束条件（包括关键技术的成熟度、成本、进度、资源、法规、更高级别的要求和风险）对所选生命周期概念的可行性进行评估。如果在规定的约束条件下不可行且风险可接受，则不应将需求和由此产生的要求纳入集合。这样做会对成本和进度产生负面影响，并可能导致无法满足和验证需求。Therefore, in most cases determining whether the need or requirement is feasible is difficult without an underlying assessment and analysis of the proposed lifecycle concepts from which the needs are derived, and requirements transformed. Before allowing a need into your set, an assessment of the feasibility of the chosen lifecycle concepts must be made in terms of the drivers and constraints including the maturity of critical technologies, cost, schedule, resources, regulations, higher level requirements, and risk. If not feasible within the stated constraints with acceptable risk, the need and resulting requirement should not be included in the set. Doing so can negatively impact cost and schedule and can result in a requirement that will not be met and verified.

评估风险的一个有用工具是使用技术就绪水平 (TRL) 来确定和计算关键技术的成熟度——较低的 TRL 表示项目的风险大于较高的 TRL。如 NRM 中所述，作为风险评估的一部分，在生命周期概念分析和成熟过程中，确定关键技术，评估其 TRL 和进步难度 (AD2)，并制定技术成熟计划，以推进关键技术的成熟度，从而能够及时满足系统开发计划。这些活动对项目来说是一种风险，因此必须密切管理这种风险。A useful tool for assessing risk is the use of Technology Readiness Levels (TRLs) to determine and compute the maturity of a critical technology—a lower TRL represents more risk to the project than a higher TRL. As discussed in the NRM, as part of risk assessment and during lifecycle concept analysis and maturation critical technologies are identified, their TRL and Advancement Degree of Difficulty (AD2) is assessed, and a technology maturation plan is developed that will result in the critical technology maturity to advance such that it will be feasible in time to meet the system development schedule. These activities represent a risk to the project and as such this risk must be managed closely.

其他有用的工具包括建模和原型设计，用于评估个人需求和要求以及需求和要求子集的可行性。这意味着设计团队必须纳入一个综合、多学科、协作的团队，负责生命周期概念和需求定义活动，以评估生命周期概念在功能或概念模型的物理实现方面的可行性，如 NRM 和 GtNR 中所述。Other useful tools include modeling and prototyping to evaluate the feasibility of individual needs and requirements and subsets of needs and requirements. This means that the design team must be included in an integrated, multidiscipline, collaborative team responsible for the lifecycle concept and needs definition activities to assess the feasibility of a lifecycle concept in terms of physical implementation of the functional or conceptual model as discussed in the NRM and GtNR.

在某些情况下，我们可以识别并避免明显不可能或不切实际的需求和要求（见 R26）。当需求或要求存在内部矛盾或违反物理定律时，该需求或要求本质上是不可行的。更常见的是，必须检查与单个实体相关的需求或要求集的可行性，以确保需求集中没有冲突（C12）。In some cases, we can recognize and avoid needs and requirements that are clearly impossible or unrealistic (see R26). The need or requirement is inherently infeasible where the requirement is either internally contradictory or it violates the laws of physics. More often, feasibility must be examined for sets of needs or requirements associated with a single entity to ensure there is no conflict in the set of requirements (C12).

可行性的衡量并不总是容易评估的。可行性的衡量基于在项目约束内成功实施需求的风险程度，除非物理条件（无法完成，期限）或需求冲突。如上所述，TRL 可以成为依赖于关键技术成熟度的需求的有用风险衡量标准。The measurement of feasibility is not always easy to assess. Measurement of feasibility is based on the degree of risk in successfully implementing the requirement within program constraints, unless precluded by physics (cannot be done, period) or requirements conflict. As stated above, TRLs can be a useful measure of risk for requirements dependent on the maturity of an essential technology.

在 NRM 和 GtVV 中讨论的早期系统验证和设计验证活动中，还可以评估单个需求和要求陈述的可行性。Feasibility of individual need and requirement statements can also be assessed during early system verification and design verification activities discussed in the NRM and GtVV.

有助于建立此特征的规则： Rules that help establish this characteristic:

R26 - /现实主义 Realism/避免绝对 AvoidAbsolutes

R33 - /容忍度 Tolerance/价值范围 ValueRange

有助于建立此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A6 - 系统验证或系统成功标准 System Verification or System Success Criteria

A8 - 系统验证或系统确认方法 System Verification or System Validation Method

A26 – 稳定性 Stability/波动性 Volatility

A36 - 风险（实施风险） Risk (of implementation)

A38 - 关键驱动需求或要求（KDN/KDR） Key Driving Need or Requirement (KDN/KDR)

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.1.6 – 正式、具有约束力的协议；Formal, Binding Agreement;

3.2.2.1 – 需求和要求的分析； Analysis From Which Needs And Requirements Are Derived;

4.3.6.2 – 技术成熟度； Technology Maturity;

4.3.7.1 – 风险类别 - 开发风险；Classes of Risk - Development Risk;

4.5 – 生命周期概念分析和成熟度；Lifecycle Concepts Analysis And Maturation;

4.5.1 – 可行性；Feasibility;

4.5.7.4 – 集中精力于可行的架构和设计；Zeroing in on a Feasible Architecture and Design;

4.6.3.1 – 管理未知数；Managing Unknowns;

4.6.3.4 – 需求可行性和风险；Needs Feasibility and Risk;

4.8 – 确定和管理生命周期概念和需求定义输出的基准；Baseline and Manage Lifecycle Concepts and Needs Definition Outputs;

5.2.2 – 执行需求验证；Perform Needs Validation;

6.2.1.5 – 管理未知数；Managing Unknowns;

6.2.6.3 – 要求可行性和风险；Requirements Feasibility and Risk;

6.3 – 确定基准并管理设计输入要求；Baseline and Manage Design Input Requirements;

7.2.2 – 执行设计输入要求验证；Perform Design Input Requirements Validation;

8.1 – 设计定义流程概述，Design Definition Process Overview,

8.2 – 早期系统验证和系统确认；Early System Verification and System Validation;

8.4 – 设计验证，Design Verification,

14.2.1 – 基准需求、要求和规范；Baseline Needs, Requirements, and Specifications;

14.2.4 – 管理未知数；Managing Unknowns

定义 Definition:

需求说明的结构和措辞应当能够使其实现情况得到验证，以满足审批机构的需要。The requirement statement is structured and worded such that its realization can be verified to the approving authority’s satisfaction.

基本原理 Rationale:

除非以允许设计验证或系统验证的方式编写要求，否则无法判断它是否已得到满足以及义务是否已得到履行。Unless a requirement is written in a way that allows design verification or system verification, there is no way to tell if it has been satisfied and that the obligation has been met.

每个需求陈述都必须包含必要的信息，以便可以定义成功标准，并且可以验证 SOI 以确保满足成功标准，即，需求陈述所传达的内容没有任何歧义，并且需求中没有缺失的特征，即，需求是完整的。Each requirement statement must include the necessary information such that success criteria can be defined, and the SOI can be verified such that that success criteria has been met, i.e., there is no ambiguity regarding what the requirement statement communicates and there are no missing characteristics within the requirement, i.e., the requirement is complete.

无法验证的需求可能会导致多个客观观察者（例如，设计人员或测试人员）对该需求做出不同的解读，从而难以验证 SOI 是否满足需求。An unverifiable requirement can result in multiple, objective observers (for example, designers or testers) interpreting the requirement differently making it difficult to verify the SOI meets the requirement.

可验证性是建立以下特征的必要条件：适当（C2）、无歧义（C3）、完整（C4）、独特（C5）、可行（C6）、符合（C9）、一致（C11）和可理解（C13）。因此，应将可验证性作为首要标准和检查其他特征的基础。Verifiability is a necessary condition for establishing the characteristics: Appropriate (C2), Unambiguous (C3), Complete (C4), Singular (C5), Feasible (C6), Conforming (C9), Consistent (C11), and Comprehensible (C13). Therefore, verifiability should be addressed as the initial criterion and a basis for examining these other characteristics.

指导 Guidance:

重要的是不要混淆“需求验证”与“设计验证”或“系统验证”这两个词组，如图 5 所示，并在第 1.7 和 1.8 节中讨论。这个可验证特性与设计和系统验证有关 - 表明设计可以验证，以便在实现时产生满足要求的 SOI，并验证实现的 SOI 是否满足要求。It is important not to confuse the phrase “requirement verification” vs. “design verification” or “system verification” as shown in Figure 5 and discussed in Section 1.7 and 1.8. This characteristic, verifiable, is about design and system verification – showing that the design can be verified such that, when realized, will result in a SOI that meets the requirement and verifying that the realized SOI meets the requirement.

以允许验证设计或系统是否已满足需求的方式编写每个需求声明，这可以通过四种标准验证方法（检查、分析、演示或测试）之一进行。各种需求可以通过不同的方式进行验证，这将影响需求的编写方式。一般来说，要实现可验证，需求应该是可衡量的。（有关整个生命周期内验证和确认的详细讨论，请参阅 NRM 和 GtVV。）Write each requirement statement in a way that allows the design or system to be verified that the requirement has been met by one of the four standard verification methods (inspection, analysis, demonstration, or test). Various kinds of requirements are verifiable in different ways, and this will influence the way the requirement is written. In general, to be verifiable, a requirement should be measurable. (Refer to the NRM and GtVV for a detailed discussion on verification and validation across the lifecycle.)

如果满足以下条件，则认为要求是可验证的：A requirement is considered to be verifiable if:

1. 可以从需求说明中确定验证案例，该说明允许对需求的所有方面进行全面检查，并精确确定所有值（包括公差），从而可以确定成功或失败；a verification case can be determined from the requirement statement that allows for complete examination of all aspects of the requirement and precise determination of all values, including tolerances, such that success or failure can be determined, and
2. 需求内容足以完整定义实际验证活动的预期行为、特征、条件和成功标准。the requirement content is adequate to completely define the expected behavior, characteristics, conditions, and success criteria for the actual verification activity.

可验证性的衡量标准是需求的完整性和质量：它是否包含建立什么、建立得如何、在什么条件下建立所需的所有必要信息，即它是否完整（C4）？The measure of verifiability is the completeness and quality of the requirement: does it contain all the necessary information to establish what, how well, and under what conditions, i.e., is it Complete (C4)?

每个需求都必须包含所有必要的可验证信息——需求的措辞明确（C3）并且对所有观察者或读者都具有相同的含义。Each requirement must have all the necessary information to be verifiable – the wording of the requirement is unambiguous (C3) and will have the same meaning to all observers or readers.

这可以通过使用附录 C 中所述的标准模板来实现 - 另请参阅特性符合 (C9)。This can be facilitated by use of a standard template as described in Appendix C – see also characteristic Conforming (C9).

客户可能会指定“飞机的航程应尽可能长”。这种说法含糊不清且无法验证。这种要求表明需要进行权衡研究以建立可验证的最大航程要求。【注意：这是将需求写成要求的一个很好的例子。虽然“利益相关者需要飞机的航程尽可能长”是需求陈述中可接受的抽象程度，但它不能作为要求。】A customer may specify, “The aircraft’s range shall be as long as possible.” This statement is ambiguous and unverifiable. This type of requirement is a signal that a trade study is needed to establish a verifiable maximum range requirement. [Note: This is a good example of a need written as a requirement. While “The stakeholders need the aircraft’s range to be as long as possible” is an acceptable level of abstraction for a need statement, it is not acceptable as a requirement.]

需求无法验证的最常见原因是：The most usual causes for a requirement not to be verifiable are:

- 没有明确定义正确的功能行为、条件和状态。no clear definition of the correct functional behavior, conditions, and states.

- 在可接受的性能范围内缺乏准确性或可行性。 lack of accuracy or feasibility in the ranges of acceptable performance.

- 使用模糊术语。 use of ambiguous terms.

- 未能定义可行的生命周期概念和相关利益相关者的需求（需求由此转变而来）。failure to define a feasible lifecycle concept and associated stakeholder need from which the requirement was transformed.

- 需求不可行。 the requirement is not feasible.

在编写需求陈述时，使用验证的视角想象自己执行验证活动，并定义需要什么证据来证明需求的意图已经按照成功标准定义得到实现。When writing requirement statements, use a verification point-of-view to imagine yourself performing the verification activity and define what evidence is needed to show that the requirement’s intent has been achieved as defined by the success criteria.

建议在形成需求声明时定义验证成功标准、策略和方法属性。这样做后，需求声明的质量将得到改善，从而实现此特性（可验证）。It is a recommended best practice to define the verification success criteria, strategy, and method attributes when forming the requirement statement. When this is done, the quality of the requirement statement will improve resulting in this characteristic (verifiable).

可以在 NRM 和 GtVV 中讨论的早期系统验证和设计验证活动中评估 SOI 是否能够根据要求进行验证。Whether the SOI will be able to be verified against a requirement can be assessed during early system verification and design verification activities discussed in the NRM and GtVV.

针对需求声明提出的有用问题是：Useful questions to ask of a requirement statement are:

- 我如何知道是否满足了需求？如果需求已正确量化，它将为这个问题提供精确的答案。 How will I know if the requirement has been met? If the requirement has been properly quantified, it will provide a precise answer to this question.

- 所需的强制和理想性能水平是什么？结果可能是提供多个值来描述此需求允许的公差和权衡空间。 What are the mandatory and desirable levels of performance required? The result of this may be that several values are provided describing the tolerance and trade-space allowed for this requirement.

- 需求陈述的内容是否是我想要验证 SOI 的内容？如果不是，则重写需求以说明意图。 Is what the requirement states what I want to verify the SOI against? If not, then rewrite the requirement to state what is intended.

例如，最好验证您是否获得了特定的性能数据，而不是验证系统是否具有提供该数据的传感器。它可能有传感器，但它们是否会产生所需的实际数量和质量的数据？这也是设计输入与设计输出的一个很好的例子。对数据的需求是设计输入，用于获取这些数据的传感器是设计输出。很多时候，当陈述设计输出要求时，没有说明为什么需要设计输出——正确的设计输入。因此，SOI 可能看起来通过了系统验证，但实际上并没有——SOI 是根据错误的要求进行验证的！For example, it is best to verify you obtain specific performance data rather than verifying the system has sensors to provide that data. It may have the sensors, but do they result in the actual quantity and quality of data needed? This is also a good example of design input versus design output. The need for the data is a design input, the sensors used to obtain this data are design outputs. All too often, when a design output requirement is stated there was a failure to state why the design output was needed – the proper design input. Because of this it could seem the SOI passed system verification, but in reality, it did not –the SOI was verified against the wrong requirement!

有助于建立此特征的规则： Rules that help establish this characteristic:

R1 - /准确度 Accuracy/句子结构 SentenceStructure

R2 - /准确度 Accuracy/使用主动语态 UseActiveVoice

R3 - /准确度 Accuracy/主谓词 SubjectVerb

R4 - /准确度 Accuracy/使用定义术语 UseDefinedTerms

R5 - /准确度 Accuracy/使用定冠词 UseDefiniteArticles

R6 - /准确度 Accuracy/单位 Units

R7 - /准确度 Accuracy/避免使用模糊术语 AvoidVagueTerms

R8 - /准确度 Accuracy/无逃避条款 NoEscapeClauses

R9 - /准确度 Accuracy/无开放式 NoOpenEnded

R10 - /简洁 Concision/多余的不定式 SuperfluousInfinitives

R11 - /简洁 Concision/单独条款 SeparateClauses

R12 - /无歧义 NonAmbiguity/正确语法 CorrectGrammar

R13 - /无歧义 NonAmbiguity/正确拼写 CorrectSpelling

R15 - /无歧义 NonAmbiguity/避免 AvoidNot

R16 - /无歧义 NonAmbiguity/避免 AvoidNot

R17 - /无歧义 NonAmbiguity/倾斜 Oblique

R18 - /单一性 Singularity/单句 SingleSentence

R24 - /完整性 Completeness/避免代词 AvoidPronouns

R26 - /现实主义 Realism/避免绝对 AvoidAbsolutes

R27 - /条件 Conditions/明确 Explicit

R28 - /条件 Conditions/明确列表 ExplicitLists

R32 - /量词 Quantifiers/通用 Universals

R33 - /容忍度 Tolerance/值范围 ValueRange

R34 - /量化 Quantification/可测量 Measurable

R35 - /量化 Quantification/时间不确定 TemporalIndefinite

有助于建立此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A6 – 系统验证或系统确认成功标准 System Verification or System Validation Success Criteria

A8 - 系统验证或系统确认方法 System Verification or System Validation Method

A32 - 追踪接口定义 Trace to Interface Definition

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.1.1 – 沟通； Communication;

3.2.1.2 – 表达能力；Power of Expression;

3.2.1.6 – 正式的约束性协议；Formal Binding Agreement;

3.2.1.7 – 系统验证和系统确认； System Verification and System Validation;

3.2.2.5 – 支持模拟；Support Simulations;

4.4.3 – 获得利益相关者的同意；Get Stakeholder Agreement;

4.5 – 生命周期概念分析和成熟；Lifecycle Concepts Analysis and Maturation;

4.6.3.1 – 管理未知数；Managing Unknowns;

6.2 – 执行设计输入需求定义；Perform Design Input Requirements Definition;

6.2.1.2 – 每种需求类型的考虑因素，Considerations For Each Type Of Requirement,

6.2.1.5 – 管理未知数；Managing Unknowns;

6.2.3.6 – 接口需求审计；Interface Requirements Audit;

6.2.5 – 系统验证计划；Plan for System Verification;

7.1.2 – 执行设计输入需求验证；Perform Design Input Requirements Verification;

8.1 – 设计定义流程概述，Design Definition Process Overview,

8.2 – 早期系统验证和系统确认； Early System Verification and System Validation;

8.4 – 设计验证， Design Verification,

14.2.4 – 管理未知数 Managing Unknowns

14.2.9 – 管理系统验证和系统确认。 Managing System Verification and System Validation.

定义 Definition:

需求陈述必须准确表述其所转化的生命周期概念或来源。需求陈述必须准确表述其所转化的需求、来源或父需求。The need statement must be an accurate representation of the lifecycle concept or source from which it was transformed. The requirement statement must be an accurate representation of the need, source, or parent requirement from which it was transformed.

基本原理 Rationale:

需求从以下来源转化而来：生命周期概念、利益相关者期望、驱动因素和约束、目标、目的、风险等，这些定义为 NRM 和 GtNR 中讨论的生命周期概念和需求定义活动的一部分。从这些来源转化而来的需求必须经过验证，以确定转化的准确性。Needs are transformed from a source: lifecycle concept, stakeholder expectation, drivers and constraints, goals, objectives, risks, etc. defined as part of the lifecycle concept and needs definition activities discussed in the NRM and GtNR. The resulting needs transformed from these sources must be validated to determine the accuracy of the transformation.

不正确的需求可能导致需求不能反映生命周期概念或其转化来源，或者不符合其衍生需求、来源或父需求的要求。An incorrect need can result in a need that does not reflect the lifecycle concept or sources from which it was transformed or a requirement that is not compliance with a need, source, or parent requirement from which it was derived.

必须能够验证需求，以确保需求传达正确的信息（例如，值、公差和单位），从而满足需求转换的原有需求。必须能够证明（验证）满足书面需求将满足需求转换的原有需求的意图。

The requirement must be able to be validated to ensure that the requirement communicates the right thing (for example, value, tolerance, and units) such that the need(s) from which the requirement was transformed will be met. It must be able to be shown (validated) that achievement of the requirement, as written, will result in meeting the intent of the need(s) from which it was transformed.

正确意味着“没有错误”，无论是从包含不正确的信息、遗漏所需信息还是避免措辞歧义的角度来看。Correct implies “no errors” both from the perspective of the inclusion of incorrect information, the omission of required information, and avoidance of ambiguous wording.

如果需求或要求不具备以下特征，则它不可能是正确的：必要的（C1）、明确的（C3）、完整的（C4）、可行的（C6）、可验证的（C7）和符合的（C9）。The need or requirement cannot be correct if it does not have the characteristics: Necessary (C1), Unambiguous (C3), Complete (C4), Feasible (C6), Verifiable (C7), and Conforming (C9).

指导 Guidance:

确保需求陈述反映： Ensure the need statement reflects:

- 对概念、利益相关者期望、驱动因素和制约因素、目标、目的、风险等的准确解释，以及其转化的来源； the accurate interpretation of the concept, stakeholder expectation, drivers and constraints, goals, objectives, risks, etc. from which it was transformed;

- 对问题或机会以及潜在目标和目的的准确理解； an accurate understanding of the problem or opportunity and underlying goals and objectives;

- 提取需求的模型或图表，以便需求可以追溯到模型；以及 the model or diagram from which the need was extracted so the need traces to the model; and

- 对转化过程中潜在分析和假设的准确表示。 an accurate representation of the underlying analysis and assumptions that were part of the transformation.

使用定义的开发和管理流程来确保在个体需求以及综合需求背景下转换的准确性。Use a defined development and management process to ensure accuracy of the transformation in the context of the individual need as well as the integrated set of needs.

确保需求陈述反映： Ensure the requirement statement reflects:

- 基于对需求、来源或更高级别需求的准确且明确的解释的分解或推导。decomposition or derivation that is based on an accurate and unambiguous interpretation of the need, source, or higher-level requirement from which it was transformed.

- 提取需求的模型或图表，以便需求可追溯到模型或图表；以及  the model or diagram from which the requirement was extracted so the requirement traces to the model or diagram; and

- 作为转换一部分的底层分析和假设的准确且明确的表示。 an accurate and unambiguous representation of the underlying analysis and assumptions that were part of the transformation.

不正确的信息可能意味着具有错误的：Incorrect information can mean having the wrong:

- 价值观， values,

- 功能， functions,

- 条件，或 conditions, or

- 在需求或要求中确定的其他特征。 other characteristics identified in the need or requirement.

执行 NRM 和 GtNR 中描述的需求和要求验证，以确保在单个需求和要求陈述以及完整的需求和要求集上下文中转换的正确性。Perform the needs and requirements validation described in the NRM and GtNR to ensure correctness of the transformation in the context of the individual need and requirement statements as well as the complete sets of needs and requirements.

在 NRM 和 GtVV 中讨论的早期系统验证和设计验证活动中，还可以评估单个需求和要求陈述的正确性。Correctness of individual need and requirement statements can also be assessed during early system verification and design verification activities discussed in the NRM and GtVV.

有助于建立此特征的规则： Rules that help establish this characteristic:

R1 - /准确性 Accuracy/句子结构 SentenceStructure

R6 - /准确性 Accuracy/单位 Units

R11 - /简洁 Concision/独立条款 SeparateClauses

R12 - /无歧义 NonAmbiguity/正确语法 CorrectGrammar

R14 - /无歧义 NonAmbiguity/正确标点符号 CorrectPunctuation

R16 - /无歧义 NonAmbiguity/避免 AvoidNot

R26 - /现实主义 Realism/避免绝对 AvoidAbsolutes

R27 - /条件 CONDITIONS/明确 EXPLICIT

R32 - /量词 Quantifiers/普遍性 Universals

R33 - /容忍度 Tolerance/值范围 ValueRange

R36 - /统一语言 UniformLanguage/使用一致术语 UseConsistentTerms

有助于确定此特征的属性：（请参阅 NRM 第 15 节。）

Attributes that help establish this characteristic: (Refer to the NRM Section 15.)

A6 – 系统验证或系统确认成功标准 System Verification or System Validation Success Criteria

A8 - 系统验证或系统确认方法 System Verification or System Validation Method

A12 - 使用条件 Condition of Use

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

3.2.2.1 - 分析需求和要求的来源； Analysis from Which Needs and Requirements are derived;

3.2.2.4 – 识别和管理相互依赖关系； Identify and Manage Interdependencies;

4.4.3 – 获得利益相关者的同意； Get Stakeholder Agreement;

4.5 – 生命周期概念分析和成熟； Lifecycle Concepts Analysis and Maturation;

4.5.3 – 使用图表和模型进行分析； User of Diagrams and Models for Analysis;

4.5.7.1 – 模型开发、分析和成熟； Model Development, Analysis, and Maturation;

4.6.3.1 – 管理未知数； Managing Unknowns;

4.8 – 确定和管理生命周期概念和需求定义输出的基准； Baseline and Manage Lifecycle Concepts and Needs Definition Outputs;

5.2.2 – 执行需求验证； Perform Needs Validation;

6.2 - 执行设计输入需求定义； Perform Design Input Requirements Definition;

6.2.1.2 – 每种需求类型的考虑因素， Considerations For Each Type Of Requirement,

6.2.1.5 – 管理未知数； Managing Unknowns;

6.2.3.6 – 接口需求审计； Interface Requirements Audit;

6.2.6.2 – 完整性、正确性和一致性； Completeness, Correctness, and Consistency;

6.3 – 确定基准并管理设计输入需求； Baseline and Manage Design Input Requirements;

6.4.7 – 使用可追溯性和分配来管理需求； Use of Traceability and Allocation to Manage Requirements;

7.2.2 – 执行设计输入需求验证； Perform Design Input Requirements Validation;

8.1 – 设计定义流程概述， Design Definition Process Overview,

8.2 – 早期系统验证和系统确认； Early System Verification and System Validation;

8.4 – 设计验证， Design Verification,

14.2.1 – 基准需求、需求和规范； Baseline Needs, Requirements, and Specifications;

14.2.4 – 管理未知数； Manage Unknowns;

14.2.7 – 结合分配和可追溯性来管理需求。 Combine Allocation and Traceability to Manage Requirements.

定义 Definition:

个人的需求和要求应符合已批准的标准模式和风格指南或编写和管理需求和要求的标准。Individual needs and requirements should conform to an approved standard pattern and style guide or standard for writing and managing needs and requirements.

基本原理 Rationale:

当同一组织内的需求和要求具有相同的外观和感觉时，每个需求和要求声明都更易于编写、理解和审查。此外，当符合已批准的标准时，单个需求和要求声明的质量将得到提高。When needs and requirements within the same organization have the same look and feel, each need and requirement statement is easier to write, understand, and review. Also, when conforming to an approved standard, the quality of the individual need and requirement statement will improve.

符合需求和要求的标准或模板将有助于识别缺失的信息，从而实现完整（C10）、明确（C3）和可验证（C7）的特征。Conforming to standards or templates for needs and requirements will help to identify missing information resulting in the characteristics of complete (C10), unambiguous (C3) and verifiable (C7).

指导 Guidance:

为了使从生命周期概念中得出的需求正式化，最终需求陈述的结构也必须是正式的。例如，所有需求可能都需要根据组织为需求陈述类型定义的特定模式进行结构化：“利益相关者需要 <主语子句> 到 <动作动词子句><宾语子句>，<可选限定子句>。”如果需求集合中包含目标（非强制性），则可以使用以下模式：“利益相关者希望 <主语子句> 到 <动作动词子句><宾语子句>，<可选限定子句>。” For the derivation of a need from a lifecycle concept to be formal, the structure of the resultant need statement must also be formal. For example, all needs may be required to be structured according to a specific pattern defined by the organization for the type of need statement: “The stakeholders need the <subject clause> to <action verb clause> <object clause>, <optional qualifying clause>.” If goals (non-mandatory) are included in the set of needs then the following pattern could be used: “The stakeholders would like the <subject clause> to <action verb clause> <object clause>, <optional qualifying clause>.”

为了使从需求到要求的转换正式化，生成的需求陈述的结构也必须是正式的。例如，所有需求可能都需要按照组织为需求陈述类型定义的特定模式进行结构化：“当<条件条款>时，<主语条款>应<动作动词条款><宾语条款>，<可选限定条款>。”有关需求格式的更多详细信息，请参阅 R1，有关模板和模式使用的更多详细信息，请参阅附录 C。For the transformation from a need to a requirement to be formal, the structure of the resultant requirement statement must also be formal. For example, all requirements may be required to be structured according to a specific pattern defined by the organization for the type of requirement statement: “When <condition clause>, the <subject clause> shall <action verb clause> <object clause>, <optional qualifying clause>.” See R1 for more detail on requirement formats and Appendix C for more detailed information on the use of templates and patterns.

组织必须有明确的标准和流程来开发和管理需求和要求。这些标准和流程必须包括编写格式良好的需求和要求声明的规则、评估需求和要求质量的清单以及需求和要求声明的可行结构模板。例如，所有需求和要求可能都必须具备本指南中包含的特征并按照其中的规则编写。Organizations must have well-defined standards and processes for needs and requirements development and management. These standards and processes must include rules for writing well-formed need and requirement statements, checklists to assess the quality of the needs and requirements, and templates for allowable structures for need and requirement statements. For example, all needs, and requirements may be required to have the characteristics and be written in accordance with the rules contained in this Guide.

在许多情况下，政府、行业和产品都有适用的标准、规范和接口，需要遵守这些标准、规范和接口。在为客户开发需求和要求时，客户可能有自己的流程、标准、检查表和模式。负责编写需求和要求的人员可能需要遵守客户的流程和标准。In many instances, there are applicable government, industry, and product standards, specifications, and interfaces with which compliance is required. When developing needs and requirements for a customer, the customer may have their own process, standards, checklists, and patterns. The people responsible for writing the needs and requirements may need to conform to the customer’s processes and standards.

请参阅 GtNR 或示例指南，以记录组织的标准、流程、清单和工作说明，用于定义生命周期概念、需求和要求。Refer to the GtNR or an example guide for documenting an organization’s standards, processes, checklists, and work instructions for defining lifecycle concepts, needs, and requirements.

有助于建立此特征的规则： Rules that help establish this characteristic:

R1 - /准确性 Accuracy/句子结构 SentenceStructure

R12 - /无歧义 NonAmbiguity/正确语法 CorrectGrammar

R18 - /单一性 Singularity/单个句子 SingleSentence

R30 - /唯一性 Uniqueness/一次表达 ExpressOnce

R36 - /统一语言 UniformLanguage/使用一致术语 UseConsistentTerms

R37 - /统一语言 UniformLanguage/定义首字母缩略词 DefineAcronyms

R38 - /统一语言 UniformLanguage/避免缩写 AvoidAbbreviations

R39 - /统一语言 UniformLanguage/风格指南 StyleGuide

R40 - /模块化 Modularity/相关要求 RelatedRequirements

与此特征相关的活动和概念：（NRM 内的部分）

Activities and concepts associated with this characteristic: (Sections within the NRM)

4.6.2.3 – 组织综合需求集； Organizing the Integrated Set of Needs;

5.1.2 – 进行需求验证； Perform Needs Verification;

6.2.1.1 – 组织设计输入需求集； Organizing Sets of Design Input Requirements;

7.1.2 – 进行设计输入需求验证。 Perform Design Input Requirements Verification.