團隊做業3 ---- 需求分析與設計

需求分析

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

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

• 若是是原有項目，須要對舊項目的全部信息作一個調研，經過採訪之前的開發者，造成採訪文檔，請參考《構建之法》的大馬哈魚巡迴遊的過程性介紹。
• 用戶調研方法參考《構建之法》第8章獲取用戶需求——用戶調研
  http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html
  http://www.cnblogs.com/xinz/p/3308608.html

咱們在問卷網上作了一份問卷調查，總共10道選擇題，外加一道用戶建議題

• 問卷調查連接
• 統計結果連接

用戶問卷調查統計對比：

截止目前爲止，一共有89人完成了問卷，其中男女比例2:3，學生佔了78人，咱們從如下幾個主要的方面來調查，結果以下

記帳習慣

選擇習慣

是否有消費計劃

比較學生和從事其餘行業的用戶的需求

學生用戶的需求

其餘行業的用戶的需求

現用的記帳APP或小程序不足之處

用戶擔憂的問題

對於記帳APP或小程序的意見：

用戶指望和建議

---

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

• 除形式上知足規範文本要求外，總體內容必須圍繞項目實質展開，對所要開發的項目確保盡力作到清晰完整準確。
• 使用一致的圖形符號和文字描述內容。
  • 分析和設計方法： http://www.cnblogs.com/xinz/p/4525232.html
  • 在線做圖工具ProcessOn： https://www.processon.com/
• 全部的縮寫須事先定義。
• 須要有一個目錄，word排版樣式規範美觀，圖文並茂，通篇文檔有一個統一的樣式風格。
• 將本身置於讀者的立場——若是對軟件項目不熟悉的人員，經過閱讀這份文檔，可否徹底讀懂軟件要作什麼。

git連接入口

3.NABCD 寫做，視頻

• 請同窗們把本身項目的NABCD 都寫出來。
• 列成詳細的條目，用具體的事實和分析說明。
• 請分析本身項目的殺手功能是什麼？參考教材的第8章：功能分析的四個象限
  把這些要點都組合成爲一段話 -- 當你要向別人兜售你的項目的時候， 你一般只有很短的時間 （電梯演說），可否天然而有條理地把項目說清楚？ 請用你產品中實際的元素代替 <> 中的抽象概念。
  各位領導/投資人/用戶/合做夥伴：咱們的產品 是爲了解決 <目標用戶> 的痛苦, 他們須要 ，可是現有的方案並無很好地解決這些需求，咱們有獨特的辦法 ，它能給用戶帶來好處 ，遠遠超過目前市場上的競爭對手 。 同時，咱們有高效率的 方法，能很快地讓大部分用戶知道咱們的產品，並進一步傳播。
  [附加題]把上面的這段話錄製爲視頻，上傳到視頻網站，並把連接發到團隊博客上。

• N（Need)
  • 咱們團隊的項目是基於微信開發的記帳小程序，知足了用戶不依賴app，就能夠在手機上輕鬆記錄平常開銷收支的需求，即開即用，用完就走，無需佔用內存，影響桌面美觀。
  • 從需求量來看，在咱們的調查問卷結果上能夠明確看出，相對於傳統的記帳方式，超過一半的人選擇使用較爲簡便的記帳小程序。
  • 從用戶對曾經使用的記帳方式的痛苦,最主要的緣由是數據表達不直觀問題，其次是程序繁瑣，界面美觀和分類細節也佔有一部分。
  • 從用戶對小程序要求統計數據來看，數據分析及統計和數據更改都是最基本的，同步帳本和提醒功能雖比重不大，但也是咱們項目的一個發展趨勢。
  • 綜上總結了記帳小程序最本質的開發需求是：以簡爲本，在基本記帳功能之上進行分類細則的數據分析與界面美化。
• A（Approach）
  向微信方申請搭建一個我的性質的微信小程序。用戶經過微信搜索咱們的小程序後直接使用微信註冊綁定使用。
  完成基本的基礎記帳的功能後，就能夠推出去給客戶試用一下，看看用戶有什麼反饋的要求，或者改進的地方，好的方面及時商討改進，方便後續更多功能的推動，若固步自封地作，所有完成後反而不知足客戶需求，很難倒回頭改進。
  小程序第一版後端使用java+SQL數據庫，前端使用HTML + javascript+css。小程序風格以簡潔爲主。前期主要將基礎功能作好作強大，後期再不斷迭代更新。
