【正文】 偽碼在形式上很接近于代碼，而大家更習(xí)慣在 source insight中閱讀代碼； ，原因同上； 。 2）影響分析 修改原有數(shù)據(jù)結(jié)構(gòu)，對(duì)其他模塊無(wú)影響。 修改分類一 關(guān)于將 MQC策略應(yīng)用到 ATM PVC接口下的修改 修改點(diǎn)： ? 一個(gè)修改點(diǎn)描述一處修改，如一個(gè)數(shù)據(jù)結(jié)構(gòu)的修改，一個(gè)宏定義的修改，一個(gè)函數(shù)的修改等； ? 修改點(diǎn)也應(yīng)使用有意義的標(biāo)題，不要使用“修改點(diǎn) 1”等。每個(gè)函數(shù)的復(fù)雜度控制在 10以內(nèi)，即：一個(gè)函數(shù)中不能有太多的 if， else， for, switch…case 等邏輯； ?LLD階段寫 偽碼 ，推薦在 source insight中寫，完成后嵌入 LLD中。務(wù)必記?。翰灰谛枨笳f明中使用“和 /或”，“等等”之類的連詞。 ?舉例： 計(jì)算過程中出現(xiàn)除零錯(cuò)誤時(shí)，系統(tǒng)必須立即彈出對(duì)話框顯示該錯(cuò)誤，并進(jìn)行聲音提示。 分析： 前兩個(gè)功能點(diǎn)是在描述一條命令行，而后一功能點(diǎn)描述的是另一條相關(guān)的命令行。 需求文檔寫作要點(diǎn) ?功能需求劃分應(yīng)合理 Requirements 功能需求 PPP協(xié)商從對(duì)端得到協(xié)商的 DNS地址 在接口視圖下通過以下命令來(lái)配置要求通過 PPP主動(dòng)協(xié)商從對(duì)端得到 DNS地址： ppp ipcp dns request 輸入 用戶在某一封裝了 PPP協(xié)議的接口視圖下，輸入 ： ppp ipcp dns request 處理 路由器解析此命令輸入正確后，將修改 PPP協(xié)議中的協(xié)商參數(shù)，使的路由器在進(jìn)行 PPP協(xié)商的時(shí)候會(huì)要求對(duì)端分配協(xié)商的 DNS地址。 * 調(diào)用關(guān)系 : 略 * 其 它 : 無(wú) *******************************************************************************/ 50 總體設(shè)計(jì)約束 ? 描述由標(biāo)準(zhǔn)、硬件、技術(shù)限制等造成的對(duì)設(shè)計(jì)的限制 ?標(biāo)準(zhǔn)順從：描述來(lái)自現(xiàn)有標(biāo)準(zhǔn)和規(guī)則的需求 –報(bào)告格式 –數(shù)據(jù)命名 協(xié)議 ?硬件約束：描述支持軟件運(yùn)行的硬件條件，如內(nèi)存限制 ?技術(shù)限制：描述對(duì)使用的特定技術(shù)的限制，如數(shù)據(jù)庫(kù)、并行操作等 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 軟件質(zhì)量屬性 ?可維護(hù)性 ?可靠性 ?安全性 ?可移植性 ?易用性 ?...... 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 軟件質(zhì)量屬性 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 ?可維護(hù)性 描述支持軟件可維護(hù)的具體需求 例如： –跟蹤調(diào)試功能 –告警提示功能 –對(duì)軟件模塊之間的耦合度進(jìn)行考慮 軟件質(zhì)量屬性 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 ?可靠性 ?容錯(cuò)性 在出現(xiàn)軟件故障的時(shí)候仍然能夠維持某種層次性能的能力。 ，按照這樣的 IPO描述無(wú)法對(duì)其進(jìn)行驗(yàn)證； 求，而不是功能需求； 具體需求－性能需求 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 ? 描述軟件或人機(jī)交互的靜態(tài)和動(dòng)態(tài)量化需求。標(biāo)題通常是動(dòng)賓詞組，不要使用“功能需求一 /二”這樣的描述。 總體概述－用戶特征 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 ?描述影響特定需求的最終用戶的一般特征 最終用戶：操作人員、維護(hù)人員、系統(tǒng)管理人員等 考慮方面：受教育程度、經(jīng)驗(yàn)、專業(yè)技術(shù)知識(shí)等 總體概述－假設(shè)和依賴 總體概述 具體需求 設(shè)計(jì)約束 質(zhì)量屬性 簡(jiǎn)介 附錄 依賴關(guān)系 其它需求 ?假設(shè) 尚不確定但又必須要的情況下，所設(shè)定的一個(gè)參考結(jié)果，與已知事實(shí)相對(duì)。此消息包含本 unit所配置的鏡像組信息。不完整 ？不完整 練習(xí) WOL功能 1. Introduction介紹 在系統(tǒng)視圖下配置或者取消配置 WOL使能。 DHCP server就是這樣的一個(gè)模塊。 練習(xí) CAMS收到該報(bào)文后會(huì)立即回應(yīng)一個(gè) code=5的計(jì)費(fèi)回應(yīng)報(bào)文，然后根據(jù) accountingon報(bào)文攜帶的 NASIP和 NASID找到通過該設(shè)備認(rèn)證的用戶，并將他們的在線信息刪除。 修改成如下描述之后呢？ 練習(xí) 主臥室 次臥室 廚房 餐廳 客廳 陽(yáng)臺(tái) 陽(yáng)臺(tái) 衛(wèi)生間 書房 門廳 過道 北 西 再改成如下圖形描述呢？ 練習(xí) LSW與 CAMS配合實(shí)現(xiàn)認(rèn)證計(jì)費(fèi)的方案中，客戶（禁止多人同時(shí)使用的業(yè)務(wù)帳號(hào)）登陸通過認(rèn)證開始計(jì)費(fèi)后，如果出現(xiàn) LSW重起的情況，處理方法分為兩種： LSW（可以記錄時(shí)間的），設(shè)備重起后會(huì)使用設(shè)備時(shí)間戳的特性判斷出設(shè)備重起了，這時(shí)會(huì)將 CAMS上的在線用戶刪除并按照最后一次計(jì)費(fèi)更新報(bào)文來(lái)終結(jié)計(jì)費(fèi)。 長(zhǎng) 3米，寬 2米，門廳左面是主臥室，右面是廚房。廚房 3米寬， 4米長(zhǎng)，廚房門對(duì)著門廳，廚房的頂頭還有一個(gè)北陽(yáng)臺(tái)，與廚房同寬，長(zhǎng) 1米。 需求設(shè)計(jì)寫作培訓(xùn) 質(zhì)量管理部 SQA小組 課程范圍 ?僅關(guān)注如何寫作文檔 ?不涉及具體的需求分析和設(shè)計(jì)方法 課程內(nèi)容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設(shè)計(jì)文檔模板 ?需求文檔寫作 ?設(shè)計(jì)文檔寫作 為什么要文檔化 ? 開發(fā)人員通過文檔化的過程查錯(cuò)補(bǔ)遺； ? 便于評(píng)審，在早期發(fā)現(xiàn)技術(shù)上的問題； ? 后續(xù)階段開發(fā)任務(wù)可能由他人承擔(dān)，輸出文檔便于他們開展工作； ? 維護(hù)人員開展維護(hù)工作需要； ? 文檔是必要的交付件； ?………… 可讀性就尤為關(guān)鍵 為什么要文檔化 “所有的過程分析都要形成文檔。主臥室寬 3米，長(zhǎng) 5米左右，房間門對(duì)著客廳。 3米寬， 4米長(zhǎng)，廚房門對(duì)著門廳，廚房的頂頭還有一個(gè)北陽(yáng)臺(tái)，與廚房同寬，長(zhǎng) 1米。用戶可再次正常登陸。 CAMS收到該報(bào)文后會(huì)立即回應(yīng)一個(gè) code=5的計(jì)費(fèi)回應(yīng)報(bào)文，然后根據(jù) accountingon報(bào)文攜帶的 NASIP和 NASID找到通過該設(shè)備認(rèn)證的用戶，并將 其 在線信息刪除。 靜態(tài) arp的優(yōu)先級(jí)高于授權(quán) arp，也就是說可以覆蓋授權(quán) arp。 2. Inputs 輸入 系統(tǒng)視圖下 : wol enable 或 undo wol enable 3. Process 處理 在系統(tǒng)視圖下配置或者取消 WOL使能。 Performance Requirements 性能需求 1. Performance Requirements1 性能需求 1 通話語(yǔ)音要求流暢。 ?依賴 對(duì)外部條件的依賴，兩者之間存在明確的需求關(guān)系。 ? 是描述 What to do，而不是 How to do； ? 介紹部分描述“做什么”沒有意義，因?yàn)楹竺?IPO會(huì)詳細(xì)介紹。 靜態(tài)的量化需求 –支持的終端數(shù)目 –支持的并發(fā)用戶數(shù)目 –需處理的文件和記錄的數(shù)目 –表和文件的大小 動(dòng)態(tài)的量化需求 –可包括正常和滿負(fù)荷業(yè)務(wù)量條件下，某時(shí)間段（如一小時(shí)）內(nèi)處理的事務(wù)和任務(wù)的數(shù)目以及數(shù)據(jù)量。 ?可恢復(fù)性 在出現(xiàn)故障時(shí)的恢復(fù)能力和重新建立某種層次性能的能力。 輸出 操作成功后，可以通過在當(dāng)前視圖下輸入 display this 命令來(lái)查看配置是否成功。 用戶的需求是什么？是這兩條命令行嗎？ 命令行只是我們提供的用戶界面，隱藏其后的功能需求是什么？ “支持通過 PPP協(xié)商獲取 DNS地址”，就這一條。 ?舉例： 計(jì)算過程中出現(xiàn)除零錯(cuò)誤時(shí)，系統(tǒng)必須給出提示