需求分析

軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。

1. 訪問軟件項目的真實用戶（至少10個），確保軟件真正體現用戶的需求，為軟件最終可用奠定基礎。

   • 如果是原有項目，需要對舊項目的所有信息做一個調研，通過采訪以前的開發者，形成采訪文檔，請參考《構建之法》的大馬哈魚巡回遊的過程性介紹。

   • 用戶調研方法參考《構建之法》第8章獲取用戶需求——用戶調研
     • http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html
     • http://www.cnblogs.com/xinz/p/3308608.html

   問卷調查鏈接：https://www.wenjuan.in/s/UZryIz0/

   問卷調查截止至4月15日，我們共收到了55份調查答卷，女生比例達到了60.00%，男生占了40.00%，並且我們從這些答卷中可以分析出一些實際性的問題。

   • 問卷調查結果及分析：
     （1）因為我們是在微信朋友圈及qq中發送問卷調查鏈接的，所以在本次調查問卷中以18~25歲的年齡段占最大比例。
     

     （2）在調查中可以發現用戶沒有記賬習慣的結果和只記錄大筆支出也占了比較大的比重，都占到了41.82%。因此我們大概采訪了幾個我們知道的選擇不記賬的朋友，通過詢問他們為什麽沒有記賬的習慣，從而讓我們知道我們的APP應該怎麽做來吸引他們的使用。
     

     

     

     （3）在調查過程發現大部分人的支出情況還是以生活方面的支出為主，這樣的話，我們在設計記賬APP時就可以往這方面發展，例如多設計些生活類的分類之類的。

     

     （4）60.00%的用戶選擇了根據前段時間花多少錢，來決定自己今後的消費水平。這樣的用戶其實算是我們的潛在用戶，他們可以在記賬APP中記錄賬單，APP會計算出總支出，這樣就不需要用戶自己計算了，從而吸引用戶使用我們的APP。

     

     （5）大部分的用戶認為好的APP以對花費和收入進行分析說明和按年、月、類別進行查詢收支為最重要的功能。

     

     （6）45.45%的用戶喜歡以月為單位進行一次賬單的統計分析，這樣的話，我們的APP會在每月的月頭推送一份月賬單，包括了統計分析及評價。

     

     （7）45.45%的用戶喜歡APP的風格是清新可愛的，所以我們會盡可能的讓我們的APP界面美觀，給人小清新的感覺。

     

     

     （8）65.45%喜歡將自己的支出和收入可以變成統計圖，所以在我們的APP中將會提供賬單的統計圖功能，以滿足用戶的需求和喜好，讓用戶對我們的APP有好感。

     

2. 參考《軟件需求規格說明書》國標規範文本，撰寫對應項目的軟件需求規格說明書。提供《需求規格說明書》的Git鏈接。

   • 除形式上滿足規範文本要求外，整體內容必須圍繞項目實質展開，對所要開發的項目確保盡力做到清晰完整準確。

   • 使用一致的圖形符號和文字描述內容。
     • 分析和設計方法：http://www.cnblogs.com/xinz/p/4525232.html
     • 在線作圖工具ProcessOn：https://www.processon.com/

   • 所有的縮寫須事先定義。

   • 需要有一個目錄，word排版樣式規範美觀，圖文並茂，通篇文檔有一個統一的樣式風格。

   • 將自己置於讀者的立場——如果對軟件項目不熟悉的人員，通過閱讀這份文檔，能否完全讀懂軟件要做什麽。

     《軟件需求規格說明書》

