需求追溯

学习目标

完成本模块后，你将能够： - 理解需求追溯的目的和重要性 - 建立完整的需求追溯矩阵 - 使用工具管理需求追溯关系 - 验证需求追溯的完整性 - 应用医疗器械软件的需求追溯最佳实践

前置知识

• 软件需求工程基础
• IEC 62304基本概念
• 软件开发生命周期

内容

需求追溯概述

需求追溯（Requirements Traceability）是建立和维护需求与其他工作产品之间关系的过程。

追溯的目的： - 确保所有需求都被实现 - 验证实现满足需求 - 评估变更的影响 - 支持监管审查 - 便于维护和演进

IEC 62304要求： - Class B和C软件必须建立需求追溯 - 追溯需求到设计、实现和测试 - 维护追溯关系的完整性

追溯关系类型

1. 向前追溯（Forward Traceability）

从需求追溯到下游工作产品。

系统需求 → 软件需求 → 设计 → 代码 → 测试

示例：

系统需求 SR-001: 系统应测量心率
    ↓
软件需求 SWR-001: 软件应从ECG信号计算心率
    ↓
设计 DD-001: HeartRateCalculator类实现心率计算
    ↓
代码 heart_rate.c: calculate_heart_rate()函数
    ↓
测试 TC-001: 验证心率计算准确性

说明: 这是需求追溯链的示例。从系统需求开始，向下追溯到软件需求、设计、代码和测试，形成完整的追溯链。这确保了每个需求都有对应的实现和验证，是医疗器械软件开发的关键要求。

2. 向后追溯（Backward Traceability）

从下游工作产品追溯到需求。

测试 ← 代码 ← 设计 ← 软件需求 ← 系统需求

用途： - 验证每个实现都有对应的需求 - 识别多余的功能 - 确保测试覆盖所有需求

3. 双向追溯（Bidirectional Traceability）

同时维护向前和向后追溯。

系统需求 ⇄ 软件需求 ⇄ 设计 ⇄ 代码 ⇄ 测试

说明: 这是双向追溯关系的示意图。箭头表示可以从任何一个阶段向前或向后追溯，确保需求、设计、实现和测试之间的完整关联，支持影响分析和变更管理。

追溯矩阵

需求追溯矩阵（Requirements Traceability Matrix, RTM）是记录追溯关系的表格。

基本追溯矩阵

系统需求	软件需求	设计	代码	测试	状态
SR-001	SWR-001, SWR-002	DD-001	heart_rate.c	TC-001, TC-002	完成
SR-002	SWR-003	DD-002	spo2.c	TC-003	进行中
SR-003	SWR-004, SWR-005	DD-003, DD-004	display.c	TC-004	完成

详细追溯矩阵

ID	需求描述	优先级	风险等级	设计文档	实现模块	测试用例	验证状态	备注
SWR-001	计算心率	高	Class C	DD-001	heart_rate.c:100-150	TC-001, TC-002	通过	-
SWR-002	检测心律不齐	高	Class C	DD-001	heart_rate.c:200-250	TC-003	通过	-
SWR-003	测量血氧饱和度	高	Class C	DD-002	spo2.c:50-100	TC-004	失败	Bug #123

追溯实现方法

方法1：文档标识符

在文档中使用唯一标识符建立追溯关系。

需求文档：

## SWR-001: 心率计算
系统应从ECG信号计算心率，范围30-300 bpm。

**追溯**：
- 来源：SR-001（系统需求）
- 设计：DD-001（心率计算模块设计）
- 实现：heart_rate.c
- 测试：TC-001, TC-002

设计文档：

## DD-001: 心率计算模块

**追溯**：
- 需求：SWR-001
- 实现：heart_rate.c, calculate_heart_rate()
- 测试：TC-001, TC-002

### 设计描述
...

代码注释：

