【正文】 ），利用設備時間戳特性可以檢測出設備 是否重啟 ， 設備重啟時 將 CAMS上的在線用戶刪除，并依據(jù)最后一次計費更新報文終結計費。 15 練習 修改原因： 這個函數(shù)是將要發(fā)送的 packet轉化為 buffer，系統(tǒng)原有函數(shù)RD_PutPacketToBuffer是針對認證用戶設計的，由于本特性為設備啟動后執(zhí)行，沒有用戶信息，所以在 RD_PutPacketToBuffer函數(shù)基礎上做了一些修改，形成該函數(shù)。 1. ARP與 arp、 ARP Authorized與授權 arp，使用術語應該統(tǒng)一； 2. ARP Authorized應先解釋后引用； 3. “ DHCP server就是這樣的一個模塊”，是否相關？ 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 模板 何處獲取 需求 SRS文檔： REP01T01 接口文檔： REP01T03 設計 概要設計： DVP05T01 詳細設計： DVP05T03 軟件設計： DVP05T04 移植設計： DVP05T05 需求設計合一 來自華為北研所 \\h3crnd01fs\軟件部規(guī)范 \小特性開發(fā)規(guī)范 \模板 \需求設計 需求設計文檔模板 19 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 什么是好的需求 什么樣的需求是好的需求 完整性 清晰性 可行性 一致性 可驗證性 練習 Requirements1 功能需求 1修改設置 smarton password命令 1. Introduction介紹 在設置 smarton password的同時，規(guī)定密碼顯示形式為明文和密文。去系統(tǒng) WOL使能時，將 WOL模塊的 MACADDR表清空，釋放所占內存。 “可能”、“流暢”都是不清晰的，不同人理解不一樣。 練習 PPPoFR和 MPoFR應用，是針對虛模板上的 QoS應用的增強型項目，要求原有的 PPPoFR模塊、 QoS模塊、 MP模塊穩(wěn)定可靠。應描述有利于理解后續(xù) IPO的內容： Why，為什么會有此需求 When/Where，什么時候 /什么場合使用 How，如何使用 對 IPO描述中將使用到的特殊術語的解釋 與其它功能需求的聯(lián)系等 具體需求－功能需求 功能需求寫作要點 (續(xù) )： ? 處理部分可以 采用 C語言中關鍵詞如 if、 else、 while等輔助描述，這樣在時序、邏輯上更清晰； ? IPO缺一不可 有些情況下，輸入輸出可能不直觀，如：定時器超時事件、接口up/down事件等，但并不是沒有，否則處理什么。 45 具體需求－性能需求 舉例： 性能需求寫作要點： ? 每條性能需求必須以可測量的術語進行描述，即應給出明確的量化指標，包括度量單位； ? 對于動態(tài)性能指標，除性能指標外，還應包含必要的的前置條件； 前置 條件 ?交易能很快完成，操作員不必等待。 例如： –主備板熱備份 –通信鏈路中斷重連 軟件質量屬性 總體概述 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 ?安全性 在此描述防止軟件遭到意外或惡意的侵入、使用、修改、破壞或泄密的因素。否則顯示出錯提示。 拆成三條，需求分解不合理，如何修正？ 一條功能需求（支持通過 PPP協(xié)商獲取 DNS地址） display命令的修改可以在功能需求的輸出中提及。 65 需求文檔寫作要點 ?必須避免模糊的、主觀的術語，減少不確定性。 ?CC08交換機應該提供呼叫等待功能。 優(yōu)點： ?維護方便 ?容易評審 ?作為代碼注釋 缺點： ?不容易掌握粗細 ?容易寫成代碼 偽碼 偽碼 = 關鍵字語法 + 自然語言描述 偽碼 ?使用 C語言的語法書寫偽代碼，使用標準符號，如： if, else, { }, while等； ?用描述性語言來描述； if（接口是以太網(wǎng)接口） if（ InterfaceType == ETHERNET) ?詳略得當。 修改 原因 影響分析 修改描述 增強、移植設計 影響分析： ? 應評估修改對原模塊有無沖擊，從功能、性能、接口等多方面進行評估； ? 應評估修改對系統(tǒng)資源的消耗情況； ? 應描述為了配合此修改點還需要作哪些修改，即將各修改點關聯(lián)起來。 if ( VRP_MODULE_LINK_ARP_AUTHORIZED == VRP_YES ) ULONG ulArpAuthTag。 移植設計能否也在 C文件中寫呢？ 請大家思考這個問題，如果有好的想法，可以提出來討論。 修改原因還是在描述如何修改，沒有介紹增加該標志是為了什么。 影響分析“無”，是無影響，還是沒有分析？ 修改描述中沒有體現(xiàn)出修改在原代碼中的具體位置。 用發(fā)送報文接口的地址來設置發(fā)送報文的源地址 。 這個“等”包含哪些內容？怎么測試？ 測試人員 需求范例 69 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 設計文檔大綱 (開發(fā)項目 ) 零層設計 一層設計 二層設計 配置和 控制 簡介 模塊 1 詳設 數(shù)據(jù)庫 模塊 n 詳設 …… HLD LLD 上下文定義 設計思路 分解描述 依賴性描述 接口描述 …… 分解描述 依賴性描述 接口描述 …… 數(shù)據(jù)描述 函數(shù)描述 開發(fā)項目： 系統(tǒng)總體設計 子系統(tǒng)設計 系統(tǒng)對外關系 ?HLD分解層次一般不超過 3層（ 0層、 1層、 2層），每層的模塊數(shù)以 2到 4個為宜，最多不要超過 7個。 提高文件柜的高度。 需求文檔寫作要點 ?需求陳述應該具有一致的樣式。 DNS地址，并可通過命令 display interface查看 保存從對端協(xié)商得到的 DNS地址，并可通過查看接口信息的 display interface命令將得到的 DNS地址顯示出來。不要描述“ How to do”， 那是設計關注的事情。如： 認證接口 /******************************************************************************* * 函數(shù)名稱 : ATMLoginInProc * 功能描述 : 讀取輸入的用戶的賬號名及密碼，保存到當前用戶信息全局變量中， * 并到賬務處理系統(tǒng)進行認證。 練習 取以下配置：鏈路空閑掛斷時間： dialer timer idle；呼叫間隔時間： dialer timer enable；鏈路建立等待時間： dialer timer waitcarrier；競爭等待時間： dialer timer pete；緩沖區(qū)報文數(shù)： dialer queuelength 輸入 NULL。 下面的描述是假設還是依賴？ 〔假設〕 〔依賴〕 〔依賴〕 〔假設〕 需求建模 需求建模 具體需求 設計約束 質量屬性 簡介 附錄 依賴關系 其它需求 總體概述 DFD樣例 －在 DOS環(huán)境下模擬實現(xiàn) ATM柜員機的功能 需求分析方法更多的培訓資料參見 \\h3crnd01fs\軟件部規(guī)范 \小特性開發(fā)規(guī)范 \培訓 \需求設計 35 具體需求 功能需求 具體需求 性能需求 接口需求 總體概述 具體需求 設計約束 質量屬性