网上零食管理系统需求规格说明书模板.doc

网上零食管理系统需求规格说明书

35
2020年4月19日
文档仅供参考
项目编号：

文档编号：1.0

密 级：开源

网上零食管理系统需求规格

V1.0

开发人员：王瑞 徐扬

评审日期： 年 月 日

目 录
1 导言 4
1.1 目的 4
1.2 范围 4
1.3 缩写说明 4
1.4 术语定义 4
1.5 引用标准 4
1.6 参考资料 4
1.7 项目组员及模块分配 5
1.8 版本更新信息 5
2 系统定义 6
2.1 项目来源及背景 6
2.2 项目要达到的目标 6
3 应用环境 6
3.1 系统运行网络环境 7
3.2 系统运行硬件环境 7
3.3 系统运行软件环境 8
4 功能规格 8
4.1系统的架构设计 8
4.2 数据库 10
4.3 系统的主的use-case图 12
4.4 系统的功能模块分析 13
4.4.1 用例描述 13
4.4.2 设计决策 21
4.4.2 接口设计 22
4.4.3 处理流程 24
1、确认订单用例(网上零食店_UC_用户系统ID_03) 24
2、商品管理用例(网上零食店_UC_用户系统ID_05) 25
4.4.4 业务逻辑层设计 26
5 性能需求 26
5.1 界面需求 27
5.2 响应时间需求 27
5.3 可靠性需求 27
5.4 开放性需求 28
5.5 可扩展性需求 28
5.6 系统安全性需求 28
6 产品提交 29
7 实现约束 29
8 签字 30

1 导言
1.1 目的
该文档是关于网上零食管理系统前期进行的需求分析，重点描述了网上零食系统的设计需求，将作为对该工具在概要设计阶段的设计输入。
本文档的预期读者是：
l 设计人员
l 开发人员
l 项目管理人员
l 测试人员
l 用户
1.2 范围
该文档是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决整个项目系统“做什么”的问题。在这里，对于开发技术并没有涉及，而主要是经过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。
1.3 缩写说明
JSP: Java Server Page（Java服务器页面）的缩写，一个脚本化的语言。
UML: Unified Modeling Language（统一建模语言）的缩写。
1.4 术语定义
无
1.5 引用标准
[1] 《企业文档格式标准》 V1.1
[2] 《需求规格报告格式标准》 V1.1
1.6 参考资料
[1] 《疯狂Java讲义》 李刚等 电子工业出版社
[2] 《Tomcat与Java Web开发技术详解》封超等 清华大学出版社
[3] 《Java Web开发实战经验》 李兴华等 清华大学出版社
[4] 《数据库开发教程》 清华大学出版社
[5] 《UML和模式应用》 机械工业出版社
[6] 《需求规格报告格式标准》 V1.1
1.7 项目组员及模块分配
王瑞 负责前台设计，包括：
用户登录注册模块
修改信息模块
浏览商品模块
购物车订单模块
留言板模块
徐扬 负责后台设计，包括：
管理员登录模块
食品管理模块
用户信息管理模块
订单管理模块
推送信息模块
1.8 版本更新信息
因为此系统即将成为满足客户需求的实用性系统，因此在开发的过程中需要与客户进行多次的交流以便达到客户的要求，因而在开发过程中就需要进行多次的修改，从而达到理想的阶段，得出最终的1.0版本。
因此在开发时初始计划定义本系统的版本信息，更改如下：
1.0 版本：正式使用版本，用户使用过程中实行跟踪维护服务半年。人员：专业维护人员
1.1 版本：一个简单的、内部自己测试的版本，能够实现一些基本的操作功能，和一些基本的功能特性。人员：王瑞、徐扬
1.2 版本：经过对用户进行详细的调查分析后，小组成员再更新自己的实现模块，完善系统功能，然后添加一些用户所需要的原来版本中缺少的基本功能，进行完善。人员：王瑞、徐扬
1.3 版本：客户根据当前开发出的系统自己实行测试，检测系统功能实现情况，并提出自己的意见，开发人员再根据客户提出的意见进行测试修改，然后开发组自己进行测试，经过再与用户交流进行修改。人员：王瑞、徐扬
1.4 版本：最终版的雏形，最后一次试用版本，先让用户进行试用一段时间，然后在试用期间提出新的问题，开发人员再对新提出的问题进行修改，最终达到客户满意。人员：王瑞、徐扬

