1. 程式人生 > >福大軟工 · 第七次作業——需求分析報告

福大軟工 · 第七次作業——需求分析報告

【計劃安排】

 

1.團隊所有成員共同討論各部分實現功能,一共有4個功能,分別由5名成員負責各自的後端介面,2名同學負責前端介面,1名同學負責美工;

2.在11月8日前,美工組同學先完成介面主體設計,然後交由各引數於前端小組;

3.在11月8日——11月15日期間,前端小組根據美工小組同學的設計,完成前端的程式設計,與此同時,後端組自發討論學習各自功能的實現演算法;

4.在11月15日——11月20日期間,後端組完成各自的後端功能實現,並與前端介面相連線;

5.在11月20日——11月25日期間,團隊成員組織探討合併該專案,對於有缺陷或者未能實現的功能集中討論,改善專案。

 

  • 線上推廣

    • 在本院、校學生會以及各個班級組織推廣免費使用
  • 線下推廣

    • 與福建省其他高校一起推廣使用,體驗高效便捷的微信辦公軟體服務
    • 另外,在辦公區域,通過新增小程式等服務,贈送相關辦公用品

    【專案logo】

因為我們的專案名稱是WeEdit,所以我們的LOGO象形E,即辦公的意思,另外,用“...”以及鉛筆象形結合,展現出我們的主推功能“共享編輯”。底色的綠色的,主要是為了契合微信的圖示底色,我們竭盡全力地使這個小程式與微信進一步的貼切,減少使用者的使用難度,方便使用。

 

 

【思維導圖】

 

【團隊中個人的貢獻比例】

  • xxx:

    姓名 學習進度/任務 個人貢獻分
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx
    xxx xxx

    【評審表格設計】

    評審表PDF版

    【答辯總結】

  • 去除最高分(87)最低分(63)後的平均分:

    • 第一組:82
    • 第二組:77
    • 第四組:87
    • 第五組:63
    • 第六組:82
    • 第七組:79
    • 第八組:69
    • 第九組:
  • 第一組的問題

    • Q1:在宣傳中講到應用的文件編輯傾向於“輕量化的編輯”,這與現有的移動端文件編輯應用相比有獨到的競爭力嗎?
      A1:我們主推微信群聊群體,簡單編輯易上手就是我們的競爭力。
    • Q2:產品比起之前的需求分析又增添了新功能,能否闡述一下產品的核心功能是?
      A2:我們的核心功能還是共享編輯。
    • Q3:是否對文件協同編輯時可能出現的問題制定相應的驗收標準(比如文件在多端編輯時沒有同步更新)
      A3:後期會制定一個標準,及時更新,謝謝。
  • 第二組的問題

    • Q1:市面上有很多做的很成熟且使用很方便的競品,其功能也很豐富,為什麼客戶要選擇你們的?
      A1:首先,微信小程式便於安裝和分享,其次捕獲定位資訊的功能能夠方便使用者們的使用而不同於其他軟體的選取地點。
    • Q2:你們產品為小程式且介紹的功能較多,加上小程式本身有侷限,能夠真正實現你們所介紹的功能嗎?
      A2:可以的。
    • Q3:是否有考慮增加更佳新穎功能或介面設計更加突出來吸引使用者使用?
      A3:沒有,我們認為能使使用者更加便捷地適應這個專案和使用就是我們的最初目的。
  • 第四組的問題

    • Q1:請問你們開發的產品相比於如騰訊文件這類多人實時線上編輯的軟體,存在有哪些附加功能呢,還是僅是以微信小程式形式來實現?
      A1:我們還有現場簽到、釋出通知等一系列附加功能的呀。
    • Q2:微信小程式能實現的功能存在侷限性,是否能有效完成該專案呢?
      A2:目前看來是可以的。
    • Q3: 僅依賴於微信小程式是否顯得拓展性不夠,擴充套件成APP的形式是否會效果更好呢?
      A3:我們認為微信小程式更為簡單便捷,而且其實目前微信的使用量似乎要遠遠超過其他的APP,因此我們認為這邊比較有市場需求。
  • 第五組的問題

    • Q1:既然是鏈式功能服務,有沒有考慮做成app,可供多種社交賬號進行登入使用?並且不同賬號之間的檔案可以共享編輯?
      A1:我們暫時主要是為了微信使用者來考慮,因為從目前來看,微信這邊市場需求比較大
    • Q2:文件編輯授權問題,發起人能否進行批量授權?
      A2:我們的初始授權是對於分享到的這一個群聊,即群聊裡的人數都可以進行提供建議。
    • Q3:現場簽到的防止虛擬定位是否繁瑣了點,能否有更加高效的簽到方式?
      A3:好的,感謝建議,我們會盡量實現。
  • 第六組的問題

    • Q1:你好,請問1分鐘的視訊用來展示原型的操作時間過短,且沒有聲音,觀看者很難看清楚具體功能,是否可以考慮採用截圖置於PPT中由演講者大致講解功能模組?
      A1:好的,我們會考慮的,謝謝你。
    • Q2:你好,請問簽到功能是否能夠解決代簽問題?
      A2:我們目前已經在考慮這方面內容,會盡能力解決的。
    • Q3:你好,請問PPT內容相對比較少,是否可以考慮豐富PPT內容? 如增加原型的介面截圖。
      A3:嗯嗯好的。
  • 第七組的問題

    • Q1:你們提到簽到的時候會限制IP或者WIFI,不知道這個方法的可行性有多高呢?是否可以給出一些例證來說明?
      A1:就比如你到一定的地點使用上此IP,然後你才可以進行簽到,你在其他IP地址上籤到是無效的。
    • Q2:”收集想法“這個功能和在朋友圈發一條訊息或者在QQ空間發說說有什麼差別?
      A2:emm,你會一直在QQ空間或者朋友圈發動態嗎?
    • Q3:”共享編輯“這個功能是否有歷史修改記錄,能實現版本回退?如果回退到較早的一個版本,這個版本之後的改動是否會一直儲存著,還說是在這次操作裡還能保留,但退出本次操作後,那些版本就會被清空?
      A3:會有記錄儲存著,即可以退回使用。
  • 第八組的問題

    • Q1:產品與其他同類型產品拉開距離的核心競爭力是什麼?
      A1:我們使用微信小程式,給使用者更便捷的體驗。
    • Q2:對於協同編輯功能有沒有考慮到線上使用者數量會暴增,那會不會造成編輯的不穩定,有什麼對策解決?
      A2:目前我們考慮的是小群體使用者,即一個部門或者一個小團隊的內部使用,針對於這個,我們也會考慮解決的謝謝謝
    • Q3:對於簽到,為防止代簽之類的問題,是不是會用gps定位功能,但若是組員沒有開啟這個功能,那這樣不就有漏網之魚了嗎?
      A3:可以根據他們的具體要求來選擇是否開啟,有時候人家也想水一點點呢?
  • 第九組還未提問。

    【其他組提出的意見和建議】

  • 第一組

    • 產品需求說明書的規格和視訊的音訊部分修改。
  • 第二組

    • 考慮不在微信上也能使用,提高安全性和使用者資料真實性。
  • 第四組

    • 在視訊展示環節增加更多創意元素
  • 第五組

    • 簽到功能應該要簡單便捷且高效
  • 第六組

    • 豐富ppt內容,ppt排版再優化一點
  • 第七組

    • 加強文件撰寫,共享編輯能否支援多樣的檔案形式。
  • 第八組

    • 完善相關功能,保證能真正的在辦公上實現高效。
  • 第九組還未提問。

