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

Part 0. 開篇

WeEdit需求規格說明書
第三次軟工實踐答辯材料
一分鐘演示視頻
組長博客連接

Part 1. 計劃安排

1. 團隊全部成員共同討論各部分實現功能，共有5個功能，分別由5名成員負責各自的後端接口，2名同窗負責前端界面，1名同窗負責美工；
2. 在11月8日前，美工組同窗先完成界面主體設計，而後交由各參數於前端小組；
3. 在11月8日——11月15日期間，前端小組根據美工小組同窗的設計，完成前端的編程，與此同時，後端組自發討論學習各自功能的實現算法；
4. 在11月15日——11月20日期間，後端組完成各自的後端功能實現，並與前端接口相鏈接；
5. 在11月20日——11月25日期間，團隊成員組織探討合併該項目，對於有缺陷或者未能實現的功能集中討論，改善項目。

• 線上推廣
  • 在本院、校學生會以及各個班級組織推廣無償使用
• 線下推廣
  • 與福建省其餘高校一塊兒推廣使用，體驗高效便捷的微信辦公軟件服務
  • 另外，在辦公區域，經過添加小程序等服務，贈送相關辦公用品

 

• 線上推廣

  • 在本院、校學生會以及各個班級組織推廣無償使用

• 線下推廣

  • 與福建省其餘高校一塊兒推廣使用，體驗高效便捷的微信辦公軟件服務
  • 另外，在辦公區域，經過添加小程序等服務，贈送相關辦公用品

  Part 2. 項目logo

由於咱們的項目名稱是WeEdit，因此咱們的LOGO象形E，即辦公的意思，另外，用「...」以及鉛筆象形結合，展示出咱們的主推功能「共享編輯」。底色的綠色的，主要是爲了契合微信的圖標底色，咱們不遺餘力地使這個小程序與微信進一步的貼切，減小用戶的使用難度，方便使用。

 

 

Part 3. 思惟導圖

 

•  

  Part 4. 團隊中我的的貢獻比例

   

  圖中已經細分了各個成員在本次的團隊實踐任務中的具體工做分工，並以工做量的比例進行分數的評定，詳細見圖。本次的需求規格說明書具體參照了「GB-T 9385-2008，《計算機軟件需求規格說明規範》」，以大綱爲框架逐漸完善內部內容，後續經審覈補充完成最終的文檔。

  姓名	得分（百分制比例%）
  柯奇豪	18.575
  蔣熊	8.675
  黃志銘	7.775
  黃毓明	14.975
  林翔宇	16.775
  丁水源	14.975
  楊禮亮	16.775
  陳超星	1.475

• Part 5. 評審表格設計

  對其餘組評分結果審表PDF版

• Part 6. 答辯總結

• 去除最高分（90）最低分（63）後的平均分：80

  • 第一組：82
  • 第二組：77
  • 第四組：87
  • 第五組：63
  • 第六組：82
  • 第七組：79
  • 第八組：69
  • 第九組：90

• 第一組的問題

  • 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:能夠根據他們的具體要求來選擇是否開啓，有時候人家也想水一點點呢？

• 第九組還未提問。

　　
• Q1:既然是多人編輯文檔，以微信小程序實現的話，在手機端會不會不方便編輯文檔？
  A1:咱們會考慮儘量的去使得用戶滿意並願意使用咱們的小程序，關於不方便操做的問題咱們正在設法簡約操做，謝謝大家給予的意見。
• Q2:若是在電腦端實現，那麼該產品跟目前以有的產品相比較，你以爲大家的優點在哪裏？
  A2:能夠進行配套使用，由於主打的羣體面向微信用戶，目前市面上的公司等等大型組織通常都更常常的使用微信，所以其存在的意義就是以其方便快捷來拉攏這些潛在的既有用戶，拓展更多的新用戶涌入。
• Q3:微信小程序的編輯文檔界面是否真的能方便用戶的使用，有沒有考慮調查一下用戶的使用感覺？
  A3:能夠在後續進行若干次產品調研，提高使用質量。

 

•  

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

• 第一組

  • 產品需求說明書的規格和視頻的音頻部分修改。

• 第二組

  • 考慮不在微信上也能使用，提升安全性和用戶數據真實性。

• 第四組

  • 在視頻展現環節增長更多創意元素

• 第五組

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

• 第六組

  • 豐富ppt內容，ppt排版再優化一點

• 第七組

  • 增強文檔撰寫，共享編輯可否支持多樣的文件形式。

• 第八組

  • 完善相關功能，保證能真正的在辦公上實現高效。

• 第九組還未提問。

  • 　　更加方便的用戶操做

Part 7. 軟件需求規格說明書(有大幅度的豐富改動)

WeEdit需求規格說明書
修改了上次答辯過程當中出現的問題和不足，而且增長了數據流圖等內容。

 

Part 8. 遇到的困難及解決方法

• 困難描述

  • 對於簽到系統的精準實時定位
  • 想法收集模塊的創意性
  • 更便捷的分享
  • 界面美觀

• 作過哪些嘗試

  • 瞭解模擬定位軟件的實現方式，但願能從這之中找到突破
  • 對於想法收集模塊參照了當前幾款作的比較好的軟件，但咱們想要與他們有些區別
  • 分享依舊保持連接分享，界面上稍做改善

• 是否解決

  • 定位咱們打算採起IP或WIFI
  • 界面上有了必定改善

• 有何收穫

  • 第一是瞭解到技術上的實現問題，清楚本身當前的技術實力和前進方向
  • 第二是對本身審美也是一種鍛鍊吧

 

Part 9. 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

 

Part 10. 學習進度條

第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開發者工具的使用