weborder - 副本

Requirements Documentation
Doc Name 乐器购买系统需求分析
Doc No.
Version No.
Total Page 4
Generated By Generated Date 10.1 Checked By Checked Date Approved By Approved Date
Version Modification Record
No. Date Version Modified
By Modification (修改)
Project
Name
WebOrder
Project Description provides an end user with the ability to order products from a Web site.
User
Introduction
有购买乐器的顾客
Glossary 拍卖购买历史运输方式商品信息
Functional Requirement 一用户：
1 允许顾客登陆
2 查看查找乐器及其信息
3 添加活删除乐器
4 进行购买（运输方式选择）5查看购买历史信息
二：开发者：
1 支持对系统数据的更新修改（对内部）
（1）订单信息
(2) 商品信息
（3）功能完善
2 对顾客的管理（对外部）
Nonfunctinal Requirement ●Req. for user interface
用户可以看到一个购买乐器的界面
●Req. for software and hardware
应该支持大多数人的操作环境，推广为大众使用●Req. for Performance
保证系统响应的及时性
●Req. for Robustness
稳定性好可移植性高。

保证一个可靠的购买环境●Req. for Security
应为这是一个购买系统，涉及到顾客的财产，所以一定要是稳定安全的。

●Req. for architecture
采用三层架构，用户界面，产品信息/订单数据库，数据库连接应分开在架构中
●Other req.
1系统有支付手段吗？（在线付费还是货到付款）2顾客地址信息从哪里得知，是在注册时候吗？（无法配送。

）
3 不具备检索功能，查找所需乐器困难（是否有必要增添查找功能）
4 只有在把货物添加到购物篮才能看到乐器具体信息，对顾客造成操作困难（如果货物不满意，顾客还需删除）
5 支不支持退货功能
这是一个面向有购买乐器需求顾客的在线订单系统。

Question 1:
系统功能：
一（对顾客）
允许顾客在登陆之后，查看乐器的种类，价格等信息，进而添加到购物篮进行购买。

1 允许顾客登陆
2 查看查找乐器及其信息
3 添加乐器
4 进行购买
5查看购买历史信息
二（对开发者）
主要就是可实现对系统的编辑更新功能。

1 支持对系统数据的更新修改（对内部）
2 对顾客的管理（对外部）
系统存在问题：
1系统有支付手段吗？（在线付费还是货到付款）
2顾客地址信息从哪里得知，是在注册时候吗？（无法配送。

）
不明确需求：
1 不具备检索功能，查找所需乐器困难（是否有必要增添查找功能）
2 只有在把货物添加到购物篮才能看到乐器具体信息，对顾客造成操作困
难（如果货物不满意，顾客还需删除）
3 支不支持退货功能
Question 2 ：范围声明
Project Name WebOrder
Project Description provides an end user with the ability to order products from a Web site.
User
Introduction
有购买乐器的顾客
end-user
software
Instruments online order
hardware
platform
支持windows Linux系列操作系统
network
connectivity
普通链接
transactions Tomcat 7.0
response time 1 ns
reliability 可靠稳定性好
robustness 可移植性高
Question 3: 模式选择分析：
瀑布模型：更改代价大，不符合系统的更新功能（No）
螺旋模型：项目简单，不适合大型开发（No）
喷泉模型：项目规格较小，聘请大量工程师成本高（No）
上述模型的匹配情况较差，不可采用。

增量模型与快速原型模型
从表面来看都是可以的，符合扩展变更以适应需求的要求，并能很好的适应项目的规模。

因此需将两个模式进一步比较。

增量模型有率先发布抢占市场的优势（但该系统并不新鲜），加速资金回陇（系统规模小，成本低，资金的流动性要求不高）。

此外，该模型有整合困难的缺点，加重了管理的难度。

（系统的涉及面比较窄，做的服务很专一，所以发展终究不会太大型。

后期管理难度大势必会加重系统的负担，使维护的成本增加，进而会造成系统的收益无法满足维护的代价。

最终系统死掉。

）简单来说，增量模型无法体现优势，却充分暴露缺点。

不合适！
相比之下，快速原型能好点。

迅速搭建系统原型，这本身对资金要求不高。

接着，便可在此原型的基础上，进行与顾客的沟通。

（可以借助当代信息渠道拓宽，进行问卷调查，也可针对性的采访，这样会使得系统更可能为大家接受。

也可能不符合市场的需求，早起就死掉，这样造成的代价也很小。

）比较合适！
可以看出，快速原型就像是增量模型的另一种形式，只不过二者的侧重各有不同。

综上所述，最终选择为快速原型模型。

班级：
学号：
姓名：。