S1000D DMRL 是什么？数据模块需求清单、字段与编制流程

DMRL（Data Module Requirements List，数据模块需求清单）把项目需要的技术信息拆成可分配、可审核、可交付的模块需求。它把需求来源、DMC、系统层级、模块类型、责任人、依赖和完成状态放在同一条跟踪链路中，帮助团队回答“要编哪些模块、谁负责、何时交付、如何验收”。

本文由北京重子科技 VizMan IETM 团队编写，最后更新：2026-09。页面用于中文学习与项目规划，不替代 S1000D 正式规范。

DMRL 解决什么问题？常见字段责任、状态与依赖编制流程示例检查清单常见问题

DMRL 解决什么问题？

大型装备项目的技术资料来自设计、维修、试验、供应商和用户需求。没有统一的需求清单时，团队容易遗漏模块、重复编制，或者只完成了文件却无法证明它满足哪个任务和配置。DMRL 将每项需求与明确的身份、范围和状态关联起来，是从需求分析走向数据模块生产和交付验收的管理基础。

DMRL 不是简单的文件目录：它需要说明模块为什么存在、服务哪个任务或系统、由谁负责、依赖什么输入、处于什么状态，以及最终如何验收。目录只回答“有哪些文件”，DMRL 还要回答“需求是否被覆盖”。

DMRL 常见字段

不同项目会采用电子表格、数据库、CSDB 管理对象或定制工具维护 DMRL。下面列出常见字段，用于设计模板和评审清单；正式项目应根据合同、DMRL 模板、采用的 S1000D Issue 和业务规则裁剪。

字段通常记录的内容核对重点
dmrlId / 条目编号DMRL 条目的稳定标识。编号唯一，修改标题或负责人时不随意重用。
dmc / DMC数据模块代码，或在正式 DMC 确定前的临时标识。与 SNS、型号、信息类型和项目编码规则一致；临时值要有转正规则。
模块标题与类型读者主题、信息类型及预计内容边界。描述、程序、故障隔离、零件等类型是否适合目标任务。
需求来源合同条款、任务分析、设计资料、故障报告、法规或用户需求。能回溯到原始来源、章节或需求编号，避免“来源不明”。
SNS / 系统与适用性所属系统层级、型号、构型、序列号范围或其他适用条件。与 DMC、PM、适用性表达和目标用户保持一致。
优先级与目标日期编制顺序、里程碑、提交或批准期限。优先级有定义，日期变更有原因和批准记录。
责任人与审核人编制、技术审核、语言审核、配置管理和最终批准责任。每个角色有明确边界，不能只写一个无法追踪的部门名称。
状态与版本分析、分配、编制、审核、批准、发布、暂停或取消等状态。状态转换有条件、有时间、有责任人，版本与交付包对应。
依赖与交付要求前置模块、引用资料、媒体、翻译、输出格式和验收标准。依赖可追踪，缺少输入时不会被误标为“已完成”。

责任、状态与依赖如何管理？

责任分工

DMRL 最少应区分需求提出或确认人、数据模块编制人、技术审核人、语言或格式审核人、配置管理人员和批准人。小型项目可以由同一人承担多个角色，但记录仍要保留，以便复盘和验收。责任人变更时，不能只替换姓名，还应记录交接日期、未完成工作和影响范围。

状态转换

状态示例进入条件离开状态的证据
待分析需求已登记但范围、类型或来源尚未确认。完成任务边界、来源和目标模块类型确认。
已分配需求已确认并指定编制责任人。责任人接受任务，输入资料和目标日期已明确。
编制中作者正在建立数据模块内容。结构校验通过，依赖资料和媒体达到可审核状态。
待审核作者提交模块，等待技术、语言或配置审核。审核意见已处理，问题关闭或有批准的豁免。
已批准 / 已发布模块满足批准条件并纳入交付基线。批准记录、版本号、发布包和 DMRL 条目一致。
暂停 / 取消需求被暂缓、合并或确认不再交付。保留原因、替代条目或影响评估，不能静默删除。

依赖关系

依赖可以来自前置数据模块、DMC/SNS 代码表、BREX、图形和 3D 媒体、适用性规则、翻译或外部设计资料。建议把依赖写成可识别的条目，而不是备注中的一句“等待资料”。对于循环依赖、缺失输入和版本不匹配，应在 DMRL 中显式标记并阻止错误的完成状态。

