ENOVIA 需求管理优势

• 通过控制需求管理流程来满足标准和法规。
• 通过设计和开发可以准确反映客户声音的新产品来提高产品质量和客户满意度。
• 通过弥合产品需求，设计和发布之间的差距来降低开发成本和返工。
• 因为团队正在使用中央存储库和通用工具来管理产品需求，所以可以提高可见性，团队沟通和协作。
• 在整个需求演变过程中提高总体可追溯性。​​

需求捕捉

产品开发团队能够从客户的技术需求文档中提取需求并存入产品数据中：

• 获取文本、表格、图象、图形、外形、列表、3DXML等文件对象。
• 自动提取需求描述中句子和段落中的关键词。
• 根据章节的标题自动形成需求的组成结构。
• 在提取过程中定义需求的类型、生命周期和属性。
• 定义需求的属性，分配需求的唯一标示 ID。

需求定义

为系统和子系统定义准确，无二义的需求技术规格，让产品开发环节上的参与者统一认识。

• 定义客户需求分解到系统和子系统的详细技术规格描述。
• 定义需求类型和生命周期策略。
• 定义需求规格的结构：章节、备注和描述。
• 需求分类并定义需求之间的约束关系。
• 需求的发放冻结和版本修订。
• 需求的订阅机制。

设计决策

产品开发的过程中，原始的产品设计变化和决策可以为项目团队提供很好的追溯记录。

• 定义需求的基本原理。
• 定义需求来源和逻辑关系。

产品定义与需求分配

产品团队按照产品线、平台以及技术模块进行需求的满足性跟踪。

• 定义产品组合、产品线、平台和产品版本。
• 在ENOVIA变型设计定义产品功能模块与需求的关系。
• 分配需求到产品模型A。
• 分配可选需求。
• 需求满足性承诺。
• 分配需求到产品版本。
• 分配需求到产品功能模块。

定义测试

定义测试用例来确保和验证产品质量能够满足客户需求。

• 为需求定义测试用例。
• 关联参考文档。
• 查询测试用例 where use。
• 测试用例与工程变更的关联。

需求确立

建立需求基线来冻结需求状态和产品实际的功能状态。

• 需求技术规格基线。
• 技术规格冻结和发放。
• 需求基线以及需求的发放控制机制。
• 需求与技术规格的基线版本标准匹配。

需求问题管理

需求的变更由问题引发。

• 捕捉影像需求的问题。
• 记录需求变化的详细描述文档，为什么与客户需求发生偏差。
• 为问题分配对应的责任人员。
• 定义问题解决的优先级。
• 问题分类管理。
• 通过工程变更解决问题，产生需求新版本。

需求变更管理

需求的变更由问题引发

• 捕捉影像需求的问题。
• 记录需求变化的详细描述文档，为什么与客户需求发生偏差。
• 为问题分配对应的责任人员。
• 定义问题解决的优先级。
• 问题分类管理。
• 通过工程变更解决问题，产生需求新版本。

变更的影响分析

项目团队评估工程变更对多个产品、功能模块的影响。

• 捕捉分析信息
• 冲突分析（计划，资源，验证）。
• 相关性分析（成本、处罚、风险）。
• “Where Used” 分析相关的产品、平台、功能模块、生命周期状态以及结构层次A。
• 对比需求规格变更基线。
• 比较不同版本差异、整合不同版本差异。

需求追溯矩阵

产品团队容易从底层的需求和测试用例进行满足性追溯。

• 从任意需求规格执行追溯分析。
• 用户定义报告参数。
• 从高到低的各层需求追溯报告。
• 不同的颜色Red/Green/Yellow显示需求的满足性状态 (疑惑, 有效 or 无效)。
• 需求覆盖率报告。
• 需求到测试用例。
• 需求的符合性报告展示测试用例是否满足需求。
• 不同的颜色Red/Green/Yellow 展示测试用例验证状态。

匹配性追溯

系统工程师确认不同层面的系统需求匹配到不同的产品功能模块。

• 从选择的产品配置生成需求满足性报告。
• 浏览功能模块关联的需求。
• 浏览需求与功能模块的匹配性状态red/green/yellow。