医疗器械注册证软件描述文档（医疗器械软件描述文档编制要点）

医疗器械注册证软件描述文档，医疗器械软件描述文档编制要点的分享，本文来给你说说。

医疗器械注册证软件描述文档

1.基本信息

1.1.产品标识 软件名称： 软件型号： 软件版本号： 软件制造商： 软件生产地址:
1.2.安全性级别
软件的安全性级别为A/B/C级。理由如下：
a） 软件的预期用途为：
b） 软件的功能包括：
c） 如果软件失效，可能导致以下后果（按软件各功能失效逐条描述，如果软件失效的时候由硬件降 低失效后果或危害发生概率，可以做说明，并由此降低安全性级别）：
1）……
2） ……
3） ……
1.3.结构功能 1.3.1.组成模块、各模块功能及模块相互关系
依据软件设计规格给出体系结构图（如图1.3T所示）。 嵌入式软件（SDS）体系结构图一一示例1
独立式软件（SDS）体系结构图一一示例2

结构图（SC）举例
医院管理系统

1. 4. 2.连接关系描述
与PC连接
与医疗器械硬件连接
1.5.运行环境
1.5.1.硬件配置
处理器： 储存器
外设器件 输入/输出设备
1.5. 2.软件环境
系统软件:
支持软件:
必备软件:
选配软件:
杀毒软件:

3核心算法概述

算法类型：
公认成熟算法：公开文献专利标准、原理简单明确、上市超过四年且无不良事件。公认成熟算法列明 名称、原理、用途，全新算法列明名称、原理、用途，并提供验证资料。
全新算法：源自科学研究和临床数据
内容：
实质**注册：所有核心算法 实质重新注册：新增核心算法

附件1

XXX风险管理报告

附件2

XXX需求规格说明书(SRS)
I.引言
1.1编写目的
为了明确“XXXXX”项目的需求，为用户和分析设计人员之间的交流提供方便，**地安排项目规划与 进度，组织软件开发与测试，减少项目风险，撰写本需求规格规格说明书。
本需求规格说明书的读者为项目经理、分析设计人员、程序员、质量保证人员、维护人员以及客户方 的相关人员。
1.2项目背景
1.3定义
GB/T 11457所列术语和下列定义适用于本指南。
合同：指XXXX共同签署的关于本项目的合同。
客户：指XXXX公司。
语言：是指具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。
编程语言：是指用于编写源程序的**语言和汇编语言。
用户：XXXXXX
1.4参考资料
a) GB/T 11457软件工程术语
b) GB 8566计算机软件开发规范
c) GB 8567计算机软件产品开发文件编制指南
d) GB/T 12504计算机软件质量保证计划规范
e) GB/T 12505计算机软件配置管理计划规范
f) GB/T 19001质量管理体系
g) IS09001质量管理体系
h) IS09000-3质量管理体系
i) 1S0/1EC 12207软件生命周期过程标准
j) ISO/IEC TR 15504软件过程评估标准
k) IEEE1058. 1软件项目管理计划标准
l) CMM 2.0能力成熟度模型
m) PMBOK项目管理知识体系
n) 项目计划任务书
O) 项目开发计划
P) 设备用户手册

2. 总体描述 2. 1日标