2 系统定义
下面分别阐述一下项目的来源、背景和项目的目标。
2.1 项目来源及背景
网上生活是现代快时代生活的主要区域，简单快速的购物方式成为一种主流的趋势。同时伴随着物流领域的不断发展，各种各样的购物网站已成为人们平时浏览和购物的场所，但由于大型购物网站涉及的领域过于广泛，有可能会导致客户搜索不便捷的问题。
网上零食店专门针对零食的销售，更加地全面和便捷，给广大的年轻群体带来了巨大的方便。虽然网上零食销售在中国的兴起时间不长，可是发展迅速，随着中国互联网的普及和网上零食店的日趋成热，会有越来越多的消费群体加入到这个行列，市场潜力会得到充分发挥。
网上零食购物系统不但是传统销售渠道的发展和补充，也是未来食品销售的发展趋势方向，它满足了消费者足不出户买到各地零食的愿望，也便于商家进行商品及收益的管理，给商家带来更大的利润。

2.2 项目要达到的目标
本项目设定的目标如下：
1. 系统能够提供友好的用户界面，使操作人员的工作量最大限度的减少。
2. 系统具有良好的运行效率，能够得到提高生产率的目的。
3. 系统应有良好的可扩充性，能够容易的加入其它系统的应用。
4. 平台的设计具有一定的超前性，灵活性，能够适应企业生产配置的变化。
5. 经过这个项目能够锻炼队伍，提高整个团队成员的开发能力和项目管理能力。
6. 经过此项目的开发，增强开发组成员间的团队合作能力。同时将所学的知识能灵活的运用到实践中，提高小组每个成员的动手能力，以便更好的适应社会对人才的需求发展。还有就是提前用一些企业常见的开发工具以及一些前端流行的技术，以便使小组成员在走向工作岗位时能更好的适应环境的变化，提前进入状态，更好的胜任自己的工作。

3 应用环境
本次项目完成的运行环境是在windows下完成的网上零食店项目。本项目的应用环境能够分硬件环境、软件环境和网络环境来描述。

3.1 系统运行网络环境
本系统的网络运行图如图3-1所示：

图3-1 网络拓扑图

客户经过网络浏览商品、提交客户的购物车信息和联系人地址等相关信息；管理员经过网络发布商品信息，对获得提供的各种信息进行检验，并经过网络处理客户的订单、管理商品的更新维护和用户的信息维护。

3.2 系统运行硬件环境
本系统的硬件环境如下：
l 客户机：普通PC
n CPU：P4 1.8GHz
n 内存：256MB以上
n 分辨率：推荐使用1024*768像素
l WEB服务器
n CPU：P4 1.8GHz
n 内存：256MB以上
l 数据库服务器
n CPU：P4 1.8GHz
n 内存：256MB以上
3.3 系统运行软件环境
l 操作系统：Windows 7
l 数据库：MYSQL
l 开发工具包：JDK 1.7
l 开发工具 eclipse
l JSP服务器：Tomcat 8
l 浏览器：IE9

