INCOSE需求编写指南-附录 C: 需求模式

附录 Appendix C: 需求模式 Requirement Patterns

C.1 需求模式简介 Introduction to Requirement Patterns

需求模式（样板或模板）的概念最初于 1998 年在英国的未来水面战斗人员 (FSC) 国防项目中应用（Dick 和 Llorens，2012 年），用于帮助解决编写不同类型的文本需求（及时性等）时的若干困难。一旦向需求编写者展示了如何根据其类型形成需求陈述的良好示例，编写正确格式的需求的困难就基本上克服了。 The notion of requirement patterns (boilerplates or templates) was initially applied within the Future Surface Combatant (FSC) defense project in the United Kingdom in 1998 (Dick and Llorens, 2012) as an aid to solve several difficulties when writing different types of textual requirements (timeliness, etc.). Once requirement writers are shown a good example of how to form a requirement statement based on its type, the difficulty in writing a properly formed requirement was largely overcome.

使用模式还可以开发 NLP/AI 工具或“数字助理”。这些工具与项目本体一起，可以帮助作者编写需求和要求声明，并帮助确保满足本指南中定义的规则和特征。 The use of patterns also enables the development of NLP/AI tools or “digital assistants”. These tools, along with a project ontology, can aid writers when writing need and requirement statements and helping ensure the rule and characteristics defined within this Guide are met.

可以在模式中定义“结构化和规范化”需求类型的示例。模式可以构造为占位符的顺序列表，包括单词以及句法或语义限制。这些占位符通常称为模式槽。需求文本是按照适合要传达的内容的需求模式编写的。 “Structured and normalized” examples of types of requirements can be defined in patterns. A pattern may be structured as a sequential list of placeholders, including words, along with syntactic or semantic restrictions. These place holders are generally called pattern slots. The requirement text is written per a requirement pattern that is appropriate to what is to be communicated.

例如，以下示例表示一个需求陈述和关联的候选模式。在此示例中，需求模式有 6 个模式槽。 For example, the following example represents a requirement statement and the associated candidate pattern. In this example, the requirement pattern has 6 pattern slots.

电源可用性应大于或等于 98%。 The Power_Supply shall have an Availability greater than or equal to 98%.

<子系统> <应> <具有> <a：可选> <物理属性> <操作符> <百分比>

<Subsystem> <shall> <have> <a: Optional> <PHYSICAL_PROPERTY> <OPERATOR> <PERCENTAGE>

目前，用于定义表示句法和语义层面的常见自然语言需求结构的抽象的术语还不够成熟。文献中采用了几种方法（请参阅本附录末尾的参考资料），目的类似。 Currently, the terminology for defining the abstractions that represent common natural language requirement structures at the syntactic and semantic level is not mature enough. Several approaches are used in the literature (see references at the end of this appendix) with similar intent.

一种常见的方法是使用“需求模板”。术语“模板”最常用于需求管理领域，指需求文档的结构和组织。使用此类模板有助于确保作者在组织一组需求陈述时考虑到所有关注点。对于需求陈述，一些作者创造了一个更详细的术语：“陈述级模板”，以避免与需求集模板混淆（Dick 和 Llorens，2012 年）。 One common approach uses “requirement templates”. The term “template” is most often used in the field of requirements management to refer to the structure and organization of a requirements document. The use of such templates helps ensure that the authors consider the complete range of concerns when organizing a set of requirement statements. For requirement statements, some authors have coined a more detailed term: “statement-level template” to avoid confusion with templates for requirement sets (Dick and Llorens, 2012).

在另一种方法中，Hull 等人（2002）使用“样板”来指代单个文本要求的语法结构。 In another approach Hull et al (2002) use “boilerplates” to refer to a grammatical structure for an individual textual requirement.

“模式”一词在软件（Gamma 等，1994）和最近的系统工程中具有明确的含义，通常表示一种可重复使用的结构，通过实例化和配置该结构以使其成为解决方案来解决问题。INCOSE 和其他组织提倡在系统工程生命周期中使用这个术语（INCOSE 模式工作组）。为了与这些用途保持一致，本指南使用术语“模式”来表示表示句法和语义信息（限制和属性）的常见自然语言需求结构的概念。 The term “pattern” has a clear meaning in software (Gamma et al, 1994) and recently systems engineering, usually representing a reusable structure that resolves a problem by instantiating and configuring this structure to become a solution. INCOSE and others promote this term for use in the system engineering lifecycle (INCOSE Patterns Working Group). To align with these uses, this guide uses the term “patterns” to represent the concept of common natural language requirements structures representing syntactic and semantic information (restrictions and properties).

正如本指南所述，有多种因素有助于实现高质量的需求陈述和需求集。帮助实现高质量需求陈述和需求集的一个重要方法是正确定义和约定需求必须遵循的一组需求模式。本附录提供了有关需求模式的更多详细信息。 As this guide describes, there are multiple factors that contribute to the realization of high-quality requirement statements and sets of requirements. One important way to assist in achieving high quality of requirement statements and sets of requirements is by the proper definition and agreement of a set of requirement patterns with which the requirements must comply. This appendix provides additional detail on requirement patterns.

本指南的多个部分都提到了需求模式的概念——模式用于确保需求和需求集遵循本指南中的规则，以便它们具有所需的特性。 The concept of a requirement pattern is mentioned in several sections of this guide— patterns are used to ensure that requirements and requirement sets obey the rules in this guide so that they have the desired characteristics.

C.2 使用模式形成需求陈述的好处 Benefits of Using Patterns to Form Requirement Statements

