專案評審建議

第一組（微食堂）：

缺點：

1.展示視窗不明顯，同學並不一定清楚某個視窗的特設招牌菜，只認識視窗的牌匾和模樣，值得改進。

2.每家店的菜品可以按照受歡迎度排列。

3.使用者登陸不同步。

優點：頁面比較全，雖然部分沒有做完，但是考慮得很周全。

缺點：

1.介面不好看，首頁顯得很堵

2.資訊顯示冗餘，並且分類太多

3.可以新增記賬統計的功能

優點：

缺點：

1.對於分類太少，無論是科目還是年級、專業

優點：利於大學生複習交流、學業進步

缺點：

1.首頁太緊湊了，排布不是很好看，顏色可以稍微做點改動

2.可以新增按圖書種類分類、賣家年級/專業分類和搜尋，這樣就能避免介面顯得太混亂

優點：因為是賣書，所以加上支付聊天肯定會更好

缺點：

1.主介面不好看，可以做改觀

優點：軟體利於學生繁忙的生活。

缺點：

1.對於使用者註冊時，可以同校推薦，或者對於乙個校區有乙個專門的平台

2.功能實現不是很好

優點：利於增強新生進入大學前的認知

缺點：

1.不能授權登陸，每次登陸都會要求密碼輸入

2.如果加上關注使用者，可以更增加軟體的吸引力

優點：介面炫酷哇，地圖也很實用的

缺點：

1.不能做成貼上板的形式，得及時更新該資訊是否已經過期

2.在發布啟事時，加上自動匹配會更好

3.未登入首頁和登陸後的首頁顯得重複，介面有點多餘

優點：分類做得很好，能夠做到多使用者使用

缺點：

1.內容不清晰，對於成員記錄什麼誰記錄功能有點亂

2.對於使用者成員如何做到不同宿舍不能來往，只能進入本宿舍的限制

優點：接地氣！以免舍友們因為小錢錢翻船！

建議：

建議：

這種小額外快的形式符合了滿足懶人的思想，其關鍵在於是否能夠讓使用者滿意（比如時間上是否合理等），所以根據這個問題就應該有競爭機制，比如誠信度，如果使用者給予好評，誠信度增加，若時間太長或者沒達到使用者滿意，給予差評，類似於**的評價機制；這樣有了競爭，服務也就會更加到位，使用者也更容易選擇接單的物件。

建議：

基本框架已搭建，優化的話可以從消費種類上下手，由於是針對大學生的軟體，所以消費型別上應該更貼近與大學生的消費方式；另一方面就是能夠提供模板記賬方式，假如兩天的消費型別以及金額差別不大，便可以基於昨天的消費模板，做簡單修改即可，這也是為了方便使用者的操作。

建議：

已連線上資料庫，可以顯示各個教室是否有課的情況，進一步可以在座位上考慮，比如當乙個教室人滿了的時候，顯示乙個等級，人中等數量，顯示乙個等級，人很少的情況，顯示乙個等級，這也就更方便了學生的選擇，當然這也就需要時時的對教室座位情況進行監控，對教室的人數情況及時了解並反饋相應資料。

建議：

作業管理系統，類似於上邊的作業系統，優化方向應該從作業分類上面考慮，還有就是可以加入班級的分類，這樣對於乙個科目來說，在乙個班級一般就不能出現不同的作業情況（也可以有特殊情況，例如留了多項作業等，這就需要系統去進行判斷等）；還有就是安全效能應該高一些，各個使用者的許可權也應該管理好，避免低階錯誤的發生。

建議：

建議：

建議：

寵物領養系統，由於相關與寵物問題，可以考慮在安全性上多做考慮，比如，對於寵物狗是否打過疫苗等問題；另一方面，安全問題也需要對寵物領養後是否正常成長等，這也可以基於一些評價信譽系統來做約束，對於使用者的不良行為做相應記錄。在系統結構上可以從寵物分類上做些優化，便於尋找某一類寵物以及進行深入了解等。

SDL 專案安全評審

1.分析專案需求流程，功能，架構文件 2.安全風險，stride威脅建模，隱私保護 gdpr 3.根據流程，功能，架構等提出安全需求 要求能落地 4.建立草稿 5.建立文件 根據1,2,3 名詞解釋，安全需求對應的作用等 6.平台錄入存檔 1.1 資料威脅模型 資料屬性 id,name 注入攻擊 越...

bingo培訓 需求評審一些建議

1 結合背景對產品進行論述比較重要。可以如我們小組論述現狀以及產生現狀的具體原因再到解決方案，向客戶論述當今環境下業務功能的一些痛點與恨點，再闡述我們的產品是如何去解決問題的。2 結合當下熱點問題進行分析。正如我們想要做的系統是乙個問卷系統，正好在評審的前夜我們收到了乙份關於活動的調查問卷，正好是乙...

專案開發系列 需求評審

今天進行了傳說中的需求評審。開始以為是一群大boss坐在那裡挑我們的毛病，沒想到是乙個極度輕鬆和open的過程。總結下一哈 首先，需求評審的參與者是pd，pm，需求方和專案小組全體成員。目的是對需求方提出的需求進行確認和補充。大致的流程是 需求方給出乙個大概的輪廓，開發團隊提出自己的想法，然後諮詢需...