用Mermaid需求图重构医疗系统需求管理流程

揭示传统需求管理的五大痛点

当医院信息系统升级项目进行到第三季度时，张医生发现护理记录模块的需求文档已经堆积了37版Word文档，其中"患者数据同步"相关的需求变更达14处，却没人能说清当前有效的需求版本。这不是个例——传统需求管理正面临着五大核心挑战：需求关系混乱如蜘蛛网难以梳理、变更影响范围无法快速评估、文档与代码实现脱节、跨团队协作存在信息壁垒、测试用例与需求追溯困难。

可视化需求管理工具Mermaid.js的需求图功能，通过文本驱动的方式将需求转化为结构化图表，为解决这些痛点提供了全新方案。本文将以医疗和教育领域案例为基础，展示如何用Mermaid需求图构建清晰、可维护的需求管理体系。

构建需求间的关联网络

如何让分散的需求形成有机整体？Mermaid需求图的核心价值在于能清晰表达需求间的七种关系类型，这是传统文档难以实现的可视化优势。以下是一个远程医疗平台的核心需求关系示例：

requirementDiagram
  requirement 远程诊断系统
  functionalRequirement 视频会诊功能
  performanceRequirement 传输延迟要求
  securityRequirement 数据加密标准
  
  远程诊断系统 - contains -> 视频会诊功能
  视频会诊功能 - traces -> 传输延迟要求
  视频会诊功能 - satisfies -> 数据加密标准
  传输延迟要求 - verifies -> 数据加密标准

在这个案例中：

• contains 表示整体与部分关系（系统包含功能）
• traces 表示需求间的追溯关系（功能依赖性能指标）
• satisfies 表示实现关系（功能满足安全要求）
• verifies 表示验证关系（性能测试验证安全标准）

💡 提示：关系定义遵循SysML规范，共支持contains（包含）、derives（派生）、satisfies（满足）、verifies（验证）、refines（细化）、traces（追溯）和copies（复制）七种类型，覆盖需求管理全场景。

定义需求与实体元素

需求由谁来实现？实现结果如何验证？Mermaid需求图通过"元素（Element）"概念连接需求与实际交付物。以下是一个医学院教学管理系统的元素定义示例：

requirementDiagram
  requirement 在线考试系统 {
    id: EDU-001
    text: 支持500人同时在线考试
    risk: Medium
    verifymethod: Test
  }
  
  element 考试服务 {
    type: 微服务
    docref: src/services/exam/
  }
  
  element 压力测试报告 {
    type: 测试文档
    docref: docs/tests/stress-exam.md
  }
  
  考试服务 - satisfies -> 在线考试系统
  压力测试报告 - verifies -> 在线考试系统

元素类型可以是代码模块、测试用例、文档等任何实体，通过docref属性直接链接到实际资源。每个需求包含四个核心属性：唯一ID、描述文本、风险等级（High/Medium/Low）和验证方法（Test/Analysis/Inspection/Demonstration）。

💡 提示：需求ID建议采用"系统简称-序号"格式（如EDU-001），便于跨文档引用和版本追踪。风险等级和验证方法会影响后续测试策略，应在需求定义阶段明确。

高级技巧：从复杂到清晰的需求组织

当需求数量超过20个时，如何保持图表的可读性？Mermaid提供了多种高级技巧帮助管理复杂需求。

子图嵌套实现模块化管理

医疗系统中的电子病历模块需求可按功能域分组：

requirementDiagram
  direction TB
  
  subgraph 电子病历核心功能
    requirement 数据录入
    requirement 查询检索
    requirement 历史对比
  end
  
  subgraph 安全与合规
    securityRequirement 隐私保护
    securityRequirement 审计跟踪
  end
  
  电子病历核心功能 - contains -> 数据录入
  安全与合规 - refines -> 数据录入

条件样式区分需求优先级

通过类定义（classDef）为不同优先级需求设置视觉标识：

requirementDiagram
  classDef critical fill:#ff4444,stroke:#aa0000,stroke-width:2px
  classDef normal fill:#44dd44,stroke:#00aa00
  
  requirement 急救数据实时传输:::critical {
    id: MED-001
    text: 急救车数据需实时传输到医院系统
    risk: High
    verifymethod: Test
  }
  
  requirement 患者信息统计:::normal {
    id: MED-002
    text: 生成月度患者就诊统计报表
    risk: Low
    verifymethod: Inspection
  }

