團隊任務電子公文傳輸系統
項目名：電子公文傳輸系統 成員：20191331劉宇軒、20191303姜淳譯、20191305李天琦、20191311陳之韬、20191318王澤文 撰寫：劉宇軒 日期：2021.10.31
分層形式描述不夠具體清晰，沒有做到逐層深入，缺少目錄。
目錄：
1.引言
<code>1.1使用說明 1.2背景</code>
2.使用者場景
3.類圖
4.界面原型
5.功能描述
<code>5.1使用者功能 5.2系統管理者功能 5.3資料庫管理者 5.4安全審計員 5.5系統功能補充</code>
6.驗收驗證标準
未描述成員具體分工和工作量比例。
上次制定的需求規格說明書中部分内容實作起來較為困難且備援，我們删除了管理者字号管理功能。
更新後的《需求規格說明書》：https://gitee.com/vegetable-dogggg/docsys/blob/master/規格需求說明書v2.md
團隊的編碼規範：
代碼風格的原則是：簡單，易讀，無二義性。包括縮進、行寬、括号等。
縮進：将Tab鍵擴充定義為4個空格。不使用tab鍵的原因是它在不同的情況下會顯示不同的長度。使用空格可讀性高。
行寬：行寬限制為100字元。
括号：在複雜的條件表達式中，用括号清楚地表示邏輯優先級；左右小括号和字元之間不能出現空格。
斷行與空白的{}行：每個｛和｝都單獨占一行，互為一對的{和}要位于同一列，并且與引用它們的語句左對齊。
代碼行：if、else、for、while、do 等語句自占一行。不論執行語句有多少行，就算隻有一行也要加{}，并且遵循對齊的原則。
命名：
代碼中的命名隻能由字母、數字、下劃線組成；不能以下劃線或美元符号開始，也不能以下劃線或美元符号結束。
命名不能直接使用中文。
不可以是系統的關鍵詞比如if、else等。
常量命名全部大寫，單詞用下劃線隔開。
注釋：保證代碼與注釋的一緻性，要簡潔明了，注釋的雙斜線與注釋内容之間有且僅有一個空格複雜的注釋放在函數頭，注釋中應隻使用ASCII字元。
函數：
一個函數最好僅完成一件功能，多調用為簡單功能編寫函數。
函數的功能應該是可以預測的，也就是隻要輸入資料相同就應産生同樣的輸出。
避免設計多參數函數，不使用的參數從接口中去掉。
檢查函數所有參數輸入的有效性與作用。
函數名應準确描述函數的功能，便于查找和修改。
明确函數功能。
變量：
去掉沒必要的公共變量。
構造僅單一子產品或函數可以修改、建立的公共變量，防止多個不同子產品或函數都可以修改、建立同一公共變量的現象。
定義并明确公共變量的含義、作用、取值範圍及公共變量間的關系。明确公共變量與操作此公共變量的函數或過程的關系，如通路、修改及建立等。
當向公共變量傳遞資料時，要十分小心，防止賦與不合理的值或越界等現象發生。
局部變量與公共變量不能同名。
嚴禁使用未經初始化的變量。聲明變量同時對變量進行初始化。
注意資料類型的強制轉換。
編寫：
注意随時儲存與備份避免代碼丢失。
使用相同編輯器與選項設定。
編寫代碼過程中互相幫助，随時找出代碼中的錯誤并進行改進，互相學習。
相應的WBS圖：
象限法分析核心需求：
目前核心任務TODOList：
燃盡圖：
正在編篡。