在上一篇文章中，分享了“单个需求的需求特征 (Characteristics of requirements)”，本文介绍：当把众多的单个需求放在一起，形成的 需求集合的需求特征 (Characteristics of requirements)以及为实现这些需求特征，有哪些推荐的，可以指导实践的规则。

需求特征的分类

说明：关于需求特征分类的解释，请参考上一篇文章。

C10 – Complete (完整的)

需求集合中包括的需求，需要是 Complete(完整的) ，意味着这个需求集合能充分描述其所必要的能力、特征、功能、性能、约束、条件等。

需求集合是Complete(完整的)：

• 需求集合中包括的需求是完整的，未有缺失的需求
• 需求集合中的每个需求，都是Complete(完整的) – 参考C4
• 需求集合中的每个需求，都是Necessary(必要的) – 参考C1。即：需求集合中包括了所有必要的需求，排除了所有不必要的需求。

C11 – Consistent (一致的)

需求集合中包括的需求是 Consistent (一致的) ，意味着：

• 需求集合中的每个需求，都是唯一的，独一无二的
• 需求集合中的需求之间，没有冲突，没有重叠
• 需求集合中的所有需求，使用的是一致的单位/度量等的表达
• 需求集合中的所有需求，遵循一致的需求描述方式、术语、词汇表等

C12 – Feasible (可行的)

需求集合中包括的所有需求，在项目的约束条件内是可实现的，约束条件可包括例如：成本、进度、技术、法律、道德、安全等。

C13 – Comprehensible (可理解的)

需求集合中的需求，必须明确表达：对某实体的期望和要求、需求之间的关系、该实体与外部系统之间的关系等。

C14 – Able to be validated (可被确认的)

需求集合是 Able to be validated (可被确认的) ，意味着：必须能够在可接受风险的约束条件下（如成本、进度、技术和法规遵从性等），确认该需求集合，可以实现其上一层级的需求集合。

例如：

在项目中，是基于“Stakeholders Requirements(相关方需求)” --> “System Requirements (系统需求)”，则：要能够对“System Requirements(系统需求)”进行确认，来确认其可以实现“Stakeholders Requirements(相关方需求)”的 意图 。

C15 – Correct (正确的)

需求集合是 Correct (正确的) ，意味着：需求集合，必须是其所依据的上一个层级需求集合的准确和明确的表达。

需求集合是正确的，意味着：

• 需求集合未包含不正确的信息
• 需求集合中未有遗漏所需信息
• 需求集合中每个需求都是正确的（C8）

例如：

在项目中，是基于“Stakeholders Requirements Set(相关方需求集合)” --> “System Requirements Set (系统需求集合)”，则：需要以“Stakeholders Requirements Set(相关方需求集合)”为判定准则，判断“System Requirements Set (系统需求集合)是否是对的。

前面两篇文章中，分享了：单个需求的需求特征、需求集合的需求特征。

本文讨论：为实现这些需求特征，有哪些推荐的，可以指导实践的规则。

规则类别1 – Accuracy (准确性)

R1 – Structured Statements (结构化的陈述)

需求描述语句必须符合约定的模式(pattern)，从而使得需求描述，是一个结构良好的完整语句。

需求描述的Pattern，例如：

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

R2 – Active Voice (主动语态)

需求描述语句，需要使用主动语态。

这样可以明确需求的主体(subject)， 更容易确认需求描述是否完整，更容易保证需求的合适性(Appropriate)。

例如：

• 在xx条件下，BMS软件需要在5ms内，切断接触器。
• 切断接触器，是“BMS软件”的行为吗？

R3 – Appropriate Subject Verb (恰当的动词)

需求描述语句中要使用恰当的适合于主语(subject)的动词。

例如：如果是使用英文来描述需求的话，则可以使用“shall”, “must”，但不能使用“can”, “may”等。

R4 – Defined Terms (使用定义的术语)

需求描述语句中使用的术语，都需要被定义。

例如：

• 在xxx条件下，<yyy system>需要提示出当前时间信息。
• 时间的format？精度？是否需要考虑时区？--> 时间信息，可以定义为术语

R5 – Definite Articles (定冠词)

如果是使用英文来描述需求的话，则需要使用定冠词(“the”)，而不能使用不定冠词(“a”)。