4 功能规格
采用面向对象的分析方法进行系统建模，使用UML(Unified Modeling Language)作为建模语言。
UML从考虑系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图。这些图从不同的侧面对系统进行描述。系统模型将这些不同的侧面综合成一致的整体，便于系统的分析和构造。
用例图(Use Case)展现了一组用列、参与者(actor)以及她们之间的关系。用例图从用户的角度描述系统的静态使用情况，可用于建立需求模型。
设计Use-case时，我们遵循下列步骤：
第一步：
识别出系统的actor。它能够是用户、外部系统，甚至是外部处理，经过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者是谁。尽可能地确保所有actor都被完全识别出来。
第二步：
描述主要的Use Case。能够采取不断地问自己“这个管理员究竟想经过系统做什么？”来准确地描述Use Case。
第三步：
重新审视每个Use Case，为它们下个详尽的定义。
4.1系统的架构设计
a.系统前台主要分为以下几部分：
网站首页：显示食品，主要为特价和热销的零食。用户在此页能够搜索商品，查看商品分类，注册新账户和登录已有账户等。
用户注册：用户填写基本信息，同时还要填写用户的真实姓名和详细地址，以便购买商品后进行送货。
用户登录：用户未登陆时，能够查看商品，若要加入购物车或购买下单就要进行登录。
我的账户：对账户进行各种操作和管理，包括查看用户基本资料，查看订单，查看积分，查看优惠券，修改用户名、密码或地址等。
商品搜索：用户能够根据需求进行商品的搜索。
购物车：用户将要购买的商品加入购物车后，在确认订单环节进行结算。
以下图4-1是系统的前台构架图。

图4-1 系统前台构架图

b. 系统后台主要分为以下几部分：
管理员登录：系统管理员只有在成功登录后，才能对系统进行操作，比如进行食品、订单、用户的管理，及消息推送。
食品管理：可搜索食品对已有食品进行上下架、对食品信息进行修改和添加新的产品。
用户管理：管理员能够搜索已经注册的用户，对用户信息进行维护。
订单管理：管理员能够查看新加入的订单情况，对其进行处理，也可对以前的订单进行查询。
以下图4-2是系统的后台构架图。

图4-2 系统后台构架图

4.2 数据库
数据库是必要的一个子系统，用来存储用户、零食等的各种数据信息，它是一个能够与主系统产生交互式信息的外部系统。管理员经过对数据库的基本操作实现对系统的数据的查询、增加、删除和修改等操作。
本系统所用的数据库为mysql，以下列出主要的表的设计：

表4-1 用户基本信息表user
字段名称
数据类型
说明
user_id
varchar
主键，不为空
utype_id
varchar
外键，不为空
nike_name
varchar
唯一的，不为空
password
varchar
不为空
email
varchar
不为空
gender
varchar
不为空
balance
numeric
默认0.00，不为空
status
numeric
默认0，不为空
question
varchar
不为空
answer
varchar

表4-2 用户详细信息表user_addr
字段名称
数据类型
说明
user_id
varchar
主键，外键，不为空
real_name
varchar
不为空
country
varchar
不为空
province
varchar
不为空
city
varchar
不为空
detail_addr
varchar
不为空
tel
varchar

mobile_tel
varchar

表4-3 商品基本信息表product_desc
字段名称
数据类型
说明
product_id
varchar
主键，不为空
type_id
varchar
外键，不为空
dType1_id
varchar
外键，不为空
dType2_id
varchar
外键，不为空
pname
varchar
不为空
market_price
numeric
不为空
type
varchar

brand(品牌)
varchar

material
varchar

configure
varchar

product_area
varchar

specs
varchar

product_data
data

availably_data
data

表4-4 订单信息表orders
字段名称
数据类型
说明
order_id
varchar
主键，不为空
user_id
varchar
外键，不为空
voucher_id
varchar
外键
order_price
numeric
不为空
carriage(邮费)
numeric
不为空
pay_quomodo(付款方式)
varchar
不为空
order_data
data
不为空
country
varchar
不为空
province
varchar
不为空
city
varchar
不为空
detail_add
varchar
不为空
consignee(收货人)
varchar
不为空
tel
varchar

mobile_tel
varchar

status
varchar
不为空，默认“等待处理”
consign_area
varchar
不为空，默认“等待发货”

另外，还包括用户等级信息表user_type、用户详细信息表user_addr、商品分类表ptype、商品详细类型表dType1_id与dType2_id、优惠券表voucher、订单明细表order_detail、出库记录表invoice、库存表repertory、管理员信息表admin等等。
4.3 系统的主的use-case图
网上零食店能够分为注册用户和管理员两个主要的actor，还包括游客与支付授权的第三方服务，用例图展示她们与系统之间的交互即系统的主Use Case图如图4-3所示：