批量导入与动态数据

对于大型项目，可通过外部文件导入需求数据：

requirementDiagram
  direction LR
  
  // 从CSV文件导入需求数据
  // import requirements from 'data/requirements.csv'
  
  requirement 门诊预约
  requirement 检查预约
  requirement 治疗计划
  
  门诊预约 - contains -> 检查预约
  检查预约 - traces -> 治疗计划

💡 提示：批量导入功能需要配合Mermaid CLI工具使用，可通过mermaid --requirement-import data.csv diagram.mmd命令实现外部数据整合。

需求变更管理：追踪变化的完整轨迹

需求变更如何影响其他需求？Mermaid需求图通过版本标记和变更关系，构建完整的变更追溯链。以下是一个疫苗接种管理系统的变更示例：

requirementDiagram
  direction BT
  
  requirement 疫苗库存管理_v1 {
    id: VAC-001_v1
    text: 手动记录疫苗入库数量
    risk: Medium
    verifymethod: Inspection
  }
  
  requirement 疫苗库存管理_v2 {
    id: VAC-001_v2
    text: 扫码自动记录疫苗入库及有效期
    risk: Low
    verifymethod: Test
  }
  
  element 库存管理模块_v1
  element 库存管理模块_v2
  
  VAC-001_v1 - derives -> VAC-001_v2
  库存管理模块_v1 - satisfies -> VAC-001_v1
  库存管理模块_v2 - satisfies -> VAC-001_v2
  VAC-001_v2 - affects -> 疫苗有效期提醒

变更管理最佳实践：

1. 为每个变更的需求创建新版本（如_v2后缀）
2. 使用derives关系表示版本演进
3. 用affects关系标记受影响的其他需求
4. 在元素定义中体现实现版本的对应关系

实战案例：医院信息系统需求全景图

以下是一个综合医院信息系统的完整需求图，展示Mermaid在大型项目中的应用：

requirementDiagram
  direction LR
  classDef high fill:#ff9999,stroke:#cc0000
  classDef medium fill:#ffff99,stroke:#cccc00
  classDef low fill:#99ff99,stroke:#00cc00
  
  requirement 医院信息系统:::high {
    id: HIS-001
    text: 整合门诊、住院、检验的综合信息系统
    risk: High
    verifymethod: Demonstration
  }
  
  subgraph 门诊管理
    functionalRequirement 挂号系统:::medium {
      id: HIS-002
      text: 支持现场、线上多渠道挂号
      risk: Medium
      verifymethod: Test
    }
    functionalRequirement 医生工作站:::medium {
      id: HIS-003
      text: 电子处方开具与病历记录
      risk: Medium
      verifymethod: Test
    }
  end
  
  subgraph 住院管理
    functionalRequirement 床位管理:::medium {
      id: HIS-004
      text: 实时床位状态监控与分配
      risk: Medium
      verifymethod: Test
    }
  end
  
  subgraph 系统质量属性
    performanceRequirement 响应时间:::low {
      id: HIS-005
      text: 高峰期页面加载<3秒
      risk: Low
      verifymethod: Test
    }
    securityRequirement 数据加密:::high {
      id: HIS-006
      text: 患者数据传输全程加密
      risk: High
      verifymethod: Analysis
    }
  end
  
  element 门诊模块代码 {
    type: 源代码
    docref: src/modules/outpatient/
  }
  
  element 安全审计报告 {
    type: 文档
    docref: docs/security/audit.md
  }
  
  HIS-001 - contains -> 门诊管理
  HIS-001 - contains -> 住院管理
  HIS-001 - contains -> 系统质量属性
  门诊模块代码 - satisfies -> 挂号系统
  安全审计报告 - verifies -> 数据加密
  医生工作站 - traces -> 响应时间

这个案例展示了：

• 多层级需求结构（系统→子系统→功能需求）
• 不同类型需求的分类管理
• 需求与实现元素的关联关系
• 基于风险等级的视觉区分

实用资源与模板

基础需求图模板

