夜雨聆风软件可追溯性（Software Traceability）是软件验证和确认（Software Verification and Validation）的核心活动，其目的是通过建立软件开发各阶段产物之间的逻辑链接，确保软件的功能、安全性和质量得到完整实现。
1.可追溯性分析的范围
通常涵盖产品需求、软件需求、软件设计、源代码（具体到软件单元即可）、软件测试以及风险管理之间的双向关系，分析已识别关系的正确性、一致性、完整性、准确性。
2.可追溯性分析什么阶段做？
软件生存周期过程均需开展可追溯性分析活动，各阶段的可追溯性分析不同。
《医疗器械软件注册审查指导原则（2022年修订版）》要求：
即
软件需求分析阶段：软件需求-产品需求-风险分析关系（双向）
软件设计阶段：软件设计-软件需求-风险控制关系（双向）
软件编码阶段：源代码-软件设计-测试用例关系（双向）
软件测试（内部测试）：测试用例-系统测试-软件设计-软件需求-风险管理关系（双向）
用户测试：用户测试-产品需求-风险管理关系（双向）
理想情况下（虽然不会理想），如果在各阶段做好可追溯分析，到产品注册阶段只需整合资料提交即可）
3.可追溯文件的要求
3.1 国内软件可追溯分析强调五位一体，即明确要求追踪软件需求、设计、源码、测试、风险管理之间的关系。
可追溯分析文档内容要求（《医疗器械软件注册审查指导原则（2022年修订版）》）：
（1）软件可追溯性分析流程图，依据流程图详述软件可追溯性分析过程的具体活动（即第2部分）。
（2）提供软件可追溯性分析报告，汇总列明软件需求规范文档、软件设计规范文档、源代码（明确软件单元名称即可）、软件测试报告、软件风险分析报告之间的对应关系（列个追溯表格矩阵即可，第一行列名这些追溯项，列出每条软件需求与这些追溯项的对应关系），另附软件开发所形成的原始文件（目前经验还没有要求强制提交）。
3.2 关于FDA软件可追溯性要求，软件验证和确认（Software Verification and Validation）提到国内注册阶段最多（C级软件）要求提交集成、系统和用户测试计划和报告，FDA要求则是最多（Enhanced Documentation Level）要求提交单元、集成和系统，主要强调验证和确认（V&V）支持： 通过追溯分析验证设计输出符合设计输入，且源代码与测试用例（单元、集成和系统测试）、设计规范挂钩。
FDA软件指南《Content of Premarket Submissions for Device Software Functions June 14, 2023》建议将识别出的危害追踪至具体的风险控制需求（ID）和测试项目。
即 SRS-XXX（软件需求编号）-SDS-XXX（软件设计编号）-UT-XXX（单元测试用例编号）- INT-XXX（集成测试用例编号）-SYS-XXX（系统测试用例编号）- HAZ-ID（软件危害/风险控制项ID），这个也建议列个追溯表格矩阵，第一行列名这些追溯项，列出每条软件需求与这些追溯项的对应关系。
（注意：追溯项关系不是一对一的关系，可能是一对多或多对一的关系。）
附上法规原文：
This can be accomplished by tracing the identified hazard to the verified specific risk control measures (e.g., a requirement ID in the SRS and SDS, a test name and identifier in the testing documentation that shows pass/fail results, a user manual name and identifier, a training manual name and identifier). For example, given an identified hazard (e.g., HAZ-XXX47), the following could be listed for traceability: a design related risk control measure that is documented in a software requirement specification (e.g., SRS-XXX) and software design specification (e.g., SDS-XXX), and tested as part of a unit test case (e.g., UT-XXX), integration test case (e.g., INT-XXX) and system test case (e.g., SYS-XXX). FDA recognizes that there may be instances where a specific hazard traces to several requirements/specifications and tests, thereby making the presentation of information cumbersome in the risk assessment document. Therefore, sponsors may choose to present this traceability in a separate document linking together software requirements specifications, software design specifications, testing and identified hazards derived from the risk assessment.
翻译参考：这可以通过将已识别的危险追溯到经过验证的具体风险控制措施来实现（例如：SRS 和 SDS 中的要求 ID、显示通过/未通过结果的测试文档中的测试名称和标识符、用户手册的名称和标识符、培训手册的名称和标识符）。例如，针对已识别的危害（如 HAZ-XXX47），可列出以下可追溯性信息：记录在软件需求规范（例如 SRS-XXX）和软件设计规范（例如 SDS-XXX）中记录，并作为单元测试用例（例如 UT-XXX）、集成测试用例（例如 INT-XXX）和系统测试用例（例如 SYS-XXX）的一部分进行测试。FDA 认识到，在某些情况下，特定危害可能追溯到多个需求/规范和测试，从而导致风险评估文件中的信息呈现较为繁琐。因此，申办方可选择在单独的文件中呈现这种可追溯性，将软件需求规范、软件设计规范、测试以及从风险评估中识别出的危害相互关联起来。