3. NABCD 寫作，視頻

   • 請同學們把自己項目的NABCD 都寫出來。

   • 列成詳細的條目，用具體的事實和分析說明。

     • N (Need 需求)
       ??現在大多數人的個人財務管理意識都很薄弱，普遍呈現著一種現象——“啊，明明沒買什麽，怎麽錢都用光了”，所以我們需要通過記賬的方式來合理的管理自己的財務，曾經使用傳統的記賬本記賬，隨身攜帶著及時將每天的收支記錄下來，但是現在網絡發展迅速，生活節奏加快，每年的支付收入賬單絡繹不絕，傳統記賬已經滿足不了人們的需求，所以我們需要一款可以隨時、隨地、隨身進行記賬的、輕量級的、簡約的、以最清新的界面給用戶最舒適體驗的記賬app。

     • A (Approach 做法)
       • 用戶通過註冊或登錄一個賬號，進入賬單管理界面，可以通過界面上的記賬和查詢，以及餅狀圖標按鍵可以進入不同操作界面。
       • 點擊記賬按鈕，進入到記賬管理界面可以進行收支記錄，保存之後返回賬單管理界面就可以看到賬單條目更新了。
       • 點擊了查詢按鈕就可以通過月份、年份、類別三種方式進行賬單的查詢。
       • 點擊餅狀圖按鈕就可以進入統計分析，查看你的收支情況。
     • B (Benefit 好處)
       • 用戶只需要註冊登錄一個賬號，即可享受隨時隨地隨身記賬、查賬、分析賬目的功能，還可以管理自己的賬戶。
       • 傳統記賬本雖然也有它的好處，一本記賬本的價錢也便宜，但是它的安全性卻難以保證，可能出現丟失或損壞，而記賬app則可以避免這個問題，更加的經濟可靠。

     • C (Competitors 競爭)
       ??現在市場上記賬app有很多，但是挺多用起來都太過復雜，像是挖財記賬，它實現了很多功能，可以說是很齊全，但是事實上在平時的生活，你不會需要使用到那麽多的方式記賬，情景記賬、旅行記賬、家庭記賬等，因為太過復雜，很容易用著用著就懶得用了，所以我們設計的是一種功能簡單的，易用性高，極簡之余又不失完善的記賬app。它不是一款專業級的記賬app，主要是針對學生群體，專門為其設計的，滿足其日常生活記錄。

     • D (Delivery 交付)
       • 初期通過身邊的同學朋友進行推廣，收集用戶的使用反饋，然後進行改進後，
       • 通過網絡組合策略，以微信推廣、微博推廣、貼吧推廣、軟文推廣的組合方式叫app交付到用戶手中
   • 請分析自己項目的殺手功能是什麽？參考教材的第8章：功能分析的四個象限
     • 殺手功能：輕松記APP用戶可以一鍵導出日賬單、月賬單、年賬單，還可以比較當月支出- 與上月支出的增長/降低比例，可以分享到各個平臺，例如微信朋友圈，QQ空間等。
     • 外圍功能：良好的界面設計，在各個平臺上都可以運行。
     • 必要需求：記賬，導出每日賬單、月賬單、年賬單。
     • 輔助需求：可以做各種皮膚。

   • 把這些要點都組合成為一段話 -- 當你要向別人兜售你的項目的時候， 你通常只有很短的時間 （電梯演說），能否自然而有條理地把項目說清楚？ 請用你產品中實際的元素代替 <> 中的抽象概念。
     ??各位領導/投資人/用戶/合作夥伴：我們的產品記賬app是為了解決 需要進行財務管理的用戶的痛苦, 他們需要一款輕量級、易用性高的記賬app，但是現有的方案並沒有很好地解決這些需求，我們有獨特的辦法將功能進行化簡，滿足用戶的日常生活記，它能給用戶帶來好處易用性高，操作簡單，以清新的界面給以用戶舒適的用戶體驗，遠遠超過目前市場上的競爭對手挖財記賬。 同時，我們有高效率的網絡組合策略推廣方法，能很快地讓大部分用戶知道我們的產品，並進一步傳播。

     [附加題]把上面的這段話錄制為視頻，上傳到視頻網站，並把鏈接發到團隊博客上。

     鏈接: http://v.youku.com/v_show/id_XMzU0MDMyMjgzMg

4. 團隊協作，加強分工，需要描述每個成員的具體分工及占整個文檔任務的工作量比例。

   姓名	團隊分工	工作量比例
   徐婉萍	博客編輯，整合其他團員任務，填寫團隊任務分工，進行用戶問卷調查及分析，原型設計	22%
   譚燕	任務分解WBS，《軟件需求規格說明書》撰寫	22%
   郭雅芳	系統設計，NABCD 寫作並合成一段話	22%
   李香榮	編碼規範，功能分析的四個象限，視頻錄制	22%
   羅登宇	部分問卷調查撰寫	12%

參考

• NABCD參考 （參見 http://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html）

