03.福大本科生畢設導師雙向選擇系統_需求分析和原型設計

031402508 洪佳銘

031402516 黃瑞鈺

需求分析和原型設計pdf

一、需求分析

1、N（Need，需求）

• 分配過程繁瑣：以往都是通過系負責人對各班收集來的信息進行匯總，再通過某種復雜的算法進行分配。

• 學生對導師的了解程度有限：學生只能從表格中得到導師的些許信息，甚至連聯系方式都沒有，這對學生是不利的。

• 導師對學生不了解：之前的模式中，完全沒有導師的參與，導師完全不知道選擇自己的學生是怎樣的，只能是在分配后才知道自己帶的學生是誰。

• 分配結果不盡如人意：有些學生分配到的導師不是他（她）所期望的，這對之后的學習是一個重大的隱患。

2、A（Approach，做法）

• 采用web端：由於使用頻率非常的低，所有web端絕對更適合該項目。很難想象去把一個用戶使用一兩次就絕對不會再去用的功能，做成一個獨立的APP。如果作為一個功能模塊，嵌入到像福大教務通、福大助手這些使用頻率高的產品里，那還說得過去。

• 線上直接選擇：學生通過系統，直接填選自己中意的導師，無需通過中間人來收集填報信息。

• 雙向選擇，導師參與其中：導師也參與到分配過程，導師可以根據學生的志願表來挑選自己中意的學生。

• 豐富學生、導師信息：導師和學生均可以編輯自己的信息，加深雙方的了解，做出更好的決策。特別是導師和學生都可以留下聯系方式，師生可以更好的溝通。

• 多輪志願填報：采取2~3輪志願填報，這樣第一輪沒有選中的學生，可以根據自己的情況再去選擇其他人數未滿的導師。這樣就避免了被強制安排的情況。

3、B（Benefit，好處）

• 解放系負責人：學生和導師均可在線上直接互選，不用系負責人辛苦收集學生的填報志願，再人工分配導師。

• 師生之間更加了解：有詳細的信息參考，學生更加了解導師的研究方向，導師更加了解學生的特長和需求。

• 分配方式更加人性化：導師可以自己選擇學生，如果未選擇，系統將一定的排序自動分配。

4、C（Competitors，競爭）

• 競品較多：同班20多個組，競爭很激烈啊。

• 優勢：

  1. 基於web端，沒有使用負擔，方便操作
  2. 部分數據基於教務處，盡量減少需要用戶自己填寫的數據。

• 劣勢：

  1. 隊里的兩人都不會開發web端
  2. 依賴教務處的數據，如果教務處那邊不願意提供幫助，就得增改功能了。

5、D（Delivery，推廣）

• 老師方面：希望學校鼓勵老師提前去完善自己的個人信息。（我看了咱們學院網站，里面老師信息不是很完善，有些老師信息甚至是空白的。希望日后能夠完善，這樣也方便未來在其他地方信息共用。）

• 學生方面：由於這是每屆學生必做的事情，所有只要在選擇導師前期，學校直接下放通知，層層往下，最終學生能收到通知就好。

二、原型設計

• 原型模型設計工具：Axure Rp Pro 7.0

• 演示地址：猛戳此處⬅️

• 產品功能結構圖
  

• 學生界面

1. 登錄希望能夠直接和教務處的賬號密碼關聯，這樣用戶就無需再去注冊賬號。（若有政策方面的原因而無法和教務處關聯，那后期再考慮其他方式注冊登錄。問：教師應該也有自己的教務處賬號密碼吧？）
   

2. 導師選擇界面的入口用戶可以很方便的查看自己的預選結果。
   

3. 導師選擇界面靈感來自於與京東篩選電腦的界面。用戶看到導師姓名、職稱、預帶人數、研究方向等基本信息。
   
   
   

4. 點擊選擇該導師后，導師頭像和名字將在底部志願確定框中顯示。
   
   
   

5. 點擊紅框中的熱區，學生可以查看導師信息詳情。（導師部分信息學院網站里就有（待完善），若能共享數據那最好，不能的話后期導師的個人信息編輯功能需要增加一些輸入）
   
   
   

6. 我的導師界面，用戶可以查看自己的中選結果，為了方便勾搭自己的導師，同時考慮到教師手機號這種隱私性較強的東西，只有學生中選后才會顯示。中選前，學生只能看到QQ、電子郵箱這類聯系方式。
   

7. 個人信息界面，由於是和教務處賬號關聯，應該會有用戶的基本信息，所有姓名，學號強制設為不可編輯，以防用戶ID更改。其他信息，學生根據自己情況填寫。
   

• 教師界面

1. 學生選擇界面，沒有像導師選擇界面那么豐富。考慮到性別、長相可能會產生差別對待的情況，所以只抓取了學生姓名，專業方向，志願序列這些關鍵信息。學生排序，默認按照學生填報志願順序排序，相同志願序的按照績點高低來排列。
   

2. 點擊學生姓名，可以查看學生詳細信息。
   

3. 我的學生界面，主要還是為了方便導師查看自己的學生的聯系方式。
   

4. 個人信息界面，導師根據自己情況填寫。特別是老師可以自定義預帶學生人數。
   

三、效能分析和PSP

• 效能分析

1. 前期的需求討論充分利用了課余時間。
2. 為了確保雙方最終想法一致，各自畫了一份低保真的原型，這樣不僅可以補缺補漏，也可以很好的避免未來的爭執，少繞彎路。
3. 使用有道雲筆記一起拽寫文檔，提高效率。
4. 由於中秋假期回家，在家效率比較低。

• PSP

psp	明細	時長
需求階段	需求討論	1天

    || 需求確認 | 1小時

產品設計 | 產品功能框架 | 1天
|| 原型設計 | 2天
文檔拽寫 | |3天

四、小結

• 需求討論：最開始根據本次作業的要求以及客戶的需求，相互撕逼（討論），一步一步的考慮解決方案。比如是要采用web端還是APP來實現這個項目，我們考慮到用戶的使用頻率等因素就果斷拋棄了APP。恩，撕逼過程還是很愉快的。

• 功能取舍：最開始是有想做站內學生和導師相互交流的功能，但是考慮到學生和導師都不會常常登錄，何況我們還是基於web端，更難實時交流，站內交流的功能就雞肋了。交流方面導師提供郵箱/QQ就可以溝通了。

• 保證想法一致：討論過后，為了確認雙方是否都有很好理解對方的想法和整個項目，我們各自畫了一份原型，雙方互換后補缺補漏，再完善成一份中保真原型。

• 協同工具的使用：因為兩個人要一起寫文檔，所有考慮到了協同工具的使用。最初是要用石墨的，但是中秋期間石墨停機了...后來我們轉戰有道雲筆記，經過多個版本的更改， 逐漸完善了這份文檔。