• B(Benefit)
  成本低：咱們的微記帳小程序是一種無需下載安裝便可使用的應用，能以最低成本觸達用戶，減小用戶成本，釋放手機內存量。
  靈活性高：替代傳統麻煩的手工記帳，實現記帳簡單化、方便化、數據化。

• C(competitors)
  1)其餘小組帶來的競爭
  2)其餘微信記帳小程序開發者帶來的競爭
  優點：咱們團隊人員積極合做，並且你們住在一塊兒能夠第一時間瞭解項目進度，並及時修改或更新。
  劣勢：都是大學生，項目經驗不足，能力稍有欠缺。
  優點：經過簡單調查，目前同類型的微信小程序功能大都不齊全不完善，不存在已經很強大健全的記帳小程序，開發空間仍是很大的。
  劣勢：記帳app能夠不用網絡就可記帳，而咱們的記帳小程序必須鏈接網絡登陸微信才能使用。

• D(delivery)
  微信小程序本就自帶推廣，大大減輕了咱們的推廣工做量；而且小程序特色之一就是隻要使用過便是用戶，只要在微信內搜索過記帳小程序並進入咱們的微記帳，就會產生用戶，隨着時間，咱們會產生固定用戶，繼而有了大的流量產生，咱們的微記帳也會在用戶搜素記帳小程序是排名愈來愈靠前，交付推廣就更容易簡單了。

殺手功能

相較於其餘同類的記帳小程序：
咱們增長了數據導出備份的功能，這樣即便用戶清除了歷史帳目記錄，也能夠經過備份再次查到，減小用戶丟失數據的損失；
還增長了帳單添加的功能，例如：默認帳單能夠記錄用戶我的全部支出消費結餘等，生意帳單能夠記錄用戶公有的財務支出收入等，還有旅遊帳單…….

一段話

各位用戶朋友們：咱們的產品 <微記帳小程序> 是爲了解決手工記帳和APP記帳用戶的痛苦, 他們在現有的記帳工具中不能明確的瞭解自身的收支情況且清除記錄後沒法找到數據，易形成損失；可是現有的方案並無很好地解決這些需求， 咱們有獨特的辦法，首先咱們增長了數據備份這項功能，而且也增長了收支情況的分類統計圖表、對比統計圖表、趨勢統計圖表，它能讓用戶清晰快速的瞭解本身的收支情況而且加以對比和估算，也大大的減小了數據丟失所形成的的重大損失，遠遠超過目前市場上的競爭對手（同類型記帳小程序）。 同時，咱們有高效率的推廣方法（利用微信自身海量用戶的優點），能很快地讓大部分用戶知道咱們的產品，並進一步傳播。

---

視頻連接入口

---

4.團隊協做，增強分工，須要描述每一個成員的具體分工及佔整個文檔任務的工做量比例。

參考

• 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.給目標用戶展示原型，與目標用戶進一步溝通理解需求。

• 思考：他們的痛是什麼？場景是什麼？（用產品以前/以後，有照片或視頻顯示用戶調查的過程，使用了各類調查手段的，加分）
• 參考：
  • 《構建之法》第10章典型用戶和場景
  • http://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html

  • 阿里巴巴衛哲：http://iamsujie.com/8000/8018/

    場景：用戶使用產品的過程當中
    痛點：剛開始想要要點擊圖標按鈕，但實際上點擊按鈕下面的小字才能實現功能的切換。
    這會使剛接觸使用的人不能較好適應。以致於一直點擊圖標卻沒有反應。調研拍攝圖片以下：

用戶體驗界面

初始界面（記帳、顯示當月收支及預算）

報表界面（根據預算值顯示總收入支出及結餘）

帳單界面（設置月預算及關鍵字搜索記錄）

帳本界面（新建帳本及查看當前帳本總額記錄）

登陸界面（經過郵箱記帳提醒及導出數據到郵箱）

調研拍攝

---

原型工具參考

若是是設計原型，採用專門的原型設計工具，可以事半功倍，工具參考：

