文档介绍：INCOSE需求编写指南INCOSE需求编写指南【编者按】如何写好需求是INCOSE 需求工作组编写的需求文本化表达指南。本指南是专门讲述如何在系统工程中对需求进行文本化表达,其目的是从现有的各种标准中得出一个单一的,全面的规则,从而对需求编写工作提出建议。如何写好需求指南不是关于需求捕获、抽取或发现的,也不是关于需求分析以及建模与设计的。它侧重于如何用文本将需求表达清楚、准确,以便于后续进一步的需求分析。如何写好需求指南是在INCOSE需求工作组的专家们基于广泛的需求实践提炼而成,可以应用到更广范围内知道需求过程。本指南是由何强根据INCOSE(国际系统工程协会)需求工作组的成果《INCOSE_RWG_Guide_for_Writing_Requirements20130126》进行翻译整理,《INCOSE_RWG_Guide_for_Writing_Requirements20130126》是INCOSE产品,仅限于INCOSE成员和那些INCOSE企业顾问委员会成员组织的员工使用。因此,本文的发布仅作学****用途,若存在任何问题请联系管理员,我们将作相应处理。。要明确、准确、避免歧义这很难。然而,它仍然是目前唯一的能够涵盖各种所需概念的通用表达方式,。可以替代书面表达需求的方式包括:•具有完善语言定义的图形建模方法,如SysML。•模板结构的表格格式收集和描述需求,如汤姆·吉尔的P语言(TomGilb’sPlanguage,Gilb,T.,2005)。这些其他的方法也不完善:模型尚未能覆盖概念所需要的范围,表格的呈现格式,追溯和管理也都存在问题。事实是,如果仅仅是为了补充其他的表达方式,则仍然需要文本化需求。文本的优点是:•对可以表达的概念没有任何限制。• 句子和语法结构提供了一种可以追踪有意义的元素的方法。本指南仅指文本化需求的表达。 C1–必要性每一条需求都是必须的。基本原理:如果去掉这条需求仍能够满足问题,那么这条需求就不是必须的如果需求条目所要表达的意图已经在其他需求条目中描述了,那么这条需求就不是必须的如果不能找到为什么需要这条需求的原因,那么这条需求也不是必须的每一条需求都会有相应的成本;不必要的需求可能导致没有价值的额外工作,增加成本与不必要的风险策略:没有什么本质的特征可以表明需求是必须的。每一条需求都需要根据利益相关者真实的期望不断地进行调整。在需求的最高层级,这一特点仅被用来在评审每一条需求时,针对相应的需要、目标、目的以及驱动者、约束、概念以及系统范围内的场景定义进行确认。如果顶层需求不能在上述范围内被追踪到,那么这条需求就不是必须的。在较低的层级,需求的必要性表现为可以追述到更高层级的需求。需求从一层到另一层的可追溯性能够支持每一条独立需求覆盖的充分性与必要性原理。这一原理也可以帮助表达需求的必要性及需求条目的意图。 C2–与实现无关仅描述需要,而不是需求如何被满足。基本原理:如果在需求中描述如何实现至少有以下不良影响:错过考虑其他更好的实现方式的机会;(“What”),那就不能正确地将需求往下一层分配策略:只捕获那些在任何方案中都必须正确满足的功能、特征与约束。一个很有用的提问——“需求用于什么目的”?如果是在需求中描述了实现的话,那这个问题的答案就是真正的需求。如果是有效的需求,只是层级比较低。那就需要确定合适的层级以及在本层级描述需求。也就是说需求要跟系统层级匹配,不要描述太细节的内容。支撑这一特征的规则R3-/精确/-/抽象/问题域词汇如果在问题域,表达问题被解决要使用问题域的词汇而不要涉及到解决方案R34-/抽象/解决方案域词汇如果在解决方案域, C3–清晰的(无二义性)一条需求仅能有唯一的一种解释。基本原理:需求的意图必须在编写者、设计者以及验证者之间按照同一种方式理解,模棱两可会因为需求的解释不是客户的真实意图而导致项目延期、成本增加等问题。策略:减少模棱两可有很多方法,包括:使用正确的语法;使用术语中定义的术语或缩略语;使用精确的数量词与限定符;使用一致的语言表达形式;避免使用含混的术语;,包括:每一条需求用一个单一的句子描述, 使用主动语态,不使用形容词和副词,精简多余的表达理由、目的以及举例的辅助信息或从句;使用独立的子条款来表达条件、性能或约束;-/精确/-/精确/-/精确/使用定义过的术