D06需求規(guī)格說明書

1、文件編號： NEWSEASE-PM-D06配置瞬部門卜系統 g-OK 本號 -DSRS-Mg 本號工程名稱工程英文名稱需求規(guī)格說明書嬸版本號編寫人: 編寫時間 : 部門名: 審核人: 審嘶間:編號早節(jié)名稱像丁內容簡述修1】日期版本號似丁后版本號人扌睦人目錄1. 弓I言 11.1目的 11.2文檔約圮 11.3預期的讀者和閱讀建議 11.4產品的范用 11.5參考文獻 12. 綜合描述 12. 1產品的前景 22. 2產品的功能 22. 3用戶類和特征 22. 4運行環(huán)境 22. 5設計和實現上的限制 22. 6假設和依賴 23. 外部接口需求 33.1用戶界而 33. 2硬件接口 33. 3軟

2、件接口 33.4通信接口 34. 系統特性 34. 1說明和優(yōu)先級 44. 2鼓勵/響應序列 44. 3功能需求 45. 其它非功能需求 45. 1性能需求 45. 2平安設施需求 45. 3平安性需求 55. 4軟件質量屬性 55. 5業(yè)務規(guī)那么 55. 6用戶文檔 56. 其它需求 5附錄A :詞匯表 5附錄B :分析模型 6附錄C :待確定問題的列表 61.引言引言提岀了對軟件需求規(guī)格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。1.1 目的對產品進行泄義，在該文檔中詳盡說明了這個產品的軟件需求，包括修正或發(fā)行版本號。 如果這個軟件需求規(guī)格說明只與整個系統的一局部有關系，

3、那么就只圧義文檔中說明的局部或子 系統。1.2 文檔約定描述編寫文檔時所采用的標準或排版約左，包括正文風格、提示區(qū)或重要符號。例如， 說明了高層需求的優(yōu)先級是否可以被苴所有細化的需求所繼承，或者每個需求陳述是否都有英自 身的 優(yōu)先級。1? 3 預期的讀者和閱讀建議列舉了軟件需求規(guī)格說明所針對的不同讀者，例如開發(fā)人員、工程經理、營銷人員、用戶、測試 人員 或文檔的編寫人員。描述了文檔中剩余局部的內容及其組織結構。提出了最適合于每一類型讀者 閱讀文檔 的建議。1.4 產品的范圍提供了對指立的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業(yè)目標或業(yè)務策略相聯 系。 可以參考工程視圖和范圍文檔而不

4、是將其內容復制到這里。1. 5 參考文獻列舉了編寫軟件需求規(guī)格說明時所參考的資料或苴它資源。這可能包括用戶界而風格指導、合同、 標 準、系統需求規(guī)格說明、使用實例文檔，或相關產品的軟件需求規(guī)格說明。在這里應該給出詳細的信息，包括標題名稱、作者、版本號、日期、岀版單位或資料來源，以方便讀者查閱這些文獻。2. 綜合描述這一局部概述了正在定義的產品以及它所運行的環(huán)境、使用產品的用戶和的限制、假設和依 賴。2.1 產品的前景描述了軟件需求規(guī)格說明中所左義的產品的背景和起源。 說明了該產品是否是產品系列中的下一 成員， 是否是成熟產品所改良的下一代產品、是否是現有應用程序的替代品，或者是否是一個新型的、

5、 自含型產 品。如果軟件需求規(guī)格說明泄義了大系統的一個組成局部，那么就要說明這局部軟件是怎樣與整個系統相關聯的，并且要定義出兩者之間的接口。2. 2 產品的功能概述了產品所具有的主要功能。英詳細內容將在 4 中描述，所以在此只需要概略地總結，例如用列 表 的方法給岀。很好地組織產品的功能，使每個讀者都易于理解。用圖形表示主要的需求分組以及它 們之間 的聯系，例如數據流程圖的頂層圖或類圖，都是有用的。2. 3 用戶類和特征確定你覺得可能使用該產品的不同用戶類并描述它們相關的特征。有一些需求可能只與特立的用 戶類 相關。將該產品的重要用戶類與那些不太重要的用戶類區(qū)分開。2. 4 運行環(huán)境描述了軟件

