【正文】 信息。 ?CC08交換機應(yīng)該提供呼叫等待和三方通話等新業(yè)務(wù)。偽碼的粗細程度以適宜作注釋為標準； 設(shè)計文檔寫作要點 結(jié)構(gòu)圖 (structure chart)描述了一個系統(tǒng)的模塊劃分，體現(xiàn)了模塊之間的層次、組織和通信關(guān)系 示例： 結(jié)構(gòu)圖 偽碼 又叫 PDL(Program Design Language)，是一種混合語言，用自然語言（如英語、漢語等）描述程序的處理邏輯，用一定的關(guān)鍵字語法（如 if、 else等）定義控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。 增強、移植設(shè)計 修改原因： ? 針對每個修改點，具體闡述為什么需要修改，如因為某某處理流程的變化，功能的擴展，界面的變化，性能的優(yōu)化等； ? 不應(yīng)該描述修改什么，這是修改描述部分應(yīng)詳細介紹的內(nèi)容； ? 修改原因中的描述應(yīng)有助于對修改描述的理解。 3）修改描述 typedef struct tagARPRTENTRY { 。 對于增強、移植項目，目前大家都是在 word文檔中寫設(shè)計，是因為 word文檔中可以使用特殊的標注，這樣能將修改前后的對比體現(xiàn)出來。 影響分析“對其他模塊無影響”，結(jié)構(gòu)體變大，有沒有評估對系統(tǒng)內(nèi)存資源的消耗？ 增強、移植設(shè)計范例 85 思考 對于開發(fā)項目，在詳細設(shè)計階段，我們提倡在 C文件中寫偽碼，這樣較之在 word文檔中寫偽碼的好處有： 。 練習 2 數(shù)據(jù)結(jié)構(gòu)修改： ETHARP_ARPRTENTRY_S 1）修改原因 需要在 ARP表項節(jié)點紀錄授權(quán)表項標志位。 偽碼寫作說明： 75 設(shè)計樣例 設(shè)計文檔大綱 (增強、移植項目 ) 移植或增強項目： 修改分類 1 修改原因 影響分析 修改描述 修改點 1 修改點 n …… …… 修改分類 N 增強、移植設(shè)計 修改分類： ? 對所有需要的修改點進行分類，一個修改分類包含一個或多個修改點，實現(xiàn)一相對獨立的功能； ? 每個修改分類都應(yīng)使用有明確含義的標題，如：“關(guān)于 XXX的修改”。 單元模塊函數(shù)總數(shù)也不超過 7個； ?HLD階段將所有函數(shù)全部分解出來， LLD階段不再關(guān)注模塊分解； ?HLD使用 結(jié)構(gòu)圖 描述函數(shù)的調(diào)用關(guān)系； ?函數(shù)分解規(guī)模以 30~50行 (非空非注釋 )為宜，最大不超過200行。 伙計 2 伙計 3 伙計 1 伙計需求文檔寫作要點 ?不應(yīng)該把多個需求集中在一個冗長的敘述段落中。例如“系統(tǒng)必須 …… ”或者“用戶必須 …… ”，并緊跟一個行為動作和 可觀察 的結(jié)果。 輸入 取出協(xié)商得到的 DNS地址 處理 路由器保存協(xié)商得到的 DNS地址，并將其添加到接口信息中 輸出 操作成功后，協(xié)商得到的 DNS地址保存 GotOptions里，并被添加到接口信息中，否則顯示出錯提示，不會顯示在接口信息中。 “函數(shù)”、“數(shù)據(jù)結(jié)構(gòu)”、“指針”、 buildrun之類的表述； ，而不是站在開發(fā)人員的立場上。 * 輸 入 : 無 * 輸 出 : 無 * 返 回 值 : VOS_OK： 表示登錄成功； VOS_ERR：表示登錄失敗。 處理 遍歷所有的全局 DDR控制塊鏈表 是 Dialer接口和物理接口 取 DDR的 if 取所有的撥號口屬性 返回鏈表頭指針 輸出 撥號口屬性鏈表頭指針。 輸入 輸出 具體需求－功能需求 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 功能需求描述 介紹 處理 該功能的目的、使用方法和技巧，及相關(guān)背景介紹 所有輸出數(shù)據(jù)的詳細描述 從輸入數(shù)據(jù)和中間參數(shù)獲得輸出的所有操作 所有輸入數(shù)據(jù)的詳細描述 輸入 輸出 具體需求－功能需求 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 ?輸入數(shù)據(jù)的描述： ?輸入來源 ?數(shù)量 ?度量單位 ?時序 ?允許的輸入偏差范圍 具體需求－功能需求 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 ?處理操作： ?輸入數(shù)據(jù)合法性檢測 ?操作次序 ?異常情況的響應(yīng) ?操作影響到的參數(shù) ?用于把系統(tǒng)輸入轉(zhuǎn)換到相應(yīng)輸出的所有方法，諸如方程式，數(shù)學算法，邏輯操作 ?對輸出數(shù)據(jù)的合法性檢測 ?溢出 ?通信失敗 ?錯誤處理 40 具體需求－功能需求 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 ?輸出數(shù)據(jù)的描述 ?輸出到何處（如打印機、文件等） ?數(shù)量 ?度量單位 ?時序 ?允許的輸出偏差范圍 ?對非法值的處理 ?錯誤消息 具體需求－功能需求 功能需求寫作要點： ? 每個功能需求分配唯一編號，且給出一有意義的標題，便于檢索。 應(yīng)在范圍中描述 范圍不是用來描述本文包括什么、不包括什么 總體概述 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 假設(shè)和依賴關(guān)系 總體概述 軟件功能 用戶特征 軟件概述 本節(jié)不對需求作具體描述，只是為了使那些需求更易于理解 總體概述－軟件概述 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 ? 描述軟件與其它產(chǎn)品或項目所組成的整體環(huán)境 本軟件模塊 1 外部模塊 3 系統(tǒng)外部模塊 1 系統(tǒng)外部模塊 2 外部模塊 4 ? 本節(jié)是概要性描述，最好使用圖形描述系統(tǒng)或項目的組件、互聯(lián)性及外部接口 30 總體概述－軟件功能 總體概述 具體需求 設(shè)計約束 質(zhì)量屬性 簡介 附錄 依賴關(guān)系 其它需求 ? 提供軟件所實現(xiàn)功能的一個概要描述 ?可以從更高層規(guī)格文檔直接引用 ?清楚易懂 ?顯示不同功能及其相互關(guān)系 ?不描述具體需求 功能 3 功能 1 功能 2 。 當收到 unit up消息時，本 unit向其它 unit發(fā)送端口鏡像同步消息。 4. output輸出 無 5. Inherit繼承性 Update需要改進 大家看看下面的需求描述如何？ 密文兩種，但處理中描述的顯示形式卻是 simple和 cipher，不一致； ，長度有無限制，均沒有交待。 在禁止了 arp動態(tài)學習的接口上，只能通過手工添加靜態(tài) arp，或者其他一些被允許的模塊才可以添加 arp，這種 arp被稱為 ARP Authorized，授權(quán) arp不再和其他的動態(tài)表項一樣老化，而是有自己的老化機制，后面會說明。用戶可以通過命令行來配置該 radius服務(wù)器是否啟動設(shè)備重啟防吊死功能。門廳東墻北端 90角折向東，長 2米，把書房和廚房北陽臺分隔開。 大家認為下面的描述如何？ 究竟長多 少？ ? 是左？ 還是右？ 大段的敘述，不利于理解！ 10 練習 ，房子大門在東側(cè)中間位置。門廳長約 3米，寬 2米，門廳左面是主臥室，右面是廚房。我們現(xiàn)在有一個嚴重的問題是，大家好像不喜歡寫文檔，對于需要的實現(xiàn)方案，通常都是一個負責人在腦袋里想想該怎么實現(xiàn)，然后郵件或電話找?guī)讉€相關(guān)人員討論一下就算可以了， 可能連個會議材料或會議紀要都沒有?？蛷d與餐廳連為一體，共 7米長， 4米寬，與客廳相連有一南陽臺，與客廳同寬，長 。 寬 3米，長 5米左右，房間門對著客廳。 2.…… 下面的描述呢？ 白話 修改成如下的描述呢？ ………… LSW（ 支持記錄時間功能