• 移動應用原型與線框工具-墨刀
• 原型設計界的PS -Axure RP，Axure
• 網頁和移動端的設計sketch
• 一款簡潔高效的原型圖設計工具mockplus
• 致力於高保真原型製做工具Justinmind
• 一款免費的帶有手繪塗鴉風格的原型設計軟件balsamiq mockups
• 更多選擇，請參考：https://www.zhihu.com/question/19592829

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

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

原型設計連接

---

任務分解WBS

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

1.請給出團隊項目的WBS

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

成員	負責模塊	估計時間
顧芷菱 丁蓉	報表模塊	210h
林羽晴 洪亞文	帳單模塊	210h
秦貞一 齊暢	用戶模塊	200h

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

• 代碼風格規範
  • 基本間距：
    • 縮進：4個空格
    • 行寬：100字符
  • 條件執行塊：
    • 條件表達式：在複雜的條件表達式中增長括號加強邏輯性，如if ( (A||B) & ( (A&B) || (A||B) ) )
    • 格式：斷行與空白的{ }行，
      如:
      if ( condition)
      {
      DoSomething();
      }
      else
      {
      DoSomethingElse();
      }
  • 分行：
    • 變量定義:將不一樣的變量分別分行定義
      如：
      Foo foo1, foo2; （錯）
      Foo foo1；
      Foo foo2； （對）
    • 多行語句：分行放
      如：
      a = 1; b = 2; （錯）
      a = 1;
      b = 2; （對）
      if (fFoo) Bar(); （錯）
      if (fFoo)
      Bar(); （對）
      
  • 變量名稱：
    • 命名：匈牙利命名法，能夠直觀看出變量的類型或存在的意義
    • 下劃線：分隔變量名字中的做用域標註和變量的語義，如：people結構體中的student爲p_student
    • 大小寫問題：全部變量及函數的名稱均使用camel式，每一個單詞首字母大寫，如：StuInfo，GetInfo()
  • 註釋
    • 內容：註釋的內容僅爲程序的用途和緣由
    • 符號：源程序和註釋都使用ASCII字符
    • 函數頭註釋解釋函數的參數類型，若程序說明則省去
• 代碼設計規範
  • 函數：只實現一個功能
  • goto：使用goto語句實現無條件轉移，加強程序的邏輯性
  • 參數的處理：對傳遞過來的參數進行驗證
    • 斷言：參數百分百正確，直接Assert
    • 錯誤處理：設置條件語句的斷定，對不一樣的斷定作不一樣的處理
  • 類的使用：
    • 在必要的時候才使用，數據的封裝用結構體就行，減少開銷
    • 成員變量：用下劃線指明所屬域
    • 修飾詞：按照public、protected、private的次序來講明類中的成員
    • 構造函數：只用來簡單初始化數據成員，不能有返回錯誤的操做
    • 運算符：簡單運算狀況下直接使用不要從新定義，複雜操做才定義成函數進行運算
    • 異常
      • 不要用異常做爲邏輯控制來處理程序的主要流程
      • 使用時須要明確數據被清理的地方

---

系統設計

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

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

（1）微信小程序主要由3個全局的文件和一些與頁面相關的文件組成

文件	做用及說明
app.js	邏輯部分，用於編寫全局的事件
app.json	用於配置微信小程序
app.wxss	公共樣式表，用於設置可使用的樣式

（2）系統結構簡單描述

• 前端設計：
  前端是直接提供給用戶的，屬於視圖層面的，是最直觀的，須要保證界面的美觀，能夠給人用的，並且還要保證易上手，知足大多數人的使用習慣。

• 後臺開發：
  後臺是爲了在各個不通的界面中，實現不一樣的功能。若是隻有良好的界面，沒有後臺的支持，那這個產品也只是一個空殼。假設用戶經過點擊某一個功能按鈕，爲達到其效果，就須要從後臺調取數據，根據不一樣的需求呈現給用戶，而這些是屬於邏輯層面的

• 搭建服務器，提供數據服務：
  咱們作的是基於微信平臺的記帳小程序，須要保存用戶大量的數據，並且還要保持數據的同步，咱們將採用mysql，優勢是易操做，咱們還須要搭建web服務器，爲用戶提供http service

（3）系統結構圖:

2.完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖（若是必要）

E-R圖說明：

