ARTICLE · 1313031

医疗器械软件研发文档要写什么?怎么自查?

发布时间：2026-11-05 10:56:49 最近访问：2026-11-05 10:56:49

大家好，我是mars。上一篇讲了软件升级和注册变更，今天接着聊软件研发文档：从开发到发布，需要准备哪些资料？

做医疗器械软件，先要了解YY/T 0664—2020《医疗器械软件软件生存周期过程》。它为软件开发和维护提供了过程框架，不只是要求写需求和测试报告，还涉及风险、配置、问题处理和维护等工作。

这个标准不仅适用于独立医疗器械软件，也适用于医疗器械中的嵌入式软件或其他软件组件。下面按照研发工作的几个阶段，讲讲常见文件和自查重点。

先弄清楚：标准管什么？

YY/T 0664—2020是推荐性行业标准，2021年9月1日起实施。企业应结合适用法规、产品标准、注册要求和自身选择，确定采用方式；不能简单说所有项目都必须照同一张文件清单执行。

实际工作中，可以把它理解成几条同时开展的线：软件开发与维护、风险管理、配置管理和问题解决。需求变了，风险、设计、测试和版本记录也要跟着评估，而不是只改一份需求文档。

软件安全级别的判断要看软件可能造成的伤害及相关风险，不能直接拿医疗器械注册分类代替。不同安全级别适用的活动和记录深度，应结合标准具体条款和项目情况确定。

先看一张图：开发和测试怎么对应？

常见的V型模型，左边从用户需求逐步细化到软件需求和设计，底部是编码实现，右边则通过单元、集成、系统测试及确认，检查相应工作是否达到要求。

软件开发V型模型示意：连线表示典型对应关系，具体测试覆盖和确认方式应按项目确定。

比如：一条软件需求要能找到系统测试的证据；模块之间的接口要考虑集成测试；预期用途和用户需求还要通过适宜的确认活动评价。测试工作不一定只在编码后才开始，方案和用例可以提前准备。

这张图只是帮助理解的模型，YY/T 0664并不要求所有企业必须使用V型模型。实际开发可以分阶段、迭代开展，但每次迭代都要留下相应记录并控制版本。

第一步：先把计划和风险定下来

项目开始时，先明确软件用途、开发范围、人员分工、阶段评审、测试安排和交付物。如果是设备里的软件组件，还要确定软件与硬件的接口，以及哪些活动需要结合整机开展。

常见资料包括设计开发计划、软件开发计划、风险管理计划、软件安全级别判断依据和阶段评审记录。网络安全相关活动是否单列，结合产品联网、接口和风险情况确定。

第二步：把需求写到能测试

软件需求应说明功能、性能、接口、数据处理、异常响应以及适用的安全和网络安全要求。每条需求尽量有唯一标识，写清条件、行为和判定标准，后面才好追溯。

例如，设备断开传感器后需要提示使用者，就要写清触发条件、提示方式和响应要求；涉及风险控制时，还要关联风险分析和相应控制措施。输入形成后，保留需求评审和批准记录。

第三步：设计和实现留下什么？

常见资料有软件架构设计、详细设计、接口设计、源代码及版本记录。架构文件要能说明模块如何划分、模块之间怎么通信，关键风险控制措施在哪里实现。

使用操作系统、开源组件或其他现成软件时，应识别名称、版本、用途，并结合产品评估相关风险。对于嵌入式软件，还要关注软硬件接口、联调和适用的整机记录。

第四步：测试资料要能追溯

测试前准备计划或方案、用例和接受准则；执行时记录测试对象、版本、环境、实际结果及异常；结束后形成报告，并对未通过项目和遗留问题作出处理。

单元测试关注软件单元，集成测试关注模块及接口，系统测试关注软件整体是否满足需求。具体层级、范围和方法要按架构、安全级别及风险确定，不能只看有没有一份“测试合格报告”。

确认关注产品能否满足规定的用户需求和预期用途；对软件组件，还要结合整机的验证确认安排。第三方检测报告可以作为相关证据，但不自动替代企业按计划开展的全部验证和确认。

第五步：发布后，维护和变更不能断

发布时，要能确认发布版本对应哪些代码、配置、测试结果和已知问题，并保留批准记录。适用时，还要准备安装部署、使用说明和维护资料。

发现缺陷或开展升级时，记录问题、影响分析、处理、必要的回归测试和发布情况。涉及网络功能的产品，还要按实际情况考虑漏洞、补丁和安全维护；软件变更也要评估是否涉及注册等监管要求。

最后说两句

整理资料时，先区分是记录分散、证据不足，还是工作没有开展。做过的工作要找到真实依据；没有做过的，要按计划补充，不能只补一份结论。

百思得也会协助企业梳理软件研发资料、检查追溯关系。具体的研发活动、数据和审核批准，仍然要由企业落实。

我是mars，你身边的研发顾问。下面这份清单整理了各阶段常见资料，大家可以对照自己的项目看看。

