目錄
一.《需求規格說明書》初稿的不足
總結了一下，主要有一下不足：
1.注冊功能的搶注
問題
棟哥在課堂上對我們小組的注冊功能進行了一番猛烈“抨擊”——我們是用學号注冊的，但是如果學号唯一的話，被别人注冊了，就沒轍了。其實，這點我們之前是讨論過的。橙汁采用的辦法是，使用者名自己随便注冊，但是在個人資訊中，填入學号，并不會沖突。
棟哥說了一種情況，就是報名的時候，A用B的學号報名活動1，B也用自己的活動報名活動1，會不會沖突。其實是不會的，報名表上到時候相同的學号隻會産生一個。
解決
為了從根本上解決沖突的問題，我們将注冊功能重新建構。新增手機号發送驗證碼來避免搶注事情的發生。将學号作為主鍵，為了確定一個手機号對應一個學号，學号注冊完無法更改。
2.角色身份之管理者
最開始我們小組的設想，我們程式員本身就是管理者。直到被棟哥問的時候才意識到，産品一旦交出去，程式員便不再使用。是以權限的管理必須需要一個專門的管理者角色來管理
我們新增了管理者的角色，并專門為他做了一個界面。在程式登入的界面中，可以選擇自己的身份，并登陸。在管理者界面中，有着四個功能，分為兩類，稽核與管理。
3.釋出新活動之推送範圍
我們之前所設想的方案，是根據學号來進行身份的解析，定點投放通知消息。棟哥問的時候，說如何确定投送範圍？原本的原型上，寫着的是1、2、3三個等級分别代表着校級、院級、班級。答辯的時候有點懵，一時不知道該回答是年級還是班級。。。其實這樣的方案是有問題的，比如我想投放“數計學院14級全體學生”，這時候你按這個1、2、3根本沒什麼用。。。😂。然後我們才恍然大悟。
我們在注冊的時候，就讓同學選擇自己所在院系年級，并且去掉了班級。班級的通知一般用QQ群，我們面向的主要是大範圍的資訊推送。
在活動釋出的時候，也是可以選擇推送範圍的，這時候是直接出現了具體的院系跟年級，不像之前那毫無用處的"1、2、3"。。。。
4.“特色功能”的實作問題
- 我的好友
- 水友集結
- 猜你喜歡
前三項功能最開始所想的本來是想作為特色功能的，但是時間匆忙，實際上并不是核心功能，Alpha版本沒有必要實作，是以就删去了。先做好核心功能——活動釋出、報名以及簽到才是重中之重。
二.對原型的一些改進說明
經過數次會議的讨論，我們重新設計了找回密碼、注冊、釋出活動等功能的界面
1.重新設計忘記密碼功能
之前是忘記密碼聯系管理者的QQ，現在是送出自己的手機号以及新密碼即可。
2.軟體主界面分為别為三個角色身份重新設計
之前是活動釋出者與活動參與者公用一個界面，造成混亂不便管理。現在可以在登入界面直接選擇身份，并且對應的登入進屬于自己的界面，裡面隻有自己的功能，簡潔易懂。
3.為配合管理者稽核功能，重新設計“權限稽核”功能子產品
需要先聲明的一點，所有的注冊，僅限于活動參與者。如果需要活動釋出者的身份，需要進行權限申請，由管理者稽核。
在參與者界面中的個人中心下方有個權限申請，填入個人資訊以及理由，便可以申請了。
4.管理者添加登出賬号功能
在注冊的時候，如果有人不小心注冊成别人的學号，會導緻這個學号的人自己無法注冊。是以這個學号的主人可以聯系管理者，送出證明，登出掉自己的學号，這樣便可以放心注冊了。
5.消息箱功能的改變
由于之前有我的好友這個功能，是以消息箱用于接受别人的消息。把我的好友功能删除後，便用了管理者接收權限申請等的消息請求。
三.編碼規範
http://www.cnblogs.com/gzwu/p/6006001.html
四.新版需求說明書以及架構的github連結:
https://github.com/cafe3165/admin
五.資料庫設計之ER圖
ER圖
PowerDesigner實作
六.分工與工作比例
| 組員 | 分工 | 比例 |
|---|---|---|
| 橙汁 | 根據讨論結果對原型進行了重新的設計、更新需求文檔界面部分 | 13% |
| 黃志明 | 撰寫上回需求說明書的不足以及改進的地方、整合新需求文檔 | |
| 牛姐 | 項目的體系結構設計和界面設計、性能需求部分更新 | 18% |
| 李嚴 | 項目的體系結構設計和界面設計、驗收标準更新 | 15% |
| 洪志興 | 資料庫的E-R圖設計、使用者特點以及場景更新 | 14% |
| 佳恺 | 資料庫的E-R圖設計、類圖以及用例圖的更新 | |
| 格格 | 編碼規範的撰寫、功能描述部分的更新 |