PAGE\*Arabic1/NUMPAGES\*Arabic2
软件可追溯性分析管理规定
目的
对医疗器械软件开发进行控制，明确医疗器械软件开发、现成软件、网络安全等相关软件的可追溯性的流程和控制要求。
适用范围
本文件适用于作为医疗器械用途的独立软件，软件组件参照执行。本文件所述“软件”均是指医疗器械软件。
医疗器械软件的设计开发过程的可追溯性分析，还需要遵守本文件的要求。
本文件规定了软件需求分析、软件设计、软件编码、软件验证、软件确认、软件更新、风险管理、缺陷管理、网络安全、软件发布、软件部署、软件停运等过程中软件可追溯性的要求。
职责
3.1研发部：负责在设计和开发过程的软件可追溯性实施，确定设计和开发的过程中保证软件的可追溯性方法，并在设计开发过程中保证软件产品的可追溯性。
3.2其它各部门负责配合研发部实现软件的可追溯性。
定义
软件可追溯性分析：追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。
内容
5.1软件需求分析过程中的可追溯性
在软件产品设计开发过程中，进行风险分析和风险评估后，对不可接受的风险，拟定相应的风险控制措施，危害清单中的每一条不可接受的风险，在风险分析报告中都有唯一的编号，具体规定见《风险管理控制程序》。
产品需求是依据产品立项策划时对产品的定义，形成的产品需求文档。针对产品需求文档中的每一条需求，都应赋予唯一的编号。具体编号规则和要求见《软件需求分析管理规程》。
依据产品需求和风险管理资料，结合软件设计开发的要求，形成软件需求文档。软件需求文档中的每一条需求，都应赋予唯一的编号，具体编号规则和要求见《软件需求分析管理规程》。
在《可追溯性分析报告》中，应将风险管理报告中的每一条不可接受的风险对应的编号，可对应到软件需求中的具体需求条款的编号，可以是一对一、一对多、多对一的关系，保证每一条不可接受的风险，其对应的风险控制措施在软件需求中都有具体的需求来体现。
在《可追溯性分析报告》中，产品需求的每一个条款的编号，可对应到软件需求中具体条款的编号，可以是一对一、一对多、多对一的关系，保证每一条产品需求，在软件需求中都有具体的需求条款来体现。
5.2软件设计过程中的可追溯性
软件概要设计和软件详细设计的要求见《软件设计管理规程》。
软件概要设计中的每一条应由唯一的编号；软件详细设计中的每一条应有唯一的编号。
在《软件可追溯性报告》中，要体现软件需求中的每一条对应的软件概要设计条款编号，同时要体现软件概要设计中的每一条，对应的软件详细设计的条款号；对应关系可以是一对一、一对多、多对一的关系，保证每一条软件需求，在软件概要设计中都有对应条款，软件概要设计中的每个条款，在软件详细设计中都有对应条款。
5.2.1软件编码过程中的可追溯性
针对软件概要设计和软件详细设计中的每一条，都应有对应的软件代码实现。针对软件源代码，需进行测试，测试用例需要覆盖到所有软件功能和源代码。
在《可追溯性分析报告》中，需体现软件概要设计和详细设计，与源代码的对应关系；同时要体现软件源代码与测试用例的关系。
5.2.2软件验证过程中的可追溯性
在《可追溯性分析报告》中，需体现测试用例与软件设计文档中具体条款的对应关系，系统测试可验证软件需求的实现情况，系统测试用例和软件需求的条款需体现出对应关系，可以是一对一、一对多或多对一的关系。
系统测试也可验证风险管理中的风险控制措施实施的情况，在《可追溯性分析报告》中应体现系统测试用例与风险管理中的需采取风险控制措施的条款的对应关系。
5.3软件确认过程中的可追溯性
采用用户测试的方式对进行软件确认时，通过软件确认过程检验软件产品是否满足产品需求，同时确认软件产品实施了风险控制措施后风险是否可接受。
为体现软件确认的实施情况，应在《软件可追溯性报告》中体现用户测试报告中的条款应与产品需求中的条款的对应关系，可以是一对一、一对多或多对一的关系；同时为确认风险控制措施实施后风险是否可接受，在《软件可追溯性报告》中应体现用户测试报告中的条款与风险管理报告中的需采取风险控制措施的条款的对应关系，可以是一对一、一对多或多对一的关系。
5.4软件更新过程中的可追溯性
软件更新过程中，应分析软件更新对软件设计开发过程的影响，受到影响的软件开发过程对应的软件开发文档，需同步进行更新。
软件更新过程中的对应文档的更新，需满足可追溯性要求，其实现可追溯性的方式与软件设计开发过程中的方式一致。
可追溯性分析工具
为实现软件开发和软件更新过程的可追溯性，需使用可追溯性分析工具。可追溯性分析工具的使用，见《可追溯性分析工具使用操作规程》。
软件可追溯性分析报告
在软件开发过程中，应形成软件可追溯性分析报告。软件可追溯