软件需求规格说明

a. 引言

参考资料：
1、Process Impact Internet Application User Interface Standard 2.0

b. 综合描述

b.1 产品前景

本产品保险公司智能运营系统（后简称系统）旨在帮助甲方保险公司（小型保险公司）实现智能化运营，具体定位为保险公司内部人员进行日常工作的系统。系统采用C/S架构，客户端通过员工个人电脑访问，服务端与客户操作系统通过少量接口连接简化数据传输，与财务系统通过少量接口连接确保与财务有关的工作能够进行。本代系统是保险公司智能运营的初代1.0.0版本，是一个新开发的，试验性质的产品。在使用过程中不断接受反馈不断迭代完善本产品，并在一段时间后推出功能更加完善全面的更新版本。

b.2 产品功能

系统具有的主要功能有：

ID	要求功能	实现功能
1	职员管理	1. 不同部门分别管理，职能分开 2. 数据库管理职员个人档案和绩效档案 3. 保险经理人在线数据采集和画像，生成保险经理人标签 4. 职员过往工作记录分析
2	业务数据分析	1. 数据库管理PB级业务数据；业务数据增删改查 2. 对业务数据在时间，空间等维度上进行分析并生成图表 3. 保险客户分析，个性化服务
3	日常工作处理	1. 业务事件机制。相关工作人员处理响应事件 2. 依赖业务和独立业务。对于有依赖即有前提条件的业务，设施处理条件，要求完成前提条件下才能处理。独立业务之间互不干扰，相互独立 3. 业务期限提醒。针对有时间限制的业务，实现梯度时间提醒
4	绩效评测考核	1. 绩效完成度图表化展 2. 绩效未完成提示和通
5	工作记录留档	1. 数据库存储职员工作日志
6	其他系统对接	1. 财务系统接口 2. 客户系统接口

b.3 用户类和特征

本产品用户为保险公司内部职员，可细分为营销部（保险经理人），财务部，售后服务部，人事部，行政部等主要五个部门。

• 五部门职员的共同特征

  1. 经常处理业务数据和日常工作时间
  2. 时常查询自身的绩效数据
  3. 有时更改自身档案

• 营销部保险经理人的特有特征

  1. 经常使用保险客户分析
  2. 经常使用系统与客户系统的接口
  3. 经常查询过往自身业务数据以及对业务数据进行分析
  4. 时常查看自身的用户画像和标签

• 财务部职员的特有特征

  1. 经常使用系统与财务系统的接口
  2. 经常查询过往工作记录对账

• 售后服务部职员的特有特征

  1. 经常使用系统与客户系统的接口
  2. 经常查询过往保单记录

• 人事部职员的特有特征

  1. 经常使用职员过往工作记录分析
  2. 经常使用绩效考核相关功能
  3. 时常使用保险经理人画像功能

• 行政部职员特有特征

  1. 经常发起公司内部业务事件
  2. 时常使用过往工作记录查询功能

b.4 运行环境

• 硬件平台

  • 服务端：市面上常见的满足性能要求的服务器
  • 客户端：市面上常见的电脑主机或笔记本

• 操作系统和版本

  • 服务端：Debian或者CentOS
  • 客户端：无要求

• 软件依赖

  • 服务器：Apache，Tomcat，Nginx
  • 客户端：能够使用Web服务的浏览器

b.5 设计和实现上的限制

• 必须使用公司其他系统已经使用的数据库
  • 原因：如果运营系统使用不同的数据库系统，系统将花费大量资源在数据库数据的迁移上，并且在数据迁移上可能导致不可挽回的数据错误。
• 保证高并发大流量情况下的系统稳定性
  • 原因：公司人数众多，在工作时间系统流量大，在高并发性和大流量性下的稳定性必须保证以保证公司日常运行。
• 避免使用python语言
  • 原因：python语言的执行效率较低，不能满足公司智能运营的效率要求。

b.6 假设和依赖

• 假设
  • 保险公司完全使用本系统进行日常工作
  • 保险公司的财务系统，客户系统与日常运营系统相互独立
• 依赖
  • 需要甲方公司提供合适的服务器设备
  • 需要甲方公司提供贵司的其他内部系统的接口和对应文档

c. 外部接口需求

c.1 用户界面

1. “保险公司运营平台”的屏幕画面将遵照 Process Impact Internet Application User Interface Standard 2.0版本。
2. 系统对所有的交互功能都提供帮助链接，解释如何使用该功能。
3. 页面的全部导航和选择，除了综合使用鼠标和键盘共同完成之外，还可以只用鼠标来完成。

c.2 硬件接口

• 无特殊需求

c.3 软件接口

