專案評審建議

2022-08-14 06:39:11 字數 2439 閱讀 3280

第一組(微食堂):

缺點:

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

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

3.使用者登陸不同步。

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

第二組(微記賬):

缺點:

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

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

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

優點:

第三組(記憶箱):

缺點:

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

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

第四組(舊書銷售)

缺點:

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

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

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

第五組(日曆鬧鐘):

缺點:

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

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

第六組(校園知道):

缺點:

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

2.功能實現不是很好

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

第七組(一起):

缺點:

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

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

優點:介面炫酷哇,地圖也很實用的

第八組(online):

缺點:

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

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

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

優點:分類做得很好,能夠做到多使用者使用

第九組(宿舍小助手):

缺點:

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

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

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

10、馮碩

建議:

11、張家星

建議:

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

12、劉子倫

建議:

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

13、毛松林

建議:

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

14、謝夢雨

建議:

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

15、羅振宇

建議:

16、劉西寧

建議:

17、陳晨

建議:

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

SDL 專案安全評審

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

bingo培訓 需求評審一些建議

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

專案開發系列 需求評審

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