華為開發(fā)文檔.doc

軟件開發(fā)及文檔培訓 (僅供內部使用) 深圳市華為技術有限公司 版權所有 侵權必究 1 軟件開發(fā)過程介紹華為公司的軟件開發(fā)過程基本上由以下幾個開發(fā)過程組成: 系統(tǒng)需求分析過程 系統(tǒng)設計過程 軟件需求分析過程 軟件概要設計過程 軟件詳細設計過程 軟件編碼和單元測試過程 軟件集成與集成測試過程 系統(tǒng)集成和系統(tǒng)集成測試過程 系統(tǒng)驗收測試過程 軟件維護過程 圖一. 軟件開發(fā)相關的過程示意圖： 各軟件開發(fā)過程中應該輸出的文檔如下 軟件開發(fā)過程輸出文檔名稱文檔模板系統(tǒng)需求分析操作概念文檔OCD系統(tǒng)/子系統(tǒng)需求規(guī)格書SSS系統(tǒng)/子系統(tǒng)接口需求規(guī)格書IRS系統(tǒng)結構設計系統(tǒng)/子系統(tǒng)設計描述SSDD系統(tǒng)/子系統(tǒng)接口設計描述IDD軟件需求分析軟件需求規(guī)格書SRS接口需求規(guī)格書IRS軟件概要設計 軟件詳細設計軟件設計描述SDD接口設計描述IDD數據庫設計描述DBDD2. 軟件開發(fā)過程詳細要求2.1系統(tǒng)需求分析開發(fā)者應該根據以下要求參與系統(tǒng)需求分析。 注：如果一個系統(tǒng)分成多個版本開發(fā)，可能直到最后一個版本需求才能完全定義。開發(fā)者的計劃中應該定義在每個版本中確定的需求子集，每個版本中實現的需求子集。某個版本的需求分析應該理解為定義那個版本的系統(tǒng)需求。 2.1.1 分析用戶的輸入開發(fā)者應該通過分析用戶的輸入來理解用戶的需求。這個輸入的形式可能是需求報告單、調查、問題/修改報告，原型的反饋，訪談或其他用戶或反饋。 2.1.2 操作概念開發(fā)者應該參與定義和記錄系統(tǒng)的操作概念。結果應該包括在操作概念描述（OCD）文檔模板中的所有條目。 2.1.3 系統(tǒng)需求開發(fā)者應該參與定義和記錄系統(tǒng)應該滿足的需求以及驗證每個需求已經被滿足的方法。結果應在包括系統(tǒng)/子系統(tǒng)規(guī)格說明書（SSS）中的所有可能的條目。根據實際情況，有關系統(tǒng)接口的需求可以在SSS中規(guī)定或者在接口需求規(guī)格說明書（IRSs）中規(guī)定。 注：如果一個系統(tǒng)由子系統(tǒng)組成，系統(tǒng)需求分析）中的活動應該同系統(tǒng)設計中的活動疊代進行。定義系統(tǒng)的需求，設計系統(tǒng)并定義它的子系統(tǒng)，定義這些子系統(tǒng)的需求，設計子系統(tǒng)并定義他們的部件，如此下去。 2.2系統(tǒng)的設計開發(fā)者應該按照下列要求參與系統(tǒng)的設計。 注：如果系統(tǒng)分成多個版本開發(fā)，系統(tǒng)的設計可能要等到最后一個版本才完成。開發(fā)者的計劃中應該定義每個版本中所要完成的設計。一個特定版本的設計應理解為那個版本中應完成的設計內容。 2.2.1 系統(tǒng)范圍的設計決定（System-wide design decisions)開發(fā)者應該參與定義和記錄系統(tǒng)范圍的設計決定（這就是，有關系統(tǒng)運行設計和其它影響到系統(tǒng)部件選擇、設計的決定）。結果應該包括系統(tǒng)/子系統(tǒng)設計說明書（SSDD）模板中有關系統(tǒng)范圍設計決定的所有內容。根據實際情況，有關接口的設計可以包括在SSDD中或者接口設計說明書中，有關數據庫的設計可以包括在SSDD或者數據庫設計說明書（DBDDs）中。 注：除非在需求中有明確的規(guī)定，設計一般由開發(fā)者負責。開發(fā)要滿足所有的需求并通過系統(tǒng)集成測試來證明需求得到了滿足。 2.1.2系統(tǒng)結構設計(System architectural design)開發(fā)者應該參與定義和記錄系統(tǒng)的結構設計（定義系統(tǒng)的部件，它們的接口，以及它們之間的運行概念）以及系統(tǒng)部件同系統(tǒng)需求之間的跟蹤關系。結果應該包括系統(tǒng)/子系統(tǒng)設計說明書（SSDD）中有關結構設計及跟蹤性的部分的所有條目。根據需要，有關接口的設計可以包括在SSDDs或接口設計說明書中。 2.3 軟件需求分析（Software requirements analysis) 開發(fā)者應該定義和記錄每個CSCI應該滿足的軟件需求，驗證每個需求是否完成的方法，以及CSCI需求同系統(tǒng)需求之間的跟蹤關系。結果應該包括軟件需求規(guī)格說明書（SRS）中所有的條目。根據需要，CSCIs接口的需求可以包括在SRS中或接口需求規(guī)格說明書（IRSs）中。 注：如果一個CSCI分成多個版本開發(fā)，需求可能要到最后一個版本才能完全定義。開發(fā)者的計劃中應該說明每個版本中每個CSCI需求的子集。 2.4 軟件設計開發(fā)者應該根據以下要求進行軟件的設計。 注意：如果一個CSCI分成多個版本開發(fā)，可能需要等到最后一個版本才能完全設計完畢。每個版本的軟件設計應該理解為為了實現這個版本的需求而進行的設計。 2.4.1 CSCI范圍的設計決定（CSCI-wide design decision).開發(fā)者應該定義和記錄CSCI范圍的設計決定（這就是，有關CSCI的運行設計和其它影響到構成CSCI的軟件單元選擇和設計的設計決定）。結果應該包括軟件設計說明書（SDD）中有關CSCI范圍設計決定的所有項目。根據需要，有關接口的設計內容可以包括在SDD中，也可以安排在接口設計說明書中。有關數據庫的設計可以安排在數據庫設計說明書中。 2.4.2 CSCI結構設計（CSCI architectural design)。開發(fā)者應該定義和記錄每個CSCI的結構設計（定義構成CSCI的軟件單元，它們的接口，它們之間的運行概念）以及軟件單元CSCI需求的跟蹤關系。結果應該包括軟件設計說明書中有關結構設計及跟蹤性的所有項目.根據實際需要，有關接口的設計內容可以包括在接口設計說明書中。 注意：如果軟件單元又有其它軟件單元組成，則CSCI的結構可以根據需要組成多個層次。例如。一個CSCI可以被分成三個軟件單元，上述每個軟件單元又可以分成其他的軟件單元，如此下去。 2.4.2 CSCI的詳細設計（CSCI detailed design)開發(fā)者應該開發(fā)和記錄每個軟件單元的設計描述。結果應該包括軟件設計說明書模板的所有項目。根據需要，接口的內容可以在接口設計說明書中，有關數據庫訪問和操作的軟件單元可以安排在數據庫設計說明書中。 2.5 軟件編碼與單元測試開發(fā)者應根據以下要求進行軟件單元實現和測試。 注意：“軟件”的含義即包括計算機程序也包括計算機數據庫?！皩崿F的含義為將軟件實現轉換為計算機程序和計算機數據庫。如果一個CSCI的開發(fā)分成多個版本，軟件實現、和單元測試可能要到最后一個版本才能完成。每個版本的軟件實現和單元測試指在那個版本中需要實現的軟件單元或部分軟件單元。 2.5.1 軟件實現開發(fā)者應該開發(fā)和記錄CSCI設計中的每個軟件單元。這些活動應該包括，編碼、數據定義、構造數據庫，給數據庫或其他數據文件賦值以及其他實現設計所需要的活動。 注意：設計中的軟件單元不一定與實現它們的代碼和數據實體有一一對應的關系。 2.5.2 單元測試準備開發(fā)者應該建立測試用例（按照輸入、預期輸出和評價標準）、測試過程和測試數據來測試每個軟件單元。測試用例應該覆蓋單元詳細設計的所有方面。開發(fā)者應該將這些信息記錄在相應的軟件開發(fā)文件中。 2.5.3 進行單元測試開發(fā)者應該測試每個軟件單元對應的軟件。這些測試應該按照單元測試用例和測試過程進行。 2.5.4 修正和回歸測試開發(fā)者應該根據單元測試的結果進行所需的修正并進行回歸測試，更新相關的軟件開發(fā)文件。 2.5.5 分析和記錄單元測試的結果開發(fā)者應該分析單元測試的結果并將測試和分析結果記錄在相應的軟件開發(fā)文件中。 2.6 單元集成和測試開發(fā)者應該根據以下要求進行單元集成和測試。 注意1：單元集成和測試指將兩個或多個軟件單元集成起來，通過測試保證它們在一起工作正常，繼續(xù)這個過程直到每個CSCI中的軟件單元都集成和測試過。因為一個軟件單元可能由其它單元組成，一些集成測試在單元測試過程中就可以完成，這里不要求重復這些測試活動。 如果一個CSCI分成多個版本開發(fā)，CSCI的單元集成和測試可能要等到最后一個版本才能完成。 2.6.1 單元集成和測試的準備開發(fā)者應該建立單元集成和測試的測試用例、測試過程和測試數據（按照輸入、預期結果和評價標準）。測試用例應該覆蓋CSCI范圍和CSCI結構設計的所有方面。開發(fā)者應該將這些信息記錄在相應的軟件開發(fā)文件中。 2.6.2 進行單元集成和測試開發(fā)者應該進行單元集成和測試，測試應該按照單元集成測試用例和過程進行。 2.6.3 修正和回歸測試開發(fā)者應該根據單元集成和測試的結果修正軟件并進行回歸測試，更新軟件開發(fā)文件及其他所需的軟件產品。 2.6.4 分析、記錄單元集成和測試的結果開發(fā)者應該分析單元集成和測試的結果并記錄在相應的軟件開發(fā)文件中。 2.7 CSCI/HWCI的集成和測試開發(fā)者應該根據以下要求參加CSCI/HWCI（軟件配置項/硬件配置項）的集成和測試活動。 注意1：CSCI/HWCI集成和測試的含義是將CSCI和與之有接口的HWCI、CSCI結合，通過測試來驗證它們在一起工作是否正常。連續(xù)進行這個過程，直到系統(tǒng)中所有CSCI和HWCI都已經集成并進行測試過。這個集成測試的最后階段是開發(fā)者內部的系統(tǒng)測試。 注意2：如果一個系統(tǒng)CSCI分成多個版本開發(fā)，CSCI/HWCI集成和測試可能要到最后一個版本才完成。某個版本的CSCI/HWCI的含義為此版本中的CSCI和此版本中HWCI進行測試以保證這個版本的系統(tǒng)需求得到了實現。 2.7.1 準備CSCI/HWCI的集成和測試開發(fā)者應該參與開發(fā)和記錄CSCI/HWCI集成和測試的測試用例（根據輸入、預期輸出和評價標準）、測試過程。測試用例應該覆蓋系統(tǒng)范圍設計和系統(tǒng)結構設計的所有方面。開發(fā)者應該將軟件相關信息記錄在軟件開發(fā)文件中。 2.7.2 進行CSCI/HWCI集成和測試開發(fā)者應該參加CSCI/HWCI的集成和測試。測試應該按照CSCI/HWCI集成測試用例和測試過程進行。 2.7.3 修正和重新測試根據CSCI/HWCI集成和測試的結果，開發(fā)者應該做所需要的修正，參加所有需要的重新測試，更新相應的軟件開發(fā)文件和其他軟件產品。 2.7.4 分析和記錄CSCI/HWCI集成和測試的結果開發(fā)者應該參加分析CSCI/HWCI集成測試的結果。軟件相關的分析和測試結果應該記錄在相應的軟件開發(fā)文件中。 2.8 系統(tǒng)測試開發(fā)者應該根據以下要求參加系統(tǒng)測試。 注意1：系統(tǒng)測試用來給用戶演示系統(tǒng)需求已經得到滿足。它覆蓋系統(tǒng)/子系統(tǒng)規(guī)格說明書（SSS）中的系統(tǒng)需求和相關的接口需求。這個測試和集成測試的最后階段在開發(fā)者內部進行的系統(tǒng)測試不同。 注意2：如果系統(tǒng)分成多個版本開發(fā)，完整的系統(tǒng)測試可能在最后一個版本才遇到。每個版本的質量測試應該理解為為了驗證此版本的需求已經得到滿足而進行的測試。 2.8.1 系統(tǒng)測試中的獨立性負責系統(tǒng)測試的人不應該是進行詳細設計或軟件實現的人。這并不排除負責詳細設計或實現的人對這個過程作出貢獻，例如：提供需要了解系統(tǒng)內部實現的測試用例。 2.8.2 在目標計算機上的測試開發(fā)者的系統(tǒng)測試應該包括在目標計算機（或其它用戶同意的系統(tǒng)）上的測試。 2.8.3 系統(tǒng)測試的準備開發(fā)者應該參加參加開發(fā)和記錄測試的準備、測試用例、測試過程以及測試用例和系統(tǒng)需求之間的跟蹤性。對于軟件系統(tǒng)，結果應該包括軟件測試說明書（STD）中的所有項目。開發(fā)者應該參加準備系統(tǒng)測試需要的測試數據以及通知用戶測試的時間和地點。 2.8.4 運行（自己動手）系統(tǒng)測試如果系統(tǒng)測試需要用戶見證，開發(fā)者應該參加（自己動手）運行系統(tǒng)測試用例和過程以保證其完整性和正確性。開發(fā)者應該將這些測試活動的結果記錄在相應的軟件開發(fā)文件中并根據需要對測試用例和過程進行更新。 2.8.5 進行系統(tǒng)測試開發(fā)者應該參加系統(tǒng)測試。測試應該根據測試用例和過程進行。 2.8.6 修正和重新測試根據系統(tǒng)測試的結果，開發(fā)者應該對軟件做必要的修正，給用戶提供重新測試的建議，參加所有需要的重新測試并更新軟件開發(fā)文件和其他軟件產品。 2.8.7 分析和記錄系統(tǒng)測試結果開發(fā)者應該參加分析和記錄系統(tǒng)測試結果。對于軟件小，這些結果應該包括軟件測試報告（STR）中的所有項目。 深圳市華為技術有限公司 研究管理部文檔中心文檔編號產品版本密級產品名稱：共10頁軟件需求規(guī)格說明書（SRS） (僅供內部使用) 擬制：日期：yyyy/mm/dd審核：日期：yyyy/mm/dd審核：日期：yyyy/mm/dd批準：日期：yyyy/mm/dd深圳市華為技術有限公司 版權所有 侵權必究 修訂記錄 日期修訂版本描述作者1999/01/301.00初稿完成作者名目 錄 1范圍41.1標記41.2 系統(tǒng)概論41.3文檔概述42參考文獻43需求43.1所需的狀態(tài)和模式53.2CSCI能力需求53.2.1（CSCI 能力）53.3CSCI 外部接口需求53.3.1 接口標識符和示意圖53.3.2（項目內部接口唯一的標識符）63.4CSCI內部接口需求73.5CSCI內部數據需求73.6適應性需求73.7安全性需求83.8安全和隱蔽性需求83.9CSCI的環(huán)境需求83.10計算機資源需求83.10.1計算機硬件需求83.10.2計算機硬件資源利用程度需求83.10.3計算機軟件需求83.10.4計算機通訊需求83.11 軟件質量因素93.12設計和實現約束93.13人員相關的需求93.14培訓有關的需求93.15后勤相關的需求93.16其它需求93.17包裝的需求93.18需求的優(yōu)先和關鍵順序94質量保證措施105需求跟蹤106 注釋107 附錄10軟件需求規(guī)格說明書 軟件需求規(guī)格說明書（SRS）規(guī)定一個計算機軟件配置項（CSCI）的需求，以及驗證每個需求是否得到滿足的方法。CSCI的外部接口需求可以在SRS中進行規(guī)定，也可以在一個或多個接口需求規(guī)格說明書（IRS）中進行規(guī)定，在軟件需求規(guī)格說明書（SRS）對這些文檔進行引用。 軟件需求規(guī)格說明書（SRS）（可能需要IRS的補充）是CSCI設計和測試的基礎。 1. 范圍這部分將被分為以下幾段。 1. 標識這一部分應包含系統(tǒng)、接口實體、被說明接口的完整標識，盡可能包括：標識號碼、標題、縮寫、版本號、發(fā)布號。 1. 系統(tǒng)概論這一部分將簡要的闡述文檔所說明的系統(tǒng)和軟件的目的。它將大概描述系統(tǒng)、軟件的本質；總結系統(tǒng)的發(fā)展、操作和維護的歷史；確定這個方案的發(fā)起人、受益人、使用人、開發(fā)者和維護機構；確定當前的狀況并計劃操作地點；最后列出其它相關聯的文檔。 1. 文檔概述這一部分總結了這個文檔的目的和內容，并且描述了與文檔用處有關的任何安全性及保密性的事項。 1. 參考文獻這一部分列出了一些文檔中引用的所有文檔的號碼、名稱、修訂本和數據。 1. 需求本部分應該分成以下段落來描述CSCI的需求，它們是CSCI為了被接受而必須具有的特性。CSCI的需求是為了滿足分配到本CSCI的系統(tǒng)需求而產生的軟件需求。需要給每個需求分配一個項目唯一的標識符以支持需求的測試和跟蹤，對需求的描述必須能夠達到可以設計針對性測試的程度。如果在以后的4、5節(jié)沒有說明，在這里每個需求都要注明相應的測試方法（見4節(jié)）及與系統(tǒng)需求間的追溯關系（見5節(jié)）。需求描述的詳細程度應該依照以下原則：包括CSCI達到可接受的標準所必須具有的特征，避免進行設計描述，這些是開發(fā)者的工作。如果在某一段中沒有需求，只需要寫“無”即可。如果一個需求在多個段落中出現，它只需描述一次即可，在其它地方進行引用。 1. 所需的狀態(tài)和模式如果CSCI工作在不同的狀態(tài)和模式中，并且在不同的工作狀態(tài)和模式有不同的需求，本段應定義每一個狀態(tài)和模式。狀態(tài)和模式的例子如下：等待、待命、行動、事后分析、訓練、降級、緊急、備份、戰(zhàn)時、和平時期。狀態(tài)和模式間的區(qū)別時靈活的。一個CSCI可以只按照狀態(tài)描述，只按照模式描述，按照模式中的狀態(tài)描述，按照狀態(tài)中的模式描述或按照任何其他有用的順序描述。如果系統(tǒng)沒有任何狀態(tài)和模式的特別要求，按照實際情況描述即可，沒有必要“人工創(chuàng)造”不同。如果需要按照模式或狀態(tài)描述，那么每個需求或者需求集合都要和狀態(tài)或模式相關。這些相關性可以通過段落或附錄中的一個表格進行說明，也可以對需求進行注釋。 1. CSCI能力需求本段應該分成以下子段落以逐條說明CSCI的每個能力需求。一個“能力”定義成一組相關的需求。名詞“能力”可以用“功能”、“題目”、“目標”等有助于表達需求的名詞替代。 1. （CSCI 能力）本段定義CSCI的一個能力并羅列有關此能力的需求。如果此能力分成幾個組成部分描述更清楚些，這些子能力應在各子段落中描述。需求規(guī)定CSCI的動態(tài)行為并包括可能的參數，例如：反映時間、吞吐時間、其他時間約束、順序、準確度，能力（多少）、優(yōu)先級、連續(xù)操作的需求，不同操作條件下允許的偏差。需求應盡可能包括：在異常情況下、越界情況下所需的動態(tài)行為，錯誤處理的需求，緊急情況下提供連續(xù)操作能力的需求。3.3段規(guī)定了描述CSCI有關輸入輸出需求時需要考慮的一系列題目。 1. CSCI 外部接口需求本段應該分成以下幾個子段落來規(guī)定CSCI的外部接口需求，本段可能引用一個或多個接口需求規(guī)格說明書或其它相關文檔。 1. 接口標識符和示意圖本段應該定義CSCI所需的外部接口（它們是和其他外部實體之間涉及共享、提供或交換數據的關系）。每個接口的標識包括一個項目內部唯一的標識符以及接口實體（系統(tǒng)、配置項、用戶、等），對接口實體的說明盡量包括以下內容：名稱、編號、版本、參考文檔。定義應該說明那個接口實體具有固定的接口特性（因此對相應的接口實體提出接口要求），那些正在被開發(fā)或修改（因此被賦予接口需求）。應該提供一個或多個示意圖以對接口進行說明。 1. （接口的標識符）本段（從3.3.2開始應該給CSCI的一個外部接口定義一個項目唯一的標識符，簡要描述接口實體。為了描述一個或者多個接口實體的需求，可以劃分為子段落。如果一個接口實體未被本文檔覆蓋（例如一個外部系統(tǒng)），但是描述接口需要提到它時，應該以假定的方式說明，或者以“當未被覆蓋的實體這樣作，系統(tǒng)中說明的實體將. 樣的方式說明。本段可能會引用其他文檔（例如：數據字典、標準協議、用戶接口標準）。設計描述應該盡可能包括以下信息，可以用任何適合需求的順序提供，應該注明這些特征從接口實體角度看的任何區(qū)別（例如：對數據元素的大小、頻率或其他特征的不同理解）： 接口實體必須賦予接口的優(yōu)先級。 接口類型的需求（例如：實時數據傳送，存儲檢索，等等）。 接口實體提供、存儲、發(fā)送、訪問、接收的每個數據元素的特征。例如： 1. 名稱/標記 1. 項目唯一的標記 2. 自然語言的名稱 3. 國防部標準數據元素名稱 4. 技術名稱（例如，代碼或數據庫中的變量名和域名） 5. 縮寫詞或同義詞 2. 數據類型（字符型、整型等） 3. 大小和格式（例如字符串的長度和分隔符號 4. 測量單位（例如米、美元、微秒） 5. 可能的數值范圍（例如：099） 6. 準確度（正確的程度）和精確度（有效數字的位數） 7. 優(yōu)先級、時序、頻率、數量、順序和其他約束，例如：是否更新數據成員，是否應用行業(yè)標準。 8. 安全和隱蔽性的約束 9. 源頭（設置/發(fā)送實體）和接受（使用/接收實體） 數據元素集（紀錄，消息，文件，數組，顯示，報告）的特性。 11. 名稱/標記 1. 項目唯一的標記 2. 自然語言的名稱 3. 技術名稱（例如，代碼或數據庫中的變量名和域名） 4. 縮寫詞或同義詞 12. 裝配中的數據元素及其類型 （編號，順序，分組） 13. 媒介（如磁盤）和在媒介上的元素/裝配的結構 14. 輸出的視覺和聽覺特性，其他輸出（顏色，字體，布局，圖標，亮度， 蜂鳴等） 15. 數據集合之間的關系，如排序/存取特性 16. 優(yōu)先級、時序、頻率、數量、順序和其他約束，例如：是否更新數據成員，是否應用行業(yè)標準。 17. 安全和隱蔽性的約束 18. 源頭（設置/發(fā)送實體）和接受（使用/接收實體） 接口使用的通訊方法 項目唯一的標識符 通訊鏈接、波段、頻率、媒質和特性。 消息格式 流控（例如：順序號和分配緩沖）。 數據傳輸數率，是周期性還是突發(fā)性，傳送的間隔。 路由、地址、和命名約定。 傳送服務，包括：優(yōu)先和分級 安全和隱蔽性的考慮，例如：加密、用戶驗證、隔離和審計。 接口中使用的協議特性需求 項目唯一的標志符 協議的優(yōu)先級和層次 包操作，包括拆分、組裝、路由和尋址 合法性檢查，出錯控制，恢復過程。 同步過程，包括：建立連接，保持，結束。 狀態(tài)、標志、任何其他的報告特性。 其他特性，例如：接口實體的物理兼容性（體積、公差、負荷、電壓、插頭兼容性等） 36. CSCI內部接口需求本段定義CSCI內部接口需求。如果內部接口情況由開發(fā)者決定，這里說明即可。如果需要定義內部接口需求，請參照3.3的題目進行說明。 1. CSCI內部數據需求本段定義CSCI內部數據的需求，內部數據庫和數據文件的需求。如果所有的設計由開發(fā)者決定，這里只要說明即可。如果具有這方面的需求，本段的3.3.x.c 和3.3.x.d提供了需要考慮的條目。 1. 適應性需求本段規(guī)定CSCI和安裝數據有關的需求（例如：和安裝地點有關的經緯度，或和安裝有關的州稅務碼）以及不同操作下可能不同的操作參數需求（例如：指示和操作有關的目標變量或數據記錄的參數）。 1. 安全性需求本段應該描述CSCI有關避免或減少對人員、財產、環(huán)境的意外傷害的需求。例如：必須提供一些保證措施來避免一些無意中的行為（例如：無意中發(fā)出一個關閉自動駕駛儀的命令）和“不行為”（例如：沒有按要求發(fā)出“關掉自動駕駛”命令）。 1. 安全和隱蔽性需求本段規(guī)定有關保持系統(tǒng)安全和隱蔽性的需求。這些需求包括，CSCI操作必須的安全和隱蔽環(huán)境，需要滿足的安全和隱蔽性級別。CSCI需要面對的安全/隱蔽性風險，減少這些風險所需的安全性措施，必須滿足的安全/隱蔽性策略，CSCI必須提供的安全/隱蔽性責任，通過安全/隱蔽性檢驗所必須滿足的標準。 1. CSCI的環(huán)境需求本段規(guī)定CSCI有關操作環(huán)境的需求。例如：CSCI所必須運行的操作環(huán)境、計算機硬件。（有關計算機資源的詳細需求在下段描述）。 1. 計算機資源需求1. 計算機硬件需求本段規(guī)定CSCI必須使用的計算機硬件資源的需求。需求包括：每種設備的數量，體積，能力，其它對處理器、存儲器、輸入輸出設備、輔助存儲器、通訊網絡設備和其它所需設備的需求。 1. 計算機硬件資源利用程度需求本段說明有關CSCI的計算機硬件資源使用方面的需求，例如：允許最大限度占用的處理器、存儲器、輸入輸出設備、通訊網絡設備能力。需求（例如以每種資源所允許的占用百分比說明）應說明測量條件和環(huán)境。 1. 計算機軟件需求本段規(guī)定CSCI運行使用到或者需要合作的計算機軟件。例如：操作系統(tǒng)、數據庫管理軟件、通訊網絡軟件，設備軟件，輸入和設備模擬器，測試軟件，制造軟件等等。應該說明每種軟件的正確名稱、版本、參考文檔。 1. 計算機通訊需求本段規(guī)定CSCI必須使用的計算機通訊需求。例如：需要相互連接的地理位置；配置和網絡拓撲； 傳送技術；數據傳送速率；網關；需要的系統(tǒng)使用次數；傳送和接收數據的類型和容量；傳送/接收/反饋的時間界限；數據量的峰值；診斷特點； 1. 軟件質量因素本段應該規(guī)定CSCI的軟件質量需求。例如：有關CSCI功能性（完成所有的所需功能的能力），可靠性（提供正確、連續(xù)操作結果的能力），可維護性（能夠很容易修正的能力），可用性（在需要時候能夠很容易訪問和操作），靈活性（適應變化環(huán)境的能力），可測試性（容易和全面測試的能力），重用性（應用在多個應用中的能力），易用性（容易學習和使用的能力），以及其它屬性。 1. 設計和實現約束本段應說明CSCI設計和實現的約束。這些需求可能需要對民用和軍用標準進行引用。例如： 1. 使用專門的CSCI結構或對結構的需求，例如：數據庫或其他軟件單元；標準、現有部件的使用。 2. 特別設計和實現標準的使用；特別數據標準的使用；特別編程語言的使用 3. 為了支持預期增長的技術、威脅和目標所必須提供的靈活性和可擴展性。 1. 人員相關的需求本段應該規(guī)定對使用或支持本CSCI所需的人員需求，包括：數量、熟練程度、責任鏈、培訓需求或者其他信息。例如對同時進行操作者數量的要求，內部幫助和培訓特征。同時也應包括工程需求的人的因素。這些需求應該包括：對人的能力及限制的考慮；在一般情況下和極端環(huán)境中可預見的人的錯誤；人為錯誤將造成特別嚴重后果的區(qū)域。例如：錯誤信息顯示的顏色和時段，關鍵指示器和開關的物理位置，聲音信號的使用。 1. 培訓有關的需求本段應該包括CSCI有關培訓的需求。例如：CSCI中應該包括的訓練軟件。 1. 后勤相關的需求本段應該規(guī)定CSCI與后勤相關的需求，例如：系統(tǒng)維護、系統(tǒng)支持、系統(tǒng)運輸、支持系統(tǒng)的需求，對原有設施的影響，對現有設備的影響。 1. 其它需求本段應該包括在上述段落中沒有包括的其它需求。 1. 包裝的需求本部分應該說明CSCI包裝、標簽、發(fā)行的需求。 1. 需求的優(yōu)先和關鍵順序本段應該通過優(yōu)先順序、關鍵程度、權重來說明規(guī)格中需求的相對重要程度。例如：要注名那些需求對安全性、保密性或隱蔽性上非常關鍵，以便進行特殊處理。如果所有需求具有相同的權重，本段這樣據實描述即可。 1. 質量保證措施本段應說明一系列的質量保證措施，并說明對3節(jié)中每個需求所采用的質量保證方法?？梢杂帽砀竦男问教峁┻@方面的信息，或者在3節(jié)中對需求進行說明時加上相關的注釋。 1.演示： 該接口實體的運作依賴于明顯的功能性操作，并且不需要使用儀器、特殊測試裝備、或是事后的分析。 2.測試：接口實體的運作需要使用儀器、測試裝備，來收集數據，用于事后的分析。 3.分析：處理使用其它的判定方法獲取的數據，例如簡約、譯碼、或是推斷。 4.檢視： 對接口實體、文檔的正規(guī)檢視。 5.特殊合格性判定方法： 所有的特殊合格性判定方法，如專用的工具、技術、過程、設備和容忍極限。 1. 需求跟蹤1.本文檔中的需求到系統(tǒng)（或子系統(tǒng)）需求的跟蹤。（這種跟蹤也可以由第三節(jié)中的需求的注釋表明。） 注釋：每一層次的系統(tǒng)求精可能會導致需求無法直接跟蹤到高層的需求。例如，有一項系統(tǒng)構結構設計產生了多個軟件配置項（CSCIs），這有可能產生了如何劃分接口的需求，然而這些需求并沒有包括在系統(tǒng)需求之中。這種需求可能會跟蹤到一般性的需求，象“系統(tǒng)實現”，或是跟蹤到導致他們產生的系統(tǒng)設計決定上。 2. 從每個系統(tǒng)（子系統(tǒng)）需求到CSCI需求間的跟蹤。與CSCI有關的所有需求都應該被說明。如果有些跟蹤涉及到的CSCI需求在接口需求說明書中（IRS），應該對這些文檔進行引用。 1. 注釋本段包括對理解文檔有幫助的其他一般信息（例如：背景、詞匯表、原理）。本部分應該包括所有專有名詞、縮寫詞、術語、定義及其含義。 1. 附錄附錄用來提供為了文檔維護方便而進行獨立發(fā)行的信息（例如，圖表，分類數據）。如果可能，在文檔主體中需要相關數據的地方提供對文檔的索引。為了便于處理，附錄裝訂成獨立文檔。附錄應按字母順序標記（A，B，等.）。 深圳市華為技術有限公司 研究管理部文檔中心文檔編號產品版本密級產品名稱：共7頁接口需求說明書(IRS) (僅供內部使用) 擬制：日期：yyyy/mm/dd審核：日期：yyyy/mm/dd審核：日期：yyyy/mm/dd批準：日期：yyyy/mm/dd深圳市華為技術有限公司 版權所有 侵權必究 修訂記錄 日期修訂版本描述作者1999/10/121.00初稿完成任蔚目 錄 接口需求描述說明書41 范圍：41.1 標志41.2 系統(tǒng)概述41.3 文檔的概述42 參考文獻43 需求43.1 接口定義和圖示43.2（項目內部唯一的接口標識符）53.3 需求的優(yōu)先級和緊急程度64 合格性規(guī)定(qulification provisions)75 需求跟蹤76 注釋77 附錄7接口需求說明書 接口需求描述文檔（IRS）詳細描述接口需求，它涉及一個或多個系統(tǒng)，子系統(tǒng)，硬件配置項（HWCIs），軟件配置項（CSCIs），手動操作或是其他系統(tǒng)組件，一篇接口描述文檔可包括任意數目的接口。 接口需求描述文檔可以補充說明系統(tǒng)/子系統(tǒng)規(guī)格說明書(SSS) (DI-IPSC-81431)和軟件需求規(guī)格說明書，作為系統(tǒng)和軟件配置項的設計與測試的基礎。 1. 1 范圍：本部分應該分為以下幾個段落。 1. 1.1 標志本段應該包括文檔所應用系統(tǒng)和軟件的完全標志，可能包括，序列號、名稱、簡稱、版本號、發(fā)行號。 1. 1.2 系統(tǒng)概述本段應簡短的說明文檔敘述的系統(tǒng)和軟件的目的。描述軟件和系統(tǒng)的本質；總結系統(tǒng)或軟件的發(fā)展、操作、維護的歷史。 1. 1.3 文檔的概述本段應該總結本文檔的目的和內容并描述所有的安全和隱蔽性的考慮。 1. 2 參考文獻本段應該列出本說明中提到的所有文檔的序號，名稱，修訂和日期。本段也要說明一般途徑不能獲得的文檔的來源。 1. 3 需求本部分應該分為以下幾個段落，用來描述一個或多個系統(tǒng)，子系統(tǒng)，硬件配置項（HWCIs），軟件配置項（CSCIs），手動操作或是其他系統(tǒng)組件所涉及到的接口需求。應該給每個需求賦予一個項目內部唯一的標識符，用來支持測試和跟蹤，需求的描述方式應能夠用來定義針對性測試。如果在以后的部分沒有提供，需求就要加以注釋，表明相關的合格性判定方法（見 4部分）及與系統(tǒng)/子系統(tǒng)需求（見5.a節(jié)）可追溯性。詳細程度應該遵循以下規(guī)則：包括接口實體達到可接受水平所必須具有的特性，避免描述具體設計，這些是開發(fā)者的工作。如果一項需求安排在幾個段落中，應該說明一次，而在其他的段落中引用。如果一個接口實體在不同的工作模式下的接口需求不同，那么所有的需求都要基于一定的模式進行說明。通過一張表或者其他方式說明對應關系。 1. 3.1 接口定義和圖示本段應該給每個接口定義一個項目唯一的標識符并說明接口的實體（軟件單元、系統(tǒng)、配置項、用戶等), 可能的話使用名稱、編號、版本、參考文獻進行說明。定義應說明那些實體具有固定的接口特性（因此有接口需求），那些正在被開發(fā)或修改。有可能的話，提供一個或多個圖型對接口進行描述。 1. 3.2（項目內部唯一的接口標識符）本段（從3.2開始應該給接口一個項目唯一的標識符，簡要描述接口實體。為了描述一個或者多個接口實體的需求，可以劃分為子段落。如果一個接口實體未被本文檔覆蓋（例如一個外部系統(tǒng)），但是描述接口需要提到它時，應該以假定的方式說明，或者以“當未被覆蓋的實體這樣作，系統(tǒng)中說明的實體將. 樣的方式說明。本段可能會引用其他文檔（例如：數據字典、標準協議、用戶接口標準）。設計描述應該盡可能包括以下信息，可以以任何合適的順序提供，應該注明這些特征從接口實體角度看的任何區(qū)別（例如：對數據元素的大小、頻率或其他特征的不同理解）： 接口實體必須賦予接口的優(yōu)先級。 接口類型的需求（例如：實時數據傳送，存儲檢索，等等）。 接口實體提供、存儲、發(fā)送、訪問、接收的每個數據元素的特征。例如： 1. 名稱/標記 1. 項目唯一的標記 2. 自然語言的名稱 3. 國防部標準數據元素名稱 4. 技術名稱（例如，代碼或數據庫中的變量名和域名） 5. 縮寫詞或同義詞 2. 數據類型（字符型、整型等） 3. 大小和格式（例如字符串的長度和分隔符號 4. 測量單位（例如米、美元、微秒） 5. 可能的數值范圍（例如：099） 6. 準確度（正確的程度）和精確度（有效數字的位數） 7. 優(yōu)先級、時序、頻率、數量、順序和其他約束，例如：是否更新數據成員，是否應用行業(yè)標準。 8. 安全和隱蔽性的約束 9. 源頭（設置/發(fā)送實體）和接受（使用/接收實體） 數據元素集合（紀錄，消息，文件，數組，顯示，報告）的特性。 11. 名稱/標記 1. 項目唯一的標記 2. 自然語言的名稱 3. 技術名稱（例如，代碼或數據庫中的變量名和域名） 4. 縮寫詞或同義詞 12.