• 一個用戶的微信名是惟一的，咱們能夠經過存儲微信名的方式直接找到暱稱和微信頭像，用戶綁定郵箱無關緊要，用於導出帳單數據和提醒用戶記帳
• 一個用戶能夠擁有多個帳單，帳單的每一個數據項包含帳單編號（自增），帳單類型編號，時間，備註，消費類型，金額（+爲入，-爲出）
• 一個用戶有多個月預算，帳單類型和年月做爲主鍵，保證惟一
• 消費類型表，好比生活用品，服裝，飲食，車費等等，用戶還能自定義類型
• 帳單類型表，好比生意帳單，生活消費帳單等等，用戶一樣也能添加自定義類型

參考

• 分析設計方法：
• 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編寫與視頻、用戶需求分析調查及《軟件規格說明書》編寫等。
  ①關於用戶需求調查，咱們採用調查問卷的方式，收集了90人左右的調查結果。經過結果瞭解了用戶的需求及痛點，找到從此項目開發的側重點，知足用戶需求
  ②在編寫軟件規格說明書的時候遇到了一些麻煩，從網上搜索得來的模版看起來很正式很高檔，一開始甚至有寫專業名詞都看不懂，寫起來比較一頭霧水。固然，從編寫的過程當中也獲得了編寫規範文檔的經驗與方法。
  ③NABCD編寫是參照老師給的一些參考連接結合本身項目的實際狀況寫的，印象深入的是宣傳視頻的製做，咱們倆採用的是幽默詼諧的方式，但願能給咱們的項目起到正面積極的宣傳做用。
  從此你們也一塊兒繼續加油吧~

• 丁蓉
  本週博客用戶需求分析模塊是由我和顧芷菱負責，包括用戶調查，編寫《軟件需求規格說明書》以及編寫NABCD和拍視頻。 軟件需求規格說明書那邊真的是有點難寫，看了不少模版，大多都是寫了四五十頁，咱們經驗不足不太清楚具體怎麼寫，因此用了好久的時間，也才初步完成，而後又修改了一遍，最後組長羽晴又再次修改了一遍，足以說明這個真的很差寫，而後咱們很認真哈哈。還有就是我和個人搭檔顧芷菱的視頻啦，頗有意思？！但願你們能夠用一種放鬆的心情來了解咱們的產品。相信咱們會越作越好的。

• 洪亞文
  本週我主要負責的是熟悉微信小程序後端的編程開發爲後面作好編程準備，本週博客部分因爲內容較多，我負責的是整個編碼規範的部分，通過討論以後發現不少因爲不一樣編碼風格會影響了代碼的可讀性比較差，所以代碼規範一系列仍是特別有必要達到一致性的。
  其次是我以爲這個項目在初始階段作這些準備工做，好比需求分析,代碼規範等，都是在爲後續工做打基礎，可是我以爲若是在後續編程工做中還要繼續完成量大的博客任務可能有點吃力，特別是衝刺階段兩天一篇博客，但願老師能夠酌情分配任務，留更多的時間在開發之上

• 秦貞一
  本週我主要負責原型設計這一塊，所用的工具是墨刀，在肯定了軟件的功能便開始着手設計，一開始的時候沒有什麼頭緒，不知道如何將功能如何很好的分塊並實如今不一樣的界面中，後來便參考了其餘的記帳的軟件，再結合咱們的記帳軟件的具體需求，設計界面也是水到渠成。
  可是墨刀設計的侷限性，不少功可以作了簡便化的處理，如報表那一塊，並無圖標的實例，只能在設計完成後和組員說明狀況。通過這一週的設計，相信在接下來的時間裏，咱們會作的更好。

• 齊暢 這周我和我主要負責原型設計中的用戶調查關於痛點的問題，並拍了視頻圖片。以及和隊友們在朋友圈微信廣撒網，積累了大量的問卷調查的數據，有較強的說服力。完成了基本的市場需求分析。開了兩次會，就功能實現展開激烈的討論，並最終造成了整個項目的構架。 感想：下面兩週就是衝刺周了。咱們也準備買雲服務器，爲數據庫實現作準備。基本上能夠想象天天的平常除了上課，吃飯睡覺，剩下的時間可能都是跟五個隊友一塊兒吧。雖然有點殘忍，易審美疲勞，但一想到若是堅持到兩週後，看到基本成型的小程序，那再痛苦也是值得的！