图4-3 系统的主use case图

管理员：网上零食店的管理员。可对食品、订单信息和用户信息进行管理和维护。
游客：游客能够进行网站访问和浏览商品，可注册。
注册用户：除了浏览商品外，还能够进行选购、支付、修改自己的信息、留言等。
4.4 系统的功能模块分析
根据系统特点，针对客户和管理员这两个主要的参与者，设计的主要模块的介绍如下：
针对客户：用户注册登录模块、修改信息模块、浏览商品模块、购物车订单模块、留言板模块
针对管理员：管理员登录注册模块、食品管理模块、用户信息管理模块、订单管理模块、推送信息模块。
我们从表4-5中的用例分析该系统。

表4-5系统用例一览
序号
用例名称
用例标识符
需求描述（功能说明）
1
用户注册
网上零食店_UC_用户系统ID_01
为新用户注册一个账号
2
选购商品
网上零食店_UC_用户系统ID_02
用户将需要购买的商品添加到购物车中
3
确认订单
网上零食店_UC_用户系统ID_03
用户从购物车中选择需要确认购买的商品并下单
4
用户管理
网上零食店_UC_管理系统ID_04
管理员管理用户信息
5
商品管理
网上零食店_UC_管理系统ID_05
管理员管理商品信息包括新品上线、商品下架、修改、查询

4.4.1 用例描述
本节详细描述用户系统功能的需求，以及功能的活动图。
a. 用户注册
表4-6 用户注册用例描述
用例标示符：网上零食店_UC_用户系统ID_01
用例名称：用户注册
范围：业务用例
级别：用户目标级别
主要角色：用户
涉众：
—用户：希望在该零食店中注册一个账户，并能迅速完成注册
—管理员：希望获取用户的信息，并能及时进行信息的维护更新
前置条件：用户进入网上零食店主页
后置条件：记录用户的信息，添加进用户数据库中
主成功场景：用户输入ID以及个人密码；
系统识别用户身份的有效性；
系统对用户进行注册识别；
系统显示用户的基本信息；
退出时，系统记录此次的购买信息
扩展（或替代流程）
2a.用户身份检查失败，提示重新输入（3次机会）。
3a.注册识别失败，提示没有注册的用户不能进行选购商品。
4a.基本信息未录入，提示没有录入用户信息，需要进行录入。
特殊需求：
能同时允许 以上人同时进行注册；
系统应具备较强的数据恢复能力；
用户注册期间每2小时数据备份一次
技术和数据变元表：
支持网上注册。
能自动进行注册的信息是否满足要求。

图4-4 用户注册活动图

b.选购商品
表4-7 选购商品用例描述
用例标示符：网上零食店_UC_用户系统ID_02
用例名称：选购商品
范围：业务用例
级别：用户目标级别
主要角色：用户
涉众：
—用户：希望能在该零食店中进行商品浏览以及将选择的商品添加到购物车中，并能向客服咨询相关疑问
—管理员：希望获取用户的购物车记录，并能及时回应用户的请求
前置条件：用户进入网上零食店主页，登录账户
后置条件：记录用户的购物车信息，添加进用户数据库中
主成功场景：
1.用户输入ID以及个人密码；
2.系统识别用户身份的有效性；
3.系统对用户进行注册识别；
4.系统显示用户的基本信息以及购物车信息；
5.退出时，系统记录此次的购买信息
扩展（或替代流程）
2a.用户身份检查失败，提示重新输入（3次机会）。
3a.注册识别失败，提示没有注册的用户不能进行选购商品。
4a.基本信息未录入，提示没有录入用户信息，需要进行录入。
特殊需求：
1.能同时允许 以上人同时进行选购；
2.系统应具备较强的数据恢复能力；
3.用户选购期间每2小时数据备份一次
技术和数据变元表：
1.支持在线购物车服务。