软件研发文档自查清单

下面按策划、输入、输出、验证和确认五个阶段，整理常见的软件研发文件。清单参考YY/T 0664—2020的软件生存周期工作，并结合设计开发、注册和生产管理中可能用到的资料，不是该标准规定的固定文件目录。

文件名称可以不同，内容也可以合并或交叉引用。网络安全、现成软件、生产和用户测试等项目，应结合产品特点、软件安全级别、适用法规标准和企业程序判断；不适用时建议记录依据。软件风险、配置、问题解决和维护应贯穿相关阶段，表格中的归类仅为方便查看。

文件或记录	自查重点
一、策划阶段
软件设计开发计划书	明确开发范围、阶段、职责、评审及交付物。
软件风险管理计划	明确风险管理活动、职责及相关安排。
软件安全级别判断记录	记录安全级别及其判断依据。
网络安全风险管理计划	适用时明确网络安全风险活动和职责。
设计开发阶段评审记录	记录评审参与人员、结论和问题处理。
二、输入阶段
软件需求规格	明确用途、功能、性能、接口、数据和异常处理。
用户与使用需求	明确使用者、使用环境和预期用途相关要求。
网络安全需求规格	适用时明确安全功能、接口和安全需求。
软件及网络安全风险分析	识别相关风险，并关联风险控制需求。
设计输入清单	识别适用输入文件、版本及其状态。
设计输入评审记录	确认输入完整、明确、可验证，并记录结论。
三、输出阶段
软件架构设计说明书	明确软件结构、模块、接口和风险控制位置。
软件详细设计说明书	记录关键模块、逻辑、接口和异常处理。
源代码及编码规范	保存适用的编码规范、源代码和受控版本。
软件及软硬件接口资料	适用时明确接口、通信、联调和整机关系。
现成软件清单及评估	适用时记录组件名称、版本、用途和风险。
软件开发和测试设备与工具清单	记录工具、版本、环境及必要的适用性评估。
软件可追溯性分析记录	关联需求、设计、风险控制及测试证据。
网络安全可追溯性分析记录	适用时关联安全需求、风险控制和测试。
产品安全性特征及风险控制记录	结合产品记录安全性特征、风险和控制措施。
软件风险管理记录／报告	记录风险分析、控制措施及评价结果。
网络安全风险管理记录／报告	适用时记录网络安全风险分析与控制。
软件配置管理计划	明确配置项、版本、基线及配置控制方法。
配置管理报告及过程记录	记录配置识别、变更、状态及必要的核查。
软件缺陷与问题记录	记录问题、影响、处理、复测和未关闭事项。
软件变更记录	记录申请、影响分析、审批、实施和验证。
软件发布说明及批准记录	明确发布版本、已知问题及对应配置。
软件维护计划	明确维护职责、问题接收、分析和更新安排。
网络安全维护及补丁记录	适用时记录漏洞监测、补丁评估和更新。
产品技术要求及软件说明资料	结合产品核对适用的技术要求、使用说明。
成品检验规程与记录	适用时明确检验方法、判定和执行记录。
生产操作规程、流程图及物料清单	适用时明确生产、部署、配置和物料信息。
设计输出清单与评审记录	识别输出文件、版本、评审及批准状态。
四、验证阶段
软件验证计划／方案	明确对象、版本、环境、方法及接受准则。
软件单元测试方案	按适用要求明确单元测试对象和方法。
软件单元测试用例和记录	记录输入、预期结果、实际结果及异常。
软件单元测试报告	汇总单元测试结果、问题和结论。
软件集成测试方案	明确模块、接口及集成测试安排。
软件集成测试用例和记录	记录接口及集成测试执行情况。
软件集成测试报告	汇总集成测试结果、问题和结论。
软件系统测试方案	明确软件系统需求、环境及测试安排。
软件系统测试用例和记录	记录测试用例、实际结果及异常。
软件系统测试报告	汇总软件系统测试结果、问题和结论。
测试缺陷报告及分析	记录各阶段问题、处置、复测和未关闭情况。
网络安全测试方案与报告	适用时记录安全测试、结果和问题处理。
漏洞扫描或漏洞评估记录	适用时记录漏洞评估、分析及处理。
风险控制验证记录	确认控制措施已实施，并评价其有效性。
相关标准测试报告	适用时提供相关测试依据及报告，不默认所有产品均须开展某项特定标准测试。
验证报告及评审记录	汇总验证结果、偏差处理和评审结论。
五、确认阶段
设计确认计划／方案	明确确认目的、条件、方法及接受准则。
用户测试计划、用例和记录	适用时记录测试对象、场景、执行情况和结果。
用户测试报告	适用时汇总用户测试结果和问题处理。
整机联调及验证确认记录	适用时关联软件组件与整机的相关证据。
软件风险管理报告	结合项目确认风险控制和剩余风险评价记录。
设计确认报告及评审记录	汇总确认结果、未解决问题和评审结论。