2.1.1开发意图、应用目标
a） 开发意图：
XXXX_O
b） 应用目标：
XXXX
2.1.2产品描述
（描述产品的基本要求、主要部分、外部接口等可使用框图展示较大系统的主要部分、相互关系、
外部接口等））
2. 1. 2. 1 软件系统总体结构图
采用基于采用MVC模式架构的开发方式，实现的系统具有界面美观、操作简单、开发系统容易升级、
系统开发周期短、成本低等优点。在项目的研发中，从体系结构上将本系统设计为4层结构：
系统结构图
（结构图说明）
2. 1. 2. 2 软件系统总体数据流图（图示及说明）
2. 1. 2.3 系统功能的总体用况图（图示及说明）
2. 1.2.4 约束：
a） 系统接口；
（列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。）
b） 用户界而；
（如要求的屏幕显示格式、页面、版式、报告内容、菜单内容等）
c） 硬件接口；
（如支持的设备，采用的协议等）
d） 软件接口；
（与其他软件的接口，软件应提供名称、助记符、规格说明编号、版本号、来源，接口软件的目的
等）
e） 通信接口：
（如局域网协议等）
f） 内存约束；
（对主存、辅存的任何使用特征和限制）
g） 运行；
（如用户引发的操作、交互操作的周期、无人值守操作的周期、数据处理支持能力、备份和回复操
作）
h）现场适应性需求
（给定现场、任务和运行模式的需求）
2. 2产品功能
描述软件的将执行主要功能的概要。（可用文本或图示的方法，显示不同功能及其之间的关系，显示 变量之间的逻辑关系）
2.3用户的特点
a） 管理员：。
b） 用户1：
c） 用户2：
2. 4约束条件
经费限制：
时间限制：
硬件局限：
方法、技术、环境：
法规：
标准：
并行操作：
审核功能：
3. 具体需求
3.1外部接口
各接口描述包括以下内容：
a） 项的名称；
b） 目的描述；
c） 输入源和输出目的地；
d） 有效范围、准确度和容限;
e） 测量单位：
f） 定时；
g） 与其他输入/输出的关系；
h） 屏显格式：
i） 窗口格式；
j） 数据格式；
k） 命令格式：
l） 结束消息。

3. 1. 1. 1 用户接口

3. 1. 1.2 硬件接口
3. 1.1.3 软件接口
3. 1.1.4 通信接口
3.2功能需求
3. 2.1用户注册功能
系统应能完成用户注册功能
> 主参加者：用户
>环境目标：
>前置条件：数据库有足够的空间。
> 触发器：用户进入注册界面。
>场景：
a) 用户进入注册界面。
b) 用户输入会员名。
c) 用户输入登录密码。
d) 用户输入确认密码。
e) 用户输入其他个人基本信息。
f) 用户输入验证码。
g) 点击确认按钮，提交注册信息。
> 异常：
a) 用户注册的会员名己在系统中存在时，给出提示信息，让其更改所输入的会员名。
b) 用户输入的确认密码与登录密码不一致时，给出提示信息，让其重新输入密码。
c) 用户输入的验证码错误时，给出提示信息，随机更换验证码的图片后，让其重新输入验证码。
> 优先级：必须被实现。
> 何时可用：**开发。
> 使用频率：每天多次。
> 后置条件：用户完成操作后显示注册成功信息。
> 活动图
3.2.2
3. 3性能需求
3.3.2支持同时运行的用户数量;
3. 3.3要处理的信息量和类型：
3. 3.4精度
3. 3.5速度：
3. 3.6人身和环境安全性需求
3. 4数据库逻辑需求
（规定将置于数据库的任何信息的逻辑需求，可包括：）
a） 不同功能使用的信息类型；
b） 使用频度；
c） 访问能力；
d） 数据实体及其之间的关系；
e） 完整性约束；
f） 数据保存要求
3. 5设计约束
（描述由可能由其他标准、硬件局限等引发的设计约束）
3. 6软件系统属性
3.6.1可靠性
3.6.2可用性
3. 6.3保密性需求
a） 对注册过的用户个人信息的严格保密，除用户自己以及管理员之外，其他人不能査阅用户信息。
b） 对数据传输过程需有严格的保密机制，防止用户数据的泄露。
O 对于管理员要分发给管理数据库的权限。
3.6.4可维护性
3. 6.5可移植性

附件3

XXX软件开发计划（SDP）摘要
1. 引言
本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行 和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出 其他有关的文档。
2, 实施整个软件开发活动的计划
2.1软件开发过程
本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定己计划的开发阶段（适 用的话）、目标和各阶段要执行的软件开发活动。
2. 2软件开发总体计划
2. 2.1软件生存周期
描述预期采用的生存周期模型，并进行说明
2. 2.2软件开发方法
本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描 述。该方法应覆盖论及它的所有合同条款。
2. 2.3可重用的软件产品
本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围利进行评估的 准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对已选定的或候选的可重用的软件产品 应加以标识和说明，（若适用）同时应给出与使用有关的优点、缺陷和限制。
2. 2.4处理关键性需求
本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款。
3. 进度表和活动网络图
本章应给出：
a. 进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和***终结果的可用性、 其他的果程碑及每个活动的完成点：
b. 活动网络图，描述项冃活动之间的顺序关系和依赖关系，标出完成项目中有***严格时间限制的活动。
4. 项目组织和资源
本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个 机构的权限和职责。
4.2项目资源
本条应描述适用于本项目的资源。（若适用）应包括：
a. 人力资源，包括：
1） 估计此项目应投入的人力（人员/时间数）；
2） 按职责（如：管理，软件工程，软件测试，软件配置管理，软件产品评估，软件质量保证和软 件文档编制等）分解所投入的入力：
3） 履行每个职责人员的技术级别、地理位置和涉密程度的划分；
b. 开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的 设施的其他特性：
c. 为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述 各项的进度表；
d. 其他所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性。

