1 需求&原型改进
1.针对课堂讨论环节老师和其他组的问题及建议，对选题及需求进行修改。
问题1：具体交易方式是什么？（线上or线下）
修改1：现在设计的暂时不考虑线上支付，只支持线下交易，用户的面对面交易，我们相当于是提供信息以及交流的渠道。
问题2：商品的添加功能是由谁添加？
修改2：由用户上传照片以及联系方式，理想价格和时间。
问题3：用户使用什么登陆？
修改3：以用户学号为唯一标识登陆，密码暂定身份证后六位。（或用户自己设置）
问题4：现存在学校相应的公众号（二手平台）类似的竞争者，项目优势在哪儿？
修改4：类似的二手公众号平台只是商品图片和卖家联系方式的集合，没有搜索功能，使用起来很不方便，并且存在暴露卖家联系方式的问题。而我们要开发的app中提供搜索功能并且卖家的联系方式只提供给想要买东西的人，不会造成信息泄露。
问题5：有没有考虑以微信小程序的形式完成。（APP和微信小程序哪个更好？）
修改5：与原生app比较，微信小程序具有低开发成本、无需下载等优势，但在功能性上限于微信平台提供的功能，而APP可实现完整功能。考虑到APP 可能由于用户使用频次较低，导致无法聚集流量而被微信上类似功能的小程序占得先机，所以未来会考虑向微信小程序迁移。
问题6：上传的图片使服务器压力增加，压力过大怎么办？
修改6：我们现在在开发初期，对于多图片问题，考虑压缩分辨率，限制用户上传图片大小，本地缓存等方式。后期系统做强，我们再将图片存入分布式服务器。
与用户沟通：
了解到我们这个APP如何让他们知道，如何推广，怎么吸引他们。
我们准备将APP与武大APP绑定，让用户更方便地下载，推送打折等活动来吸引学生。
2. 修改完善上周提交的需求规格说明书
初稿不足之处：
功能不全：未添加分校区的功能
项目进度计划未具体说明。
具体改进：
增加分校区功能
增加具体项目进度计划
场景举例：
小王同学临近毕业，发现自己好多以后用不上的书，家离得也比较远，还有些书架之类的东西也不方便带回去，扔掉的话又舍不得，毕竟是花了好多钱买的，于是他找到了校内二手市场APP，想着可以处理掉这些东西，于是用自己的学号登录账号将自己想要卖的书和物品的照片放到了平台上，附上自己想要卖出的价格和自己的信息，附上交易地点。在操作的过程中，他偶然发现了自己一直想要看的《时间简史》，于是提交订单，根据卖家提示的个人信息联系到了卖家，在XX宿舍楼下和小张同学进行了交易，买到了书。
过了几天以后，小王同学收到了收到订单的提示，但是买家并没有跟他联系，他就根据买家提交订单时附带的个人信息联系到买家，经过沟通之后，该买家因为选课的原因并不想买该书，上课用不到，于是小王取消订单。又过了几天小王同学又收到了订单提示，买家根据提交订单后获得的小王同学的联系方式联系到了小王同学，想要买他的旧书，约定好在小王同学的宿舍楼下完成交易。交易完成后，小王同学登录APP点击完成订单，二手市场上他卖出的书的信息显示交易已完成。
3.四个象限
杀手功能：上传商品，购买商品
外围功能：界面简洁，美观，方便用户管理商品，为用户推荐商品。
辅助需求：留言板，用户可以发布自己的需求，商品交换
必要需求：登陆注册
4.WBS分解
5.项目计划
2 系统设计
系统的架构设计
数据库设计
在本系统中，用户使用移动终端，通过网络的连接向服务器频繁地请求数据处理、数据修改或数据上传等。服务器访问数据库，将所需数据处理后发送回移动终端。本系统的服务器端需要保存大量数据，如用户的个人信息，商品的发布信息等，还需实时对数据库进行各项复杂的操作。
根据校园二手交易app各个功能模块，本系统涉及商品信息、商品分类、订单、注册用户等实体。各实体的E-R图如下图所示：
系统数据库的E-R图如下：
重要数据表的字段设计与功能如下：
用户信息表(Customer)
用户信息表主要用于存放系统登录用户的相关信息，表示的是每一个用户实体。表的字段主要包括：主键UID、用户头像、用户手机、用户qq、用户登录密码。
| 字段名 | 中文名称 | 字段类型 | 可否为空 | 描述 |
| UID | 用户id (学号) | varchar(20) | 否 | 主键 |
| Image | 用户头像 | varchar(255) | 是 | |
| Mobile | 用户手机 | varchar(20) | 否 | |
| 用户qq | varchar(20) | 否 | ||
| Psw | 用户密码 | varchar(20) | 否 |
商品信息表(Product)
商品信息表主要用于记录用于交易的商品的条目信息。Sale记录发布商品的用户的ID；Type，Area记录商品所属类型、区域；Title、Content、Price、Picture记录商品标题、描述、价格及图片（如果有的话）；Delete、Pstatus为记录商品状态的字段，0表示状态正常，1表示商品被删除
| 字段名 | 中文名称 | 字段类型 | 可否为空 | 描述 |
| PID | 商品id | int(20) | 否 | 主键 |
| Sale | 卖家Id | varchar(20) | 否 | 外键，关联到Customer |
| Type | 商品类型 | int | 否 | 外键，关联到Category |
| Area | 商品所属区域 | varchar(255) | 否 | |
| Title | 商品标题 | varchar(64) | 否 | |
| Content | 商品描述 | text | 否 | |
| Picture | 商品图片 | varchar(255) | 是 | |
| Price | 商品价格 | double | 否 | |
| Delete | 是否删除 | int | 否 | 0:正常 1:删除 |
| Pstatus | 商品状态 | int | 否 | 0:正常 1:已删除 |
订单表(Order)
订单表记录买方和卖方达成一致后的订单信息。OID表示订单ID；PID表示该商品ID；Buyer表示买下这个商品的用户ID；Ostatus表示订单状态：0表示交易完成，1表示交易失败，卖家可重新上架该商品，2表示交易正在进行，该商品对其他用户不可见
| 字段名 | 中文名称 | 字段类型 | 可否为空 | 描述 |
| OID | 订单id | int | 否 | 主键 |
| PID | 商品id | int | 否 | 外键，关联到Product |
| Buyer | 买家id | string(20) | 否 | 外键，关联到Customer |
| Ostatus | 订单状态 | int | 否 | 0:交易完成 1:交易失败 2:交易进行中 |
商品分类表(Category)
商品分类表记录商品的分类信息。Ctype表示商品不同类型；Cname表示该类型的名称
| 字段名 | 中文名称 | 字段类型 | 可否为空 | 描述 |
| Ctype | 商品类型 | int | 否 | 主键 |
| Cname | 类型名称 | varchar(32) | 否 |
3 Alpha任务分配计划
实现的功能项：
上传商品，购买商品
任务分配：
前端：王田路
功能：王婷婷
数据库：张芷祎
服务器：张宇光
通信与测试：程环宇
甘特图：
见需求改进&原型项目计划
4 测试计划
1.引言
1.1项目背景
l 项目名称：基于Android的校园二手市场app
l 项目面向用户：武汉大学全体学生
l 项目开发者：武汉大学软工实践MyGod小组
1.2参考资料
l 《Android 基础教程》（第四部），伯内特
l 《构建之法》(第二版)，邹欣。
l 《GB8567-88 计算机软件需求说明编制指南》
1.3有关项目人员组成以及联系方式
PM：程环宇
组员：张宇光、王婷婷、张芷祎、王田路
2.任务概述
2.1测试范围
整个项目
2.2测试目标
发现软件中存在的各种问题，排除潜在错误，最终将高质量的软件交给用户
3.测试策略
3.1测试人员需求、分工
两个人，一个人提交订单，一个人接收订单
3.2测试方法
单元测试、黑盒测试、性能测试
3.3测试停止及恢复条件
出现bug即停止
恢复条件：bug消除
3.4测试环境
Android手机
4.测试资源
4.1硬件资源需求
2个Android手机、服务器主机
4.2软件资源需求
Android系统
4.3测试人员需求
2个
5.风险评估
5.1人力方面
总开发人员为5人，相对较少，对最终完成项目有一定影响。
5.2时间方面
总开发时间为三周，相对较少。
6.其他内容
测试计划制定者：程环宇
日期：2017.10.30
修改记录：无
项目经理：程环宇