軟工1816 · 第七次作業 - 需求分析報告
阿新 • • 發佈:2018-11-04
軟工1816 · 第七次作業 - 需求分析報告
組長本次作業的部落格
評審表
《需求規格說明書》
成員分工明細以及TODO-list
負責人 | 分工明細 | TODO-list |
---|---|---|
白晨曦 | 1.規劃專案程序;2.組織會議、分配任務;3.負責UI設計;4.參與文件擬寫 | 完成各個介面的UI設計稿 |
陳德斌 | 輔助專案原型的邏輯功能設計 | 協同同何裕捷完成專案原型邏輯功能設計 |
林志華 | 1.負責前端的開發;2.輔助pm進行專案規劃 | 個人資訊模組前端開發 |
何裕捷 | 負責專案原型的邏輯功能設計 | 完成專案原型邏輯功能設計 |
黃培鑫 | 負責前端的設計、開發 | 完成登陸註冊模組前端開發 |
蔡子陽 | 負責網路介面 | 完成網路介面的設計與開發 |
李麒 | 1.負責後臺的設計、搭建;2.主要功能程式編寫 | 完成後臺構建以及累計反饋模組的實現 |
樂忠豪 | 1.輔助後臺的設計、搭建;2.搭建資料庫 | 鬧鐘模組的實現,搭建資料庫 |
王煥仁 | 1.輔助後臺的設計、搭建;2.輔助主要功能編寫 | 計劃模組的實現 |
專案logo
思維導圖
團隊評估
- 團隊分工與貢獻比例(100):
- 白晨曦(10):視訊和ui。
- 陳德斌(5):E-R圖及資料流圖的製作。
- 林志華(10):需求分析報告第四章前半部分4.1到4.5。
- 何裕捷(10):需求分析報告第二章、思維導圖的製作。
- 黃培鑫(10):需求分析報告第四章後半部分4.6驗收驗證標準與4.7屬性。
- 蔡子陽(30):需求分析報告整合,ppt製作及演講。
- 李麒(10):部落格的撰寫、回答提問。
- 樂忠豪(10):評審表設計及總結,需求分析報告引言編寫。
- 王煥仁(5):調查報告。
答辯總結
在11月03日的答辯現場我們得到的平均分為:75.25分
第一組:
- 問:宣傳視訊沒有體現出產品的功能
- 答:確實視訊製作倉促、質量不足,我們會吸取教訓並完善。
- 問:專案需求分析報告的排版有瑕疵
- 答:需求分析報告確實存在瑕疵,我們會進行改良,上傳的最終版本也歡迎各位指正。
- 問:展示的PPT中沒有體現出“關聯鬧鐘“這個專案特色
- 答:PPT中對於關聯的體現確實不足,我們會進一步的完善,突出產品的特色。
第二組:
- 問:使用該軟體的核心功能需要聯網
- 答:關於聯網的問題,首先鬧鐘本身的功能是不會受到影響,但監督、提醒(指隊友訊息,自定義備忘不會受到影響)等功能會受限,這是沒辦法避免的。
- 問:後臺軟體會被自動關閉
- 答:關於這點,我們會鎖定軟體,保持程序,同時也不會佔用太多後臺。
第三組:
- 問:沒有實際列出異常處理的情況
- 答:PPT中有對異常的情況歸納,但處理方案展示不到位,我們會加以改進,相應的處理情況在需求分析報告中有詳解。
- 問:沒有將盈利考慮在內
- 答:盈利問題是有考慮的,但是沒有展示出來是我們的失誤,我們會在需求分析報告中補足。
- 問:產品週期較短,新鮮度較低
- 答:我們的成長反饋模組會針對趣味性加以完善,同時我們也會積極收集使用者反饋,保持一定週期的趣味性功能更新。
第四組:
- 問:PPT原型設計部分有些圖片過暗
- 答:使用者可以自行選擇圖片作為背景,同時現場所說的夜間模式,我們也會考慮加入。
- 問:惡意修改時間這個現象無法解決
- 答:響鈴時間的確定是需要所有組員同意的,而修改時間也是一樣的。
- 問:沒有展示思維導圖
- 答:PPT展示不到位,我們會吸取教訓並完善,思維導圖會在部落格和需求報告中體現。
第五組:
第六組:
- 問:視訊有點簡陋
- 答:視訊製作倉促、質量不足,我們會吸取教訓並完善。
- 問:原型某些頁面存在佈局不清晰的情況
- 答:我們會進行相應的修改,做到簡潔美觀。
- 問:沒有看到logo
- 答:logo在PPT的最後幾頁,可能展示太快,說明略簡略,給你們的印象不深刻,我們會修改PPT,將logo放在前幾頁。
第七組:
- 問:音訊不清
- 答:視訊製作倉促、質量不足,我們會吸取教訓並完善。
- 問:PPT和文件的排版有點問題
- 答:排版確實存在瑕疵,我們會進行改良,上傳的最終版本也歡迎各位指正。
- 問:備忘錄可能跟核心功能關聯不是很大,可以考慮做成嵌入的
- 答:備忘錄是一個附屬功能,幫組使用者記憶和區別事件的,我們會考慮你們的建議。
第八組:
- 問:競爭力不強
- 答:我們的產品專案的核心互動和亮點在關聯上,具有提高團隊效率、增進隊友(情侶)互動等優勢,同時我們力求做趣味性產品,保持使用者的新鮮感。且就目前現狀而言,大多數app功能都較為單一、體驗一般且使用者粘性差。我們要做的應該是看到前輩的不足,反饋到自己,認真思考並吸取教訓,在現有的市場基礎上不斷完善我們的app,推出高階功能,提高使用者體驗,增加產品的競爭力。
- 問:使用的場景受限
- 答:為了方便說明,我們選用團隊、研友、情侶作為例子,但並不侷限於這些,只要有組隊需求,例如組隊晨跑、登山、逛街、遊玩等,都可以使用。
第九組:
- 問:PPT排版存在問題
- 答:排版確實存在瑕疵,我們會進行改良,上傳的最終版本也歡迎各位指正。
- 問:離線時的關聯已經說明過,但是產品的特色不是很明確,可能會和其他同類產品混淆
- 答:首先,傳統意義的鬧鐘又或是群通知等沒有共享鬧鐘和共享任務的功能。其次,我們會在之後的實際開發過程中,思考更具有團隊意義的關聯方式,比如一個團隊是一張圖,每個成員是其中一塊拼圖,只有所有人完成關聯任務,才會構成一張完整圖。
需求分析報告
我們聽取各方意見,對需求分析報告的排版、字型等進行了相應的修改,同時添加了盈利方面的內容
- 市場推廣
- (1)網路推廣:
宣傳視訊的製作及傳播
製作生動活潑的動畫向客戶展示APP的顏值、特色以及使用方式,並通過大學生最常使用的微博、QQ空間、微信朋友圈等方式大面積傳播,達到產品初步推廣的目的。
h5的製作及傳播
H5動畫頁面簡潔明瞭,有趣生動,能夠吸引大量人群點選觀看,簡單幾張介面就將產品的基本功能與特色完美展示,因此通過H5頁面對產品特性及使用方式進行介紹,既符合當代快節奏的生活方式,迎合受眾群體的口味,也能夠有效地推廣產品。
不定期釋出新活動和福利營銷,吸引使用者
推廣初期,將會不定期推出福利活動,如邀請好友贏得積分、兌換抽獎,高階功能免費試用,吸引更多的新使用者。 - (2)資訊平臺推廣:
建立微信、微博等公眾號,定期傳送軟文
如今微信已經成為年輕人生活中不可或缺的一部分,通過微信公眾號進行營銷也成為一種新型營銷形式。通過抓住年輕人的喜好,跟緊時代熱點,不斷推送生動有趣的文章,吸引受眾使用者的關注,並且不定期在公眾號上進行產品的宣傳與推廣,能夠達到一定的增加使用者量、提高使用者粘性的作用。
蹭熱點
在熱門平臺上展現活躍身姿,吸引目標使用者的關注 。
與其他平臺合作推廣
與年輕人使用頻率較高的的平臺、運營商進行合作,如學生較常訂閱的校園知名公眾號、微博知名大v,知乎大佬、星網銳捷等 - (3)線下推廣:
海報和傳單的定製使用。
與校內學生部門建立合作推廣關係。
不定期舉辦使用者交友會,提高知名度和使用者滿意度。
- (1)網路推廣:
- 營銷策略
- (1)福利營銷:
高階功能免費試用
為提高使用者量,開展邀請一個好友即可免費試用7天的營銷活動,免費試用天數可累加。
抽獎活動
在初期開展使用者下載APP獲得積分,可進行抽獎或兌換等活動。; - (2)軟文營銷:
抓住年輕人的喜好,跟緊時代熱點,推送生動有趣的文章,在熱門平臺上展現活躍身姿,吸引目標使用者的關注。 - (3)合作營銷
與知名公眾號、微博大v、熱門遊戲運營商等受眾群體相似的平臺合作,推送廣告以及開展系列主題活動。
- (1)福利營銷:
- 經營目標
- 在初期,以打入市場、擴大產品的知名度及推廣度為主。 中期以產品升級為主,當積累一定的使用者群體以後,開始重新定位使用者的需求,根據使用者需求研發新功能和升級、優化原先功能,為使用者提供更好的服務,從而推動產品的發展。同時在產品逐漸被接納認可以後進一步考慮如何擴大產品的淨收益利潤。但無論在那個階段,我們始終會堅持app的核心建設思想——致力於提高工作效率,鬧鐘成功率,介面簡約,打造有趣的效率工具。
- 財務分析
- 資金來源
- 前期軟體開發過程中,主要由團隊內部出資。開發完成後並經過各種測試,產品已穩定,小規模投入市場,如果反饋良好,可進一步向學校申請資助或者尋找天使投資人。如果發展良好,可以引入風險投資甚至銀行貸款。
- 盈利模式
- 會員收費盈利:
除免費使用的基本功能外,推出僅限付費會員使用的高階功能,並授予會員免廣告等一系列特權以吸引使用者付費。根據實際情況,針對使用者群體,會員費用設定為5-20元/月不等。 - 開設創意工坊:
使用者可以自己制定一定的元素,如累積反饋的元素,鬧鈴的鈴聲,製作好的計劃模板,掛在創意工坊進行買賣,我們收取其中的一些手續費,當然,創意工坊的東西也可以是免費的。-
- 會員收費盈利:
- 成本規劃
- 開發測試成本
主要是伺服器的租用費用,主流平臺的適合該應用的伺服器價格為200-400元/月。 - 推廣成本
平臺推廣預計需要200-300元/月。初期費用主要來自線下對附近在校大學生推廣,預計需要100-200元/月。
- 開發測試成本
- 收入預期
- 初期預計平均1000人的使用者量:
- 會員費收入:以5元/月收取會員費,隨著更多功能的推出與市場佔有率的增加,可以適當增加收費。以1%的會員率計算,每月會員收入約為50元。
- 創意:該收入與使用者量有關,也與很多人是否願意去製作有
- 資金來源
- 風險管理
- 技術風險及對策
該專案的技術應用可分為兩塊。- (1)常規技術比如我們前端所用的Android技術和後端使用的php指令碼語言及伺服器lamp環境。我們面臨的風險之一是團隊內還有部分成員屬於零基礎,對策是讓有經驗者輔助、帶領無經驗者,讓零基礎成員能夠在實踐與指導中快速成長。令人欣慰的是目前的it程式設計技術已十分成熟,而且可供學習的資料很多,完全能做到快速學習、快速掌握。
- (2)非常規技術,也就是我們目前因為技術問題暫時無法實現或者學習資料較少的技術。例如創意工坊功能,這要求較高的開發水準和編碼水平,而我們現屬於專案建立初期,水準相對不高,並且沒有太多的資源,這也是風險之一。而我們的對策是,根據迭代原則,初期以實現基本功能為主,不追求過分完美,從小到大,不斷提高團隊整體水平,在實踐中開拓眼界,學習和接觸新的未知技術,為之後完成產品的高階功能打下基礎。也會不斷通過分析開源平臺和市場上的例項,虛心學習借鑑,找尋到適合我們的實現方案。
- 潛在進入者風險及對策
- 目前這類app不少,潛在進入者門檻低,但以現在的狀況來看,大多效率app功能都較為單一、體驗一般且使用者粘性差。我們要做的應該是看到前輩的不足,反饋到自己,認真思考並吸取教訓,在現有的市場基礎上不斷完善我們的app,推出高階功能,提高使用者體驗,增加產品的競爭力。
- 技術風險及對策
遇到的困難及解決方法
- 困難:在需求分析報告上,著重點的掌握難以確定;由於PPT的製作和演講者要求不同於之前的答辯,生疏,對產品認知度的考察。
- 解決過程:我們參考了其他優秀的需求分析報告,並對報告的各個部分進行分工,最後整合完善,在統一寫作風格上下了不少的功夫;PPT的製作和演講者認真、負責地完成了這項工作,不斷地翻閱需求報告,同組長溝通,加深對產品的認知,避免生疏,但難免緊張,PPT展示有略微的不足。
PSP表格
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | 180 | 190 |
· Estimate | · 估計這個任務需要多少時間 | 5 | 5 |
Development | 開發 | 90 | 120 |
· Analysis | · 需求分析 (包括學習新技術) | 60 | 60 |
· Design Spec | · 生成設計文件 | 30 | 60 |
· Design Review | · 設計複審 (和同事稽核設計文件) | 0 | 0 |
· Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
· Design | · 具體設計 | 0 | 0 |
· Coding | · 具體編碼 | 0 | 0 |
· Code Review | · 程式碼複審 | 0 | 0 |
· Test | · 測試(自我測試,修改程式碼,提交修改) | 0 | 0 |
Reporting | 報告 | 80 | 80 |
· Test Report | · 測試報告 | 0 | 0 |
· Size Measurement | · 計算工作量 | 20 | 20 |
· Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 60 | 60 |
合計 | 350 | 390 |
學習進度表
第N周 | 新增程式碼(行) | 累計程式碼(行) | 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
---|---|---|---|---|---|
1 | 200 | 200 | 6 | 6 | Java複習 |
2 | 200 | 15 | 21 | 學習Axure RP8 | |
3 | 200 | 400 | 10 | 31 | Java學習 |
4 | 15 | 工具學習 | |||
5 | 20 | 工具學習 | |||
6 | 15 | 後臺搭建學習 |