XXX软件配置管理计划（SCMP）摘要

I. 软件配置管理活动
本章描述配置标识、配置控制，配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活 动的需求。
1.1配置标识 1.1.1本条必须详细说明软件项目的基线（即***初批准的配置标识）
在软件生存周期中，主要有三种基线，它们是功能基线、分配基线和产品基线。对于每个基线，必须 描述下列内容：
a. 每个基线的项（包括应交付的文档和程序）；
b. 与每个基线有关的评审与批准事项以及验收标准；
c. 在建立基线的过程中用户和开发者参与情况。
例如，在产品基线中，要定义的元素可以包括：
a. 产品的名字和命名规则：
b. 产品标识编号；
c. 对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的 修改要求以及对有关文档的修改要求；
d. 安装说明；
e. 己知的缺陷和故障；
f. 软件媒体和媒体标识。
1.1.2本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程
例如，对代码来说：
a. 编译日期可以作为每个交付模块标识的一部分；
b. 在构造模块源代码的顺序行号时，应使它适合于模块作进一步的修改。
1.2配置控制
1.2. 1本条必须描述软件生存周期中各个阶段使用的修改批准权限的级别
1. 2. 2本条必须定义对己有配置的修改申请进行处理的方法
其中包括：
a. 详细说明在本计划第3.2条描述的软件生存周期各个阶段中提出修改申请的程序（可以用注上自 然语言的流程图来表达）；
b. 描述实现己批准的修改申请（包括源代码、目标代码和文档的修改）的方法；
c. 描述软件库控制的规程，其中包括库存软件控制、对于适用基线的读写保护、成员保护、成员 标识、档案维护、修改历史以及故障恢复等七项规程；

d. 如果有必要修补目标代码，则要描述其标识和控制的方法。

2. 工具、技术和方法
木章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并 在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具，技术和方法：
a. 软件媒体和媒体文档的标识。
b. 把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件 库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系 统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。
c. 编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项 目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术方法。

1. 维护范围

a） 改正性维护
b） 适应性维护
c） 完善性维护
d） 预防性维护
2. 维护工作流程

XXX软件生存周期实施情况核査表（YY/T 0708）

1. 目的
2. 引用文件
3. 术语和定义
4. V&V综述
4. 1组织
4. 2主进度
4.3资源摘要
4.4职责
4.5工具、技术和方法
5. V&V过程
5.1活动：概念V&V
(标识要执行的V&V的任务，描述每个V&V任务要求的输入、输出、进度、进度、资源等)
5.2活动：需求V&V
5.3活动：设计V&V
5.4活动：实现V&V
5.5活动：测试V&V
5.6活动：安装和检验V&V
5.7活动：运行V&V 6. V&V报告
XXX软件测试文档
XXXX测试计划
1测试计划标识符
AP05-0103
2引言
2.1目标
公司XX系统的系统测试计划应该支持以下目标：
(1) 细化准备和进行系统测试所需要的活动。
(2) 与所有负责方沟通有关他们要执行的任务以及执行任务时所安排的进度。
(3) 确定用来准备计划的信息源。
(4) 确定进行系统测试所需要的测试工具和环境。
2.2背景
去年，XYZ公司系统和程序开发部门应公司会计部门的要求开发了一个新的通用总帐系统。与此同时， 还提出要求要开发一个与该通用总帐系统接口的新的公司工资系统。
管理层系统评估委员会在19**年9月批准了开发匸资系统的请求，并且指定一个匸资系统顾问组来确 定系统需求。顾问组于19**年12月完成了一份需求陈述(AP01-01)和一份初步开发计划。
2.3范围
该测试计划覆盖了公司工资系统的全部系统测试，包括操作者和用户规程、以及程序和作业控制。除 了综合性多程序功能性测试外，还应评估外部接口、安全、恢复和性能。
2.4引用文件
下列文档用作该测试计划的信息源：
公司工资系统初步开发计划(AP01-02)
公司工资系统授权(AP01-03)
公司工资系统***终开发计划(AP01-06)
公司工资系统质量保证计划(AP01-08)
公司工资系统配置管理计划(AP01-09)
XYZ公司系统开发标准及规程(XYZ01-0100)
公司通用总帐系统设计描述(AG01-04)
公司通用总帐系统测试计划(AG05-01)
3测试项
组成公司工资系统的所有项在系统测试期间应予测试。待测试的版本应由配置管理员放在合适的库中。

