INCOSE需求编写的指南.doc

上传人:可****阿 文档编号:30692433 上传时间:2022-08-06 格式:DOC 页数:47 大小:554KB
返回 下载 相关 举报
INCOSE需求编写的指南.doc_第1页
第1页 / 共47页
INCOSE需求编写的指南.doc_第2页
第2页 / 共47页
点击查看更多>>
资源描述

《INCOSE需求编写的指南.doc》由会员分享,可在线阅读,更多相关《INCOSE需求编写的指南.doc(47页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、 . . . . INCOSE需求编写指南2015-10-17系统工程1. 为什么需要文本化需求自然语言并不是表达需求的完美的方式。要明确、准确、避免歧义这很难。然而,它仍然是目前唯一的能够涵盖各种所需概念的通用表达方式,。可以替代书面表达需求的方式包括:具有完善语言定义的图形建模方法,如SysML。模板结构的表格格式收集和描述需求,如汤姆吉尔的P语言(Tom Gilbs Planguage,Gilb,T.,2005)。这些其他的方法也不完善:模型尚未能覆盖概念所需要的围,表格的呈现格式,追溯和管理也都存在问题。事实是,如果仅仅是为了补充其他的表达方式,则仍然需要文本化需求。文本的优点是:对可

2、以表达的概念没有任何限制。句子和语法结构提供了一种可以追踪有意义的元素的方法。本指南仅指文本化需求的表达。2.需求条目的特点2.1C1 必要性每一条需求都是必须的。基本原理: 如果去掉这条需求仍能够满足问题,那么这条需求就不是必须的 如果需求条目所要表达的意图已经在其他需求条目中描述了,那么这条需求就不是必须的 如果不能找到为什么需要这条需求的原因,那么这条需求也不是必须的 每一条需求都会有相应的成本;不必要的需求可能导致没有价值的额外工作,增加成本与不必要的风险策略: 没有什么本质的特征可以说明需必须的。每一条需求都需要根据利益相关者真实的期望不断地进行调整。 在需求的最高层级,这一特点仅被

3、用来在评审每一条需求时,针对相应的需要、目标、目的以与驱动者、约束、概念以与系统围的场景定义进行确认。如果顶层需求不能在上述围被追踪到,那么这条需求就不是必须的。 在较低的层级,需求的必要性表现为可以追述到更高层级的需求。需求从一层到另一层的可追溯性能够支持每一条独立需求覆盖的充分性与必要性原理。这一原理也可以帮助表达需求的必要性与需求条目的意图。2.2C2 与实现无关仅描述需要,而不是需求如何被满足。基本原理:如果在需求中描述如何实现至少有以下不良影响: 错过考虑其他更好的实现方式的机会; 不能解决真正的问题. 如果在本层级没有很好地沟通需要什么(“What”),那就不能正确地将需求往下一层

4、分配策略: 只捕获那些在任何方案中都必须正确满足的功能、特征与约束。 一个很有用的提问“需求用于什么目的”?如果是在需求中描述了实现的话,那这个问题的答案就是真正的需求。 如果是有效的需求,只是层级比较低。那就需要确定适宜的层级以与在本层级描述需求。也就是说需求要跟系统层级匹配,不要描述太细节的容。支撑这一特征的规则R3 - /精确/主体使需求的主题与需求所在的层级相适应.R33 - /抽象/问题域词汇如果在问题域,表达问题被解决要使用问题域的词汇而不要涉与到解决方案R34 - /抽象/解决方案域词汇如果在解决方案域,表达系统层级的解决方案使用系统的词汇2.3C3 清晰的(无二义性)一条需求仅

5、能有唯一的一种解释。基本原理: 需求的意图必须在编写者、设计者以与验证者之间按照同一种方式理解,模棱两可会因为需求的解释不是客户的真实意图而导致项目延期、成本增加等问题。策略:减少模棱两可有很多方法,包括: 使用正确的语法; 使用术语中定义的术语或缩略语; 使用精确的数量词与限定符; 使用一致的语言表达形式; 避免使用含混的术语; 避免使用代词.精确的表达有很多好的实践方法,包括: 每一条需求用一个单一的句子描述,使用主动语态,不使用形容词和副词,精简多余的表达理由、目的以与举例的辅助信息或从句; 使用独立的子条款来表达条件、性能或约束; 适当的使用图形与图标来表达.支撑这一特征的规则R1 -

6、 /精确/使用定冠词使用定冠词.R2 - /精确/使用主动语态使用有明确确定的参与者的主动语态.R4 - /精确/使用定义过的术语只使用术语表中定义过的术语.R5 - /精确/量化避免不精确的量词.R6 - /精确/单位描述数量时使用适当的单位.R7 - /精确/避免副词避免副词.R8 - /精确/避免形容词避免形容词R9 - /精确/无例外条款避免例外条款.R10 - /精确/无开口避免开口条款.R11 - /简明/无不定式避免多余的不定式.R12 - /简明/单独条款针对每一种条件使用子条款.R13 - /无歧义/正确的语法使用正确的语法.R14 - /无歧义/正确拼写使用正确的拼写.R1

7、5 - /无歧义/正确的标点使用正确的标点R16 - /无歧义/连接词使用X和Y,而不是两者都R17 - /无歧义/避免和/或r避免使用X和/或Y.R18 - /无歧义/”/”避免使用斜线分隔符号(/).R30 - /条件/明确清楚要给出明确的满足条件,而不是仅列出条件清单.R35 - /量词/避免全称量词使用“每一个”而不是“全部”、“都”、“任何”等全称量词.2.4C4 完整一条需求要完整地描述需求本身的容。基本原理:需求相关的一系列过程,如分解、分配、验证,依赖于对独立描述的完整理解而不依赖于其他的描述.注意,需求可以参考其他的文档,如,接口定义文件、标准、规则等。策略: 一条需求描述本

8、身就应该是一个完整的句子,对于这条需求的理解不需要参考其他需求的信息。 需求不能通过代词被参考。例外完整性和唯一性性需要平衡,目前已经使用模块化方式来保证相关需求的分组。支撑这一特征的规则R6 - /精确/Units描述数量时使用适当的单位.R7 - /精确/避免副词避免副词.R8 - /精确/避免形容词避免形容词R9 - /精确/无例外条款避免例外条款.R10 - /精确/无开口避免开口条款.R26 - /完整/避免使用代词在需求述中,全部重复名词而不是使用代词来指代.R27 - /完整/使用需求标题避免使用标题支持子条款需求的解释.R29 - /条件/明确清楚描述适用条件必须明确,而不是从

9、上下文进行推断.2.5C5 唯一性一条需求只表达单一的观点。基本原理:分解、分配、验证和确认等与需求相关的几个过程的有效性依赖于需求的唯一性。策略: 一条需求只描述一个功能、特征或约束。要理解需求的可追溯性。可以使用项目标准模板来编写需求。 虽然一条需求只包含一个功能、特征或约束,但是可能有多个从属条件满足需求 避免使用和这样的词连接多个短语或句子表达多重意思。例外完整性和唯一性性需要平衡,目前已经使用模块化方式来保证相关需求的分组。唯一性与上下文需要平衡,有时文本并不是表述复杂行为的最好方法,这时需要参考模型或设计。支撑这一特征的规则R19 - /一致/简单句子用简单的肯定的述句写需求,各种

10、条件与约束用子条款描述.R20 - /一致/避免使用关系连接词避免使用关系连接词.R22 - /一致/避免目的短语避免使用表达目的的短语.R23 - /一致/避免括号“()”避免使用“( ) ”来描述子条款.R24 - /一致/列举能够明确列举出来的就不要用概述的方式.R47 - /表达一致/风格指南使用项目围的风格指南.2.6C6 可行需求描述的容在本质上是可行的。基本原理: 本质上不可行的需求,如,100%的可靠性,浪费时间,甚至导致不必要的昂贵解决方案 不切实际的问题通常都是重要的问题没有很好地进行量化。策略: 可行性/可达性可以通过成本、计划、技术和风险等方面的因素来衡量,使用现有的技

11、术和工程方法可以对需求的可达性进行评估,如果不具备可达性,那这条需求不是好的需求。 通常来说在没有对潜在解决方案进行分析和考量的情况下无法确定一条需求的可行性,但是我们可以从基本面上识别出那些不可能实现或不切实际的需求。支撑这一特征的规则R28 - /现实的/避免绝对避免使用绝对的不现实的词.2.7C7 可验证需可验证的。基本原理: 除非需求在某些方面是可验证或可测试的,否则没有方法判断它是否被满足。因此对于不同类型的需求需要以不同的方式来证实。 功能需求,通常都要通过测试来验证产品正确的行为,所以功能需求的行为一定要表达清楚; 而性能需求需要明确地表达与性能相关的数量。策略:需求不可验证最常

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

13、空间。 我要验证的是什么?如果没有,那么重写这条需求,表达出你真实的意图。支撑这一特征的规则R1 - /精确/使用定冠词使用定冠词.R2 - /精确/使用主动语态使用有明确确定的参与者的主动语态.R4 - /精确/使用定义过的术语只使用术语表中定义过的术语.R5 - /精确/量化避免不精确的量词.R6 - /精确/Units描述数量时使用适当的单位.R7 - /精确/避免副词避免副词.R8 - /精确/避免形容词避免形容词R9 - /精确/无例外条款避免例外条款.R10 - /精确/无开口避免开口条款.R30 - /条件/明确清楚要给出明确的满足条件,而不是仅列出条件清单条件.R36 - /公

14、差/值的围定义正确的数量围.R37 - /量化/可度量的提供具体的可度量的性能目标.R38 - /量化/避免无限时间明确地定义时间限制,而不是使用无限时间的关键词.2.8C8 正确性需对利益相关者期望的正确表达。基本原理: 这一特性是对必要性原则的补充,需求所描述的功能或性能值必须是正确的。 这一特性关系到利益相关者期望的验证,验证系统设计与构建满足需求。策略:确保以下容: 基于对高层需求的正确解释与理解进行需求分解与派生; 对根本目标的正确理解(如,最小、最大); 正确的分析与假定。使用预先定义的需求验证流程来保证需求在上下文环境中的正确性支撑这一特征的规则R6 - /精确/Units描述数

15、量时使用适当的单位.R36 - /公差/值的围定义正确的数量围.R42 - /可追踪/外部参考针对可识别的元素参考外部文档.2.9C9 合规需求要符合组织所选择的适用标准。基本原理:当所有需求都同组织特定领域的标准相符合时,每一条需求就更容易编写、理解与评审。策略:使用组织的模板写需求。支撑这一特征的规则R43 - /表达一致/要点使用一致的惯例或约定来区分相对重要的需求.R44 - /表达一致/一致的术语使用术语表定义一致的术语应用到需求描述中.R45 - /表达一致/首字母缩略语使用首字母缩略词表来定义一致的缩略词应用到需求描述中.R46 - /表达一致/缩略语使用缩略语列表来定义一套一致

16、的缩略语用于需求描述.R47 - /表达一致/风格指南使用项目围的风格指南.后记由于中英文语言环境的差异,部分需求编写规则在中文语言环境下并不特别适用需求的多样性意味着规则必须不断地去适应特定的情况。基于这一现实,指南中仅仅介绍了一些基本的特征与属性3.需求集的特点3.1C10 完整性需求集是对利益相关者期望的完整诠释。基本原理:这个特性确保所有的特定、约束、功能等都包含在需求集中。需求集如果有遗漏的话,需要考虑两方面问题: 是否所有需求都捕获到了? 是否所有的需求都派生出来了?策略:对于顶层需求,完整性只能通过建模以与同客户和所有利益相关方一起进行评审的方式来处理。 在定义项目围时,要保证所

17、有的利益相关者都被识别; 确保从所有利益相关者视角的场景都被开发了,包括在所有生命周期阶段名义和非名义上的所有操作。 识别所有外部接口,确保每一个接口都被定义,每一个给定接口的互操作都被包含在接口需求中对于低层级的需求,可以通过从低层需求项高层需求的追踪关联来保证需求的完整性。 需求标题的使用也有助于确保需求的所有方面。 根本目的就是通过清晰的沟通达成利益相关者最小的、充分必要的期望,而不是更多支撑这一特征的规则R40 - /可追踪/父子关系建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.3.2C11 一致性需求集是对利益相关者期望的一致性表达。基本原理: 客户和其他利益相关者的需求

18、或设计约束通常会彼此冲突,如果不能在开发早期尽早发现并解决,会导致昂贵的返工。 此外,即使每一个需无歧义的,但是如果使用不一致的术语或缩略语也会导致整个需求集不一致。策略: 确保相同的或非常相似的需求不在不同的地方重复。 一个策略就是根据需求种类进行分类,如,完全性、与时性、功能区的等; 然后使用排序和过滤的方法将多样化的需求联系在一起,并检查他们的交互,权衡以与冲突; 使用术语表来保证术语和缩写的一致性 对接口需求特别注意,要确保与其他系统描述的接口需一致的。支撑这一特征的规则R4 - /精确/使用定义过的术语只使用术语表中定义过的术语.R44 - /表达一致/一致的术语使用术语表定义一致的

19、术语应用到需求描述中R45 - /表达一致/首字母缩略语使用首字母缩略词表来定义一致的缩略词应用到需求描述中R46 - /表达一致/缩略语使用缩略语列表来定义一套一致的缩略语用于需求描述R47 - /表达一致/风格指南使用项目围的风格指南3.3C12 可行需求集是对利益相关者期望的可行的表达。基本原理: 如果不能在开发早期发现不可行的需求,则会在后期带来成本和费用上的浪费。 即使每个单一的需可行的,也不能保证由它们组成的需求集是可行的。例如,下面是可行的单个笔记本需求:a. 重量不超过1.4 kg,1TB存储容量,4G RAM,一个无线网网络接口,一个以太网接口,一个USB接口,一个HDMI接

20、口,可以从1米高空坠落没有损坏,可以在50C的环境温度下工作,零售价低于500美元。b. 虽然每个需求看上去都完全可行,但即使是非专业人员乍一看,也不会轻易相信这个需求集是可行的(也就是说同时满足所有需求)。策略: 在解决方案域,最好有多个可实现的解决方案,至少也要有一个; 这个解决方案在项目相关约束条件是可行的(如,成本、进度、技术以与法规符合),并且技术成熟度和项目目标也是匹配的。支撑这一特征的规则R28 - /现实的/避免绝对避免使用绝对的不现实的词.R31 - /唯一/分类根据问题或系统解决的不同方面对需求进行分类.R32 - /唯一/只描述一次每一个需求只描述一次.R36 - /公差

21、/值的围定义正确的数量围.R37 - /量化/可度量的提供具体的可度量的性能目标.3.4C13 有边界需求集一定要在一个已定义的围。基本原理: 需求集要清晰地传达设计团队、客户和其他利益相关者在系统定义围的期望,必须包括所有必要的需求,要排除不相干的要素。 这一特点的目的就是要避免对工作围的误解,防止资源消耗与浪费到系统围之外。策略: 在写需求前开发和定义基线围,围要清晰地反应利益相关者需求。一旦围基线确定(利益相关者同意),就可以根据这一围基线来写需求。围确定的时候,要跟踪需求到相应的围容。 背景图在定义围的时候很有用,可以显示正在开发的系统与其他系统之间的交互,帮助确定哪些是系统关注的,哪

22、些不是。支撑这一特征的规则R44 - /表达一致/一致的术语使用术语表定义一致的术语应用到需求描述中.R45 - /表达一致/首字母缩略语使用首字母缩略词表来定义一致的缩略词应用到需求描述中.R46 - /表达一致/缩略语使用缩略语列表来定义一套一致的缩略语用于需求描述.R47 - /表达一致/风格指南使用项目围的风格指南.3.5C14 结构化需求集需要结构化,以使同其关联的需求子集可以被识别到。基本原理:结构良好的需求文档可以帮助读者对整个需求集的理解,而不会给读者带来过分认知的负担。策略: 使用功能层次分解的方法对需求集进行认知分组。这种分组尽量不要超过7个子类,每个子类的选择要按照自然实

23、体选择(不能随意选择) 组织应该针对其不同领域的系统开发需要定义相应的需求文档模板。 应用需求管理工具来配置对相关需求的识别确认。例外完整性和唯一性需要平衡,目前已经使用模块化方式来保证相关需求的分组支撑这一特点的规则R47 - /表达一致/风格指南使用项目围的风格指南.R48 - /模块化/依赖关系将具有相互依赖关系的需求分为一组.R49 - /模块化/关联需求将关联的需求分为一组.4.需求说明书的属性4.1A1 与需要(need)相符不同层级需求之间的满足关联关系要被记录。基本原理:这个特性的目的是多方面的: 辅助理解一个解决方案究竟是如何解决问题的; 避免产生过度设计的解决方案; 避免产

24、生缺乏设计的解决方案; 在复杂的多层次需求集之间应用变更管理流程。策略:追踪每一条需求,看其是否满足其上层需求。例外唯一性和上下文信息需要平衡,有时文本并不是表述复杂行为的最好方法,这时需要参考模型或设计(同C5)支撑这一特点的规则R32 - /唯一/只描述一次每一个需求只描述一次.R39 - /可追踪/唯一参考为每一条需求提供唯一参考.R40 - /可追踪/父子关系建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.R42 - /可追踪/外部参考针对可识别的元素参考外部文档.4.2A2 与设计相符需求和设计之间的关联关系要被记录。基本原理: 需求和设计的关联有助于分析需求变更对设计产生

25、的影响 需求和设计的关联有助于验证设计和实现是否满足需求策略:追踪与需求关联的每个设计与其工作产物。支撑这一特点的规则R25 - /一致/上下文当需求涉与复杂的行为时,应该参考设计或模型.R32 - /唯一/只描述一次每一个需求只描述一次.R40 - /可追踪/父子关系建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.R41 - /可追踪/验证产物每个需求都应该需求验证产物R42 - /可追踪/外部参考针对可识别的元素参考外部文档.4.3A3 与证据相符需求和验证产物之间的关联关系要被记录。基本原理:需求和验证产物的关联有助于分析需求变更对验证产生的影响。策略:追踪与需求关联的所有验证

26、和确认活动与其工作产物。支撑这一特点的规则R32 - /唯一/只描述一次每一个需求只描述一次.R41 - /可追踪/验证产物每个需求都应该需求验证产物R43 - /表达一致/要点使用一致的惯例或约定来区分相对重要的需求.R47 - /表达一致/风格指南使用项目围的风格指南.4.4A4 优先级需求要有优先级。基本原理:在有限的条件下(时间、资源等)不能实现所有需求的情况下,要考虑实现优先级最高的需求以保证项目进行(如,分配权重进行权衡分析)。策略:根据对项目成功影响大小来定义需求的优先级,例如需求的重要性、紧急程度等。支撑这一特征的规则R43 - /表达一致/要点使用一致的惯例或约定来区分相对重

27、要的需求.5.独立需求条目规则5.1 精确5.1.1R1-/精确/使用定冠词使用定冠词。详细描述:定冠词the,不定冠词a。 使用不定冠词容易导致歧义。例如,如果需求中使用a user,那就不知道是否是指任意一个用户还是一个特定用户。 这可能导致验证的混乱,例如,babies是婴儿食品的用户,但是,如果测试机构试图去验证a baby可以订购、接收、开启与服务(甚至是独立地消费),那么系统一定是失败的;另一方面,如果需求所指的用户,在术语表中一定有明确的定义。 这里主要是说明,如果我们在需求中使用一些“泛指”,会导致歧义发生。举例:不正确的:The system shall provide a

28、time display.问题在于会混淆一些事,是在任何时候显示吗?是一次性显示吗?写需求的人最可能的意思是想要系统持续地显示当前时间,但是,如果开发者提供一个持续显示10:00am(或者一次性显示任意时间),他们会说(尽管不合理),他们满足了需求。很显然,他们并没有真正满足客户的需求下述需求特点是通过这条规则来呈现的C3 - 清晰的C7 - 可验证5.1.2R2-/精确/使用主动语态使用可明确识别参与者的主动语态。详细描述:主动语态要求参与者/实体完成活动是句子的主体,如果系统的参与者/实体不明确,就不清楚谁来完成这个活动,进而,需求验证就会很困难。举例: 不正确的:必须确认客户的身份. 这

29、条需求的问题在于没有确定Who/What负责确认客户的身份. 正确的:会计系统必须确认客户的身份. 注意:如果存在不同的解释的话,会计系统, 身份, 确认以与客户必须在术语表中定义下述需求特点是通过这条规则来呈现的C3 - 清晰的C7 - 可验证5.1.3R3-/精确/需求主体与层级匹配使需求的主体与需求所在的层级相适应。详细描述: 需求的主体要能说明需求的层级。用系统必须.来表达系统需求;用子系统必须.来表达子系统需求。 在写需求的时候有必要问一下需求的主语是否正确?或者是否需要描述需求到更高或更低层级?还要问是否是验证需求满足的适宜的层级?举例: 系统需求用 必须.来表述. 子系统需求用

30、必须.来表述.下述需求特点是通过这条规则来呈现的C2 - 与实现无关5.1.4R4-/精确/使用定义过的术语只使用术语表中定义过的术语。详细描述: 大多数语言都很丰富,几乎每一个字都有大量的同义词,每一个都有很微妙的不同的意义。在需求中,隐含的意思最有可能导致歧义以与难以验证。使用术语表可以让需求的读者能够准确地知道作者所选择的每一个词汇的意思。 在需求文本中应该使用一致认同的术语表来识别术语,如:英文术语可以大写,多个英文单词组成的词可以加“_”(如:Current_Time);中文术语可以加粗或者添加术语标记符号(此为译者给的建议)。举例: 不正确的:arrivals board应该不断地

31、显示当前时间问题就在于current含糊不清,在哪个时区?什么样的精度?用什么样的形式? 正确的:到港显示牌必须显示当前时间注意,到港显示牌以与当前时间必须在术语表中定义,后者还应该明确所依据的精度、形式与时区下述需求特点是通过这条规则来呈现的C3 - 清晰的C7 - 可验证C11 - 一致性5.1.5R5-/精确/量化避免不精确的量化描述。详细描述: 需求应该精确量化。避免使用模糊量化的词,如:一些,任何,很多,几,大约,几乎总是,几乎,接近,近似,重要的,灵活的,可扩展的,典型的,足够,适当的,有效的,合理的,熟练的等。 另外还应该注意避免使用未指定的单位和为指定的值的围举例: 不正确的:

32、飞行信息系统必须显示当前的高度,分辨率“大约”1米. 这条需求的问题就是不精确。在距离1米这个上下文中“大约”是什么?谁来确定这个“大约”具体是多少?如何去验证这个“大约” 正确的:飞行信息系统必须显示当前的高度1米. 注意:如果存在其他可能的解释,那么“当前高度”必须要定义在术语表中下述需求特点是通过这条规则来呈现的C3 - 清晰的C7 - 可验证5.1.6R6-/精确/单位描述数量时使用适当的单位。详细描述: 所有数字都应该有某种明确的单位举例: 不能承受的:电路板的存储温度不超过30度 正确的:电路板的存储温度不超过30摄氏度.5.1.7R7-/精确/避免使用含糊的副词避免使用含糊的副词

33、。详细描述: 在需求描述过程中有时候会使用副词来修饰(限定)活动。要避免使用含糊的副词,如:经常,大约, 充分的,有代表性的,典型的等含糊的副词导致需求含糊不清、不可验证,不能准确地表达利益相关者的期望举例: 不正确的:飞行信息系统必须经常在线. 正确的:飞行信息系统必须具有至少YY小时至少#%的有效性注意:有效性必须在术语表中进行定义因为它有很多的测量计算方法下述需求特点是通过这条规则来呈现的C3 - 清晰的C4 - 完整C7 - 可验证5.1.8R8-/精确/避免使用含糊的形容词避免使用含糊的形容词。详细描述: 在需求描述过程中有时候会使用形容词来修饰(限定)实体.如辅助的,相关的,日常的

34、,普通的,一般的, 通常的等含糊的形容词导致需求含糊不清、不可验证,不能准确地表达利益相关者的期望。举例: 不正确的:飞行信息系统必须显示“相关飞机”的航迹信息这条需求的问题在于没有明确相关飞机是什么,此外,这个描述允许由开发者去确定什么是相关的;而这种决定是客户来完成的,应该由客户来明确需求 正确的:飞行信息系统必须显示处于机场20KM围的每一架飞机的航迹这样,需要显示航迹信息的飞机就非常明确。注意:飞机、航迹信息、机场都应该在术语表中进行定义.下述需求特点是通过这条规则来呈现的C3 - 清晰的C4 - 完整C7 - 可验证5.1.9R9-/精确/无免责条款避免免责条款。详细描述: 免责条款

35、总是会给供应商一些借口而不是去满足要求。这些免责条款通常提供模糊的条件或可能性,使用的词语可能有只要可能, 尽可能少,尽可能多, 如果证明有必要,尽可能以与如果可行。免责条款会导致模棱两可、无法验证的需求,不能反映准确的涉众期望。举例: 不正确的:GPS必须有“足够的”空间来显示用户的位置. 正确的:GPS必须显示用户的位置下述需求特点是通过这条规则来呈现的C3 - 清晰的C4 - 完整C7 - 可验证5.1.10R10-/精确/无开放条款避免开放条款。详细描述: 开放条款告诉读者这里还有更多的要求,但是没有具体说明到底是什么。 要避免使用以下的词语:包括但不限于,等等。 开放条款会导致模棱两

36、可、无法验证的需求,不能反映准确的涉众期望。 使用开放条款也违反了“one thought”准则.如果有更多的必须的情况需要说明,那么就必须明确地描述出来。举例:不正确的:ATM必须显示客户、账户余额等等。正确的:(分解成多条需求,把这些要求都完整地列举出来): ATM必须显示客户账号. ATM必须显示客户账户余额. ATM必须显示客户账户类型. ATM必须显示客户账户透支限制. ATM必须显示客户.下述需求特点是通过这条规则来呈现的C3 - 清晰的C4 - 完整C7 - 可验证5.2 简明扼要5.2.1R11-/简明/避免助动词“能”避免使用多余的助动词“能”、“能够”。详细描述: 有时候会

37、看到一条需求使用了助动词“能”“能够”来描述一个基本动作,如系统必须设计成能,就不如简单地描述成系统必须。 类似还有一种描述如:“系统必须具备的能力”或者“系统提供的能力”。 我们必须事先考虑到验证,如果系统具备“一次”做某事的能力,但是其余的99次都失败了,那么是否满足需求?很显然,No.举例: 不正确的:武器子系统必须有能力存储所有的武器 正确的:武器子系统必须存储所有的武器.备注:我国有能力多次把卫星、把人送上太空,但是现在还不能生产完全自主知识产权的汽车。前者就是一种能力,做100个零件,只要有一个两件满足就可以了。这跟生产上的“试制”与“批产”是一个道理(此为译者注)下述需求特点是通

38、过这条规则来呈现的C3 - 清晰的5.2.2R12-/简明/单独条款使用单独的子条款分别对应每一种情况。详细描述:每个需求都应该有一个主要的动词来描述基本的功能与需要,主要的句子可辅以子条款来说明条件、性能值和约束条件。每一个条件使用单一的、明确的可识别子条款来表示。举例: 导航信标必须为每个海事用户在港/靠港操纵提供增强数据,8-20米精度,至少99.7%的时间。 这里基本功能是一个不可分割的条款,后面跟着子条款描述性能: 8-20米精度,至少99.7%的时间 两个量(准确性和可靠性)不是独立可核实的,所以依然在一起作为一个单一的需求下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3

39、无歧义5.3.1R13-/无歧义/正确的语法使用正确的语法。详细描述:不正确的语法让人云里雾里,尤其在不同语言之间的表达更需要注意。举例: 不正确的:The Weapon_Subsystemshall storingthe location of all ordnance. The grammatical error leads to uncertainty about the meaning. 正确的:The Weapon_Subsystemshall storethe location of all Ordnance. Note that Ordnance must be defined

40、in the glossary to be explicit about the types of weapons and ammunition.下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3.2R14-/无歧义/正确拼写正确拼写。详细描述:不正确的拼写导致混淆。举例: 不正确的:The Weapon_Subsystem shall store the location of allordinance(条例).这里由于拼写上的失误,不太可能武器子系统会关注规则 正确的:The Weapon_Subsystem shall store the location of allOrdnan

41、ce(军火).注意,术语表中的军火必须明确武器和弹药的类型下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3.3R15-/无歧义/正确标点符号使用正确的标点符号。详细描述:不正确的标点符号会导致需求子条款之间混淆举例: 不正确的:导航信标必须为每个海事用户提供增强数据,致力于为在港/靠港(HHA)用户在99.7%的时间提供8-20米的精度。这句话大问题就在于,上,它把读者的主意力引到精度上而不是增量数据上 正确的:导航信标必须为在港/靠港(HHA)用户在在99.7%的时间提供8-20米精度的增强数据. 逗号的位置清楚地说明了数据的精度与可用性。另外,在需求条款中,标点符号也多,引起歧义的

42、可能性就越大下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3.4R16-/无歧义/使用定义过的术语Use the construct X and Y instead of both X and Y。详细描述:要表达X和Y两者都的意思,最好不要添加Both,添加Both容易让读者想到其他不同的意思。举例: 不正确的:The Engine_Management_System shall disengage the Speed_Control_Subsystem whenboththe Cruise_Control is engagedandthe Driver is applying th

43、e Accelerator. 正确的:The Engine_Management_System shall disengage the Speed_Control_Subsystem when the Cruise_Control is engaged AND the Driver is applying the Accelerator.发动机管理系统在巡航控制中并且司机加速的时候必须解除速度控制子系统下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3.5R17-/无歧义/避免和或避免使用X和/或Y。详细描述:和/或最常见的解释是要表达一种包容性,要么X或Y,要么两者,如果是这个意图,应该写成两条需求。举例:不正确的:当离合器分离和/或司机使用制动器时,发动机管理系统必须解除速度控制子系统。正确的应该是两条需求: 当离合器分离时,发动机管理系统必须解除速度控制子系统。 当司机使用制动器时,发动机管理系统必须解除速度控制子系统。下述需求特点是通过这条规则来呈现的C3 - 清晰的5.3.6R18-/无歧义/避免/符号避免使用/符号。

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 应用文书 > 工作计划

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