项目验收文档模板
最近接手公司的一个需要项目，我最主要的工作便是编写整理项目文档。以前除了上大学交论文的时候写过什么概要设计、详细设计，工作以来还没写过这些东西。
请教项目经理、上网查资料发现这些文档还真没有统一的格式，千奇百怪，这就愁坏了我这样的新手，虽说有GB
T-8567-2006标准，但是这也不是模板，故在自己不断总结摸索中，总结出了一些文档格式，希望对大家有所帮助。
先来说说一个项目的文档都包括什么：
-
需求规格说明书
需求规格说明书是对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。
有的为了更严谨还会有需求调研报告等文档，咱们这里讨论主要也是必须的文档。 -
项目开发计划
项目开发计划为软件项目实施方案制定出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。项目开发计划应提供给管理部门，并作为开发阶段评审的参考。
-
建设方案
该文档根据需求分析说明书，对系统建设整理出总体流程及系统总体编码规范等，为设计人员、编程人员及测试人员工作的基础。
-
概要设计说明书
该说明书是概要设计阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。
-
详细设计说明书
编制目的是说明一个软件系统各个层次中的每一个程序 （每个模块或子程序）的设计考虑，着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
-
测试计划
为做好组装测试和确认测试，需为如何组织测试制定实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
-
测试用例
项目测试用例设计，是为项目编制的测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足需求。
-
测试报告
测试工作完成以后，应提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论意见。
-
用户操作手册
该手册详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。
-
系统安装部署手册
顾名思义，就是项目软件及软件环境、数据库等相关软件的安装及部署手册，详细描述安装步骤。
-
培训方案
培训方案是从组织的战略出发，在全面、客观的培训需求分析基础上做出的对培训内容、培训时间、培训地点、培训者、培训对象、培训方式和培训费用等的预先系统设定。
说完了文档包括哪些，下面来说说文档书写模板。
需求规格说明书
1引言
1.1编写目的
1.2适用范围
1.3术语和缩写
1.4参考资料
2项目概述
2.1项目背景
2.2建设目标
2.3项目遵循的标准或规范
2.4用户特征
3系统功能需求
3.1系统总体功能
3.2组织结构图
3.3系统角色
3.4主要功能流程图
3.5系统功能详情
4外部接口需求
4.1用户接口
4.2硬件接口
4.3软件接口
4.4通信接口
5系统数据需求
5.1数据内容
5.2数据的逻辑描述
5.2.1静态数据
5.2.2动态输入数据
5.2.3动态输出数据
5.2.4内部生成数据
5.2.5数据约定
5.3数据的采集
5.3.1要求和范围
5.3.2输入的承担者
5.3.3预处理
5.3.4影响
6系统非功能需求
6.1用户界面需求
6.2软件环境需求
6.3硬件环境需求
6.4网络需求
6.5安全设施需求
6.6产品质量需求
6.7故障处理需求
项目开发计划
1引言
1.1编写目的
1.2项目背景
1.3术语与缩略语
1.4参考资料
1.5标准、条件和约定
2项目概述
2.1工作内容
2.2主要参加人员
2.3产品及成果
2.3.1程序
2.3.2文件
2.3.3服务
2.3.4非移交产品
2.4验收标准
2.4.1代码的验收
2.4.2文档验收
2.4.3服务验收
2.5完成项目最迟期限
3实施总计划
3.1开发过程
3.1.1需求分析
3.1.2系统设计
3.1.3编码及测试阶段
3.1.4文档、产品部署
3.1.5项目总结
3.2工作任务分解
3.3接口人员
3.4进度
3.5关键问题
4支持条件
4.1计算机系统支持
4.2需要用户承担的工作
4.3需由外单位提供的条件
5专题计划要点
5.1培训计划
5.2测试计划
5.3质量保证计划
5.4安全保密计划
5.5合同计划
注：其中内容可根据具体情况酌情删减。
接着来说建设方案、概要设计以及详细设计的书写模板。
建设方案
1引言
1.1编写目的
1.2项目背景
1.3术语定义
1.4参考资料
2系统环境建设
2.1系统运行环境
2.2系统数据库
2.3系统开发语言
3系统总体设计
3.1系统概述
3.2系统建设需求
3.3系统建设目标
3.4限制和约束
3.5设计原则和设计要求
3.6标准化体系
3.7关键技术分析与技术路线
3.8系统总体架构
3.9网络性能
3.10系统安全
4系统功能设计
5数据库设计
6安全保障体系建设
6.1系统安全原则
6.2系统安全机制
6.3应用系统安全
6.4数据安全及备份恢复
6.5主机安全
6.6网络安全
6.7物理安全
6.8安全管理体系
7系统出错处理设计
7.1出错信息
7.2出错处理对策
7.3出错信息与处理对策表
7.4补救措施
8系统维护设计
8.1应用系统的本地化和升级
8.2数据的本地化维护
8.3功能的本地化维护
8.4系统升级
8.5代码的可维护性
8.5.1代码的规范性
8.5.2代码的可测试性
8.5.3系统运行日志
8.5.4程序文档
9项目管理
9.1项目沟通机制
9.1.1沟通与汇报
9.1.2项目沟通制度
9.1.3问题解决流程
9.1.4项目变更管理
9.2项目实施难点、风险分析和应对策略
9.2.1基础设施与运行环境风险
9.2.2项目沟通与协调风险
10项目进度计划
10.1进度目标
10.2阶段划分
11质量保证措施
11.1质量保障目标
11.2质量保障方法
11.2.1按照ISO/CMMI
质量管理体系进行软件控制
11.2.2开发过程保障
11.2.2.1需求分析
11.2.2.2系统实现
11.2.2.3质量评审
11.2.2.4系统测试
概要设计说明书
1引言
1.1编写目的
1.2项目背景
1.3术语定义
1.4参考资料
2系统概述
2.1项目简介
2.2系统目标
3设计依据和约束
3.1系统开发环境
3.2系统运行环境
3.3设计约束
3.4设计目标
4系统架构设计
4.1总体架构
4.2组织结构图
4.3主要功能流程图
5界面总体设计
5.1界面设计思路
5.2界面设计原则
5.3界面总体结构
6功能模块设计
7数据库设计
7.1数据库选择
7.2数据库设计原则
7.3数据库设计规范
7.4逻辑表结构设计
8接口设计
8.1接口设计方法
8.2面向对象设计中接口设计的一般原则
9系统出错处理设计
9.1出错信息
9.2出错处理对策
9.3出错信息与处理对策表
9.4补救措施
10系统安全性设计
10.1系统安全原则
10.2系统安全机制
10.3应用系统安全
10.4数据安全及备份恢复
10.5主机安全
10.6网络安全
10.7物理安全
10.8安全管理制度
10.9安全管理机构
10.10人员安全管理
11系统维护设计
11.1应用系统的本地化和升级
11.2数据的本地化维护
11.3功能的本地化维护
11.4系统升级
11.5代码的可维护性
11.5.1代码的规范性
11.5.2代码的可测试性
11.5.3系统运行日志
11.5.4程序文档
12系统运行设计
12.1运行控制
12.2运行时间
详细设计说明书
1引言
1.1编写目的
1.2背景
1.3定义与缩略语
1.4参考资料
2程序系统的结构
2.1系统总体架构
2.2系统功能模块图
3系统详细设计
4数据库设计
4.1数据库选择
4.2数据库设计规范
4.3概念结构设计
4.4逻辑表结构设计
4.5数据库安全
5系统建设的关键技术
6开发规范
介绍测试相关文档的书写模板，主要包括测试计划、测试用例、测试报告。测试用例是根据具体项目的功能编写出来的，我们这里不做讨论，需文档书写者根据实际情况编写。
测试计划
1引言
1.1目标
1.2项目简介
1.3项目背景
1.4测试范围
1.5术语与缩略语
1.6参考资料
2测试概要
2.1测试环境与配置
2.2测试工具
2.3测试数据
2.4放行准则
2.5缺陷与纠错管理
3测试策略
3.1测试过程
3.2测试类型
3.2.1功能测试
3.2.2性能测试
3.2.3用户界面测试
3.2.4集成测试
3.2.5负载测试
3.2.6可靠性测试
4测试安排
4.1测试人员
4.2进度安排
5测试内容
5.1功能测试
5.2性能测试
5.3流程测试
6测试风险、优先级
测试报告
1引言
1.1编写目的
1.2项目背景
1.3术语与缩略语
1.4参考资料
2测试概要
2.1放行准则
2.2测试用例设计方法
2.2.1等价类划分法
2.2.2边界值分析法
2.2.3错误推测法
2.2.4因果图法
2.3测试工具
2.4测试环境与配置
2.5测试类型
2.5.1功能测试
2.5.2性能测试
2.5.3用户界面测试
2.5.4集成测试
2.5.5负载测试
2.6测试过程
3测试执行情况
3.1测试组织
3.2实际进度
4测试结果
5测试总结
5.1用例统计
5.2测试结论
介绍用户操作手册、安装部署手册、培训方案的书写模板。
用户操纵手册
1引言
1.1编写目的
1.2项目背景
1.3术语与缩略语
1.4参考资料
2系统概述
2.1系统目标
2.2系统功能
2.3系统性能
3运行环境
4使用说明
系统安装部署手册
1引言
1.1编写目的
1.2项目背景
1.3术语与缩略语
1.4参考资料
2系统配置
2.1系统环境
2.1.1网络环境
2.1.2运行环境
2.2系统部署结构图
3软件环境部署
3.1服务器安装
3.3数据库安装
3.5项目程序部署
3.6系统部署确认
4备份
4.1备份应用程序
4.2数据库数据备份
5回退操作
培训方案
1引言
1.1文档简介
1.2编写目的
1.3目标读者
2总体计划
2.1培训前提
2.2培训目标
2.3培训人员
2.4培训内容
2.5培训时间
2.6培训地点
至此，文档模板介绍就告一段落了，当然上述文档并不是软件项目验收的所有文档，我只是列出了一些比较常见的，毕竟文档需要根据项目的实际情况来决定，另一方面文档也取决于软件项目监理验收的要求和标准，但文档一定是遵循国家标准（GB T-8567-2006标准）的。希望大家在看完我的文章后，有所启发。
|
案卷号 |
|
|
日期 |
|
＜项目名称＞
软件需求说明书
作 者：
完成日期：
签 收 人：
签收日期：
修改情况记录：
|
版本号 |
修改批准人 |
修改人 |
安装日期 |
签收人 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目录
1 引言 1
1.1 编写目的 1
1.2 范围 1
1.3 定义 1
1.4 参考资料 1
2 项目概述 2
2.1 产品描述 2
2.2 产品功能 2
2.3 用户特点 2
2.4 一般约束 2
2.5 假设和依据 3
3 具体需求 3
3.1 功能需求 3
3.1.1 功能需求1 3
3.1.2 功能需求2 4
3.1.n 功能需求n 5
3.2 外部接口需求 5
3.2.1 用户接口 5
3.2.2 硬件接口 5
3.2.3 软件接口 5
3.2.4 通信接口 6
3.3 性能需求 6
3.4 设计约束 6
3.4.1 其他标准的约束 6
3.4.2 硬件的限制 7
3.5 属性 7
3.5.1 可用性 7
3.5.2 安全性 7
3.5.3 可维护性 7
3.5.4 可转移 ＼转换性 8
3.5.5 警告 8
3.6 其他需求 8
3.6.1 数据库 8
3.6.2 操作 8
3.6.3 场合适应性需求 9
4 附录 9
1 引言
1.1 编写目的
说明编写这份软件需求说明书的目的，指出预期的读者范围。
1.2 范围
说明：
a． 待开发的软件系统的名称；
b． 说明软件将干什么，如果需要的话，还要说明软件产品不干什么；
c． 描述所说明的软件的应用。应当 ：
1） 尽可能精确地描述所有相关的利益、目的、以及最终目标。
2） 如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
1.3 定义
列出本文件中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 项目概述
2.1 产品描述
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2 产品功能
本条是为将要完成的软件功能提供一个摘要。例如，对于一个记帐程序来说，需求说明可以用这部分来描述：客房帐目维护、客房财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。
有时，如果存在较高层次的规格说明时，则功能摘要可从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意：
a． 编制功能的一种方法是制作功能表，以便客房或者第一次读这个文件的人都可以理解；
b． 用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。
2.3 用户特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
2.4 一般约束
本条对设计系统时限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括：
a． 管理方针；
b． 硬件的限制；
c． 与其他应用间的接口；
d． 并行操作；
e． 审查功能；
f． 控制功能；
g． 所需的高级语言；
h． 通信协议；
i． 应用的临界点；
j． 安全和保密方面的考虑。
2.5 假设和依据
本条列出影响需求说明中陈述的需求的每一个因素。这些因此不是软件的设计约束，但是它们的改变可能影响到需求说明中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，需求说明就要进行相应的改变。
3 具体需求
3.1 功能需求
3.1.1 功能需求1
对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成：
a． 引言
描述的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能意图的由来和背景。
b． 输入
1) 详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）；
2) 操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整；
3) 指明引用接口说明或接口控制文件的参考资料。
c． 加工
定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明：
1) 输入数据的有效性检查；
2) 操作的顺序，包括事件的时间设定；
3) 响应，例如，溢出、通信故障、错误处理等；
4) 受操作影响的参数；
5) 降级运行的要求；
6) 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；
7) 输出数据的有效性检查。
d． 输出
1) 详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
2) 有关接口说明或接口控制文件的参考资料。
此外，对着重于输入输出行为的系统来说，需求说明应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。
3.1.2 功能需求2
．．．．．．
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用户接口
提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：
a． 对屏幕格式的要求；
b． 报表或菜单的页面打印格式和内容；
c． 输入输出的相对时间；
d． 程序功能键的可用性。
3.2.2 硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
3.2.3 软件接口
在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或数学软件包），以及同其他应用系统之间的接口。对每一个所需的软件产品，要提供如下内容：
a． 名字；
b． 助记符；
c． 规格说明号；
d． 版本号；
e． 来源。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
3.2.4 通信接口
指定各种通信接口。例如，局部网络的协议等等。
3.3 性能需求
从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。
A． 静态数值需求可能包括：
1) 支持的终端数；
2) 支持并行操作的用户数；
3) 处理的文卷和记录数；
4) 表和文卷的大小。
B． 动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。
所有这些需求都必须用可以度量的术语来叙述。例如，95％的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。
3.4 设计约束
设计约束受其他标准、硬件限制等方面的影响。
3.4.1 其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如：
a． 报表格式；
b． 数据命名；
c． 财务处理；
d． 审计追踪，等等。
3.4.2 硬件的限制
本项包括在各种硬件约束下运行的软件要求，例如，应该包括：
a． 硬件配置的特点（接口数，指令系统等）；
b． 内存储器和辅助存储器的容量。
3.5 属性
在软件的需求之中有若干个属性，以下指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。
3.5.1 可用性
可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个确定的可用性级别。
3.5.2 安全性
指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括：
a． 利用可靠的密码技术；
b． 掌握特定的记录或历史数据集；
c． 给不同的模块分配不同的功能；
d． 限定一个程序中某些区域的通信；
e． 计算临界值的检查和。
3.5.3 可维护性
规定若干需求以确保软件是可维护的。例如：
a． 软件模块所需要的特殊的耦合矩阵；
b． 为微型装置指定特殊的数据＼程序分割要求。
3.5.4 可转移 ＼转换性
规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束等等。
3.5.5 警告
指定所需属性十分重要，它使得人们能用规定的方法去进行客观的验证。
3.6 其他需求
根据软件和用户组织的特性等，某些需求放在下面各项中描述。
3.6.1 数据库
本项对作为产品的一部分进行开发的数据库规定一些需求，它们可能包括：
a． 在功能需求中标识的信息类别；
b． 使用的频率；
c． 存取能力；
d． 数据元素和文卷描述符；
e． 数据元素、记录和文卷的关系；
f． 静态和动态的组织；
g． 数据保存要求。
注：如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。
3.6.2 操作
这里说明用户要求的常规的和特殊的操作。
A． 在用户组织之中各种方式的操作。例如，用户初始化操作；
B． 交互作用操作的周期和无人操作的周期；
C． 数据处理运行功能；
D． 后援和恢复操作。
注：这里的内容有时是用户接口的一部分。
3.6.3 场合适应性需求
这里包括：
a． 对给定场合或相关任务或操作方式的任何数据或初始化顺序的需求进行定义。例如，栅值，安全界限等等。
b． 指出场合或相关任务为特点，这里可以被修改以使软件适合特殊配制的要求。
4 附录
对一个实际的需求规格说明来说，若有必要应该编写附录。附录中可能包括：
a． 输入输出格式样本，成本分析研究的描述或用户调查结果；
b． 有助于理解需求说明的背景信息；
c． 软件所解决问题的描述；
d． 用户历史、背景、经历和操作特点；
e． 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善；
f． 特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。
注：当包括附录时，需求说明必须明确地说明附录是不是需求要考虑的部分。
|
案卷号 |
|
|
日期 |
|
＜XX项目＞
概要设计说明书
作 者：
完成日期：
签 收 人：
签收日期：
修改情况记录：
|
版本号 |
修改批准人 |
修改人 |
安装日期 |
签收人 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目录
1 引言 1
1.1 编写目的 1
1.2 范围 1
1.3 定义 1
1.4 参考资料 1
2 总体设计 1
2.1 需求规定 1
2.2 运行环境 2
2.3 基本设计概念和处理流程 2
2.4 结构 2
2.5 功能需求与程序的关系 2
2.6 人工处理过程 2
2.7 尚未解决的问题 3
3 接口设计 3
3.1 用户接口 3
3.2 外部接口 3
3.3 内部接口 3
4 运行设计 3
4.1 运行模块组合 3
4.2 运行控制 3
4.3 运行时间 4
5 系统数据结构设计 4
5.1 逻辑结构设计要点 4
5.2 物理结构设计要点 4
5.3 数据结构与程序的关系 4
6 系统出错处理设计 5
6.1 出错信息 5
6.2 补救措施 5
6.3 系统维护设计 5
1 引言
1.1 编写目的
服务于XX集团网络化运营，管理销售中的各个环节，最终用户为XX集团销售公司,销售办事处和集团领导。
1.2 范围
说明：
a． 待开发的软件系统的名称；
b． 列出本项目的任务提出者、开发者、用户以及将运行该项软件的单位。
1.3 定义
列出本文件中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 总体设计
2.1 需求规定
说明对本系统的主要的输入输出项目、处理的功能性能要求，详细的说明可参见《需求分析说明书》。
2.2 运行环境
简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定，详细说明参见《需求分析说明书》。
2.3 基本设计概念和处理流程
说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
2.4 结构
用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。
2.5 功能需求与程序的关系
本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系：
|
|
程序1 |
程序2 |
．．．．．． |
程序m |
|
功能需求1 |
√ |
|
|
|
|
功能需求2 |
|
√ |
|
|
|
．．．．．． |
|
|
|
|
|
功能需求n |
|
√ |
|
√ |
2.6 人工处理过程
说明在本软件系统的工作过程中不得不包含的人工处理过程（如果有的话）。
2.7 尚未解决的问题
说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
3 接口设计
3.1 用户接口
说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。
3.2 外部接口
说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。
3.3 内部接口
说明本系统之内的各个系统元素之间的接口的安排。
4 运行设计
4.1 运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。
4.2 运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
4.3 运行时间
说明每种运行模块组合将占用各种资源的时间。
5 系统数据结构设计
5.1 逻辑结构设计要点
给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
5.2 物理结构设计要点
给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。
5.3 数据结构与程序的关系
说明各个数据结构与访问这些数据结构的各个程序之间的对应关系，可采用如下的矩阵图的形式：
|
|
程序1 |
程序2 |
．．．．．． |
程序m |
|
数据结构1 |
√ |
|
|
|
|
数据结构2 |
|
√ |
|
|
|
．．．．．． |
|
|
|
|
|
数据结构n |
|
√ |
|
√ |
6 系统出错处理设计
6.1 出错信息
用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。
6.2 补救措施
说明故障出现后可能采取的变通措施，包括：
a． 后备技术：说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；
b． 降效技术：说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；
c． 恢复及再启动技术：说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6.3 系统维护设计
说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。
Confidential
(秘密)
XXXX需求规格说明书
需求规格说明书
|
文档标识： |
TW_PROC_RM_301 |
当前版本： |
1.0 | ||||||
|
当前状态： |
草稿 |
ü |
发布日期： |
| |||||
|
发布 |
| ||||||||
|
修改历史 | |||||||||
|
日期 |
版本 |
作者 |
修改内容 |
评审号 |
变更控制号 | ||||
|
2009/4/14 |
1.0 |
蒋赛华 |
新建 |
|
| ||||
|
|
|
|
|
|
| ||||
|
|
|
|
|
|
| ||||
|
|
|
|
|
|
| ||||
|
|
|
|
|
|
| ||||
|
|
|
|
|
|
| ||||
目 录
1 前言
1.1 编写目的
[说明编写这份需求规格说明书的目的，指出预期的读者（一般包括评审人员、软件设计人员、软件开发人员，针对具体情况，还可能包括客户），它是软件开发的基础。]
1. 准确全面定义、阐述甘肃移动门户网站系统的业务需求，明确甘肃移动门户网站系统的目标和功能。
2. 为甘肃移动的有关业务部门和技术部门提供对这个系统的统一的文字的理解。为业务部门判断系统是否满足其业务需要提供文字依据，为技术部门监督项目功能提供统一标准。
3. 在甘肃移动门户网站系统之前尽可能周密考虑全部需求及设计要求，减少以后可能的重新设计、重新编码、重新测试等工作。
4. 为设计项目方案、编制计划进度提供文字依据。
5. 为对项目的完成进行确认和验证提供基准。
本需求规格说明书合法读者对象为：软件开发项目管理者、设计师、测试工程师、甘肃移动管理人员、技术人员、业务人员。
1.2 文档约定
[描述编写文档时所采用的字体标准或排版约定，包括标题和正文的字体和字号约定。完成文档编写后，文档编写完成后本部分须裁剪]
字体大小约定：
标题1 宋体 三号 加粗
标题2 宋体 小三号加粗
标题3 宋体 四号加粗
标题4 宋体 小四号加粗
标题5 宋体 小四号
正文 宋体 五号
段落约定：文章中每段落需抬头，即段落开头需有两字元的缩排，单倍行距。
表与图编号约定：文中所有表、图须按章节编号，如：第四章节第二个表，编号为：表4-2。
裁剪约定：如标注可裁剪提示信息，表示该部分内容可以裁剪或删除。
1.3 读者对象
[描述本需求规格说明书的主要读者。建议将不同读者的阅读重点与建议以列表方式表现，如下表：]
|
读者对象 |
阅读重点与建议 |
|
网站建设主管领导 |
仔细阅读编写目的、项目概述、系统功能。 |
|
甘肃移动管理人员、技术人员、业务人员和系统管理员 |
仔细阅读项目概述、功能性需求、非功能性需求。 各个部门可重点阅读与本部门相关的内容。 |
|
需求评审人员 |
仔细阅读全部内容。 |
|
系统设计人员 |
仔细阅读全部内容。 |
|
系统开发人员 |
仔细阅读全部内容。 |
|
质量管理人员 |
仔细阅读全部内容。 |
|
系统测试人员 |
仔细阅读文档约定，系统功能介绍和维度指标说明。 |
|
…… |
…… |
1.4 术语和缩略词
[在此列出本文中用到的专门术语的术语定义，英文缩写的原词组的解释，以便读者可以正确地解释和理解软件需求规格说明。]
|
术语/英文缩写 |
术语/英文全称 |
解释与描述 |
|
BSS |
Business Supporting System |
业务支持系统 |
|
SSO |
single sign-on |
单点登录，即用户登录后不需要再次提供认证信息就可以访问相关各应用系统。 |
|
|
|
|
|
|
|
|
1.5 参考文档
[可简单罗列编写本文档时所参考的其他资料或文档，如：行业标准和规范。也可用表格方式列出这些文件资料的标题和来源。]
|
编号 |
文档、资料名称 |
来源 |
备注 |
|
1 |
《中国移动通信门户网站业务规范V1》 |
集团公司 |
由中国移动集团公司发布 |
|
2 |
《门户网站业务技术规范.doc》 |
集团公司 |
由中国移动集团公司发布 |
|
3 |
《本地化需求》 |
甘肃移动 |
由甘肃移动发布 |
|
4 |
《甘肃移动门户网站系统规范书》 |
甘肃移动 |
由甘肃移动发布 |
2 项目概述
2.1 项目背景
[描述项目产生的背景，包括：
1. 产生该项目需求的原因或起源，如社会背景、市场发展、政策趋势、原有系统局限性、存在问题等方面。
2. 列出此项目的任务提出者、开发者
3. 软件项目的用途、软件项目的范围
4. 需开发的软件系统的名称，英文缩写（可选），项目编号（可选）]
中国移动通信集团公司（简称“中国移动通信”）于2000年4月20日成立，注册资本为518亿元人民币，资产规模超过4000亿元。中国移动通信集团公司全资拥有中国移动（香港）集团有限公司，由其控股的中国移动有限公司在国内31个省（自治区、直辖市）设立全资子公司，并在香港和纽约上市。目前，中国移动有限公司是我国在境外上市公司中市值最大的公司之一，也是亚洲市值最大的电信运营公司。
随着经济全球化趋势和中国加入WTO，中国电信市场的政府管制力度越来越弱，市场更加开放，竞争更加激烈。国内外市场环境要求国内的公众电信运营企业在经营理念、管理模式上能有较高层次的飞跃，以求在电信运营商的国际化竞争中立于不败之地。
在互联网络高速发展的今天，网站正成为公司、企业、政府及团体进行形象展示、信息发布、业务拓展、客户服务、内部沟通的重要阵地，她不但具有快捷、无距离及随时随地均可更新的特性，更能提供一些互动性的功能，如留言板、会员制、讨论区等等，使得网站充满生气，让人倍感亲切。传统媒体就这一点是无法与之相比拟的，可以说网站的快捷、无距离及互动性是其在媒体中脱颖而出的主要因素。
中国移动通信集团甘肃有限公司是中国移动有限公司的全资子公司，公司5000多名在职员工，拥有雄厚的移动通信建设和维护技术力量。经过十几年的探索和努力，甘肃移动以惊人的建设速度成就了甘肃地区最大的移动通信网络，覆盖已通达全市各个角落，而移动通信的网络容量超过300万户，同时网络质量优良。
为进一步统一甘肃移动业务品牌，整合网络营销渠道，提升个人客户服务质量，拓展集团客户服务领域，甘肃移动需要建设统一的外部门户网站。
2.2 项目目标
[描述项目建设的目标，即简要叙述该项目要达到的要求。例如：应用目标、作用范围，简述该软件系统能给用户的受益。]
2.2.1 总体目标（长期）
中国移动门户网站的总体目标是通过整合集团内所有网站系统资源，逐步建立集团公司和省公司二级网站的架构，实现服务、业务和品牌的三类整合，达到有效整合门户网站资源，提升门户地位、市场营销能力、客户服务能力和运营管理能力的目的，逐步建立线上线下相结合的中国移动网上客户服务和市场营销体系，使网站建设成为中国移动客户服务、市场营销和公司对外宣传的核心渠道。
一、提升门户地位，重组业务资源。
构建完整的两级门户体系，提升门户功能及性能；通过门户实现互联网资源的有机整合和统筹管理；在两级门户上实现业务平台汇聚，确立门户地位。
二、提升市场营销能力
成为新业务营销推广的主要界面，缩短营销路径，降低营销成本；成为新业务发布、展示和体验的最佳途径；充分挖掘互联网技术优势，发展各类依托互联网的营销手段。
三、提升客户服务能力
拓展服务方式，降低服务成本，培养客户自助务意识；提升客户体验，简化操作，实现跨平台和系统的单点登录、统一认证或鉴权；规范新业务客户服务，满足服务界面的一体化和客户体验的一致性的要求。
四、提升运营管理能力
整合并规范业务流程和资源，实现业务运营的集中管控，降低运营成本；拓展门户服务对象，提升业务功能部署管理能力，提升整体运作效率；适应生产力发展趋势，优化组织结构，提高企业内部协同能力。
2.2.2 中期目标（3-5年达到）
中国移动门户网站的中期目标是通过逐步完善网站支撑系统，整合网站信息资源，完善网站的运营机制，实现网站对线下客户服务和市场营销的支持，最大程度的资源共享，并逐步在网站上实现互动社区、电子商务等功能。
中国移动门户网站的中期目标是通过逐步完善网站支撑系统，整合网站信息资源，完善网站的运营机制，实现网站对线下客户服务和市场营销的支持，最大程度的资源共享，并逐步在网站上实现互动社区、电子商务等功能。
一、实现网上业务办理与市场业务拓展同步
网上客户服务能紧跟市场业务的拓展，及时实现新业务的网上查询和办理。
二、基于互联网平台支撑，向其他渠道的客户服务延伸
延伸基于互联网技术的网上客服功能到其他客服终端，例如：设置在营业厅、商场、社区等公共场所的自助服务终端，以及为大客户经理上门服务提供有效的支撑等。
三、建立统一的信息资源规划，实现高度的资源共享
对于除各省公司新闻以外的通信行业新闻、手机仿真、通信技术、手机天地、全网业务等具有全集团共性的新闻、信息和业务介绍等内容，由集团公司统一制作，各省公司根据各自特色统一选择使用。
实现集团内网站的高度资源共享，并与线下资源融合互动。开展互联网层面的业务整合，统一全网推广业务的解释口径及分类标准。
四、拓展网站业务，逐步实现互动社区和电子商务
根据互联网业务特性，适时开展互动社区、网上短信等具有客户粘性的互联网业务。同时，根据市场业务和网上客服的发展情况，选择不同业务项目，分期逐步实现电子商务。
2.2.3 近期目标（2007年底）
近期网站的主要任务是整合中国移动通信集团网站资源，在全国范围内各省公司网站实现统一网站规划，统一业务管理，统一鉴权认证，统一网站风格，整合信息结构，实现全网信息共享。
一、统一网站规划和整合
架构以客户为导向的两级网站信息结构，融合集团、省（市）公司的服务和营销信息，实现中国移动多网站在界面和系统上的融合。
统一规划网站的栏目结构，对网站的栏目结构进行全面的整合，建立完整的三大客户品牌专区、集团客户专区和城市频道。
明确集团网站与省公司网站定位，理顺两级网站之间的承接关系，统一规划建设国际漫游、手机终端、卡类、集团客户等网上专区，以门户网站为核心，分步对移动梦网、短信回执、PIM、飞信、彩铃、手机报等产品网站进行风格、内容和认证系统的整合。
各省公司在现有基础上，近期实现互联网界面的资源整合，将地市公司专区整合到省公司网站，将业务或品牌网站整合成为省公司网站结构下的栏目或专区，使省公司网站真正成为本省公司互联网界面的统一入口。
二、统一业务管理，规范网站运营相关管理办法和制度
明确集团、省（市）二级网站业务管理职能，制定和明确网站业务管理和信息维护流程。
制定网站内容发布、网站页面与风格设计规范、网站运营数据的统计和考核等管理办法和制度。
三、统一鉴权认证
建设跨多业务平台的统一认证平台，统一认证鉴权，先期完成chinamobile内的两级统一，最终实现所有业务平台的统一认证鉴权。
规范域名管理，开展中国移动多网站系统和业务整合。
四、全面统一网站风格
在目前集团公司与各省公司网站风格基本保持统一的基础上，对网站的整体风格（视觉元素、信息结构）进行修改与整合，全面提升网站协同统一的整体能力。由集团公司制定统一的网站设计风格，各省公司网站本着核心相同，个性发展的原则，在保持和集团风格统一的前提下，可以适当的发展各自个性化的内容。
五、完善网上服务营销的支撑功能
在现有基础上，加强各省的生产运营系统对网上服务与营销的高效支撑、有效扩展，保证网上客服功能的正常使用和有序发展。
加强网站的应用功能和系统功能的建设。提升网站的可用性、稳定性、安全性和黏性，探索开户、网上交费、终端销售等商务功能。
六、深化网站信息统计分析，完善定期分析和上报制度。
深化网站信息统计分析，完善定期分析和上报制度，为网站工作的改进和发展提供有效依据。
七、建立网上信息共享机制
建立网站信息共享机制，在集团公司和各省公司及各省公司之间实现有效的资源共享和交流。同时，还可以考虑实现网站与其它电子渠道和实体渠道之间的信息和资源的共享和交流。
2.3 需求范围
[对项目的需求范围进行整体性的描述。]
结合近期目标中国移动甘肃分公司门户网站建设的内容主要包括以下几个方面：
1、 业务宣传方面：进行移动业务的宣传，对移动的品牌进行介绍和宣传，宣传企业形象，扩大企业在社会上的影响力，因而进行移动品牌/产品、最新动态、城市频道、手机天地、关于甘肃移动等栏目的建设。
2、 客户服务方面：为用户提供一站式的服务，因则进行统一认证、个人（集团）用户营业厅、信息搜索、网上调查、客户服务（包括投诉与知识库）等功能建设。
3、 信息共享方面：构建企业内沟通的渠道，可以借助企业门户网站改善企业内部员工之间的信息交流；提供与集团相关信息的共享与全网业务的应用、提供活动栏目及其内容的管理。
4、 门户管理方面：为优化门户网站的易维护性及安全性，因而进行网站后台的运营管理、证书管理、会话管理、统计报表的生成、展现管理、信息采集与发布管理、内容管理、模版管理等功能的建设，同时进行相关业务平台的数据与认证整合。
5、 新业务方面：为客户提供新业务介绍、内容管理及其功能开通，用户开通后可直接享受该业务的功能服务，例如天气预报、手机报等。建立新业务推广和介绍模块，例如手机导航等。
6、 个性化方面：为个人与集团用户提供信息个性化业务应用的功能；建设统一基于规则的授权，建立用户的个性化频道。
2.4 总体框架
[用VISIO工具画图，以图的方式显示系统的内部模块和模块之间关系以及系统与外部系统的关系。]
门户网站的系统架构为三层架构，分为展现层、应用层和服务层。如下图所示：
图4 门户网站的系统架构
展现层提供门户网站的内容展示、页面集成。以品牌专区、业务专区和主题栏目的形式 进行统一展现（统一用户界面、统一页面风格模版）。
应用层是门户网站内的业务处理逻辑平台，它通过对服务层的调用实现不同的业务应 用，满足不同的业务需求，这些业务应用具有自己独立的业务逻辑和数据逻辑。业务应用通 过展现层进行页面展现。
服务层提供门户网站的基础服务，包括统一认证、安全服务、内容管理、展现管理、系 统管理和业务平台整合服务。统一认证和安全服务提供对门户网站的安全能力的支撑，包括： 统一认证中心实现用户认证和单点登录；对证书的统一管理。内容管理对网站展现内容进行 统一管理。展现管理为门户网站的展现风格、样式提供统一配置与管理。业务平台整合通过
URL 链接、Iframe、Web Clipping、Portlet、WSRP、Web Service 等方式，实现各业务平台 与门户网站在展示层面上的集成整合。
现有 BOSS 提供对门户网站的业务功能和用户身份认证的支撑，业务功能支撑包括BOSS对个人客户网上营业厅和集团客户网上营业厅的后台支撑，用户身份认证以 BOSS 内的用户号码和服务密码为唯一的认证数据来源。
示例二：下面是物资管理系统的系统架构图：
物资管理系统架构图
2.5 组织机构
[用VISIO工具画图，以图的方式表现客户方（系统使用相关角色）的组织机构。可裁剪]
示例一：甘肃移动组织机构
目前，公司下设18个职能部室、3个直属中心，14个市、州分公司和72个县（市、区）公司。（因为缺图，所以用示例二说明组织机构）
示例二：湖南烟草专卖局组织机构
2.6 用户特点
[列出本软件的最终可能用户，操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计的重要约束。]
2.7 设计约束
[描述设计开发系统时的限制，例如经费限制、开发期限、实现的语言和平台约束等等。描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。]
网站设计必须遵循《中国移动通信门户网站业务规范》
网站设计必须遵循《门户网站业务技术规范》
网站设计必须遵循《中国移动通信门户网站页面模版子规范》；
网站设计必须遵循《甘肃移动门户网站系统规范书》
3 功能性需求
3.1 总体流程
[ 用VISIO工具画图，以图的方式显示系统的内部模块之间的业务关系。此部分可以更加项目实际情况进行裁剪。]
示例：（云南移动12580语音搜索系统）
业务流程图
3.2 角色定义
[按照不同的使用对象，紧密围绕使用对象的工作范围、工作性质和工作内容，进行角色分类描述。]
示例：
本规范按照不同的使用对象，紧密围绕使用对象的工作范围、工作性质和工作内容，具体角色描述如下：
系统管理员：一般为甘肃移动门户网站管理人员，主要工作是对网站的用户管理、权限管理等方面的相关管理。
维护人员：一般为甘肃移动门户网站维护人员，主要工作是对网站的内容、数据等方面的维护。
分析人员：为甘肃移动门户网站相关数据统计和分析的工作人员，为营销等部门提供相关数据。
移动用户：主要为中国移动的在网用户，通过登录与认证后，可使用网站提供的相关服务功能。
……
就以上角色描述和可能的对应工作岗位列表如下：
[对使用系统的人员进行角色分类，并进行详细的定义与说明。]
|
角色名称 |
角色定义与说明 |
|
系统管理员 |
门户网站的管理员 |
|
维护人员 |
门户网站的维护人员 |
|
分析人员 |
门户网站的分析人员 |
|
移动用户 |
中国移动用户 |
3.3 系统功能
[概述系统所具有的主要功能，可以用VISIO画图的形式展示，建议有功能列表，列出功能分类，以及优先级，并加入必要文字说明。]
示例一：（情况特殊，采用的移动规范）
|
一级栏目 |
二级栏目 |
三级栏目 |
四级栏目 |
实现方式 |
|
网上营业厅 |
话费服务 |
话费查询 |
当月话费查询、当月详单查询、历史详单查询、交费历史查询、账户余额 |
具体业务流程规范参见“网上营业厅部分” |
|
定制话费信息 |
定制纸质账单邮寄、定制短信账单、定制EMAIL账单、定制EMAIL详单、定制短信余额提醒 | |||
|
网上交费 |
| |||
|
业务办理 |
新业务推荐 |
飞信、中国手机报等 |
具体业务流程规范参见“网上营业厅部分” | |
|
业务办理 |
基本业务、新业务专区、无线音乐专区 | |||
|
套餐的办理与变更 |
| |||
|
梦网业务查询与退订 |
| |||
|
其它业务办理 |
网上选号、备卡激活、停/开机 | |||
|
积分计划 |
积分规则 |
|
具体业务流程规范另文下发。 | |
|
积分查询 | ||||
|
短消息服务 |
自写短信 |
|
具体业务流程规范参见“网上营业厅部分” | |
|
短信设置 | ||||
|
在线客服 |
客户信息查询 |
客户品牌及资费、手机归属地查询、PUK码查询、手机仿真、营业厅导航 |
具体业务流程规范参见“网上营业厅部分” | |
|
客服受理 |
客户投诉/建议 | |||
|
个人信息管理 |
个人资料修改 |
|
具体业务流程规范参见“网上营业厅部分” | |
|
客服密码修改 | ||||
|
套餐使用状态 | ||||
|
业务开通状态 |
示例二：（办公自动化烟站管理系统）
|
模块 名称 |
功能名称 |
需求功能 |
标识符 |
优先级 |
描述 |
|
烟叶生产预安排 |
省烟叶预安排 |
制定并提交生产预安排 |
SRS_省烟叶预安排_01 |
1 |
|
|
审核生产预安排（省局烟叶处长） |
SRS_省烟叶预安排_02 |
| |||
|
审核生产预安排并下发预安排任务（省局烟叶局长） |
SRS_省烟叶预安排_03 |
| |||
|
督办下级工作并反馈信息 |
SRS_省烟叶预安排_04 |
| |||
|
查看审批意见及生产预安排内容 |
SRS_省烟叶预安排_05 |
| |||
|
市生产预安排启动 |
接收省任务并下达市生产预安排 |
SRS_市生产预安排启动_01 |
| ||
|
审核市生产预安排 |
SRS_市生产预安排启动_02 |
| |||
|
查看审批意见及生产预安排内容 |
SRS_市生产预安排启动_03 |
| |||
|
市生产预安排 |
接收生产预安排任务 |
SRS_市生产预安排_01 |
| ||
|
制订市生产预安排并提交审核 |
SRS_市生产预安排_02 |
| |||
|
督办下级工作并反馈信息 |
SRS_市生产预安排_03 |
| |||
|
查看审批意见及生产预安排内容 |
SRS_市生产预安排_04 |
| |||
|
县生产预安排启动 |
接收市任务并下达县生产预安排 |
SRS_县生产预安排启动_01 |
| ||
|
审核市生产预安排 |
SRS_县生产预安排启动_02 |
| |||
|
查看审批意见及生产预安排内容 |
SRS_县生产预安排启动_03 |
| |||
|
县生产预安排 |
接收生产预安排任务 |
SRS_县生产预安排_01 |
| ||
|
制订县生产预安排并提交审核 |
SRS_县生产预安排_02 |
| |||
|
督办下级工作并反馈信息 |
SRS_县生产预安排_03 |
| |||
|
查看审批意见及生产预安排内容 |
SRS_县生产预安排_04 |
| |||
|
生产预安排到村组（烟站） |
接收生产预安排任务 |
SRS_生产预安排到村组_01 |
| ||
|
制订生产预安排到村组并提交反馈 |
SRS_生产预安排到村组_02 |
| |||
|
烟叶计划管理 |
省公司烟叶生产计划 |
制定省烟叶生产计划 |
SRS_省公司烟叶生产计划_01 |
2 |
|
|
审核省烟叶生产计划 |
SRS_省公司烟叶生产计划_02 |
| |||
|
督办省烟叶生产计划 |
SRS_省公司烟叶生产计划_03 |
| |||
|
传阅省烟叶生产计划 |
SRS_省公司烟叶生产计划_04 |
| |||
|
市公司烟叶生产计划 |
启动市烟叶生产计划 |
SRS_市公司烟叶生产计划_01 |
| ||
|
制定市烟叶生产计划 |
SRS_市公司烟叶生产计划_02 |
| |||
|
审核市烟叶生产计划 |
SRS_市公司烟叶生产计划_03 |
| |||
|
督办市烟叶生产计划 |
SRS_市公司烟叶生产计划_04 |
| |||
|
传阅市烟叶生产计划 |
SRS_市公司烟叶生产计划_05 |
| |||
|
县公司烟叶生产计划 |
启动县烟叶生产计划 |
SRS_县公司烟叶生产计划_01 |
| ||
|
制定县烟叶生产计划 |
SRS_县公司烟叶生产计划_02 |
| |||
|
审核县烟叶生产计划 |
SRS_县公司烟叶生产计划_03 |
| |||
|
督办县烟叶生产计划 |
SRS_县公司烟叶生产计划_04 |
| |||
|
传阅县烟叶生产计划 |
SRS_县公司烟叶生产计划_05 |
| |||
|
烟站公司烟叶生产计划 |
烟站公司烟叶生产计划 |
SRS_烟站公司烟叶生产计划_01 |
| ||
|
合同管理 |
启动合同签订任务 |
SRS_合同管理_01 |
| ||
|
审核烟农合同信息 |
SRS_合同管理_02 |
| |||
|
站长工作成果确认 |
SRS_合同管理_03 |
| |||
|
接收合同任务要求 |
SRS_合同管理_04 |
| |||
|
烟农合同签订 |
SRS_合同管理_05 |
|
优先级：1－5 数字越小，优先级别越高
3.4 功能描述
3.4.1 网上营业厅—话费服务
3.4.1.1 业务流程
[ 用VISIO工具画图，以图的方式显示模块内的业务流程。本部分可以进行裁剪。]
3.4.1.2 用例图
[用ROSE工具画用例图，用来鉴别和划分系统功能。它把系统分成角色和用例。角色表示与系统交互以实现某种目的的人、硬件或软件系统 。]
示例：
3.4.1.3 月账单查询
3.4.1.3.1 功能描述
[这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景，一般以一个段落说明。]
查询上月已出帐月帐单，或前五个月的出帐帐单。
1. 客户通过网上营业厅密码认证后，查询帐单。
2. 月帐单格式见有限公司话费信息规范。
3. 查询结果通过网站页面展示给客户，并可让客户选择是否发短信到手机上(参照短
信营业厅的用户短信格式，避免跟短信营业厅冲突)。
4. 对所有查询的操作可提供日志记录。
3.4.1.3.2 使用角色描述
[此处描述哪些角色使用此功能，可同时说明操作本功能的相关权限]
使用角色为中国移动用户，只有登陆用户具备月账单查询权限，查询结果只读，不可修改。
3.4.1.3.3 业务操作流程
[描述正常业务流程，列举异常情况和处理流程。建议使用图示，并配合必要的文字说明。如无需或没有操作流程说明则注明‘无’或‘略’。]
如果没有登陆首先输入‘用户手机号码’和‘服务密码’进行登陆操作，登陆用户从下拉选择框选择需要查询的月份，点击‘查询’按钮查询所选定月份的话费信息。
3.4.1.3.4 输入
[提供所有与本功能有关的输入描述，包括：输入数据类型、媒体、格式、有效数值范围、精度、单位等，如果有界面原型此项可以进行裁剪。]
数据输入：用户手机号码，服务密码，查询月份。
3.4.1.3.5 输出
[提供与本功能有关所有输出的描述，包括：输出数据类型、方式、格式、精度、单位等，以及图形或显示报告的描述，如果有界面原型此项可以进行裁剪。]
数据输出：客户姓名、手机号码、话费帐期、查询日期及用户帐单信息，详见用户界面。
3.4.1.3.6 用户界面
[如有条件插入界面原型，否则注明‘无’或‘略’。原型设计采用Axure工具]
3.4.1.3.7 约束与约定
[描述本功能需求的相关约束或约定，可裁剪。]
2、要求在30秒内反馈查询结果，超过30秒没有处理结果要求系统发送告知信息，在网站页面上展示（如“系统忙，请稍后再试”）。
3.4.1.4 详单查询
3.4.1.4.1 业务定义/功能描述
[这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景，一般以一个段落说明。]
根据客户的手机号码和时间段等信息，提供客户指定的时间段内通话清单的详细资料。根据甘肃移动的情况，详单查询采取5+1的模式，即用户可以查询当前月与最近5个月的详单情况
1. 客户通过网上营业厅密码认证后，查询详单。
2. 提示客户输入查询的详细账单的起始时间和终止时间。
3. 查询结果通过网站页面展示给客户。
4. 对所有查询的操作可提供日志记录。
3.4.1.4.2 使用角色描述
[此处描述哪些角色使用此功能，可同时说明操作本功能的相关权限]
使用角色为中国移动用户，只有登陆用户具备详单查询权限，查询结果只读，不可修改。
3.4.1.4.3 业务操作流程
[描述正常业务流程，列举异常情况和处理流程。建议使用图示，并配合必要的文字说明。如无需或没有操作流程说明则注明‘无’或‘略’。]
选择需要查询的详单类型，输入或选择账单周期，点击‘确定’进行详单查询。
3.4.1.4.4 输入
[提供所有与本功能有关的输入描述，包括：输入数据类型、媒体、格式、有效数值范围、精度、单位等，如果有界面原型此项可以进行裁剪。]
数据输入：用户手机号码，服务密码，详单类型、查询时间（开始日期、结束日期）
3.4.1.4.5 输出
[提供与本功能有关所有输出的描述，包括：输出数据类型、方式、格式、精度、单位等，以及图形或显示报告的描述，如果有界面原型此项可以进行裁剪。]
数据输出：见用户界面。
3.4.1.4.6 用户界面
[如有条件插入界面原型，否则注明‘无’或‘略’。原型设计采用Axure工具]
3.4.1.4.7 约束与约定
[描述本功能需求的相关约束或约定，可裁剪。]
约束：1、支持本月查询和最近5个月的详单查询。
2、要求在30秒内反馈查询结果，超过30秒没有处理结果要求系统发送告知信息，在网站页面上展示（如“系统忙，请稍后再试”）。
3.4.1.5 功能点N
3.4.1.5.1 业务定义/功能描述
[这部分描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景，一般以一个段落说明。]
3.4.1.5.2 使用角色描述
[此处描述哪些角色使用此功能，可同时说明操作本功能的相关权限]
3.4.1.5.3 业务操作流程
[描述正常业务流程，列举异常情况和处理流程。建议使用图示，并配合必要的文字说明。如无需或没有操作流程说明则注明‘无’或‘略’。]
3.4.1.5.4 输入
[提供所有与本功能有关的输入描述，包括：输入数据类型、媒体、格式、有效数值范围、精度、单位等，如果有界面原型此项可以进行裁剪。]
3.4.1.5.5 输出
[提供与本功能有关所有输出的描述，包括：输出数据类型、方式、格式、精度、单位等，以及图形或显示报告的描述，如果有界面原型此项可以进行裁剪。]
3.4.1.5.6 用户界面
[如有条件插入界面原型，否则注明‘无’或‘略’。原型设计采用Axure工具]
3.4.1.5.7 约束与约定
[描述本功能需求的相关约束或约定，可裁剪。]
例如：只有持有管理员密码的用户才能执行￥100.00或更大金额的退款操作。
4 非功能性需求
[在本节中主要描述项目所包含的非功能性方面的需求，主要包括软件需求和硬件需求。]
4.1 软件需求
(1)应用软件应采用面向对象的分析、设计方法。
(2)应用软件应采用模块化的方式实现软件的重构和组装。
(3)应用软件应具有较强的灵活性，以便在今后业务需要时，可简单、迅速方便地实现
等。
(4)应用软件应具备一定的可扩充性，能不断满足对系统功能的需求。
(5)整个应用软件系统要能够连续7*24小时不间断工作，应用软件按功能模块划分，在
其中任一模块更新、加载时，在不更新与上下模块的接口的前提下，应不影响其它模块
的运行。
(6)应用软件应注重操作上的方便性、维护上的简便性。
(7)应用软件应具备相应容错手段，能容许操作人员的某些误操作。
(8)应用软件应提供与门户网站交易网站相关系统的接口。
(9)传输大量数据的双方系统均应支持高速大数据量传输，并对被中断的传输数据进行
断点续传及纠错，保障数据的准确传送。
(1)应用软件功能应至少满足中国移动关于企业信息化系统相关规范和甘肃移动应用需
求。
(2可根据自身经验和甘肃移动实际情况增加一定功能。
4.1.1 界面需求
[说明系统界面方面的需求；没有则注明‘无’或‘略’。]
为执行中国移动通信公司对集团公司网站和各省市公司网站的统一管理，形成统一的客户界面风格，通过对网站视觉元素、设计样式、模版结构、网页优化要求的规范及完善，从而提供统一的视觉设计，页面结构与制作规范的标准给各移动省市网站维护人员参照使用，以保证所有省市的中国移动网站都在统一的标准下予以建设和维护。为满足中国移动各级网站保持统一客户界面的要求，确保在互联网渠道创建更为友好一致的企业形象，因此界面需求要严格按照《中国移动通信门户网站页面模版子规范V1.0》。
4.1.2 性能要求
[说明系统整体性能需求，包括并发处理能力以及单事务响应时间等指标，甚至更多性能要求指标，如：数据精度、时间特性、容错性、可扩展性以及系统有效性等等。]
门户网站系统支持100万用户使用，同时支持2000用户的在线访问操作；
(1)网站访问性能：每天100万次用户点击，高峰时每秒200次的网站点击；每秒处理
的连接处理数为300；
(2) 后台处理性能：详单调取速度小于20秒
(3) 系统存储性能：按100万用户的数据存储量配置
（1）静态页面响应时间 ≤2秒；
（2）密码登录响应及完成时间 ≤5秒；
（3）查询功能响应时间及完成时间 ≤5秒；
（4）业务办理功能响应及完成时间 ≤5秒；
4.1.3 容量要求
[说明系统整体容量，包括系统需要满足的用户规模以及对存储空间的要求等；没有则注明‘无’或‘略’。]
目前甘肃手机注册用户数为420万，通话用户数大约370万，网站用户数大约为100万用户。预计每个网站用户平均每月登陆网站10次，每次登陆进行业务业务办理和查询次数为5笔，网站总的业务办理和查询量预计可达到50,000,000笔/月。
用户每次办理业务记录日志的平均大小为4K，月业务办理量＝50,000,000笔/月
每月日志量＝业务办理量×日志平均字节数
＝50,000,000×4KB＝200GB
如保存半年的数据，则：
数据总量＝200*6=1200GB
考虑存储系统容量增加30%的冗余
则数据存储容量＝1200GBx（1+30%）＝1560GB
4.1.4 数据安全
4.1.4.1 数据保护/保密
[对需要保护或保密的敏感性、局限性等方面的数据进行需求描述；没有则注明‘无’或‘略’。]
4.1.4.2 数据加密
[描述关于在访问或传输过程中的数据加密方面的需求；没有则注明‘无’或‘略’。]
为保证数据传输过程中的安全，应考虑在数据传输过程中增加对数据传输的加密。实现数据传输不被非法复制、修改。可采用技术如SSL、IPSec-VPN等。
4.1.5 数据备份/恢复
[对数据备份与数据恢复的需求进行描述；没有则注明‘无’或‘略’。]
系统应具有完备的数据备份功能，备份系统应能够与存储系统的有效结合。备份系统应支持全备份、增量备份、差异备份等多种备份策略，支持LAN、LAN-Free和Server-Less备份方式。备份系统能够保证数据的一致性，备份数据的可恢复性，对必要系统的可提供实时备份功能。
存储系统应有良好的备份策略和恢复计划。系统数据和业务数据可联机备份、联机恢复，恢复的数据必须保持其完整性和一致性。
4.2 硬件需求
4.2.0.1 主机系统
[描述主机方面的需求；]
(1) 本工程主机设备主要包括门户网站所需的各种功能服务器，开发商应根据门户网站业务量的大小和应用软件的需要等因素设置主机设备的数量，对于业务量较大的应用功能应配置单独的服务器主机，业务量较小的若干种应用功能可以合设一套/一台主机设备。
(2) 主机设备应具有较强的扩充能力，包括系统处理能力的扩充、存储容量的扩充及I/O能力的扩充、节点数的扩充等。服务器设备还应支持CPU的板级升级和节点的平滑扩充。
(3) 开发商应根据各服务器的业务处理能力需求，计算出各种服务器硬件系统的性能指标（如TPMC值等），详细说明计算方法及结果，并提供服务器完整的软硬件配置结构（包括主要设备配置情况和配套选项部分设备等）。
(1) 采用64位UNIX操作系统，并可兼容以往的32位应用系统；
(2) 多机群集系统中的每个主机都应同时处于工作状态，并根据配置的情况运行相同或者不同的应用（或应用模块），保证主机资源的充分利用；
(3) 在计算机硬件、操作系统、存储系统及应用系统业务进程出现故障时，能迅速响应并进行应用的切换；集群系统中，某一台计算机出现故障时，应不影响系统的应用及响应能力；
(4) 主机的处理能力要求满足所有业务的应用和一定客户规模的需求，而且需考虑全部系统的开销及应用切换时性能余量；
(5) 内存容量的配置要考虑到主机正常运行状态下的内存利用率不应大于70%，保证系统在业务高峰时仍具有较强的抗冲击能力；
(6) 主机应支持100/1000Mb/s等高速连接接入系统核心局域网；
(7) 主机的硬盘、网络接口、网络连接及电源均应考虑足够的冗余；
(8) 支持电源、I/O设备、存储设备的热插拔；
(9) 主机系统平均无故障时间应大于8000小时。
应分别就其建议的每一种服务器产品，针对以下技术指标项目进行详细阐述：
(1) 32位以上CPU，说明其介质类型。
(2) 支持多CPU结构，支持平滑升级，给出支持的最多CPU数量。
(3) CPU Cache：给出Cache值。
(4) 节点性能：提供单节点处理能力的各种性能指标参数，如TPC—C。
(5) 支持高可用性计算集群，详细描述实现方案并说明所支持的软件系统。
(6) 系统总线带宽(bit)
(7) 系统总线速率(Mbps)
(8) 系统内存(MB)，说明最大可扩充容量
(9) 内置硬盘，说明最大可扩充容量
(10) CD-ROM或DVD，支持的接口类型，倍速率
(11) 说明提供各种I/O接口的数量、速率及类型
(12) 主控显示器支持图形显示或字符终端，支持中文
(13) 根据实际需要支持多种局域网接入方式
(14) 网络协议支持TCP/IP、IPX等多种协议
(15) 系统可靠性：给出MTBF值(小时)
(16) 采用UNIX操作系统或其变种，支持中文内码，符合中国关于中文字符集定义的有关国家标准。要求完整运行同一操作系统下的产品线，提供可靠技术支持和系统管理的解决方案。
(17) 提供完整的服务器系统及相关软件，包含相应的管理、开发工具。开发商应在建议书中给出详细的相关技术资料，及其它软件的清单和说明。
4.2.0.2 操作系统
[描述操作系统方面的需求；]
采用64位UNIX操作系统，并可兼容以往的32位应用系统；
4.2.0.3 数据库
[描述数据库方面的需求；]
数据库系统基本技术要求如下，应对以下要求给出本产品满足的技术指标：
l 支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准；
l 支持中文汉字内码，符合双字节编码；
l 数据库系统应具有良好的扩展能力；
l 支持主流的网络协议；
l 具有良好的开放性，支持异种数据库的互访：
l 实现对文件数据和桌面数据库数据的访问；
l 实现对大型异种数据库的访问；
l 能够将原有异种数据库向本数据库无损失移植；
l 实现和高级语言互联的能力；
l 支持XA、ODBC 3.0、X/OpenCLI、JDBC等标准。
l 具有支持并行处理所需的技术；
l 支持网络上同构或异构数据库之间数据的相互访问；
l 支持C2或以上级安全标准、多级安全控制；
l 支持数据库存储加密；
l 提供Web访问服务；
l 支持联机存储和备份功能；
l 应具有强的容错能力、错误恢复能力、错误记录及预警能力；
l 数据库、表大小等技术参数可灵活设置，支持对多媒体数据及大数据量处理的技术需求；
l 应避免数据库死锁的出现，一旦死锁能够自动解锁；
l 开发工具易使用、开发效率高、维护方便；
l 支持多种CASE工具。
4.2.0.4 存储设备
[描述存储设备方面的需求；]
(1)本工程存储设备主要包括磁盘阵列和磁带库设备，磁盘阵列主要提供门户网站数据的联机存储，磁带库主要提供门户网站数据的脱机存储。
(2)应针对选用的设备，提出完整的存储与备份解决方案，应给出系统存储容量需求，同时详细给出测算依据。
(1)磁盘阵列设备要求具有很高的安全可靠性，请详细说明其实现方案；
(2)磁盘阵列可与多种厂家的主机系统相连；
(3)磁盘阵列应能配合多机高可用群集系统的需要；
(4)磁盘阵列采用ULTRA SCSI 接口或FC-AL接口，支持RAID 0、1、0+1、3、5，并可提供多通道、双电源及冗余风扇；
(5)磁盘阵列设备应具有较强的平滑扩充能力，包括系统的处理能力、存储容量的扩充及I/O能力的扩充等；
(6)磁盘阵列应支持先进的存储、备份方式，例如支持存储区域网（SAN）技术等；
(7)磁盘阵列可支持热插拔功能。
(8)应对其建议的磁盘阵列产品针对以下指标项目进行详细阐述：
l 可支持磁盘驱动器的种类、数量及技术指标
l MemoryCache的容量
l 接口方式
l 磁盘转速
l 可选择的单磁盘容量
l 支持的存储方式
l 详细说明磁盘阵列电源安全保障措施
l 提供一套完整的系统存储管理软件
l 说明磁盘阵列I/O读写速度和总线带宽
l 系统可靠性，说明MTBF具体小时数
(1)磁带库设备要求具有良好的安全可靠性，请详细说明其实现方案。
(2)应对其建议的磁带库产品针对以下技术指标项目进行详细阐述:
l 磁带容量：可根据系统整体容量选择磁带容量，具有磁带压缩功能，要求磁带容量>=20GB
l 传输速率
l 支持多种接口方式
l 磁带读写速度
l 机械手可靠性：其平均无故障时间(小时)
l 磁头可靠性：其平均无故障时间(小时)
l 磁带库可靠性：其平均无故障时间(小时)
l 应用于UNIX操作系统，说明可支持的数据库系统
l 提供一套完整的磁带库管理
l 提供其他与磁带库系统相关的技术指标，如磁带平均搜索时间、记录格式、磁带交换能力、支持磁带驱动器的数量及型号等。
(3)备份设备容量至少是在线存储容量的4倍；
(4)备份设备可与多种厂家的主机系统相连；
(5)磁带库要求支持ULTRA SCSI 或SCSI-2或FWD SCSI或FC-AL接口。大型的磁带库设备要求提供冗余的数据接口和机械手设备；
(6)备份设备应具有较强的平滑扩充能力，包括系统设备容量的扩充及I/O能力的扩充等；
(7)应支持先进的存储、备份方式，例如SAN技术等。
4.2.0.5 网络设备
[描述网络设备方面的需求；]
(1)根据自己设备情况及本工程的网络组织，提出合理的设备配置方案；并针对所采用网络组织和设备配置方案给出门户网站与其它系统互联接入对传输带宽的要求，同时给出计算依据；
(2)网络采用TCP/IP协议，主干网络要求统一采用千兆网标准；
(3)核心交换机采用热旁路路由器协议HSRP协议，实现双机互为备份；
(4)核心交换机提供三层交换能力，同时提供等路径路由，实现负载均衡；
(5)核心局域网划分VLAN，由核心交换机实现网段间路由；
(6)核心交换机及中心路由应采用高可靠的设备，具备背板冗余功能，系统板、关键I/O板、电源、风扇等考虑冗余，并可热插拔；
(7)交换机的配置端口总数应能满足应用和客户规模的要求，并保留约20%的余量；
(8)主干网络设备的端口配置至少保证30%的可扩展能力；主干网络设备要求平均无故障时间应大于1万小时，可用性不小于99.99%；
(9)支持SNMP和SNMPv2协议。
可以采用主机加防火墙软件或专用的防火墙设备，应满足下列要求：
(1)支持动态和静态的内部网与外部网之间的地址转换、映射；
(2)能有效地实现内部网到外部网的单向访问控制，可以禁止外部网对内部网的访问；
(3)能侦测、过滤或跟踪非法访问企图，能自动实时告警，并生成相应日志记录；
(4)能对常用的服务（例如WWW、e-mail、FTP、Telnet、Rlogin等）的访问权限进行有效控制和管理；能对经过防火墙的网络流量进行统计和管理，并定期生成相应报告文件；
(5)具有友好的图形界面；
(6)支持SNMP和SNMPv2协议；
5 外围系统和接口
[在本节中主要描述系统和哪些外围系统进行交互以及交互的接口说明。]
门户网站作为一种重要的电子渠道，与其他系统有着密切的关系。根据接口对端系统的性质，可将门户网站相关的接口分为两大类：与业务支撑网内部系统接口以及与业务平台的接口。
5.1 与业务支撑网内部系统接口
5.1.1 概述
[此处简要描述外围系统基本情况。可裁剪]
门户网站与业务支撑网内部系统之间的接口用于提升服务质量、扩展服务范围、辅助制定市场营销策略、完善服务功能以及对门户网站的监控和管理。主要包括与经营分析系统的接口、与BOMC 系统的接口和与短信营业厅的接口以及与BOSS 核心域的关系。
5.1.2 接口描述
5.1.2.1 与经营分析系统接口
[此处描述接口的方式、接口数据内容，数据转换、数据安全、周期等信息。]
【概述】
门户网站与经营分析系统的接口是双向的，门户网站向经营分析系统传递业务数据，并从经营分析系统获取分析结果数据，从而实现与经营分析系统的互动。
【实现方式】 门户网站与经营分析系统的接口数据主要通过文件方式传递。视数据量大小，可以采取全量抽取或增量抽取的方式，也可以两者结合使用。 该接口需实现以下三个方面要求：
1、传输方式 通过文件传输传送到指定的位置或直接存放到指定的位置。具体要求包括：
u 支持同一主机内对指定设备存储目录位置的文件获取；
u 支持网络模式传输，可以实现跨越局域网络、广域网络、拨号网络等平台的文 件获取，并支持文件重传功能；
u 网络传输方式应支持对通信机的 IP 地址、帐户、口令、存取目录的验证。
2、传输协议 接口应支持以下主流网络协议：FTP、TCP/IP 等。
3、传输过程 数据传输应支持：
u z 实时、高效和安全可靠地传送数据；
u z 断点续传功能；
u z 数据压缩传输；
u z 传输过程中的差错控制。
【业务数据】 客户服务信息：个人客户网上营业厅和集团客户网上营业厅生成的订单/服务请求信息、客户接触相关信息(交互历史、接触记录、菜单轨迹等)等；营销活动信息：营销活动执行情况、营销结果分析、营销效果分析等； 渠道分析信息：用户访问量信息、访问情况分析(时段等)、业务量信息；
5.1.2.2 与BOSS 核心域的关系
[此处描述接口的方式、接口数据内容，数据转换、数据安全、周期等信息。]
门户网站与BOSS 核心域的关系是：门户网站提交用户号码和服务密码给BOSS 核心域，由BOSS 对该用户进行认证，并返回认证结果。BOSS 核心域返回认证成功或失败的信息。BOSS返回的认证结果包括如下几类信息：
l 用户姓名；
l 用户状态信息；
l 用户品牌信息；
门户网站与BOSS 核心域的交互关系是实时的交互关系。
5.2 与其他系统的接口和关系
5.2.1 概述
[此处简要描述外围系统基本情况。可裁剪]
与其它系统的接口和关系是指门户网站与支撑网外部系统的接口、关系的描述。
5.2.2 接口描述
5.2.2.1 与手机邮箱接口
[此处描述接口的方式、接口数据内容，数据转换、数据安全、周期等信息。]
【概述】
手机邮箱是门户网站与用户进行信息联络和沟通的重要渠道。
【接口功能】
1、 门户通过设定的手机邮件服务器地址、端口、协议，将用户门户网站上的业务数据发送到其手机邮箱中；
2、 手机邮件服务器对门户的发送请求进行鉴权，确定是否存在此用户、是否开通此服务、是否通过身份认证；
3、 门户网站与手机邮箱的交互支持非实时的异步交互关系。
【业务数据】
邮箱：邮件来源、邮件主题、邮件内容、邮件附件、邮件服务器地址、端口、协议。
6 其他需求
[对其它需要描述但未在本模板中列出的需求，在此进行说明，没有则注明‘无’或‘略’。]
举例：项目在移动现场进行开发，开发商项目团队必须遵守甘肃移动公司相关管理制度。
7 数据字典
[在本章中主要描述系统的数据字典。主要包括有哪些实体以及实体所包含的数据项，实体关系图使用工具POWERDESIGN或者ERWIN。根据情况可裁剪。]
8 附件
[此处主要是对在需求调研过程中项目甲方提供的原始清单、票据、单据等材料进行罗列]
|
序号 |
附件名称 |
描述 |
|
1 |
话费详单 |
按照甘肃移动提供的标准格式设计话费详单 |
|
2 |
客户投诉单 |
按照甘肃移动提供的标准格式设计客户投诉单 |
|
3 |
客户建议单 |
按照甘肃移动提供的标准格式设计客户建议单 |
|
|
|
|
|
|
|
|
附录 A：需求确认
主要分两步：（1）需求评审，（2）需求承诺。
在获取责任人（Stakeholders）对需求的承诺之前，该《需求规格说明书》必须先通过需求评审。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”。
|
需求评审报告摘要 | |
|
需求文档 |
输入名称，标识符，版本，作者，完成日期，… |
|
需求评审报告 |
输入名称，标识符，评审日期，… |
|
评审结论 |
[ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审 核”。
[√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。
[ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评 审。 |
|
评审意见 |
|
|
评审小组成员 |
输入评审小组成员 |
|
需求承诺 | |
|
需求文档 |
输入名称，标识符，版本，作者，完成日期，… |
|
客户承诺 |
承诺…
签字，日期 |
|
项目经理承诺 |
承诺…
签字，日期 |
-------
学问：纸上得来终觉浅，绝知此事要躬行
为事：工欲善其事，必先利其器。
态度：道阻且长，行则将至；行而不辍，未来可期
.....................................................................
------- 桃之夭夭，灼灼其华。之子于归，宜其室家。 ---------------
------- 桃之夭夭，有蕡其实。之子于归，宜其家室。 ---------------
------- 桃之夭夭，其叶蓁蓁。之子于归，宜其家人。 ---------------
=====================================================================
* 博客文章部分截图及内容来自于学习的书本及相应培训课程以及网络其他博客，仅做学习讨论之用，不做商业用途。
* 如有侵权，马上联系我，我立马删除对应链接。 * @author Alan -liu * @Email no008@foxmail.com
转载请标注出处！ ✧*꧁一品堂.技术学习笔记꧂*✧. ---> https://www.cnblogs.com/ios9/