/**
 * @brief 计算心率
 * @trace SWR-001 心率计算需求
 * @trace DD-001 心率计算模块设计
 * @param ecg_data ECG数据缓冲区
 * @param length 数据长度
 * @return 心率值（bpm）
 */
uint16_t calculate_heart_rate(const int16_t* ecg_data, uint32_t length) {
    // 实现
}

测试用例：

/**
 * @test TC-001: 心率计算准确性测试
 * @trace SWR-001 心率计算需求
 * @trace DD-001 心率计算模块设计
 */
void test_heart_rate_calculation_accuracy(void) {
    // 测试实现
}

方法2：追溯工具

使用专门的需求管理工具维护追溯关系。

工具示例： - IBM DOORS - Jama Connect - PTC Integrity - Polarion - Azure DevOps

工具功能： - 自动生成追溯矩阵 - 可视化追溯关系 - 影响分析 - 覆盖率报告 - 变更追踪

方法3：代码标签

在代码中使用特殊标签标记追溯关系。

// @requirement SWR-001
// @design DD-001
// @test TC-001, TC-002
uint16_t calculate_heart_rate(const int16_t* ecg_data, uint32_t length) {
    uint16_t heart_rate = 0;

    // @requirement SWR-001: 检测R波峰值
    uint32_t r_peaks[MAX_PEAKS];
    uint32_t peak_count = detect_r_peaks(ecg_data, length, r_peaks);

    // @requirement SWR-001: 计算RR间期
    if (peak_count >= 2) {
        uint32_t rr_interval = calculate_rr_interval(r_peaks, peak_count);

        // @requirement SWR-001: 转换为心率（bpm）
        heart_rate = 60000 / rr_interval;  // 60秒 * 1000ms
    }

    return heart_rate;
}

提取追溯信息的脚本：

import re

def extract_traceability(source_file):
    """从源代码提取追溯信息"""
    traceability = []

    with open(source_file, 'r') as f:
        content = f.read()

    # 查找追溯标签
    requirements = re.findall(r'@requirement\s+([\w-]+)', content)
    designs = re.findall(r'@design\s+([\w-]+)', content)
    tests = re.findall(r'@test\s+([\w-,\s]+)', content)

    return {
        'file': source_file,
        'requirements': requirements,
        'designs': designs,
        'tests': [t.strip() for test in tests for t in test.split(',')]
    }

def generate_traceability_matrix(source_files):
    """生成追溯矩阵"""
    matrix = []

    for file in source_files:
        trace_info = extract_traceability(file)
        matrix.append(trace_info)

    return matrix

追溯验证

完整性检查

向前完整性：每个需求都有对应的设计、实现和测试。

def check_forward_completeness(requirements, designs, code, tests):
    """检查向前追溯完整性"""
    incomplete_requirements = []

    for req in requirements:
        req_id = req['id']

        # 检查是否有对应的设计
        if not any(req_id in d['traces_to'] for d in designs):
            incomplete_requirements.append({
                'requirement': req_id,
                'missing': 'design'
            })

        # 检查是否有对应的实现
        if not any(req_id in c['traces_to'] for c in code):
            incomplete_requirements.append({
                'requirement': req_id,
                'missing': 'implementation'
            })

        # 检查是否有对应的测试
        if not any(req_id in t['traces_to'] for t in tests):
            incomplete_requirements.append({
                'requirement': req_id,
                'missing': 'test'
            })

    return incomplete_requirements

向后完整性：每个实现和测试都有对应的需求。

def check_backward_completeness(code, tests, requirements):
    """检查向后追溯完整性"""
    orphaned_items = []

    # 检查孤立的代码
    for c in code:
        if not c['traces_to']:
            orphaned_items.append({
                'type': 'code',
                'item': c['file'],
                'issue': 'no requirement'
            })

    # 检查孤立的测试
    for t in tests:
        if not t['traces_to']:
            orphaned_items.append({
                'type': 'test',
                'item': t['id'],
                'issue': 'no requirement'
            })

    return orphaned_items