管理员还应控制对受试版本的更改，并且将可提供新版木的时间通知测试组。 以下文档为规定正确的操作建立基础：

公司工资系统需求规格说明(AP01-01)
公司工资系统设计描述(AP01-04)
公司工资系统参考手册(AP02-01)
公司工资系统模块参考手册(AP02-03)
GB/T 9386-2008
要测试的各项列出如下：
3.1程序模块
要测试的程序模块按以下规则来标识：
类型 库 成员名称
源代码 SOURLIB1 AP0302
AP0305
可执行代码 MACLIBI AP0301
AP0302
3.2作业控制规程

3.3用户规程

公司工资系统用户事务参考手册(AP02-04)中规定的在线规程应予测试。
3.4操作者规程
系统测试包括公司工资系统操作参考手册(AP02-02)中规定的规程。
4要测试的特征
以下清单列出待测试的特征：
测试设计
说明编号 描述
AP06-01 数据库转换
AP06-02 月薪雇员全面的工资处理
AP06-03 计时雇员全面的工资处理
AP06-04 所有雇员全面的工资处理
AP06-05 定期报告
AP06-06 通用总帐事务的建立

安全 恢复

AP06-09 性能
5不要测试的特征
下列特征不应包括在系统测试中，因为它们在系统初始安装时不会使用。
平等就业机会委员会符合性报告
内部培训进度报告
工资/业绩审查报告
二期开发阶段文档集应包含关于这些特征的一个测试计划。
测试用例将不会覆盖正在受试的事务或者报告中所有可能的选项组合。只有目前XYZ公司工资处理明确 需求的组合应予测试。
6方法
测试人员应根据系统文档集准备所有的测试设计、用例以及规程说明。这种方法应验证测试所覆盖那些 领域的文档集信息的准确性和综合性。
公司工资和会计部门的人员应协助开发测试设计和测试用例，这样做有助于确保测试能体现系统的实际 使用。
为了确保保密性，从会计文件中选取的所有测试数据应含有己更改的保密敏感字段。
6.1转换测试
除了计算输入和输出的记录外，转换数据库的有效性应以两种方式进行验证。第一种验证方法涉及到 使用必须由开发组建立的“数据库审核员”功能。当针对被转换数据库运行时，数据库审核员应核对一条 记录内的数值范围，以及要求的各条记录之间的关系。
第二种验证方法涉及到随机选取旧记录的一个小的子集，然后直接与新记录的相对应子集进行比较。 直接比较的数目“c”和旧记录的数目“r”必须加以规定。从1到r的范围内产生由随机数字组成的c集 合。在转换过程中，该集合应予以分类和应用，以驱动对宣接比较记录的选择。
注：同样的两种验证方法在实际的转换期间应予采用。
6.2作业流测试
月薪雇员和计时雇员的记录综合集以及这两种记录的合并集应用于测试工资处理。标准的作业流测试 方法应予采用。
每种定期报告作业流至少运行一次。
6.3接口测试
为了测试工资系统与通用总帐系统之间的接口，工资系统应建立一个通用总帐事务综合集。这些事务 应输入到通用总帐测试系统。生成的通用总帐条目必须加以选取、打印并与由工资系统准备的通用总帐事 务的打印输岀相比较。

无妥当口令但又试图访问在线数据条目并显示事务的情况应予测试。

