結對項目之需求分析與原型設計
學号：3004 陳慧玲/3022 方澤慧
在《建構之法》第八章的重大競争性需求分析的架構（P160-P163）這一小節中，詳細介紹了NABCD模型。
- N需求（Need），了解使用者的需求，用你的創意解決使用者的需求
- A做法（Approach），運用獨特的招數解決使用者的痛苦（需求）
- B好處（Benefit），這個産品/服務會給客戶/使用者帶來什麼好處
- C競争（Competitors），了解市場及競争對手，看清我方優劣勢
- D推廣（Delivery）,了解産品怎樣能有效地在使用者中推廣，能讓我們把相關功能設計做好
一、需求分析
1、N（Need，需求）
随着計算機技術的飛速發展，通過網絡學習的人越來越多，可是有許多的學習網站都隻滿足使用者的其中一種需求，比如，部落格園給出的比較多的是專業性較強的文章，而缺乏資源的提供；而知乎可以提供問答功能，可是答案比較雜亂。是以希望做一個綜合性的學習交流平台，給使用者提供交流互動、學習心得記錄、學習資料共享等功能，同時使用者可以舉報一些惡意的使用者，減少惡意答題；上傳資料需要經過背景稽核，防止一些不良資訊散播，進而營造一個比較愉悅輕松的學習氛圍。
2、A（Approach，做法）
由需求分析可以看出，大部分的網站都是主要做好某一個功能的，而論單一功能我們的技術現在還無法達到它們的高度，而我們能做到的是盡可能把那些網站比較優秀的功能結合起來，外加一些自己的想法，合理設計出屬于我們的網站。
學習網站平台大緻運作流程如下：
1.個人管理
普通使用者可以注冊賬戶，注冊時每個使用者需要填寫一些注冊的必要資訊，注冊完成後需要對自己的個人資訊進行完善，個人資訊可以修改。另外，使用者可以管理自己的學習筆記，心情，或者提問和評論，可以建立或加入興趣圈，以找到自己想學習的圈子。
2.好友互動
學習興趣相同的使用者可以通過互相交流提高學習效率，是以，設有好友功能，可以搜尋關注其他使用者，如果互相關注，則可以私聊互動。
3.資源共享
網上學習資料特别多，可總是找不到自己想要的，浪費了很多時間。是以這裡的資源共享隻要是一些學習文檔或者視訊類的資料，共享資料需要寫上版權所有者等，并且需要背景稽核，稽核通過的資料可供其他使用者下載下傳。上傳的使用者對自己上傳的資料可以随時下載下傳、删除。
5.疑難問答
在學習過程中，常會遇到難題，是以設立答疑區，使用者可以在答疑區提問，當然可以通過類似懸賞金币的形式吸引答疑者回答問題，讓問題可以及時解決。如果在一定的時間内問題沒有解決，将自動關閉問題。如果問題解決，提問者可以選擇滿意答案和推薦答案并停止問題，停止後的問題不能再回答，但問題和答案會保留供其他使用者檢視。
6.智能推薦
在答疑區、讨論區和資源共享等地方，根據個人的浏覽記錄或者使用者所在興趣圈給使用者推薦其感興趣的話題或資源。
7.學習筆記
使用者在學習後，可能會有想寫點筆記或者心得。設立使用者筆記子產品，使用者可以在這裡将學到的東西記錄下來，供自己日後檢視或讓其他使用者借鑒學習。在這個子產品也可以找别人的學習筆記，可以收藏别人的筆記。
8.回報系統
當學習者感覺網站體驗效果不佳、覺得有什麼需要改進的地方或者想要舉報使用者，可以通過回報系統将問題回報給我們，管理者會對回報進行稽核，如果對網站建設有一定作用，可獎勵相應金币。
3、B（Benefit，好處）
- 提供優質的學習資料，提高使用者的學習效率
- 把學習需要的各個方面結合起來，提高使用者的時間使用率
- 提供較為輕松的學習平台，提升使用者體驗
- 提供好友互動平台，友善使用者間的交流和學習
4、C（Competitors，競争）
- 對于單一功能來說，許多的學習網站已經較為成熟，而且開發時間比較久，市場競争較為激烈
- 目前在網絡上暫時還沒看到功能較為綜合的學習網站，在綜合性學習網站的市場還有待研究
5、D（Delivery，推廣）
- 原型系統設計完成後，全力進行開發
- 在百度中進行廣告推廣
- 使用者在網站發表完筆記後，可以同步分享到微信、QQ等平台
二、結對過程
三、原型系統設計
原型設計工具：墨刀
1.登入後首頁面：
2.登入頁面：
3.注冊頁面：
4.筆記頁面：
暫時設計出這些頁面内容，其他頁面還需要再思考。
四、PSP
| PSP2.1 | personal Software Process Stages | 預估時間（分鐘） | 實際耗時（分鐘） |
| Planning | 計劃 | 20 | 30 |
| · Estimate | · 估計這個任務需要多少時間 | 20 | |
| Development | 開發 | 260 | 450 |
| · Analysis | · 需求分析 (包括學習新技術) | 60 | 90 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | / | |
| · Design | · 具體設計 | 120 | 240 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | 80 | |
| · Test Report | · 測試報告+部落格 | 50 | |
| · Size Measurement | · 計算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 10 | |
| 合計 | 360 | 540 |
五、結對心得及項目總結
結對心得：第一次進行結對項目，通過跟别人讨論需求，進行頭腦風暴，可以得出許多千奇百怪的腦洞，這是一個人無法做到的。結對更加可以提升自身的溝通能力以及協作能力，進而更好的進行開發。
項目總結：以前從未見過NABCD，經過這次的項目分析，系統地了解了NABCD模型，并且了解了項目開發的第一步——需求分析和原型設計，加深了對軟體工程的了解。