【需求专题】如何写好需求——INCOSE需求编写指南（1）

已剪辑自: https://mp.weixin.qq.com/s/Z5VBTyV6j07JylDdOsFSxQ

【编者按】 如何写好需求是INCOSE 需求工作组编写的需求文本化表达指南。本指南是专门讲述如何在系统工程中对需求进行文本化表达，其目的是从现有的各种标准中得出一个单一的，全面的规则，从而对需求编写工作提出建议。如何写好需求指南不是关于需求捕获、抽取或发现的，也不是关于需求分析以及建模与设计的。它侧重于如何用文本将需求表达清楚、准确，以便于后续进一步的需求分析。如何写好需求指南是在INCOSE需求工作组的专家们基于广泛的需求实践提炼而成，可以应用到更广范围内知道需求过程。 本指南是由 何强 根据INCOSE（国际系统工程协会）需求工作组的成果《INCOSE_RWG_Guide_for_Writing_Requirements 20130126》进行翻译整理，《INCOSE_RWG_Guide_for_Writing_Requirements 20130126》翻译整理，该成果是INCOSE产品，仅限于INCOSE成员和那些INCOSE企业顾问委员会成员组织的员工使用。因此，本文的发布仅作学习用途，若存在任何问题请联系管理员，我们将作相应处理。

1. 为什么需要文本化需求

自然语言并不是表达需求的完美的方式。要明确、准确、避免歧义这很难。然而，它仍然是目前唯一的能够涵盖各种所需概念的通用表达方式。

可以替代书面表达需求的方式包括：

• 具有完善语言定义的图形建模方法，如SysML。
• 模板结构的表格格式收集和描述需求，如汤姆·吉尔的P语言（Tom Gilb’s Planguage ，Gilb，T.，2005）。

这些其他的方法也不完善：模型尚未能覆盖概念所需要的范围，表格的呈现格式，追溯和管理也都存在问题。

事实是，如果仅仅是为了补充其他的表达方式，则仍然需要文本化需求。文本的优点是：

• 对可以表达的概念没有任何限制。
• 句子和语法结构提供了一种可以追踪有意义的元素的方法。

本指南仅指文本化需求的表达。

2.需求条目的特点

2.1 C1-必要性

基本原理：
如果去掉这条需求仍能够满足问题，那么这条需求就不是必须的如果需求条目所要表达的意图已经在其他需求条目中描述了，那么这条需求就不是必须的如果不能找到为什么需要这条需求的原因，那么这条需求也不是必须的每一条需求都会有相应的成本;不必要的需求可能导致没有价值的额外工作，增加成本与不必要的风险

策略：
没有什么本质的特征可以表明需求是必须的。每一条需求都需要根据利益相关者真实的期望不断地进行调整。在需求的最高层级，这一特点仅被用来在评审每一条需求时，针对相应的需要、目标、目的以及驱动者、约束、概念以及系统范围内的场景定义进行确认。如果顶层需求不能在上述范围内被追踪到，那么这条需求就不是必须的。在较低的层级，需求的必要性表现为可以追述到更高层级的需求。需求从一层到另一层的可追溯性能够支持每一条独立需求覆盖的充分性与必要性原理。这一原理也可以帮助表达需求的必要性及需求条目的意图。

2.1 C2-与实现无关

仅描述需要，而不是需求如何被满足。

基本原理：
如果在需求中描述如何实现至少有以下不良影响：错过考虑其他更好的实现方式的机会; 不能解决真正的问题.如果在本层级没有很好地沟通需要什么（“What”），那就不能正确地将需求往下一层分配

策略：
只捕获那些在任何方案中都必须正确满足的功能、特征与约束。一个很有用的提问**——“需求用于什么目的”？**如果是在需求中描述了实现的话，那这个问题的答案就是真正的需求。如果是有效的需求，只是层级比较低。那就需要确定合适的层级以及在本层级描述需求。也就是说需求要跟系统层级匹配，不要描述太细节的内容。

支撑这一特征的规则
R3 - /精确/主体使需求的主题与需求所在的层级相适应.
R33 - /抽象/问题域词汇如果在问题域，表达问题被解决要使用问题域的词汇而不要涉及到解决方案
R34 - /抽象/解决方案域词汇如果在解决方案域，表达系统层级的解决方案使用系统的词汇

**
**

2.3 C3 –清晰的（无二义性）

一条需求仅能有唯一的一种解释。

