标准理赔系统需要具备的文档

理赔系统所需相关文档

注：

标题一，技术类文档为必须提供，并保证与项目实现相符。

标题二，管理类文档，标题三，计划类文档，可以根据项目实际情况，选择提供。但必须提供2.1《需求管理计划》、2.4《人员职能安排计划》、3.1《项目实施计划—里程碑》、3.2《项目活动定义》、3.4《项目进度计划》、3.5《项目开发详细计划》。

对于已完成，但未及时更新的相关文档，需进行后续补充，并由公司项目管理办公室调研、审查，确保文档完整、正确，为后续开发、维护等工作提供必要保证。

建议：项目上线后，召开项目工作交接会议，为接手人员提供文档使用培训、项目实现培训等工作，并由接手人员反馈交接情况，统一提交项目管理办公室评估能否结束交接工作。

一、项目技术类文档

1.1《理赔系统需求文档》

需求文件的组成部分包括（但不限于）：

●业务需求或需抓住的机遇，描述当前局面的不足以及启动项目的原因；

●可跟踪的业务目标和项目目标；

l 需求范围的确定，其中明确出哪些属于范围内哪些属于范围外。

●功能要求，描述业务流程、信息以及与产品的内在联系。可采用适当的方式，如写成文本式需求清单或制作出模型，也可以同时采用这两种方法；

●非功能性要求，如服务水平、绩效、安全、防护、合规性、保障能力、保留／清除等；

●质量要求；

●验收标准；

●体现组织指导原则的业务规则

●对组织其他领域的影响，如呼叫中心、销售队伍、技术团队；

●对执行组织内部或外部团体的影响；

●对支持和培训的需求；

●与需求有关的假设条件和制约因素。

1.2《理赔系统功能概要设计文档》

概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。概要设计建立的是目标系统的逻辑模型，与计算机无关。

1.3《理赔系统功能详细设计文档》

详细设计是对概要设计的一个细化，就是详细设计每个模块实现算法，调用关系，参数类型，所需的局部结构，并且出于这种代码设计的原因和想法。有必要可以列出后续的扩展性与可维护性进行描述。

1.4《理赔系统数据库设计文档》

内容包括（但不限于）：

●数据库模型（二维表）

●各表间关系

●各表数据写入规则

1.5《理赔系统数据迁移设计文档》

出于数据迁移的复杂性，建议将其拆分成一个单独的项目进行管理和控制。

内容包括（但不限于）：

●新老系统表、数据探查

●新老系统表对迁关系

●技术架构、方案

●迁移程序详细设计

●数据迁移测试设计

●风险、免责说明

1.6《理赔系统操作手册》

系统操作使用说明。

1.7《理赔系统测试文档》

内容包括（但不限于）：

●测试计划

●测试需求

●测试用例

●测试过程及结果记录

●bug清单及修改情况

●最终测试报告

●压力测试报告

1.8《理赔系统框架结构说明文档》

内容包括（但不限于）：

●系统框架结构说明

●系统文件夹、文件命名规范

●代码注释规范

●类命名、方法命名规范

●关键配置文件说明

●编码规范

1.9《理赔系统查勘费分摊功能设计文档》

注：结合都邦实际情况，提供。

1.10《理赔系统查勘费分摊功能操作手册文档》

注：结合都邦实际情况，提供。

1.11《理赔系统使用配置说明文档》

内容包括（但不限于）：

●客户端，软硬件配置、操作系统要求

●浏览器版本要求

●浏览器设置操作说明

●影像控件配置、使用说明

1.12《理赔系统应用环境及数据库环境搭建文档》

内容包括（但不限于）：

●系统应用部署

●系统数据库部署

●数据迁移

1.13《理赔系统外部接口文档》

内容包括（但不限于）：

●外部接口技术实现方式说明

●外部接口报文格式定义

●外部接口日常维护使用说明

●外部接口相关责任方及联系方式

1.14《理赔系统上线操作说明文档》

罗列上线时需执行的活动，并对活动排序，保证上线过程有章可循。

二、项目管理类文档

2.1《需求管理计划》

需求管理计划的内容包括（但不限于）：

●如何规划、跟踪和汇报各种需求活动；