覆盖率分析

需求覆盖率：

def calculate_requirement_coverage(requirements, tests):
    """计算需求测试覆盖率"""
    total_requirements = len(requirements)
    covered_requirements = 0

    for req in requirements:
        req_id = req['id']
        if any(req_id in t['traces_to'] for t in tests):
            covered_requirements += 1

    coverage = (covered_requirements / total_requirements) * 100

    return {
        'total': total_requirements,
        'covered': covered_requirements,
        'coverage_percent': coverage
    }

测试覆盖率报告：

需求测试覆盖率报告
====================

总需求数：50
已覆盖：48
未覆盖：2
覆盖率：96%

未覆盖需求：
- SWR-023: 电池电量监测
- SWR-041: 数据导出功能

建议：
1. 为SWR-023添加测试用例
2. 为SWR-041添加测试用例

说明: 这是需求测试覆盖率报告的示例格式。显示总需求数、已覆盖数、未覆盖数和覆盖率百分比，并列出未覆盖的需求，帮助识别测试缺口。

变更影响分析

使用追溯关系分析需求变更的影响。

def analyze_change_impact(changed_requirement, traceability_matrix):
    """分析需求变更的影响"""
    impact = {
        'requirement': changed_requirement,
        'affected_designs': [],
        'affected_code': [],
        'affected_tests': []
    }

    # 查找受影响的设计
    for design in traceability_matrix['designs']:
        if changed_requirement in design['traces_to']:
            impact['affected_designs'].append(design['id'])

    # 查找受影响的代码
    for code in traceability_matrix['code']:
        if changed_requirement in code['traces_to']:
            impact['affected_code'].append(code['file'])

    # 查找受影响的测试
    for test in traceability_matrix['tests']:
        if changed_requirement in test['traces_to']:
            impact['affected_tests'].append(test['id'])

    return impact

# 使用示例
impact = analyze_change_impact('SWR-001', traceability_matrix)
print(f"变更需求：{impact['requirement']}")
print(f"受影响的设计：{', '.join(impact['affected_designs'])}")
print(f"受影响的代码：{', '.join(impact['affected_code'])}")
print(f"受影响的测试：{', '.join(impact['affected_tests'])}")

医疗器械追溯最佳实践

1. 建立追溯策略

# 需求追溯策略

## 追溯范围
- 系统需求 → 软件需求
- 软件需求 → 架构设计
- 软件需求 → 详细设计
- 详细设计 → 源代码
- 软件需求 → 测试用例
- 测试用例 → 测试结果

## 追溯方法
- 使用唯一标识符
- 在文档中明确标注追溯关系
- 使用工具自动化追溯管理

## 追溯验证
- 每个sprint结束时验证追溯完整性
- 发布前进行完整的追溯审查
- 使用自动化脚本检查追溯覆盖率

## 追溯维护
- 需求变更时更新追溯关系
- 定期审查追溯矩阵
- 记录追溯变更历史

2. 使用一致的标识符

命名规范：
- 系统需求：SR-XXX
- 软件需求：SWR-XXX
- 架构设计：AD-XXX
- 详细设计：DD-XXX
- 测试用例：TC-XXX
- 风险：RISK-XXX

说明: 这是追溯ID的命名规范。使用统一的前缀和编号格式(SR-系统需求、SWR-软件需求、AD-架构设计、DD-详细设计、TC-测试用例、RISK-风险)，便于识别和管理。

3. 自动化追溯管理

# 追溯管理工具示例
class TraceabilityManager:
    def __init__(self):
        self.requirements = []
        self.designs = []
        self.code = []
        self.tests = []

    def add_trace(self, source_type, source_id, target_type, target_id):
        """添加追溯关系"""
        trace = {
            'source_type': source_type,
            'source_id': source_id,
            'target_type': target_type,
            'target_id': target_id
        }
        # 存储追溯关系

    def get_traces_from(self, source_type, source_id):
        """获取从指定项追溯的所有目标"""
        # 返回追溯目标列表

    def get_traces_to(self, target_type, target_id):
        """获取追溯到指定项的所有源"""
        # 返回追溯源列表

    def generate_matrix(self):
        """生成追溯矩阵"""
        # 生成并返回追溯矩阵

    def validate_completeness(self):
        """验证追溯完整性"""
        # 检查并返回完整性报告