基本原理：
需求的意图必须在编写者、设计者以及验证者之间按照同一种方式理解，模棱两可会因为需求的解释不是客户的真实意图而导致项目延期、成本增加等问题。

策略：
减少模棱两可有很多方法，包括：使用正确的语法; 使用术语中定义的术语或缩略语;使用精确的数量词与限定符;使用一致的语言表达形式; 避免使用含混的术语;避免使用代词. 精确的表达有很多好的实践方法，包括：每一条需求用一个单一的句子描述, 使用主动语态,不使用形容词和副词，精简多余的表达理由、目的以及举例的辅助信息或从句;使用独立的子条款来表达条件、性能或约束;适当的使用图形与图标来表达.

支撑这一特征的规则
R1 - /精确/使用定冠词 使用定冠词.
R2 - /精确/使用主动语态 使用有明确确定的参与者的主动语态.
R4 - /精确/使用定义过的术语 只使用术语表中定义过的术语.
R5 - /精确/量化避免不精确的量词.
R6 - /精确/单位描述数量时使用适当的单位.
R7 - /精确/避免副词避免副词.
R8 - /精确/避免形容词避免形容词
R9 - /精确/无例外条款避免例外条款.
R10 - /精确/无开口避免开口条款.
R11 - /简明/无不定式避免多余的不定式.
R12 - /简明/单独条款针对每一种条件使用子条款.
R13 - /无歧义/正确的语法使用正确的语法.
R14 - /无歧义/正确拼写使用正确的拼写.
R15 - /无歧义/正确的标点使用正确的标点
R16 - /无歧义/连接词使用 ‘X 和 Y’，而不是’两者都’
R17 - /无歧义/避免和/或r避免使用 ‘X 和/或 Y’.
R18 - /无歧义/”/”避免使用斜线分隔符号(“/”).
R30 - /条件/明确清楚要给出明确的满足条件，而不是仅列出条件清单.
R35 - /量词/避免全称量词使用“每一个”而不是“全部”、“都”、“任何”等全称量词.

2.4 C4 –完整

一条需求要完整地描述需求本身的内容。

基本原理：
需求相关的一系列过程，如分解、分配、验证，依赖于对独立描述的完整理解而不依赖于其他的描述.注意，需求可以参考其他的文档，如，接口定义文件、标准、规则等。

策略：
一条需求描述本身就应该是一个完整的句子，对于这条需求的理解不需要参考其他需求的信息。需求不能通过代词被参考。

例外
完整性和唯一性性需要平衡，目前已经使用模块化方式来保证相关需求的分组。

支撑这一特征的规则
R6 - /精确/Units 描述数量时使用适当的单位.
R7 - /精确/避免副词 避免副词.
R8 - /精确/避免形容词 避免形容词
R9 - /精确/无例外条款避免例外条款.
R10 - /精确/无开口避免开口条款.
R26 - /完整/避免使用代词在需求陈述中，全部重复名词而不是使用代词来指代.
R27 - /完整/使用需求标题避免使用标题支持子条款需求的解释.
R29 - /条件/明确清楚描述适用条件必须明确，而不是从上下文进行推断.

2.5 C5 –唯一性

基本原理：
分解、分配、验证和确认等与需求相关的几个过程的有效性依赖于需求的唯一性。

策略：
一条需求只描述一个功能、特征或约束。要理解需求的可追溯性。可以使用项目标准模板来编写需求。虽然一条需求只包含一个功能、特征或约束，但是可能有多个从属条件满足需求避免使用‘和’这样的链接词连接多个短语或句子表达多重意思。

例外
完整性和唯一性性需要平衡，目前已经使用模块化方式来保证相关需求的分组。
唯一性与上下文需要平衡，有时文本并不是表述复杂行为的最好方法，这时需要参考模型或设计。

支撑这一特征的规则
R19 - /一致/简单句子 用简单的肯定的陈述句写需求，各种条件与约束用子条款描述.
R20 - /一致/避免使用关系连接词 避免使用关系连接词.
R22 - /一致/避免目的短语 避免使用表达目的的短语.
R23 - /一致/避免括号“（）” 避免使用“( ) ” 来描述子条款.
R24 - /一致/列举 能够明确列举出来的就不要用概述的方式.
R47 - /表达一致/风格指南 使用项目范围的风格指南.

2.6 C6 –可行

需求描述的内容在本质上是可行的。