图4-5 选购商品活动图

c.确认订单
表4-8 确认订单用例描述
用例标示符：网上零食店_UC_用户系统ID_03
用例名称：确认订单
范围：业务用例
级别：用户目标级别
主要角色：用户
涉众：
—用户：希望能将购物车中的商品进行选择购买，并能快速完成购买
—管理员：希望获取用户的购买订单，方便及时进行发货确认
前置条件：用户进入网上零食店个人账号的购物车中
后置条件：生成购买订单，添加进用户数据库中
主成功场景：
1.用户选择购物车，系统显示出购物车页面。
2.用户选择删除购买项，系统将该项商品从购物车排除。
3.用户修改购买项商品数量，系统更新购物车中该项商品的数量。
4.用户选择继续购买，系统回到浏览商品界面。
5.用户选择确认订单，系统显示当前购物车中的商品项。
6.用户选择继续，系统提示客户输入送货信息、付款方式、发票信息等。
7.用户选择进入结算中心，系统将当前购物车中的商品项加入新生成的订单中，系统显示付款界面。
8.用户成功付款后，系统清空当前购物车。
扩展（或替代流程）
1a. 如果当前购物车为空，系统提示当前购物车中无商品。
3a. 客户输入的商品数量如果不合法，系统给出提示，不修改该商品项数量。
5a. 当前购物车中无商品，则系统给出提示，并中止确认订单。
6a. 如果用户未登录，则系统进入登录界面，提示客户登录系统。
6b. 输入信息不完整或合法，系统给出提示
7a. 如果选择货到付款方式，则无需进入付款界面
8a. 如果未成功付款，系统给出提示。
特殊需求：
1.能同时允许 以上人同时进行确认订单；
2.系统应具备较强的数据恢复能力；
3.用户选购期间每2小时数据备份一次
技术和数据变元表：
1.支持货到付款，在线付款方式。

图4-6 确认订单活动图

d.用户管理
表4-9 用户管理用例描述
用例标示符：网上零食店_UC_管理系统ID_04
用例名称：用户管理
范围：业务用例
级别：用户目标级别
主要角色：管理员
涉众：
—用户：希望能将个人信息进行完整保存
—管理员：希望获取用户的信息，并能及时进行管理维护
前置条件：管理员进入网上零食店登录个人账号
后置条件：记录用户信息，及时更新用户数据库
主成功场景：
1.管理员输入ID以及个人密码。
2.系统识别管理员身份的有效性。
3.系统显示管理员的信息及权限设置。
4.管理员选择进入用户管理界面，并对用户信息进行维护更新。
5. 退出时，系统保存此次记录。
扩展（或替代流程）
2a.管理员身份检查失败，提示重新输入（3次机会）。
3a.管理员权限识别失败，提示该管理员不具备用户管理的权限。
4a.基本信息未更新，提示没有更新用户信息，需要进行更新。
特殊需求：
1.同一权限的管理员一次只能一人进行信息维护更新；
2.系统应具备较强的数据恢复能力；
3.管理员更新用户信息期间每2小时数据备份一次
技术和数据变元表：
1.能自动进行用户信息检测判断是否满足要求。

图4-7 用户管理图

e.商品管理
表4-10 商品管理用例描述
用例标示符：网上零食店_UC_管理系统ID_05
用例名称：商品管理
范围：业务用例
级别：用户目标级别
主要角色：管理员
涉众：
—用户：希望能及时了解最新发布的商品信息
—管理员：希望及时对商品信息进行修改以及维护
前置条件：管理员进入网上零食店登录个人账号
后置条件：记录商品更改信息，及时更新商品数据库
主成功场景：
1.管理员输入ID以及个人密码。
2.系统识别管理员身份的有效性。
3.系统显示管理员的信息及权限设置。
4.管理员选择进入商品管理界面，并对商品的上新、下架、信息修改、信息查询进行选择。
5.进入商品上新界面，添加新品，并更新数据库。
6.进入商品下架界面，删除相应的商品信息，并更新数据库。
7.进入商品信息修改界面，修改相应的商品信息，并更新数据库。
8.进入商品信息查询界面，查询相应的商品信息。
9.退出时，进行数据库的更新保存。
扩展（或替代流程）
2a.管理员身份检查失败，提示重新输入（3次机会）。
3a.管理员权限识别失败，提示该管理员不具备用户管理的权限。
4a.基本信息未更新，提示没有更新用户信息，需要进行更新。
特殊需求：
1.同一权限的管理员一次只能一人进行商品信息维护和更新；
2.系统应具备较强的数据恢复能力；
3.管理员更新商品信息期间每2小时数据备份一次。
技术和数据变元表：
1.能自动进行商品信息检测判断是否满足要求。

