产品
本系列文章将致力于阐述系统工程与数字孪生在大型基础设施数字化转型中的应用与实践。笔者核电人出身，故文章逻辑与案例将以核工业作为牵引，用来阐述广义上大基建行业数字化转型与传统制造业的区别，以及其价值（Why）、工作内容（What）、解决方案（How）与实施方法（How to）。
需求工程作为系统工程的首要工作，主要包括需求开发和需求管理，是对需求规范和管理的一种系统化和标准化的方法，其目标一是为了解相关需求，并就这些需求在利益相关者中达成共识，根据既定标准记录和管理；二是为了理解和记忆利益相关者的期望和需求，并详细说明和管理需求，以将所交付系统中不符合利益相关者期望和需求的风险降到最低。
利益相关者（Stakeholder），是一个中性名词（注意不是含贬义的“既得利益者”），也可简称为“涉众”，专指组织外部环境中受组织决策和行动影响的任何相关者，对于需求工程是一个基本术语。
未来需求工程师会扮演越来越重要的角色，不但要深耕某领域并精通其专业术语（如核电），同时要掌握足够的信息技术知识以及数字化转型理念，并能熟练翻译和连接多方涉众的需求。需求工程师担任核心人物的同时免不了会遭受大量的挑战和非议，所以要具备以下七大能力：
根据国际系统工程协会（INCOSE）的研究显示，无论什么领域的项目都约有60%的错误源于需求工程阶段，其原因也不深奥，甚至是人性使然：都是因为员工对不正确或不完整的需求有一种凭借自己的主观臆断或潜意识就能完成的思维趋势，进而导致这些错误在项目后期阶段或应用时才被发现。
大多数人普遍认为需求是不言自明的，已经在脑中很清楚了，而不需要像模像样地明确记录或跟踪。但随着时间的推移和涉众越来越多，就会导致参与各方因各自的经验和知识背景的差异在沟通中出现问题，更糟的是随着技术迭代加速，需求也一直在发生变化。
以我国核工业为例，由于长期历史原因，我们更重视物理实体和静态几何关系、但欠缺顶层设计和动态功能关系，所以必须“知其然，也知其所以然”。系统思维重视顶层需求的完整性，早发现矛盾、早解决矛盾、保持协调一致，避免等到物理实体做完后才发现问题而导致的积重难返、增加额外的风险和成本等。
正所谓“不可描述即不可管理”，所以我们要应用系统工程的思维实现：
1. 获取需求
如前文所述，基于系统工程思维与单一数据源的协同平台，要引导并捕捉多方利益相关者的需求到平台中进行数字化管理。对于大基建或核工业来说一般来自高层的战略、地方的发展规划和能源需求，以及相关国内国际的法律法规等，初步获取的需求层次不同，颗粒度大小不一。
如果初始需求在办公软件文档或其他需求管理软件中描述，可使用平台CATIA-Reqtify模块从多种格式来源获取条目化需求，如pdf, docx, xlsx, rif, slx等60个接口。
通过用户可配置的表格格式从电子表格导入需求，可突出显示、标记和捕获文档中的章节、注释和需求信息，同时保持对源文件的可追溯性。
根据对应系统的层级，实现需求的定义、分解和分配；获取需求基本原理（为什么需要，设计决策，假定条件或参数）、添加参考；通过可定制的视图和筛选来分析需求；获取各项目利益相关者的批复。
应用平台CATIA-STIMULUS模块，像程序员调试代码一样对需求进行仿真，进而保证海量需求的：
尤其通过仿真功能需求在设计开始前检测需求是否正确，检测遗漏和冲突，可基于正确的需求进行系统设计，并在设计完成后通过仿真来验证系统是否满足需求。
在协同平台上基于需求仿真结果形成需求规格文件，可对需求规格进行流程驱动的同行评审或在线迭代评审；根据评审结果维护需求规格的基线，并作为交付物给下游部门。基线管理基于业务流程逻辑，包括基线版本、基线差异比较、历史纪录维护。
基于协同平台可进行拖拽式操作，定义全局设计数据与各层级需求间的追溯范围，同时建立设计各阶段交付物的追溯关系。可通过可视化看板来检查各阶段的交付物与需求条目间的可追溯性、模型比较、一致性等，让系统负责人拥有全局能见度。
在平台中基于单一数据源的理念，可随时创建并浏览与需求关联的文档与数据。
7. 需求确认与生效 当需求处于“发布”状态时，它的整个结构将被冻结并且不能修改。 以可视化图表的形式展示需求的总体状态与统计情况。
8. 需求规格书自动化生成 基于数据自动化生成需求规格书、可追溯性报告与可视化统计报告等。 如何落地实施 如果您希望深入了解主数据模型的详细架构、节点上需要挂的数据类型、以及和业务流程如何映射等具体事宜，请留下您的联系方式与业务需求，我们的工作人员会与您取得联系，并为您提供“业务价值驱动的数字化转型咨询服务（Value Engagement）”
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