这个规则，是为了使需求的描述更具体、更聚焦。

R6 – Common Unit of Measure (通用的计量单位)

需求描述中，如果包括对“数量”的描述时，那么数字应该使用适当、一致的计量单位。

R7 – Vague Terms (笼统的措辞)

需求描述中，应避免使用笼统的措辞。

例如：

• BMS系统需要将电芯的 相关数据 ，每隔50ms，传送给 Dashboard 。

R8 – Escape Clauses (例外条件)

需求描述中，避免使用一些模糊条件或可能性的免责条款，如“尽可能”、“尽可能少”、“在可能情况下”、“尽量多”、“必要时”、“在必要的范围内”、“按要求”等。

R9 – Open-Ended Clauses (开放式条款)

需求描述中，避免使用开放式条款，例如：在需求描述中不能使用“等…”、”包括但不限于”等内容。

规则类别2 – Concision (简洁)

R10 – Superfluous Infinitives (多余的不定式)

需求描述中，避免使用多余的不定式，如“被设计成”、“能够”、“有能力”、“使能”、“允许”。

例如：

• BMS系统，能够每10ms，将XX数据，发送给Dashboard。
• BMS系统，每隔10ms发送XX数据，如果发送了10次，只有1次成功，这个需求算不算满足呢？

R11 – Separate Clauses (单独条款)

需求描述中，如果存在多个条件时，对每个条件都应单独进行描述。

例如：

• 在充电状态时，BMS系统，需要根据充电状态，每10ms向 Charger 发送精度是0.1Y或0.01Y的XX数据。
• 什么情况下发送0.1Y精度的数据，什么情况下发送0.01Y的数据？

规则类别3 – Non-ambiguity (无歧义)

R12 – Correct Grammar (正确的语法)

为避免歧义，陈述需求的语句，需要使用正确的语法。

例如：

• The <xxx website> shall only use Approved Fonts.

有几种可能的理解呢？only是对什么的限制？

R13 – Correct Spelling (拼写正确)

为避免歧义，陈述需求的语句中，不能有别字、错字等。

R14 – Correct Punctuation (正确的标点符号)

为避免歧义，陈述需求的语句中，需要正确的使用标点符号。

R15 – Logical Expressions (逻辑表达式)

需求描述中，需要 使用已定义的规则来表示逻辑表达式，例如：”[X AND Y]”、“[X OR Y]”，”[X XOR Y]”等。

R16 – Use Of “Not” (“不”的使用)

需求描述中，不使用“不”。

R17 – Use Of Oblique Symbol (“/”的使用)

需求描述中，不使用“/”。

规则类别4 – Singularity(单一性)

R18 – Single Thought Sentence (单一意思的语句)

一个需求描述中，只是包括一个要求（或者说，只包括一个idea）

R19 – Combinations (组合)

需求描述中，避免使用连接词，例如：和(and)、或者(or)等。

例如：

• The <xxx system> shall display the Location and Identity of the Lead Vehicle.

解释：

• 显示Location，和显示Identity是2个需求，不能合在一起。 有些时候，这两个需求的验证方式是不一样的，合在一起不利于需求的验证。
• 该需求中还存在另外一个问题：没有明确说明如何显示（即：显示的format）

R20 – Purpose Phases (表达目的的短语)

需求描述中，避免使用“表达目的”的短语。

例如：

• The Record_Sub system shall display the Name of each Line_Item so that the Operator can confirm that it is the correct Item.

R21 – Parentheses (从属文本)

需求描述中，避免使用包含从属文本的括号和方括号。

例如：

• When the Water_Temperature exceeds 85 °C (usually towards the end of the boiling cycle) , the Control_Unit shall disconnect power from the Boiler within <xxx ms>.

R22 – Enumeration (枚举)

需求描述中，需要把所有情况都枚举（罗列）出来，逐一说明。不能笼统的说。

例如：

• The thermal control system shall monitor system temperature.
  • monitor什么？
  • 什么是monitor?

• The thermal control system shall manage temperature-related functions.
  • 要manage哪些功能？
  • manage是指什么？

R23 – Supporting Diagram, Model (支持的图表、模型)