DMRL 编制与维护流程

  1. 收集需求：从合同、任务分析、维修概念、设计资料、故障报告和用户意见提取技术信息需求。
  2. 划分模块：确定每个模块的主题边界、信息类型、受众、系统层级和适用性，避免把整本手册当成一个条目。
  3. 建立身份：分配 DMC 或临时标识，核对型号、SNS、信息代码、组件和变体等编码字段。
  4. 补齐管理字段：指定责任人、审核角色、优先级、目标日期、依赖、交付格式和验收标准。
  5. 试编和评审：用代表性条目验证模块类型、字段、代码表、BREX、引用和适用性规则是否可执行。
  6. 持续更新：编制、审核、批准、发布、返工、暂停和取消都要回写 DMRL，保留变更历史和依据。
  7. 交付核对：将 DMRL 与最终数据模块、PM、IETP/PDF/其他交付包逐条比对，处理遗漏和多余项。
建议设一个“完成”门槛：只有当模块结构校验、内容审核、引用与媒体、适用性、状态和交付包都达到项目定义的条件时，DMRL 才能标记为已批准或已发布。

DMRL 条目示例

下面示例以“更换液压泵”维修程序为对象，展示如何把需求、责任、依赖和验收条件放在同一条记录中。字段名称和状态仅为项目模板示意。

字段示例值
DMRL 条目DMRL-0237
DMC / 临时标识ABC-23-10-02-01-040A-A（示意，须按项目规则确认）
标题与类型更换液压泵；维修程序模块（procedural）
需求来源液压系统维修任务分析 TA-0237；型号维修方案第 4.2 节
SNS / 适用性23-10-02；型号 ABC，构型 A
责任与时间编制：张三；技术审核：李四；目标提交：2026-10-15
依赖安全信息模块、安全警告图形、泵组件 IPC、适用性代码表 v2.1
验收条件Schema 与 BREX 通过；步骤可复现；引用可解析；适用性筛选正确；纳入 PM 和交付包。
状态待审核；版本 1.2；上次退回原因已关闭
DMRL-0237 | 23-10-02 | procedural | 待审核
来源 TA-0237 | 责任 张三 | 审核 李四
依赖 安全信息 / IPC / 适用性代码表 v2.1
验收 Schema+BREX+引用+适用性+交付包

示例中的 DMC、人员和日期用于说明字段关系，不代表任何正式型号项目的编码或交付承诺。正式项目应使用经批准的 DMC、代码表、人员标识和配置基线。

DMRL 项目检查清单

  1. 覆盖：合同、任务分析和用户需求是否都能追溯到一个或多个 DMRL 条目？
  2. 边界：每个条目是否有清晰的主题、模块类型、系统层级、适用性和交付范围？
  3. 身份：DMC、临时标识、SNS、标题和 PM 引用是否一致且唯一？
  4. 责任：编制、审核、配置管理和批准角色是否明确，人员变更是否有交接记录？
  5. 状态：状态转换是否有进入条件、退出证据、时间和责任人？
  6. 依赖：前置模块、媒体、代码表、BREX、翻译和外部资料是否已标识并可追踪？
  7. 质量：是否完成结构、规则、内容、引用、适用性和专业安全审核？
  8. 交付：已发布条目是否与 PM、IETP、PDF 或其他交付包逐项核对，并保留差异处理记录？
验收建议：随机抽取一条已发布 DMRL 记录，反向追到原始需求、DMC、数据模块、审核记录、PM 和交付文件；再抽取一条“取消”或“暂停”记录，确认原因、替代关系和历史版本仍可解释。

常见问题

S1000D DMRL 是什么？

DMRL 是数据模块需求清单，把项目需要编制、审核、交付或维护的数据模块列成可跟踪条目，连接任务分析、DMC、责任分工、状态和验收。

DMRL 是数据模块本身吗？

不是。数据模块承载实际技术内容，DMRL 是描述模块需求和完成情况的清单或管理对象。

DMRL 需要包含哪些字段？

常见字段包括 DMC 或临时标识、标题、模块类型、系统或 SNS、需求来源、责任人、优先级、状态、依赖、适用性、目标日期、审核人和交付要求。

DMRL 中的状态如何管理？

可按项目定义待分析、已分配、编制中、待审核、已批准、已发布、暂停或取消等状态，并保留每次状态转换的责任人、时间和依据。

DMRL 与 DMC、SNS、PM 有什么关系？

DMRL 跟踪需求，DMC 标识模块，SNS 提供系统层级，PM 组织出版物目录。它们应通过稳定标识和映射关联，形成从需求到交付的追溯链。

相关页面

S1000D 标准总览数据模块DMC 数据模块代码SNS 系统划分码PM 与适用性CSDBBREXGJB 6600 说明S1000D 官方网站