本文由 何强 翻译整理。
（前接如何写好需求——INCOSE需求编写指南（1））
3.需求集的特点
3.1 C10 –完整性
需求集是对利益相关者期望的完整诠释。
基本原理：
这个特性确保所有的特定、约束、功能等都包含在需求集中。
需求集如果有遗漏的话，需要考虑两方面问题：
是否所有需求都捕获到了？
是否所有的需求都派生出来了？
策略：
对于顶层需求，完整性只能通过建模以及同客户和所有利益相关方一起进行评审的方式来处理。
在定义项目范围时，要保证所有的利益相关者都被识别；
确保从所有利益相关者视角的场景都被开发了，包括在所有生命周期阶段名义和非名义上的所有操作。
识别所有外部接口，确保每一个接口都被定义，每一个给定接口的互操作都被包含在接口需求中
对于低层级的需求，可以通过从低层需求项高层需求的追踪关联来保证需求的完整性。
需求标题的使用也有助于确保需求的所有方面。
根本目的就是通过清晰的沟通达成利益相关者最小的、充分必要的期望，而不是更多
支撑这一特征的规则
R40 - /可追踪/父子关系
建立起每一条父需求同由其派生出来的子需求集之间的追踪关系.
3.2 C11 –一致性
需求集是对利益相关者期望的一致性表达。
基本原理：
客户和其他利益相关者的需求或设计约束通常会彼此冲突，如果不能在开发早期尽早发现并解决，会导致昂贵的返工。
此外，即使每一个需求是无歧义的，但是如果使用不一致的术语或缩略语也会导致整个需求集不一致。
策略：
确保相同的或非常相似的需求不在不同的地方重复。
一个策略就是根据需求种类进行分类，如，完全性、及时性、功能区的等；
然后使用排序和过滤的方法将多样化的需求联系在一起，并检查他们的交互，权衡以及冲突；
使用术语表来保证术语和缩写的一致性
对接口需求特别注意，要确保与其他系统描述的接口需求是一致的。
支撑这一特征的规则
R4 - /精确/使用定义过的术语
只使用术语表中定义过的术语.
R44 - /表达一致/一致的术语
使用术语表定义一致的术语应用到需求描述中
R45 - /表达一致/首字母缩略语
使用首字母缩略词表来定义一致的缩略词应用到需求描述中
R46 - /表达一致/缩略语
使用缩略语列表来定义一套一致的缩略语用于需求描述
R47 - /表达一致/风格指南
使用项目范围的风格指南
3.3 C12 –可行
需求集是对利益相关者期望的可行的表达。
基本原理：
如果不能在开发早期发现不可行的需求，则会在后期带来成本和费用上的浪费。
即使每个单一的需求是可行的，也不能保证由它们组成的需求集是可行的。
例如，下面是可行的单个笔记本需求：
重量不超过1.4 kg，1TB存储容量，4G RAM，一个无线网网络接口，一个以太网接口，一个USB接口，一个HDMI 接口，可以从1米高空坠落没有损坏，可以在±50°C 的环境温度下工作，零售价低于500美元。
虽然每个需求看上去都完全可行，但即使是非专业人员乍一看，也不会轻易相信这个需求集是可行的（也就是说同时满足所有需求）。
策略：
在解决方案域，最好有多个可实现的解决方案，至少也要有一个；
这个解决方案在项目相关约束条件是可行的（如，成本、进度、技术以及法规符合），并且技术成熟度和项目目标也是匹配的。
支撑这一特征的规则
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 - /表达一致/要点
使用一致的惯例或约定来区分相对重要的需求.
请点击标题下“系统工程”进行关注
点击右上角“┇”，发送给朋友或分享到朋友圈
回复你感兴趣的话题，可以根据需要推出相应专题。
进入文档目录查看历史信息。
欢迎各位把你对系统工程的认识与理解撰写成文，发布到“系统工程”微信平台，一起交流，共同进步。
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
