INCOSE需求编写指南-第4节：需求和要求陈述以及需求和要求集的规则

阐述 Elaboration:

需求和要求陈述的结构必须采用完整的句子形式，最简单的形式是：The structure of needs and requirements statements must be in the form of a complete sentence, the simplest form of which is:

<主题> <动词> <对象>

<subject> <verb> <object>.

主语是必不可少的，因为它是采取动作的实体；动词是必不可少的，因为它是正在执行的动作；而宾语是必不可少的，因为必须清楚哪个实体受到了作用。The subject is essential because it is the entity undertaking the action; the verb is essential because it is the action being performed; and the object is essential because it must be clear as to which entity is being acted upon.

因此，主体和客体通常是实体，而对于要求陈述，动词是第 1 节中所述的“应”。使用“应”可以明确表明所传达的内容是正式的、陈述是要求、陈述具有法律约束力，并且 SOI 将根据要求进行验证。目前，除了文本“应”要求陈述之外，没有其他形式能够满足这些特征。一些组织可能会使用其他动词，例如“必须”、“将”、“应该”或“可以”——无论使用哪种动词，都必须在合同条款和条件的某个地方定义该行动的强制性、合同约束性，以明确该陈述是一项要求。The subject and objects are therefore normally entities and for a requirement statement the verb is “shall” as described in Section 1. Use of “shall” makes it clear that what is being communicated is formal, the statement is a requirement, the statement is legally binding, and the SOI will be verified against the requirement. Currently, no other form, other than textual “shall” requirement statements, have been shown to meet these characteristics. Some organizations may use other verbs such as “must”, “will”, “should”, or “may”—regardless, whichever verb is used, the mandatory, contractually binding nature of the action must be defined somewhere in the terms and conditions of the contract to made clear the statement is a requirement.

扩展<主题> <动词> <对象>形式，需求具有以下一般形式:

Expanding on the <subject> <verb> <object> form, requirements have a general form of

<实体>应为<实体响应><限定语句>，可进一步扩展为

The <entity> shall <entity response> <qualifying statement> which can be further expanded to

<实体>应当<动作动词><对象><可衡量的结果><限定语句>。

The <entity> shall <action verb> <object> <measurable outcome> <qualifying statement>.

就功能/性能要求而言，<动作动词><对象>对被传达为功能/对象对（加热咖啡），并且<可测量结果>是执行该功能的特定性能结果（达到 120 华氏度的温度）。<限定语句>是清楚地传达要求意图所需的附加信息，如下所述。In terms of a function/performance requirement, the <action verb> <object> pair is communicated as a function/object pair (heat coffee) and the <measurable outcome> is a specific performance outcome of performing that function (to a temperature of 120deg F.) The <qualifying statement> is additional information needed to clearly communicate the intent of the requirement as discussed below.

对于涉及两个实体之间交互的需求（接口需求），＜动作动词＞表示交互的类型，＜对象＞是交互中涉及的内容，＜可衡量的结果＞是定义特定交互的指针（例如，接口控制文档）。For a requirement involving an interaction between two entities (interface requirement) the <action verb> indicates the type of interaction, the <object> is what is involved in the interaction, and the <measurable outcome> is a pointer where the specific interaction is defined (e.g., Interface Control Document).

需求陈述具有类似的形式：

Need statements have a similar form:

<利益相关者> 需要 <实体><实体响应>。或

The <stakeholders> need the <entity><entity response>. or

<利益相关者> 需要 <实体><动作动词><对象><结果>。

The <stakeholders> need the <entity><action verb> <object> <outcome>.

对于需求陈述，结果可能处于更高的抽象层次，并不像第 2 节和 R3 中讨论的需求陈述的<可衡量结果>那么具体。For need statements the outcome may be at a higher level of abstraction and not as specific as <measurable outcome> for a requirement statement as discussed in Section 2 and R3.

如果需要一个<限定语句>来清楚地传达对象上动作动词的意图，而该意图没有在需求或要求语句中明确说明，则该需求或要求语句不完整（C4）、可验证（C7）也不正确（C8），除非包含限定语句，例如，与动作动词相关的性能，或指向定义特定交互的位置的指针（即 ICD）。If a <qualifying statement> is needed to clearly communicate the intent of the action verb on the object is not stated explicitly within the need or requirement statement, the need or requirement statement is not Complete (C4) ), Verifiable (C7), nor Correct (C8) unless the qualifying statement is included, .e.g., performance associated with the action verb or for an interface requirement where a pointer to where the specific interaction is defined (i.e., and ICD).

ISO/IEC 29148 规定，功能需求的更完整、典型的句子形式是：ISO/IEC 29148 states that a more-complete, typical sentence form for a functional requirement is:

当<条件子句>时，<主语子句>应当<动作动词子句><宾语子句><可选限定子句>。

When <condition clause>, the <subject clause> shall <action verb clause> <object clause> <optional qualifying clause>.

约定的条件条款有以下几种类型：There are several agreed types of condition clauses:

事件驱动的要求： Event-driven requirements:

当<可选先决条件/触发器>时，<系统名称>应<系统响应>。

When <optional preconditions/trigger>, the <system name> shall <system response>.

当发生<特定事件>时，<系统名称>应<系统响应>。

In the event of <specific event>, the <system name> shall <system response>.

行为驱动的要求：Behavior driven requirements:

如果<可选先决条件/触发器>，则<系统名称>应<系统响应>。

If <optional preconditions/trigger>, then the <system name> shall <system response>.

状态驱动的要求：

State-driven requirements:

当<进入、退出或处于特定状态（或模式）>时，<系统名称>应<系统响应>。

While <entering, exiting or in a specific state (or mode)>, the <system name> shall <system response>.

有关使用子句的更多示例模式，请参阅附录 C。 See Appendix C for additional example patterns using clauses.

如果适用于某项需求或要求的条件未在需求或要求陈述中明确说明，则该需求或要求陈述不完整（C4）、可验证（C7）或不正确（C8），除非包含条件子句。 If a condition that applies to a need or requirement is not stated explicitly within the need or requirement statement, the need or requirement statement is not Complete (C4), Verifiable (C7), nor Correct (C8) unless the condition clause is included.

注意：虽然 IEEE/ISO/IEC 29148 将条件短语放在句首，但有些组织更喜欢将条件短语放在句末。 Note: While IEEE/ISO/IEC 29148 shows the conditional phrase at the beginning of the sentence, some organizations prefer to put the conditional phrase at the end of the sentence.

组织需要在其标准、指南和流程中定义所需的形式，然后在使用的形式上保持一致。只要结果清晰明确，任何形式都是可以接受的。 Organizations need to define the desired form in their standards, guides, and processes and then be consistent in the form being used. As long as the result is clear and unambiguous, either form is acceptable.

另请参阅 R2、R3、R11、R18、R27 和附录 C。 See also R2, R3, R11, R18, R27, and Appendix C.

例子 Examples:

条件示例 Condition examples:

事件驱动的要求 Event-driven requirements:

当飞机发出 Continuous_Ignition（ 连续点火） 指令时，控制系统应开启 Continuous_Ignition。

When Continuous_Ignition is commanded by the Aircraft, the Control_System shall switch on Continuous_Ignition.

一旦探测到火灾，安全系统应打开防火通道门。

In the event of a fire detection, the Security_System shall Unlock the Fire_Escape_Doors.

行为驱动的要求 Behavior driven requirements:

如果设置了 Computed_Airspeed Fault_Flag（计算空速故障标志），则 Control_System 应使用 Modelled_Airspeed（模型空速）。

If the Computed_Airspeed Fault_Flag is set, [then] the Control_System shall use Modelled_Airspeed.

状态驱动的要求 State-driven requirements:

当飞机在飞行时，控制系统应维持发动机燃油流量大于 XX 磅/秒。While the Aircraft is In-flight, the Control_System shall Maintain Engine_Fuel_Flow at greater than XX lbs/sec.

资质举例 Qualification examples:

当处于‘开启’状态时，系统应显示时间，而不会遮挡工作空间。When in the ‘ON’ state, the System shall display the Time, without obscuring the Work_Space.

该规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

C8 - 正确 Correct

C9 - 符合Conforming

详述 Elaboration:

主动语态要求执行动作的实体是句子的主语。这在编写需求和要求时很重要，因为满足要求的责任在于陈述的主语，而不是宾语。如果没有明确标识负责该动作的实体，则不清楚谁或什么应该执行该动作，从而难以验证 SOI 是否符合要求。将实体包括在主语中也有助于确保要求引用与实体名称一致的适当级别（参见 R3）。如果没有明确将实体名称标识为句子的主语，则需求或要求未完成（C4）。

The active voice requires that the entity performing the action is the subject of the sentence. This is important in writing needs and requirements since the onus for satisfying the requirement is on the subject, not the object of the statement. If the entity responsible for the action is not identified explicitly, it is unclear who or what should perform the action making it difficult to verify the SOI meets the requirement. Including the entity in the subject also helps ensure the requirement refers to the appropriate level consistent with the entity name (see R3). If the entity name is not clearly identified as the subject of the sentence, the need or requirement is not Completed (C4).

通常当使用短语“shall be”时，陈述采用被动语态。

Often when the phrase “shall be” is used, the statement is in the passive voice.

示例 Examples:

不可接受：应确认客户的身份。

Unacceptable: The Identity of the Customer shall be confirmed.

[这是不可接受的，因为它没有识别负责确认身份的实体。]

[This is unacceptable because it does not identify the entity that is responsible/accountable for confirming the identity.]

可接受：Accounting_System 应确认 Customer_Identity。

Acceptable: The Accounting_System shall confirm the Customer_Identity.

[请注意，必须在词汇表中定义“ Accounting_System”，“ confirm”和“ Customer_Identity”，因为这些术语有多种可能的解释。]

[Note that” Accounting_System”, “confirm”, and “Customer_Identity” must be defined in the glossary since there are a number of possible interpretations of these terms.]

不可接受：音频应被系统记录。

Unacceptable: The Audio shall be recorded by the System.

[这是不可接受的，因为负责录制音频的实体位于句子末尾而不是开头。]

[This is unacceptable because the entity that is responsible/accountable for recording the audio is at the end of the sentence rather than the beginning.]

不可接受：音频应被录制。

Unacceptable: The Audio shall be recorded.

[这是不可接受的，因为没有说明负责录制音频的实体。]

[This is unacceptable because the entity that is responsible/accountable for recording the audio is not stated.]

可接受：系统应记录Audio_Feed。

Acceptable: The System shall record the Audio_Feed.

[请注意，必须在词汇表中定义“Audio_Feed”，并添加所需的性能和条件条款以使要求完整。]

[Note that “Audio_Feed” must be defined in the glossary and required performance and conditional clauses added for the requirement to be complete.]

该规则所确定的特征 Characteristics that are established by this rule:

C2 - 适当 Appropriate

C3 - 明确Unambiguous

C4 - 完整Complete

C7 - 可验证Verifiable

阐述 Elaboration:

主题 Subject

需求或要求陈述的主题必须与其所指的实体相适应。

The subject of a need or requirement statement must be appropriate to the entity to which it refers.

因此，涉及业务管理级别的需求的形式为“<业务>应...”；

Requirements referring to the business management level therefore have the form “The <business> shall …”;

涉及业务运营级别的需求的形式为“<运营>应...”；

those referring to the business operations level have the form “The < operations> shall …”;

涉及系统级别的需求的形式为“<系统>应...”；

those referring to the system level have the form "The <system> shall …";

涉及子系统级别的需求的形式为“<子系统>应...”；

requirements referring to the subsystem level have the form "The <subsystem> shall ...";

涉及组件级别的需求的形式为“<组件>应...”。

and requirements referring to the component level have the form "The <component> shall ...".

作为一般规则，特定实体的需求和要求陈述集应该仅包含该实体的需求或要求 - 也就是说，一组业务管理要求只包含业务管理需求或要求，一组业务运营要求只包含业务运营需求或要求，一组系统要求只包含适用于集成系统的需求或要求，一组子系统要求只包含适用于该子系统的需求或要求，一组系统元素要求只包含适用于该系统元素的需求或要求。

As a general rule, sets of need and requirement statements for a specific entity should only contain needs or requirements for that entity—that is, a set of business management requirements would contain only business management needs or requirements, a set of business operations requirements would contain only business operations needs or requirements, a set system requirements would contain only needs or requirements that apply to the integrated system, a set subsystem requirements would contain only needs or requirements that apply to that subsystem, a set system element requirements would contain only needs or requirements that apply to that system element.

但是，在某些情况下，较高级别的实体可能希望规定适用于较低级别实体的需求和要求。例如，对于企业来说，强制要求正在开发的新飞机必须使用特定的引擎（可能出于支持原因）可能很重要，在这种情况下，他们可以在业务级别做出声明，引用子系统级别的实体。因此，任何一组实体需求或要求都可以为该实体陈述引用自身的需求或要求，以及较低级别实体的需求或要求适用（如果有充分的理由这样做）。在这种情况下，规定的分配需求或要求被视为对较低级别实体的约束。在这些情况下，较低级别实体将包括实体特定的子需求，并将该子需求追溯到其父级或来源。

In some cases, however, a higher-level entity may wish to be prescribe needs and requirements that apply to a lower-level entity. For example, it may be important for a business to mandate that the new aircraft under development must use a particular engine (perhaps for support reasons) in which case they may make a statement at the business level that refers to an entity at the subsystem level. Therefore, any set of entity needs, or requirements can state for that entity needs or requirements that refer to itself, as well a lower-level entity the need or requirement applies (should there be a good reason to do so). When this is the case, the prescriptive allocated need or requirement is treated as a constraint on the lower-level entity. In these cases, the lower-level entity will then include an entity specific child requirement and trace that child requirement to its parent or source.

因此，无论需求或要求适用于哪个实体，需求或要求陈述的主题都必须适合于它所指的实体。继续我们上面的飞机示例，尽管业务管理级别的许多要求都以“ACME 飞机公司应……”开头，但企业可能希望在业务管理级别声明一项要求，即该组织开发的所有飞机都应使用具有特定特性的发动机。对于特定飞机，将为实现业务管理通用要求意图的适当实体编写子要求。对于专门处理发动机的实体，系统级子要求将以“飞机应……”开头；而在子系统级别，子要求将以“发动机应……”开头，并追溯到系统级父要求，而系统级父要求又将追溯到业务管理级约束作为父级或来源。

Consequently, regardless of the entity to which a need or requirement applies, the subject of a need or requirement statement must be appropriate to the entity to which it refers. To continue our aircraft example above, although many requirements at the business management level will begin with “The ACME Aircraft Company shall …”, the business may therefore wish to state at the business management level a requirement stating that all aircraft developed by the organization shall use an engine with specific characteristics. For a specific aircraft, child requirements will be written for the appropriate entity that implements the intent of the business management generic requirement. For the entity dealing with the engine specifically, the system level child requirement would begin “The Aircraft shall….”; and at the subsystem level the child requirement would begin “The Engine shall …” and trace back to the system level parent requirement, which, in turn, would trace back to the business management level constraint as the parent or source.

动词 Verb

同样，需求或要求陈述的动词必须适合陈述实体的需求或要求的主题。对于需求，“支持”、“处理”、“处理”、“跟踪”、“管理”和“标记”等动词可能合适。但是，对于需求陈述而言，它们太模糊了，因此可能不明确（C3）也不可验证（C7）。例如，在业务管理级别，使用诸如“安全”之类的动词可能是可以接受的，只要它在该级别明确、在较低级别分解并在这些级别可验证即可。

Similarly, the verb of a need or requirement statement must be appropriate to the subject of the need or requirement for the entity it is stated. For needs the verbs such as “support”, “process”, “handle”, “track”, “manage”, and “flag” may be appropriate. However, they are too vague for requirement statements which therefore may not be Unambiguous (C3) nor Verifiable (C7) . At the business management level, for example, the use of a verb such as “safe”, may be acceptable as long as it is unambiguous at that level, decomposed at the lower levels, and is verifiable at those levels.

示例 Examples:

主题示例 Subject examples:

业务管理需求的形式为“<业务>应当...” — 例如，“ACME_Transport 应当...”。

Business management requirements have the form “The <business> shall …”—for example, “ACME_Transport shall …”.

业务运营对人员角色的要求形式为：“<人员角色>应当……”，例如，“生产经理应当……”；“营销经理应当……”。

Business operations requirements on personnel roles have the form: “The <personnel role> shall …”—for example, “The Production_Manager shall …”; “The Marketing_Manager shall …”.

系统级需求的形式为“利益相关者需要系统……”

System level needs have the form “The stakeholders need the system to ……”

系统要求的形式为“<系统>应...”——例如，“飞机应...”

System requirements have the form "The <system> shall ..."—for example, “The Aircraft shall …”

子系统级需求的形式为“利益相关者需要子系统……”

Subsystem level needs have the form “The stakeholders need the subsystem to ……”

子系统需求的形式为“<子系统>应当...”——例如，一旦定义了子系统：“发动机应当...”；“起落架应当...”。

Subsystem requirements have the form "The <subsystem> shall ..." –for example, once the subsystems are defined: “The Engine shall …”; “The Landing_Gear shall …”.

动词示例 Verb examples:

系统级利益相关者需求：“利益相关者需要系统来处理从[其他系统] XYZ 收到的数据。”

System level stakeholder need: “The stakeholders need the system to process data received from [other system] XYZ.”

系统级要求：“系统应[处理]具有[提供数据的其他系统]接口定义XYZ中定义的特征的数据。”

System level requirement: “The system shall [process] data having the characteristics defined in [Other system that supplies the data] Interface Definition XYZ.”

通过分析，可以将动词/功能“处理”分解为“接收”、“存储”、“计算”、“报告”和“显示”等子功能。然后需要决定在哪个级别表述这些子功能。如果任何一个子功能涉及多个子系统，则应在系统级别传达该需求并分配给适用的子系统。如果要由单个子系统实现子功能，则应在子系统级别传达子功能需求并追溯到分解它的父需求。Through analysis, the verb/function “process” could be decomposed into sub functions such as “receive”, “store”, “calculate”, “report”, and “display”. Then a decision needs to be made regarding the level at which these sub functions are to be stated. If more than one subsystem is involved in any one of the sub functions, that requirement should be communicated at the system level and allocated to the applicable subsystems. If a sub function is to be implemented by a single subsystem, then the sub function requirement should be communicated at the subsystem level and traced back to the parent requirement from which it was decomposed.

不可接受的系统要求：“用户应……”

