电子商城需求分析文档

1、河南省 863 软件孵化器有限公司软件需求规格说明 书 电子商城 软件需求规格说明书 前台_购物车模块 后台_订单管理模块 1/19 目录 1 引言 (3) 1.1 编写目的 (3) 1.2 产品的范围 (3) 1.3 预期的读者和阅读建议 (3) 1.4 参考资料 (3) 1.5 优先级定义 (3) 2 综合描述 (4) 2.1 产品的前景 (4) 2.2 用户类和特征 (4) 2.3 产品的功能 (4) 2.4 遵循的标准和规范 (5) 2.5 应用模型(系统运行概貌 ) (5) 2.6 运行环境 (5) 2.7 设计和实现上的限制 (5) 3 领域模型 (6) 3.1 业务流程图 (6)

2、 3.2 类图 (6) 3.3 用例图 (7) 4 功能需求 (8) 4.1 包结构模型 / 模块关系模型 (8) 4.2 前台购物 (9) 4.2.1 购物车管理 (9) 4.3 后台管理 (14) 4.3.1 订单管理 (14) 4.3.2 退出后台 (17) 5 总结 (18) 1 引言 编写目的 本文档作为电子商城系统 1.0 的系统设计依据 , 对软件需求作详细的描述 , 为 后续的设计工作提供基础。 产品的范围 本文档包括的内容有 : 软件的功能性需求、软件的性能需求、软件的外部接 口、软件的质量特性。 预期的读者和阅读建议 本文档读者对象为项目开发组、系统测试组、 QA 高层,项

3、目经理。 参考资料 产品需求规格说明书模版 优先级定义 该需求的优先级 , 按高、中、低的优先级分类。 对高、中、低的解释如下 : 高: 关键的功能特性 , 必选, 不能实现意味着无法满足客户的需求。所有 “高”优先级 的需求必须在本次项目开发中实现。 中: 重要的功能 , 必选, 不能实现可能会影响产品的销售和客户满意度。所有 中”优 先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在 产品的下一个版本中实现。 低：有用的功能或性能的提高，可选,不能实现不会对产品产生实质性影响， 但可能会 在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在 产品的某一版本

4、中实现。 2 综合描述 本产品名称为电子商城系统，软件需求参照商场的实际业务流程，同时考虑系 统产品化的需求进行设计。本系统作为在线购物，在设计时本着规范、灵活的原则 来规划其业务功能。 2.1 产品的前景 本产品根据在线购物实际业务开发,满足广大WEB用户的需求。 系统采用B/S 结构,易于功能扩展和产品升级。 2.2 用户类和特征 2.3 产品的功能 2.4 遵循的标准和规范 公司制定的 CMM 级体系文件中的各种规范 2.5 应用模型（系统运行概貌） 2.6 运行环境 2.7 设计和实现上的限制 本系统基于互联网运行,是基于 WEBT 发模式的 B/S 系统,开发语言为 Java, 数据

5、库为 Oracle 9i,服务操作系统为 Windows server 2003。 3 领域模型3.1 业务流程图 图 3-1 系统流程图 3.2 类图 3.3 用例图 系统用例图如下图 3.1 所示 LE1 三 图 3.1 系统用例图 4 功能需求 4.1 包结构模型/模块关系模型 退出 查询所有订单 删除商品 4.2 前台购物 显示用户登录信息、商品信息、商品详细信息、购物车信息、订单信息 4.2.1 购物车管理 4.2.1.1 购物车管理概述 有会员权限的用户。显示用户的购物车信息，提供删除商品、继续购物、收银 结账、清空购物车、修改数量功能。 4.2.1.2Use Cases 目录 4

6、.2.1.3Use Cases 模型 -I 4.2.1.4Use Cases 时序图 421.5 活动图来描述关键业务流程及其参与人员 4.2.1.6Use Cases 描述 42161 删除商品 名称：删除 参与者:会员 功能描述 : 删除购物车里的商品 触发事件 : 需要删除商品 事件流: 用户点击【购物车管理】 , 系统进入购物车管理界面。 点击“删除”图标 , 提示是否删除购物车里的商品。 点“确定”按钮 , 该购物车里的商品就从购物车中删除了 ,刷新会员的购物 车信息。 备选事件流 : 后置条件 :用户操作被正确响应 , 并给出可能的提示 , 显示用户要求的界面 业务规则 : 会员能

7、够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 4.2.1.6.2 继续购物 名称: 继续购物 参与者 : 会员 功能描述 : 能够继续购买商品放入购物车中。 触发事件 : 需要继续购物 事件流: 点击继续购物连接 , 系统进入首页面。 点击想要购买的商品系统进入该商品的详细信息界面。 点击购买按钮 , 该商品就放到了购物车中 , 刷新会员的购物车信息 备选事件流 : 如果未选择记录 , 则给出信息提示 后置条件 : 无 业务规则 : 会员能够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 收银结账 名称: 收银结账 参与者 : 会员 功能描述 : 会

