©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
1、 XXX客户关系管理系统 需求分析阐明书 编号：BDQN-LIB-CRM 版本：1.0 作者： 北大青鸟 日期： -11-22 审批： 北大青鸟 日期： -12-4 状态 修订人 修改日期 版本 备注 新创立 北大青鸟 -11-21 1.0 目 录 1. 概述 4 1.1 目 4 1.2 定义、简写和缩略语 4 1.3 综述 5 2 总体描述 5 2.1 产品描述 5 2.2 产品功能 6 2.3
2、顾客特点 6 3 功能性需求 9 3.1 功能描述 9 3.2 流程描述 9 3.2.1 系统设立模块 9 3.2.2 销售管理模块 17 3.2.3 客户管理模块 27 3.2.4 服务管理模块 33 3.2.5 订单管理模块 40 3.2.6 合同管理模块 43 3.2.7 记录分析模块 45 4 非功能性需求 50 4.1 技术需求 50 4.1.1 软硬件环境需求 50 4.1.2 产品性能 50 4.1.3 安全性 51 4.2 质量需求 51 4.2.1 可靠性 51 4.2.2 灵活性 51 4.2.3 兼容性 51 4.2.4 易用性 5
3、2 4.3 文档需求 52 4.3.1 文档清单 52 4.3.2 顾客手册 52 4.4 设计约束 52 4.4.1 语言约束 53 4.4.2 系统模型约束 53 5 验收原则 54 1. 概述 1.1 目 读者范畴：最后顾客和软件设计人员 本文档作为CRM需求阐明文档，用于与顾客拟定最后目的，并成为合同文本一某些，同步也是本系统设计人员基本文档。 1.2 定义、简写和缩略语 编号 缩写、术语 解 释 1. 建模语言 用语法和语义定义、用来表达模型语言。某些建模语言尚有某些实用规则。 2. UML Unified Modeling Lang
4、uage统一建模语言，是一种建模语言，是第三代用来为面向对象开发系统产品进行阐明、可视化和编制文档办法，已正式成为进行软件分析和设计办法信息技术国际原则。 3. 顾客 指运营系统或者直接与系统发生交互作用个人或集团。 4. 迭代 迭代涉及产生产品发布（稳定、可执行产品版本）所有开发活动和要使用该发布必须所有其她外围元素。因此，在某种限度上，开发迭代是一次完整地通过所有工作流程过程：（至少涉及）需求工作流程、分析设计工作流程、实行工作流程和测试工作流程。 5. 用例 从一种外部角色角度描述如何使用系统。用例阐明了系统功能，并且是用外部角色、用例和被建模系统角度来描述。用例应当对
5、某个特定角色产生一种可见成果。 6. 前置条件 在操作被执行前必要为真条件。 7. 后置条件 在操作完毕后必要为真一种条件。 8. 扩展 在用例之间一种通用关系，其中一种用例通过增长动作把另一种用例扩展成一种更通用化用例。扩展用例也许包括被扩展用例（依扩展条件而定）。 9. 优先级 5最高、4高、3中、2低、1最低。 10. 富文本编辑器 富文本编辑器，Rich Text Editor，简称 RTE，它提供类似于 Microsoft Word 编辑功能，可以协助顾客在浏览器中设立各种文本格式。 11. 流程图 本文专指业务流程图，就是用某些规定符号及连线来表
6、达某个详细业务解决过程。业务流程图绘制基本上按照业务实际解决环节和过程绘制。 1.3 综述 本文档第一某些为引言，重要简介需求规格阐明书背景内容；第二某些为项目总体描述，第三某些是系统详细需求阐明和用例阐明。 2 总体描述 2.1 产品描述 协助管理者更好完毕客户关系管理两项基本任务：辨认和保持有价值客户。一是扩展客户，二是维护客户关系增长二次收益。 2.2 产品功能 图1 功能构造图 2.3 顾客特点 顾客分为如下几类：系统管理员、销售总监、销售经理、销售代表。 系统管理员拥有本系统所有权限；销售总监负责所有销售状况；销售经理从属于销售总监，并负责下属销售代表销售状况；
7、销售代表从属于上级销售经理。 顾客构造如下： 销售总监 销售经理 销售代表 系统管理员 系统用例图： 依照以上顾客特点描述，本系统用例图如下所示： 图2 系统总用例图 3 功能性需求 3.1 功能描述 客户关系管理系统重要用于寻常工作中客户资源维护与管理等任务。重要涉及系统设立、销售管理、客户管理、服务管理、订单管理、合同管理、记录分析等模块，可满足寻常客户资源维护、销售数据分析、潜在和有价值客户分析等需求。 3.2 流程描述 3.2.1 系统设立模块 3.2.1.1 角色管理 图3 角色管理用例图（编号UC011） 用例阐明： 用例框架 框架
8、阐明 用例名称 角色管理 重要参加者 系统管理员 简要阐明 管理系统中各组织构造下岗位角色。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.2 权限管理 图4 权限管理用例图（编号UC012） 用例阐明： 用例框架 框架阐明 用例名称 权限管理 重要参加者 系统管理员 简要阐明 管理系统中岗位角色权限，给顾客分派角色等功能 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2
9、 阐明 无 3.2.1.3 组织构造 图5 组织构造用例图（编号UC013） 用例阐明： 用例框架 框架阐明 用例名称 组织构造 重要参加者 系统管理员 简要阐明 用于管理员维护公司部门构造。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.4 员工管理 图6 员工管理用例图（编号UC014） 用例阐明： 用例框架 框架阐明 用例名称 员工管理 重要参加者 系统管理员 简要阐明 用于管理员维护员工信息（涉及对员工进行状态启用
10、/停用或角色授权操作）。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.5 公示管理 图7 公示管理用例图（编号UC015） 用例阐明： 用例框架 框架阐明 用例名称 公示管理 重要参加者 销售总监、销售经理、销售代表 简要阐明 销售总监和销售经理对发布公示进行管理 销售代表可以查看发布公示 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.6
11、个人信息管理 图8 个人信息管理用例图（编号UC016） 用例阐明： 用例框架 框架阐明 用例名称 个人信息管理 重要参加者 销售总监、销售经理、销售代表 简要阐明 每个人可以修改自己顾客信息和登录密码。 新增员工初始化登录ID为“名.姓”格式全拼字母，登录密码为0000。 每个人仅能修改一次自己登录ID。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.7 基本信息 图9 基本信息管理用例图（编号UC017） 用例阐明： 用例框架 框架
12、阐明 用例名称 基本信息 重要参加者 系统管理员 简要阐明 管理惯用系统参数，例如选项开关，自动绩效考核时间设定等信息。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.1.8 数据字典 图10 数据字典管理用例图（编号UC018） 用例阐明： 用例框架 框架阐明 用例名称 数据字典 重要参加者 系统管理员 简要阐明 系统所需基本数据字典管理 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无
13、 优先级 2 阐明 无 3.2.2 销售管理模块 3.2.2.1 销售筹划 图11 销售筹划管理用例图（编号UC021） 用例阐明： 用例框架 框架阐明 用例名称 销售筹划 重要参加者 销售总监、销售经理、销售代表 简要阐明 1、 销售总监制定公司阶段销售筹划合理规划业务发展。 2、 销售总监查看各销售经理部门销售筹划，指引并协助其进行合理开展部门销售工作。 3、 销售经理制定部门阶段销售筹划合理规划部门业务开展工作。 4、 用于销售经理查看下属销售代表个人销售筹划，指引并协助其进行合理开展销售工作。 5、 销售代表管理本人销售筹划，并可将
14、销售筹划提交给上级。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 流程图： 图12 销售筹划审核流程图（编号FC021） 状态图： 图13 销售筹划审核状态图（编号SD021） 3.2.2.2 销售预测 图14 销售预测用例图（编号UC022） 用例阐明： 用例框架 框架阐明 用例名称 销售预测 重要参加者 销售总监、销售经理 简要阐明 1、通过对收集资料分析，对预测目的时间内公司销售状况进行预测，该预测成果供销售总监查看。 2、通过对收集资
15、料分析，对预测目的时间内指定部门销售状况进行预测，该预测成果供销售总监查看。 3、通过对收集资料分析，对预测目的时间内本部门销售状况进行预测，该预测成果供销售经理查看。 通过对收集资料分析，对预测目的时间内本部门指定个人销售状况进行预测，该预测成果供销售经理查看。 事件流 1、指定预测目的时间，设定系统变量(业务部门规模、上年度同期业绩、当前客户数量等系统数据由系统自动提供，可以手动修改) 2、导入收集资料（数据文献格式为Excel文档） 3、执行分析过程 4、输出分析成果 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2
16、 阐明 无 图15 销售预测执行流程图（编号FC022） 3.2.2.3 销售绩效 图16 销售绩效用例图（编号UC023） 用例阐明： 用例框架 框架阐明 用例名称 销售绩效 重要参加者 销售总监、销售经理 简要阐明 销售总监按部门业绩考核销售经理，销售经理按个人业绩考核销售代表。可设定业绩目的与相应奖励，从下个月开始生效。每月1号将前一种月所有订单明细记录为结账数据，系统自动依照结账数据与设定业绩目的对员工进行考核。 事件流 1、 设定业绩目的与相应奖励 2、 次月1日系统自动结算上个月订单，并按预设参数执行绩效考核计算 前置条件
17、 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 流程图： 图17 销售绩效执行流程图（编号FC023） 3.2.2.4 机会管理 图18 机会管理用例图（编号UC024） 用例阐明： 用例框架 框架阐明 用例名称 机会管理 重要参加者 销售经理、销售代表 简要阐明 销售代表发现销售机会时，在系统中创立销售机会。 所有销售机会由销售经理进行分派，分派给指定销售代表。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级
18、 2 阐明 无 流程图： 图19 销售机会管理流程图（编号FC024） 状态图： 图20 销售机会管理状态图（编号SD024） 3.2.2.5 联系人管理 图21 联系人管理用例图（编号UC025） 用例阐明： 用例框架 框架阐明 用例名称 联系人管理 重要参加者 销售总监、销售经理、销售代表 简要阐明 用于管理个人联系人信息。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.2.6 竞争管理 图22 竞争管理用例图（编
19、号UC026） 用例阐明： 用例框架 框架阐明 用例名称 竞争管理 重要参加者 销售总监 简要阐明 通过度析目的数据，得到行业信息、行业动态、竞争对手核心数据等信息并对分析成果进行保存和归档管理，以供查阅。 事件流 1、 手动导入Excel格式文献 2、 系统对目的文献中数据进行分析，得到分析成果。 3、 操作人对分析成果进行分类和保存。 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.2.7 销售分析 图23 销售分析用例图（编号UC027） 用例阐明： 用
20、例框架 框架阐明 用例名称 销售分析 重要参加者 销售总监、销售经理 简要阐明 每月初系统按部门自动记录上个月各销售代表和各部门销售状况，并生成记录报表和记录图。其中各部门记录成果供销售总监查看，各销售代表记录成果供销售经理查看。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.3 客户管理模块 3.2.3.1 客户资源管理 图24客户资源管理用例图（编号UC031） 用例阐明： 用例框架 框架阐明 用例名称 客户资源管理 重要参加者 销售总监、销售
21、经理、销售代表 简要阐明 1、用于销售总监、销售经理维护公司已有客户资源，状态为“启用”客户信息可以编辑。 2、销售总监、销售经理可以对公司既有客户资源进行分派，指定给销售代表维护。 3、销售代表可以维护指定给自己客户资源。 事件流 前置条件 登录后并具备该操作权限 后置条件 非功能需求 扩展点 优先级 阐明 3.2.3.2 客户发展筹划 图25客户发展筹划用例图（编号UC032） 用例阐明： 用例框架 框架阐明 用例名称 客户发展筹划 重要参加者 销售代表 简要阐明 用于销售代表制定每月份个人新客户发展
22、规划。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.3.3 客户价值管理 图26客户价值管理用例图（编号UC033） 用例阐明： 用例框架 框架阐明 用例名称 客户价值管理 重要参加者 销售经理、销售代表 简要阐明 通过度析模型对客户已有消费行为进行价值分析，得出将来一段时间消费预测，推算出客户将来价值，有助于对客户进行有针对性服务。 事件流 前置条件 分析目的为已有购买行为客户 后置条件 无 非功能需求 无 扩展点 无 优先级
23、 2 阐明 无 3.2.3.4 客户满意度管理 图27客户满意度管理用例图（编号UC034） 用例阐明： 用例框架 框架阐明 用例名称 客户满意度管理 重要参加者 销售经理、销售代表 简要阐明 通过定期回访、座谈会、问卷等形式收集既有客户对产品或服务满意度，分析并提出有关工作改进建议，为后续客户维护工作提供指引。 事件流 前置条件 目的为已有购买行为客户 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.3.5 客户信誉管理 图28客户信誉管理用例图（编号UC035
24、 用例阐明： 用例框架 框架阐明 用例名称 客户信誉管理 重要参加者 销售经理、销售代表 简要阐明 通过信用模型对客户进行信誉分析，依照分析成果对客户进行差别化服务。 事件流 前置条件 目的为已有购买行为客户 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.3.6 客户关怀 图29客户关怀用例图（编号UC036） 用例阐明： 用例框架 框架阐明 用例名称 客户关怀 重要参加者 销售代表 简要阐明 通过设立关怀周期和特定日期（如生日、春节等）提示，提示销售代表对客户进行定期回访
25、回访提供关怀服务。关怀服务内容可依照该客户综合评分指数（客户价值、满意度、信誉度等）来指定。 事件流 1、 设立关怀周期和特定节日提示 2、 依照客户综合评分指数选取关怀方案 3、 实行关怀服务，填写执行成果 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 流程图： 图30 客户关怀执行流程图（编号FC036） 3.2.4 服务管理模块 3.2.4.1 服务创立 图31服务创立用例图（编号UC041） 用例阐明： 用例框架 框架阐明 用例名称 服务创立 重要参加者 销
26、售经理、销售代表 简要阐明 当收到客户服务祈求时，创立服务单据，状态为“新创立”。拟定提交后，状态为“已提交”。 事件流 前置条件 收到客户服务祈求 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.4.2 服务分派 图32服务分派用例图（编号UC042） 用例阐明： 用例框架 框架阐明 用例名称 服务分派 重要参加者 销售经理 简要阐明 销售经理对状态为“已提交”服务单据进行分派，指定销售代表解决该单据。除了“新创立”以外其她状态可以被查看。 事件流 前置条件 系统存在状态为“已提交”
27、服务单据 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.4.3 服务解决 图33服务解决用例图（编号UC043） 用例阐明： 用例框架 框架阐明 用例名称 服务解决 重要参加者 销售代表 简要阐明 被分派解决服务销售代表负责对服务祈求进行解决，并在系统中记录解决过程和成果。 事件流 前置条件 发现系统中存在分派服务祈求 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.4.4 服务反馈 图34服务反馈用例图（编号UC044）
28、用例阐明： 用例框架 框架阐明 用例名称 服务反馈 重要参加者 销售代表 简要阐明 对状态为“已解决”服务单据积极联系客户进行反馈，填写服务反馈成果。 事件流 前置条件 发现状态为“已解决”服务单据 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.4.5 服务归档 图35服务归档用例图（编号UC045） 用例阐明： 用例框架 框架阐明 用例名称 服务归档 重要参加者 销售经理、销售代表 简要阐明 对状态为“已反馈”服务进行归档操作，便于其她员工查询、查阅，为解决类似问题提供参照。
29、 事件流 前置条件 系统中存在状态为“已归档”服务 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.4.6 常用问题管理 图36常用问题管理用例图（编号UC046） 用例阐明： 用例框架 框架阐明 用例名称 常用问题管理 重要参加者 销售经理、销售代表 简要阐明 销售代表可以将寻常工作中遇到常用问题录入到系统中，以便其她员工（普通为新员工）参照学习。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无
30、流程图： 图37 服务管理流程图（编号FC040） 状态图： 图38 服务管理状态图（编号SD040） 3.2.5 订单管理模块 3.2.5.1 代下订单 图39代下订单用例图（编号UC051） 用例阐明： 用例框架 框架阐明 用例名称 代下订单 重要参加者 销售代表 简要阐明 对于不以便下单客户，销售代表可以代替其进行下单操作 事件流 1、接到代下单祈求 2、拟定客户身份 3、选取购买产品 4、客户确认 5、执行下单操作 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明
31、无 流程图： 图40 代下订单流程图（编号FC051） 3.2.5.2 订单查询 图41订单查询用例图（编号UC052） 用例阐明： 用例框架 框架阐明 用例名称 订单查询 重要参加者 销售代表 简要阐明 销售代表可以对所属客户订单状况进行查询和跟踪。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.5.3 订单记录与分析 图42订单记录与分析用例图（编号UC053） 用例阐明： 用例框架 框架阐明 用例名称 订单记录与分析
32、 重要参加者 销售经理、销售代表 简要阐明 销售代表可以对指定期间段内自己销售状况进行记录，并分析出与预定目的完毕比例。 销售经理可以对本部门指定期间段内各个销售代表业绩和部门销售总额进行记录分析，为销售经理下步工作提供指引。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 3.2.6 合同管理模块 3.2.6.1 合同管理 图43合同管理用例图（编号UC061） 用例阐明： 用例框架 框架阐明 用例名称 合同管理 重要参加者 销售总监、销售经理、销售代表
33、 简要阐明 销售代表对于已经拟定销售订单，创立销售合同。经销售经理、销售总监等审核并与客户订立后，进行履行程序，依照执行状况，更改合同状态，如“已订立”、“已审核”、“已履行”、“已变更”、“已解除”、“已转让”、“已终结”、“已归档”等。“已归档”状态合同不能进行修改。 销售代表可以对自己所销售所有合同进行查阅和跟踪。 销售经理可以对本部门所销售所有合同进行查阅和跟踪。 销售总监可以对所销售所有合同进行查阅和跟踪。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无 流程图： 图44 合同
34、管理流程图（编号FC060） 状态图： 图45 合同管理状态图（编号SD060） 3.2.7 记录分析模块 3.2.7.1 客户构成记录 图46客户构成记录取例图（编号UC071） 用例阐明： 用例框架 框架阐明 用例名称 客户构成记录 重要参加者 销售总监、销售经理 简要阐明 通过对公司既有客户数据分析，得出客户区域分布、类型构成、所占比例等分析成果数据，供销售总监和销售经理查阅，指引下步工作更有效开展。 事件流 前置条件 1、系统中存在一定数量有购买行为客户信息及其订单数据 2、使用者需要登录并具备该功能权限 后置条件 无
35、 非功能需求 无 扩展点 无 优先级 2 阐明 无 记录数据要素阐明： 客户构成记录详细信息应涉及：客户类型、客户来源、区域分布、所属行业等属性。查看详情时，按以上属性分别生成饼状图，可以直观展示出客户群特性。 3.2.7.2 客户流失记录 图47客户流失记录取例图（编号UC072） 用例阐明： 用例框架 框架阐明 用例名称 客户流失记录 重要参加者 销售总监、销售经理 简要阐明 依照时间查看不同月份客户流失状况记录。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级
36、 2 阐明 无 记录数据要素阐明： 客户流失记录详细信息应涉及：服务代表、客户类型、客户来源、区域分布、所属行业等属性。查看详情时，按以上属性分别生成饼状图，可以直观展示出流失客户群特性。 3.2.7.3 客户贡献记录 图48客户贡献记录取例图（编号UC073） 用例阐明： 用例框架 框架阐明 用例名称 客户贡献记录 重要参加者 销售总监、销售经理 简要阐明 查询指定期间段内不同类型客户数量及消费总金额记录状况，理解不同客户对公司贡献。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点
37、 无 优先级 2 阐明 无 记录数据要素阐明： 客户贡献记录详细信息应涉及：客户类型、客户来源、区域分布、所属行业等属性。查看详情时，按以上属性分别生成饼状图，可以直观展示出流失客户群特性。 3.2.7.4 客户服务记录 图49客户服务记录取例图（编号UC074） 用例阐明： 用例框架 框架阐明 用例名称 客户服务记录 重要参加者 销售总监、销售经理 简要阐明 依照时间和服务类型对服务进行记录分析。 事件流 前置条件 登录后并具备该操作权限 后置条件 无 非功能需求 无 扩展点 无 优先级 2 阐明 无
38、 记录数据要素阐明： 客户服务记录详细信息应涉及：服务类型、客户类型、客户来源、区域分布、所属行业等属性。查看详情时，按以上属性分别生成饼状图，可以直观展示出流失客户群特性。 4 非功能性需求 在这一某些应对所有软件需求进行足够详细描述。详尽限度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试筹划和编写测试用例为准。 4.1 技术需求 4.1.1 软硬件环境需求 硬件需求：web Server DBServer1(write) DBServerR1(read) DBServerR2(read) 共3台服务器。服务器配备如下： CPU：4核或8核
39、 内存：8-16G 硬盘：500G 远程控制卡 软件需求： 带宽：10M或者100M Java运营环境：JDK1.5以上 WebApplicationServer：Tomcat1.6以上 DataBase：Mysql5.0以上 Memcache Nginx1.4.2 （稳定版） 4.1.2 产品性能 系统需满足如下性能： 1、 最大并发顾客数100人/次 2、 最大同步在线人数500人/次 3、 最大同步提交事务人数20人/次 4、 高峰时期系统响应时间3~5秒 4.1.3 安全性 系统需满足国家保密部门
40、规定分级保护中机密级信息系统设计有关规定，并采用必要技术手段从应用开发层面保证数据安全。 4.2 质量需求 4.2.1 可靠性 系统具备大量数据记录汇总和查询分析规定，因而，必要保证数据汇总、记录、查询分析更精确有效。系统必要具备较强可靠运营设计，可应对单点故障。保证数据安全，涉及数据级备份与劫难性恢复。 4.2.2 灵活性 系统要采用先进技术，保证可灵活地按照不同方式组织其内部模块，从而适应不同网络规模、不同个性化需求和不同组织模式。 4.2.3 兼容性 系统必要具备高度可扩展性，可以在规模、功能、性能三个方面进行扩展，以适应应用和技术发展需要，特别是对省（区、市）应用
41、系统及其她纪检监察业务系统扩展。系统必要开发维护中心，使整个系统管理维护工作量以及开销较小，并提供完备运营管理解决方案，涉及性能、安全、记录、配备管理等。 4.2.4 易用性 须保证系统易用性。详细可以通过如下方式保障系统易用性： 1) 通过提供统一信息门户，使各种渠道信息以便接入，并提供一致渠道服务手段。 2) 针对不同类型顾客设计集成顾客界面，保证顾客可以以便快捷使用自己需要惯用功能。 3) 遵循统一界面设计规范，在应用程序编码阶段监督编码人员认真执行规范，以做到：界面风格一致、颜色调和、提示清晰、窗口大小恰当，提供惯用快捷操作键，操作办法应符合寻常习惯。 4.3 文档需求
42、 4.3.1 文档清单 交付验收时需交付文档清单： 《需求规格阐明书》 《软件开发筹划》 《概要设计阐明书》 《详细设计阐明书》 《软件测试筹划》 《测试用例》 《配备管理筹划》 4.3.2 顾客手册 4.4 设计约束 详细阐明对系统设计局限性。设计局限定义代表了对系统规定决策，这也许出于商务运作、资金、人员、时间等多方面综合考虑从而指引软件设计和开发。例如，软件开发语言、开发环境、开发工具、第三方软件、硬件使用以及网络设备等。 4.4.1 语言约束 本系统是基于中文系统环境开发和使用，系统必要支持中文解决。 4.4.2 系统模型约束 本系统采用MVC模型，在保证明现技术简朴易维护基本上，实现体现层和业务逻辑层分离，提高可重用性、可移植性。 5 验收原则 XXX客户关系管理系统验收原则为： Ø 实现所有功能需求 Ø 满足非功能性需求 Ø 系统设计文档完整，且符合规范 Ø 代码符合规范，且与系统设计一致 此规定将作为验收测试筹划和测试基线。如果所开发产品能满足此规定，则项目可结束并由客户方按合同规定付款。
©2010-2026 宁波自信网络信息技术有限公司 版权所有
客服电话：0574-28810668 投诉电话：18658249818
浙ICP备2021020529号-1 | 浙B2-20240490
关注我们 ：
