软件需求实验需求说明报告书Word文件下载.docx
《软件需求实验需求说明报告书Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件需求实验需求说明报告书Word文件下载.docx（18页珍藏版）》请在冰豆网上搜索。
4.2部分用例时序图绘制16
5静态模型19
5.1寻找系统中的类。
19
5.2确定类的属性。
5.3确定类之间的关系20
6小结21
1项目概况
1.1项目建设的内容
贵州是有名的产茶大省，贵州所产的茶叶更有些远销国内外，为了更好的销售和宣传，打造自己的本地特色，同时也为了更好管理销售，采用计算机网络销售能更好的帮助卖家。
系统的主要任务是将茶叶、茶具通过网络营销系统进行宣传销售。
通过系统后台管理模块，信息管理员可以将各种茶、茶具信息上传到服务器数据库中，并能在线显示。
更新、删除系统中已有的信息。
并进行简单的统计分析销售信息，为决策提供数据依据。
1.2.1技术先进性
项目的硬件设备、支撑基础软件、开发的应用软件应能够保持较长的生命周期；
设计的功能和使用的技术应是行业成熟的、先进的。
要考虑系统处理速度和流程处理的科学性。
1.2.2安全可靠性
应有物理安全设施、技术安全措施和管理安全策略，保证系统使用的硬件能够稳定不间断运行，信息加工、存放和交换要保证机密、完整、可靠、可用、可控和可审查。
1.2.3开放性和标准化
考虑本项目要与各系统互联，数据共享和交换等问题，系统采用SOA抽象与耦合的软件架构，根据服务请求通过分布式网络对松散耦合的应用群件进行部署、组合和使用。
在遵循贵州省电子政务建设标准前提下，项目的设计尽可能遵循国际标准和国家标准，如J2EE标准、XML技术、TCP/IP协议、LDAP协议、SSL安全协议、公文格式和处理、电子签名等。
1.2.4灵活易用性
采用模块化、组件化设计原则，保证系统具有较强的并发处理能力及开放性、灵活性、可重构性、可伸缩性和可维护性。
对部分可塑性功能和大部分界面，应做到用户可定制。
人机界面友好和有图示、提示。
操作要简便易用。
1.2.5可扩展可维护性
项目的硬件、软件、数据库承载能力、业务环节和分布、数据指标和信息量、功能设置等必须可扩展，应用系统可二次开发。
要考虑项目涉及的系统技术环境、业务环境等因素，系统必须具备足够的兼容性和可升级。
管理人员可轻松地完成对整个系统的配置、管理和维护。
2业务目标
2.1系统功能需求定义
通过对业务概况的了解和整理（业务目标既可以由客户提出也可以由开发方整理得出）得出该系统的业务目标如下：
具体如下：
内容管理：
内容管理主要针对所出售的商品以及网站特殊模块的动态维护。
a．商品种类的添加、修改、删除；
b．每种商品的添加、修改、删除，商品信息包括名称、介绍、库存量等，支持库存量。
模块管理：
模块管理包括一些新鲜的商家特色。
a.新品推荐，可以动态添加、修改、删除商家最新添加的商品，并在网站主页展示；
b.热卖推荐，网站可以根据用户长期的购买量挖掘出热卖商品，并在网站主页展示；
c.优惠活动，商家可以在节假日等特殊时期推出优惠活动，并在网站主页展示；
统计功能：
该功能基于数据挖掘，可以帮助商家及用户更好的决策。
对于用户包括：
a.可以对商品进行智能查询和排序，排序条件可以是单个或者组合，如产地+销量；
对于商家包括:
a.可以统计某段时间（1天、一个月等）内商品的销量及销售走势等；
b.可以根据某段时间内商品的销量及被购买频率分析统计出哪些商品属于热销、滞销等，方便商家后续的决策；
用户管理：
用户管理主要针对网站普通用户和注册商家，其中对于普通用户包括：
a.用户账号注册、密码修改、个人其它信息的动态维护；
b.个人购物车管理；
c.卡号绑定和解绑；
d.个人购买记录查询、删除；
e.个人评价记录的查询、修改、删除；
对于入驻系统的商家主要包括：
a.本店会员的添加、修改、删除（可加入会员封号等）;
b.会员消费记录查询，便于划分客户等级，实施有针对性的营销策略；
评论功能：
主要包括：
a.会员对购买过的商品具有一次评价的权利；
b.第一次评价之后对所作评论会员只有追加评论的权利；
c.会员可以删除已作的评论；
d.商家可以对用户评论进行回复；
系统管理包括：
主要是系统管理员通过账号登陆进去对商家和用户信息进行管理，包括新增、删除、修改以及查询；
系统维护主要包括：
该部分由系统开发人员负责；
2.1.1涉众分析
根据本系统所要实现的业务目标，我们把系统的涉及人员即涉众分为以下几类：
（1）系统管理员；
（2）商家；
（3）用户
通过以上分析，可以得出该项目的利益相关者（涉众）如图2-1所示：
图2-1涉众
以及涉众的信息如表1所示：
表1涉众信息表：
编号
名称
说明
期望
cy001
系统管理员
权限最高的使用者.
可以对系统进行入驻商信息家以及用户账号信息的查询、添加、删除、修改；
cy002
入驻商家
通过与公司签订入驻合同的商家，可以在系统中有自己的网上茶叶销售商店
入驻商家可以对自己的信息进行修改、可以对购买过自己商店商品的用户进行用户等级分类。
cy003
普通用户
拥有系统账号的普通人群
普通用户可以对自己的信息进行修改（包括修改密码）、销注账号、购买产品、评论货物以及管理购物车
cy004
会员用户
拥有系统账号并且给该账号开通会员的用户
会员用户除了拥有普通一级用户的所有权限，还可以享受相应的折扣
2.2系统非功能需求
非功能需求主要有以下几项：
（1）数据安全；
（2）用户接口（可扩展性）；
（3）系统的运行环境；
具体的非功能信息如表2所示：
表2非功能信息表：
序号
非功能需求名称
内容
备注
01
数据安全
数据安全主要有以下两条：
1.购买记录日志必须有备份
2.保证充值或扣款事务的完整进行，不受特殊情况（如断电，误操作等）而影响数据的完整性、一致性。
02
用户接口
用户接口是为了以后的系统维护与拓展，在实现的同时必须考虑清楚将来系统的升级与功能拓展所需要的技术与接口问题，同时也是方便与其他系统链接。
03
系统的运行环境
系统要保证在windowsxp及以上操作系统中能使用，还要保证在常见的浏览器上不存在兼容性问题。
3需求模型
3.1根据业务目标进行边界定义
边界是系统与外界的联系，其实通俗点说就是使用系统的人与系统之间的交互。
边界是系统与外界的交接，我们确定分析的起点就是定义一个边界。
从系统的业务目标来看，本系统就归为四大类的界面定义。
3.1.1用户账号管理界面定义
用户账号管理之间的内容包括对用户（这里包括普通用户和会员用户）的信息进行编辑，可进行的操作有增加用户、用户信息查询、用户信息修改。
3.1.2商家信息管理边界定义
商家是系统中很重要的执行者，对于商家的信息管理，主要包括修改账号信息、
修改登录密码、进行店铺页面设计、店铺页面修改。
3.1.3商品信息管理边界定义
这里就分为两类涉众的行为，第一是用户可以对商品信息进行检索、把商品加入购物车、购买商品。
第二类是商家可以对商品信息进行修改、查询商品信息、上传商品信息、删除商品信息。
3.1.4购物车管理边界定义
购物车管理主要是针对用户的，只有用户拥有对购物车的管理权限，对购物车的管理包括把商品加入购物车、在购物车中进行购买、删除购物车的商品、查询购物车商品。
正如实验一业务目标所示，按照业务目标，本系统的边界定义如图3-1和图3-2所示。
图3-1边界定义1
图3-2边界定义2
3.2主角分析
首先根据涉众概要，可以得到涉众列表，其次根据所定义的边界也可以从中寻找那些站在边界外的涉众。
而这些涉众可能就是我们需要分析出来的主角（actor）。
在用户账号管理中，首先一个需要对边界进行操作的边界之外的涉众就是用户，而我们的用户分为普通用户和会员用户，当然会员用户是由商家进行管理，每个商家的会员用户不相同，而用户账号系统管理员也有权限进行管理，所以在用户账号管理边界定义之外就有用户和系统管理员这两种主角。
在商家信息管理边界定义中，主要的涉众有系统管理员和商家，边界之外就是管理员和入驻商家，所以在商家信息管理边界定义之中的主角就是商家和系统管理员。
同理在商品信息管理中就有商家、用户和系统管理员三类主角。
在购物车管理中却只存在用户一类主角。
综上所述，本系统的根据涉众分析和边界定义进行的主角分析中主角有：
用户、商家和管理员三类。
如图3-3所示。
图3-3主角分析
3.3用例分析
当有了主角和用例边界后，根据需求分析边界外的主角要做什么事情（即边界内的用例），用例描述了系统与外部角色之间的一系列的交互。
通过用例来描述用户需要系统执行的所有工作，是一组相关的使用场景。
通过调研和访谈，本系统的用例分析包括对用户的用例分析、对系统管理员的用例分析、对入驻商家的用例分析。
如图3-4、图3-5、图3-6所示。
图3-4管理员用例分析
图3-5用户用例分析
3-6入驻商家用例分析
3.4用例描述
用列描述是用来描述一组相关的使用场景。
下面我们用以下几张表进行本系统的用例描述。
表3用例列表
主要参与者
用例
用户、商家
购买茶叶
管理员
管理账号
表4用例描述
用例ID
1
用例名称
购买茶叶项目
创建者
张涛
最后更新者
创建日期
2016年12月1日
最后更新日期
参与者
描述
实现购买商品并且商家发货用户评价
前置条件
所有用户必须选择正确的支付方式：
货到
付款或通过第三方支付软件在线支付
后置条件
更新商品信息
主过程
1.用户进行账号登陆。
2.系统判断密码与账号是否匹配，正确匹配则登陆成功跳转到商品检索页面，否则登陆失败提示密码或账号有误请重新输入。
3.登陆成功之后用户可以通过输入关键字检索自己需要的商品。
4.检索出来的商品用户可以选择加入购物车再从购物车里面购买付款，同时也可以直接购买付款
5.商家通过系统看到用户购买信息若是已经付款或者选择货到付款的则选择发货。
分支过程
1.若不是系统用户，请注册。
2.密码错误请重新输入。
表5用例描述
2
实现对商家或者用户账号的管理。
系统数据库中有商家或用户信息。
更新信息。
1.管理员进行账号登陆。
2.系统判断密码与账号是否匹配，正确匹配则登陆成功跳转到系统管理页面。
3.从管理页面可以点击对商家或者用户账号进行管理。
4．跳转到相应的管理页面，可以对使用者信息进行新增、删除、修改、备份。
5.编辑完成点击保存。
系统跳转到管理页面。
6.完成。
1.若不是系统管理员，则无法登陆。
2.密码错误请重新输入。
4.动态模型
4.1部分活动图的绘制
1、用户下单活动图
（1）用户通过检索窗口检索想要购买的商品。
（2）根据检索结果选择要购买的商品。
（3）系统验证该商品是否还有库存。
若是库存为0则返回缺货提示。
（4）若是有货则进入确认购买进行订单的填写。
（5）系统显示订单详情，用户确认订单，若是有误则返回重新填写订单。
（6）提交订单，系统把详情写入数据库
（7）购物完成。
用户下单的过程活动图如图4-1所示：
图4-1用户下单活动图
2、商家修改商品信息
（1）利用商家账号登陆系统。
（2）检索要修改的商品信息。
（3）进入商品信息详情，进行编辑。
（4）提交修改结果。
（5）系统反馈检查，确认修改结果。
（6）商家确认修改，系统跳转到商店主页面。
商家修改商品信息活动图如图4-2所示：
图4-2修改商品信息
4.2部分用例时序图绘制
1．用户下单
该用例是在客户登录后可以浏览上架的商品，并能搜索相应的商品，根据需要选择商品并下订单，该用例的流程如下：
（1）用户指定相应的商品种类进行搜索，得到相应的商品信息；
（2）选中自己需要的商品并选择其定购的数量放入购物车或者直接购买；
（3）提交订单请求，系统检查用户是否登录，若用户未登录转回登录页面提示用户登录。
（4）用户登录系统，重新进入购物车页面，转入订单详情页面进行确认。
（5）否则返回个人信息由用户确认，转入订单详情页面进行确认。
（
（6）用户确认自己的订单信息后，由系统数据库记录订单信息及订单的细节更新订单表和订单细节表；
（7）数据库更新成功后，返回顾客下订单成功的消息。
时序图如图4-3所示：
图4-3用户下单时序图
2.入驻商家修改商品信息
该用例是商家根据商品信息的变动情况可以修改商品的相关信息，该用例的执行流程如下：
（1）入驻商家登录系统后，提交要搜索的商品信息，系统搜索数据库中的商品表，向商家返回符合要求的商品信息；
（2）商家选择要修改的商品，向系统提交修改请求，系统返回修改商品信息的页面；
（3）商家修改商品信息，并提交给系统处理；
（4）系统更新数据库中商品表的信息，并返回修改成功的页面。
修改商品信息时序图如图4-4所示：
图4-4修改商品信息时序图
3.管理员管理用户和商家信息
该用例是管理员登陆进入相应管理界面对商家信息和用户账号信息进行添加、删除、修改、查询操作。
管理用户的时序图如图4-5所示：
4-5管理用户账号信息时序图
管理商家信息的时序图如图4-6所示：
图4-6管理商家信息时序图
5静态模型
类图中的类是针对用例描述、时序图和协作图中每个对象创建的，系统中对类的识别可以通过寻找用例描述中的名称来进行。
我们可以根据前文所描述的用例描述和用例场景，用确定名词短语的方法来寻找概念类（语言分析，即从领域的文本性描述中来识别名词和名词短语，将其作为候选的概念类或属性），根据用例描述，故有以下类：
A.系统用户；
B.非用户（游客）；
C.入驻商家；
D.订单；
F.购物车；
G.商品（茶叶）；
H.管理员；
I.入驻商家。
根据用例描述中的分析，可以得出类中的属性，如:
a）用户（Customer）：
用户账号、用户姓名、收货地址、电话号码、购物记录、注册时间、等级。
b）系统管理员（Admin）：
管理员账号、管理员姓名、日志记录。
c）入驻商家：
商家账号、商家姓名、家庭住址、联系方式。
d）订单（Order）：
订单号、订单时间，产品名称，产品数量，产品单价，订单总金额，客户信息，供应商，仓储，交货时间，处理时间。
e）购物车（Cart）：
用户账号、更新时间、商品号、商品数量、商品单价、商品总价。
5-1用户类图
5-2订单类图
5.3确定类之间的关系
识别出类后，还要识别出类之间的关系。
5-3用户订单关系图
6小结
本文介绍了名茶网络销售系统的需求分析。
帮助程序人员首先明确客户对系统的要求，然后再将这些要求编写为文档，为系统开发做好准备。
升级会员 