6、的運行環(huán)境，包括硬件平臺、操作系統和版本，還有英它的軟件組件或與英共存的應 用程 序。2. 5 設計和實現上的限制確立彫響開發(fā)人員自由選擇的問題， 并說明這些問題為什么成為一種限制。 可能的限制包括如下 內容：? 必須使用或者防止的特窪技術、工具、編程語言和數據庫。? 所要求的開發(fā)標準或標準例如，如果由客戶的公司負責軟件維護，就必須泄義轉包者所使 用的 設計符號表示和編碼標準。? 企業(yè)策略、政府法規(guī)或工業(yè)標準。? 硬件限制，例如泄時需求或存儲器限制。? 數據轉換格式標準。2.6 假設和依賴列舉出在對軟件需求規(guī)格說明中影響需求陳述的假設因素與因素相對立。這可能包括你打 算 要用的商業(yè)組件或有關開

7、發(fā)或運行環(huán)境的問題。你可能認為產品將符合一個特殊的用戶界而設汁約 泄，但 是另一個讀者卻可能不這樣認為。如果這些假設不正確、不一致或被更改，就會使工程受到影 響。此外，確泄工程對外部因素存在的依賴。例如，如果你打算把其它工程開發(fā)的組件集成到系統中 , 那么 你就要依賴那個工程按時提供正確的操作組件。如果這些依賴已經記錄到其它文檔例如工程方案中了，那么在此就可以參考其它文檔3. 外部接口需求利用本節(jié)來確泄可以保證新產品與外部組件正確連接的需求。關聯圖表示了髙層抽象的外部接口。 需 要把對接口數據和控制組件的詳細描述寫入數據字典中。如果產品的不同局部有不同的外部接口， 那么應 把這些外部接口的詳細

8、需求并入到這一局部的實例中。3.1 用戶界面陳述所需要的用戶界而的軟件組件。描述每個用戶界面的邏借特征。以下是可能要包括的一些特 征：? 將要采用的圖形用戶界而 GUI 標準或產品系列的風格。? 屏幕布局或解決方案的限制。? 將出現在每個屏幕的標準按鈕、功能或導航鏈接例如一個幫助按鈕。? 快捷鍵。? 錯誤信息顯示標準。對于用戶界而的細巧，例如特泄對話框的布局，應該寫入一個獨立的用戶界而規(guī)格說明中，而不 能寫 入軟件需求規(guī)格說明中。3. 2 硬件接口描述系統中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交流的 數據 和控制信息的性質以及所使用的通信協議。3.3 軟件接口描

9、述該產品與其它外部組件由名字和版本識別的連接，包括數據庫、操作系統、工具、庫和 集成 的商業(yè)組件。明確并描述在軟件組件之間交換數據或消息的目的。描述所需要的效勞以及內部組 件通信的 性質。確泄將在組件之間共享的數據。如果必須用一種特殊的方法來實現數據共享機制，例如在多任務操作系統中的一個全局數據區(qū)，那么就必須把它運義為一種實現上的限制。3. 4 通信接口描述與產品所使用的通信功能相關的需求，包括電子郵件、 Web 瀏覽器、網絡通信標準或協議及電 子 表格等等。定義了相關的消息格式。規(guī)左通信平安或加密問題、數據傳輸速率和同步通信機制。4. 系統特性功能需求是根據系統特性即產品所提供的主要效勞來組

