【正文】 需求設計文檔模板 19 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 什么是好的需求 什么樣的需求是好的需求 完整性 清晰性 可行性 一致性 可驗證性 練習 Requirements1 功能需求 1修改設置 smarton password命令 1. Introduction介紹 在設置 smarton password的同時，規(guī)定密碼顯示形式為明文和密文。在某個接口上禁止 arp動態(tài)學習，不影響其他接口的 arp學習。 15 練習 修改原因： 這個函數是將要發(fā)送的 packet轉化為 buffer，系統(tǒng)原有函數RD_PutPacketToBuffer是針對認證用戶設計的，由于本特性為設備啟動后執(zhí)行，沒有用戶信息，所以在 RD_PutPacketToBuffer函數基礎上做了一些修改，形成該函數。 由于一臺設備可以設置多個 radius服務器，即 radius scheme。 2.…… 下面的描述呢？ 白話 修改成如下的描述呢？ ………… LSW（ 支持記錄時間功能 ），利用設備時間戳特性可以檢測出設備 是否重啟 ， 設備重啟時 將 CAMS上的在線用戶刪除，并依據最后一次計費更新報文終結計費。 書房 門，書房南北長 4米，書房有一個一米見方的門廳，書房的西墻長 4米，包括 1米長的門廳長度，西墻把書房和次臥分隔開。 寬 3米，長 5米左右，房間門對著客廳。門廳東墻北端 90角折向東，長 2米，把書房和廚房北陽臺分隔開?？蛷d與餐廳連為一體，共 7米長， 4米寬，與客廳相連有一南陽臺，與客廳同寬，長 ?！? —— 摘自一位華為員工的瑞典出差報告 5 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 文檔寫作基本要求 下面的文檔出自于我們開發(fā)人員的手筆，大家覺得如何？ 文檔寫作基本要求 ? 應使用標準模板寫作； ? 文檔封頁、頁眉頁腳、修訂記錄、附錄、參考文獻應完善； ? 關鍵詞、摘要、縮略語應完整； ? 目錄要及時更新； ? 通篇文檔標題、文字格式、間距應協(xié)調美觀； ? 所有文檔模板中的章節(jié)，只可增加，不可刪除； ? 編寫建議是用來指導文檔寫作的，在利用完后要及時刪除； ? 圖號置于圖形之下，表號置于表格之上； 文檔寫作基本要求 ? 應追求圖文并茂的效果； ? 句子和段落要短； ? 使用語言應嚴謹，不要使用白話； ? 采用主動語氣； ? 不要出現“我們”、“你們”、“他們”這樣的稱謂，或“這個”、“那個”這樣的詞，應使用“本”、“該”、“其”； ? 表述清晰，避免引起歧義； ? 通篇文檔細節(jié)上要保持一致； 練習 房子南北走向，房子大門在東側中間位置。我們現在有一個嚴重的問題是，大家好像不喜歡寫文檔，對于需要的實現方案，通常都是一個負責人在腦袋里想想該怎么實現，然后郵件或電話找?guī)讉€相關人員討論一下就算可以了， 可能連個會議材料或會議紀要都沒有。 而老外可不是這樣的，他們非常非常重視文檔，他們認為 一個人在腦袋里想的東西是不清晰也不全面的，有時候心里想的認為很正確的方案實際上可能存在致命缺陷。門廳長約 3米，寬 2米，門廳左面是主臥室，右面是廚房。餐廳的北面是衛(wèi)生間，衛(wèi)生間與廚房相對，中間由 1米寬， 3米長的過道隔開；衛(wèi)生間門對著過道，南墻與廚房的南墻在一條直線上；衛(wèi)生間為長方形，南墻長 3米，另一邊長 2米。 大家認為下面的描述如何？ 究竟長多 少？ ? 是左？ 還是右？ 大段的敘述，不利于理解！ 10 練習 ，房子大門在東側中間位置。 與餐廳連為一體，共 7米長， 4米寬，與客廳相連有一南陽臺，與客廳同寬，長 。門廳東墻北端 90角折向東，長 2米，把書房和廚房北陽臺分隔開。用戶可再次正常登陸。用戶可以通過命令行來配置該 radius服務器是否啟動設備重啟防吊死功能。 修改原因： 該函數實現將待發(fā)送的 packet轉化為 buffer的功能，系統(tǒng)原有函數RD_PutPacketToBuffer針對認證用戶設計，由于本特性為設備啟動后執(zhí)行，沒有用戶信息，所以在 RD_PutPacketToBuffer函數基礎上做了一些修改，形成該函數。 在禁止了 arp動態(tài)學習的接口上，只能通過手工添加靜態(tài) arp，或者其他一些被允許的模塊才可以添加 arp，這種 arp被稱為 ARP Authorized，授權 arp不再和其他的動態(tài)表項一樣老化，而是有自己的老化機制，后面會說明。 2. Inputs 輸入 1)密碼顯示形式。 4. output輸出 無 5. Inherit繼承性 Update需要改進 大家看看下面的需求描述如何？ 密文兩種，但處理中描述的顯示形式卻是 simple和 cipher，不一致； ，長度有無限制，均沒有交待。初始化 MAC地址表相關指針。 當收到 unit up消息時，本 unit向其它 unit發(fā)送端口鏡像同步消息。 不清晰一般也不可驗證。 應在范圍中描述 范圍不是用來描述本文包括什么、不包括什么 總體概述 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 假設和依賴關系 總體概述 軟件功能 用戶特征 軟件概述 本節(jié)不對需求作具體描述，只是為了使那些需求更易于理解 總體概述－軟件概述 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ? 描述軟件與其它產品或項目所組成的整體環(huán)境 本軟件模塊 1 外部模塊 3 系統(tǒng)外部模塊 1 系統(tǒng)外部模塊 2 外部模塊 4 ? 本節(jié)是概要性描述，最好使用圖形描述系統(tǒng)或項目的組件、互聯(lián)性及外部接口 30 總體概述－軟件功能 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ? 提供軟件所實現功能的一個概要描述 ?可以從更高層規(guī)格文檔直接引用 ?清楚易懂 ?顯示不同功能及其相互關系 ?不描述具體需求 功能 3 功能 1 功能 2 。 ACL模塊的穩(wěn)定性，包括 ACL規(guī)則的維護、匹配等。 輸入 輸出 具體需求－功能需求 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 功能需求描述 介紹 處理 該功能的目的、使用方法和技巧，及相關背景介紹 所有輸出數據的詳細描述 從輸入數據和中間參數獲得輸出的所有操作 所有輸入數據的詳細描述 輸入 輸出 具體需求－功能需求 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ?輸入數據的描述： ?輸入來源 ?數量 ?度量單位 ?時序 ?允許的輸入偏差范圍 具體需求－功能需求 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ?處理操作： ?輸入數據合法性檢測 ?操作次序 ?異常情況的響應 ?操作影響到的參數 ?用于把系統(tǒng)輸入轉換到相應輸出的所有方法，諸如方程式，數學算法，邏輯操作 ?對輸出數據的合法性檢測 ?溢出 ?通信失敗 ?錯誤處理 40 具體需求－功能需求 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ?輸出數據的描述 ?輸出到何處（如打印機、文件等） ?數量 ?度量單位 ?時序 ?允許的輸出偏差范圍 ?對非法值的處理 ?錯誤消息 具體需求－功能需求 功能需求寫作要點： ? 每個功能需求分配唯一編號，且給出一有意義的標題，便于檢索。若認為實在沒有，那最可能是功