• 同學們的實際作業例子：

  • http://www.cnblogs.com/dasusu/p/4830168.html
  • http://www.cnblogs.com/MR-ZH/p/5879464.html
  • http://www.cnblogs.com/linexu/p/5880155.html
  • http://www.cnblogs.com/liangzhilin/p/5462486.html
  • http://www.cnblogs.com/jjy520/p/5463552.html
  • http://www.cnblogs.com/hgf520/p/5457322.html

原型設計

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

1. 不要等到所有代碼寫好之後再去驗證需求，請用設計工具描述用戶界面和需求。

2. 原型設計不僅要考慮主要功能的頁面排布，同時也要考慮用戶實際操作中的問題，提前為用戶考慮得當並征求用戶意見

3. 系統是必須可運行的，可實際使用的——請抱著這樣的同理心去考慮系統。

4. 給目標用戶展現原型，與目標用戶進一步溝通理解需求。

   • 原型設計使用工具：墨刀
   • 原型設計預覽：https://modao.cc/workspace/apps/p99540276C11523625916498/preview
   • 原型設計具體解析：

   （1）用戶登錄界面：用戶安裝好APP後，打開APP顯示畫面，進入登錄頁面，如果用戶沒有賬號的話，就可以點擊註冊按鈕，進行賬號註冊，註冊完後，會自動跳轉到用戶登錄頁面。而如果用戶原來已經有了賬號，則用戶直接在此頁面登錄。
   

   

   

   （2）記賬顯示界面：用戶登錄APP後，進入記賬APP，這時候就會顯示本月的賬單明細，同時也可以通過此界面中的按鈕進入其他功能頁面。

   

   （3）記賬界面：用戶通過點擊記賬按鈕後，進入記賬頁面，此時分為了支出和收入兩塊，可以通過按鈕切換，可以記賬頁面中輸入需要記錄的賬單詳情。保存賬單後，會重新跳轉回顯示界面，並且也可以通過返回按鈕，返回到顯示界面。

   

   

   （4）查詢界面：用戶通過點擊顯示界面中的查詢按鈕後，進入賬單查詢界面，此時可以通過按鈕切換查詢月賬單，年賬單和每種類別的賬單詳情。通過界面中的返回按鈕可以返回顯示界面。

   

   

   

   （5）編輯界面：用戶通過點擊顯示界面中的編輯按鈕後，進入賬單編輯界面，此時會根據所點擊的賬單項目不同，跳轉至支出界面或收入界面，這時候可以對它們進行修改，點擊保存按鈕後又跳轉至顯示界面。也可以對項目進行刪除操作，點擊刪除按鈕後就可以刪除項目，並跳轉至顯示界面。通過界面中的返回按鈕可以返回顯示界面。

   

   

   （6）統計分析界面：用戶通過點擊顯示界面中的圖表按鈕後，進入賬單統計分析界面，此時可以選擇日期，進行統計分析，顯示月支出，月收入，月結余及圖表。通過界面中的返回按鈕可以返回顯示界面。

   

   （7）退出界面：用戶通過點擊顯示界面中的退出按鈕後，退出登錄，跳轉至登錄界面。

   

• 思考：他們的痛是什麽？場景是什麽？（用產品之前/之後，有照片或視頻顯示用戶調查的過程，使用了各種調查手段的，加分）

  • 他們的痛是：現在大多數人們普遍都存在一種現象——"啊，明明沒買什麽，怎麽錢都用光了"。每次到了月末的時候，都不知道自己將錢花在了什麽地方，每個月花錢沒有記錄就是導致自己並不知道自己已經花了多少錢，從使得自己每個月都是月光族了。

  • 用戶的場景是：
    用戶用產品之前：用戶每個月的花銷都沒有記錄，既沒有支出記錄，也沒有收入記錄。經常是到了月末發現卡裏沒錢了，但是又不知道自己把錢花在了哪裏。而且沒有記錄自己花了多少錢，花錢就會沒有節制，導致自己的支出經常花超了。
    用戶用產品之後：用戶使用了記賬APP之後，將自己的支出和收入記錄下來，從而讓自己清楚地知道自己花了多少錢，錢都花在了哪裏。這樣可以讓自己知道自己是否有在不應該花錢的地方花錢，讓自己可以為下一個月的開銷做好計劃，避免不必要的支出，也可以讓自己知道自己到現在已經花了多少錢，來決定是不是後面的時間就要節約了，避免成為月光族。使用了產品之後，可以為自己節省花銷，增加存款。