【需求規格說明書】

  需求分析報告

【遇到的困難及解決方法】

      • 困難描述

        • 對於簽到系統的精準實時定位以及共享編輯的多使用者使用
      • 做過哪些嘗試

        • 我們查找了一些演算法以及在網上查閱了一些類似的解決方法
      • 是否解決

        • 定位我們是打算採取IP或WIFI,然後多使用者的編輯目前還在進行中
      • 有何收穫

        • 使得我們更加認真地考慮了專案功能的完善方向,以及之後的可行性。

        【PSP表格】

        PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
        Planning 計劃 5 5
        · Estimate · 估計這個任務需要多少時間 120 150
        · Development 開發 10 10
        · Analysis · 需求分析 (包括學習新技術) 10 10
        · Design Spec · 生成設計文件 20 30
        · Design Review · 設計複審 (和同事稽核設計文件) 20 20
        · Coding Standard · 程式碼規範 (為目前的開發制定合適的規範) 0 0
        · Design · 具體設計 50 80
        · Coding · 具體編碼 0 0
        · Code Review · 程式碼複審 0 0
        · Test · 測試(自我測試,修改程式碼,提交修改) 0 0
        · Reporting 報告 0 0
        · Test Report · 測試報告 0 0
        · Size Measurement · 計算工作量 0 0
        · Postmortem & Process Improvement Plan · 事後總結, 並提出過程改進計劃 5 15
          合計   160

        【學習進度條】

        第N周 新增程式碼 累計程式碼 本週學習時間 累計學習時間(小時) 重要成長
        1 200 200 5 5 對Axure的學習
        5 200 400 12 17 html,css的學習
        7 400 800 7 24 學習C的函式、Xhtml的語法
        7 100 900 7 24 微信web開發者工具的使用