軟工網絡15團隊做業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.wenjuan.in/s/UZryIz0/

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

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

     （2）在調查中能夠發現用戶沒有記帳習慣的結果和只記錄大筆支出也佔了比較大的比重，都佔到了41.82%。所以咱們大概採訪了幾個咱們知道的選擇不記帳的朋友，經過詢問他們爲何沒有記帳的習慣，從而讓咱們知道咱們的小程序應該怎麼作來吸引他們的使用。
     

     （3）在調查過程發現大部分人的支出狀況仍是以生活方面的支出爲主，這樣的話，咱們在設計記帳小程序時就能夠往這方面發展，例如多設計些生活類的分類之類的。

     （4）60.00%的用戶選擇了根據前段時間花多少錢，來決定本身從此的消費水平。這樣的用戶其實算是咱們的潛在用戶，他們能夠在記帳小程序中記錄帳單，小程序會計算出總支出，這樣就不須要用戶本身計算了，從而吸引用戶使用咱們的小程序。

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

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

     （7）45.45%的用戶喜歡小程序的風格是清新可愛的，因此咱們會盡量的讓咱們的小程序界面美觀，給人小清新的感受。

     （8）65.45%喜歡將本身的支出和收入能夠變成統計圖，因此在咱們的小程序中將會提供帳單的統計圖功能，以知足用戶的需求和喜愛，讓用戶對咱們的小程序有好感。

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

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

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

   • 全部的縮寫須事先定義。

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

   • 將本身置於讀者的立場——若是對軟件項目不熟悉的人員，經過閱讀這份文檔，可否徹底讀懂軟件要作什麼。

     《軟件需求規格說明書》

3. NABCD 寫做，視頻

   • 請同窗們把本身項目的NABCD 都寫出來。

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

     • N (Need 需求)
         如今大多數人的我的財務管理意識都很薄弱，廣泛呈現着一種現象——「啊，明明沒買什麼，怎麼錢都用光了」，因此咱們須要經過記帳的方式來合理的管理本身的財務，曾經使用傳統的記帳本記帳，隨身攜帶着及時將天天的收支記錄下來，可是如今網絡發展迅速，生活節奏加快，每一年的支付收入帳單絡繹不絕，傳統記帳已經知足不了人們的需求，因此咱們須要一款能夠隨時、隨地、隨身進行記帳的、輕量級的、簡約的、以最清新的界面給用戶最溫馨體驗的記帳小程序。

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

     • C (Competitors 競爭)
         如今市場上記帳app有不少，可是挺多用起來都太過複雜，像是挖財記帳，它實現了不少功能，能夠說是很齊全，可是事實上在平時的生活，你不會須要使用到那麼多的方式記帳，情景記帳、旅行記帳、家庭記帳等，由於太過複雜，很容易用着用着就懶得用了，因此咱們設計的是一種功能簡單的，易用性高，極簡之餘又不失完善的記帳小程序。它不是一款專業級的記帳app，主要是針對學生羣體，專門爲其設計的，知足其平常生活記錄。

     • D (Delivery 交付)
       • 初期經過身邊的同窗朋友進行推廣，收集用戶的使用反饋，而後進行改進後，
       • 經過網絡組合策略，以微信推廣、微博推廣、貼吧推廣、軟文推廣的組合方式叫小程序交付到用戶手中
   • 請分析本身項目的殺手功能是什麼？參考教材的第8章：功能分析的四個象限
     • 殺手功能：EASY記小程序用戶能夠一鍵導出日帳單、月帳單、年帳單，還能夠比較當月支出- 與上月支出的增加/下降比例，能夠分享到各個平臺，例如微信朋友圈，QQ空間等。
     • 外圍功能：良好的界面設計，在各個平臺上均可以運行。
     • 必要需求：記帳，導出每日帳單、月帳單、年帳單。
     • 輔助需求：能夠作各類皮膚。

   • 把這些要點都組合成爲一段話 -- 當你要向別人兜售你的項目的時候， 你一般只有很短的時間 （電梯演說），可否天然而有條理地把項目說清楚？ 請用你產品中實際的元素代替 <> 中的抽象概念。
       各位領導/投資人/用戶/合做夥伴：咱們的產品記帳小程序是爲了解決 須要進行財務管理的用戶的痛苦, 他們須要一款輕量級、易用性高的記帳小程序，可是現有的方案並無很好地解決這些需求，咱們會盡可能在咱們的軟件中將用戶最須要的功能實現出來，將一些冗餘的功能去除，減小軟件的冗餘度，作到以最少的操做實現完美的結果，知足用戶的平常生活記，它能給用戶帶來好處易用性高，操做簡單，以清新的界面給以用戶溫馨的用戶體驗，遠遠超過目前市場上的競爭對手挖財記帳。 同時，咱們有高效率的網絡組合策略推廣方法，能很快地讓大部分用戶知道咱們的產品，並進一步傳播。

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

     連接: 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）用戶登陸界面：用戶安裝好小程序後，打開小程序顯示畫面，進入登陸頁面，若是用戶沒有帳號的話，就能夠點擊註冊按鈕，進行帳號註冊，註冊完後，會自動跳轉到用戶登陸頁面。而若是用戶原來已經有了帳號，則用戶直接在此頁面登陸。
   

   （2）記帳顯示界面：用戶登陸小程序後，進入記帳小程序，這時候就會顯示本月的帳單明細，同時也能夠經過此界面中的按鈕進入其餘功能頁面。

   （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

小結

團隊分工及完成狀況：

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

我的感想

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

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

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

• 李香榮：在本次博客做業中，咱們對項目進行了更加詳細的分析，也明確規定了每一個人的任務。我完成了本次做業中的代碼規範、功能分析的四個象限和視頻錄製幾個部分，咱們團隊的其餘同伴也都完成了各自相關的做業，我認爲此次做業咱們完成的很好。同時，但願接下來幾周的工做咱們也能夠很好的完成。

• 羅登宇：爲了此次博客做業，咱們小組進行了一次具體的分析會議，將每一個成員的任務分配好，每人各自進行着每一個人的任務。經過完成此次任務，使得我認識到了用戶調查的重要性，雖然我作的工做比較簡單，但我仍是感受到了團隊合做能夠頗有效的提升提升做業的效率