10、織的。 你可能更喜歡通過使用實例、 運行 模式、 用戶類 . 對彖類或功能等級來組織這局部內容IEEE1998 。你還可以使用這些元素的組合?？偠灾惚仨氝x擇一種使讀者易于理解預期產品 組織方案。僅用簡短的語句說明特性的爼稱，例如 "4. 1 拼寫檢查和拼寫字典管理。無論你想說明何種特性 , 闡 述每種特性時都將重述從 4. 1? 4. 3 這三步系統特性。4.1 說明和優(yōu)先級提岀了對該系統特性的簡短說明并指岀該特性的優(yōu)先級是髙、中，還是低?；蛘吣氵€可以包括對 特左 優(yōu)先級局部的評價，例如利益、損失、費用和風險，其相對優(yōu)先等級可以從 1 低到 9 高。4. 2 鼓勵/ 響應序列列

11、出輸入鼓勵 用戶動作、 來自外部設備的信號或其它觸發(fā)器 和泄義這一特性行為的系統響應 序列。 這些序列將與使用實例相關的對話元素相對應。4. 3 功能需求詳列出與該特性相關的詳細功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提 供的 特性執(zhí)行效勞或者使用所指左的使用實例執(zhí)行任務。描述產品如何響應可預知的出錯條件或者非 法輸入或 動作。每個需求的標識必須是唯一的。5. 其它非功能需求這局部列舉岀了所有非功能需求，而不是外部接口需求和限制5.1 性能需求闡述了不同的應用領域對產品性能的需求，并解釋它們的原理以幫助開發(fā)人員作出合理的設計選 擇。 確定相互合作的用戶數或者所支持的操作、響應

12、時間以及與實時系統的時間關系。你還可以在這 里左義容 量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。盡可能詳細地確 泄性能需求。 可能需要針對每個功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述。例如，“在運行微軟 Window 2000 的 450MhzPentiumII 的汁算機上， 當系統至少有 50 弔的空閑資源時 , 95% 的目錄數據庫 査詢必須在兩秒內完成。5. 2 平安設施需求詳盡陳述與產品使用過程中可能發(fā)生的損失、破壞或危害相關的需求。泄義必須采取的平安保護 或動 作，還有那些預防的潛在的危險動作。明確產品必須遵從的平安標準、策略或規(guī)那么。一

13、個平安設施需求的范例如下： "如果油箱的壓力超過了規(guī)泄的最大壓力的 95%,那么必須在 1 秒鐘內終止操作。品所 策略。一 最初的登錄能時 于有效性。能需碼的用用戶增加 操作等方 局部。望為術語。5. 3 平安性需求詳盡陳述與系統平安性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產 創(chuàng)立或使用的數據的保護。左義用戶身份確認或授權需求。明確產品必須滿足的平安性或保密性 個軟件系統的平安需求的范例如下： " 每個用戶在第一次登錄后，必須更改他的最初登錄密碼。 密碼不能重用。5. 4 軟件質量屬性詳盡陳述與客戶或開發(fā)人員至關重要的苴它產品質量特性。這些特性必須是

14、確定、泄量的并在可 是可驗證的。 至少應指明不同屬性的相對側重點， 例如易用程度優(yōu)于易學程度， 或者可移植性優(yōu)5. 5 業(yè)務規(guī)那么列舉出有關產品的所有操作規(guī)那么，例如什么人在特定環(huán)境下可以進行何種操作。這些本身不是功 求，但它們可以暗示某些功能需求執(zhí)行這些規(guī)那么。一個業(yè)務規(guī)那么的范例如下：“只有持有管理員密 戶才能執(zhí)行 $100. 00 或更大額的退款操作。5? 6 用戶文檔列舉出將與軟件一同發(fā)行的用戶文檔局部，例如，用戶手冊、在線幫助和教程。明確所有的 文檔的交付格式或標準。6. 其它需求定義在軟件需求規(guī)格說明的苴它局部未岀現的需求，例如國際化需求或法律上的需求。你還可以 有關操作、管理和維護局部來完善產品安裝、配置、啟動和關閉、修復和容錯，以及登錄和監(jiān)控 面的需求。在模板中參加與你的工程相關的新局部。如果你