当需求内容复杂时，需要使用图表、模型等方式配合需求描述。

规则类别5 – Completeness (完整性)

R24 – Pronouns (代词)

需求描述中，避免使用人称代词和不定代词，如：他、她、它、这个、那个、所有的。

R25 – Headings (标题)

避免依赖标题来支持对需求的解释或理解。

规则类别6 – Realism (现实考虑)

R26 – Absolutes (绝对的)

避免使用无法实现的绝对的表达方式。

例如：

The <xxx system> shall have 100% availability.

规则类别7 – Conditions (条件)

R27 – Explicit Conditions (显示的、明确的条件)

明确说明条件的适用性，而不是将适用性留给读者依赖上下文进行推断。

例如：

• The Free_Access_Mode shall be set to ON within <xxx ms>. 

这个需求，需要满足什么条件才能触发呢？

R28 – Multiple Conditions (多个条件)

当需求的触发，需要多个条件时，需要明确：这多个条件之间是什么关系，例如：是AND的关系，还是OR的关系。

规则类别8 – Uniqueness (唯一性、独特性)

R29 – Classification (分类)

根据所解决的问题的某种考虑，对需求进行分类。

例如：

• 按照功能性需求、非功能性需求进行分组
• 对功能性需求，按照Input、Process、Output进一步分组
• 按照ASIL等级，对需求进行分类

R30 – Unique Expression (唯一)

每个需求的描述，有且只有一次。

规则类别9 – Abstraction (抽象)

R31 – Solution Free (实现的自由)

除非真的对设计和实现有约束，否则避免在需求描述中包括“设计和实现”的内容。

例如：

• 系统需求中， 不包括 系统架构设计的内容、也 不依赖 系统架构设计的内容。

规则类别10 – Quantifiers (量词)

R32 – Universal Qualification (普适性)

当要进行普适性的描述时，使用”each”，而不是“all”、“any”或“both”。

例如：

• The Operation_Logger shall record any (or all)  warning messages.
• 调整改进后 -->
• The Operation_Logger shall record each Warning_Message. (注：Warning_Message需要被定义，这样本条需求才是确定的)

规则类别11 – Tolerance (容忍)

R33 – Range of Values (值的范围)

需求描述中使用数量的时候，需要明确值的范围。

规则类别12 – Quantification (量化)

R34 – Measurable Performance (可测量的性能)

需求描述中包括性能指标时，需要定义具体的可测量的性能目标，这样才能根据这些可测量的目标进行验证。

例如：

• The <xxx system> shall use minimum power.
• 调整改进后 -->
• The <xxx system> shall consume less than or equal to 50W of mains power.

R35 – Temporal Dependencies (时序上的依赖)

显式的、明确的定义时序依赖关系，而不是使用不确定的时序表达。

例如：

• Continual operation of the pump shall eventually result in the tank being empty.
• 调整改进后 -->
• The Pump shall remove greater than 99% of the Fluid from the Tank in less than 3 days of continuous operation.

规则类别13 – Uniformity of Language (语言的统一性)

R36 – Consistent Terms and Units (一致的术语和单位)

R37 – Acronyms (首字母缩写)

R38 – Abbreviations (缩略语)

需求集合的每个需求，以及整个项目生命周期的开发和测试活动中，使用一致的术语和度量单位、首字母缩写、缩略语等。

R39 – Style Guide (风格指南)

需求集合中的每个需求，都采用一致的需求描述风格。

R40 – Decimal Format (十进制格式)

使用一致的格式来规范十进制数字的描述。

例如：

• 当精度要求是0.01的时候，数字”512”的表达方式应该是”512.00”。

规则类别14 – Modularity (模块化)

R41 – Related Requirements (相关的需求)

对需求进行分组或分类时，将相关的需求，放在一起。

例如：

• 按照类型分类，包括：基础功能、高级功能、Safey需求、Cybersecurity需求等
• 按照场景对需求进行分类
• 按照Input、Output、Process进行分类

R42 – Structured Sets (结构化集合)

按照已定义好的结构，对需求进行分类。

例如：

• 功能性需求，包括：功能需求 + 性能需求
• 非功能需求 – 质量需求，包括reliability, availability, maintainability, accessibility, transportability
• 合规性需求