4. 定期审查

追溯审查清单：
□ 所有需求都有对应的设计
□ 所有需求都有对应的实现
□ 所有需求都有对应的测试
□ 所有实现都追溯到需求
□ 所有测试都追溯到需求
□ 追溯关系准确无误
□ 追溯文档是最新的
□ 变更已反映在追溯中

说明: 这是追溯审查的检查清单。包括需求到设计、实现、测试的完整性检查，以及追溯关系的准确性和文档的最新性检查，确保追溯体系的质量。

追溯工具集成

与版本控制集成

# Git commit消息中包含追溯信息
git commit -m "Implement heart rate calculation

Implements: SWR-001
Design: DD-001
Tests: TC-001, TC-002"

与CI/CD集成

# .gitlab-ci.yml
traceability_check:
  stage: validate
  script:
    - python scripts/check_traceability.py
    - python scripts/generate_rtm.py
  artifacts:
    reports:
      - traceability_matrix.html

实践练习

1. 为一个简单的医疗器械功能建立完整的追溯矩阵
2. 编写脚本从代码注释中提取追溯信息
3. 分析一个需求变更对系统的影响
4. 验证一个项目的追溯完整性并生成报告

相关资源

相关知识模块

• 变更管理 - 需求变更的管理流程
• IEC 62304生命周期过程 - 软件生命周期中的追溯要求

深入学习

• 需求工程概述 - 需求工程的基础知识
• 测试策略 - 测试与需求的追溯关系
• 配置管理 - 追溯信息的版本控制

参考文献

1. IEC 62304:2006+AMD1:2015 - Medical device software - Software life cycle processes
2. ISO/IEC/IEEE 29148:2018 - Systems and software engineering - Life cycle processes - Requirements engineering
3. FDA Guidance - General Principles of Software Validation
4. "Software Requirements" by Karl Wiegers and Joy Beatty
5. "Requirements Engineering for Software and Systems" by Phillip A. Laplante

自测问题

问题1：什么是需求追溯？为什么重要？

问题：解释需求追溯的概念及其在医疗器械软件开发中的重要性。

答案

需求追溯定义： 建立和维护需求与其他工作产品（设计、代码、测试）之间关系的过程。

重要性：

1. 确保完整性：
2. 确保所有需求都被实现

3. 验证实现满足需求

4. 变更管理：

5. 评估变更的影响范围

6. 识别需要更新的工作产品

7. 监管合规：

8. IEC 62304要求Class B和C软件建立追溯

9. 支持监管审查和审计

10. 质量保证：

11. 验证测试覆盖所有需求

12. 识别多余的功能

13. 维护支持：

14. 便于理解系统
15. 支持长期维护和演进

知识点回顾：需求追溯是医疗器械软件质量管理的核心实践。

问题2：向前追溯和向后追溯有什么区别？

问题：解释向前追溯和向后追溯的概念，并说明各自的用途。

答案

向前追溯（Forward Traceability）： - 定义：从需求追溯到下游工作产品 - 方向：需求 → 设计 → 代码 → 测试 - 用途： - 确保所有需求都被实现 - 验证实现的完整性 - 评估需求变更的影响

向后追溯（Backward Traceability）： - 定义：从下游工作产品追溯到需求 - 方向：测试 ← 代码 ← 设计 ← 需求 - 用途： - 验证每个实现都有对应的需求 - 识别多余的功能（金镀层） - 确保测试覆盖所有需求

双向追溯： - 同时维护向前和向后追溯 - 提供最完整的追溯信息 - IEC 62304推荐的方法

