團隊作業3-需求分析與設計
需求分析
軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。
1.訪問軟件項目的真實用戶（至少10個），確保軟件真正體現用戶的需求，為軟件最終可用奠定基礎。
如果是原有項目，需要對舊項目的所有信息做一個調研，通過采訪以前的開發者，形成采訪文檔，請參考《構建之法》的大馬哈魚巡回遊的過程性介紹。
用戶調研方法參考《構建之法》第8章獲取用戶需求——用戶調研
http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html
http://www.cnblogs.com/xinz/p/3308608.html
由於我們的項目是新項目，所以我們采用了問卷調查的調查方面收集用戶的需求數據。
問卷鏈接：https://www.wjx.cn/report/22393231.aspx
調查過程：
2.參考《軟件需求規格說明書》國標規範文本，撰寫對應項目的軟件需求規格說明書。提供《需求規格說明書》的Git鏈接。
- 除形式上滿足規範文本要求外，整體內容必須圍繞項目實質展開，對所要開發的項目確保盡力做到清晰完整準確。
- 使用一致的圖形符號和文字描述內容。
分析和設計方法：http://www.cnblogs.com/xinz/p/4525232.html
在線作圖工具ProcessOn：https://www.processon.com/ - 所有的縮寫須事先定義。
- 需要有一個目錄，word排版樣式規範美觀，圖文並茂，通篇文檔有一個統一的樣式風格。
- 將自己置於讀者的立場——如果對軟件項目不熟悉的人員，通過閱讀這份文檔，能否完全讀懂軟件要做什麽。
軟件需求規格說明書鏈接：https://gitee.com/zyjjj/babaka/attach_files
3.NABCD 寫作，視頻
- 請同學們把自己項目的NABCD 都寫出來。
N（Need，需求）：我們的項目是英語單詞微信小程序。首先，滿足“便攜式”需求，它可以隨時隨地幫助用戶記憶英語單詞學習英語；其次，它附著在微信上，以一個小程序來運行，不需要用戶切換界面來使用，作為大學生，在使用APP記憶單詞的時候，切換到微信或其他社交界面，就會玩著玩著忘記了自己在做什麽，這時候就會想著：如果在回復別人消息的時候不用切換整個界面就好了，就不會想著一刷就刷，避免其他事情的介入導致了我們本在進行的活動。所以我們也認為作為小程序，最大的好處也是它可以在與其他人交流的時候運行，切換很方便快捷，使用方面會舒暢很多。其實我們自身也有在想，現在有很多的語言APP推出，可是某寶上的紙質英語資料還是賣得火得不得了，我們經過討論，采訪發現紙質的優點：可以對自己熟知，不認識的詞做不同的標記，也可以在一個單詞旁進行拓展記憶。形成自己的單詞網。
對於需求量分析後我們認為，將來對移動端“單詞記憶”的需求量會變大，並且也是學習英語的趨勢。因為它方便快捷，可以做到“碎片化”學習。輔助需求是一種枯燥學習的調劑，也是讓用戶堅持的一種方式，畢竟背單詞逃不出枯燥的怪圈。
A（Approach，做法）：上面也說過，我們自身也是大學生，那我們就更能理解學生在學習英語中的痛處，並能針對大部分學生在學習英語中遇到的各種難處來完善我們的小程序。例如：①大部分學生缺少自律性，這是不可避免的，但是大家都會有隱約的競爭性，那我們就可以設置一個好友圈打卡功能，讓大家自己加入一個圈子進行每日英語學習的打卡。②在學習英語的時候，我們會有一個記憶周期，一而再再而三地重復練習十分有必要，那麽如何重復，重復什麽。這裏我們就可以加入紙質優勢，設置“熟知”“陌生”“不確定”等按鈕記憶用戶單詞掌握度，並針對“陌生“不確定”模塊進行相應頻率的重復。③設置“筆記”模式：可以讓用戶在相應單詞旁做自己個性化筆記，方便不同用戶的不同記憶方式。也形成的我們小程序的“個性化”。
B（Benefit，好處）：我們項目這類應該會有很多類似的應用。首先，我們從微信小程序和獨立APP上來說明優劣：微信小程序是近期來熱度很高的話題應用，因為是用微信的平臺作載體，無需再獨立註冊一個新用戶，直接通過微信賬號來使用，並且可以直接獲得微信好友圈來建立程序內的交互功能，微信小程序社交屬性非常牛，實現了用戶幫你推送微信小程序，達到了微信用戶的流量裂變，而企業只需要花很小的成本，而不是巨大的廣告費用。前段時間話題度很高的某多多平臺就是靠這微信用戶流量的裂變，使用量、關註度與用戶數量迅速上升，靠這種形式在短短半年的時間內就積累了2億用戶，並已在電商領域排名第三，僅次於某貓某東。所以這也是我們選擇微信小程序的理由之一， 其次是成本低，這一點對於大學生來說是十分誘惑的。而對於我們這類程序中，我們能從中脫穎而出的優勢，我想在於我們更能總結用戶使用的痛處，對於界面、使用過程、學習模式、學習進度，可以根據其他小程序來克服痛處並完善程序，並且通過下面我們要說的推廣進行用戶遷移。
C（Competitors，競爭）：競爭是必然的，首先市場上有很多獨立的app，他們可以獲得各方輔導機構的贊助，獲得相應的詞庫如“戀戀有詞”，“紅寶書”等已經編排好的詞庫，而且可以根據不同年份，更新相應的詞庫。而我們初出茅廬，又基於微信平臺，可能無法獲得多方支持。而我們可以贏在本身也可作為用戶一員，能夠更好的理解用戶“說不出”的痛點，來優化程序實現程序的個性化。並且UI設計風格也更貼近用戶的理想風格。同時我們也具備環境優勢：我們基於微信本身開發，這樣其他已有小程序可以與我們的程序相互輔助，在一個app內實現用戶多需求。後期競爭就是該如何在完善中不斷提升用戶體驗，提高用戶遷入量。
D（Delivery，推廣）：作為大學生，其實最好的推廣方法，除了直接付廣告費進行推廣，就是通過大學生校園內進行推廣，其實我還沒見過對於這類小程序的校園推廣，並且認為學生不一定會排斥這樣的推廣應用，通過朋友圈轉發、口碑相傳、相關社團宣傳等方式在校園內傳播，相信這樣的宣傳方法會很有效。而現在很多年輕人也會被比較不一樣、簡潔的UI界面吸引，我們也準備通過這方面來進行推廣。
- 請分析自己項目的殺手功能是什麽？參考教材的第8章：功能分析的四個象限
殺手功能：“個性化”單詞記憶程序，生詞記憶算法；好友圈打卡功能。
外圍功能：吸引年輕人的UI界面，支持不同系統載體。
必要需求：單詞發音釋義準確度。
輔助需求：利用微信朋友圈，實現好友排名。以競爭方式，滿足用戶們娛樂需求
- 把這些要點都組合成為一段話 -- 當你要向別人兜售你的項目的時候， 你通常只有很短的時間 （電梯演說），能否自然而有條理地把項目說清楚？ 請用你產品中實際的元素代替 <> 中的抽象概念。
各位領導/投資人/用戶/合作夥伴：我們的產品“背背佳”基於微信開發的英語單詞小程序 是為了解決 大學生各種英語等級考試，對於單詞記憶方面 的痛苦, 他們需要 一個個性化的記憶單詞小程序，可以讓他們實現“碎片化“學習的同時也能讓他們堅持，並且逃離“今天背，明天忘”的怪圈，但是現有的方案並沒有很好地解決這些需求，我們有獨特的辦法 在背誦單詞的同時可以允許用戶有自己的“筆記”，輔助用戶形成自己的記憶方式。並且根據不同用戶需求，多頻率出現 “生詞”或“記憶模糊”的單詞，同時設置“朋友圈打卡”“好友排名”等模塊，加大程序趣味性。它可以加深用戶對單詞的記憶，同時不抹殺個人對英語的語感和個性化的記憶方法，以“遊戲競爭”的方式更好的讓用戶堅持學習，激發鬥誌和學習英語的興趣。遠遠超過目前市場上一些缺少個性化，記憶方法單調無趣的單詞app。 同時，我們有高效率的宣傳方法因為我們本身就處於受眾環境中，所以不需要大量投資廣告費用，可以通過自身朋友圈的轉發，校園社團的傳播，能很快地讓大部分用戶知道我們的產品，並進一步傳播。
[附加題]把上面的這段話錄制為視頻，上傳到視頻網站，並把鏈接發到團隊博客上。
http://v.youku.com/v_show/id_XMzUzMjgwNDA0NA==.html?spm=a2h3j.8428770.3416059.1
4.團隊協作，加強分工，需要描述每個成員的具體分工及占整個文檔任務的工作量比例。
原型設計
原型設計能夠在表現層將設計合成一個邏輯整體，用戶能和你一起看到未來交互的軟件藍圖、功能和效果，獲得較真實的感受，在不斷討論的基礎上完善未來的設計思想。因此，原型設計能起到有效溝通的作用，漂亮，直觀的原型圖更是讓人賞心悅目。
1.不要等到所有代碼寫好之後再去驗證需求，請用設計工具描述用戶界面和需求。
2.原型設計不僅要考慮主要功能的頁面排布，同時也要考慮用戶實際操作中的問題，提前為用戶考慮得當並征求用戶意見
3.系統是必須可運行的，可實際使用的——請抱著這樣的同理心去考慮系統。
4.給目標用戶展現原型，與目標用戶進一步溝通理解需求。
- 思考：他們的痛是什麽？場景是什麽？（用產品之前/之後，有照片或視頻顯示用戶調查的過程，使用了各種調查手段的，加分）
參考：
《構建之法》第10章典型用戶和場景
http://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html
阿裏巴巴衛哲：http://iamsujie.com/8000/8018/
首頁界面
我的
簽到打卡
單詞本
錯題集
設置
生詞本
單詞本中的單詞
刪除單詞本
任務分解WBS
一個團隊項目要在一段時間內完成諸多任務，滿足用戶需求，實現團隊目標，從哪裏入手？
WBS（Work Breakdown Structure）即工作分解結構，是根據項目目標把工作分解成許多層次分明的、可交付成果的工作任務，然後用邏輯圖形或樹形結構表示出來。
做好WBS有以下幾個要點：
- 保證所有子節點覆蓋了全部父節點包含的內容，我們的單詞小程序項目中的單詞發音和釋義、單詞復習等子節點全部都包含在學習模塊、打卡&和PK模塊、統計模塊以及復習模塊的父節點中了。
- 保證各個子節點不要相互覆蓋，我們每個父節點下面的子節點劃分算是比較清楚了，每個子節點都沒有相互覆蓋。
- 葉子節點要保證足夠小，能在一個裏程碑中完成，一個模塊下的葉子節點劃分得比較細，足夠小，所以我們是可以在一個裏程碑中完成的。
- 從結果出發構建WBS，而不是從團隊的活動出發，“從結果出發”就是我們想呈現給用戶的樣子，所以我在做任務分解時是站在用戶的立場上去考慮的，所以我們所有的父結點和葉子結點都是用戶能看得懂的
1.請給出團隊項目的WBS；
2.團隊成員估計各自任務所需時間
| 隊員 | 任務分配 | 所需時間 |
|---|---|---|
| 曾藝佳、王興 | 學習模塊 | 7天 |
| 徐璐琳、祁澤文 | 打卡&PK模塊、統計分析模塊 | 7天 |
| 郭琪容、吳玲 | 復習模塊 | 5天 |
編碼規範
根據結對編程的經驗，大家已經意識到編碼規範的重要性。
討論制定團隊的編碼規範，滿足代碼風格規範和代碼設計規範（參考書第4章4.1-4.3內容）http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html
編碼規範：https://gitee.com/zyjjj/babaka/attach_files
系統設計
在設計階段，我們要清楚：軟件是怎麽解決這些需求的？
一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的接口，負責不同邏輯設計的開發人員就可以分散關註，齊頭並進。
1.如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計
小程序架構參考(https://juejin.im/post/59b631d0f265da0649241368)：
- 微信小程序的框架包含兩部分View視圖層、App Service邏輯層，View層用來渲染頁面結構，AppService層用來邏輯處理、數據請求、接口調用，它們在兩個線程裏運行。
- 視圖層使用WebView渲染，邏輯層使用JSCore運行。
- 視圖層和邏輯層通過系統層的JSBridage進行通信，邏輯層把數據變化通知到視圖層，觸發視圖層頁面更新，視圖層把觸發的事件通知到邏輯層進行業務處理。
- view 模塊和 service 模塊的 WeixinJSBridge 都使用了 postMessage 接口與後臺通信。
系統模塊結構設計：
我們的view視圖層有預估有5個page，包含單詞學習頁面，單詞練習頁面，自定義筆記頁面，復習/錯詞頁面，排行榜頁面。
| 布局 | 實現 | 模塊間數據傳送及其調用關系 |
|---|---|---|
| 前端視圖層 | WXML 與 WXSS 編寫，由組件來進行UI展示 | 產生事件，調用API發送至邏輯層處理，采用wx.navigateTo實現頁面跳轉 |
| 邏輯層 | 使用javascripe語言編寫，微信提供各種小程序組件和API | app()註冊小程序實例，page()註冊頁面，將數據反饋至視圖層，以ajax方式調用java創建的後端接口 |
| 後臺服務器 | 使用java語言編寫 | 創建Websocket 實現與小程序的通信 |
| 後臺數據庫 | 使用sqlserver構建數據庫 | 利用java的JDBC連接數據庫 |
2.完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖（如果必要）
| 表名 | 描述 | 備註 |
|---|---|---|
| Update | 版本信息 | 小程序更新版本，更新時間，功能等信息 |
| User | 用戶信息表 | 存放用戶的微信名(主鍵)，昵稱，地址等信息 |
| Friendship | 微信好友表 | 存放用戶的微信好友信息，本用戶微信名(主鍵，外鍵User） |
| SearchHistories | 搜索歷史表 | 存放用戶搜索歷史，微信名(主鍵，外鍵User) |
| Lexicon | 單詞庫表 | 各種單詞庫名，內容，庫id(主鍵) |
| UserNodes | 用戶自定義筆記表 | 存放用戶的筆記，微信名(主鍵，外鍵User) |
| StudyStatus | 用戶學習情況表 | 所選詞庫，已學，未學，錯詞，收藏詞，微信名+詞庫id(主鍵)，微信名(外鍵User)，庫id(外鍵Lexicon) |
- 觸發器：修改用戶id，詞庫id時觸發，修改全部表格中的包含的相關id
- 視圖：User表+自定義筆記表 / 學習情況表 / 搜索歷史表
ER圖：
參考
- 分析設計方法：http://www.cnblogs.com/xinz/p/4525232.html
- http://www.cnblogs.com/bugphobia/p/4946840.html
- http://www.cnblogs.com/bugphobia/p/4946844.html
- http://www.cnblogs.com/bugphobia/p/4946849.html
合作情況
團隊的分工：
| 姓名 | 任務 | 完成情況 |
|---|---|---|
| 吳玲 | 原型設計 | 100% |
| 郭琪容 | 用戶調研，軟件需求規格說明書 | 100% |
| 王興 | 任務分解WBS，時間預估 | 100% |
| 曾藝佳 | 系統設計 | 100% |
| 祁澤文 | NABCD分析 | 100% |
| 徐璐琳 | 制定編碼規範，錄制視頻 | 100% |
每個人的感想：
吳玲的感想：
曾藝佳的感想：本周我負責的是系統的設計，系統設計需要對系統進行分析，劃分模塊層次，對系統實現規劃等進行合理的安排。小程序系統設計需要先了解微信開發環境的架構和通信，才能據此做出所做系統的設計。在此過程中，了解小程序較原先的前端語言語法上，方法上都有變化，發現自己對小程序架構整體的了解還不足。
王興的感想：本周我負責的是任務分解WBS，做好WBS就需要對項目足夠了解，做WBS時需要從用戶的立場出發，還需要把葉子節點劃分的足夠小，因為通常的軟件項目中，葉子節點的時間成本最好不要超過兩周以保證項目可以在一個裏程碑中完成，劃分過程中我發現有些功能可能是重復的，比如復習模塊的“選擇復習題型”和“復習單詞”、“復習例句”等子節點有重復，所以最後就把選擇題型的子節點砍掉了。
郭琪容的感想：
祁澤文的感想：
徐璐琳的感想：這一周在團隊內主要和祁澤文負責項目NABCD、殺手功能、錄制視頻與編碼規範。在寫NABCD的時候因為之前 個人作業提問那有仔細了解過，也仔細閱讀了教材和搜集了參考材料，所以寫的時候比較容易。殺手功能相對來說比較 難找，但這也是我們最需要解決的問題，所以在這裏卡得比較久。錄制視頻方面因為要把NABCD匯總成一句話成電梯演說 ，就要把我們項目最精華的部分提取出來，能在電梯到達樓層之前準確並一語中的的爭取到機會，而編碼規範部分不太 了解，上網也好查書也好，做了很多工作，慢慢地制定了一套還算詳細完整的編碼規範。這周感覺到了關於一個項目起 始階段的完整內容，不單單只是開發，需求分析原型設計也是有必要的，雖然很多東西都才接觸到，但這也是一個學習 的過程，相信都會越來越好
團隊作業3-需求分析與設計