确保需求符合商定的模式有助于需求验证活动，并有助于确保需求有效地传达需求。此外，按照一组商定的模式编写需求还可以更轻松地完成以下工作： Ensuring that requirements conform to agreed-to patterns contributes to the requirement verification activity and helps to ensure the requirements effectively communicate needs. In addition, writing requirements following a set of agreed-upon patterns also makes it easier to:

• 编写简洁、易读且原子性强的需求说明 write concise, easy to read and atomic requirement statements;
• 在大型文档中查找和分类需求 find and classify requirements within a large document;
• 查找缺失的需求（完整性） find missing requirements (completeness);
• 在大量需求中查找不一致之处 find inconsistences within a large set of requirements;
• 查找重复的需求（以及查找和重用一般需求）；以及 find duplicated requirements (and finding and reusing requirements in general); and
• 跟进其他活动，例如分析和实施 follow with other activities such as analysis and implementation.

此外，遵循一组商定的模式还会产生一组一致的需求，并实现多项需求管理活动的自动化，例如： In addition, following a set of agreed-upon patterns also leads to a consistent set of requirements, and the automatization of several requirement management activities such as:

• 半自动需求验证，确保需求陈述具有本指南中定义的特征并符合其规则 the semi-automatic requirement verification that requirement statements have the characteristics and conform to the rules defined in this guide;
• 验证与所有系统生命周期中生成的系统工程工件相关的其他一致性和完整性规则（例如，模型中所述的需求与设计的一致性以及项目本体中定义的术语的一致使用） the verification of other consistency and completeness rules associated with systems engineering artifacts generated across all system lifecycles (e.g., consistency of requirements versus design as stated in a models and consistent use of terms defined in the project ontology);
• 从需求或非结构化文档中提取实体、属性等；以及 the extraction of entities, properties, etc. from requirements or unstructured documents; and
• 将需求翻译成不同的语言 the translation of requirements to different languages.

最后，需求模式还可以促进正确教授良好且常见的需求编写方式的过程，并利用一致的词汇。 Finally, requirement patterns can also facilitate the process of properly teaching a good and common way of writing requirements and leverage the use of consistent vocabulary.

C.3 需求模式的构建模块 Building Blocks for Requirement Patterns

在定义需求模式的语法时，必须考虑递归。从这个意义上讲，需求模式可能由更小的模式（构建块）组成（如果需要），这些更小的模式也可以进一步拆分为更小的块。 When it comes to defining the grammar of a requirement pattern, recursion has to be considered. In that sense, requirement patterns may be made up, if necessary, of smaller patterns (building blocks) that can also be further split in even smaller blocks.

这使得需求模式更加模块化和可重用，因为不同类型的需求可以共享一些共同的构建块，同时也具有独特的元素。 This makes requirement patterns more modular and reusable, since different types of requirements can share some common building blocks, whilst also having unique elements.

例如，某些特殊类型的需求可能（可选）包含性能信息。如果将性能信息表示为第二级模式，则​​可以获得以下几个优点： For example, some special types of requirements may include (optionally) performance information. If the performance information is represented as a second level pattern, several advantages can be gathered:

• 该第二级模式可能会在不同的顶级模式中重复使用 This second level pattern might be reused among different top-level patterns.
• 可以定义第二级模式的变体，从而扩展整个模式目录的“表现力”，而无需改变顶层模式 Variations of the second level pattern can be defined yet extending the ‘expressivity’ of the entire catalog of patterns, with no need of changing the toplevel ones.

幸运的是，本附录中提到的递归并不太深；只需几个层次就足以提供一组灵活且可重用的模式目录。通常，复杂模式由子模式组成，简单模式由简单限制组成，定义一组构建块。构建这些模式目录的方式（自下而上、自上而下、迭代等）由每个组织根据其特定需求决定。 Fortunately, the recursion referred in this appendix is not too deep; just a few levels should be enough to provide a set of flexible and reusable catalog of patterns. Usually, the complex patterns are formed by sub-patterns and the simple patterns are formed by simple restrictions, defining a set of building blocks. The way to construct these patterns catalog (bottom up, top down, iterative, etc.) is left to each organization based on their specific needs.

作为示例，图 C-1 显示了可能位于模式目录中的用作构建块的子模式的结构。 As an example, Figure C-1 shows the structure of sub-patterns used as building blocks that may be in a catalog of patterns.

根据商定的模式编写需求是一种很好的方法，可以产生一组一致的需求。但是，如果用于指定需求的实际词语和概念使用不一致，处理一致的模式基本上是没有意义的。每个组织都必须在知识管理流程范围内解决这一挑战。必须在模式中实现此通用本体，以用于记录和管理需求开发和系统工程流程活动。 Writing requirements based on agreed patterns is a good approach that will result in a consistent set of requirements. However, dealing with consistent patterns is largely pointless if the actual words and concepts used to specify a requirement are not used consistently. Every organization must solve this challenge within the scope of the knowledge management process. This common ontology must be implemented within the schema to be used to document and manage the requirement development and systems engineering process activities.

需求模式的其他来源包括 Other sources of requirement patterns are:

• Jeremy Dick, Juan Llorens, "Using Statement-level Templates to Improve the Quality of Requirements", International Conference on Software and Systems Engineering and Applications. ICSSEA 2012, Paris, France.
• Hull et al: Requirements Engineering, Springer, 2012.
• “EARS – Easy Approach to Requirements Syntax”, http://ieeexplore.ieee.org/document/5636542/
• The PABRE Catalog: http://www.upc.edu/gessi/PABRE/index.html
• ARTEMIS CRYSTAL EU Research Project: http://www.crystal-artemis.eu/