weedit需求規格說明書
第三次軟工實踐答辯材料
組長部落格鏈結
團隊所有成員共同討論各部分實現功能，共有5個功能，分別由5名成員負責各自的後端介面，2名同學負責前端介面，1名同學負責美工；
在11月8日前，美工組同學先完成介面主體設計，然後交由各引數於前端小組；
在11月8日——11月15日期間，前端小組根據美工小組同學的設計，完成前端的程式設計，與此同時，後端組自發討論學習各自功能的實現演算法；
在11月15日——11月20日期間，後端組完成各自的後端功能實現，並與前端介面相連線；
在11月20日——11月25日期間，團隊成員組織**合併該專案，對於有缺陷或者未能實現的功能集中討論，改善專案。
線下推廣
另外，在辦公區域，通過新增小程式等服務，贈送相關辦公用品
圖中已經細分了各個成員在本次的團隊實踐任務中的具體工作分工，並以工作量的比例進行分數的評定，詳細見圖。本次的需求規格說明書具體參照了「gb-t 9385-2008，《計算機軟體需求規格說明規範》」，以大綱為框架逐漸完善內部內容，後續經審核補充完成最終的文件。
姓名得分（百分制比例%）
柯奇豪18.575
蔣雄8.675
黃志銘7.775
黃毓明14.975
林翔宇16.775
丁水源14.975
楊禮亮16.775
陳超1.475
q&a
q1:在宣傳中講到應用的文件編輯傾向於「輕量化的編輯」，這與現有的移動端文件編輯應用相比有獨到的競爭力嗎？
q2:產品比起之前的需求分析又增添了新功能，能否闡述一下產品的核心功能是？a2: 我們的核心功能還是共享編輯。
q3:是否對文件協同編輯時可能出現的問題制定相應的驗收標準（比如文件在多端編輯時沒有同步更新）a3: 後期會制定乙個標準，及時更新，謝謝。
q1:市面上有很多做的很成熟且使用很方便的競品，其功能也很豐富，為什麼客戶要選擇你們的？
q2:你們產品為小程式且介紹的功能較多，加上小程式本身有侷限，能夠真正實現你們所介紹的功能嗎？a2: 小程式開發內部提供有豐富的介面，就目前了解而言是可以實現的。
q3:是否有考慮增加更佳新穎功能或介面設計更加突出來吸引使用者使用？a3:暫時沒有，我們認為能使使用者更加便捷快速的去熟悉使用就是我們產品推出的初衷。
a1:我們還有現場簽到、發布通知等一系列功能，可以形成乙個鏈式的關聯整體使用。
a2: 就目前而言是可以完成的。
q2:文件編輯授權問題，發起人能否進行批量授權？a2: 文件本身是以一種互動反饋的形式來共享編輯，因此批量授權的實現是在我們考慮範圍中的。
q3:現場簽到的防止虛擬定位是否繁瑣了點，能否有更加高效的簽到方式？a3: 目前為止這是我們想到的乙個解決虛擬定位的方式之一，後續會再進一步去深入了解與學習，尋找更便捷一點的防範措施，感謝你們的建議。
q2:你好，請問簽到功能是否能夠解決代簽問題？a2: 我們在介紹中有提到，目前給出的乙個解決方案是配合網路接入位址進行防止虛擬定位的問題，後續會進一步去了解使用其他更便捷的方法。
q3:你好，請問ppt內容相對比較少，是否可以考慮豐富ppt內容? 如增加原型的介面截圖。a3: 本次的ppt主要介紹的主題均已經點出，已經滿足基礎性的要求，關於內容較少的問題，我們後續會注意的。
q1:你們提到簽到的時候會限制ip或者wifi，不知道這個方法的可行性有多高呢？是否可以給出一些例證來說明？a1: 舉例你到一定的地點使用上此ip，然後我對此進行判斷後抉擇簽到授權問題，當你在其他的ip位址上簽到時因為不滿足要求則視為無效簽到位址。可行性目前的了解是可以做到的。
q2:」收集想法「這個功能和在朋友圈發一條訊息或者在qq空間發說說有什麼差別？a2: 不太能夠理解你們提問的目的，但是作為本產品的乙個輔助性功能，收集想法本身對使用群體沒有多大的約束，它本身作為一種放鬆心態、隨時傳送隨機回答的方式，滿足工作閒暇之餘的放鬆。
q3:」共享編輯「這個功能是否有歷史修改記錄，能實現版本回退？如果回退到較早的乙個版本，這個版本之後的改動是否會一直儲存著，還說是在這次操作裡還能保留，但退出本次操作後，那些版本就會被清空？a3: 會考慮增設記錄的儲存，即可以退回使用，如果是願意回退到上乙個版本的話，自然該版本後的操作將視為失效不予記錄。
q1:產品與其他同型別產品拉開距離的核心競爭力是什麼？a2: 目前我們考慮的是小群體使用者，即乙個部門或者乙個小團隊的內部使用，針對於這個，我們後續也會考慮解決的，謝謝。
q3:對於簽到，為防止代簽之類的問題，是不是會用gps定位功能，但若是組員沒有開啟這個功能，那這樣不就有漏網之魚了嗎？a3: 本身該功能就是為了精準簽到設定的，所以對於使用者是有要求的，你所提到的問題不屬於我們產品本身該考慮的問題。
a1: 我們會考慮盡可能的去使得使用者滿意並願意使用我們的小程式，關於不方便操作的問題我們正在設法簡約操作，謝謝你們給予的意見。
q2:如果在電腦端實現，那麼該產品跟目前以有的產品相比較，你覺得你們的優勢在**？a3: 可以在後續進行若干次產品調研，提公升使用質量。
final score：
小組評分
第一組82
第二組77
第三組77
第四組87
第五組63
第六組82
第七組79
第八組76
第九組90
最低分63（第五組）
最高分90（第九組）
有效分數
82，77，77，87，82，79，76
最終平均得分
80weedit需求規格說明書
之前提到過的關於格式上的問題已經全部進行了修改，包括頁碼、部分未處理好的文字陰影等。同時在內容上進行了大幅度的增加，包括重新繪製實體關係圖，增加資料流圖以及資料字典等
psp2.1
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
planning計畫0
0· estimate
· 估計這個任務需要多少時間
8075
development開發0
0· analysis
· 需求分析 (包括學習新技術)
1010
· design spec
· 生成設計文件00
· design review
· 設計複審 (和同事審核設計文件)00
· coding standard
· **規範 (為目前的開發制定合適的規範)00
· design
· 具體設計
6060
· coding
· 具體編碼00
· code review
· **複審00
· test
· 測試（自我測試，修改**，提交修改）00
reporting
報告· test report
· 測試報告00
· size measurement
· 計算工作量55
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫00
合計75
75第n周
新增**(行)
累計**(行)
本週學習耗時(小時)
累計學習耗時(小時)
重要成長10
0112
10010078
學會了hashmap的排序30
1007
15學了nabcd模型40
0217第1次與別人合作
5100
20010
27學會了簡單地爬取網頁資訊60
2002
29第1次團隊合作70
2002
31學了uml設計，畫了一點活**和泳道圖80
2002
33學會了簡單地分析需求
第七次作業 專案需求分析
1 編寫需求說明書。2 約定好編碼規範，初步架構搭建，完成需求規格說明書最終版 3 ui設計，完成架構設計，制定測試計畫。4 完成alpha版本 編碼 測試 專案管理同步推進。5 完善專案，確定使用者試用反饋和對測試計畫改進。6 完成beta版本 以5為基礎進行改良 測試 專案管理推進。7 確定正式...
福大軟工 第七次作業 需求分析報告
我們將工作流程分為前期 中期 後期來進行。中期後期 隊員貢獻度 林燊 組長 8 陳俞辛 11 朱志豪 11 蔡宇航 12 陳柏濤 12 董鈞昊 12 劉巨集巖 10 盧愷翔 12 楊喜源 12 總計 100 說明 需求報告撰寫 蔡宇航 陳柏濤 盧愷翔 答辯ppt製作 劉巨集巖 原型設計 楊喜源 朱志...
福大軟工 第七次作業 需求分析報告
我們將工作流程分為前期 中期 後期來進行。中期後期 隊員貢獻度 林燊 組長 8 陳俞辛 11 朱志豪 11 蔡宇航 12 陳柏濤 12 董鈞昊 12 劉巨集巖 10 盧愷翔 12 楊喜源 12 總計 100 說明 需求報告撰寫 蔡宇航 陳柏濤 盧愷翔 答辯ppt製作 劉巨集巖 原型設計 楊喜源 朱志...