1. 公司财务系统：允许保险业务员查看对应保单的缴纳情况；允许理赔人员发起对客户的打款请求。
2. 公司邮件系统：允许保险业务员和理赔部门直接使用公司邮箱， 码发送给用户提醒消息。
3. openGauss数据库：保险业务表单的数据信息储存在openGauss数据库中，允许保险业务员对保单信息进行查询，修改，增加。

c.4 通信接口

1. “保险公司运营平台”将会向客户发送短信和电子邮件，以确认保险订单的内容、金额、时间和注意事项。
2. “保险公司运营平台”将会向客户发送短信和电子邮件，以 告理赔过程的进度或受理结果。

d. 系统特性

1. 保单录入

描述和优先级

保险业务员在其身份得到验证后，就可以创建新保单，选择对应保险业务，填写必要信息和备注。优先级为高。

激励/响应序列

刺激：保险业务员请求新建保单

响应：系统提供空白的表单模板

刺激：保险业务员提交新建保单

功能性需求

• 点击新建表单，弹出页面，页面内容为新建表单类型的选择栏
• 选择对应保险业务类型，点击“下一步”，窗口跳转至对应类型的空白表单
• 填写信息后，点击“提交”，系统验证是否完成所有必填项，项目对应数据类型是否合规，如有不和规范的选项，用高亮的红色标识，弹出窗口“信息有误”。

2. 表单追踪

描述和优先级

保险业务员在保单期间内可以查询保单信息，系统自动提醒用户缴费。优先级为高。

激励/响应序列

刺激：保险业务员输入保单 ，查询客户保单

响应：系统返回客户保单信息

刺激：保险业务员进行业务查询

响应：系统返回该业务员近期经手的保单

刺激：日期到达保单应缴时间

响应：系统自动发送短信给用户，提醒缴费

刺激：保险业务自动扣费后

响应：系统自动发送短信给用户，提醒已成功缴费

功能性需求

• 点击“表单查询”，系统跳出弹窗，以输入保单
• 输入合法单 后，点击“查询”，系统返回客户保单详细信息，否则提示“单 错误”
• 点击“近期业务查询”，系统返回该业务员近期经手的保单列表
• 系统定期扫描数据库，对近期应缴保单的预留手机 发送提醒短信
• 系统每日扫描数据库，对成功扣费订单的预留手机 发送提醒短信

3. 表单修改

描述和优先级

保险业务人员在一定期限内可对保险业务进行修改，取消服务。优先级高。

激励/响应序列

刺激：保险业务人员对业务发起修改处理

响应：判断保险业务是否允许实施对应操作，如果允许，则返回表单修改界面，否则弹窗提示“无法修改”。

功能性需求

• 点击表单修改，系统跳出弹窗，以输入保单
• 输入合法单 后，点击“查询”，系统返回客户保单详细信息，否则提示“单 错误”
• 点击“保存”，系统检测哪些信息发生修改，判断能否修改，能则返回“修改成功”，更新数据库，否则返回“无法修改”，用高亮红字提示无法修改的地方。

4. 保险理赔

描述和优先级

激励/响应序列

刺激：点击“新建赔付申请”

响应：系统提供空白的表单模板

刺激：业务员提交新建保单

响应：通知财务系统转账，发送短信给客户

功能性需求

• 点击新建表单，弹出页面，页面内容为新建表单类型的选择栏
• 选择对应保险业务类型，点击“下一步”，窗口跳转至对应类型的空白表单
• 填写信息后，点击“提交”，系统验证是否完成所有必填项，项目对应数据类型是否合规，如有不和规范的选项，用高亮的红色标识，弹出窗口“信息有误”。

e. 其它非功能性需求

e.1 性能需求：

通用系统：

1. 用于存储保单数据以及客户数据的数据库存储空间至少需要1T，每张表的最大行数为10^9；
2. 对于保险公司内部人员个人信息的增删改查时间不得超过1s；
3. 内部通信系统的带宽不得小于16Mbps；

营销部：

1. 对于保单数据以及客户数据的增删改查时间不得超过10s；
2. 对客户数据进行智能分析到展示图表的时间不得超过1min；

售后服务部：

1. 业务员保单初审后，从提交保单到录入系统的时间不得超过1min；
2. 该系统查找某个客户的保单信息所用时间不得超过10s；

财务部：

1. 财务部对于收付款信息的增删改查时间不得超过1s；
2. 从成本统计分析、获利分析到展示图表所用的时间不得超过1min；
3. 财务部完成用户交易时间不得超过1s；

e.2 安全设施需求：

通用需求：

1. 公司数据库管理员对用户内部成员信息进行增加、删除、修改、或者对各个用户权限进行修改时均需要进行双重验证（两层提示框）。