知识点回顾：双向追溯提供最全面的需求管理能力。

问题3：如何在代码中实现需求追溯？

问题：描述至少两种在源代码中建立需求追溯关系的方法。

答案

方法1：代码注释标签：

/**
 * @brief 计算心率
 * @trace SWR-001 心率计算需求
 * @trace DD-001 心率计算模块设计
 * @param ecg_data ECG数据缓冲区
 * @return 心率值（bpm）
 */
uint16_t calculate_heart_rate(const int16_t* ecg_data) {
    // @requirement SWR-001: 检测R波峰值
    detect_r_peaks(ecg_data);

    // @requirement SWR-001: 计算RR间期
    calculate_rr_interval();
}

方法2：特殊注释标记：

// TRACE: SWR-001, DD-001
// TEST: TC-001, TC-002
void process_sensor_data(void) {
    // 实现
}

方法3：使用追溯工具： - 在需求管理工具中建立链接 - 工具自动提取和验证追溯关系 - 生成追溯矩阵报告

提取追溯信息： - 使用脚本解析代码注释 - 自动生成追溯矩阵 - 验证追溯完整性

知识点回顾：代码级追溯确保实现与需求的直接对应关系。

问题4：如何验证追溯的完整性？

问题：描述验证需求追溯完整性的方法和检查项。

答案

完整性检查方法：

1. 向前完整性检查：

# 检查每个需求是否有对应的实现和测试
for requirement in requirements:
    if not has_design(requirement):
        report_missing("设计", requirement)
    if not has_implementation(requirement):
        report_missing("实现", requirement)
    if not has_test(requirement):
        report_missing("测试", requirement)

2. 向后完整性检查：

# 检查每个实现是否有对应的需求
for code_module in code_modules:
    if not has_requirement(code_module):
        report_orphan("代码", code_module)

for test in tests:
    if not has_requirement(test):
        report_orphan("测试", test)

3. 覆盖率分析： - 需求测试覆盖率 - 需求实现覆盖率 - 设计实现覆盖率

4. 自动化验证： - 使用脚本自动检查 - 集成到CI/CD流程 - 定期生成追溯报告

检查清单： - ☐ 所有需求都有对应的设计 - ☐ 所有需求都有对应的实现 - ☐ 所有需求都有对应的测试 - ☐ 所有实现都追溯到需求 - ☐ 所有测试都追溯到需求 - ☐ 追溯关系准确无误

知识点回顾：自动化验证是确保追溯完整性的最有效方法。

问题5：需求变更时如何进行影响分析？

问题：当一个需求发生变更时，如何使用追溯关系进行影响分析？

答案

影响分析步骤：

1. 识别变更需求： - 确定变更的需求ID - 理解变更的性质和范围

2. 追溯受影响的工作产品：

需求 SWR-001 变更
↓
查找追溯关系
↓
受影响的设计：DD-001, DD-003
受影响的代码：heart_rate.c, display.c
受影响的测试：TC-001, TC-002, TC-005

3. 评估影响程度： - 需要修改的设计文档 - 需要修改的代码模块 - 需要更新的测试用例 - 需要重新验证的功能

4. 制定变更计划： - 更新设计文档 - 修改代码实现 - 更新测试用例 - 重新运行测试 - 更新追溯矩阵

5. 验证变更： - 确认所有受影响的工作产品已更新 - 验证追溯关系仍然完整 - 确认所有测试通过

示例影响分析报告：

变更需求：SWR-001
影响范围：
- 设计文档：2个
- 代码文件：3个
- 测试用例：5个
预计工作量：8小时
风险评估：中等

知识点回顾：追溯关系使变更影响分析变得系统化和可追踪。

---

内容有用

报告问题 链接失效 建议改进

---

💬 讨论区

欢迎在这里分享您的想法、提出问题或参与讨论。需要 GitHub 账号登录。