需求分析
軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。
1、 訪問軟件項目的真實用戶（至少10個），確保軟件真正體現用戶的需求，為軟件最終可用奠定基礎。
我們是寫的新項目，采用的用戶調研方式是調查問卷
調查問卷的git地址（https://gitee.com/kezhiqing/soft_team_blog/attach_files）
（1）調研目的
為什么要進行這次調研？可以是為了確認產品功能是否好用，可以是了解用戶喜好，可以是為了推廣新產品。
以這次調研為例，目的是通過用戶調研，理性了解用戶，根據他們的目的、行為和態度差異，將他們區分不
同類型，然后從每種類型中抽取出典型特征，賦予人群畫像，最終挖掘出不同人群對產品的偏好和潛在需求，
以及對品牌的認知程度，從而更好地進行產品設計及推廣。
(2)目標人群
因為我們的打卡小程序有自創話題的優勢，可以了解了各個年齡段的潛在需求，所以調查的年齡跨度相對比較大
(3)調研內容
就是要調研哪些層面的內容，用什么形式進行調研。例如這次我們重點是針對用戶小程序及其app關於打卡小程序的使用情況和使用態度設計調查問卷，並進行全站發放。研究發現大家更願意使用小程序來進行打卡，原因是小程序更加方便，而且用完即走，無需下載。所以挺有市場的
(4)、調研方法
第一步：划分用戶范圍
比如本次調研目標需要區分核心用戶、普通用戶，那么定義核心用戶為在XXXX年XX月，在打卡小程序發布過20個以上的話題並參與打卡活動完成，其他人則為普通用戶。
第二步：收集樣本數據
我們是利用網絡資源，在線上群發，請求線上各個年齡段的人幫助我們如實填寫調查問卷
第三步：聚類分析
我們調查發現大部分人堅持做一件有意義的最長時間集中在半年之內，其沒有堅持下去的原因大部分是因為沒有自制力，而大部分人覺得打卡能督促自己做一件事情或者養成習慣。所以微信打卡小程序的用戶大都是沒有自制力但是想堅持做一件有意義事的人和有自制力仍然願意參加打卡的人，其潛在用戶是沒有自制力需要勸說進行打卡的人。而我們小打卡程序就是希望通過打卡來督促大部分人堅持一件事
（4）數據來源說明
這次調查問卷投放五天的時間，主要通過在朋友圈和空間進行了投放，聚集團隊里六個人的朋友圈和空間，數據可信，實際回收了100多份問卷，有效問卷99。
（5）發現產品應該具備的功能
（6）總結
1、學生群體應該是潛在目標用戶，因為學生時代比較喜歡參與各種事物，並且可以參與的話題也比較多？
2、學生群體的特點是：學歷較高、習慣用使用微信並且可以說已經離不開微信。針對這一特點，我們是否可以考慮寫個公眾號啥的，在學生群體加粉絲，然后進行推送
3、很多人相信打卡能夠督促自己堅持一件事情或者養成好習慣，可以發展潛在客戶，讓更多客戶知道這個應用
4、有些人參與了打卡但是並沒有堅持，我們可以挖掘一些吸引人的功能，比如把獎勵機制做好，讓用戶願意堅持打卡並且從中發現樂趣。當然還有自創話題界面美觀等等
2、參考《軟件需求規格說明書》國標規范文本，撰寫對應項目的軟件需求規格說明書。提供《需求規格說明書》的Git鏈接。
除形式上滿足規范文本要求外，整體內容必須圍繞項目實質展開，對所要開發的項目確保盡力做到清晰完整准確。使用一致的圖形符號和文字描述內容。
我們的《需求規格說明書》的Git鏈接：
（ https://gitee.com/kezhiqing/soft_team_blog/attach_files）
3、NABCD 寫作，視頻
NABCD模型：
1) N (Need 需求)
大家經常會有這樣的行為：常常對自己說明天早起，卻還是經常睡過頭；給自己定了個小目標，每天要記60個單詞，卻總是三天打魚兩天曬網。當然，你可以讓同學或舍友提醒你。但是，時間一長，這顯然是行不通的。也有用戶會去下載相應的APP來監督自己,但是往往只用一小段時間，用完還要卸載，太不方便了。這時候，如果能有一個小程序，能監督自己去完成所定的目標，那用戶的痛苦就解決了。
2) A (Approach 做法)
開發一個微信打卡小程序，用戶在該小程序中可以先新建活動（用戶給自己定的任務），然后設置活動內容，活動時間等，待用戶完成該任務后，可以進入該打卡小程序通過發表打卡日記來完成打卡。
3) B (Benefit 好處)
談談我們團隊設計開發此打卡小程序的初衷在於，對自我行為的約束，良好習慣的養成，予以目標實現更大的可能性，這是較為寬泛的好處。
娓娓道來:
A.我們的產品在形式上可以給客戶帶來新鮮感，一方面由於以微信小程序通道的模式，減免了重新下載軟件的繁重感（畢竟現在還是有一大批小可愛的手機內存是16g的），另一方面以電子互聯網模式代替紙質計划的制定，避免了記錄的丟失和消息的閉塞，是極好的。
B.在體驗感上，我們的產品主要針對青少年學生（學業重）和上班族（壓力大），自然，界面要走小清新路線，一目了然，操作簡單上手容易，我們的原型設計框架結構清晰，相信我們最終交付的作品也不會有太大的偏差，滿足預期效果並且更好地去完善。
C.與此同時，我們的首頁發現模塊借鑒微博的類似功能，在此平台建立打卡，分享打卡日志，互相監督遇見與自己志同道合的一批人，與之結為好友，這是一個相對來說不可控卻又令人驚喜與期待的好處。
D.當然，現在市面上已經有諸如此類小程序的成功案例，比如，“小打卡”的功能就相對強大，而我們要做的，很明顯是競爭用戶群啊，先從身邊舍友好友同學推廣，擴至校園，再運營至更大的用戶空間和類型。從學生大眾角度出發，設計出一個界面美觀，功能完善的打卡程序。
E.至於在基本功能實現的基礎上，作為我們的殺手功能的“我的獎勵”模塊，也屬於畫龍點睛之作，后續將會詳細提及，在此就不一一贅述。
F.據說Benefit還可以指對自己團隊的好處，團隊每個人都很不錯，至少就目前進度而言，我們處於需求分析框架設計階段，每個人都積極提出自己的想法與見解，指出團隊設計上存在的缺點和不可行之處。術業有專攻，每個人都有擅長的模塊，就我而言（無名氏），視覺感受比較敏銳，審美較強，細心，瞎寫點東西的能力也還是過得去，自然，我選擇了前端開發，順便做個可愛的美工小姐姐，完全ojbk的hhh。
4) C (Competitors 競爭)
競爭的話，上述也有提到，市面上已存在此類打卡小程序，對比各小程序，較為成功的就屬“小打卡”了，而APP有待開發。基於團隊經驗值為零和前端基礎薄弱的情況，我們就先盡全力去實現微信小程序。我們的產品的優勢就在於提供獎勵機制，增加小程序的趣味性，可以吸引更多的顧客。
**5) D (Delivery 交付) **
最終成果交付，這個問題簡單回答，我們給自己的小程序設定的預期用戶數為30人，這個相對來說還是可行的（論親友團的重要性）。在微信朋友圈、qq空間、微博等發布相關動態，借用現有通訊介質，（各種美圖？）渲染宣傳效果。我們還可以在集大通朋友圈po出我們的作品，介紹基本功能和特色功能，實現校園用戶的普及，那么打卡的實際操作力將
大大提高。打個比方：創建一個夜跑活動，在首頁推送，同集大的學生加入后，相互了解認識（確保可靠性），一起去萬人夜跑啊，減肥健身得終身踐行，可不就是開啟一段從虛擬世界走向現實的革命友誼。
將NABCD組織成一段話：
各位用戶小伙伴你們好，我們的產品“滴卡錄”，首先我們的名字就很可愛了，它是為了解決青少年學生自制力的匱乏、上班族工作壓力大的痛苦而量身打造，他們需要制定目標、約束行為、養成良好習慣、與此同時享受生活 。但是現有的方案並沒有很好地解決這些需求，我們有獨特的辦法 ，就是開發一個微信打卡小程序，操作簡單上手容易。它能給用戶帶來的好處數不勝數，例如，界面新鮮感和使用體驗感良好，分享打卡結識好友，獎勵制度是我們的殺手功能，遠遠超過目前市場上的競爭對手微信“小打卡”、“易打卡”、“計划控”團隊。同時，我們有高效率的成果交付方法，比如現在這種面基的形式就很不錯，能很快地讓大部分用戶知道我們的產品，並進一步傳播。
殺手功能：
用戶一旦新建完一個活動，即可獲得一棵樹的種子。根據用戶新建活動中的活動時間，用戶所能選擇的樹的品種也不一樣。用戶每完成一次打卡，即可獲得相應的能量（總的能量/天數）。若在活動期間存在未打卡情況，那么這棵樹就立馬枯萎。只有打卡全部完成，才能獲得這棵樹作為獎勵。
附加題：
視頻鏈接：（https://m.weibo.cn/5702894875/4227758076947602 ）
4、團隊協作，加強分工，需要描述每個成員的具體分工及占整個文檔任務的工作量比例。
5、原型設計
原型設計能夠在表現層將設計合成一個邏輯整體，用戶能和你一起看到未來交互的軟件藍圖、功能和效果，獲得較真實的感受，在不斷討論的基礎上完善未來的設計思想。因此，原型設計能起到有效溝通的作用，漂亮，直觀的原型圖更是讓人賞心悅目。不要等到所有代碼寫好之后再去驗證需求，請用設計工具描述用戶界面和需求。原型設計不僅要考慮主要功能的頁面排布，同時也要考慮用戶實際操作中的問題，提前為用戶考慮得當並征求用戶意見系統是必須可運行的，可實際使用的——請抱着這樣的同理心去考慮系統。
給目標用戶展現原型，與目標用戶進一步溝通理解需求。
原型設計工具：墨刀
原型設計結果鏈接：滴卡錄
（1）“滴卡錄”小程序入口界面
（2）首頁界面
（3）進入Keep健身計划活動界面
（4）點擊立即加入活動，選擇是否打卡界面
（5）點擊“+”后進入的界面
（6）新建活動界面
（7）活動選擇界面
（8）編輯打卡日記界面
（9）進入“我的”界面
（10）我參與的活動界面
（11）可查看該活動詳情及參與者的動態界面
（12）我的打卡記錄界面
6、任務分解WBS
一個團隊項目要在一段時間內完成諸多任務，滿足用戶需求，實現團隊目標，從哪里入手？
WBS（Work Breakdown Structure）即工作分解結構，是根據項目目標把工作分解成許多層次分明的、可交付成果的工作任務，然后用邏輯圖形或樹形結構表示出來。
請給出團隊項目的WBS；團隊成員估計各自任務所需時間
一個團隊項目要在一段時間內完成諸多任務，滿足用戶需求，實現團隊目標，從哪里入手？
WBS（Work Breakdown Structure）即工作分解結構，是根據項目目標把工作分解成許多層次分明的、可交付成果的工作任務，然后用邏輯圖形或樹形結構表示出來。
6.1.請給出團隊項目的WBS；
- 前端：郭煒埕 廖怡潔 包夢榕
- 后端：鄭曉麗 柯智青 黃曉楊
6.2.團隊成員估計各自任務所需時間
| 成員 | 任務 | 所需時間 |
|---|---|---|
| 郭煒埕 | “首頁”前端 | 3天 |
| 廖怡潔 | “我的”前端 | 4天 |
| 包夢榕 | “新建”前端和“我的”前端 | 4天 |
| 鄭曉麗 | “首頁”后端 | 5天 |
| 黃曉楊 | “我的”后端 | 7天 |
| 柯智青 | “新建”后端和“我的”后端 | 7天 |
7、編碼規范
8、系統設計
在設計階段，我們要清楚：軟件是怎么解決這些需求的？一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的接口，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖
滴卡錄架構設計
ER圖
9、個人感想
- 郭煒埕：在本周團隊合作中，我主要負責的是用戶調研和軟件需求規格說明書的攥寫。關於用戶調研，我們應用了問卷星進行線上的問卷調查，通過分享朋友圈、轉發到群的方式，在短短兩天內，有99人填寫了問卷。這個數量我個人是滿意的，也在此感謝每一位參與調研的朋友！再者，關於軟件需求規格說明書，我們參考了老師給的模板，自己也上網查找了許多資料。從一開始無從下手，到后來理清頭緒完成說明書的攥寫，還蠻有成就感的。我們已將部分文檔上傳至項目Git，也期待下一次的合作。
- 鄭曉麗：這次博客量比較多，所以我們分工完成，可以說特別和諧了，而且效率也不錯。組長分配有方，組員積極完成。然后我負責的是用戶調研和需求規格說明書完善及博客整合。感覺問卷是用戶調研不錯的方式，畢竟在網上，所以可以很快找到用戶幫忙填寫。在博客整合的過程中，發現組里的其他成員都很厲害，用心得完成了自己的任務，而且完成得很好，察覺到自己平時不夠細心的缺點。這樣團隊合作的方式，可以讓你發現別人的優點認識自己的不足的，取長補短。
- 廖怡潔：當我在做WBS的時候，先了解了一下如何做任務分解，通過查書、百度種種方法全面獲悉應該如何着手，然后我發現用通俗的話來解釋其實就是分工明細每個人的任務，之后我們經過商量討論，就畫出了分工的邏輯圖，並且也商討了編碼規范，按照書上的編碼規范，一項一項羅列出來，給出了一個個明確的標准，以后我們就按着這個標准寫代碼。看着我們一步步為這個小程序開始做各種准備，很有凝聚力的感覺。
- 包夢榕：本周博客我們團隊進行了各自的分工合作，我和我的舍友負責需求分析中的NABCD分析和原型設計。感覺這兩個任務相對來說，NABCD設計還是比較簡單的，只要把各點理清楚寫起來得心應手，最后的視頻錄制比較尬就是了；原型設計也是特別有趣的，以前嗯沒有接觸過使用墨刀進行界面設計，第一次和舍友一起共同設計。兩個人對着一台電腦互相討論（后來做完了才知道是可以兩台電腦共享，浪費了些時間），（在此之前我們團隊討論了很久的原型設計，可以說是很用心了），將各自的設計想法po出，一旦有錯誤的如圖標鏈接另一個人及時糾正指出，或者有更好的比如圖標選擇，這也很考驗我們的審美力哈哈，這個過程給我的感覺有點像我之前做過的微信文編輯，充分地體驗了合作的樂趣。不斷地進行修改查看的循環操作，樂此不疲，沒錯啊，這個過程我們委實是對精致的豬豬女孩了d(`･∀･)b。
- 柯智青：在這次團隊合作中，我參與了原型設計和需求分析中的NABCD分析，體會到項目不是隨隨便便就開始做的。項目前期要進行需求分析，原型設計，系統設計等一系列工作。完成這些任務后，對我們所要進行的小程序開發有了更進一步的認識。在小組討論進行任務分配及原型設計過程中算是比較順利的，大家的積極性比較高，希望下周進行沖刺的時候繼續保持這種狀態。
- 黃曉楊：這次博客我主要負責系統設計這一部分，這又分架構設計和數據庫設計。我對於架構設計的概念比較模糊，所以在百度過后，根據自己的理解大致寫了一下關於小程序整體的實現方式，具體的語言之類的還沒有確定。然后就是數據庫，在仔細分析討論過后才得出了這樣的一個設計，但后續的開發中，可能還會有一些細小的改動和完善。