需求工程理论碰撞Teamcenter需求管理

fuhe

需求工程理论

1.1►

什么是需求工程？为什么做？



按照《需求工程基础》书中需求工程定义如下：



中文：需求工程是一种用于定义需求和管理需求的系统性、规范化的方法。

英文：Requirements engineering is a systematic and disciplined approach to the specification and management of requirements。



开展需求工程主要有以下两个目的：

理解相关的需求，在利益相关方之间就这些需求达成共识，按照给定的标准记录需求，并系统性地管理这些需求；

理解并记录利益相关方的愿望和需要，正确定义需求并有效地管理需求，以减少交付的系统不满足利益相关方的愿望和需要的风险。



1.2►

需求工程主要包括哪些内容？



需求工程主要包括两个部分的内容：1）需求定义或需求开发，2）需求管理。



图片
图-1 需求工程内容



需求定义流程是把利益相关方的期望转换成对问题的定义，然后再转换成经确定的技术需求规范文档。需求定义是递归和反复迭代的过程，它包括开发利益相关方需求、产品需求和底层组件需求。



需求管理流程是对所有的利益相关方需求、客户需求、自顶向下直到最底层组件的技术需求进行管理，主要的作用是：

在系统设计阶段对设定控制基线并使用的需求进行管理；

提供父子需求之间的双向可追溯性；

在系统生命周期中对所建立的需求控制基线的变更进行管理。



1.3►

需求工程师有哪些职责？



需求工程师是连接用户和设计工程师的桥梁，他的职责是深入理解用户的需要，把用户的需要转化成设计视角的系统需求，正确编写需求并有效管理需求。理解系统的运行环境和外部接口，并确保功能架构正确地捕获了系统需求等。



优秀的需求工程师应具备的品质有：分析思维、共情、沟通技巧、解决冲突的技能、调和、自信、且有说服力。





#2

需求工程实践流程



大多数复杂工程项目中需求工程实践的流程方法，它依赖于两个核心实践活动：

根据客户需求生成解决方案元素的需求；

细化解决方案需求并分配给解决方案组件。



图片
图- 2 工程的层级结构





2.1►

生成解决方案元素的需求



负责第N+1 层级解决方案元素（一般指供应商）开发的每个工程团队都继承了一组需求，这些需求反映了第N层级架构师（一般指客户）对解决方案要素在职责范围内的预期愿景。为了增加清晰度，这里命名上层级需求为“客户需求”，这里的客户有时可能是特定工程层级的架构师。



第N+1层级的每个供应商必须分析这些客户需求，以将它们生成一组“正规化”的相应的解决方案需求，这些解决方案需求将构成验证标准和验收准则的参考（如图2所示）。



图片
图- 3 从N级需求生成N+1解决方案需求



任务1：通过重新组合或丰富客户需求来定义“解决方案元素”的需求。此任务包括转换客户需求的文本，以形成清晰、无歧义的解决方案需求，尤其是当客户需求直接从上层级需求中继承时，该任务更加重要。例如，分配给系统的如下客户需求“用户应能够…”时，必须重新组织该条需求，“如基于给定的用户的操作要求，系统应执行…”



任务2：确保每个解决方案需求的可验证性。根据应用的质量要求，强烈建议同时确定验证方法（检查、分析、演示或测试，这四种验证方法的英文首字母的缩写为I/A/D/T），如果可能，形成验证与确认（V&V）策略。



任务3：确保每个解决方案需求的可追溯性。





2.2►

细化解决方案需求并分配给解决方案组件



假设第N层级的解决方案元素的需求已经固定和打上基线，架构师执行设计分析（图3中的第2项）进一步分配该需求：

如果第N+1层级的解决方案元素完全涵盖第N层级的需求，则完全继承该需求（图3中的第1项）；

如果需要多个N+1层级的解决方案元素之间的协同来满足该需求，则必须创建新的解决方案需求并分配给每个参与者组件（图3中的第2项）。



图片
图- 4 需求的细化和分配



在该过程中会引出设计约束，还可能创建衍生需求（例如：质量或功率预算的分配）。





#3

Teamcenter需求管理



在Teamcenter中对需求的管理主要包括以下步骤：

    1）在接到需求文档的初步草稿后，需求工程师可以选择在TC中进行创建这些需求条目或者选择导入需求文档；

    2）在TC中编写需求的层级关系或补充新需求；

   3）需求在线审查，或者导出Word、Excel离线审查，再导入；

    4）建立需求基线，当发生需求变更时对变更进行管理；

    5）建立多层级需求之间的追溯关系。



图片
图-5 TC需求管理流程



3.1►

在TC中直接创建新需求



在Teamcenter中能够创建HTML需求规范模板（规划需求文档的结构形式，提供需求条目的编写的模板）。在创建新的需求文档时，可以直接引用这些HTML模板。

图片
图-6 HTML需求规范模板



创建需求文档时如果HTML模板内容不能完全满足需求定义时，可以在Teamcenter中选中某条需求创建该条需求的子需求或者同代需求。

图片
图-7 添加子需求或同代需求



3.2►

需求文档的导入



如果需求文档已经在其他工具中编辑完成，可以将这些需求文档直接导入Teamcenter自动建立需求数据库。



目前Teamcenter支持多种格式的需求文档的导入，如Word、Excel、PDF、ReqIF，DOORS和Polarion等。

图片
图-8 支持多种文档格式的导入



3.3►

需求在线审查



对于多人组内协同编辑一份需求文档或者在需求评审之前，组内同事相互校验，这种情形下可以采用创建注释，方便大家在线协同交流。

图片
图-9 创建注释，在线协同交流



在组内同事相互校验完毕后，通过提交到工作流进行在线审签。

图片
图-10 需求在线审签



3.4►

需求离线审查



如果需求审批的领导没有TC访问权限或者邀请外部专家进行评审，这个时候可以选中导出需求到Word、Excel或者PDF。

图片
图-11 导出至Word需求文档



3.5►

需求变更



当需求评审完毕后创建需求基线版本。如果在需求基线创建之后仍需要进行更改需求，这时需要发起需求变更。1）对变更的需求进行影响性分析（Impact Analysis），看看更改这些需求会影响到哪些模型和数据；2）发起需求变更流程，更新需求完成变更。

图片
图-12 需求的影响性分析



图片
图-13 需求变更管理流程



3.6►

创建需求追溯矩阵



在Teamcenter中选中两个需求文档，如系统需求和子系统需求，能够快速地创建它们之间的追溯矩阵。

图片
图-14 需求追溯矩阵





#4

小结



需求工程是系统工程流程的起始阶段，是后续系统架构、工程设计、集成、验证与确认的基础和依据。企业是否建立需求数据库也成为衡量企业是否基于系统工程流程方法、是否实施MBSE的重要标准之一。



Teamcenter已经从传统的PDM（产品数据管理）延伸到PLM（产品生命周期管理），基于Teamcenter的集成需求管理解决方案，相比于独立的需求管理工具，有着明显的优势。Teamcenter集成的需求管理解决方案能够把需求延伸到系统设计、结构设计、电气设计、软件开发、工程仿真和试验测试中，能够实现需求的设计闭环验证、仿真闭环验证和测试闭环验证等多轮的验证迭代，在早期就消除产品缺陷，做到一次设计即成功。