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 | 使用者手機 | |||
| 使用者qq | ||||
| Psw | 使用者密碼 |
商品資訊表(Product)
商品資訊表主要用于記錄用于交易的商品的條目資訊。Sale記錄釋出商品的使用者的ID；Type，Area記錄商品所屬類型、區域；Title、Content、Price、Picture記錄商品标題、描述、價格及圖檔（如果有的話）；Delete、Pstatus為記錄商品狀态的字段，0表示狀态正常，1表示商品被删除
| PID | 商品id | int(20) | ||
| Sale | 賣家Id | 外鍵，關聯到Customer | ||
| Type | 商品類型 | int | 外鍵，關聯到Category | |
| Area | 商品所屬區域 | |||
| Title | 商品标題 | varchar(64) | ||
| Content | 商品描述 | text | ||
| Picture | 商品圖檔 | |||
| Price | 商品價格 | double | ||
| Delete | 是否删除 | 0:正常 1:删除 | ||
| Pstatus | 商品狀态 | 0:正常 1:已删除 |
訂單表(Order)
訂單表記錄買方和賣方達成一緻後的訂單資訊。OID表示訂單ID；PID表示該商品ID；Buyer表示買下這個商品的使用者ID；Ostatus表示訂單狀态：0表示交易完成，1表示交易失敗，賣家可重新上架該商品，2表示交易正在進行，該商品對其他使用者不可見
| OID | 訂單id | |||
| 外鍵，關聯到Product | ||||
| Buyer | 買家id | string(20) | ||
| Ostatus | 訂單狀态 | 0:交易完成 1:交易失敗 2:交易進行中 |
商品分類表(Category)
商品分類表記錄商品的分類資訊。Ctype表示商品不同類型；Cname表示該類型的名稱
| Ctype | ||||
| 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
修改記錄：無
項目經理：程環宇