• 參考：
  • 《構建之法》第10章典型用戶和場景
  • http://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html
  • 阿裏巴巴衛哲：http://iamsujie.com/8000/8018/

原型工具參考

如果是設計原型，采用專門的原型設計工具，能夠事半功倍，工具參考：

• 移動應用原型與線框工具-墨刀

作業參考

原型設計界面簡潔，用戶體驗極佳。分工比例部分的泳道圖十分清楚地展示了各個同學的工作任務，Github上數十次Commit也展示了他們和諧的團隊協作。

• http://www.cnblogs.com/thousfeet/p/7702651.html

任務分解WBS

一個團隊項目要在一段時間內完成諸多任務，滿足用戶需求，實現團隊目標，從哪裏入手？
WBS（Work Breakdown Structure）即工作分解結構，是根據項目目標把工作分解成許多層次分明的、可交付成果的工作任務，然後用邏輯圖形或樹形結構表示出來。

1. 請給出團隊項目的WBS；

   

2. 團隊成員估計各自任務所需時間

   

3. 參考：http://www.cnblogs.com/zhengrui0452/p/6653964.html

編碼規範

根據結對編程的經驗，大家已經意識到編碼規範的重要性。
討論制定團隊的編碼規範，滿足代碼風格規範和代碼設計規範（參考書第4章4.1-4.3內容）http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html

• 編碼規範

系統設計

在設計階段，我們要清楚：軟件是怎麽解決這些需求的？
一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的接口，負責不同邏輯設計的開發人員就可以分散關註，齊頭並進。

1.如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計。

用戶界面進行數據的輸入，然後進行業務邏輯處理，（包括四類業務：賬號管理業務可以進行用戶的登錄與註冊以及用戶信息的管理，記賬管理可以進行收入、支出記賬，統計分析可以到處賬單進行賬目分析，查詢管理可以查詢所有或者日期查詢，）而數據訪問通過Dao接口（增刪改查）實現。

2.完成團隊項目的數據庫設計，並在隨筆中提供相應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

小結

團隊分工及完成情況：

個人感想

• 徐婉萍：在本次博客作業中，我們團隊成員們對我們的團隊項目進行了更為具體的項目分析，像是進行了原型設計，對用戶的問卷調查，NABCD分析等等。使用這些手段讓我們對於我們的項目有了更加深刻的認識，知道了我們的項目需要實現怎麽樣的功能，需要做到什麽樣的程度。並且對我們的項目的編程規則進行了規定，使得源代碼會看起來更加簡潔明了，且統一風格，不會出現每人每色的情況，也為我們的項目創建了《軟件需求規格說明書》，使得對軟件項目不熟悉的人員，可以通過閱讀這份文檔，讀懂軟件要做什麽。希望在下兩周的沖刺階段可以完成我們的預期。

• 譚燕：本次博客作業中我完成了任務分解WBS部分，還有寫了軟件需求規格說明書，調整碼雲Issues進度狀態。任務分解的話，要分解到很細的模塊，目前還沒開始編寫代碼，所以非常具體的代碼模塊還需要仔細商議。把各個任務狀態從進行中改為已驗收感到很有成就感，這表示著我們完成了我們的任務，今後也要更加努力！

• 郭雅芳：我這次團隊博客負責的部分是系統設計和NABCD的分析，在對app進行系統設計的時候需要考慮清楚app的整個結構，分清前端用戶界面和後端用數據庫存儲數據，用戶界面需要實現的功能模塊，以及進行數據訪問接口的設計。在進行NABCD分析的時候，我們需要了解軟件的背景，需求以及現有的競爭者和如何去脫穎而出。

• 李香榮：在本次博客作業中，我們對項目進行了更加詳細的分析，也明確規定了每個人的任務。我完成了本次作業中的代碼規範、功能分析的四個象限和視頻錄制幾個部分，我們團隊的其他同伴也都完成了各自相關的作業，我認為這次作業我們完成的很好。同時，希望接下來幾周的工作我們也可以很好的完成。

• 羅登宇：為了這次博客作業，我們小組進行了一次具體的分析會議，將每個成員的任務分配好，每人各自進行著每個人的任務。通過完成這次任務，使得我認識到了用戶調查的重要性，雖然我做的工作比較簡單，但我還是感覺到了團隊合作可以很有效的提高提高作業的效率

軟工網絡15團隊作業3——需求分析與設計