客服售后管理系统用户需求说明书模板.docx

客服售后管理系统用户需求说明书模板.docx

《客服售后管理系统用户需求说明书模板.docx》由会员分享，可在线阅读，更多相关《客服售后管理系统用户需求说明书模板.docx（9页珍藏版）》请在冰豆网上搜索。

客服售后管理系统用户需求说明书模板

客服售后管理系统

用户需求说明书

版权声明和保密须知

本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属福建省新泽尔科技有限公司所有，受到有关产权及版权法保护。

任何单位和个人未经福建省新泽尔科技有限公司的书面授权许可，不得复制或引用本文件的任何片断，无论通过电子形式或非电子形式。

ＥＰＧ　文档修改/审批纪录

日期

版本

修订内容

编制人/更改人

批准人

2013-03-30

创建文档，初始化需求文档模板

张明辉

项　目　组　文档修改/审批纪录

日期

版本

修订内容

编制人/更改人

批准人

1引言

1.1目的

『说明编写本文档的目的』

『参考』用户需求说明书主要用来说明本项目应用软件解决用户的哪些业务问题。

主要从业务定义、业务用户解决用户什么问题、解决问题的流程是怎么样的、解决问题过程需要什么也的数据支持、解决问题的输入输出是什么这几个方面去描述用户需求。

1.2适用范围

『说明本用户需求说明书适用于哪个项目、哪些读者』

1.3参考资料

资料名称[标识符]

出版单位

作者

日期

1.4术语和缩略语

术语、缩略语

解释

2系统概述

2.1项目背景

『介绍本项目提出的背景，包括外部环境、客户生产经营环境及变化和公司内部环境变化，因为这些环境变化和需求提出这么一个项目』

2.2项目目标

『采用列表方式明确列出项目目标，包括业务目标、技术目标、进度目标等』

2.3项目范围

『阐述本系统“适用的领域”和“不适用的领域”，本系统“应当包含的内容”和“不应当包含的内容”。

』

2.4系统角色

『阐述本系统的各种角色及其职责。

各种角色的具体行为将在功能性需求中描述。

可以适用UserCase图来表达』

角色名称

职责描述

3功能性需求

增加功能需求总表

『详细描述每一个具体的业务需求，业务需求粒度以能够完整描述一个事情是如何处理或者一个问题是如何解决的为原则，比如完成一次业务受理、完成一次选号』

3.1业务需求1

3.1.1业务说明

标识号

使用频度

高/中/低

执行者

相关用户/角色

优先级

高/中/低

业务定义

『明确说明该业务主要为哪些角色解决什么问题或者提供什么服务』

业务要素

『说明需要完成该业务所需要的数据名称』

3.1.2业务流程

『以流程图或者文字说明业务执行过程，同时说明业务流程启动的条件和退出条件，如果没有流程则只说明进入和退出业务条件』

3.2业务需求2（示例）

3.2.1业务说明

标识号

YSRK-01-02

使用频度

高

执行者

采购人员、仓库保管员

优先级

高

业务定义

物品入库业务提供采购的物品根据采购管理规程完成入库所需要的所有操作。

业务要素

入库单：

仓库、制单日期、编号、供货单位－名称、供货单位－帐号、供货单位－税号、供货单位－开户银行、项目性质、项目编号、项目名称、发票号码、物资类别、物资来源、合同编号、物资编码、物资品名、型号规格、单位、数量、单价、运杂费、金额、税金、价税合计、备注、审核、保管员、计划员、制单。

1、供货单位可以选择并且自动带出帐号、税号、开户行信息；

编号可以自动产生，规则如。

。

。

；

3.2.2业务流程

入库流程图如下：

（略）

1.采购人员根据验收结果（验收单）和发票填制普通入库单并提交至保管员处。

保管员审核入库单并记帐入库。

2.入库时采用加权平均价入库，每次入库时自动计算加权平均价，并更新库存价格。

入库条件：

