團隊做業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.團隊協做，增強分工，須要描述每一個成員的具體分工及佔整個文檔任務的工做量比例。

姓名	任務	工做量比例
吳玲	原型設計	100%
郭琪容	用戶調研，軟件需求規格說明書	100%
王興	任務分解WBS，時間預估	100%
曾藝佳	系統設計	100%
祁澤文 徐璐琳	NABCD分析 制定編碼規範，錄製視頻	50% 50%

---

原型設計

原型設計可以在表現層將設計合成一個邏輯總體，用戶能和你一塊兒看到將來交互的軟件藍圖、功能和效果，得到較真實的感覺，在不斷討論的基礎上完善將來的設計思想。所以，原型設計能起到有效溝通的做用，漂亮，直觀的原型圖更是讓人賞心悅目。

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.如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計

小程序架構參考(http://www.javashuo.com/article/p-szounwmq-eq.html)：

• 微信小程序的框架包含兩部分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%

每一個人的感想：

吳玲的感想：本次我負責的任務是原型設計，我用的軟件是Mockplus，整體感受仍是挺有趣的。不足之處在於這個軟件的一些圖標要開通會員才能使用，好比在單詞語音播放部分，原本應該用小喇叭圖標的，可是迫於沒錢開會員，只好將就用了音樂的圖標。還有一些其餘的圖標，其實也都不是最滿意的。作了有五六個小時了吧，辛苦是確定的，可是最後看到本身作出來的東西，仍是很開心，頗有成就感的。

曾藝佳的感想：本週我負責的是系統的設計，系統設計須要對系統進行分析，劃分模塊層次，對系統實現規劃等進行合理的安排。小程序系統設計須要先了解微信開發環境的架構和通訊，才能據此作出所作系統的設計。在此過程當中，瞭解小程序較原先的前端語言語法上，方法上都有變化，發現本身對小程序架構總體的瞭解還不足。

王興的感想：本週我負責的是任務分解WBS，作好WBS就須要對項目足夠了解，作WBS時須要從用戶的立場出發，還須要把葉子節點劃分的足夠小，由於一般的軟件項目中，葉子節點的時間成本最好不要超過兩週以保證項目能夠在一個里程碑中完成，劃分過程當中我發現有些功能多是重複的，好比複習模塊的「選擇複習題型」和「複習單詞」、「複習例句」等子節點有重複，因此最後就把選擇題型的子節點砍掉了。

郭琪容的感想：本週我負責的是用戶調研以及軟件需求規格說明書。調研部分，因爲咱們的新的項目，因此咱們採用調研的方式，咱們針對咱們項目的預想實現的功能，提了幾個相關的問題，看看你們對這些功能的接受程度以及他們偏好的功能。軟件需求規格說明書，咱們對咱們項目開發過程一些參數以及實現功能，和用戶及管理員的訪問點作了規劃，對開發者開發過程當中有個參考。

祁澤文的感想：本週和徐璐琳負責了NABCD的模塊以及編碼規範的模塊，兩人一塊兒討論了在英語紙質材料和各類單詞app盛行的階段，咱們如何讓咱們的小程序可以脫穎而出，咱們去了解了周圍同窗（主要受衆：大學生）背單詞的重難點，而且針對這些作出了一些總結和概括，去創新了一些個性化的功能。關於代碼規範，咱們也參考了一些大公司的編碼規範書寫，進行學習借鑑造成了咱們團隊的編碼規範，但願從此可以實現咱們如今所設計的所都指望。

徐璐琳的感想：這一週在團隊內主要和祁澤文負責項目NABCD、殺手功能、錄製視頻與編碼規範。在寫NABCD的時候由於以前 我的做業提問那有仔細瞭解過，也仔細閱讀了教材和蒐集了參考材料，因此寫的時候比較容易。殺手功能相對來講比較 難找，但這也是咱們最須要解決的問題，因此在這裏卡得比較久。錄製視頻方面由於要把NABCD彙總成一句話成電梯演說 ，就要把咱們項目最精華的部分提取出來，能在電梯到達樓層以前準確並一語中的的爭取到機會，而編碼規範部分不太 瞭解，上網也好查書也好，作了不少工做，慢慢地制定了一套還算詳細完整的編碼規範。這周感受到了關於一個項目起 始階段的完整內容，不僅僅只是開發，需求分析原型設計也是有必要的，雖然不少東西都才接觸到，但這也是一個學習 的過程，相信都會愈來愈好