6.5恢复测试
在可单独运行的时间内，通过停机且随后依照恢复规程进行恢复测试。
6.6性能测试
依据性能要求(AP01-01).通过利用产生的数据量测量若干作业的运行时间，以此来评估性能。
6.7回归测试
假设为了测试在系统测试期间做过的程序修改，则应对系统进行若干次重复测试。对系统的每一新版 本应做一次回归测试，从而检测由于程序修改所导致的意想不到的影响。
应通过对新版本执行前一版本曾执行的那些所有测试来完成回归测试，然后对由此得到的结果文件进 行比较。标准的比较器程序(UT08-0100)应予釆用，以便比较所有的系统输出。
6.8综合性
公司工资系统参考手册(AP02-01)中描述的每个系统特征至少应有一份相关联的测试设计说明。公司工 资系统用户事务参考手册(AP02-04)中所规定的每个用户规程至少应予测试一次。公司工资系统操作手册 (AP02-02)中规定的每个操作规程至少也应予测试一次。另外，每个作业控制规程至少应予执行一次。
对于关联到上述每个领域的测试设计说明，应采用覆盖矩阵予以核査。
6.9约束
公司工资系统的***终执行日期定于19**年8月31号。必须符合这个日期，因为新的ABC部门将于9 月1日开始全面运行，必须拥有这个系统方能向其雇员发放工资。
7测试项通过准则
该系统必须符合XYZ公司系统开发标准和规程(XYZ01-0100)中陈述的系统通过/失败的标准需求。该系统还 必须满足下列需求：
——内存需求一定不要大于真实存储量64ko
——用户规程与其他会计系统的一致性必须使工资主管满意。
8暂停准则和恢复要求
8.1暂停准则
不能转换雇员信息数据库会导致所有测试活动的暂停。
8.2恢复要求
出现测试暂停后，当系统的新版本向测试组传递时，6.7条中描述的回归测试应予执行。
9测试交付项
(1)系统测试组应形成下列文档，这些文档在测试结束后交付给配置管理组。
测试文档

系统测试计划；

系统测试设计说明；
系统测试用例说明；
系统测试规程说明；
系统测试日志；
系统测试事件报告日志；
系统测试事件报告；
系统测试总结报告。
测试数据：
所有数据录入、査询屏幕和回答屏幕的拷贝都应附在相关的测试用例文档中。
(2) 输入和输出测试文件的拷贝应交付给配置管理组。
(3) ***终执行每个测试规程的打印输出的缩微胶片拷贝，应与测试文档集一起交付给配置管理组。
10测试任务
见附件A的任务列表。
11环境要求
11.1硬件
测试应在XYZ公司的硬件配置下进行。
鉴于大多数测试必须在主要的操作时间内开展，在此期间内应向测试组提供3个在线终端。
11-2软件
11.2.1操作系统
该业务操作系统应用于执行这些测试。
11.2.2通信软件
所有在线程序应在测试通信软件的控制下加以测试。
11.3安全性
安全性应限于现有的各种控制器。
11.4工具
开发和评估系统测试需要下列测试工具：
(1) 测试数据生成器(UT09-0200)c该程序用于生成绝大多数的测试数据。它位于标准系统库SYSLIBAo
(2) 比较器程序(UT08-0100)。该程序用于在冋归测试期间比较系统结果。它位于标准系统库SYSLIBA 中。
(3) 数据库审核器。该程序用于审核数据库中的数值范围及记录之间的相互关系。它须由开发组提供。

需要下列文档支持系统测试：

XXX测试报告
1. 引言
1.1标识
1.2系统概述
1.3文档概述
2. 引用文件
3. 测试结果概述
3. 1对被测试软件的总体评估
3.3改进建议
4. 详细的测试结果
4. 1 XXX项目
4.1.1测试结果小结
4. 1.2遇到的问题
4. 1.2. 1 测试用例的项目唯一性标识符
4. 1.2.2 （逐个标识……）
4. 1.3与测试用例/测试过程的偏差
4.1.3. 1 测试用例的项目唯一性标识符
4. 1.3.2 （逐个标识……）
5. 测试记录

日期时间	地点	硬件配置	软件配置	测试活动	测试结果	测试人

 

 6.评价
6. 1能力
6.2缺陷和限制
6.3建议
6.4结论

医疗器械软件描述文档编制要点

1.基本信息

这部分是软件基本开发过程简述，在实际的软件开发过程中是在需求分析阶段结束后输出的内容，其要点有以下两个。

1.1安全性级别判定