财务部：

1. 在进行和收付款相关的操作时应进行双重验证（提示框+身份验证），防止用户进行误操作；
2. 系统规定单次交易的最高金额为5万元，来自相同用户的交易间隔时间不得小于1分钟；
3. 税务部的发票与缴税情况应记录在专门的数据库中；
4. 财务 表和总账应在每次交易后进行更新。

人事部：

1. 人事部绩效考核的会议内容和录像应在会议结束后自动进行归档。

售后服务部：

1. 办理理赔服务后，需要系统判断财务部 表和总账是否与实际账单相匹配，从而进行赔偿核对。

e.3 安全性需求：

通用：

1. 只有公司的数据库管理员才拥有对内部人员数据库的增删改查以及权限管理的权限。
2. 公司数据库管理员不能修改自己的权限。
3. 公司内部人员可以看到自己的个人信息和他人的共有信息（绩效和工资发放），但无权查看其他用户的私有信息（如身份证，银行卡 等）。
4. 该平台必须严格保证客户个人信息和交易信息的保密性和安全性，防止黑客以及竞争对手入侵公司系统，数据库和个人信息。

营销部：

1. 营销部用户组拥有对保单数据以及客户数据的增删改查权限，但无添加和删除表和数据库的权限。
2. 只有营销部用户组可以对客户数据进行智能分析。
3. 保险营销以及保险研发相关细节只能由公司全体内部人员查看，不得泄密。

售后服务部：

1. 只有售后服务部可以访问保险理赔以及核对赔偿模块。

人事部：

1. 只有人事部用户组才可以访问并修改招聘考核、绩效考核以及人事记录模块。
2. 只有人事部才可以对公司内部成员进行用户画像，从而规定公司各个内部成员的薪资、奖励、福利等。

财务部：

1. 只有财务部用户组才可以访问公司内部收付款，财务 表和总账模块。
2. 财务部用户组可以获取客户姓名等简略信息，但不能获取客户的详细信息。
3. 只有财务部用户组才可以进行薪资发放，将保险赔偿金转至客户。

行政部：

1. 只有行政部可以接受和查看合同需求具体信息。

e.4 软件质量标准属性：

由于本系统只对保险公司内部成员使用，因此有效性优于可移植性，

对于各部门相关模块的有效性，提出以下需求：

1. 本保险公司的数据库应能准确进行增删改查，录入时不应发生错误。
2. 当遇到电脑故障，停电等不可抗因素时，能够对正在进行的操作进行断点记录和有效备份。
3. 该平台的平均无故障时间应在24h以上，平均故障恢复时间必须小于10s。
4. 该保险公司智能系统在1次交易/s的高峰期仍能正常运行。

对于各个模块的易用程度：

1. 各部门从打开智能系统到跳转到相应部门的模块，执行相应操作所需平均时间不得超过5min。

e.5 业务规则：

通用：

1. 存储保单数据以及客户数据的数据库至少应一周一次进行定时备份，如果发生数据库损坏，则各部门应第一时间获取最近的一次数据库备份，以尽量减少损失。
2. 存储内部人员个人基本信息、工资绩效的数据库应每月进行一次人工复核。

人事部：

1. 公司内部成员绩效考核结果应由公司内部人员进行全体会议后决定。
2. 公司内部成员薪资待遇信息应每月更新一次，并通知财务部定期发放薪资，同时记录到公司内部成员信息数据库中。

财务部：

1. 财务部成员应每天一次对当天的财务 表结和总账、发票、缴税进行人工复核。
2. 财务部应每周进行一次成本统计分析和获利分析，并上 给人事部。

行政部：

1. 售后服务部初审录入保单、进行保险理赔时，应询问行政部的意见。此时行政部负责草拟法律意见，必要时进行仲裁诉讼。

营销部：

1. 营销部应每周一次将客户的智能分析结果 告给人事部以及售后服务部。
2. 营销部进行保险营销，保险研发时，应将保险营销的收益上交至人事部，结合经理人出售保单数据，作为绩效考核的依据。

e.6 用户文档：

对于各个部门的模块，均配备用户手册、在线帮助和教程，着重强调UI界面各个模块的内容，各个标签栏作用，以及常见关键操作流程。

其他需求

附录A：词汇表

编	名称	别名	英文名
1	保险业务员	保险经理人，业务员	salesman
2	用户画像	用户角色	persona
3	保单	保险单据	warranty
4	保险售后	保险赔付，赔付	insurance compensation
5	营销部	宣传部	marketing department
…	…	…	…

附录B：分析模型

附录C：产品使用场景

以上场景的结构分析和面向对象分析：

结构分析图：

0-1层图：

DFD片段：