1、收料时必须是确定有验收结果（验收单）和发票。

入库完成输出：

1.记录普通入库单据相关信息。

2.记帐入库，自动计算库存价格。

4非功能性需求

对非功能性需求进行描述，包括系统性能指标要求、系统运行周期要求、系统用户数、使用频度、系统界面风格等。

以下表格供参考。

需求条款

需求

说明和依赖性

延展性

应支持对数据查询、添加和更新的处理量：

XXXX/天

系统应支持以下的增长指标：

X%的数据资料查询、更新处理量

X%的数据增长量

在未来的XX个月中，随着系统使用系统的增加，系统应支持对数据查询、添加和更新的处理量应增长到XXXXX

应支持灵活的客户属性、产品类型、资费属性的改变和添加

系统应支持所有架构组件的延展性，包括：

:

硬件组件

应用软件组件

系统软件组件

网络组件

可用性

24X7

系统应对所有的外部使用系统提供每年365天，每天24小时的服务

系统应保证对24小时提供服务，系统维护时间应计划在服务的最低峰时间

响应时间

数据查询

系统使用高峰期应对95%的数据交互查询、更新提供3秒或更短响应时间的支持。

系统使用低峰期应对95%的数据交互查询、更新提供2秒或更短响应时间的支持。

数据添加、更新

系统使用高峰期应对95%的数据交互查询、更新提供5秒或更短响应时间的支持。

系统使用低峰期应对95%的数据交互查询、更新提供3秒或更短响应时间的支持。

系统内部应提供对请求处理的来源及响应时间的监控机制

系统响应时间取决于不同外部数据源和使用系统的通讯和接口情况而有差异

可靠性

系统不应在正常操作中丢失数据

当用户正在使用系统，系统不应瘫痪

系统应对所有的外部使用系统提供每年365天，每天24小时，每天3班的系统监控支持，而每月突发的宕机时间不超过4小时。

系统支持人员分三级，所有问题报告给初级系统支持，如不能解决问题转交下一级

易于使用性

系统应有操作、故障排除手册来帮助系统管理人员来快速解决系统问题

系统、管理/操作界面应易于使用，对操作人员的培训时间保持在较短的时间内.

安全性

系统应支持用户识别和单一登录。

系统使用者密码保存应使用行业标准，予以加密保护，和定期更新，使用者密码不应过于简单

系统应支持电子商务和交易相关数据的安全协议

系统帐户应有权限限制，对普通权限用户应避免更改储存的数据

对系统用户的系统使用事件应有记录

系统帐户授予权、使用权限由管理层予以批准，再由系统管理人员给予的申请应报给管理

备份和灾难的及时恢复

系统应每天对所有运作相关的数据做备份

应对数据库中的数据每周以带卡的形式做备份

应有备份的系统，以防止助运行系统瘫痪时能及时使用备份系统保证系统的服务

有相应的系统恢复机制来保证快速重新装建系统操作、应用系统和系统数据

系统硬件资源

数据库的数据量应保持在总储存物理容量的60%以下

系统负荷在系统使用高峰期应在80%以下

对系统负荷、系统资源应有相应的系统监控机制，保证有足够的系统资源来支持运营数据仓储的服务

接口要求

系统的接口应能灵活支持外部使用系统的硬件、操作系统、应用软件升级的顺畅接驳

系统接口应有足够灵活性来容纳因业务需求改变带来的相应改变

系统的接口技术应力求标准化和可跨平台的系统支持来降低投资和维护的成本

接口要求

测试要求

系统测试中需要有测试平台，供测试用的数据部分来自生产数据库的数据，保证测试系统以及以后各版本发放的测试

5接口需求

『简单说明本系统和外部系统的接口及接口主要的信息』

5.1XXXX系统

5.2XXXX系统

6限制性需求

对限制性需求进行描述，包括开发周期、开发工具、硬件要求等方面

项目

详细要求

开发周期

开发工具

……