团队作业3--需求改进&系统设计
| 修改完善需求规格说明书,系统设计,Alpha任务分配计划,测试计划 |
一、需求&原型改进
1.针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
-
问题一：业务太过繁杂，前期考虑功能过多而忽略了用户体验
-
修改一：将校园跑腿功能暂时搁置，在宿舍小卖铺功能上进行优化，不同的对象进行不同功能的设计，新添小老板的消息提醒功能，货物贩卖情况统计功能，上新推新功能，视情况而定是否添加送货时间限制功能。
-
问题二：目前暂定的计划中缺少用户和商家的交流模块
-
修改二：增添私聊功能或者订单备注功能
2.修改完善上周提交的需求规格说明书
根据出现的问题适当删减旧功能和增添新功能，大致功能如下
具体改进内容：
- 1.删除校园跑腿功能
- 2.增添私聊功能或者订单备注功能
- 3.添加一个货物统计功能
情景描述：
情景一（买家）：晚上，A同学在宿舍感觉有点饿了，想吃点夜宵，但是又懒得下楼去小卖铺买，于是在同学推荐下，使用无需下载安装的微信小程序“XXXXX”，点了点小零食和自己最喜欢的泡面，并支付了订单，不一会，老板便拿着他点的零食泡面找到他指定的宿舍号找到了他，A同学足不出户就吃到了自己想吃的东西，A同学不经感慨：“这小程序是真的方便！”
情景二（卖家）：晚上，B同学收到了一个新的订单的消息提醒，上面清楚地列出了买家想买的东西，在取得对应商品后出发去对应的宿舍号将商品交给买家，交付完商品后在回宿舍的路上将刚刚的商品库存减一，实时更新库存情况，看着这一单单的订单，想到这个月又收入了不少，而且有了这个小程序管理小卖铺也更加方便，不会占用太多时间，B同学感慨：“这真是一个好的小程序！”
3.功能分析的四个象限
4.调整后的任务分解WBS及相应的项目进度计划如下：
二、系统设计
在开发过程中，团队本身在开发的起始阶段确定了基本的开发级需求分析：
在开发过程中，除了需要满足用户级需求以为，我们还需要针对开发团队的特点，满足一些开发级的需求和约束。作为一个学生团队，我们的开发时间极为有限，很难抽调出大量的时间进行开发。因此，开发效率就显得尤为关键。幸运地是，我们团队本身的学习能力较强，成员对于项目的开发
较为积极，且对于新知识上手较快。因此，我们选择大量采用成熟的开源技术来加快我们整体的开发效率，力求以最低的成本实现最多的功能。
因此，在开发策略上，团队经过商议后确定了基本方向：
我们采用新技术实现功能。一则可以采用新技术可以快速地实现更多功能，二则可以使团队成员学到一些当下流行的技术，对成员将来的发展也会有所裨益。
综上所述，我们团队将尽可能地在开发中采用成熟的开源框架和开源技术，以实现我们对于开发效率和开发质量的需求。
框架的底层 API 部分。微信一直有一个贯穿的“JS-SDK”在不断演进。对比一下小程序的底层 API 的功能范围，和 JS-SDK 还是有很多相似的感觉，相信未来会在形式上达到统一(JS-SDK 这名字也足够霸气，塞进去什么都不会觉得奇怪。不过 JS-SDK 的很多接口设计的实在不敢恭维，希望这次统一的进程也能重新修正下)。小程序的 API 部分由于可以跳出浏览器的框架，理论上肯定可以是 JS-SDK 的超集。商城界面：前端语言（wxml）
- 用户登录与注册：Flask框架实现
- 下单数据系统：对商家的评价：Flask框架
- 数据储存：Mysql+Redis高速缓存+MongoDB
- 交易系统：订单支付：Django+Vue
- 客户与卖家交流的聊天平台：wxml
三、Alpha任务分配计划
| Pocket Backlog | Sprint Backlog | 认领成员 |
|---|---|---|
| 买家模块 | 提交订单/私聊老板模块 | 赖泽荃，粟云涛 |
| 卖家模块 | 上下架/更新库存/查看销售情况/消息提醒 | 叶永安，李颂豪，赵铭骏 |
| UI设计 | 小程序UI | 谢启扬 |
四、测试计划
1.引言
想参考饭堂水吧点餐系统，做一款类似的小卖部点餐系统，这样就不用在所谓的小卖部群里进行买卖，麻烦又没有保障
2.任务概述
测试范围：小程序各种小功能
测试目的：小程序是否能正常运转
3.测试策略
测试人员：叶永安，谢启扬
测试成本：人力测试
测试方法：一人扮演商家，一人扮演买家，进行一次商品买卖