基本原理：
本质上不可行的需求，如，100% 的可靠性，浪费时间，甚至导致不必要的昂贵解决方案不切实际的问题通常都是重要的问题没有很好地进行量化。

策略：
可行性/可达性可以通过成本、计划、技术和风险等方面的因素来衡量，使用现有的技术和工程方法可以对需求的可达性进行评估，如果不具备可达性，那这条需求不是好的需求。。通常来说在没有对潜在解决方案进行分析和考量的情况下无法确定一条需求的可行性，但是我们可以从基本面上识别出那些不可能实现或不切实际的需求。

支撑这一特征的规则
R28 - /现实的/避免绝对 避免使用绝对的不现实的词.

2.7 C7 –可验证

需求是可验证的。

基本原理：
除非需求在某些方面是可验证或可测试的，否则没有办法判断它是否被满足。因此对于不同类型的需求需要以不同的方式来证实。功能需求，通常都要通过测试来验证产品正确的行为，所以功能需求的行为一定要表达清楚；而性能需求需要明确地表达与性能相关的数量。

策略：
需求不可验证最常见的原因：没有明确的正确功能的行为、条件与状态；缺乏正确数量的范围；使用了有歧义的描述. 站在验证者的角度来想象自己如何进行验证 (分析、检验、演示、测试)。 要关注需求的量化与公差范围，有两方面原因：1)多个需求之间可能需要权衡，以权衡空间的方式提供了公差或限制，很少有绝对的数量要求。值的范围通常反映了提供不同性能的水平。2)测试对于一个绝对值通常是不可能的，定义值的上下限可以让测试更容易 可以尝试问这样对问题：*我如何知道需求被满足了？*如果需求被正确的量化了，就会对这个问题提供一个很精确的回答。*什么是强制性的和什么样的性能需求水平是令人满意的？*这个回答可能有多个值，在需求中所描述的公差于权衡空间。*我要验证的是什么?*如果没有，那么重写这条需求，表达出你真实的意图。

支撑这一特征的规则
R1 - /精确/使用定冠词 使用定冠词.
R2 - /精确/使用主动语态 使用有明确确定的参与者的主动语态.
R4 - /精确/使用定义过的术语 只使用术语表中定义过的术语.
R5 - /精确/量化 避免不精确的量词.
R6 - /精确/Units 描述数量时使用适当的单位.
R7 - /精确/避免副词 避免副词.
R8 - /精确/避免形容词 避免形容词
R9 - /精确/无例外条款 避免例外条款.
R10 - /精确/无开口避免开口条款.
R30 - /条件/明确清楚要给出明确的满足条件，而不是仅列出条件清单条件.
R36 - /公差/值的范围定义正确的数量范围.
R37 - /量化/可度量的提供具体的可度量的性能目标.
R38 - /量化/避免无限时间明确地定义时间限制，而不是使用无限时间的关键词.

2.8 C8 –正确性

需求是对利益相关者期望的正确表达。

基本原理：
这一特性是对必要性原则的补充，需求所描述的功能或性能值必须是正确的。 这一特性关系到利益相关者期望的验证，验证系统设计与构建满足需求。

策略：
确保以下内容：基于对高层需求的正确解释与理解进行需求分解与派生;对根本目标的正确理解 (如，最小、最大);正确的分析与假定。使用预先定义的需求验证流程来保证需求在上下文环境中的正确性。

支撑这一特征的规则
R6 - /精确/Units 描述数量时使用适当的单位.
R36 - /公差/值的范围 定义正确的数量范围.
R42 - /可追踪/外部参考 针对可识别的元素参考外部文档.

2.9 C9 –合规

需求要符合组织所选择的适用标准。

基本原理：
当所有需求都同组织内特定领域的标准相符合时，每一条需求就更容易编写、理解与评审。

策略：
使用组织内的模板写需求。

支撑这一特征的规则
R43 - /表达一致/要点 使用一致的惯例或约定来区分相对重要的需求.
R44 - /表达一致/一致的术语 使用术语表定义一致的术语应用到需求描述中.
R45 - /表达一致/首字母缩略语 使用首字母缩略词表来定义一致的缩略词应用到需求描述中.
R46 - /表达一致/缩略语使用缩略语列表来定义一套一致的缩略语用于需求描述.
R47 - /表达一致/风格指南使用项目范围的风格指南.

声明：以上内容来源于系统工程 ，如有侵权请联系删除。