图4-8 商品管理活动图

4.4.2 设计决策
本系统采用分层结构来进行设计，将系统划分为三层：UI层，业务逻辑层和技术服务层。其中，UI层主要给用户提供系统的界面。用户分为：顾客和管理员，顾客能够经过顾客界面浏览各种零食的信息，选购零食；管理员能够经过管理界面对网店的商品，顾客信息，交易进行管理。业务逻辑层主要负责处理用户在UI层发出的各种请求，比如顾客选购商品，确认订单，支付等业务，管理员添加商品，更新商品信息，管理顾客等业务。技术服务层主要为该系统提供技术支持，比如数据库的接口，系统日志等。

图4-9 逻辑架构
4.4.2 接口设计
确认订单用例(网上零食店_UC_用户系统ID_03)

图4-10 确认订单顺序图

确认订单用例中的系统操作：
契约CO1：makeTempOrder
操作：makeTempOrder()
交叉引用：用例：确认订单
前置条件：选购完毕。
后置条件：创立了Sale的实例s（创立实例）。
s被关联到Customer（形成关联）。
SaleLineItem被关联到s（形成关联）。
s的属性被初始化（修改属性）。

契约CO2：editOrder
操作：editOrder()
交叉引用：用例：确认订单
前置条件：正在进行中的订单确认
后置条件：修改与s相关的SaleLineItem的实例属性（修改属性）。
修改s的属性（修改属性）。

契约CO3：endOrder
操作：endOrder()
交叉引用：用例：确认订单
前置条件：正在进行中的订单确认。
后置条件：Sale的实例s的属性isEnd为真（修改属性）。

契约CO4：makeOrder
操作：makeOrder()
交叉引用：用例：确认订单
前置条件：正在进行中的订单确认。
后置条件：修改 s的属性customerID和customerAddress（修改属性）。

契约CO5：makePayment
操作：makePayment ()
交叉引用：用例：确认订单
前置条件：正在进行中的订单确认。
后置条件：创立Payment的实例p（创立实例）。
p.amount被赋值（修改属性）。
p被关联到当前的Sale（形成关联）。
当前的Sale被关联到Customer（形成关联）。
4.4.3 处理流程
1、确认订单用例(网上零食店_UC_用户系统ID_03)
以顾客的确认订单为例

图4-11 确认订单协作图
处理流程：
1. 顾客输入用户名和密码，核实身份后进入系统的商品展示界面；
2. 能够在商品展示界面选购商品，并加入购物车；
3. 点击购物车，进入购物车界面，显示所选购的商品信息；
4. 能够选择“编辑”选项，对购物车中商品的数量进行修改，
5. 能够选择“删除”选项，将商品从购物车中移除；
6. 能够选择“返回”选项，返回浏览界面，继续选购商品；
7. 选择“生成订单”，勾选购物车中的部分商品进行购买；
6. 系统会为用户生成订单并提示顾客输入地址等信息。
7. 点击“支付”选项能够进入支付界面进行支付；
8. 成功付款后，系统会提示用户，并将订单中的商品从购物车中移除，同时保存该用户此次的购买记录。

2、商品管理用例(网上零食店_UC_用户系统ID_05)

图4-12 增加商品协作图

