需求分析
軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。
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） - 同學們的實際作業例子：
原型設計
原型設計能夠在表現層將設計合成一個邏輯整體，用戶能和你一起看到未來交互的軟件藍圖、功能和效果，獲得較真實的感受，在不斷討論的基礎上完善未來的設計思想。因此，原型設計能起到有效溝通的作用，漂亮，直觀的原型圖更是讓人賞心悅目。
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也展示了他們和諧的團隊協作。
原型設計鏈接
任務分解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和拍視頻。 軟件需求規格說明書那邊真的是有點難寫，看了很多模版，大多都是寫了四五十頁，我們經驗不足不太清楚具體怎么寫，所以用了很久的時間，也才初步完成，然后又修改了一遍，最后組長羽晴又再次修改了一遍，足以說明這個真的不好寫，然后我們很認真哈哈。還有就是我和我的搭檔顧芷菱的視頻啦，很有意思？！希望大家可以用一種放松的心情來了解我們的產品。相信我們會越做越好的。
- 洪亞文
本周我主要負責的是熟悉微信小程序后端的編程開發為后面做好編程准備，本周博客部分由於內容較多，我負責的是整個編碼規范的部分，經過討論之后發現很多由於不同編碼風格會影響了代碼的可讀性比較差，因此代碼規范一系列還是特別有必要達到一致性的。
其次是我覺得這個項目在初始階段做這些准備工作，比如需求分析,代碼規范等，都是在為后續工作打基礎，但是我覺得如果在后續編程工作中還要繼續完成量大的博客任務可能有點吃力，特別是沖刺階段兩天一篇博客，希望老師可以酌情分配任務，留更多的時間在開發之上
- 秦貞一
本周我主要負責原型設計這一塊，所用的工具是墨刀，在確定了軟件的功能便開始着手設計，一開始的時候沒有什么頭緒，不知道如何將功能如何很好的分塊並實現在不同的界面中，后來便參考了其他的記賬的軟件，再結合我們的記賬軟件的具體需求，設計界面也是水到渠成。
但是墨刀設計的局限性，很多功能夠做了簡便化的處理，如報表那一塊，並沒有圖標的實例，只能在設計完成后和組員說明情況。經過這一周的設計，相信在接下來的時間里，我們會做的更好。
- 齊暢
這周我和我主要負責原型設計中的用戶調查關於痛點的問題，並拍了視頻圖片。以及和隊友們在朋友圈微信廣撒網，積累了大量的問卷調查的數據，有較強的說服力。完成了基本的市場需求分析。開了兩次會，就功能實現展開激烈的討論，並最終形成了整個項目的構架。
感想：下面兩周就是沖刺周了。我們也准備買雲服務器，為數據庫實現做准備。基本上可以想象每天的日常除了上課，吃飯睡覺，剩下的時間可能都是跟五個隊友一起吧。雖然有點殘忍，易審美疲勞，但一想到如果堅持到兩周后，看到基本成型的小程序，那再痛苦也是值得的！