requirementDiagram
  direction LR
  
  requirement 核心需求 {
    id: PROJ-001
    text: [在此填写核心需求描述]
    risk: [High/Medium/Low]
    verifymethod: [Test/Analysis/Inspection/Demonstration]
  }
  
  functionalRequirement 功能需求 {
    id: PROJ-002
    text: [在此填写功能需求描述]
    risk: [High/Medium/Low]
    verifymethod: [Test/Analysis/Inspection/Demonstration]
  }
  
  element 实现模块 {
    type: [模块类型]
    docref: [代码或文档路径]
  }
  
  核心需求 - contains -> 功能需求
  实现模块 - satisfies -> 功能需求

项目级需求管理模板

requirementDiagram
  direction TB
  
  classDef mustHave fill:#ff9999,stroke:#cc0000
  classDef shouldHave fill:#ffff99,stroke:#cccc00
  classDef couldHave fill:#99ff99,stroke:#00cc00
  
  requirement 项目总需求 {
    id: PRJ-000
    text: [项目总体目标描述]
    risk: Medium
    verifymethod: Demonstration
  }
  
  subgraph 功能需求集
    requirement 核心功能:::mustHave {
      id: PRJ-001
      text: [核心功能描述]
      risk: High
      verifymethod: Test
    }
    requirement 次要功能:::shouldHave {
      id: PRJ-002
      text: [次要功能描述]
      risk: Medium
      verifymethod: Test
    }
  end
  
  subgraph 非功能需求
    performanceRequirement 性能指标:::shouldHave {
      id: PRJ-003
      text: [性能要求描述]
      risk: Medium
      verifymethod: Test
    }
    securityRequirement 安全要求:::mustHave {
      id: PRJ-004
      text: [安全要求描述]
      risk: High
      verifymethod: Analysis
    }
  end
  
  subgraph 实现元素
    element 核心模块 {
      type: 源代码
      docref: src/core/
    }
    element 测试用例 {
      type: 测试文档
      docref: tests/
    }
  end
  
  项目总需求 - contains -> 功能需求集
  项目总需求 - contains -> 非功能需求
  核心模块 - satisfies -> 核心功能
  测试用例 - verifies -> 性能指标

需求变更管理模板

requirementDiagram
  direction BT
  
  requirement 原始需求_v1 {
    id: REQ-001_v1
    text: [原始需求描述]
    risk: [原始风险等级]
    verifymethod: [原始验证方法]
  }
  
  requirement 变更后需求_v2 {
    id: REQ-001_v2
    text: [变更后需求描述]
    risk: [变更后风险等级]
    verifymethod: [变更后验证方法]
  }
  
  element 旧实现版本 {
    type: 源代码
    docref: src/v1/
  }
  
  element 新实现版本 {
    type: 源代码
    docref: src/v2/
  }
  
  element 变更说明文档 {
    type: 文档
    docref: docs/changes/REQ-001.md
  }
  
  REQ-001_v1 - derives -> REQ-001_v2
  旧实现版本 - satisfies -> REQ-001_v1
  新实现版本 - satisfies -> REQ-001_v2
  变更说明文档 - traces -> REQ-001_v2
  REQ-001_v2 - affects -> [受影响的其他需求ID]

学习资源

1. 官方语法文档：docs/syntax/requirementDiagram.md
2. 测试用例示例：cypress/integration/rendering/requirementDiagram-unified.spec.js
3. 在线编辑器：demos/requirements.html
4. 布局配置指南：docs/config/configuration.md
5. 主题定制教程：docs/config/theming.md

相关工具推荐

1. Mermaid CLI：命令行渲染工具，支持批量处理需求图
2. Mermaid Live Editor：在线实时编辑与预览工具
3. Mermaid VS Code插件：集成开发环境中的语法高亮与预览

通过Mermaid需求图，团队可以将分散的需求转化为结构化的可视化网络，实现需求的可追溯、可管理和可验证。无论是医疗系统的复杂需求关系，还是教育平台的功能模块划分，这种文本驱动的可视化方法都能显著提升需求管理效率，减少沟通成本，确保项目交付质量。

图：Mermaid Live Editor界面，左侧为需求图代码，右侧实时预览效果

图：需求图导出选项支持PNG、SVG等多种格式，便于文档集成

图：Mermaid同时支持甘特图等多种图表类型，可与需求图配合使用实现项目全流程可视化