处理流程：
1. 管理员登录系统选择“编辑商品”选项，系统对管理员的权限进行验证，权限匹配的情况下，进入编辑商品界面。
2. 选择“新增商品”选项，进入新增界面，在商品的表格中，管理员输入新增的商品信息，比如商品描述，价格，数量等信息；
3. 选择“保存”，系统对添加的商品信息进行验证，验证合法后将新增的商品信息保存到系统中。

图4-13 删除商品协作图
处理流程：
1. 管理员登录系统选择“编辑商品”选项，系统对管理员的权限进行验证，权限匹配的情况下，进入编辑商品界面。
2. 选择“删除商品”选项，系统会展示商品列表，管理员能够依据系统的分类定位商品并删除，也能够直接输入商品名删除商品信息。
3. 点击“确认删除”，系统将该商品的信息从系统中移除。
4.4.4 业务逻辑层设计

图4-14 业务逻辑层类图
5 性能需求
根据用户对本系统的要求，确定系统在响应时间、可靠性、安全等方面有较高的性能要求。
5.1 界面需求
本系统采用的是图形用户界面，本系统的用户包括客户和管理员。进入主界面后点击相应的窗口，分别进入相对应的界面。客户的界面与管理员的界面是不同的。管理员对程序的维护最好要有备份。系统页面较为合理，给人一种可爱清新的感觉，看到之后对零食产生极大的兴趣。页面上的每一个按钮、文本框、超链接都是经过设计人员精心设计，使用户使用系统更加方便快捷。所有界面设置导航，使用户进入界面后一目了然，按照自己的需求点击相应的按钮。

