文档介绍：INCOSE需求编写指南
INCOSE需求编写指南
2015-10-17 系统工程
【编者按】
如何写好需求是INCOSE 需求工作组编写的需求文本化表达指南。本指南是专门讲述如何在系统工程中对需求进行文本化表达，其目的的实践方法，包括：
每一条需求用一个单一的句子描述, 使用主动语态,不使用形容词和副词，精简多余的表达理由、目的以及举例的辅助信息或从句;
使用独立的子条款来表达条件、性能或约束;
适当的使用图形与图标来表达.
支撑这一特征的规则
R1 - /精确/使用定冠词
使用定冠词.
R2 - /精确/使用主动语态
使用有明确确定的参与者的主动语态.
R4 - /精确/使用定义过的术语
只使用术语表中定义过的术语.
R5 - /精确/量化
避免不精确的量词.
R6 - /精确/单位
描述数量时使用适当的单位.
R7 - /精确/避免副词
避免副词.
R8 - /精确/避免形容词
避免形容词
R9 - /精确/无例外条款
避免例外条款.
R10 - /精确/无开口
避免开口条款.
R11 - /简明/无不定式
避免多余的不定式.
R12 - /简明/单独条款
针对每一种条件使用子条款.
R13 - /无歧义/正确的语法
使用正确的语法.
R14 - /无歧义/正确拼写
使用正确的拼写.
R15 - /无歧义/正确的标点
使用正确的标点
R16 - /无歧义/连接词
使用 'X 和 Y'，而不是'两者都'
R17 - /无歧义/避免和/或r
避免使用 'X 和/或 Y'.
R18 - /无歧义/”/”
避免使用斜线分隔符号("/").
R30 - /条件/明确清楚
要给出明确的满足条件，而不是仅列出条件清单.
R35 - /量词/避免全称量词
使用“每一个”而不是“全部”、“都”、“任何”等全称量词.
 C4 –完整
一条需求要完整地描述需求本身的内容。
基本原理：
需求相关的一系列过程，如分解、分配、验证，，需求可以参考其他的文档，如，接口定义文件、标准、规则等。
策略：
一条需求描述本身就应该是一个完整的句子，对于这条需求的理解不需要参考其他需求的信息。
需求不能通过代词被参考。
例外
完整性和唯一性性需要平衡，目前已经使用模块化方式来保证相关需求的分组。
支撑这一特征的规则
R6 - /精确/Units
描述数量时使用适当的单位.
R7 - /精确/避免副词
避免副词.
R8 - /精确/避免形容词
避免形容词
R9 - /精确/无例外条款
避免例外条款.
R10 - /精确/无开口
避免开口条款.
R26 - /完整/避免使用代词
在需求陈述中，全部重复名词而不是使用代词来指代.
R27 - /完整/使用需求标题
避免使用标题支持子条款需求的解释.
R29 - /条件/明确清楚
描述适用条件必须明确，而不是从上下文进行推断.
 C5 –唯一性
一条需求只表达单一的观点。
基本原理：
分解、分配、验证和确认等与需求相关的几个过程的有效性依赖于需求的唯一性。
策略：
一条需求只描述一个功能、特征或约束。要理解需求的可追溯性。可以使用项目标准模板来编写需求。
虽然一条需求只包含一个功能、特征或约束，但是可能有多个从属条件满足需求
避免使用‘和’这样的链接词连接多个短语或句子表达多重意思。
例外
完整性和唯一性性需要平衡，目前已经使用模块化方式来保证相关需求的分组。
唯一性与上下文需要平衡，有时文本并不是表述复杂行为的最好方法，这时需要参考模型或设计。
支撑这一特征的规则
R19 - /一致/简单句子
用简单的肯定的陈述句写需求，各种条件与约束用子条款描述.
R20 - /一致/避免使用关系连接词
避免使用关系连接词.
R22 - /一致/避免目的短语
避免使用表达目的的短语.
R23 - /一致/避免括号“（）”
避免使用“( ) ” 来描述子条款.
R24 - /一致/列举
能够明确列举出来的就不要用概述的方式.
R47 - /表达一致/风格指南
使用项目范围的风格指南.
 C6 –可行
需求描述的内容在本质上是可行的。
基本原理：
本质上不可行的需求，如，100% 的可靠性，浪费时间，甚至导致不必要的昂贵解决方案
不切实际的问题通常都是重要的问题没有很好地进行量化。
策略：
可行性/可达性可以通过成本、计划、技术和风险等方面的因素来衡量，使用现有的技术和工程方法可以对需求的可达性进