●配置管理活动，例如，如何启动产品、服务或成果的变更，如何分析其影响，如何进行跟踪和汇报，以及谁有权批准变更；

●需求排序过程；

●产品测量指标及使用这些指标的理由；

●需求跟踪结构，即：哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。

2.2《需求跟踪矩阵》

需求跟踪矩阵是一张连接需求与需求源的表格，以便在整个项目生命周期中对需求进行跟踪。需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来，有助于确保每一个需求都具有商业价值。它为人们在整个项目生命周期中跟踪需求提供了一种方法，有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。

跟踪需求的过程包括（但不限于）：

●从需求到业务需要、机会、目的和目标；

●从需求到项目目标；

●从需求到项目范围／WBS 中的可交付成果；

●从需求到产品设计；

●从需求到产品开发；

●从需求到测试策略和测试脚本；

●从宏观需求到详细需求。

2.3《沟通管理计划》

沟通计划能够帮助项目经理跟踪当前所有干系人对于项目修改所持有的态度，将其标致记录能够便于后期查看和让相关人员沟通，也可使项目经理了解当前存在的沟通问题，干系人中包括受项目影响，这里包括正面和负面的影响，可能各个干系人对于项目进行都持有不同态度，最大限制满足干系人需求，协调所有干系人可以是项目减少反工风险，也可以增加所有人的支持度。

内容包括（但不限于）：

●干系人的沟通需求

●需要沟通的信息

●发布相关信息的原因

●发布信息的时限和频率

●负责沟通的人员

●传递信息的技术或方法

●为沟通活动分配的资源

●在下层员工无法解决问题时的升级流程，关注上报时限和上报路径

2.4《人员职能安排计划》

记录管理项目团队相关资源的使用计划。

内容包括（但不限于）：

●项目团队组织结构图与职位描述

●成员任职表

●成员职位、职能详细描述及通报

2.5《质量管理计划》

质量管理计划说明项目管理团队将如何实施执行组织的质量政策，包括质量控制、质量保证、持续过程改进方法。

三、项目计划类文档

3.1《项目实施计划—里程碑》

从项目全局规划出发，定义整个项目过程中的关键节点，大方向上把握项目计划及进度。

3.2《项目活动定义》

定义活动是识别为完成项目可交付成果而需采取的具体行动的过程。创建工作分解结构过程已经识别出工作分解结构（WBS）中底层的可交付成果，即工作包。项目工作包通常还应进一步细分为更小的组成部分，即活动——为完成工作包而必须开展的工作。活动是开展估算、编制进度计划以及执行和监控项目工作的基础。

3.3《WBS》

创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。工作分解结构是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。工作分解结构每下降一个层次就意味着对项目工作更详尽的定义。工作分解结构组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作。

3.4《项目进度计划》

项目进度计划中至少要包括每项活动的计划开始日期与计划完成日期。

其中包括项目活动网络图，单双号网络图逻辑图。

最好可以使用顺推方和逆推法计算出确切工期。

3.5《项目开发详细计划》

细化项目开发活动，将最小粒度的开发活动与成员、时间相关联，指导项目开发过程及跟踪。

基准理赔系统需要具备的文档

一、项目技术类文档

1.1《理赔系统需求文档》

1.2《理赔系统功能概要设计文档》

1.3《理赔系统功能详细设计文档》

1.4《理赔系统数据库设计文档》

1.5《理赔系统数据迁移设计文档》

1.6《理赔系统操作手册》

1.7《理赔系统测试文档》

1.8《理赔系统框架结构说明文档》

1.9《理赔系统查勘费分摊功能设计文档》

1.10《理赔系统查勘费分摊功能操作手册文档》

1.11《理赔系统使用配置说明文档》

1.12《理赔系统应用环境及数据库环境搭建文档》

1.13《理赔系统外部接口文档》

1.14《理赔系统上线操作说明文档》

二、项目管理类文档

2.1《需求管理计划》

2.2《需求跟踪矩阵》

2.3《沟通管理计划》

2.4《人员职能安排计划》

2.5《质量管理计划》

三、项目计划类文档

3.1《项目实施计划—里程碑》

3.2《项目活动定义》

3.3《WBS》

3.4《项目进度计划》

3.5《项目开发详细计划》

相关推荐