系统的界面要求如下：
1) 页面内容：
主题突出，站点定义、术语和行文格式统一、规范、明确，栏目、菜单设置和布局合理，传递的信息准确、及时。内容丰富，文字准确，语句通顺；专用术语规范，行文格式统一规范。
2) 导航结构：
页面具有明确的导航指示，语言简洁，且便于理解，方便用户使用。
3) 技术环境：
页面大小适当，能用各种常见浏览器以不同分辨率浏览；无错误链接和空链接；采用CSS处理，控制字体大小和版面布局。
4) 艺术风格：
界面、版面形象清新悦目、布局合理,字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当,动静效果好；色彩和谐自然,与主题内容相协调。
5.2 响应时间需求
所有的查询等待时间不能超过3秒，所有更新操作时间均在3秒内完成。无论是客户端和管理端，当用户登录，进行任何操作的时候，系统应该及时的进行反应，反应的时间在3秒以内。系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现长时间等待甚至无响应。
5.3 可靠性需求
本系统每个时刻都要采集大量的数据并进行处理。因此，系统的故障有可能给客户带来不可估量的损失，这就要求系统具有高度的可靠性。本系统需要对重要数据进行备份， 能够经过网络备份系统或人工定时将数据备份到本地或远程存储设备。如果系统遇到严重受损时，可利用灾难恢复系统进行快速恢复。
本系统使用Java语言进行开发，基于其可一次编译到处运行的特点，可使本系统的可移植性大大提高，使其能够运行在任何装有Java虚拟机的计算机上。本系统的可使用性也较强，任何人只要熟练简单地计算机操作，都能够无需培训，仅经过简单地学习就能够熟练的操作本系统。本系统在开发时采用模块化设计，模块之间高内聚低耦合，模块大多具有较强的独立性，因此可维护性较好。
网站必须由功能范围分明的技术模块组成，这样当故障出现时，能够逐个模块地检测。技术功能分化有多种手段，其中一种是功能模块的物理分化。在网站服务器群中，各个服务器分担着不同的任务，它们集合起来完成一项任务：支持网站用户的每一个需求。在设计这种分布系统时，不但做到网站高性能所需的同步处理、资源共享，还需要考虑保持系统可维护性所需的功能分开。在系统设计和系统实施时，提供足够的系统监察信息和调试手段。计算机软件的错误很多情况下，能够从其运行过程输出的事情记录中检查出来。注意保持服务器软件的平台无关性。这样不论服务器用什么操作系统，服务器软件都能无需更改而正常运行。
5.4 开放性需求
系统应具有十分的灵活性，能够将独立的模块拿出来进行运行修改，以适应将来功能扩展的需求。
5.5 可扩展性需求
系统设计要求能够体现扩展性要求，以适应将来功能扩展的需求，比如做一个进销存系统只需要进行简单的修改，或者直接进行添加销售的功能即可。
5.6 系统安全性需求
互联网是一个标准开放的网络，在网上进行各种商务活动，随时可能将面对黑客的攻击，病毒的侵袭等。因此，确保网上信息流通的系统安全十分重要、安全不但仅是一个技术的问题，还涉及到系统的管理、法律法规的保障等。
使用身份验证机制来保护本系统的安全，未经授权的用户不能访问本系统，即未注册的用户无法访问。而且保存在数据库中的用户密码根据密码学的原理采用密钥加密成密文，防止被非法用户所盗取，增强系统的安全保密性。
因为整个系统是一个严谨的服务平台，在此系统上将会涉及诸如个人信息、银行账号、机密设定等敏感性问题，因此必须对整个系统做全面地安全性考虑，对所有的敏感会话进行高强度加密。在此系统中，我们针对会话层将采取SSL加密协议。
当前，Intent上有几种加密协议在使用，对应OSI网络模型的每一层都已提出了相应的协议。对应层有SET（安全电子交易）协议。对会话层有SSL（安全套层）协议。在所有的协议中，SSL和SET与电子商务的关系最为密切。
SSL网络资料传输的安全协定，是由著名的Internet先驱Netscape Communication 提出的针对数据的隐秘性、完整性、身份的确认、开放性的安全标准机制。Netscape公司已把SSL协议递交给W3C网络安全工作小组以便使之成为万维网应用的安全标准、尽管使SSL协议成为标准还需要一段时间，但SSL协议事实上已被大部分万维网软件生产商所采用。SSL协议能很好地解决身份验证、信息保密、信息完整等网络信息传输过程中最为关键的安全密保问题。
SET安全电子交易规格，是由著名的信用卡季候VISA及MasterCard提出的针对电子钱包、商场伺服器、认证中心的安全标准。由于Visa与MasterCard的强大实力，以及得到IBM，Microsoft等业界巨人的支持，SET协议得到了业界的广泛支持。
SSL协议是经过把对称加密技术、非对称加密技术与杂凑函数技术结合起来而实现各项安全保密功能。SSL协议所能实现的安全保密功能以及为实现各项功能所采用的技术如下：
信息保密性：在遵循SSL协议的两条计算机传递的所有信息都经过对称加密技术予以加密。这样，网络切听者虽然可利用IP packet sniffers等手段截获两条计算机之间的信息流，却不可能读懂信息流中的内容。
信息完整性：网络中可能有这样一些人，她们虽然不能读懂您传递的信息，却而已地对信息包进行篡改，使对话双方产生误解。SSL协议利用了杂凑函数技术对此进行了防备。信息包一旦被篡改，就不能经过杂凑函数检验，该信息包就会被丢弃。
身份的相互验证：为验证对方的身份，遵循SSL协议的两台计算机在进行对话之前都有一个握手过程。我收过程所交换的信息如下：1.双方交换X.509格式的身份证明文件，该身份证明文件必须服有可靠的验证机构的电子签名。双方利用非对称加密技术验证对方的身份并得到对方的公钥。2.其中一方随机生成一组进行对称加密用的密钥组，把该密钥组用对方的公钥加密并传给对方，对方即可用自己的私钥解密得到进行对称加密用的密钥组。3.双方确定以后对话中所使用的对称加密算法。

6 产品提交
提交产品为：
a) 应用系统软件包
b) 数据库初始数据
c) 系统开发过程文档
d) 系统使用维护说明文档

提交方式：利用软件开发包的形式进行提交

7 实现约束
系统的实现约束如下：
a) 操作系统为 windows系列的操作系统
b) 开发平台为：eclipse+SDK