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