基於移動端的問答系統--需求分析與原型設計

1、前言

一、結對者:2015034643032 孔潭活、2015034643023 周宏傑微信

二、需求分析模型:NABCD 模型網絡

三、原型設計工具:Axure RP 八、墨刀、FSCaptureapp

 

2、結對過程

 

 

 

3、需求分析

一、N(Need,需求):

  • 大學生做爲社會新技術、新思想的前沿羣體,在大學期間可否將本身鍛形成特點鮮明的應用型人才尤其重要,而這款基於移動端的問答系統能夠幫他們保持前沿的思惟與認知工具

  • 這個問答系統在大學生離開課堂後,在課外遇到本身沒法解決的問題時,自學和求學的能力稍顯疲軟是的時候,在線的互動能夠提高他們的求知慾學習

  • 在網絡上百度、360等搜索引擎和各類平臺涉及領域廣,提供的信息參差不齊、有些信息不具時效性甚至還出現信息出錯等狀況時,這款基於移動端的問答系統能夠幫他們得到精確的第一手信息,並配備健全的在線自學與諮詢體系
  • 對於高校學生來說,這個問答系統可以使得新生獲得老生和教師的指導,瞭解企業的就業實習信息、學習大量的經驗,所以可使得他們成長的高度會遠遠高於原先的成長高度

 

二、A(Approach,作法):

  這個基於移動端的問答平臺在校園中能有一個針對大學生高質量垂直交流的知識共享平臺,將學生、教師以及企業統一聯繫起來,讓學生能在課堂之外,可以獲得老生和教師的指導,瞭解企業的就業實習信息、學習大量的經驗,成長的高度會遠遠高於原先的成長高度。當這羣新生成長起來,他們又會去給新一屆的新生解惑,新的新生得指導會比以前的新生獲得的還要好,新的新生成長起來的高度再一次提升,如此良性循環下去,該校會造成本身內部的專屬學習交流圈,幫助新生快速適應大學的學習生活,同時也爲企業輸送人才鋪下技術基礎和提供了招聘渠道,能夠說是開闢了大學課堂之外的學習輔導途徑。測試

       學生註冊登陸平臺,便可發佈校園平常問題和學術問題,查看校園最新資訊。平常問題能夠查問校園學習攻略、周邊攻略、比賽詳情、心理調節、人生規劃、就業實習、社團活動等;學術問題可讓學生探討專業問題,解決學習上的困惑,咱們會與校方合做,邀請老師和優秀的師兄師姐進行解答;校園資訊包括最新的比賽通知、校內企業實訓課、校內舉辦的活動等,比賽資源來自於網絡上的網站搜尋和校內官網的發佈,涵蓋各專業。網站

 

三、B(Benefit,好處):

       當在讀的高校學生會遇到各類問題,僅僅向網上的百度求助和向身邊的人請教是遠遠不夠的。而這樣一個專門針對高校師生面對的各類問題的問答平臺,供高校師生使用,在這個平臺上在讀的高校學生能夠發表一些平常遇到的問題或者難以獨自解決的問題,平臺回答者都是有經驗的師兄或者是老師,可以及時給提問者帶來優秀的答案。在「校答人」平臺上,學生能夠掌握一手校園資訊。「校答人」平臺上涉及學習、競賽、社團、心理、職業方向與人生規劃以及就業實習等方面,用戶能夠經過提問獲取答覆,本身也能夠依據本身的能力,充當回答者爲他人排憂解難。搜索引擎

 

四、C(Competitors,競爭):

       如今的問答平臺正逐漸打破以往免費分享知識的慣性思惟,正在轉向提供高質量回答的知識付費,向共享經濟領域進發,知識付費問答平臺愈來愈受人們關注,目前比較有影響力的付費平臺有大弓、知乎、分答等等。016年,有知識付費意願的用戶暴漲了3倍,知識付費用戶達到近5000萬人,截止到2017年3月,用戶知識付費可估算的整體經濟規模爲100-150億左右。因爲各行各業的人數增多,自身身份和職業常見問題的知識需求增長,當前問答平臺正在向專業化與行業化過渡發展,好比有餐飲版的「餐答」,職場版的「業問」,醫療版的「來問醫生」,體育版的「映答」,知識分享平臺的內容生態還在不斷豐富創新,但目前卻沒有針對大學生高質量垂直交流的知識共享平臺。衆所周知,現在大學生是一個很是龐大的羣體。編碼

     以下圖所示,截止2016年,大學生數量已由15年前的114萬人狂飆至765萬人,該羣體之大,讓咱們不得不思考着爲這個羣體定製一些屬於他們青春活力的產品,所以這款基於移動端的問答平臺就是在免費與付費的梯度上展開競爭,固然,也可使用先免費,積累到必定用戶後再考慮收費問題,關鍵在於有付費一定存在免費。spa

 

 

 

五、D(Delivery,推廣):

  原型設計完成後,便可進行開發,並經過相應的廣告平臺作相應宣傳與推廣,固然,起步階段爲了推廣,可作相應的優惠政策。

 

4、原型設計

 

註冊頁面原型 

 

 

登陸頁面原型

 

 

首頁原型

 

 

校園頁面原型

 

 

提問頁面原型

 

 

消息頁面原型

 

 

個人頁面原型 

 

5、總結

  兵馬未動,糧草先行,或許開發中也能夠應用這個道理吧,在時間充足的狀況下,多寫這種需求分析與原型設計是頗有必要的,然而現實骨感,不少事情是不會以一我的的意志爲轉移的,咱們如今的目標也不是成爲全棧工程師,而是先往一個方向深刻學習,而不是這樣所謂的走一個完整項目流程,一個完整的開發流程應該走,但不是這樣走,言盡於此,畢竟已經寫完了......我不是個麻瓜,但在全部的事情過程當中,我最大的感覺只有合做,我也一直堅信咱們應該學會合做,但咱們最缺少的就是合做......

  一言難盡,說來話長,想聽的關注微信公衆號 compassblog ,直接後臺聯繫我吧。

 

6、PSP 表格

 

 

 

預計耗時(分鐘)

實際耗時(分鐘)

Planning

計劃

30

30

Estimate

估計這個任務須要多少時間

60

60

Development

開發

120

120

Analysis

需求分析

20

20

Design Spec

生成設計文檔

0

Design Review

設計複審(和同事審覈設計文檔)

0

0

Coding Standerd

代碼規範(爲目前的開發制定合適的規範)

0

Design

具體設計

30

50

Coding

具體編碼

0

0

Code Review

代碼複審

0

0

Text

測試(自測,修改代碼,提交修改)

0

0

Reporting

報告

30

50

Text Report

測試報告

20

30

Size Measurement

計算工做量

2

 1

Postmortem & Process Improvement Plan

過後總結,並提出過程改進計劃

0

 0

Sum

合計

312

361

 

掃描二維碼關注微信公衆號,瞭解更多

相關文章
相關標籤/搜索