8、员能够提交订单 , 购买所需商品。 触发事件 : 需要结账 事件流: 点击“收银结账”链接 , 系统进入收银结账界面 输入收银结账信息 （ 收件人、邮寄地址、邮政编码、联系电话、选择付款方 、. 、一 、） 4 、. 式、运送方式、 输入备注 ） 。 点“提交”按钮 , 检验收件人、邮寄地址、邮政编码、联系电话合法性 ,合 法则将会员的收 银结账信息保存至数据库 , 不合法则给出信息提示 , 并将光标定位在不合法项 （ 若多个不合法则定位在最靠前的项 ） 。 保存成功则关闭本窗口 , 刷新会员的购物车信息。 备选事件流 : 失败则给出信息提示。 后置条件 :用户操作被正确响应 , 并给出可能的

9、提示 , 显示用户要求的界面 业务规则 : 会员能够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 备注:必填项后加 * 清空购物车 名称: 清空购物车 参与者 : 会员 功能描述 : 清空所有购物车中的信息。 触发事件 : 需要清空购物车 事件流: 点“清空购物车”链接 , 系统提示是否清空购物车里的商品。 点“确定”按钮 , 提示该购物车里的商品将全部从购物车中清空了 , 刷新会 员的购物车信息。 备选事件流 : 后置条件 :用户操作被正确响应 , 并给出可能的提示 , 显示用户要求的界面 业务规则 : 会员能够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块

10、风格统一 修改数量 名称: 修改数量 参与者 : 会员 功能描述 : 能够修改所要购物的商品的数量。 触发事件 : 需要修改商品的数量 事件流:点“修改数量”链接 , 系统进入修改数量页面。 输入要修改的数量 , 检验输入数量的合法性不合法则给出信息提示 , 并将光 标定位在数量项。 点击提交提示修改成功信息 , 刷新会员的购物车信息。 备选事件流 : 失败则给出信息提示。 后置条件 :用户操作被正确响应 , 并给出可能的提示 , 显示用户要求的界面 业务规则 : 会员能够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 备注:必填项后加 * 4.3 后台管理 订单管理 15

11、40e-Numbered_01405b0c-257f-4b2c-9e7a-102f84db2b32-Nu 商品管理概述 有管理员权限的用户 , 提供查看订单信息、执行订单功能。 4.3.1.2Use Cases 目录I 4.3.1.3Use Cases 模型 s 4.3.1.4Use Cases 时序图 4.3.1.5 活动图来描述关键业务流程及其参与人员 4.3.1.6Use Cases 描述 43161 查看订单信息 名称：查看订单信息 参与者:系统管理员 功能描述:查看订单的详细信息。 触发事件：需要查看订单的详细信息。 事件流： 管理员点击【订单管理】，系统进入订单管理界面 点击订单用

12、户名链接，系统进入详细订单信息界面 点击“返回”按钮，系统进入订单管理界面。 备选事件流:后置条件 :用户操作被正确响应 , 并给出可能的提示 , 显示用户要求的界面业务 规则: 系统管理员能够操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 4.3.1.6.2 执行 名称: 执行 参与者: 系统管理员 功能描述 : 执行订单的运送操作。 触发事件 : 需要执行订单的运送操作。 事件流: 管理员点击执行标识 , 将执行订单的运送操作 , 刷新订单管理信息。 备选事件流 : 后置条件 :用户操作被正确响应 , 并给出可能的提示 , 显示用户要求的界面业务 规则: 系统管理员能够

13、操作此功能 引用实体 : 无 界面要求 : 界面与其他模块风格统一 4.3.2 退出后台 退出后台概述 有管理员权限的用户 , 退出后台管理界面 4.3.2.2Use Cases 目录 4.3.2.3Use Cases 模型 4.3.2.4Use Cases 时序图 4.325 活动图来描述关键业务流程及其参与人员 4.3.2.6Use Cases 描述 退出后台 名称：退出后台 参与者:系统管理员 功能描述：退出后台。 触发事件：需要退出后台。 事件流： 管理员点击【退出后台】，系统退出后台进入前台首页面。 备选事件流： 后置条件：用户操作被正确响应，并给出可能的提示，显示用户要求的界面 业

14、务规则：系统管理员能够操作此功能 引用实体：无 5 总结 已经是第二次做项目了 , 这次的项目比上次做起来顺手多了 ,毕竟已经有了经 验, 在这次的项目中我也学到了很多 , 也有很多的心得体会。 因为在第一次时做了后台的相关功能 , 所以这次做前台相对容易了很多 ,所以 在刚开始做时并没有在一起讨论太多 , 以至于在后期时因为重名的情况出现了不少 的错误, 给后期的整合带来 了不少的麻烦 , 这一点在以后的项目中必须要注意。 这次我做的是购物车的功能 , 相对来说比较复杂 , 在最开始拿到时根本没有什 么头绪,在自己考虑了一个下午后 ,才有了点头绪 ,开始编写,这样效率的确高了很 多。所以在以后开始编写代码之前要先把需求弄清楚 , 这样才可以快速的了解功能 需求,