这篇只解决一个问题
怎样写出能经得起注册追问的软件设计开发文档。
有研发同事问过我：“给我一套软件DHF模板，我是不是照着填就行？”
真正开始写后，才会发现最难的从来不是打开文档，而是：需求怎样才算写清楚？风险控制怎么写进需求和测试？架构和详细设计该写多深？版本改了三次，怎样保证资料还是同一个产品？
这篇不发模板包，也不堆术语。我们用一套能真正落地的写作顺序，讲清医疗器械软件设计开发文档该怎么写，以及最容易翻车的难点在哪里。
01
PART
先定写作逻辑，不要反过来
WRITE IN THE RIGHT ORDER
先记住一句话：软件DHF的写作目标，不是把文件写“全”，而是让软件设计开发过程有证据、能追溯、经得起追问。
对中国境内申报的产品，软件研究资料通常需要结合《医疗器械软件注册审查指导原则（2022年修订版）》组织；涉及联网、电子数据交换、远程访问等功能时，还要结合网络安全相关要求。法规与指导原则是写作边界，但本文的重点，是教你把文档真正写出来。
计划
先定规则与交付
输入
把需求写清楚
输出
把设计写明白
验证
用测试来证明
发布
用版本来锁定
项目走到哪，证据就记录到哪。
最稳的写作顺序是：计划 → 输入 → 输出 → 验证与确认 → 发布与维护 → 可追溯。顺序不要反过来。
难点 1
先写需求，后补计划
没有计划书，角色、评审点、版本规则和交付文件都容易各自理解。先把项目的共同规则写下来，后面每一份文件才知道该往哪里靠。
02
PART
计划书怎么写？先给项目定规则
SOFTWARE DEVELOPMENT PLAN
软件设计开发计划书相当于项目的“总导演”。它不是写给审评老师看的仪式感文件，而是提前规定项目怎么运转。
计划书至少写清八件事
软件名称、预期用途、产品边界和适用版本。
软件安全性级别及判定依据。
开发模型，例如瀑布、V模型或迭代开发。
产品、研发、测试、质量、注册等角色职责。
生命周期阶段、里程碑、设计评审点和交付物。
配置管理、问题解决、风险管理和网络安全活动。
变更评估、版本发布与维护规则。
各阶段输出文件清单及归档要求。
难点 2
计划写得漂亮，后面没人照着执行
计划里写了需求评审、设计评审和测试评审，后面却找不到记录；计划里写了配置管理，实际只有“最终版”“最终版2”。正确做法不是把计划写复杂，而是只写团队能够真正执行、也愿意留下证据的过程。
03
PART
需求规范怎么写？可验证才算数
SOFTWARE REQUIREMENTS
软件需求规范是整个DHF的地基。后续的架构、详细设计、测试用例和追溯矩阵，几乎都要回到它。
一条需求，至少要满足四个条件
唯一编号
能被明确引用
可验证条件
知道何时测试
判定结果
知道通过与否
需求不是愿望，需求必须可以被客观验证。
不要写：“系统应快速响应用户操作。” 这不是可验证需求。
建议写：SRS-F-023：在规定运行环境下，用户点击“确认”后，系统应在500毫秒内完成页面状态更新；超出该时间应记录异常日志。
需求通常要覆盖哪些方面
功能需求：软件要做什么。
性能需求：响应时间、精度、容量、并发等。
接口与运行环境需求：设备、系统、数据库、中间件、网络条件。
用户界面、可用性、异常处理与用户差错防御。
数据、权限、日志、审计追踪与网络安全要求。
来自风险管理的风险控制需求。
难点 3
风险控制没有写进需求
风险表里写“防止非授权用户修改治疗参数”，若需求、设计和测试中找不到对应项，它只是一句口号。正确链条是：风险项 → 权限与审计需求 → 设计模块 → 测试用例 → 追溯矩阵。
04
PART
架构与详细设计，写到什么程度？
ARCHITECTURE AND DESIGN
很多团队在架构和详细设计这里最纠结：写少了怕不够，写多了怕浪费时间。一个简单判断方法是：让没有参与编码的人，也能看懂软件由什么构成、关键功能在哪里、数据怎么流、风险控制怎么实现。
架构设计：写“整体怎么搭”
软件系统边界、模块划分及各模块职责。
模块间接口、输入输出、通信方式与关键数据流。
与硬件、外部系统、云服务的关系。
第三方软件、开源组件与外部运行环境。
关键风险控制在架构中的位置。
详细设计：写“关键功能怎么实现”
详细设计不等于把源代码贴进Word。它应重点描述关键模块的处理逻辑、算法规则、数据结构、异常处理、边界条件、接口字段，以及支撑独立测试的必要细节。
难点 4
架构图很好看，却不是当前版本
模块、接口、第三方库变了，图却停在立项阶段。每次影响结构、接口、运行环境或风险控制的变更，都要评估是否更新设计文件，并纳入版本基线。设计文档不怕改，怕的是产品变了，DHF还停在旧世界。
05
PART
测试文件怎么写？证明什么？
VERIFICATION AND VALIDATION
软件测试不是“打开软件点一遍”。测试文件的任务，是证明需求被实现，尤其是风险控制措施在正常、异常和边界情况下仍然有效。
常见测试文件怎么分工
集成测试：验证模块或接口之间是否正确协同。
系统测试：验证完整软件在目标运行环境中是否满足需求。
用户测试：验证实际使用流程和用户需求是否得到满足。
缺陷报告与回归测试：证明发现的问题被受控处理。
性能、运行环境、互操作性、网络安全测试：按产品特性提供证据。
一条测试用例，建议写清六件事
测试对象和关联需求编号。
测试环境、软件版本和前置条件。
测试步骤。
预期结果。
实际结果。
结论、问题单号与回归证据。
难点 5
测试通过了，却没有证明风险控制
“登录成功”只能证明账号密码可以登录。若该功能承担权限控制风险，还应覆盖错误密码、锁定策略、不同角色权限、未授权访问、权限变更后的生效情况和操作日志。测试要回答的不是“页面有没有反应”，而是“它究竟证明了哪项需求和风险控制”。
06
PART
追溯与版本：最容易在注册前崩掉
TRACEABILITY AND VERSION
如果只能选一个文件来判断DHF是否扎实，我会选软件可追溯矩阵。它不是一张为了交差而做的大Excel，而是项目的导航图。
一条完整的追溯路径
用户需求／风险项 → 软件需求 → 设计模块 → 测试用例 → 测试结果 → 缺陷与版本
它最大的价值，是在任何一个节点变化时，快速找到受影响的文档、代码和测试。
难点 6
项目结束才开始补追溯表
后期补追溯最常见的结局是：需求编号对不上，测试用例忘了来源，旧缺陷不知道影响哪个版本。正确做法是：需求编号一确定，就先建矩阵骨架；每新增需求、设计、测试或变更，就实时补一格。
版本一致性，请重点核对这六项
待申报的软件发布版本。
软件完整版本和版本命名规则。
需求规范版本。
架构与详细设计版本。
测试记录与测试报告对应的版本。
发布说明、缺陷清单、剩余风险评价和配置基线。
它们不一定必须版本号完全相同，但必须能够解释清楚彼此的对应关系。
难点 7
代码改了，文档和测试没跟上
软件变更很正常，最怕的是只更新代码。每次变更都要做影响评估：它影响需求吗？影响风险吗？影响设计吗？需要补哪些测试？哪些文件和版本记录要同步更新？
07
PART
DHF可以委托写吗？
PROFESSIONAL SUPPORT
可以委托专业团队协助写软件设计开发文档，特别适合项目资料分散、团队缺少医疗器械软件文档经验、海外资料需要本地化，或申报在即需要快速完成差距评估与一致性核查的情况。
但边界必须说清：专业团队可以帮助梳理事实、搭建框架、访谈研发人员、完成文档编写与一致性核查；不能凭空替代真实研发、真实测试和技术决策。
Bestec可协助的工作
搭建软件DHF文件框架、交付清单、编号规则和项目计划。
编写软件设计开发计划、软件需求规范、架构设计、详细设计和测试相关文件。
梳理风险控制与需求、设计、测试之间的追溯关系。
完善配置管理、缺陷管理、版本发布、维护与变更记录。
组织网络安全需求、风险、测试、漏洞评估和维护资料。
梳理软件描述文档、自研软件研究报告等注册资料，并做申报前一致性核查。
对已有DHF做差距评估，给出补齐路径。
你提供真实的产品资料、研发过程、版本信息与测试证据；我们把散落的研发活动沉淀成一套结构清楚、可追溯、能经得起追问的软件设计开发文档体系。。
///
LAST
写在最后
ONE QUESTION TO CHECK
写软件DHF，请始终问自己这一句：
“这份文档，能否回答为什么这样做、怎么做、怎么证明、现在是哪一个版本？”
如果能，DHF就不是负担，而是你们软件研发质量最有力的证据。
参考依据： 《医疗器械软件注册审查指导原则（2022年修订版）》《医疗器械网络安全注册审查指导原则（2022年修订版）》，以及《软件DHF设计开发历史文档集》中的交付清单、追溯表和总部文件清单。
如果这篇帮你理清了软件DHF，欢迎点赞、在看、转发给正在写文档的同事。
我是医械加油站，专注医疗器械注册备案、质量体系、产品研发和合规落地。