医疗器械软件产品标准编写指南
Aaron · 2008-04-17 19:25 · 30301 次点击
一、编写医疗器械软件产品标准应遵照以下文件
1、《医疗器械标准管理办法》(国家食品药品监督管理局令第31号)
2、《医疗器械说明书、标签和包装标识管理规定》(国家食品药品监督管理局令第10号)
3、GB/T1.1-2000《标准化工作导则第一部分:标准的结构和编写规则》
4、GB/T17544-1998《信息技术软件包质量要求和测试》
5、《医疗器械注册产品标准编写规范》(国药监械407号)
6、相关的国家标准和行业标准。
二、标准正文的内容
标准正文的内容应包括:范围、规范性引用文件、分类、要求、试验方法、检验规则、标志、标签、使用说明书、包装、运输和储存。
1、范围
明确说明本标准规范的对象和所涉及的各个方面,指明适用的界限。
2、规范性引用文件
应包括引导语和规范性引用文件一览表。
2.1引导语
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
2.2规范性引用文件一览表
GB/T17544-1998信息技术软件包质量要求和测试
相关的国家标准
相关的行业标准
相关的国际标准
3、分类
3.1型号
3.2组成
3.3硬件配置要求
4、要求
4.1产品描述(详见附录A)
4.2用户文档(详见附录A)
4.3程序和数据(详见附录A)
4.4外观
5、试验方法
产品描述、用户文档、程序和任何要交付的数据都作为软件包的组成部分,对产品描述和用户文档的测试通过文档的检查测试来进行;对程序及数据的测试采取黑盒测试的方法来进行,且应按GB/T17544-1998《信息技术软件包质量要求和测试》第3章及附录A中的要求进行符合性测试。
5.1测试预要求
5.1.1产品项的现场要求
测试现场应包括产品所有要交付的内容和产品描述中已标识的需求文档。
5.1.2对系统组成部分的现场要求
测试现场应包括产品描述中已指明要求的所有计算机系统的组成部分。
5.2测试活动
5.2.1产品描述的测试
根据A.1(参见附录A)中每一个条款的内容要求,通过文档的检查方式验证产品描述的符合性。
5.2.2用户文档的测试
根据A.2(参见附录A)中每一个条款的内容要求,通过文档的检查方式验证用户文档的符合性。
5.3.3程序和数据的测试
根据A.3(参见附录A)中每一个条款的内容要求,采用黑盒测试技术,通过创建测试用例的方法对程序和数据进行测试。
5.3.4外观的测试
6、检验规则
应明确出厂检验及型式检验的时机、抽样方法、检验项目及判定规则。
其中出厂检验的检验项目至少应包括第四章要求中4.1产品描述及4.2用户文档的要求;型式检验应包括第四章要求的全部内容。
7、标志、标签、使用说明书
产品的标志、标签、使用说明书应满足如下文件的要求:
7.1GB/T17544-1998《信息技术软件包质量要求和测试》
7.1《医疗器械说明书、标签和包装标识管理规定》(国家食品药品监督管理局令第10号)
8、包装、运输、储存
应规定产品的包装要求、运输储存要求。
附录A:
质量要求
A.1产品描述
A.1.1内容的一般要求
a)产品描述宜是充分可理解的、完整的并且易于浏览,以帮助潜在的购买者在购买该产品前评价产品对他们自己的适用性。
b)产品描述应避免不一致,每个术语在任何地方都应有相同的意义。
c)产品描述的说明应是可测试的并且是正确的。
d)应包合或宜包含下列A.l.2到A.1.8的内容。
A.1.2标识和指示
a)产品描述的标识
产品描述应且有唯一的文档标识。它可以有不同于产品描述的命名,例如,“功能描述”、“产品信息”“产品清单”。
b)产品的标识
产品描述应标识产品。产品标识应至少有产品名字和版本号或日期。如果在产品描述中提及两个或多个派生版本,则每个版本应至少有产品名、派生版本名和版本号或日期。
c)供方
产品描述应至少包含一个供方的名字和地址。
注:名字和地址不必打印;有供方的公章即可。
d)工作任务
产品描述应标识期望的产品能完成工作任务。
e)符合需求文档
产品描述可以引用产品应符合的需求文档的内容,在这种情况下应标识相关的编辑版本。
f)要求的系统
应标识将产品投入使用所要求的系统(硬件、软件及其配置),包括制造厂商名和所有部件的类型标识符,例如;
——包括协处理器的处理单元;
——主存规格;
——外存的类型和规格;
——扩展卡;
——输入和输出设备;
——网络环境;
——系统软件和其他软件。
对于不同的工作任务、不同的边界值或不同的效率要求,可以规定不同的要求系统。
如果先前特定的硬件或软件产品已经标识,则语句“(如果兼容,或任何其他……)”可以出现在产品描述中。如果产品的先前版本已经标识,则语句“如果兼容,或升级的版本”可以出现在产品描述中。语句“自版本X至少到版本Y”可以出现在产品描述中,而“自版本X”不能出现在产品描中。
g)与其他产品的接口
如果产品描述引用了其他产品接口,则应对所引用的接口或产品进行标识。
h)要交付项
应对要提供的产品的每个物理部件进行标识,特别是所有打印的文档和所有的数据媒体。
应说明提供的程序形式如源程序、目标模块,或加载模块。
i)安装
应说明产品安装是否能由用户来完成。
j)支持
应说明是否提供对产品操作的支持。
k)维护
应说明是否提供维护。如果提供维护,应说明具体包括什么。
A.1.3功能说明
a)功能概述
产品描述应概述产品的用户可调用功能、需要的数据、所提供的设施。
对每个所论及的功能(尤其是选项和变量)是否是下列内容的一部分应清晰地说明:
——产品功能的;
——在产品描述中完整描述的产品扩展功能的;
——在产品描述中所引用的产品扩展功能的;
——无保证的补充功能的。
注:不必论及每个用户可调用功能,不必给出功能如何调用的每个细节。
b)边界值
如果由于产品特定的边界值致使产品的使用受限,则应提供这些边界值。例如:
——最小或最大值;
——键的长度;
——文卷中的记录的最大数日;
——检索准则的最大数目;
——最小样本大小。
当不可能提供固定的边界值时(例如,边界值取决于应用问题的类型或输入数据时),则应说明这些限制,可以提供允许的值组合,更具体的信息写入用户文档。
C)安全
如果提供的话,产品描述中应包含有关防止对程序或数据非授权的无意访问或蓄意访问的手段。
A.1.4可靠性说明
产品描述应包含数据存储规程的信息。
注:例如,只要说明使用操作系统进行备份就可以了。
应描述保证产品的功能能力的附加性质。例如:
——检验输入的合理性;
——防止由于用户的错误而产生的严重后果;
——出错恢复
A.1.5易用性说明
a)用户界面
应命名用户界面的类型,例如:命令行、菜单、窗口、功能键及帮助功能。
b)要求的知识
应规定应用该产品所要求的专门知识。例如:
——技术领域的知识:
——操作系统的知识;
——经过专门培训可获得的知识;
——除了已写入产品描述中以外的其他语言知识。
应说明用户文档和用户界面(包括出错信息和可视数据)所使用的所有自然语言,软件包本身和该产品描述中所涉及的所有其他产品的有关内容都应加以说明。
C)适应用户的需要
如果产品能被用户作适应性修改,则应标识这种修改的工具和修改工具的使用的条件。例如:
——参数的改变;
——计算的算法改变;
——功能键的分配。
d)防止侵权行为
如果防止侵权的技术保护可能有碍于软件的使用,则应说明这种保护,例如:
——防止拷贝的技术保护;
——程序设置的使用截止日期;
——相互约定的付费拷贝。
e)使用效率和用户满意度。
产品描述可以包括关于使用效率和用户满意度的数据。
A.1.6效率说明
产品描述可以包含产品的时间行为的数据,诸如在指定条件下(例如系统配置和负载分布)关于给定功能的响应时间和吞吐率。
A.1.7可维护性说明
产品描述可包含可维护性说明。
A.1.8可移植性说明
产品描述可包含可移植性说明。
A.2用户文档
A.2.l完整性
用户文档应包含产品使用所需信息。在产品描述中说明的所有功能以及在程序中用户可调用的所有功能,都应在用户文档中加以完整地描述。
用户文档中应再次说明产品描述中给出的所有边界值。
如果安装能由用户来完成,则用户文档应包括安装手册,该手册应包含所有必要的信息(见A.3.la)。安装手册宜说明一次安装的最小文卷和最大文卷。
如果维护能由用户来完成,则用户文档应包括程序维护手册,该手册应包含各种有关该软件维护所需要的信息。
A.2.2正确性
用户文档中所有信息应是正确的,不能有歧义和错误的表达。
A.2.3一致性
用户文档自身内容或相互之间以及与产品描述之间都不应相互矛盾。每个术语的含义宜处处保持一致。
注:程序和数据的一致性在A.3.1d)中论及。
A.2.4易理解性
用户文档对于正常执行其工作任务的一般用户宜是易理解的,例如,通过使用适当的术语、图形表示,详细的解释以及引出有用的信息源来表现。
A.2.5易浏览性
用户文档宜易于浏览,以使相互关系明确。
每个文档应有目录表和索引表。
如果文档未提供印刷本,则应指明打印过程。
A.3程序和数据
A.3.1功能性
a)安装
如用安装能由用户来完成,则按照安装手册中的信息应能成功安装。产品描述中指出的每种所要求的系统对于程序的安装应是充分的。
安装之后,程序能否运行应是可鉴别的。例如,使用提供的测试用例或通过相应信息的自检。
b)功能表现
用户文档中提到的所有功能应是可执行的。程序应按照用户文档中的给定形式,在规定的边界值范围内使用相应的设施、性质和数据执行其功能。
注:由于在产品描述中涉及的所有功能也应出现在用户文档中,这些功能更应是可执行的。
C)正确性
程序和数据应与产品描述及用户文档中的全部说明相对应。为完成工作任务,程序功能应以正确的方式执行。特别是,程序和数据应符合产品描述所引用的任一需求文档中的全部需求。
d)一致性
程序和数据其本身不能自相矛盾,并且同产品描述和用户文档不能相互矛盾。每个术语应处处具有相同的含义。
由用户行使的程序操作控制和程序行为(例如,消息,屏幕输入格式和打印报表)宜有一致的结构。
A.3.2可靠性
系统(包括硬件、要求的软件及属于该产品的程序)不应陷入用户无法控制的状态,既不应崩溃也不应丢失数据。
即使在下列情况下也应满足上述要求:
——使用的容量到达规定的极限;
——企图使用的容量超出规定的极限;
——由产品描述中列出的其他程序或用户造成的错误输入;
——用户文档中明确规定的非法指令。
只是那些不能用任何程序捕获的硬中断和操作系统中断(例如,系统操作复位用的键或组合键)不在此范围之内。
当程序认为输入错误或输入未经定义时,应视为不允许的输入,不加处理。
A.3.3易用性
关于易用性,根据本标准的规定,鼓励研究ISO9241系列标准最新版本应用的可能性。
注:特别是宜考虑ISO9241系列的第10部分和第13部分。
a)易理解性
程序的问题、消息和结果应是易理解的,例如:
——通过选择适当的术语:
——通过图形表示;
——通过提供背景信息:
——通过帮助功能的解释。
出错消息应提供解释相应差错产生原因和纠正的详细信息(例如通过引用用户文档的条文)。
b)易浏览性
如果有多种媒体,则每种数据媒体应具有产品标识、可辨别编号或文本。
对于使用程序进行工作的用户,总能找到哪个功能正在被执行是可能的。
程序宜以易观察易读的形式向用户提供信息。通过对信息的适当编码和分组对用户提供指导,必要时,程序可向用户发出警报。
源程序的消息应如此设计,即用户通过类型容易区分它们。例如:
——确认;
——程序询问;
——警告:
——出错消息。
屏幕输入格式,报表和其他输入、输出宜设计清晰和易于浏览。一般包括:
——字母数字字段左对齐:
——数字字段右对齐;
——在表中,小数点或逗号要排在同一垂直线上;
——字段界限是可识别的;
——哪些字段的使用是受限的,哪些字段是可识别的:
——标识输入失败后要立即在屏幕输入格式中加亮;
——通过一个可视或可听的信号来引起用户注意屏幕内容的改变。