《指导原则》中较大篇幅阐述判定要求，但未明确指定可操作的判定规则，建议采用YY/T0664[2]的4.3和附录B4.3条款是较好的判定方法，根据严重度与发生概率结合判定，即安全性级别=损害严重程度×发生概率，因软件失效概率目前无定论，若从临床风险角度考量，假定失效概率为**。在***新版的《医疗器械分类目录》[3]中医用软件***低类别为Ⅱ类，是具备中度风险的医疗器械，其***低安全性级别=**×中度风险，故软件***低安全性级别不应低于B级，重大疾病诊断治疗或手术导航类软件安全性级别为**高度风险，其安全性级别应为C级，在明确判定安全性级别后，应依据《指导原则》中表1提供相应文档，不同安全性级别要求的文档数量和复杂程度不同，应据实提供不可避繁就简而造成审评中较多资料发补。

1.2结构功能与硬件拓扑图

结构功能与硬件拓扑图，体系结构图是指软件各组成模块间如临床功能模块和非临床功能模块间的关系示图，用户界面关系图如登陆与数据处理或诊断界面关系示图，物理拓扑图则如软件的模块，软件的计算机与器械硬件或服务器和云端间的关系示图，《指导原则》要求应依据软件设计规范（SDS）提供，较好的方法是参考《医学图像存储传输软件注册技术审查指导原则》[4]中第二章（三）的示例绘制基本示意图，再结合申报产品的实际情况进行修订。

2.实现过程

该部分要求对软件开发过程的基本情况进行简述，实质是要求建立符合YY/T0664的开发流程，共有四个要点[2]。

2.1需求规范（SRS）

软件功能的设计和用户需求的实现均是从需求规范（SRS）开始，SRS一般包括产品描述、产品功能要求、用户特点、设计约束、需求分配等内容，应按GB/T9385[5]编制，对软件的功能如处理或诊断功能的要求应在SRS中明确，软件的约束条件如运行环境限制、不同用户控制权限的要求也应明确，SRS内容应与软件设计规范（SDS）的内容保持对应。

2.2生存周期

生存周期是指软件从需求到开发、交付、使用、升级维护全生命周期的过程，可提交依据YY/T0664附录D中表D.1过程标准核查表替代相应描述，或提交软件的维护计划及配置管理的体系文件，安全性级别为C级的软件要求提供的的设计历史文档集索引表（DHF），可提交从立项到集成测试的全过程文档目录，同时应确保目录中的文件在质量体系文件中可溯源，以备注册体系核查。

2.3验证与确认

验证与确认是对软件功能问题发现识别过程，软件的验证如黑盒与白盒测试，白盒测试一般指各类软件源代码的检查活动，黑盒测试一般指单元/集成/系统等各阶段的测试活动，可提供各种验证的记录文件，软件中确认通是指在真实或模拟的使用环境中的用户测试，可提交用户测试记录或临床评价报告证实符合此要求。

2.4可追溯性分析

是追溯软件从需求到实现整个过程间的对应关系，主要是对安全性级别为C的软件的要求，可追溯性分析一般是追踪需求规范、设计规范、源代码、测试、风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性，如需求规范（SRS）中的功能需求应与设计规范(SDS)中列明的功能、设计规范(SDS)中列明功能与软件中实现该功能的源代码应是可一一对应的，需求规范（SRS）中的设计约束与风险管理报告中的控制措施也应是可一一对应，可追溯性分析应输出可明确查看和判定对应关系的列表式记录或报告。

3.核心算法

软件本身是算法+实现的结合，一个软件常含多种功能，每个功能可能会涉及一种或多种算法，核心算法是指软件在预期使用环境中完成其预期用途的必需算法，如医学影像类软件中的成像算法，放射治疗计划中的放射计划的时间算法，治疗类软件的治疗模式匹配算法都属于核心算法，但类似搜索患者姓名的检索算法或病例数据排序算法则不属核心算法。核心算法若是成熟算法应提供相应的文献证实其公开性，而全新算法如近年兴起的人工智能算法，是基于海量数据和高算力可不断自我学习并优化提升的黑盒算法，其存在一定程度的不可控因素，一般需通过临床试验来证实其安全有效性，需提供基于临床试验结果的支持性资料。

本文关于医疗器械注册证软件描述文档，医疗器械软件描述文档编制要点的分享就到这里，如果有什么不懂的，可以联系我们！