Unacceptable system requirement: “The User shall ……….” [

[这是不可接受的，因为需求应该针对系统，而不是系统的用户或操作员。这种措辞通常是直接从用户故事或由此产生的需求陈述中编写需求的结果，而没有将用例或用户需求转化为系统需求。问，系统必须做什么才能满足用户需求？] [This is unacceptable because the requirement should be on the system, not the user or operator of the system. This wording is often the result of writing requirements directly from user stories or resulting need statements, without doing the transformation of the use case or user need into a system requirement. Ask, what does the system have to do so that the user need can be achieved?]

可接受：“<系统>应当……”

Acceptable: “The <system> shall …….”

该规则所确定的特征 Characteristics that are established by this rule:

C2 - 适当 Appropriate

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C10 - 完整 Complete

C14 - 能够被验证 Able to be Validated

阐述 Elaboration:

大多数语言都包含大量具有多个同义词的单词，每个同义词的含义根据上下文略有不同。在需求和要求陈述中，含义的细微差别很可能会导致歧义，并在整个生命周期的验证和确认活动中造成困难。以某种形式的本体论定义术语，包括词汇表、数据字典或类似的工件，使需求或要求陈述的读者能够准确地知道作者在选择单词时的意思。无论在所有生命周期阶段开发的工作产品、SE 工具或工件是什么，每次使用该词时，术语的含义都应该相同。Most languages are rich with words having several synonyms, each with a subtly different meaning based on context. In need and requirement statements, shades of meaning will most likely lead to ambiguity and to difficulty during verification and validation activities across the lifecycle. Define terms in some form of ontology, including a glossary, data dictionary, or similar artifact that allows the reader of a need or requirement statement to know exactly what the writer meant when the word was chosen. The meaning of a term should be the same every time the word is used no matter the work product, SE tool, or artifact being developed across all lifecycle stages.

应商定一项标准，使词汇表术语的使用在需求和要求文本陈述中可识别；例如，词汇表项可以大写，单个术语中的多个单词可以用下划线连接（例如，“Current_Time”）。这对于一致性至关重要，以避免在没有上下文的情况下使用该词的一般含义。这是本节示例中使用的惯例。应在项目使用的所有 SE 工具中实施和执行此标准，以帮助确保一致性。A standard should be agreed upon to make the use of glossary terms identifiable in the need and requirements text statements; for example, glossary items may be capitalized and multiple words in single terms joined by an underscore (e.g., “Current_Time”). This is essential for consistency to avoid using the word with its general meaning without context. This is the convention used in the examples in this section. This standard should be implemented and enforced within all SE tools used by the project to help ensure consistency.

需求和要求陈述中使用的术语定义必须在整个项目以及所有生命周期活动期间开发的所有 SE 工件中得到同意、记录和一致使用。Definitions of terms used within needs and requirement statements must be agreed to, documented, and used consistently throughout the project and all SE artifacts developed during all lifecycle activities.

对于需要将需求和要求翻译成不同语言的情况，开发一个“翻译矩阵”会很有帮助，其中列出原始语言中的术语以及目标语言中可接受的术语，以便传达原始意图。当多人参与翻译时，使用此矩阵将有助于确保翻译的一致性。For cases where needs and requirements will be translated into a different language, it is helpful to develop a “translation matrix” where terms in the originating language are listed along with the acceptable term to be used in the target language such that the original intent is communicated. The use of this matrix will help ensure consistency in the translations when multiple people are involved in the translations over time.

示例 Examples:

不可接受：系统应显示当前时间。

Unacceptable: The system shall display the current time.

[这是不可接受的，因为它含糊不清——什么是“当前”，在哪个时区，准确度如何，什么格式？]

[This is unacceptable because it is ambiguous--what is “current”, in which time zone, to what degree of accuracy, in what format?]

可接受：系统应以“DD/MM/YYYY”格式显示当前时间。

Acceptable: The system shall display the Current_Time in "DD/MM/YYYY" format.

[请注意，必须在词汇表中从精度、格式、时区和单位方面定义“Current_Time”。] [Note that “Current_Time” must then be defined in the glossary in terms of accuracy, format, time zone, and units.]

该规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C11 - 一致 Consistent

C13 - 可理解 Comprehensible

C14 - 能够被验证 Able to be Validated

阐述 Elaboration:

定冠词是“the”；不定冠词是“a”。在指代实体时，使用不定冠词会导致歧义。例如，如果需求或要求指的是“用户”，则不清楚它是指任何用户还是系统设计时所定义的用户之一。这会在整个生命周期的验证和确认活动中造成进一步的混乱——例如，婴儿可以说是婴儿食品的用户，但如果测试机构试图验证或确认婴儿可以订购、接收、打开和提供（甚至独立食用）婴儿食品，则系统将失败。另一方面，如果要求指的是“用户”，则明确指的是词汇表中定义的用户性质——在婴儿食品示例中，“用户”可能是负责喂养婴儿的成年人。The definite article is “the”; the indefinite article is “a.” When referring to entities, use of the indefinite article can lead to ambiguity. For example, if the need or requirement refers to “a user” it is unclear whether it means any user or one of the defined users for which the system has been designed. This causes further confusion during verification and validation activities across the lifecycle—for example, babies are arguably users of baby food, but the system would fail if the test agency sought to verify or validate that a baby could order, receive, open, and serve (or even independently consume) baby food. On the other hand, if the requirement refers to “the User”, the reference is explicitly to the nature of the user defined in the glossary—in the baby food example, the “User” is presumably the adult responsible for feeding the baby.

示例 Examples:

不可接受：系统应提供时间显示。

Unacceptable: The system shall provide a time display.

[这对于需求来说是不可接受的，因为它含糊不清——任何时间显示都可以吗？一次性显示时间是否令人满意？作者的意图很可能是他们希望系统连续显示当前时间，但如果开发人员提供“上午 10:00”的恒定显示（甚至一次性显示任何时间），他们可以争辩说（尽管不合理）他们已经满足了需求；但他们显然无法满足客户的需求和意图。

[This is unacceptable for a requirement because it is ambiguous--will any time display do? Is a one-off display of the time satisfactory? The writer's intention was most likely that they wanted the system to display continuously the current time, yet if the developer provided a constant display of “10:00 am” (or even a one-off display of any time), they could argue (albeit unreasonably) that they have met the requirement; yet they would have clearly failed to meet the customer's need and intent.

作为利益相关者需求声明：“利益相关者需要系统提供时间显示。”该声明是可以接受的。作为转换过程的一部分，需求编写者将消除歧义，从而得到以下需求声明。]

As a stakeholder need statement: “The stakeholders need the system to provide a time display.” The statement is acceptable. As part of the transformation process the requirement writers will remove the ambiguity resulting in the following requirement statement.]

可接受：系统应显示当前时间 (Current_Time)。

Acceptable: The system shall display the Current_Time.

[请注意，必须在词汇表中定义“Current_Time”，因为更通用的术语“当前时间”有多种可能的含义和格式。如果词汇表或数据字典中没有提到，可能还有其他要求，涉及时间需要显示的位置、准确性等。]

[Note that “Current_Time” must be defined in the glossary since there are a number of possible meanings and formats of the more-general term “current time.” There may also be other requirements addressing where time needs to be displayed, accuracy, etc. if not addressed in the glossary or data dictionary.]

例外情况和关系 Exceptions and relationships:

这条规则的目的是避免由于“a”或“an”等同于“any one of”而产生的歧义。然而，在某些情况下，使用不定冠词并不会产生误导。例如，“… 准确度小于 1 秒”可以让这个短语读起来更自然，并且不会因为引用的准确度而产生歧义。

The purpose of this rule is to avoid the ambiguity that arises because “a” or “an” is tantamount to saying, “any one of”. In some cases, however, the use of an indefinite article is not misleading. For instance, “… with an accuracy of less than 1 second” allows the phrase to read more naturally and there is no ambiguity because of the accuracy quoted.

该规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

所有数字都应具有明确说明的计量单位，具体说明所使用的测量系统或数字所指的事物。

All numbers should have units of measure explicitly stated in terms of the measurement system used or the thing the number refers.

在项目中，必须始终使用通用的测量系统。例如，不要在项目的任何工件中混合使用美制和公制测量单位。

Within a project, a common measurement system must be used consistently. For example, do not mix both US and metric units of measure within any of the project’s artifacts.

主要有三种测量系统：英制、美国、公制。对于温度，使用以下单位：摄氏度、华氏度或开尔文等。

There are three primary measurement systems: British imperial, US, Metric For temperatures, the following are used: Celsius, Fahrenheit, or Kelvin, etc.

示例 Examples:

不可接受：电路板的温度不得低于 30 度。

Unacceptable: The Circuit_Board shall … a temperature less than 30 degrees.

[这是不可接受的，因为声明中使用的单位没有标明使用的具体测量系统。]

[This is unacceptable because the units used are stated without indicating the specific measurement system used.]

可接受：电路板的温度应低于 30 摄氏度。

Acceptable: The Circuit_Board shall … a temperature of less than 30 degrees Celsius.

不可接受：系统应在 10 秒内与至少 4 个设备建立通信。

Unacceptable: The system shall establish communications with at least 4 in less than or equal to 10 seconds.

[这是不可接受的，因为使用的单位不完整。“4”是什么？]

[This is unacceptable because the units used are incomplete. “4” of what?]

可接受：系统应在小于或等于 10 秒的时间内与至少 4 颗卫星建立通信。

Acceptable: The system shall establish communications with at least 4 satellites in less than or equal to 10 seconds.

[请注意，“通信”一词在业务层面上是可以接受的，但需要在较低层面上进一步阐述，以便分解和验证需求。例如，频率、通信类型（语音？数据？）、质量、带宽等。]

[Note that the term “communications” is acceptable at the business level but would need further elaboration at lower levels so that the requirement is decomposed and verifiable. E.g., frequency, type of communications (voice? data?), quality, bandwidth, etc.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

避免使用提供模糊量化的词语，例如“一些”、“任何”、“允许”、“几个”、“很多”、“很多”、“一些”、“几乎总是”、“非常接近”、“几乎”、“关于”、“接近”、“几乎”和“近似”，

Avoid words that provide vague quantification, such as “some”, “any”, “allowable”, “several”, “many”, “a lot of”, “a few”, “almost always”, “very nearly”, “nearly”, “about”, “close to”, “almost”, and “approximate”,

避免使用模糊的形容词，例如“辅助的”、“相关的”、“常规的”、“常见的”、“通用的”、“重要的”、“灵活的”、“可扩展的”、“典型的”、“足够的”、“适当的”、“高效的”、“有效的”、“熟练的”、“合理的”和“习惯的”。

Avoid vague adjectives such as “ancillary”, "relevant”, “routine”, “common”, “generic”, “significant”, “flexible”, “expandable”, “typical”, “sufficient”, “adequate”, “appropriate”, “efficient”, “effective”, “proficient”, “reasonable” and “customary.”

模糊的形容词可能会导致模棱两可、无法验证的需求，无法准确反映利益相关者的期望。

Vague adjectives can lead to ambiguous, unverifiable requirements that do not reflect accurately the stakeholder expectations.

副词以某种方式限定动作，特别麻烦。避免使用模糊副词，例如“通常”、“大约”、“足够”和“通常”。

Adverbs qualify actions in some way and are particularly troublesome. Avoid vague adverbs, such as “usually”, “approximately”, “sufficiently”, and “typically”.

模糊的副词可能会导致模棱两可、无法验证的要求，不能准确反映利益相关者的期望。

Vague adverbs can lead to ambiguous, unverifiable requirements that do not reflect accurately the stakeholder expectations.

由于没有传达真实意图，需求或要求不完整（C4）。

Because the true intent is not being communicated, the need or requirement is not complete (C4).

一般来说，以“-ly”结尾的单词经常会引起歧义。

As a general rule, words that end in “-ly” often result in ambiguity.

示例 Examples:

不可接受：航班信息系统通常应处于在线状态。

Unacceptable: The Flight_Information_System shall usually be online.

[这是不可接受的，因为“通常”这个词含糊不清——可用性就是其含义吗？]

[This is unacceptable because “usually” is ambiguous - is availability what is meant?]

可接受：飞行信息系统的可用性在超过 yyyy 小时的时间段内应大于 xx%。

Acceptable: The Flight_Information_System shall have an Availability of greater than xx% over a period of greater than yyyy hours.

[请注意，必须在词汇表中定义“可用性”，因为有多种计算该指标的方法。]

[Note that “Availability” must be defined in the glossary since there are a number of possible ways of calculating that measure.]

不可接受：飞行信息系统应显示相关飞机的跟踪信息。

Unacceptable: The Flight_Information_System shall display the Tracking_Information for relevant aircraft.

[这是不可接受的，因为它没有明确说明哪些飞机是相关的。此外，该声明允许开发人员决定什么是相关的；这些决定属于客户的责任，客户应该明确提出要求。]

[This is unacceptable because it does not make explicit which aircraft are relevant. Additionally, the statement allows the developer to decide what is relevant; such decisions are in the province of the customer, who should make the requirement explicit.]

可接受：飞行信息系统应显示距离机场小于或等于 20 公里的每架飞机的跟踪信息。

Acceptable: The Flight_Information_System shall display the Tracking_Information of each Aircraft located less than or equal to 20 kilometers from the Airfield.

[现在很清楚需要显示哪架飞机的信息。请注意，必须在词汇表中定义“飞机”、“跟踪信息”和“机场”。]

[Now it is clear for which aircraft the information needs to be displayed. Note that “Aircraft”, “Tracking_Information”, and “Airfield” must be defined in the glossary.]

例外情况和关系 Exceptions and relationships:

R3 指出，在业务管理或运营层面使用诸如“安全”之类的动词是可以接受的，只要它在那个层面上是明确的，在较低层面上可以分解，并且在所述层面上是可验证的。同样，在业务管理或运营层面使用一些模糊的形容词也是可以允许的，只要它们在该层面上不会引起歧义。

R3 points out that the use of a verb such as “safe”, may be acceptable at the business management or operations level as long as it is unambiguous at that level, decomposed at the lower levels, and is verifiable at the level stated. Similarly, some vague adjectives may be allowable at the business management or operations level, providing they are not ambiguous at that level.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

阐述 Elaboration:

免责条款为较低级别的系统开发人员提供了不实施需求或要求的借口。因此，从合同的角度来看，带有这些短语的需求或要求可以解释为可选的，即使在“必须”要求声明中进行了传达。

Escape clauses give an excuse to the developer of the system at lower levels not to implement a need or requirement. From a contracting standpoint, needs or requirements with these phrases could therefore be interpreted as being optional even if communicated in a “shall” requirement statement.

此类条款提供了模糊的条件或可能性，使用诸如“尽可能”、“尽可能少”、“在可能的情况下”、“尽可能多的”、“如果证明有必要”、“如果有必要”、“在必要的范围内”、“视情况而定”、“按要求”、“在切实可行的范围内”和“如果切实可行的话”等措辞。

Such clauses provide vague conditions or possibilities, using phrases such as “so far as is possible”, “as little as possible”, “where possible”, “as much as possible”, “if it should prove necessary”, “if necessary”, “to the extent necessary”, “as appropriate”, “as required”, “to the extent practical”, and “if practicable.”

免责条款可能会导致模糊的需求，使得 SOI 无法通过验证来满足这些需求，并且可能存在多种解释，也无法准确反映其转变而来的生命周期概念。

Escape clauses can lead to ambiguous needs that the SOI cannot be validated to meet and are open to interpretation and that do not reflect accurately lifecycle concepts from which they were transformed.

免责条款可能会产生模棱两可、无法核实的要求，这些要求可能存在多种解释，也不能准确反映最初产生这些要求的需要。

Escape clauses can lead to ambiguous, unverifiable requirements that are open to interpretation and that do not reflect accurately the needs from which they were transformed.

示例 Examples:

不可接受：如果空间足够，GPS 应显示用户位置。

Unacceptable: The GPS shall, where there is sufficient space, display the User_Location.

[这是不可接受的，因为是否有足够的空间是模糊、不明确且无法验证的。如果没有例外条款，要求会更明确。]

[This is unacceptable because whether there is sufficient space is vague, ambiguous, and unverifiable. The requirement is clearer without the escape clause.]

可接受：GPS 应显示用户位置。

Acceptable: The GPS shall display the User_Location.

[请注意，词汇表中必须定义“GPS”和“用户位置”。还需要定义具体的性能要求，例如在什么时间内、格式和精度。]

[Note that “GPS” and “User_Location” must be defined in the glossary. Specific performance requirements need to be defined as well such as within what time, format, and accuracy.]

不可接受：电视机应在必要的范围内符合 XYZ 标准 a.1 部分的要求。

Unacceptable: The Television shall, to the extent necessary, conform to the requirements in Section a.1 of Standard XYZ.

[这是不可接受的，因为不清楚谁来决定“必要”的含义。如果没有例外条款，要求会更明确。]

[This is unacceptable because it is unclear who is to determine the meaning of ‘necessary’. The requirement is clearer without the escape clause.]

可接受：电视机应符合 XYZ 标准 a.1 部分的要求。

Acceptable: The Television shall conform to the requirements in Section a.1 of Standard XYZ.

[请注意，这种形式的要求意味着必须满足标准 XYZ 的每个要求 - 如果仅需要标准或法规的子集，则必须明确列出该子集，或者实施满足标准和法规中特定要求意图的要求，并追溯到来源或父要求。]有关符合标准和法规要求的更详细讨论，请参阅 NRM 和 GtNR。

[Note that this form of requirement means that each requirement of Standard XYZ is to be met—if only a subset of a standard or regulation is required, that subset must be either listed explicitly or implementing requirements derived that meet the intent of the specific requirements in the standard and regulation, with a trace to the source or parent requirement.] Refer to the NRM and GtNR for a more detailed discussion concerning compliance with requirements within standards and regulations.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

开放式条款暗示要求更多内容，但未明确说明具体内容。避免使用“包括但不限于”、“等”和“等等”等不明确的短语。

Open-ended clauses imply there is more required without stating exactly what. Avoid non specific phrases such as “including but not limited to”, “etc.” and “and so on.”

开放式条款可能会导致模糊、无法验证的需求和要求，不能准确反映利益相关者的期望和需求，并会在读者心中产生歧义。

Open-ended clauses can lead to ambiguous, unverifiable needs and requirements that do not reflect accurately the stakeholder’s expectations and needs and can create ambiguity in the mind of the reader.

使用开放式条款也违反了导致单一特征的单一思想规则 (R18)。如果需要更多情况，则包括明确说明这些情况的其他需求和要求。

Use of open-ended clauses also violates the one-thought rule (R18) that leads to the singular characteristic. If more cases are required, then include additional needs and requirements that explicitly state those cases.

带有开放式条款的需求或要求不完整（C4）

Needs or requirements with open-ended clauses are not Complete (C4)

根据合同类型（固定价格与工作量或成本加成），开放式的需求和要求声明可能会导致有关合同范围内外内容的严重解释问题；可能会导致昂贵的合同变更。

Depending on the contract type (fixed price versus level of effort or cost plus) open-ended needs and requirement statements can lead to serious interpretation problems concerning what is in or out of scope of the contract; possibly resulting in expensive contract changes.

示例 Examples:

不可接受：ATM 应显示客户帐号、账户余额等。

Unacceptable: The ATM shall display the Customer Account_Number, Account_Balance, and so on.

[这是不可接受的，因为它包含要显示内容的打开列表。]

[This is unacceptable because it contains an opened list of what is to be displayed.]

可接受：[分解为尽可能多的需求以使其完整。请注意，需要在词汇表中定义要显示的客户信息类型。]：

Acceptable: [Split into as many requirements as necessary to be complete. Note that the types of customer information to be displayed needs to be defined in the glossary.]:

ATM 应显示客户账户号码。

The ATM shall display the Customer Account_Number.

ATM 应显示客户账户余额。

The ATM shall display the Customer Account_Balance.

ATM 应显示客户账户类型。

The ATM shall display the Customer Account_Type.

ATM 应显示客户账户透支限额。

The ATM shall display the Customer Account_Overdraft_Limit.

[注意：有些人可能觉得项目符号列表或表格是可以接受的。虽然从可读性的角度来看，这可能是正确的，但从需求管理的角度来看，项目符号列表中的每个项目仍然是一项需求。因此，如上例中所示的需求语句应作为单独的语句编写，尤其是当分配、可追溯性、验证和确认活动特定于单个项目时。另请参阅 R17、R18、R22 和 R28。]

[Note: Some may feel that a bulleted list or table is acceptable. While, from a readability perspective, this may be true, from a requirement management perspective, each item in the bulleted list is still a requirement. Because of this requirement statements as in the example above should be written as individual statements especially when allocation, traceability, verification, and validation activities are specific to the single item. See also R17, R18, R22, and R28.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整Complete

C5 - 单一Singular

C7 - 可验证Verifiable

阐述 Elaboration:

我们有时会看到一个需求或要求包含比描述基本动作所需的更多的动词，例如“系统应设计为能够……”或“系统应设计为能够……”而不是简单的“系统应……”提前考虑设计验证和系统验证。如果系统“能够”或“有能力”做某事一次但失败了 99 次，则系统未满足要求。

We sometimes see a need or requirement that contains more verbs than necessary to describe a basic action, such as “The system shall be designed to be able to ...” or “The system shall be designed to be capable of ...” rather than simply “The system shall ...” Think ahead to design verification and system verification. If the system “is able to”, or “is capable of”, doing something one time but fails 99 times, the system has not met the requirement.

请注意，在企业和业务层面，实体“提供能力”的要求是可以接受的。当能力由人员、流程和产品组成时，这些要求将被分解为人员方面（技能组合、培训、角色等）、流程（程序、工作说明等）和产品（硬件和软件系统）。

Note that at the enterprise and business levels, requirements for an entity to “provide a capability” are acceptable. Where capability is made up of people, processes, and products; these requirements will be decomposed to address the people aspects (skill set, training, roles, etc.), processes (procedures, work instructions, etc.); and products (hardware and software systems).

企业和业务级别的父要求将根据情况适当地分配给人员、流程和产品 (SOI)。

The enterprise and business level parent requirements will be allocated appropriately to the people, processes, and products (SOI), as appropriate.

当所得到的需求集在所有三个领域都得到实施时，就会具备满足需求的能力。

When the resulting requirement sets are implemented for all three areas, the capability will exist to meet the need.

系统或系统元素级别的需求也是如此。利益相关者可能需要系统“能够”或“有能力”做某事。例如：“利益相关者需要系统为用户提供 [做某事] 的能力……”。作为从需求到需求的转换过程的一部分，需求编写者将确定系统需要做什么来提供这种能力。然后，生成的格式良好的需求将以明确且可验证的语言定义系统需要做什么来提供这种能力。

This is also true for needs at the system or system element levels. The stakeholders may have a need for the system to “be able to” or “have the capability to” do something. For example: “The stakeholders need the system to provide the capability for users to [do something] ...”. As part of the transformation process from need to requirement, the requirement writer will determine what the system needs to do to provide that capability. The resulting well-formed requirement(s) will then define what the system needs to do to supply that capability in unambiguous and verifiable language.

如果使用“能够”或“有能力”这类措辞的目的是传达系统只需要根据某些条件、触发器或状态执行所需的操作，那么最好将条件、触发器或状态作为要求的一部分进行陈述。在这种情况下，请参阅 R1 和 R11。

If the intent of using “be able to” or “be capable of” type wording is to communicate the system will only need to do the required action based on some condition, trigger, or state, then it is best to state the condition, trigger, or state as part of the requirements. When this is the case, refer to R1 and R11.

示例 Examples:

不可接受：武器子系统应能够存储每枚军械的位置。

Unacceptable: The Weapon_Subsystem shall be able to store the location of each Ordnance.

[这是不可接受的，因为它包含多余的不定式“be able to”。但是，这对于利益相关者的需求是可以接受的：“利益相关者需要 Weapon_Subsystem 能够存储每个军械的位置。”]

[This is unacceptable because it contains the superfluous infinitive “be able to”. However, this is acceptable for the stakeholder need: “The stakeholders need the Weapon_Subsystem to be able to store the location of each Ordnance.”]

可接受：武器子系统应存储每门军械的位置。

Acceptable: The Weapon_Subsystem shall store the Location of each Ordnance.

[请注意，术语“Weapon_Subsystem”、“Location”和“Ordnance”必须在词汇表或数据词典中定义。]

[Note that the terms “Weapon_Subsystem”, “Location”, and “Ordnance” must be defined in the glossary or data dictionary.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

每项需求或要求都应有一个主动词来描述基本功能或需求。如果合适，主句可以补充提供条件或资格（性能值或约束）的从句。对于表达的每个条件或资格，应使用单个、清晰可辨的从句。

Each need or requirement should have a main verb describing a basic function or need. If appropriate, the main sentence may then be supplemented by clauses that provide conditions or qualifications (performance values or constraints). A single, clearly identifiable clause should be used for each condition or qualification expressed.

如果适用于某项需求或要求的条件未在需求或要求陈述中明确说明，则该需求或要求陈述不完整（C4）、可验证（C7）或不正确（C8），除非包含条件子句。

If a condition that applies to a need or requirement is not stated explicitly within the need or requirement statement, the need or requirement statement is not Complete (C4), Verifiable (C7), nor Correct (C8) unless the condition clause is included.

如果在需求或要求陈述中没有明确说明清楚地传达动作动词对对象的意图所需的限定陈述，则需求或要求陈述不完整（C4）、可验证（C7）或不正确（C8），除非包含限定子句，例如与动作动词相关的性能或指向定义特定交互的位置的指针（即 ICD）。

If a qualifying statement that is needed to clearly communicate the intent of the action verb on the object is not stated explicitly within the need or requirement statement, the need or requirement statement is not Complete (C4) ), Verifiable (C7), nor Correct (C8) unless the qualifying clause is included, .e.g., performance associated with the action verb or for an interface requirement where a pointer to where the specific interaction is defined (i.e., and ICD).

使用从句时，确保从句不会将句子的宾语与动词分开。另请参阅 R1、R18、R27 和附录 C，模式。

When using clauses, make sure the clause does not separate the object of the sentence from the verb. See also R1, R18, R27 and Appendix C, Patterns.

示例 Examples:

不可接受：导航信标应在港口进近操纵（HHAM）期间向每个海事用户提供精度小于或等于 20 米的增强数据。

Unacceptable: The Navigation_Beacon shall provide Augmentation_Data at an accuracy of less than or equal to 20 meters to each Maritime_User during Harbor_Harbor_Approach_Maneuvering (HHAM).

[这是不可接受的，因为它插入短语的方式使得句子的宾语与动词分离。]

[This is unacceptable because it inserts a phrase in such a way that the object of the sentence is separated from the verb.]

可接受：导航信标应向每个参与港口进近操纵（HHAM）的海事用户提供增强数据，精度小于或等于 20 米。

Acceptable: The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor_Harbor_Approach_Maneuvering (HHAM), at an accuracy of less than or equal to 20 meters.

[此重写将基本功能放在一个完整的子句中，后面跟着描述性能的子句。]

[This rewrite places the basic function in an unbroken clause followed by the sub-clause describing performance.]

[请注意：“Navigation_Beacon”、“Maritime_User”和“Harbor_Harbor_Approach_Maneuvering (HHAM)”必须在词汇表中定义。]

[Note that: “Navigation_Beacon”, “Maritime_User”, and “Harbor_Harbor_Approach_Maneuvering (HHAM)” must be defined in the glossary.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

我们根据语法规则来解释语言。错误的语法会导致歧义并影响理解。当需求或要求声明的接收者使用第二语言并依赖特定的语法规则时，情况尤其如此。如果不遵循这些规则，该人可能会误解需求或要求声明的含义。

We interpret language based on the rules of grammar. Incorrect grammar leads to ambiguity and clouds understanding. This is especially true when the recipient of the need or requirement statement is working in a second language relying on specific rules of grammar. If these rules are not followed, that person may misinterpret the meaning of the need or requirement statement.

语法使用不当可能会使真实意图不明确，从而导致要求不正确，从而使验证 SOI 是否符合要求的意图变得困难。

Incorrect use of grammar may make the true intent unclear resulting in an incorrect requirement and thus make it difficult to verify the SOI meets the intent of the requirement.

将需求和要求从一种语言翻译成另一种语言时，以及当句子结构因原始需求或要求陈述所用语言而异时，必须小心谨慎。标点符号因语言而异，甚至因给定语言的方言而异。

Care must be taken when translating needs and requirements from one language to another and when sentence structure differs depending on the language in which the original need or requirement statement was written. Punctuation varies from language to language and even between dialects of a given language.

需要翻译需求和要求陈述时要小心谨慎。一个有趣的练习是将需求从一种语言翻译成另一种语言，然后将结果翻译回原始语言。

Be cautious when need and requirement statements must be translated. An interesting exercise is to translate a requirement from one language to another and translate the result back to the original language.

另请参阅 R4 – 定义术语。 See also R4 – Define terms.

示例 Examples:

不可接受：武器子系统应存储所有军械的位置。

Unacceptable: The Weapon_Subsystem shall storing the location of all ordnance.

[这是不可接受的，因为语法错误导致含义不确定。]

[This is unacceptable because the grammatical error leads to uncertainty about the meaning.]

可接受：武器子系统应存储所有军械的位置。

Acceptable: The Weapon_Subsystem shall store the location of all Ordnance.

[请注意，词汇表中必须定义“军械”，以明确武器和弹药的类型。]

[Note that “Ordnance” must be defined in the glossary to be explicit about the types of weapons and ammunition.]

不可接受：处于 Active_State 时，Record_Subsystem 应显示每个 Line_Items 的名称，但不隐藏 User_ID。

Unacceptable: When in the Active_State, the Record_Subsystem shall display each of the Names of the Line_Items, without obscuring the User_ID.

[这是不可接受的，因为语法错误涉及“each of”的不恰当位置——Line_Item 很可能只有一个名称。]

[This is unacceptable because the grammatical error involving the inappropriate placement of “each of”—it is most likely that a Line_Item has only one name.]

可接受：处于 Active_State 时，Record_Subsystem 应显示每个 Line_Item 的名称，而不会隐藏 User_ID。

Acceptable: When in the Active_State, the Record_Subsystem shall display the Name of each Line_Item, without obscuring the User_ID.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C8 - 正确 Correct

C9 - 符合 Conforming

阐述Elaboration:

拼写错误会导致歧义和混淆。有些单词可能发音相同，但根据拼写的不同，含义会完全不同。例如，“red”与“read”或“ordinance”与“ordnance”。在其他情况下，单词可能拼写相同，但含义不同，或者含义会根据使用上下文而变化。例如，“clear windscreen”和“clear the screen”的“clear”有两种不同含义。

Incorrect spelling can lead to ambiguity and confusion. Some words may sound the same but, depending on the spelling, will have entirely different meaning. For example, “red” versus “read” or “ordinance” versus “ordnance.” In other cases, the word could be spelled the same, but have a different meaning or the meaning changes depending on the context of which it is used. For example, "clear windscreen" and "clear the screen” which has the 2 different meanings for "clear".

此外，“sound”一词也可能含糊不清，因为它可以是名词、动词、副词或形容词。在这些情况下，拼写检查器无法区分含义和上下文，因此无法发现此类错误。

In addition, the word “sound” could be ambiguous as it can be a noun, a verb, adverb, or adjective. In these cases, a spell checker cannot distinguish the meaning nor context not finding these kinds of errors.

有拼写错误的需求不正确（C8）并且可能无法验证（C7）。

A requirement that has spelling errors is not correct (C8) and may not be Verifiable (C7).

除了拼写错误之外，此规则还指正确使用：

In addition to misspelling, this rule also refers to the proper use of:

• 缩略词中的大写字母：避免在同一组设计输入要求中使用“SYRD”和“SyRD”。Capital letters in acronyms: avoid “SYRD” and “SyRD” in the same set of design input requirements.

• 其他非首字母缩略词概念中的大写字母：避免在同一组设计输入需求中使用“需求工作组”和“需求工作组”。Capital letters in other non-acronyms concepts: avoid “Requirements Working Group” and “Requirements working group” in the same set of design input requirements.

• 连字符的正确使用：“non- functional”与“non functional”。当两个相关词用作形容词时，通常使用连字符，但用作名词时则不使用连字符。Proper use of hyphenation: “non-functional” versus “nonfunctional.” Often hyphenation is used when two related words are used as adjectives but is not used when used as a noun.

示例 Examples:

Weapon_Subsystem 应存储所有法令的位置。

Unacceptable: The Weapon_Subsystem shall store the location of all ordinance.

[这是不可接受的，因为“法令”一词的意思是法规或法律。Weapon_Subsystem 不太可能对法令（法规）的位置感兴趣。在武器系统的背景下，作者想要使用的应该是“军械”，如武器和弹药，而不是“法令”。]

[This is unacceptable because the word “ordinance” means regulation or law. It is unlikely that the Weapon_Subsystem is interested in the location of ordinance (regulations). In the context of a weapon system, what the authors meant to use is "ordnance" as in weapons and ammunition, not “ordinance”.]

可接受：武器子系统应存储所有军械的位置。

Acceptable: The Weapon_Subsystem shall store the Location of all Ordnance.

[请注意，词汇表中必须定义“位置”和“军械”，以明确武器和弹药的类型。]

[Note that “Location” and “Ordnance” must be defined in the glossary to be explicit about the types of weapons and ammunition.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

不正确的标点符号可能会造成需求或要求陈述中的子句之间的混淆。

Incorrect punctuation can cause confusion between sub-clauses in a need or requirement statement.

标点符号不正确的要求不正确（C8）

A requirement with incorrect punctuation is not Correct (C8)

还要注意，需求或要求陈述中的标点符号越多，出现歧义的可能性就越大。

Note also that the more punctuation in the need or requirement statement, the greater the opportunity for ambiguity.

示例 Examples:

不可接受：导航信标应至少在 99.7% 的时间内以 20 米或更小的精度向每个参与港口进近操纵 (HHA) 的海事用户提供增强数据。

Unacceptable: The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User, engaged in Harbor_Harbor_Approach_Maneuvering (HHA) at an accuracy of 20 meters or less at least 99.7% of the time.

[这是不可接受的，因为这句话中错误放置的逗号混淆了含义，导致读者认为准确性与机动有关，而与增强数据无关。]

[This is unacceptable because the incorrectly placed comma in this sentence confuses the meaning, leading the reader to believe that the accuracy is related to the maneuver rather than to the augmentation data.]

可接受：导航信标应在 99.7% 以上的时间内以小于或等于 20 米的精度向每个参与港口进近操纵 (HHA) 的海事用户提供增强数据。

Acceptable: The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor_Harbor_Approach_Maneuvering (HHA), at an accuracy of less than or equal to 20 meters greater than 99.7% of the time.

[逗号的位置现在可以清楚地表明准确性和可用性与数据相关。]

[The positioning of the comma now makes it clear that the accuracy and availability relate to the data.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C8 - 正确 Correct

阐述 Elaboration:

定义逻辑表达式的约定，例如“[X AND Y]”，“[X OR Y]”，“[X XOR Y]”，“NOT [X OR Y]”。

Define a convention for logical expressions such as “[X AND Y]”, “[X OR Y]”, [X XOR Y]”, “NOT [X OR Y]”.

与其他规则和特征一样，我们希望将需求陈述保持为一个具有单数陈述的想法。因此，当涉及将两个想法联系在一起时，我们避免使用“and”。但是，在谈论动词适用的条件时，可以以逻辑方式使用“AND”、“OR”、“XOR”和“NOT”。所有逻辑表达式都会分解为“真”或“假”，从而产生单数陈述。

As with the other rules and characteristics, we want to keep requirement statements as one thought with singular statements. Thus, we avoid using “and” when it involves tying two thoughts together. However, it is acceptable to use “AND”, “OR”, “XOR”, and “NOT” in a logical sense when talking about conditions to which the verb applies. All logical expressions decompose to either “true” or “false”, resulting in a singular statement.

约定示例： Examples of conventions:

1.  将连词用斜体或全部大写（AND、OR、XOR、NOT）来表明作者希望连词在某种条件中发挥作用。 Place conjunctions in italics or in all capitals (AND, OR, XOR, NOT) to indicate that the author intends the conjunction to play a role in a condition.

2.  将条件放在方括号内，同样使用方括号来控制其范围。例如，“[X AND Y]”。 Place conditions within square brackets, also using the brackets to control their scope. For example, “[X AND Y].”

此外，“和/或”的使用不明确，因此会产生歧义。“和/或”这一表达最常见的解释是包含性或：要么是 X 要么是 Y 要么是两者。如果打算使用包含性或，则应将其写为“至少是 <两个或多个要求> 中的一个”。如果打算使用排他性或，则应将其写为“要么是 <要求 1> 要么是 <要求 2> 但不是两者”，或类似的措辞。

Further, use of “and/or” is non-specific and therefore ambiguous. The most common interpretation of the expression “and/or” is as an inclusive OR: either X OR Y OR both. If an inclusive OR is intended, that should be written as “at least one of <the two or more requirements>”. If an Exclusive OR is intended, that should be written as “Either <Requirement 1> OR <Requirement 2> but NOT both”, or similar wording.

请注意，在设计输入要求中包含逻辑表达式时应谨慎行事。在许多情况下，使用逻辑表达式更适合设计输出规范/要求。输入要求应侧重于为什么需要逻辑操作——防止发生不好的事情，例如，

Note that caution should be used when including logical expressions in design input requirements. In many cases the use of logical expressions is more appropriate to design output specifications/requirements. Input requirements should focus on why the logical actions are needed – prevent something bad from happening, for example,

在设计输入要求中使用逻辑表达式来说明“在什么条件下”适用于某种需求或要求是恰当的。例如，根据逻辑条件是真还是假，必须采取的行动。

The use of logical expressions within design input requirements is appropriate when stating “under what conditions” apply to a need or requirement. For example, an action that must take place based on whether at logical condition is true or false.

另请参阅 R19 和 R20。 Also see R19 and R20.

示例 Examples:

不可接受：当巡航控制接合且驾驶员踩下油门时，发动机管理系统应脱离速度控制子系统。

Unacceptable: The Engine_Management_System shall disengage the Speed_Control_Subsystem when the Cruise_Control is engaged and the Driver applies the Accelerator.

[这是不可接受的，因为“and”的歧义可能会与两个不同的想法的结合相混淆。相反，请使用逻辑表达式 [X AND Y] 的形式。]

[This is unacceptable because of the ambiguity of “and” could be confused with combining two separate thoughts. Instead use the form of a logical expression [X AND Y].]

可接受：当 [巡航控制接合且驾驶员踩下油门] 时，发动机管理系统应脱离速度控制子系统。

Acceptable: The Engine_Management_System shall disengage the Speed_Control_Subsystem, when [the Cruise_Control is engaged AND the Driver applies the Accelerator].

例外情况和关系 Exceptions and relationships:

虽然 R21：/Singularity/AvoidParentheses 规定在一般的句子结构中应避免使用括号或方括号，但该规则表明，在表达逻辑表达式时，可以使用方括号作为惯例的一部分，以避免产生歧义。

While R21: /Singularity/AvoidParentheses states that parentheses or brackets are to be avoided within general sentence structure, this rule suggests that brackets may be used as part of a convention to avoid ambiguity when expressing a logical expression.

本规则所确定的特征 Characteristics that are established by this rule:

C3 – 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

需求或要求陈述中的“不”意味着“永远不”，这在有限的时间内是无法验证的。

The presence of “not” in a need or requirement statement implies “not ever”, which is impossible to verify in a finite time.

在这种情况下，需求或要求陈述是不正确的（C8）。In cases like this, the need or requirement statement is not correct (C8).

重写需求或要求陈述以避免使用“不”会导致需求或要求陈述更清晰且可验证或能够被确认。Rewriting the need or requirement statement to avoid the use of “not” results in a need or requirement statement that is clearer and is verifiable or able to be validated.

示例 Examples:

不可接受：<系统>不得出现故障。 Unacceptable: The <system> shall not fail.

[这是不可接受的，因为验证该要求需要无限的时间。] [This is unacceptable because verification of the requirement would require infinite time.]

可接受：<系统>的可用性应大于或等于 95%。或者 <系统>的平均故障间隔时间 (MTBF) 应为 6 个月。

Acceptable: The <system> shall have an Availability of greater than or equal to 95%. Or The <system> shall have a Mean Time Between Failures (MTBF) of 6 months.

不可接受：<系统>不得含有汞。

Unacceptable: The <system> shall not contain mercury.

[这是不可接受的，因为验证该要求需要能够以无限的准确度和精度测量汞的含量。此外，真正的要求可能没有说明，例如，真正的担忧可能是有毒物质的使用，而不仅仅是汞。如果是这样，最好参考政府机构关于允许接触常见有毒物质的标准。] [This is unacceptable because verification of the requirement would require the ability to measure the amount of mercury with infinite accuracy and precision. In addition, the real requirement may not be stated, for example, the real concern may be the use of toxic materials, not just mercury. If that is the case, it may be best to reference a standard from a governmental agency concerning allowable exposures to a list of common toxic materials.]

可接受：<系统> 应将工人在 8 小时工作日内的金属汞暴露量限制为小于或等于 0.025 mg/m3。

Acceptable: The <system> shall limit metallic mercury exposures to workers to less than or equal 0.025 mg/m3 over an 8-hour workday.

例外情况和关系 Exceptions and relationships:

当隐含逻辑“NOT”时，在要求中包含“not”可能是合理的——例如，当使用 not [X or Y] 时。但是，在这种情况下，根据规则 15，最好将“NOT”大写，以明确逻辑条件：NOT [X or Y]。可能还有其他情况，例如“<系统>不得为红色”。这说明了约束，并且是可验证的，只要说明了红色的色调范围（RBG rr,bb,gg 范围或某​​些标准中的红色“名称”）。

It may be reasonable to include “not” in a requirement when the logical “NOT” is implied—for example when using not [X or Y]. In that case, however, in accordance with Rule 15, it may be better to capitalize the “NOT” to make the logical condition explicit: NOT [X or Y]. There may be other cases such as “The <system> shall not be red in color.” Which is stating a constraint and is verifiable, as long as the range of shades of red is stated (RBG rr,bb,gg range or a “name” of red in some standard).

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

斜线符号（“/”）或“斜线”具有太多可能的含义，因此应避免使用。斜线符号（例如，“用户/操作员”、“预算/计划”或 R15 中讨论的“和/或”结构）可能导致模糊的需求和要求陈述，无法准确反映真正的客户需求或衍生这些需求的生命周期概念。

The oblique symbol (“/”), or “slash”, has so many possible meanings that it should be avoided. The slash symbol (e.g., “user/operator”, “budget/schedule” or the construct “and/or” discussed in R15) can lead to ambiguous need and requirement statements that do not reflect accurately the true customer needs or lifecycle concepts from which the needs were derived.

此规则的一个例外是，在 SI 单位中使用斜符号（例如“km/h”）或传达值的对称范围（例如 +/- 5 华氏度）时。

An exception to this rule is where the oblique symbol is used in SI units (for example “km/h”) or when communicating a symmetrical range of a value (for example +/- 5 degrees F.)

另请参阅R19。 Also see R19.

示例 Examples:

不可接受：用户管理系统应在 1 秒内打开/关闭用户帐户。 Unacceptable: The User_Management_System shall Open/Close the User_Account in less than 1 second.

[这是不可接受的，因为其含义不明确：打开、关闭，还是两者兼而有之？] [This is unacceptable because it is unclear as to what is meant: open, close, or both?]

可接受：（分为两个要求） Acceptable: (Split into two requirements)

用户管理系统应在1秒内打开用户帐户。 The User_Management_System shall Open the User_Account in less than 1 second.

用户管理系统应在 1 秒内关闭用户帐户。 The User_Management_System shall Close the User_Account in less than 1 second.

不可接受：当离合器分离和/或驾驶员踩下制动器时，发动机管理系统应分离速度控制子系统。 Unacceptable: The Engine_Management_System shall disengage the Speed_Control_Subsystem when the Clutch is disengaged and/or the Driver applies the Brake.

[由于使用了“和/或”，因此这是不可接受的。如果表示“和”，则将两个想法拆分为单独的要求。如果表示“或”，则将要求写为排他性的“或”。]  [This is unacceptable because of the use of “and/or.” If “and” is meant, split the two thoughts into separate requirements. If “or” is meant, write the requirement as an exclusive “or.”]

可接受：（分为两个要求） Acceptable: (Split into two requirements)

当离合器分离时，发动机管理系统应分离速度控制子系统。 The Engine_Management_System shall disengage the Speed_Control_Subsystem when the Clutch is disengaged.

当驾驶员踩下刹车时，发动机管理系统应脱离速度控制子系统。 The Engine_Management_System shall disengage the Speed_Control_Subsystem when the Driver is applying the Brake.

可接受：（如果是排他性的或有意为之，则可作为一项要求） Acceptable: (as one requirement if exclusive or is intended)

当 [离合器分离或驾驶员踩下制动器] 时，发动机管理系统应分离速度控制子系统。The Engine_Management_System shall disengage the Speed_Control_Subsystem when [the Clutch is disengaged OR the Driver is applying the Brake].

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

基于分配、可追溯性、确认和验证的概念，需求和要求陈述必须包含一个单一思想，允许需求追溯到它们的来源，并允许在需求陈述中分配单一思想，由此产生的单一思想子要求追溯到它们分配的父级，要求追溯到单一思想来源，并允许针对单一思想需求或要求进行设计和系统确认以及设计和系统验证。Based on the concepts of allocation, traceability, validation, and verification, need and requirement statements must contain a single thought allowing needs to be traced to their source and the single thought within a requirement statement to be allocated, the resulting single thought child requirements to trace to their allocated parent, requirements to trace to a single thought source, and allowing design and system validation and design and system verification against the single thought need or requirement.

有时，需求或要求陈述仅在特定条件或多种条件下适用。参见 R1、R11 和 R27。Sometimes a need or requirement statement is only applicable under a specific condition or multiple conditions. See R1, R11, and R27.

如果单个条件需要多个操作，则应在单独的需求或要求声明的文本中重复每个操作以及触发条件，而不是陈述条件然后列出要采取的多个操作。使用此约定，可以验证系统是否执行每个操作，并将每个操作分别分配给架构下一级的实体。If multiple actions are needed for a single condition, each action should be repeated in the text of a separate need or requirement statement along with the triggering condition, rather than stating the condition and then listing the multiple actions to be taken. Using this convention, the system can be verified to perform each action and each action be separately allocated to the entities at the next level of the architecture.

另外，避免在单独的句子中陈述动作的条件或触发因素。相反，请写一个简单的肯定陈述句，其中包含一个主语、一个主要动作动词和一个宾语，并由一个或多个子句构成和限定。Also avoid stating the condition or trigger for an action in a separate sentence. Instead write a simple affirmative declarative sentence with a single subject, a single main action verb and a single object, framed and qualified by one or more sub-clauses.

应避免使用包含多个主语/动词/宾语的复合句。Compound sentences are to be avoided that contain more than subject/verb/object.

通常，当一个要求有多个句子时，作者会使用第二个句子来传达第一个句子的使用条件或要求的理由。这种做法是不可接受的 - 而是将此信息包含在属性 A1 - 理由中，作为 NRM 中讨论的要求表达的一部分，并在需求或要求声明中包含使用条件。Often when there are multiple sentences for one requirement, the writer is using the second sentence to communicate the conditions for use or rationale for the requirement for the first sentence. This practice is not acceptable – rather include this information in the attribute A1 - Rationale as part of the requirement expression as discussed in the NRM and include the condition of use within the need or requirement statement.

See also R1, R11, R22.

示例 Examples:

不可接受：当处于 Active_State 时，Record_Subsystem 应显示每个 Line_Item 的名称并记录每个 Line_Item 的位置，而不会隐藏 User_ID。

Unacceptable: When in the Active_State, the Record_Subsystem shall display the Name of each Line_Item and shall record the Location of each Line_Item, without obscuring the User_ID.

[这是不可接受的，因为该句子包含两个要求，并且资格仅适用于第一个要求，而不适用于第二个要求。]  [This is unacceptable because the sentence contains two requirements and the qualification only applies to the first requirement, not the second.]

可接受：（分为两个单独的要求） Acceptable: (Split into two separate requirements)

当处于 Active_State 时，Record_Subsystem 应显示每个 Line_Item 的名称，而不会隐藏 User_ID。 When in the Active_State, the Record_Subsystem shall display the Name of each Line_Item, without obscuring the User_ID.

当处于Active_State时，Record_Subsystem应记录每个Line_Item的位置。 When in the Active_ State, the Record_Subsystem shall record the Location of each Line_Item.

[请注意使用词汇表来定义术语。]  [Note use of the glossary to define terms.]

不可接受：控制子系统将关闭入口阀门，直至温度降至 85°C 时，再重新打开它。Unacceptable: The Control_Subsystem will close the Inlet_Valve until the temperature has reduced to 85 °C, when it will reopen it.

[这是不可接受的，因为该句子包含两个事件驱动要求。此外，该句子包含两次代词“it”，含糊地指代不同的事物（参见 R26），“has Reduce”一词含糊不清，动作动词必须是“shall”，而不是“will”。]  [This is unacceptable because the sentence contains two event driven requirements. Additionally, the sentence contains two occurrences of the pronoun “it” ambiguously referring to different things (see R26), the term 'has reduced' is ambiguous, and the action verb must be 'shall', not 'will'.]

可接受：（分为两个要求） Acceptable: (Split into two requirements)

如果锅炉中的水温高于 85°C，则控制子系统应在 3 秒内关闭入口阀门。 If the temperature of water in the Boiler is greater than 85 °C, the Control_Subsystem shall close the Inlet_Valve in less than 3 seconds

当锅炉中的水温降至小于或等于 85°C 时，控制子系统应在 3 秒内打开入口阀门。When the temperature of water in the Boiler is reduced to less than or equal to 85 °C., the Control_Subsystem shall open the Inlet_Valve in less than 3 seconds.

[请注意使用词汇表来定义术语。]  [Note use of the glossary to define terms.]

不可接受： Unacceptable:

如果探测到火灾： In the event of a fire detection:

• 应关闭电磁防火门锁的电源。 Power to electromagnetic magnetic fire door catches shall be turned off.

• 安全入口应设置为自由出入模式。 Security entrances shall be set to Free_Access_Mode.

• 防火通道门必须处于未锁状态。 Fire escape doors shall be unlocked.

[这是不可接受的，因为“在检测到火灾的情况下”的条件是在要采取的一系列行动之后陈述的；系统必须针对每一项行动进行验证。另外，请注意，这些行动是以被动语态写的，这违反了 R2。每个行动都需要在单独的要求声明中传达。有关单个行动的多个条件，请参阅 R28。]  [This is unacceptable because the condition “in the event of a fire detection” is stated following a list of actions to be taken; each of which the system must be verified against. Also, note the actions are written in passive voice which violates R2. Each action needs to be communicated in a separate requirement statement. For multiple conditions for a single action see R28.]

可接受：（分为三个要求） Acceptable: (Split into three requirements)

一旦探测到火灾，安全系统应切断电磁防火门锁的电源。 In the event of a fire detection, the Security_System shall turn off power to electromagnetic magnetic fire door catches.

一旦探测到火灾，安全系统应将安全入口设置为自由访问模式。 In the event of a fire detection, the Security_System shall set security entrances to the Free_Access_Mode.

一旦探测到火灾，安全系统应解锁消防通道门。 In the event of a fire detection, the Security_System shall unlock fire escape doors.

例外情况和关系 Exceptions and relationships:

每项要求都应有一个带主动词 (R1) 的主句。但是，可以使用带助动词或副词的附加子句来限定具有性能属性的要求。 Every requirement should have a main clause with a main verb (R1). However, additional sub clauses with auxiliary verbs or adverbs may be used to qualify the requirement with performance attributes.

此类子条款不能孤立地进行验证，因为如果没有主条款，它们是无法理解的。需要与其他条款分开验证的子条款应表述为单独的要求。 Such sub-clauses cannot be verified in isolation since they are incomprehensible without the main clause. Sub-clauses that need to be verified separately from others should be expressed as separate requirements.

例如，“救护车控制系统应将事件详情传达给司机”是一个完整、易懂的语句，只有一个主要动词。可以添加一个辅助子句来提供约束“救护车控制系统应将事件详情传达给司机，同时与呼叫者保持通信。” For example, “The Ambulance_Control_System shall communicate Incident_Details to the Driver” is a complete, comprehensible statement with a single main verb. An auxiliary clause may be added to provide a constraint “The Ambulance_Control_System shall communicate Incident_Details to the Driver while simultaneously maintaining communication with the Caller.”

类似地，如果要求将熄灭和处理火柴作为单一组合行动，则该要求必须确保两者同时进行验证并分配相同的时间。 Similarly, if the requirement is to extinguish and dispose of a match as a single combined action, the requirement must ensure that both are verified the same time and allocated the same.

请注意，如果性能属性需要单独验证，则应将其表达为单独要求中的子条款。 Note that, if performance attributes need to be verified separately, they should be expressed as sub-clauses in separate requirements.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C5 - 单一 Singular

C7 - 可验证 Verifiable

C9 - 符合 Conforming

C13 - 可理解 Comprehensible

阐述 Elaboration:

组合词是连接子句的词，例如“and”、“or”、“then”、“unless”、“but”、“as well as”、“but also”、“however”、“whether”、“meanwhile”、“whereas”、“on the other hand”或“otherwise”。它们出现在需求中通常表示应该编写多个需求。 Combinators are words that join clauses, such as “and”, “or”, “then”, “unless”, “but”, “as well as” “but also”, “however”, “whether”, “meanwhile”, “whereas”, “on the other hand”, or “otherwise.” Their presence in a requirement usually indicates that multiple requirements should be written.

例外：AND、OR、NOT 可以在需要和要求陈述中用作逻辑条件和限定符，如 R15 中所述。 Exception: AND, OR, NOT can be used in need and requirement statements as logical conditions and qualifiers as stated in R15.

另请参阅 R16 和 R17。 See also R16 and R17.

示例 Examples:

不可接受：用户要么值得信任，要么不值得信任。

Unacceptable: The user shall either be trusted or not trusted.

[出于多种原因，这是不可接受的。其意图是应以两种方式之一对用户进行分类，但这也是针对用户而不是针对系统的被动要求 (R2)，并且含糊不清：如果系统选择将所有用户视为可信用户，则仍会满足该要求。]  [This is unacceptable for several reasons. The intention is that a user should be classified in one of two ways, but it is also a passive requirement written on the user rather than on the system (R2) and it is ambiguous: the requirement would still be met if the system took the option of treating all users as trusted.]

可接受：安全系统应将每个用户分类为[可信或不可信]。

Acceptable: The Security_System shall categorize each User as [EITHER Trusted OR Not_Trusted).

不可接受：“控制侧灯”功能应确保在侧灯、前照灯、雾灯、后雾灯或这些灯的组合亮起期间保持侧灯的照度，从而确保灯光照明符合规定的一致性。

Unacceptable: The “command the sidelights” function shall ensure the regulatory consistency of lights illumination by ensuring the illumination of sidelights is maintained during the illumination of the side lamps, or the head lights, or the fog lights or the rear fog lights or a combination of these lights.

[再次强调，这是不可接受的，因为它是非单数的、使用了可疑的语法、包含目的元素、并且总体上令人困惑。]  [Again, this is unacceptable because it is non-singular, uses dubious grammar, contains elements of purpose, and is generally confusing.]

可接受：当以下任意条件组合为真时，Control_Sidelights 功能应点亮侧灯：侧灯亮起、前灯亮起、前雾灯亮起、后雾灯亮起。

Acceptable: The Control_Sidelights function shall illuminate the Sidelights while any combination of the following conditions is true: the Side_Lamps are illuminated, the Head_Lamps are illuminated, the Front_Fog_Lamps are illuminated, the Rear_Fog_Lamps are illuminated.

[规则 16 和 17 也已应用，以删除组合子并澄清确切条件。请注意，此示例中“任何”的使用并无歧义，因此是 R32 的一个例外。另请参阅 R28。]  [Rules 16 and 17 have also been applied to remove combinators and clarify the exact conditions. Note that the use of “any” in this example is not ambiguous and thus is an exception to R32. See also R28.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C5 - 单数 Singular

阐述 Elaboration:

需求和要求陈述应尽可能简洁且完整 (C4)。为了避免歧义或传达需求或要求的必要性 (C1)，一些作者认为有必要在需求或要求陈述中包含附加文本，以包含更多信息，使意图和理由更清晰。需求或要求陈述的文本不必也不应该包含这些额外的文本。 Needs and requirement statements should be as concise as possible and be complete (C4). To avoid ambiguity or communicate why the need or requirement is necessary (C1), some writers feel the need to include additional information to make the intent and reason clearer by including additional text within the need or requirement statement. The text of a need or requirement statement does not and should not have to carry around this extra text.

目的的表达通常用“……为了”、“为了”、“使得”和“从而允许”等短语来表示。 Expressions of purpose are often indicated by the presence of phrases such as “……to”, “in order to”, “so that”, and “thus allowing.”

这些额外信息应该使用 NRM 中讨论的基本原理属性 (A1) 单独包含在需求或要求表达中。 This extra information should be included separately in the need or requirement expression using the rationale attribute (A1) as discussed in the NRM.

示例 Examples:

不可接受：Record_Subsystem 应显示每个 Line_Item 的名称，以便操作员可以确认它是正确的项目。

Unacceptable: The Record_Subsystem shall display the Name of each Line_Item so that the Operator can confirm that it is the correct Item.

[这是不可接受的，因为“以便操作员可以确认它是正确的物品”这句话是合理的。] [This is unacceptable because the text “so that the Operator can confirm that it is the correct Item” is rationale.]

可接受：Record_Subsystem 应显示每个 Line_Item 的名称。

Acceptable: The Record_Subsystem shall display the Name of each Line_Item.

[“以便操作员可以确认它是正确的物品”这句话应该包含在理由属性中。]  [The text “so that the Operator can confirm that it is the correct Item” should be included in the rationale attribute.]

不可接受：Operation_Logger 应记录系统产生的每个 Warning_Message。

Unacceptable: The Operation_Logger shall record each Warning_Message produced by the system.

[由于“系统产生”一词多余，因此这是不可接受的。]  [This is unacceptable because of the superfluous words “produced by the system”.]

可接受：Operation_Logger 应记录每个 Warning_Message。

Acceptable: The Operation_Logger shall record each Warning_Message.

本规则所确定的特征 Characteristics that are established by this rule:

C1 - 必要 Necessary

C5 – 单一 Singular

阐述 Elaboration:

如果需求或要求陈述的文本包含圆括号或方括号，通常表示存在多余的信息，这些信息可以简单地删除或在理由中传达。其他时候，方括号会引起歧义。 If the text of a need or requirement statement contains parentheses or brackets, it usually indicates the presence of superfluous information that can simply be removed or communicated in the rationale. Other times, brackets introduce ambiguity.

如果括号或方括号中的信息有助于理解要求的意图，则该信息应包含在 NRM 中定义的理由属性 (A1) 中。 If the information in the parentheses or brackets aids in the understanding of the intent of the requirement, then that information should be included in the rationale Attribute (A1) defined in the NRM.

可以为特定目的商定使用括号或方括号的惯例，但此类惯例应在需求或要求文档的开头记录。 Conventions for the use of parentheses or brackets may be agreed upon for specific purposes, but such conventions should be documented at the start of the needs or requirements document.

示例 Examples:

不可接受：当水温超过 85°C 时（通常在沸腾周期结束时），控制单元应断开锅炉的电源。

Unacceptable: The Control_Unit shall disconnect power from the Boiler when the water temperature exceeds 85 °C (usually towards the end of the boiling cycle.)

[由于括号内的语句以及含糊不清的词语“通常”，这是不可接受的。]  [This is unacceptable because of the parenthetical phrase as well as the ambiguous word “usually”.]

可接受：当水温高于 85°C 时，控制单元应断开锅炉的电源。

Acceptable: The Control_Unit shall disconnect power from the Boiler when the water temperature is greater than 85 °C.

[注意：对于上述示例，如果此行为是设计决策的结果，则需要将要求作为设计输出进行传达。设计输入要求应侧重于为什么需要此行为 - 例如，防止锅炉过压和爆炸。] [Note: for the above example, if this behavior is the result of a design decision, then the requirement needs to be communicated as a design output. The design input requirement should focus on why this behavior is needed – for example, prevent the boiler from over pressurizing and exploding.]

例外情况和关系 Exceptions and relationships:

虽然该规则规定应避免使用括号，但 R15 表示括号可以作为消除逻辑表达式等歧义条件的惯例的一部分。 While this rule states brackets are to be avoided, R15 indicates that brackets may be used as part of a convention for eliminating ambiguous conditions such as logical expressions.

本规则所确定的特征 Characteristics that are established by this rule:

C5 – 单一 Singular

阐述 Elaboration:

如果暗示了多项功能，则应该为每个功能写一份需求或要求说明。 If a number of functions are implied, a need or requirement statement should be written for each.

使用群体名词来组合功能或实体通常会产生歧义，因为它会使该群体的成员身份产生疑问。 The use of a group noun to combine functions or entities is often ambiguous because it leaves membership of that group in doubt.

其他问题包括分配、可追溯性、核查和确认。与奇异特性 C5 一样，集合中的每个成员可以分配不同，具有不同的子项要求，每个子项都必须单独核查和确认。 Other issues include allocation, traceability, verification, and validation. As with the singularity characteristic C5, each member of the set could be allocated differently, have different child requirements, each of which must be individually verified and validated.

最好将集合中的所有成员列为单独的需求或要求。请参阅下面的例外和关系讨论。 It is almost always best to list all the members of the set as separate needs or requirements. See exceptions and relationship discussion below.

另请参阅 R18。 See also R18.

示例 Examples:

不可接受：热控制系统应管理与温度相关的功能。

Unacceptable: The thermal control system shall manage temperature-related functions.

[这是不可接受的，因为对于要管理哪些功能存在歧义。应在单独的需求说明中明确列举具体功能。]  [This is unacceptable because there is ambiguity regarding which functions are to be managed. The specific functions should be enumerated explicitly in separate requirement statements.]

可以接受：（三个单独的要求）：

Acceptable: (three separate requirements):

热控制系统应每 10 +/- 1 秒更新一次当前系统温度的显示。 The Thermal_Control_System shall update the display of Current_System_Temperature every 10 +/- 1 seconds.

热控制系统应将当前系统温度维持在 95°C 至 98°C 之间。 The Thermal_Control_System shall maintain the Current_System_Temperature between 95°C and 98°C.

热控制系统应存储当前系统温度的历史记录。 The Thermal_Control_System shall store the history of Current_System_Temperature.

[请注意使用词汇表来定义术语。]  [Note use of the glossary to define terms.]

例外情况和关系 Exceptions and relationships:

列举集合中的成员几乎总是更好的做法，但如果最终的要求足够明确，规则可以在更高的抽象级别上放宽。例如，在业务管理级别，业务可能会声明“ACME Con​​sulting 应集中管理人力资源职能。”或者系统级别的需求声明可能会声明：“利益相关者需要系统来集中管理人力资源职能。” It is almost always better to enumerate members in a set, but the rule may be softened at the higher levels of abstraction if the resulting requirement is sufficiently unambiguous. For example, at the business management level the business may state “ACME Consulting shall manage HR functions centrally.” or a system level need statement may state: “The stakeholders need the system to manage HR functions centrally.”

尽管这提出了所指的是哪些人力资源职能的问题，但在这些抽象级别上包含一长串列表是没有用的，而且通常没有必要，因为该声明在其陈述的级别上已经足够清楚了。职能的详细列举将在业务运营层面进行，业务管理利益相关者应该放心，不会因为没有在业务管理层面列出职能而被遗漏。 Although this raises the question of which HR functions are being referred to, it is not useful to include a long list at these levels of abstractions and it is often not necessary since the statement is sufficiently clear at the level at which it is stated. The detailed enumeration of functions will be undertaken at the business operations level, and the business management stakeholders should be comfortable that no function will be omitted as a result of not listing it at the business management level.

在系统层面，将需求陈述转化为设计输入要求的过程中，项目团队会将需求分解为单独的功能/性能要求，并定义有关“集中”一词的要求，然后与利益相关者一起验证最终的设计输入要求在实现时是否符合需求陈述的目的。 At the system level, the during the transformation of the need statement into design input requirements, the project team would decompose the need into individual functional/performance requirements as well as define requirements concerning the word “centrally” and would then validate with the stakeholders that the resulting design input requirements, when realized, would meet the intent of the need statement.

本规则所确定的特征 Characteristics that are established by this rule:

C3 – 明确 Unambiguous

C5 – 单一 Singular

阐述 Elaboration:

有时用语言表达复杂的需求或要求可能会很困难，最好只是参考图表或模型。Sometimes it can be difficult to express a complicated need or requirement in words, and it is better simply to refer to a diagram or model.

一个例子是开启电压的要求，它涉及幅度、上升时间、过冲和阻尼时间以及公差。在同一个要求中陈述所有这些值可能会被视为违反我们的组合器和多重思维规则。有一个要求规定：“开启时，系统应提供具有图纸 xxxxx 中所示特性的初始电压。”图纸显示幅度、上升时间、允许的过冲和阻尼时间要简单得多。将每个条件作为单独的要求陈述是不适用的，因为所有四个条件都是一个动作的一部分。 An example is a requirement on voltage at turn on which involves a magnitude, rise time, overshoot, and dampening time along with tolerances. Stating all these values in the same requirement could be seen to violate our combiner and multiple thought rules. Having a requirement that states: “Upon turn on, the system shall supply the initial voltage with the characteristics shown in drawing xxxxx.” It is much simpler for the drawing to show the magnitude, rise time, allowable overshoot, and dampening time. Stating each as a separate requirement is not applicable because all four conditions are part of the one action.

示例 Examples:

不可接受：控制系统应在温度超过 95°C 后 5 秒内关闭阀门 A 和 B，并且两个阀门的关闭间隔不得超过 2 秒。

Unacceptable: The control system shall close Valves A and B within 5 seconds of the temperature exceeding 95 °C and within 2 seconds of each other.

[由于条件设置混乱，这是不可接受的。在这种情况下，如果以图表的形式表达，其含义就会很清楚。]  [This is unacceptable because of the confusing set of conditions. In this case what is meant will be clear if expressed in the form of a diagram.]

可接受：当产品温度超过 95°C 时，控制系统应按照时序图 6 规定关闭输入阀门。Acceptable: When the Product temperature exceeds 95 °C, the Control_System shall close Input_Valves as specified in timing diagram 6.

[请注意，这当然假设时序图本身没有歧义。如果无法使用图表消除歧义，最好将需求分成两部分。]  [Note that this assumes, of course, that the timing diagram itself is not ambiguous. If it is not possible to remove the ambiguity by using a diagram, it may be better to split the requirement into two.]

[注意：对于上述示例，如果这种复杂行为是设计决策的结果，则需要将需求作为设计输出传达给设计部门。设计输入要求应侧重于为什么需要这种行为。]  [Note: for the above example, if this complex behavior is the result of a design decision, then the requirement needs to be communicated below the line as a design output. The design input requirement should focus on why this behavior is needed.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C5 – 单一 Singular

阐述 Elaboration:

重复完整的名词，而不是使用代词来指代其他需求或要求陈述中的名词。 Repeat nouns in full instead of using pronouns to refer to nouns in other need or requirement statements.

代词包括“它”、“这个”、“那个”、“他”、“她”、“他们”和“他们”等词。 Pronouns are words such as “it”, “this”, “that”, “he”, “she”, “they”, and “them.”

在撰写故事时，代词是避免重复名词的有效手段；但是在撰写需求和要求陈述时，代词实际上是对其他需求或要求陈述中的名词的交叉引用，因此会产生歧义，应避免使用。When writing stories, pronouns are a useful device for avoiding the repetition of nouns; but when writing need and requirement statements, pronouns are effectively cross-references to nouns in other need or requirement statements and, as such, are ambiguous and should be avoided.

最初书写时，定义代词的名词可能位于前一个需求或要求陈述中的代词之前，但是，随着需求集的成熟，可能会添加、删除、重新排序或重新分组单个需求，并且定义需求不再位于附近。当需求存储在需求管理工具中时尤其如此，因为需求在数据库中以单个语句的形式存在，并且可能没有按顺序排列。 When originally written, the noun that defines the pronoun may have preceded the pronoun in the previous need or requirement statement, however, as the set of requirements mature, individual requirements may be added, deleted, reordered, or regrouped, and the defining requirement is no longer nearby. This is especially true when requirements are stored in a requirement management tool where they exist as single statements in a database that may not be in order.

为了避免这些问题，请重复专有名词，而不要使用代词。 To avoid these problems, repeat the proper nouns rather than using a pronoun.

不定代词包括“all”、“another”、“any”、“anybody”、“anything”、“both”、“each”、“either”、“every”、“everybody”、“everyone”、“everything”、“few”、“many”、“most”、“much”、“neither”、“no one”、“nobody”、“none”、“one”、“several”、“some”、“somebody”、“someone”、“something”和“such”等词。不定代词代表未命名的人或事物，这使得它们的含义可以被解释、模棱两可且无法验证。 Indefinite pronouns are words such as “all”, “another”, “any”, “anybody”, “anything”, “both”, “each”, “either”, “every”, “everybody”, “everyone”, “everything”, “few”, “many”, “most”, “much”, “neither”, “no one”, “nobody”, “none”, “one”, “several”, “some”, “somebody”, “someone”, “something”, and “such.” Indefinite pronouns stand in for unnamed people or things, which makes their meaning subject to interpretation, ambiguous, and unverifiable.

另请参阅 R32 和 R36。 See also R32 and R36.

示例 Examples:

不可接受：控制员应向司机发送当天的行程。行程应在司机轮班前至少 8 小时送达。Unacceptable: The controller shall send the driver his itinerary for the day. It shall be delivered at least 8 hours prior to his Shift.

[这是不可接受的，因为要求用两句话来表达，而第二句话使用了代词“它”和“他的”。] [This is unacceptable because the requirement is expressed as two sentences and the second sentence uses the pronouns “it” and “his.”]

可接受：控制员应在 Driver_Shift 前至少 8 小时将当天的 Driver_Itinerary 发送给驾驶员。Acceptable: The Controller shall send the Driver_Itinerary for the day to the Driver at least 8 hours prior to the Driver_Shift.

[请注意使用词汇表来定义术语，并明确说明司机、轮班和特定司机的行程之间的关系。]  [Note use of the glossary to define terms and to be explicit about the relationship between the driver, shift, and the itinerary for that particular driver.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

阐述 Elaboration:

在以文档为中心的需求和要求文档中，一个常见的错误是使用特定主题或主题的标题来解释需求或要求陈述。需求或要求陈述本身应该是完整的，不需要标题来清楚地理解需求或要求的意图。 It is a common mistake in document-centric documentation of needs and requirements to use the heading for a specific topic or subject under which the requirement applies to contribute to the explanation of the need or requirement statement. The need or requirement statement should be complete in and of itself and not require the heading for the intent of the need or requirement to be clearly understood.

当使用以数据为中心的方法进行 SE 时，可以避免使用标题，其中使用现代需求管理工具 (RMT) 或其他 SE 工具来开发和管理需求和要求集，而不是使用以文档为中心的传统工具（其在文档的章节和段落内组织需求和要求）。 Use of a heading can be avoided when using a data-centric approach to SE where sets of needs and requirements are developed and managed using a modern requirements management tool (RMT) or other SE tool rather than a legacy tool that is document-centric which organizes needs and requirements within sections and paragraphs of a document.

示例 Examples:

示例标题：“4.0 警报蜂鸣器要求” Example heading:” 4.0 Alert Buzzer Requirements”

不可接受：4.1 系统应发声超过20分钟。

Unacceptable: 4.1 The system shall sound it for greater than 20 minutes.

[这是不可接受的，因为该要求使用了代词“它”（R24），这要求标题理解“它”的意思。此外，“声音”这个词可能含糊不清，因为它可以是名词、动词、副词或形容词。我们不知道 Alert_Buzzer 是控制噪音的子系统还是发出噪音的东西]  [This is unacceptable because the requirement uses the pronoun “it” (R24), which requires the heading to understand what “it” means. In addition, the word “sound” could be ambiguous as it can be a noun, a verb, adverb, or adjective. We do not know whether Alert_Buzzer is a subsystem that controls the noise or the thing that makes the noise]

可接受：系统应激活 Alert_Buzzer 超过 20 分钟。

Acceptable: The system shall activate the Alert_Buzzer for greater than 20 minutes.

例外情况和关系 Exceptions and relationships:

在生成 RMT 输出时，可以使用标题，将类似类型或类别的需求或要求分组。参见 R40 和 R41。 The use of headings is acceptable when producing an output of a RMT, grouping like types or categories of needs or requirements. See R40 and R41.

该规则所确定的特征 Characteristics that are established by this rule:

C4 – 完整性 Complete

阐述 Elaboration:

绝对的可用性，例如“100% 可用性”，是无法实现的。提前考虑设计和系统验证：如何证明 100% 可用性？即使您可以构建这样的系统，您能负担得起验证或确认它的费用吗？An absolute, such as “100% availability”, is not achievable. Think ahead to design and system verification and design and system validation: how would you prove 100% availability? Even if you could build such a system, could you afford to verify or validate it?

其他要避免的例子是“全部”、“每个”、“总是”和“从不”，因为如果没有无数次的验证或确认活动，这些绝对的词是不可能被验证的。 Other examples to avoid are “all”, “every”, “always”, and “never” since such absolutes are impossible to verify without an infinite number of verification or validation activities.

包含绝对值的需求或要求既不可行（C6），不可验证（C7），也不正确（C8）。 A need or requirement that contains absolutes is neither Feasible (C6), Verifiable (C7), nor Correct (C8).

示例 Examples:

不可接受：系统应具有 100% 的可用性。

Unacceptable: The system shall have 100% availability.

[这是不可接受的，因为 100% 是绝对不可能实现和验证的。另外，在什么时间段内可用？]  [This is unacceptable because 100% is an absolute that is impossible to achieve and verify. Also, available over what time period?]

可接受：系统在运行时间内的可用性应大于或等于 98%。

Acceptable: The system shall have an Availability of greater than or equal to 98% during Operating_Hours.

[请注意使用词汇表来定义营业时间。]  [Note use of the glossary to define Operating_Hours.]

本规则所确定的特征 Characteristics that are established by this rule:

C6 – 可行 Feasible

C7 - 可验证 Verifiable

C8 – 正确  Correct

阐述 Elaboration:

明确说明适用性条件，而不是根据上下文推断适用性。State applicability conditions explicitly instead of leaving applicability to be inferred from the context.

有时需求或要求陈述仅在某些条件下适用。如果是这样，则应在每个需求或要求陈述的文本中重复该条件，而不是陈述条件然后列出要采取的措施。 Sometimes need or requirement statements are only applicable under certain conditions. If so, the condition should be repeated in the text of each need or requirement statement, rather than stating the condition and then listing the actions to be taken.

有几种同意的条件类型 There are several agreed to types of condition:

事件驱动的要求 Event-driven requirements:

当<可选先决条件/触发器>时，<系统名称>应<系统响应>。

When <optional preconditions/trigger> the <system name> shall <system response>.

当发生<特定事件>时，<系统名称>应当<系统响应>。

In the event of <specific event> the <system name> shall <system response>.

行为驱动需求 Behavior driven requirements:

如果<可选的先决条件/触发条件>，则<系统名称>应<系统响应>。

If <optional preconditions/trigger>, then the <system name> shall <system response>.

状态驱动的要求 State-driven requirements:

当<进入、退出或处于特定状态（或模式）>时，<系统名称>应<系统响应>。

While <entering, exiting or in a specific state (or mode)> the <system name> shall <system response>.

如果适用于某项需求或要求的条件未在需求或要求陈述中明确说明，则该需求或要求陈述不完整（C4）、可验证（C7）或不正确（C8），除非包含条件子句。 If a condition that applies to a need or requirement is not stated explicitly within the need or requirement statement, the need or requirement statement is not Complete (C4), Verifiable (C7), nor Correct (C8) unless the condition clause is included.

另请参阅 R1、R11、R18。 See also R1, R11, R18.

示例 Examples:

不可接受 Unacceptable:

如果检测到火灾  In the event of a fire detection:

• 应关闭电磁防火门锁的电源。 Power to electromagnetic magnetic fire door catches shall be turned off.

• 安全入口应设置为自由出入模式。 Security entrances shall be set to Free_Access_Mode.

• 防火通道门必须处于未锁状态。 Fire escape doors shall be unlocked.

[这是不可接受的，因为“如果发现火灾”这一条件是在要采取的一系列行动之后陈述的。另外，请注意，这些行动是用被动语态写的，这违反了 R2。]  [This is unacceptable because the condition “in the event of a fire detection” is stated following a list of actions to be taken. Also, note the actions are written in passive voice which violates R2.]

可接受：（分为三个单独的要求。）

Acceptable: (Split into three separate requirements.)

一旦探测到火灾，安全系统应切断电磁防火门锁的电源。 In the event of a fire detection, the Security_System shall turn off power to electromagnetic magnetic fire door catches.

一旦探测到火灾，安全系统应将安全入口设置为自由访问模式。 In the event of a fire detection, the Security_System shall set security entrances to the Free_Access_Mode.

一旦探测到火灾，安全系统应解锁消防通道门。 In the event of a fire detection, the Security_System shall unlock fire escape doors.

本规则所确定的特征 Characteristics that are established by this rule:

C4 - 完整 Complete

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

当在单个需求或要求陈述中为单个操作列出一系列条件时，可能不清楚是否所有条件都成立（连词）或其中任何一个条件成立（析取词）才能执行该操作。需求或要求的措辞应该明确这一点。 When a list of conditions is given for a single action in a single need or requirement statement, it may not be clear whether all the conditions must hold (a conjunction) or any one of them (a disjunction) for the action to take place. The wording of the need or requirement should make this clear.

当触发另一动作的条件和动作的组合很复杂时，应考虑使用图表或表格（参见 R23）。When the combination of conditions and actions that trigger another action is complex, consideration should be given to the use of a diagram or table (see R23).

示例 Examples:

不可接受 Unacceptable:

在以下情况下，审计员应能够更改操作项的状态 The Audit _Clerk shall be able to change the status of the action item when:

- 审计员发起该项目 the Audit _Clerk originated the item;

- 审计员是被起诉人；并且 the Audit _Clerk is the actionee; and

- 审计员是审阅者 the Audit _Clerk is the reviewer.

[这是不可接受的，因为不清楚是否所有条件都必须成立（合取）还是其中任何一个条件都必须成立（析取）。此外，该要求包含短语“能够”，这违反了 R11。]  [This is unacceptable because it is not clear whether all the conditions must hold (a conjunction) or any one of them (a disjunction). Also, the requirement contains the phrase “be able to” which violates R11.]

如果解释为析取，则可以接受： Acceptable if interpreted as a disjunction:

当下列一个或多个条件成立时，审计系统应允许审计员更改行动项的状态： The Audit_System shall allow the Audit_Clerk to change the status of the action item when one or more of the following conditions are true:

- Audit_Clerk 发起该项目 the Audit_Clerk originated the item;

- Audit_Clerk 是被起诉人 the Audit_Clerk is the actionee;

- Audit_Clerk 是审阅者 the Audit_Clerk is the reviewer.

或者，这可以表述为三个不同的要求，因为这使得每个原子和整体具有相同的含义。从分配、可追溯性和可验证性的角度来看，这种形式是可取的。 Alternately, this could be stated as three distinct requirements as this makes each atomic and overall has the same meaning. From an allocation, traceability, and verifiability perspective this form is preferable.

当审计员发起项目时，审计系统应允许审计员更改行动项目的状态。 The Audit_System shall allow the Audit_Clerk to change the status of the action item when the Audit_Clerk originated the item.

当审计员是行动接受者时，审计系统应允许审计员更改行动项目的状态。 The Audit_System shall allow the Audit_Clerk to change the status of the action item when the Audit_Clerk is the actionee.

当审计员是审阅者时，审计系统应允许审计员更改行动项目的状态。 The Audit_System shall allow the Audit_Clerk to change the status of the action item when the Audit_Clerk is the reviewer.

如果解释为连词则可以接受： Acceptable if interpreted as a conjunction:

当以下条件成立时，审计系统应允许审计员更改行动项的状态 The Audit_System shall allow the Audit_Clerk to change the status of the action item when the following conditions are true:

- Audit_Clerk 发起该项目并且 the Audit_Clerk originated the item AND

- Audit_Clerk 是被诉人并且 the Audit_Clerk is the actionee AND

- Audit_Clerk 是审阅者。 the Audit_Clerk is the reviewer.

[在这种形式中，这三个条件被表达为一个逻辑条件，即所有三个条件都必须为真，逻辑条件才为真。]  [In this form, the three conditions are expressed as a logical condition such that all three must be true for the logical condition to be true.]

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

阐述 Elaboration:

通过按类型或类别对需求或要求进行分类，可以对需求进行分组或排序，以帮助识别给定类型或类别中的潜在重复和冲突。 By classifying needs or requirements by type or category, it is possible to group or sort requirements to help identify potential duplications and conflicts within a given type or category.

查看特定需求或要求组的能力还可以帮助确定可能缺少哪些需求或要求，从而有助于解决与需求或要求集相关的完整性特征 (C10)。 The ability to view specific groups of needs or requirements can also assist in identifying what needs or requirements may be missing helping to address the characteristic of completeness (C10) as associated with sets of needs or requirements.

为每个需求和要求陈述分配与其类型或类别相关的属性很有用。（有关组织需求和要求以及使用属性 A 40 - 类型/类别的更多指导，请参阅 NRM）。 It is useful to assign to each need and requirement statement an attribute associated with its type or category. (See NRM for more guidance on organizing needs and requirements and the use of Attribute A 40 – type/category).

需求和要求的类型或类别的示例包括形式、适合性、功能/性能、质量（能力）和合规性（标准和法规）。这些可以进一步分为子类型或类别。有关组织需求和要求的详细讨论，请参阅 NRM 第 4 和第 6 节。 Examples of types or categories of needs and requirements include form, fit, function/performance, quality (-ilities), and compliance (standards and regulations). These can be further grouped in to sub types or categories. Refer to the NRM Sections 4 and 6 for a detailed discussion concerning organizing needs and requirements.

类型/类别属性非常有用，因为它允许大量设计人员和利益相关者查看需求和要求数据库，以供广泛的用户使用。例如，维护人员可以通过要求显示所有维护要求来查看数据库，制定测试计划的工程师可以提取所有验证要求，等等。为此，组织将选择适合其特定产品线和流程的需求或要求集管理的类型或类别。如 NRM 中所述，使用属性可以为特定类型或类别的所有需求或要求生成报告，从而识别重复、冲突或缺失的需求。 The type/category attribute is most useful because it allows the needs and requirements database to be viewed by a number of designers and stakeholders for a wide range of users. For example, maintainers could review the database by asking to be shown all the maintenance requirements, engineers developing test plans could extract all verification requirements, and so on. To that end then, the organization would choose types or categories that are useful for the management of their need or requirement set tailored to their specific product line and processes. As discussed in the NRM, the use of attributes allows reports to be generated for all needs or requirements of a certain type or category, allowing the identification of duplication, conflicts, or absence of requirements.

组织如何组织需求和要求应该在组织流程文件和用于组织需求和要求集的相关模板中明确定义。 How an organization organizes needs and requirements should be clearly defined in the organization’s process documents and associated templates for organizing sets of needs and requirements.

示例 Examples:

示例分类：功能、性能、操作、可靠性、可用性、可维护性、安全性、保障性、设计和施工标准、物理特性。 Example classifications: Functional, Performance, Operational, Reliability, Availability, Maintainability, Safety, Security, Design and Construction Standards, Physical Characteristics.

请参阅 NRM 以获取有关组织需求和要求的更多指导。 See the NRM for more guidance on organizing needs and requirements.

另请参阅 R40 - /模块化/相关要求 See Also R40 - /Modularity/RelatedRequirements

本规则所确定的特征 Characteristics that are established by this rule:

C10 - 完整 Complete

C11 - 一致 Consistent

阐述 Elaboration:

避免多次包含相同或等同的需求和要求，无论是重复还是类似形式。完全重复的内容相对容易识别；找到措辞略有不同的类似需求或要求陈述要困难得多，但可以通过一致使用定义术语 (R4) 和分类 (R29) 来提供帮助。 Avoid including the same or equivalent need and requirement more than once, either as a duplicate or in similar form. Exact duplicates are relatively straightforward to identify; finding similar need or requirement statements with slightly different wording is much more difficult but is aided by the consistent use of defined terms (R4) and by classification (R29).

示例 Examples:

通过匹配文本字符串可以找到精确的重复项。主要问题是识别具有不同表达但等价的相似性。例如：“系统应生成一份包含<某些标准或合同可交付成果清单>中定义的信息的财务交易报告”和“系统应生成一份财务报告。”是重叠的，因为前者是后者的子集。 Exact duplicates can be found by matching of text strings. The main problem is to identify similarities with different expressions, but which are equivalent. For example: "The system shall generate a report of financial transactions containing the information defined in <some standard or contract deliverable listing>" and "The system shall generate a financial report." are overlapping in that the first is a subset of the second.

分类 (R29) 可以帮助避免重复，因此可以比较需求或要求的子集。 Avoidance of duplication can be aided by classification (R29) so a subset of needs or requirements can be compared.

本规则所确定的特征 Characteristics that are established by this rule:

C1 - 必需 Necessary

C9 - 符合 Conforming

C11 - 一致 Consistent

阐述 Elaboration:

有关需求和要求之间的区别，请参阅第 1.7 节。 Refer to Section 1.7 concerning the differences between needs and requirements.

作为设计输入，每个系统工作都应具有一定层次的需求和要求，以便捕获要解决的问题（设计输入），但不包含解决方案（设计输出）。系统级需求和要求应为设计要解决的总体问题提供系统级要求。第一层架构可能已经布局完毕，但子系统被视为黑匣子，随着项目团队向下移动架构层，子系统将进一步完善。有关层级和在层级之间移动的信息，请参阅 NRM。 As design inputs, every system endeavor should have a level of needs and requirements for an entity that captures the problem to be solved (design inputs) without including solutions (design outputs). System level needs and requirements should provide a system-level requirement for the overall problem to be addressed by design. The first level of architecture may be laid out, but subsystems are considered as black boxes to be elaborated as the project team moves down levels of the architecture. See the NRM concerning levels and moving between levels.

在审查陈述解决方案的需求时，请问“出于什么目的？”答案将揭示真正的需求。（请注意，这个问题与简单地问“为什么？”略有不同，它鼓励目的论而非因果论的回应。）了解设计输入与设计输出的概念可以让您提出以下问题：“这个需求是否解决了系统需要做什么，还是系统需要如何做？”这些问题的答案有可能帮助做三件事：When reviewing a requirement that states a solution, ask “for what purpose? The answer will reveal the real requirement. (Notice that this question is subtly different from simply asking "Why?” and encourages a teleological rather than causal response.) Understanding the concepts of design inputs versus design outputs allows you to ask the question: “Is this requirement addressing what the system needs to do versus how the system needs to do it”? The answer to these questions has the potential to help do three things:

1. 根据所要解决的问题重新表述需求 Rephrase the requirement in terms of the problem being solved.
2. 确定要求是否处于正确的级别 Determine if the requirement is at the right level.
3. 确定设计输出要求解决哪些设计输入要求或需求，或者是否缺少设计输入要求 Identify which design input requirement(s) or need(s) the design output requirement is addressing or whether the design input requirement is missing.

通常，当原理与陈述解决方案（设计输出）的要求一起提供时，原理通常会回答“为了什么目的？”的问题，因此可以从原理中提取真正的（通常是缺失的）设计输入要求。 Often when rationale is provided with requirements that state a solution (design output), the rationale often answers the “for what purpose?” question, and thus the real (and often missing) design input requirement may be extracted from the rationale.

示例 Examples:

通用：用于医疗诊断系统 General: For a medical diagnostic system

• 利益相关者需求声明：“利益相关者需要诊断系统来测量[某些东西]，其精度与市场上的同类设备一样好或更好。” Stakeholders need statement: “The stakeholders need the diagnostic system to measure [something] with an accuracy as good as or better than similar devices in the market.”

[这是利益相关者需求陈述的适当抽象级别，清楚地说明了利益相关者对准确性的期望，但这不是一个好的设计输入要求。]  [This is an appropriate level of abstraction for a stakeholder need statement, clearly stating the expectation the stakeholders have concerning accuracy, however this would not be a good design input requirement.]

• 从利益相关者需求陈述转化而来的需求：“诊断系统应以 [xxxxx] 的精度测量 [某物]。 ”Requirement transformed from the stakeholder need statement: “The diagnostic system shall measure [something] with an accuracy of [xxxxx].”

[开发人员已经探索了满足准确性需求的各种概念，研究了候选技术，评估了它们的成熟度（技术就绪水平（TRL），并已确定值 [xxxxxxx] 在该生命周期阶段是可行的，且风险可接受。如上所述，这是设计输入要求的适当细节级别。]  [The developers have explored various concepts for meeting the need for accuracy, have examined candidate technologies, have accessed their maturity (technology readiness level (TRL), and have decided that the value [xxxxxxx] is feasible with acceptable risk for this lifecycle stage. As stated, this is an appropriate level of detail for a design input requirement.]

然后，将该系统级设计输入精度要求分配给系统中对满足整体系统精度要求起重要作用的关键部分。对于医疗诊断系统，这可能包括对硬件（仪器）、检测（生物样本）和软件的分配。然后，这些分配可在硬件、检测和软件较低级别实体中进一步细分。 This system level design input accuracy requirement is then allocated to the key parts of the system that have a role in meeting the overall system accuracy requirement. For a medical diagnostic system this could include allocations to the hardware (instrument), assay (biological sample), and software. These allocations could then be further sub-allocated within the hardware, assay, and software lower-level entities.

只要要求写在精度分配上，而不是某个架构实体如何获得该精度，这些要求就是设计输入要求。一旦指定了特定的硬件组件（激光器、以特定波长发光的 LED、光学系统组件、特定放大倍数、算法、配方等），这些要求就会反映设计输出，需要在设计输出工件（规范）内进行传达。 As long as the requirements are written on the accuracy allocation and not how that accuracy will be obtained by one of the architectural entities, the requirements are design input requirements. As soon as specific hardware components are named (laser, LEDs emitting light at a specific wavelength, optical system components, specific magnifications, algorithms, formulations, etc.,) then the requirements are reflecting design outputs and need to be communicated within deign output artifacts (specifications).

不可接受：应使用交通灯来控制路口的行人交通。

Unacceptable: Traffic lights shall be used to control pedestrian traffic at the intersection.

[这是不可接受的，因为“交通信号灯”是一种解决方案（设计输出）。为什么需要交通信号灯？此要求也是用被动语态写的——参见 R2]  [This is unacceptable because “Traffic lights” are a solution (design output). Why are traffic lights needed? This requirement is also written in passive voice – see R2]

可以接受：（有若干要求）

Acceptable: (several requirements):

当允许行人在路口过马路时，交通控制系统应发出“步行”信号。 The Traffic_Control_System shall signal “Walk” when the Pedestrian is permitted to cross the road at the Intersection.

交通控制系统应将穿越交叉路口的车辆的等待时间限制在正常白天交通条件下的最大白天等待时间值以内。 The Traffic_Control_System shall limit the Wait_Time of Vehicles traversing the Intersection to less than Maximum_Daylight_Wait_Time_Value during Normal_Daytime traffic conditions.

[请注意，应使用词汇表定义来定义交通控制系统 (Traffic_Control_System)、最大日光等待时间值 (Maximum_Daylight_Wait_Time_Value)、正常日间时间 (Normal_Daytime)、车辆 (Vehicles) 和交叉路口 (Intersection)。]  [Note that glossary definitions should be used for Traffic_Control_System, Maximum_Daylight_Wait_Time_Value, Normal_Daytime , Vehicles, and Intersection.]

不可接受：行人按下交通信号灯柱上的按钮，表示他的存在，信号灯变成红色，表示车辆停止行驶。 Unacceptable: By pressing a button on the traffic-light pillar, the pedestrian signals his presence, and the light turns red for the traffic to stop.

[这是不可接受的，因为这个需求包含偏向解决方案的细节——设计输出。此外，这个需求也是不可接受的，因为主体是我们无法控制的用户——也就是说，我们无法在正在开发的系统的需求声明中告诉用户该做什么。]  [This is unacceptable because this requirement contains solution-biased detail – design output. In addition, the requirement is unacceptable because the subject is the user over which we have no control—that is, we cannot tell the user what to do in a requirement statement for the system being developed.]

可接受：交通控制系统应允许行人在交叉路口发出过马路的信号。

Acceptable: The Traffic_Control_System shall allow the Pedestrian to signal intent to cross the road at the Intersection.

[此要求允许自由确定最佳解决方案（设计输入），这可能是一种自动检测的方式，而不是按下按钮。]  [This requirement allows freedom in determining the best solution (design input), which may be a means of automatic detection rather than button pushing.]

[请注意，应使用词汇表定义“行人”、“交通控制系统”和交叉路口。]  [Note that glossary definitions should be used for “Pedestrian”, “Traffic_Control_System”, and Intersection.]

例外情况和关系 Exceptions and relationships:

有时，解决方案必须在需求中描述，即使对于给定级别来说非常详细，例如，如果适航当局要求使用特定模板来编写特定报告；或者海军客户要求新海军舰艇配备特定供应商提供的特定武器系统；或者，如果舰队中的所有车辆都必须使用相同的燃料，或者下一个型号必须使用特定的发动机。在这些情况下，这不是不成熟的解决方案，而是有关约束的真正利益相关者或客户需求。因此，这可以作为设计输入。 Sometimes solutions have to be described in requirements, even if it is very detailed for a given level, for example if the airworthiness authorities require the use of a specific template for a certain report; or if a naval customer requires that the new naval vessel be equipped with a specific weapon system from a specific supplier; or, if all vehicles in a fleet are required to use the same fuel or the next model make use of a particular engine. In these cases, it is not a premature solution, but a real stakeholder or customer need concerning a constraint. As such this is acceptable as a design input.

然而，一般来说，如果在没有适当论证的情况下将详细、具体的设计解决方案表达为设计输入，则它可能是一个不成熟的解决方案，应该将其作为设计输出进行传达，并制定一组适当的设计输入需求和相关要求，以传达“出于什么目的？”，设计输出要求可以追溯到该需求。 However, as a rule, if a detailed, specific design solution is expressed as a design input without proper justification, it may be a premature solution and should be communicated as a design output and an appropriate set of design input needs and associated requirements developed that communicate “For what purpose?” which the design output requirements can be traced to.

与设计输入表达的设计输出有关的问题示例包括： Examples of issues concerning design outputs expressed as design inputs include:

1. 该项目正在开发对现有系统（棕地 SE）的升级。项目团队没有记录设计输入“什么”要求，而是专注于已知的解决方案和实施，并将设计输出级别要求记录为设计输入。这是有问题的，因为真正的“出于什么目的？”问题没有得到解决，真正的设计输入要求也没有得到传达。 The project is developing an upgrade to an existing system (brownfield SE). Rather than documenting design input “what” requirements, the project team focuses on known solutions and implementations and documenting design output level requirements as design inputs. This is problematic in that the real “for what purpose?” question is not being addressed and the real design input requirements are not communicated.
2. 类似的情况还发生在采购商用现货 (COTS) 解决方案并将该解决方案的要求作为设计输入要求而不是设计输出规范进行传达时。同样，这存在问题，因为真正的“目的是什么？”问题没有得到解决，真正的设计输入要求也没有得到传达。 A similar case exists when procuring a commercial off the shelf (COTS) solution and communicating the requirements for that solution as design input requirements rather than in a design output specification. Again, this is problematic in that the real “for what purpose?” question is not being addressed and the real design input requirements are not communicated.
3. 一个常见的问题是，当现有系统或 COTS 存在时，项目会开发并记录一组详细的系统设计输出级要求（设计输出规范）作为设计输入，而不是一组设计输入“什么”要求来指导选择合适的 COTS。这可能会导致一组不必要的冗余要求，必须进行验证 - 增加项目成本，但并未解决“出于什么目的？”设计输入要求集，而这应该推动选择特定的 COTS。有关 OTC 和 COTS 实体的详细讨论，请参阅 NRM。 A common issue is when an existing system or COTS exists, yet the project develops and documents as design inputs a detailed design output level set of requirements (design output specification) for the system rather than a set of design input set of “what” requirements that would guide the selection of an appropriate COTS. This can result in a redundant set of requirements that are not necessary, will have to be verified – adding additional cost to the project, yet not addressing the “for what purpose?” design input requirement set that should drive the selection of the specific COTS. Refer to the NRM for a detailed discussion the use of OTC and COTS entities.
4. 作为生命周期概念分析和成熟活动的一部分，开发了一个原型来评估可行性。最终的需求和要求基于原型和相关交易研究，该研究得出了满足利益相关者需求的特定解决方案。原型的设计输出要求不是传达设计输入要求，而是包含在设计输入要求集中，而没有解决驱动原型设计的设计输入要求集“用于什么目的？”。 As part of the lifecycle concept analysis and maturation activities a prototype was developed to access feasibility. The resulting needs and resulting requirements are based on the prototype and an associated trade study that resulted a specific solution that meets the needs of the stakeholders. Rather than communicating the design input requirements, the design output requirements for the prototype are included in the design input set of requirements while not addressing the “for what purpose?” design input requirement set that would drive the design for the prototype.

该规则所确定的特征 Characteristics that are established by this rule:

C2 - 合适的 Appropriate

阐述 Elaboration:

使用“全部”、“两者”或“任何”会造成混淆，因为很难区分操作是发生在整个集合上还是发生在集合的每个元素上。除非“全部”可以明确定义为封闭集合，否则“全部”也很难验证。在许多情况下，“全部”一词是不必要的，可以删除，从而减少需求或要求的歧义。 The use of “all”, “both”, or “any” is confusing because it is hard to distinguish whether the action happens to the whole set or to each element of the set. “All” can also be hard to verify unless “all” can be clearly defined as a closed set. In many cases, the word “all” is unnecessary and can be removed, resulting in a less ambiguous need or requirement statement.

示例 Examples:

不可接受：Operation_Logger 应记录任何（或所有）警告信息。

Unacceptable: The Operation_Logger shall record any (or all) warning messages.

[这是不可接受的，因为使用了“任何”一词，而添加“（或全部）”则使情况变得更糟。] [This is unacceptable because of the use of the word “any”, which is then made worse by the addition of “(or all)”.]

可接受：Operation_Logger 应记录每个 Warning_Message。

Acceptable: The Operation_Logger shall record each Warning_Message.

[请注意，必须定义Warning_Message，以便系统清楚只记录每个定义的警告消息。] [Note that Warning_Message must be defined so that it is clear that the system only will record each defined Warning Message.]

不可接受：Record_Subsystem 应显示两个 Line_Items 的名称。

Unacceptable: The Record_Subsystem shall display the Names of both of the Line_Items.

[由于使用了“两者”一词，这是不可接受的。]  [This is unacceptable because of the use of the word “both”.]

可接受：Record_Subsystem 应显示每个 Line_Item 的名称。

Acceptable: The Record_Subsystem shall display the Name of each Line_Item.

可接受：Record_Subsystem 应显示每个 Line_Item_Name。

Acceptable: The Record_Subsystem shall display each Line_Item_Name.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C7 - 可验证 Verifiable

C8 - 正确 Correct

阐述 Elaboration:

在定义性能时，单点值很少足够，而且很难测试。问这个问题：“如果性能比这个低一点（或高一点），我还会买吗？”如果答案是肯定的，那么就修改需求或要求陈述以反映可接受的值范围。 When it comes to defining performance, single-point values are seldom sufficient and are difficult to test. Ask the question: “if the performance was a little less (or more) than this, would I still buy it?” If the answer is yes, then change the need or requirement statement to reflect an acceptable range of values.

考虑根本目标也有帮助：您是想最小化、最大化还是优化某些事物？这个问题的答案将有助于确定是否存在上限、下限或两者兼有。 It also helps to consider the underlying goal: are you trying to minimize, maximize or optimize something? The answer to this question will help determine whether there is an upper bound, lower bound, or both.

用范围或限度来说明需求或要求说明中包含的数量，其准确度应适合于该需求或要求所适用的实体，并根据该实体进行验证。 State the quantities contained in a need or requirement statement with ranges or limits with a degree of accuracy that is appropriate to the entity to which the need or requirement applies and against which the entity will be verified against.

应注意避免未指定的值范围，并确保数量以公差或极限表示。这样做有两个原因： Care should be taken to avoid unspecified value ranges and ensure the quantities are expressed with tolerances or limits. There are two reasons for this:

1) 可能需要权衡多种要求，提供公差或限制是描述权衡空间的一种方式。数量很少是绝对的。通常可以接受一定范围的值，以提供不同的性能水平。 Several requirements may have to be traded against each other, and providing tolerances or limits is a way of describing the trade-space. Seldom is a quantity absolute. A range of values is usually acceptable, providing different performance levels.

2) 针对单个绝对值进行验证通常是不可行的，或者非常昂贵且耗时，而针对具有上限和下限的定义范围的值进行验证则使验证更易于管理。 Verification against a single absolute value is usually not feasible or at best very expensive and time consuming, whereas verification against a defined range of values with upper and lower limits makes verification more manageable.

还应注意确保容差不超过需要的程度。更严格的容差不仅会增加系统设计和制造成本，还会增加验证系统是否能在更严格的容差范围内运行的成本。 Care should also be taken to ensure the tolerances are no tighter than needed. Tighter tolerances can drive costs both in system design and manufacturing as well as the costs in verifying the system can perform within the tighter tolerances.

示例 Examples:

不可接受：Pumping_Station 应将水流量维持在每秒 120 升，持续 30 分钟。Unacceptable: The Pumping_Station shall maintain the flow of water at 120 liters per second for 30 minutes.

[这是不可接受的，因为我们不知道解决的数量多于或少于指定数量的问题的解决方案是否可以接受。]  [This is unacceptable because we do not know whether a solution that addresses more or less than the specified quantities is acceptable.]

可接受：Pumping_Station 应维持每秒 120±10 升的水流量至少 30 分钟。

Acceptable: The Pumping_Station shall maintain a flow of water at 120 ±10 liters per second for at least 30 minutes.

[现在可接受的流动性能范围很明确，并且 30 分钟是最低可接受的性能。]  [Now the range of acceptable flow performance is clear and that the 30 minutes is a minimum acceptable performance.]

不可接受：飞行信息系统应以大约 1 米的分辨率显示当前高度。

Unacceptable: The Flight_Information_System shall display the current altitude to approximately 1 meter resolution.

[这是不可接受的，因为它不精确。在距离为 1 米的情况下，“大约”是什么意思？谁有权决定什么是“大约”？如何验证“大约”？可接受的公差是多少？此外，海拔通常以英尺而不是米为单位来描述，因此 +3 英尺是否可以等同于 1 米，因为 3 英尺小于 1 米？]  [This is unacceptable because it is imprecise. What is “approximately” in the context of a distance of 1 meter? Who has the option of deciding what is “approximately”? How will “approximately” be verified? What is the acceptable tolerance? Further, altitude is more commonly described in units of feet, not meters, so is +3 feet an acceptable equivalent to 1 meter since 3 feet is less than 1 meter? ]

[请注意，必须小心确认单位以及从一组单位到另一组单位的转换，以确保准确性、可接受性和一致性。另请参阅 R6。]  [Note that care must be taken to confirm both units and transformation from one set of units to another set to ensure accuracy, acceptability and consistency. See also R6.]

可接受：飞行信息系统应显示当前高度，精度为±3 英尺。

Acceptable: The Flight_Information_System shall display Current_Altitude with an accuracy of ±3 feet.

[请注意，“Current_Altitude” 必须在词汇表中定义，因为该术语有多种可能的解释。] [Note that “Current_Altitude” must be defined in the glossary since there are a number of possible interpretations of the term.]

不可接受：系统应将饮用水中的砷污染限制在允许水平。理由：饮用水中的砷污染会导致健康问题。

Unacceptable: The System shall limit arsenic contamination in the drinking water to allowable levels. Rationale: Arsenic contamination in drinking water can cause health problems.

[虽然“允许”在需求陈述中是可以接受的，但在要求陈述中是不可接受的，因为“允许”含糊不清——谁允许？什么特定浓度是允许的？在哪个市场？]  [While “allowable” is acceptable in a need statement, it is unacceptable in a requirement statement because allowable is ambiguous - allowable by whom? What specific concentration is allowable? In what market?]

不可接受：系统应将饮用水中的砷污染限制在万亿分之一。理由：饮用水中的砷污染会导致健康问题。

Unacceptable: The System shall limit arsenic contamination in the drinking water to 1 part per trillion. Rationale: Arsenic contamination in drinking water can cause health problems.

[这是不可接受的，因为 EPA 饮用水中的污染限值为十亿分之十。要求更严格的限值可能超出了当前技术的测量能力，或者如果可以测量万亿分之一的浓度，那么这样做的成本可能会高得令人无法接受。此外，没有指定范围。使用小于这个值可能是真正的意图。]  [This is unacceptable because the EPA contamination limit in drinking water is 10 parts per billion. Requiring a tighter limit may be beyond the ability of current technology to measure or if measuring concentrations of 1 part per trillion are possible, the cost to do so may be unacceptably high. Also, no range is specified. Using less than is probably the real intent.]

可接受：系统应将饮用水中的砷污染限制在十亿分之十以下。理由：EPA 将饮用水的砷标准设定为 10 ppb（或百万分之 0.010）。EPA 已确定，此水平或更低的浓度将保护消费者免受长期慢性接触砷的影响。 Acceptable: The System shall limit arsenic contamination in the drinking water to less than10 parts per billion. Rationale: EPA set the arsenic standard for drinking water at 10 ppb (or 0.010 parts per million). The EPA has determined that concentrations of this level or less will protect consumers from the effects of long-term, chronic exposure to arsenic.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C6 - 可行 Feasible

C7 - 可验证 Verifiable

C8 - 正确 Correct

C12 - 可行 Feasible

阐述 Elaboration:

有些词语表示无法衡量的量化，例如“及时”、“快速”、“常规”、“最大”、“最小”、“最佳”、“名义上的”、“易于使用”、“快速关闭”、“高速”、“中等规模”、“最佳实践”和“用户友好”。这些词语含糊不清，需要用可行且可衡量的范围内的具体数量来代替。 Some words signal unmeasured quantification, such as “prompt”, ”fast”, ”routine”, ”maximum”, ”minimum”, ”optimum”, ”nominal”, ”easy to use”, ”close quickly”, ”high speed”, ”medium-sized”, ”best practices”, and ”user-friendly.” These are ambiguous and need to be replaced by specific quantities within feasible ranges that can be measured.

示例 Examples:

不可接受：系统应使用最小功率。

Unacceptable: The system shall use minimum power.

[这是不可接受的，因为“最低限度”这个词含糊不清。]  [This is unacceptable because “minimum” is ambiguous.]

可接受：系统使用的主功率应小于或等于 50W。

Acceptable: The system shall use less than or equal to 50W of main power.

[这既考虑了根本目标——最大限度地降低电力消耗，也提供了一个可衡量的目标。] [This both considers the underlying goal - to minimize power consumption - and provides a measurable target.]

不可接受：两年后，发动机的排放水平必须比竞争对手的排放水平至少低 5%。Unacceptable: The engine shall achieve an emissions level that is at least 5% less than the competition’s emission levels 2 years from now.

[这是市场部对工程部的实际要求。该声明设定了一个完全不可衡量的最终状态。] [This is an actual requirement from marketing to an engineering department. The statement sets a completely unmeasurable end state.]

可接受：发动机的排放水平至少应达到 xxx。

Acceptable: The Engine shall achieve an emissions level that is at least xxx.

[其中 xxx 代表所需的阈值。]  [where xxx represents the required threshold value.]

例外情况和关系 Exceptions and relationships:

一些量化术语，例如“最小”、“最大”、“最佳”，几乎总是含糊不清的。其他术语在较低级别可能含糊不清，但在较高级别和作为需求陈述时却足够了。例如，企业声明“飞机应提供一流的舒适度”可能是合适的——虽然这样的要求是不可量化的，因此无法衡量，但企业将其意图作为需求陈述传达给开发人员可能就足够了，然后开发人员可以将舒适度转化为可测量的数量，例如座椅尺寸和腿长。 Some quantification such as “minimum”, “maximum”, “optimal” is almost always ambiguous. Other terms may be ambiguous at lower levels but sufficient at the higher levels and as need statements. For example, it may be appropriate that the business state that “The Aircraft shall provide class-leading comfort.”—while such a requirement is not quantifiable and therefore not measurable, it may be sufficient for the business to communicate its intentions as a need statement to developers who can then turn comfort into such measurable quantities such as seat dimensions and leg length.

此例外也适用于系统或系统元素级别陈述的需求。 This exception also applies to needs stated at the system or system element levels.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

C12 - 可行 Feasible

阐述 Elaboration:

有些单词和短语表示非特定时间，例如“最终”、“直到”、“之前”、“之后”、“如”、“一次”、“最早”、“最新”、“瞬时”、“同时”和“最后”等，这些词和短语含义模糊且无法验证。不明确的时间关键词可能会造成混淆或产生非预期含义。这些词应该用具体的时间约束来代替。 Some words and phrases signal non-specific timing, such as “eventually”, “until”, “before”, “after”, “as”, “once”, “earliest”, “latest”, “instantaneous”, “simultaneous”, and “at last” are ambiguous and not verifiable. Indefinite temporal keywords can cause confusion or unintended meaning. These words should be replaced by specific timing constraints.

示例 Examples:

不可接受：泵的持续运转最终会导致水箱空了。

Unacceptable: Continual operation of the pump shall eventually result in the tank being empty.

[这是不可接受的，因为“最终”含糊不清。此外，这个陈述不是以正确的形式写的。它写在“操作”上，而不是违反 R3 的泵要求上。]  [This is unacceptable because “eventually” is ambiguous. Also, this statement is not written in the proper form. It is written on “operation” rather than on a requirement on the pump which violates R3.]

可接受：泵在连续运行 3 天以内应能从油箱中抽取 99% 以上的液体。

Acceptable: The Pump shall remove greater than 99% of the Fluid from the Tank in less than 3 days of continuous operation.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C4 - 完整 Complete

C7 - 可验证 Verifiable

阐述 Elaboration:

R4 要求对每个需求中的术语进行定义，R6 要求在数字中包含计量单位。除了这些规则之外，不仅在需求和要求集中，而且在所有生命周期阶段开发的所有工件中，术语和计量单位都必须一致使用。因此，需要为每个项目定义一个通用本体，定义所有工件（包括需求和要求集以及所有设计输出工件）中的术语和计量单位。同义词是不可接受的。 R4 requires the definition of terms in each requirement and R6 requires units of measure to be included with numbers. In addition to those rules, terms and units of measure must be used consistently throughout not only the sets of needs and requirements, but all artifacts developed across all lifecycle stages. A common ontology therefore needs to be defined for each project defining terms and units of measure across all artifacts, including the sets of needs and requirements as well as all design output artifacts. Synonyms are not acceptable.

词汇表或数据字典对于准确定义词语非常有用。词汇表或数据字典中定义的术语大写，表示所使用的单词或术语在语句集上下文中具有特定含义。 A glossary or data dictionary is extremely useful to define words precisely. Terms defined within the glossary or data dictionary terms are capitalized to signify that the word or term being used has a specific meaning in the context of the set of statements.

对于可能出现在多个需求或要求中的给定变量的数值，为了确保一致性，最佳做法是在词汇表或数据字典中定义变量及其数值和度量单位。一个例子是在多个地方指定的最大和最小环境温度。例如， For a numeric value for a given variable that may appear in multiple needs or requirements, to help ensure consistency, it is a best practice to define the variable and its numeric value and units of measure in a glossary or data dictionary. An example would be the maximum and minimum environment temperatures specified in multiple places. For example,

最大温度值。这也解决了单位问题，因为这也在词汇表条目中同时定义。虽然有人可能会认为文本中缺少值会使要求更难理解，但保持一致性的能力才是更重要的 Maximum_Temperature_Value. This also resolves the units problem as this is also defined at the same time in the glossary entry. Although it could be argued that the loss of the value in the text makes the requirement harder to understand, however the ability to maintain consistency is higher priority

理想情况下，用于需求和要求集的词汇表或数据字典与项目词汇表或数据字典相同。Ideally, the glossary or data dictionary used for the sets of needs and requirements is the same the project glossary or data dictionary.

示例 Examples:

不可接受：一个需求使用一个术语来指代一个实体，而另一个需求使用另一个术语来指代同一实体，这种做法是不可接受的。

Unacceptable: It would not be acceptable for one requirement to refer to an entity using one term and another to refer to the same entity using another term.

例如，在一组子系统设计输入需求中，有以下三个需求陈述： For example, in a subsystem set of design input requirements, the following three requirement statements:

无线电设备应.... The radio shall ....

接收机应.... The receiver shall ....

终端应.... The terminal shall ....

Or:

排气阀应.... The bleed valve shall ....

高压排气阀应.... The high-pressure bleed valve shall ....

HPBV 应.... The HPBV shall ....

如果每个术语指的是同一主题，则需要修改陈述以使用相同的词语（或者，如果它们意味着不同，则必须将词语定义为不同）。 If each term refers to the same subject, the statements need to be modified to use the same word (or, if they are meant to be different, the words must be defined to be so).

可接受：只确定一个术语，在词汇表或数据字典中定义它，然后在每个需求、要求和设计输出工件中一致地使用它。

Acceptable: Settle on only one term, define it in the glossary or data dictionary, and then use it consistently in each need, requirement, and design output artifact.

不可接受：当输入阀 (Input_Valve) 连接到水源 (Water_Source) 时，控制子系统 (Control_Subsystem) 应打开进水阀 (Inlet_Valve)。

Unacceptable: When the Input_Valve is connected to the Water_Source, the Control_Subsystem shall open the Inlet_Valve.

[两个术语表示同一事物“Input_Valve”和“Inlet_Valve”。]  [Two terms are used for the same thing “Input_Valve” and “Inlet_Valve”.]

可接受：当入口阀门 (Inlet_Valve) 连接到水源 (Water_Source) 时，控制子系统 (Control_Subsystem) 应打开入口阀门 (Inlet_Valve)。

Acceptable: When the Inlet_Valve is connected to the Water_Source, the Control_Subsystem shall open the Inlet_Valve.

不可接受：一个要求使用一个计量单位（例如，美国 - 英尺），而另一个要求使用另一个计量单位（例如，公制 - 米），这是不可接受的。

Unacceptable: It would not be acceptable for one requirement to use one unit of measure (e.g., US - feet) and another requirement to use another unit of measure (e.g., Metric - meter).

可接受：确定将使用哪些度量单位，并在所有 SE 工件（包括需求、设计输入要求和设计输出规范）中使用该度量单位一致性。

Acceptable: Settle on which units of measure will be used and use that unit of measure consistency across all SE artifacts including needs, design input requirements and design output specifications.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C8 - 正确 Correct

C9 - 符合 Conforming

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

C14 - 能够被验证 Able to be Validated

阐述 Elaboration:

每种需求和要求都必须使用相同的缩写词；不允许使用不同版本的缩写词。使用不同的缩写词意味着所指的两项内容不同。缩写词使用不一致会导致歧义。 The same acronym must be used in each need and requirement; various versions of the acronym are not acceptable. The use of different acronyms implies that the two items being referred to are different. Inconsistency in the use of acronyms can lead to ambiguity.

在基于文档的 SE 实践中，一个常见的规则是第一次使用完整术语和缩写或首字母缩略词（在括号中），然后从那时起在文档中仅使用缩写或首字母缩略词（如本指南中所做的那样）。 In a document-based practice of SE, a common rule is to use the full term and the abbreviation or acronym (in brackets) the first time and then use just the abbreviation or acronym from then on within a document (as is done in this Guide).

在以数据为中心的 SE 实践中，在 RMT 中生成和管理的需求和要求集中，无法保证以任何特定顺序提取该集合，因此旧做法没有用。因此，应避免使用首字母缩略词。 In a data-centric practice of SE, in need and requirement sets that are generated and managed within an RMT, there is no guarantee that the set will be extracted in any particular order, so the old practice is not useful. Because of this, the use of acronyms should be avoided.

但是，如果使用缩写词，则不仅必须在需求和要求集中一致使用缩写词，而且必须在所有生命周期阶段开发的所有工件中一致使用缩写词。要解决此问题，请确保在项目范围的缩写词列表或词汇表中定义缩写词。 However, if used, acronyms must be used consistently throughout not only the sets of needs and requirements, but all artifacts developed across all lifecycle stages. To address this issue, make sure acronyms are defined in a project wide acronym list or glossary.

缩写词在大小写和句号方面必须以一致的方式书写。例如，始终使用“CMDP”，而不是“C.M.D.P.”或“CmdP”。 Acronyms must be written in a consistent way in terms of capitalization and periods. For example, always “CMDP” and not “C.M.D.P.” nor “CmdP”.

示例 Examples:

不可接受：一项要求使用首字母缩略词“CP”表示指挥所，而另一项首字母缩略词“CMDP”也指“指挥所”，这是不可接受的。使用两个不同的首字母缩略词意味着所指的两个系统元素是不同的。

Unacceptable: It would not be acceptable for one requirement to use the acronym “CP” for command post and another acronym “CMDP” to also refer to the “command post.” The use of two different acronyms implies that the two system elements being referred to are different.

可接受：仅确定一个首字母缩略词，在首字母缩略词列表中定义它，然后在整个需求集中一致地使用它。

Acceptable: Settle on only one acronym, define it in the list of acronyms, and then use it consistently throughout the requirement set.

不可接受：如果一项要求提到“全球定位系统”，而其余要求仅提到“GPS”，这是不可接受的。

Unacceptable: It would not be acceptable for one requirement to refer to the “Global Positioning System” and the remaining requirements refer just to “GPS.”

可接受：每次都使用完整术语，或者也许更有用的是，在项目缩写词列表或词汇表中定义缩写词并每次使用它。

Acceptable: Use the full term every time or, perhaps more usefully, define the acronym in the project acronym list or glossary and use it every time.

本规则所确定的特征 Characteristics that are established by this rule:

C3 - 明确 Unambiguous

C9 - 符合 Conforming

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

C14 - 能够被验证Able to be Validated

阐述 Elaboration:

缩写的使用会增加歧义，除非上下文清晰且项目词汇表或首字母缩略词列表中对缩写有明确的定义，否则应避免使用缩写。 The use of abbreviations adds ambiguity and is to be avoided unless the context is clear and the abbreviation is clearly defined in the project glossary or acronym list.

根据上下文，缩写通常具有多种含义。 It is common to have an abbreviation with multiple meanings depending on context.

如果缩写具有单一含义并且项目词汇表中已定义，则可以在需求或要求的文本中使用该缩写。 In the case where there is a single meaning and that abbreviation is defined in the project glossary, it is acceptable to use the abbreviation within the text of the need or requirement.

但是，当缩写具有不同含义时，最佳做法是通过拼写缩写来避免歧义。 However, when there are abbreviations that have different meanings, it is a best practice to avoid ambiguity by spelling out the abbreviation.

示例 Examples:

不可接受：一个要求引用表示操作的缩写“op”，而另一个要求引用表示操作员的“op”，这是不可接受的。

Unacceptable: It would not be acceptable for one requirement to refer to the abbreviation “op” meaning operation and another to refer to the “op” meaning the operator.

可以接受：避免使用缩写，每次都使用全称。

Acceptable: Avoid the abbreviation and use the full term every time.

该规则所确定的特征 Characteristics that are established by this rule:

C9 - 符合 Conforming

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

C14 - 能够被验证 Able to be Validated

阐述 Elaboration:

样式指南提供了开发需求的模板和模式，定义了组织选择用每个需求陈述来记录的属性，选择了用于特定类型需求的需求模式，并定义了需要包含的其他信息（例如词汇表）。 The style guide provides a template and patterns for developing requirements, defines the attributes that the organization chooses to document with each requirement statement, selects the requirement patterns to be used for specific types of requirements, and defines what other information needs to be included (such as the glossary).

样式指南还应列出组织想要使用的规则（基于本指南）。 The style guide should also list the rules the organization wants to use (based on this Guide).

当在需求管理工具 (RMT) 或其他系统工程工具中以电子方式（而非打印文档）管理需求时，此信息是定义工具数据库内数据组织的模式的基础。 When managing requirements electronically (versus in a printed document) within a requirement management tool (RMT) or other systems engineering tool, this information is the basis of the schema that defines the organization of the data within the tool database.

为了确保需求和要求声明具有一致的结构，组织需要在其开发和管理流程中包含预定义的模式或模板。这些模式或模板可以来自国际标准，也可以是一组基于利益相关者需求或要求类型的组织标准模式或模板。如果使用需求管理工具，则应将标准模式定义为需求和要求开发和管理流程的一部分。 To ensure need and requirement statements are consistently structured, the organization needs to include pre-defined patterns or templates in their development and management process. The patterns or templates can come from an international standard, or an organizational standard set of patterns or templates based on type of stakeholder need or requirement. If using a requirement management tool, a standard schema should be defined as part of the need and requirement development and management process.

这些模式需要根据组织的领域以及该领域内不同类型的产品进行定制。 The patterns need to be tailored to the organization’s domain and the distinct types of products within that domain.

单个需求和要求陈述的模式和模板有助于确保单个陈述的一致性和完整性（参见附录 C）。 Patterns and templates for individual need and requirement statements help ensure consistency and completeness of the individual statements (see Appendix C).

另请参阅 R1。 See also R1.

示例 Examples:

例如，每个组织都应该有一个风格指南或模式来解决诸如选择和定义应该使用什么需求和要求模式来编写特定类型的需求和要求、属性的选择和使用、标准缩写和首字母缩略词、图表的布局和使用、需求和要求文档或数据库的布局以及需求和要求声明编号等问题。 For example, each organization should have a style guide or schema to address such issues as the selection and definition of what need and requirement patterns should be used for writing needs and requirements of a particular type, the selection and use of attributes, standard abbreviations and acronyms, layout and use of figures and tables, layout of needs and requirements documents or databases and, need and requirement statement numbering.

在一系列需求和要求中使用的术语在本体或至少项目词汇表中进行定义。 Terms used throughout the sets of needs and requirements are defined in an ontology or at least a project glossary.

本规则所确定的特征 Characteristics that are established by this rule:

C4 - 完整 Complete

C5 - 单一 Singular

C9 - 符合 Conforming

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

C14 - 能够被验证 Able to be Validated

阐述 Elaboration:

属于同一类的需求和要求陈述应归为一组。这是在 RMT 或其他 SE 工具中组织需求和要求集的一个很好的原则。一种方法是根据需求的类型或类别将其分组。另请参阅 R29 和 R41 以及 NRM，了解有关组织需求和要求的更多指导。 Need and requirements statements that belong together should be grouped together. This is a good principle for organizing sets of needs and requirements within an RMT or another SE tool. One approach is to put requirements into groups based on their type or category. See also R29 and R41 and the NRM for more guidance on organizing needs and requirements.

一个示例分组可以是形式、适合性、功能、质量和合规性。参见 R41。这种分组迫使团队从每个角度审视系统，有助于确保集合的完整性。仅关注功能/性能和适合性的方法将导致需求和要求集不完整。 An example grouping could be form, fit, function, quality, and compliance. See R41. This grouping forces the team to look at the system from each of these perspectives helping to ensure completeness of the sets. Methodologies that only focus on function/performance and fit will result in incomplete sets of needs and requirements.

在功能分解中，功能/性能需求按产生它们的功能分组。 In functional decomposition, functional/performance requirements are grouped by the function that originates them.

按类型/类别分组有助于确保集合的完整性、集合内的一致性，并更容易识别缺失、重叠或冗余的需求。另请参阅 R29。 Grouping by type/category helps to ensure completeness of the sets, consistency within sets, and makes it easier to identify missing, overlapping, or redundant requirements. See also R29.

示例 Examples:

需求可能与以下方面相关 Requirements may be related by:

- 类型（例如，安全要求） type (for example, safety requirements);

- 场景（例如，由单一场景引起的要求） scenario (for example, requirements arising from a single scenario).

有关组织需求和要求的更多指导请参阅 R29 和 NRM。 See R29 and the NRM for more guidance on organizing needs and requirements.

本规则所确定的特征 Characteristics that are established by this rule:

C9 - 符合 Conforming

C10 - 完整 Complete

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

阐述 Elaboration:

一组组织良好的需求和要求可以让读者更好地理解整个内容，而不会给读者带来过度的认知负担。 A well-organized set of needs and requirements allows an understanding of the whole set to be assimilated without undue cognitive loading on the reader.

尽管已经说明了单个需求和要求陈述的完整性，但将其放在其他相关要求的背景下往往更容易理解。 Despite what has been stated about the completeness of individual need and requirement statements, it is often easier to understand when it is placed in context with other related requirements.

无论是在文档中还是在 RMT 中进行管理，将相关的需求或要求组合在一起的能力是识别需求或要求陈述之间的重复和冲突的重要工具。 Whether managed within a in document or within an RMT, the ability to draw together related groups of needs or requirements is a vital tool in identifying repetition and conflict between need or requirement statements.

用于组织需求和要求的模板将有助于确保您的需求集的一致性和完整性。 Templates for organizing needs and requirements will help ensure consistency and completeness of your requirement set.

有关组织需求和要求的详细讨论，请参阅 NRM。 Refer to the NRM for a detailed discussion on organizing needs and requirements.

另请参阅 R29、R39 和 R40 See also R29, R39, and R40

示例 Examples:

对于一系列需求或要求，可以定义一个大纲，按类别或类型对其进行组织。 For sets of needs or requirements, an outline can be defined that organizes them in categories or by type.

需求和要求的类型/类别的示例包括 Examples of Type/Category of needs and requirements include:

• 功能：功能/性能 Function: Functional/Performance.

• 适合：操作：与外部系统的交互 - 输入、输出、外部接口、操作环境、设施、人体工程学、与现有系统的兼容性、物流、用户、培训、安装、运输、存储。 Fit: Operational: interactions with external systems - input, output, external interfaces, operational environmental, facility, ergonomic, compatibility with existing systems, logistics, users, training, installation, transportation, storage.

• 质量（质量）：可靠性、可用性、可维护性、可访问性、安全性、保障性、可运输性、质量规定、增长能力。 Quality (-ilities): reliability, availability, maintainability, accessibility, safety, security, transportability, quality provisions, growth capacity.

• 形态：物理特征 Form: physical characteristics.

•合规性 Compliance:

• 标准和法规 - 政策和监管 Standards and regulations - policy and regulatory.
• 约束 - 对项目施加的约束，项目必须符合这些约束 Constraints - imposed on the project and the project must show compliance.
• 业务规则 - 企业或业务部门施加的规则 Business rules - a rule imposed by the enterprise or business unit.
• 业务要求 - 企业或业务部门施加的要求 Business requirements - a requirement imposed by the enterprise or business unit.

有关组织需求和要求的方法的更详细讨论，请参阅 NRM 第 4 和第 6 节。 Refer to the NRM Sections 4 and 6 for a more detailed discussion on this approach to organizing needs and requirements.

组织需求和要求的大纲可以来自国际标准或针对组织领域和该领域内不同类型产品量身定制的组织标准。（系统级需求和要求的组织可能与一组软件需求和要求的组织不同。） Outlines for organizing needs and requirements can come from international standards or an organizational standard tailored to the organization’s domain and different types of products within that domain. (The organization for system level needs and requirements may be different than the organization of a set of software needs and requirements.)

本规则所确定的特征 Characteristics that are established by this rule

C10 - 完整 Complete

C11 - 一致 Consistent

C13 - 易于理解 Comprehensible

C14 - 能够被验证 Able to be Validated