INCOSE需求编写指南.docx
《INCOSE需求编写指南.docx》由会员分享，可在线阅读，更多相关《INCOSE需求编写指南.docx（56页珍藏版）》请在冰豆网上搜索。
INCOSE需求编写指南
INCOSE需求编写指南
2015-10-17系统工程
【编者按】
如何写好需求是INCOSE 需求工作组编写的需求文本化表达指南。
本指南是专门讲述如何在系统工程中对需求进行文本化表达，其目的是从现有的各种标准中得出一个单一的，全面的规则，从而对需求编写工作提出建议。
如何写好需求指南不是关于需求捕获、抽取或发现的，也不是关于需求分析以及建模与设计的。
它侧重于如何用文本将需求表达清楚、准确，以便于后续进一步的需求分析。
如何写好需求指南是在INCOSE需求工作组的专家们基于广泛的需求实践提炼而成，可以应用到更广范围内知道需求过程。
本指南是由何强根据INCOSE（国际系统工程协会）需求工作组的成果《INCOSE_RWG_Guide_for_Writing_Requirements20130126》进行翻译整理，《INCOSE_RWG_Guide_for_Writing_Requirements20130126》是INCOSE产品，仅限于INCOSE成员和那些INCOSE企业顾问委员会成员组织的员工使用。
因此，本文的发布仅作学习用途，若存在任何问题请联系管理员，我们将作相应处理。
1.为什么需要文本化需求
自然语言并不是表达需求的完美的方式。
要明确、准确、避免歧义这很难。
然而，它仍然是目前唯一的能够涵盖各种所需概念的通用表达方式，。
可以替代书面表达需求的方式包括：
•具有完善语言定义的图形建模方法，如SysML。
•模板结构的表格格式收集和描述需求，如汤姆·吉尔的P语言（TomGilb’sPlanguage，Gilb，T.，2005）。
这些其他的方法也不完善：
模型尚未能覆盖概念所需要的范围，表格的呈现格式，追溯和管理也都存在问题。
事实是，如果仅仅是为了补充其他的表达方式，则仍然需要文本化需求。
文本的优点是：
•对可以表达的概念没有任何限制。
• 句子和语法结构提供了一种可以追踪有意义的元素的方法。
本指南仅指文本化需求的表达。
2.需求条目的特点
2.1 C1–必要性
每一条需求都是必须的。
基本原理：
∙如果去掉这条需求仍能够满足问题，那么这条需求就不是必须的
∙如果需求条目所要表达的意图已经在其他需求条目中描述了，那么这条需求就不是必须的
∙如果不能找到为什么需要这条需求的原因，那么这条需求也不是必须的
∙每一条需求都会有相应的成本;不必要的需求可能导致没有价值的额外工作，增加成本与不必要的风险
策略：
∙没有什么本质的特征可以表明需求是必须的。
每一条需求都需要根据利益相关者真实的期望不断地进行调整。
∙在需求的最高层级，这一特点仅被用来在评审每一条需求时，针对相应的需要、目标、目的以及驱动者、约束、概念以及系统范围内的场景定义进行确认。
如果顶层需求不能在上述范围内被追踪到，那么这条需求就不是必须的。
∙在较低的层级，需求的必要性表现为可以追述到更高层级的需求。
需求从一层到另一层的可追溯性能够支持每一条独立需求覆盖的充分性与必要性原理。
这一原理也可以帮助表达需求的必要性及需求条目的意图。
2.2 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-/表达一致/风格指南
使用项目范围的风格指南.
【后记】
由于中英文语言环境的差异，部分需求编写规则在中文语言环境下并不特别适用
需求的多样性意味着规则必须不断地去适应特定的情况。
基于这一现实，指南中仅仅介绍了一些基本的特征与属性
3.需求集的特点
3.1 C10–完整性
需求集是对利益相关者期望的完整诠释。
基本原理：
这个特性确保所有的特定、约束、功能等都包含在需求集中。
需求集如果有遗漏的话，需要考虑两方面问题：
∙是否所有需求都捕获到了？
∙是否所有的需求都派生出来了？
策略：
对于顶层需求，完整性只能通过建模以及同客户和所有利益相关方一起进行评审的方式来处理。
∙在定义项目范围时，要保证所有的利益相关者都被识别；
∙确保从所有利益相关者视角的场景都被开发了，包括在所有生命周期阶段名义和非名义上的所有操作。
∙识别所有外部接口，确保每一个接口都被定义，每一个给定接口的互操作都被包含在接口需求中
对于低层级的需求，可以通过从低层需求项高层需求的追踪关联来保证需求的完整性。
∙需求标题的使用也有助于确保需求的所有方面。
∙根本目的就是通过清晰的沟通达成利益相关者最小的、充分必要的期望，而不是更多
支撑这一特征的规则
R40-/可追踪/父子关系
建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.
3.2 C11–一致性
需求集是对利益相关者期望的一致性表达。
基本原理：
∙客户和其他利益相关者的需求或设计约束通常会彼此冲突，如果不能在开发早期尽早发现并解决，会导致昂贵的返工。
∙此外，即使每一个需求是无歧义的，但是如果使用不一致的术语或缩略语也会导致整个需求集不一致。
策略：
∙确保相同的或非常相似的需求不在不同的地方重复。
∙一个策略就是根据需求种类进行分类，如，完全性、及时性、功能区的等；
∙然后使用排序和过滤的方法将多样化的需求联系在一起，并检查他们的交互，权衡以及冲突；
∙使用术语表来保证术语和缩写的一致性
∙对接口需求特别注意，要确保与其他系统描述的接口需求是一致的。
支撑这一特征的规则
R4-/精确/使用定义过的术语
只使用术语表中定义过的术语.
R44-/表达一致/一致的术语
使用术语表定义一致的术语应用到需求描述中
R45-/表达一致/首字母缩略语
使用首字母缩略词表来定义一致的缩略词应用到需求描述中
R46-/表达一致/缩略语
使用缩略语列表来定义一套一致的缩略语用于需求描述
R47-/表达一致/风格指南
使用项目范围的风格指南
3.3 C12–可行
需求集是对利益相关者期望的可行的表达。
基本原理：
∙如果不能在开发早期发现不可行的需求，则会在后期带来成本和费用上的浪费。
∙即使每个单一的需求是可行的，也不能保证由它们组成的需求集是可行的。
例如，下面是可行的单个笔记本需求：
a.重量不超过1.4kg，1TB存储容量，4GRAM，一个无线网网络接口，一个以太网接口，一个USB接口，一个HDMI 接口，可以从1米高空坠落没有损坏，可以在±50°C 的环境温度下工作，零售价低于500美元。
b.虽然每个需求看上去都完全可行，但即使是非专业人员乍一看，也不会轻易相信这个需求集是可行的（也就是说同时满足所有需求）。
策略：
∙在解决方案域，最好有多个可实现的解决方案，至少也要有一个；
∙这个解决方案在项目相关约束条件是可行的（如，成本、进度、技术以及法规符合），并且技术成熟度和项目目标也是匹配的。
支撑这一特征的规则
R28-/现实的/避免绝对
避免使用绝对的不现实的词.
R31-/唯一/分类
根据问题或系统解决的不同方面对需求进行分类.
R32-/唯一/只描述一次
每一个需求只描述一次.
R36-/公差/值的范围
定义正确的数量范围.
R37-/量化/可度量的
提供具体的可度量的性能目标.
3.4 C13–有边界
需求集一定要在一个已定义的范围内。
基本原理：
∙需求集要清晰地传达设计团队、客户和其他利益相关者在系统定义范围内的期望，必须包括所有必要的需求，要排除不相干的要素。
∙这一特点的目的就是要避免对工作范围的误解，防止资源消耗与浪费到系统范围之外。
策略：
∙在写需求前开发和定义基线范围，范围要清晰地反应利益相关者需求。
一旦范围基线确定（利益相关者同意），就可以根据这一范围基线来写需求。
范围确定的时候，要跟踪需求到相应的范围内容。
∙背景图在定义范围的时候很有用，可以显示正在开发的系统与其他系统之间的交互，帮助确定哪些是系统关注的，哪些不是。
支撑这一特征的规则
R44-/表达一致/一致的术语
使用术语表定义一致的术语应用到需求描述中.
R45-/表达一致/首字母缩略语
使用首字母缩略词表来定义一致的缩略词应用到需求描述中.
R46-/表达一致/缩略语
使用缩略语列表来定义一套一致的缩略语用于需求描述.
R47-/表达一致/风格指南
使用项目范围的风格指南.
3.5 C14–结构化
需求集需要结构化，以使同其关联的需求子集可以被识别到。
基本原理：
结构良好的需求文档可以帮助读者对整个需求集的理解，而不会给读者带来过分认知的负担。
策略：
∙使用功能层次分解的方法对需求集进行认知分组。
这种分组尽量不要超过7个子类，每个子类的选择要按照自然实体选择（不能随意选择）
∙组织应该针对其不同领域的系统开发需要定义相应的需求文档模板。
∙应用需求管理工具来配置对相关需求的识别确认。
例外
完整性和唯一性需要平衡，目前已经使用模块化方式来保证相关需求的分组
支撑这一特点的规则
R47-/表达一致/风格指南
使用项目范围的风格指南.
R48-/模块化/依赖关系
将具有相互依赖关系的需求分为一组.
R49-/模块化/关联需求
将关联的需求分为一组.
4.需求说明书的属性
4.1 A1–与需要（need）相符
不同层级需求之间的满足关联关系要被记录。
基本原理：
这个特性的目的是多方面的：
∙辅助理解一个解决方案究竟是如何解决问题的；
∙避免产生过度设计的解决方案；
∙避免产生缺乏设计的解决方案；
∙在复杂的多层次需求集之间应用变更管理流程。
策略：
追踪每一条需求，看其是否满足其上层需求。
例外
唯一性和上下文信息需要平衡，有时文本并不是表述复杂行为的最好方法，这时需要参考模型或设计（同C5）
支撑这一特点的规则
R32-/唯一/只描述一次
每一个需求只描述一次.
R39-/可追踪/唯一参考
为每一条需求提供唯一参考.
R40-/可追踪/父子关系
建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.
R42-/可追踪/外部参考
针对可识别的元素参考外部文档.
4.2 A2–与设计相符
需求和设计之间的关联关系要被记录。
基本原理：
∙需求和设计的关联有助于分析需求变更对设计产生的影响
∙需求和设计的关联有助于验证设计和实现是否满足需求
策略：
追踪与需求关联的每个设计及其工作产物。
支撑这一特点的规则
R25-/一致/上下文
当需求涉及复杂的行为时，应该参考设计或模型.
R32-/唯一/只描述一次
每一个需求只描述一次..
R40-/可追踪/父子关系
建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.
R41-/可追踪/验证产物
每个需求都应该链接需求验证产物
R42-/可追踪/外部参考
针对可识别的元素参考外部文档.
4.3 A3–与证据相符
需求和验证产物之间的关联关系要被记录。
基本原理：
需求和验证产物的关联有助于分析需求变更对验证产生的影响。
策略：
追踪与需求关联的所有验证和确认活动及其工作产物。
支撑这一特点的规则
R32-/唯一/只描述一次
每一个需求只描述一次.
R41-/可追踪/验证产物
每个需求都应该链接需求验证产物
R43-/表达一致/要点
使用一致的惯例或约定来区分相对重要的需求.
R47-/表达一致/风格指南
使用项目范围的风格指南.
4.4 A4–优先级
需求要有优先级。
基本原理：
在有限的条件下（时间、资源等）不能实现所有需求的情况下，要考虑实现优先级最高的需求以保证项目进行（如，分配权重进行权衡分析）。
策略：
根据对项目成功影响大小来定义需求的优先级，例如需求的重要性、紧急程度等。
支撑这一特征的规则
R43-/表达一致/要点
使用一致的惯例或约定来区分相对重要的需求.
5.独立需求条目规则
5.1精确
5.1.1 R1-/精确/使用定冠词
使用定冠词。
详细描述：
定冠词 'the'，不定冠词 'a'。
∙使用不定冠词容易导致歧义。
例如，如果需求中使用 'auser' ，那就不知道是否是指任意一个用户还是一个特定用户。
∙这可能导致验证的混乱，例如，babies 是婴儿食品的用户，但是，如果测试机构试图去验证ababy可以订购、接收、开启与服务（甚至是独立地消费），那么系统一定是失败的；另一方面，如果需求所指的‘用户’，在术语表中一定有明确的定义。
∙这里主要是说明，如果我们在需求中使用一些“泛指”，会导致歧义发生。
举例：
不正确的：
Thesystemshallprovideatimedisplay. {问题在于会混淆一些事，是在任何时候显示吗？
是一次性显示吗？
写需求的人最可能的意思是想要系统持续地显示当前时间，但是，如果开发者提供一个持续显示'10：
00am'（或者一次性显示任意时间），他们会说（尽管不合理），他们满足了需求。
很显然，他们并没有真正满足客户的需求}
下述需求特点是通过这条规则来呈现的
C3-清晰的
C7-可验证
5.1.2 R2-/精确/使用主动语态
使用可
升级会员 