? ? ? ?每個軟件開發組織都會為自己的項目選用一個或多個標準的軟件需求規范說明模板。有許多軟件需求規范說明模板可以使用(例如ISO/IEC/IEEE2011;Robertson and Robertson2013)。如果你的組織要處理各種類型或規模的項目，例如新的大型系統開發或是對現有系統進行微調，就要針對項目的主要類別來選擇一個軟件需求規范說明模板。第5章中的“模板策略”小節就涉及如何有效使用文檔模板。
? ? ? ?圖說明SRS模板適合很多類型的項目。附錄C包含的一個模板示例遵循的也是這個模板。此模板的每個小節都有使用指導說明，并可以從本書的配套網站下載。有些人在Word中將這些使用說明設置為“隱藏文字”，好讓你在文檔中留下提示。如果日后還想用，打開這些非打印字符就能看到說明。
? ? ? ?有時，某一些信息片斷會按邏輯記錄在好幾個模板部分中。選出其中一部分，然后在項目中前后一致地使用。不要到處復制信息，哪怕在邏輯上適合多個小節(Wiegers2006)。交叉引用和超鏈接可以幫助讀者找到他們需要的信息。
? ? ? ?創建需求文檔時，最好使用有效的版本控制實踐和工具，以確保所有讀者都知道自己在閱讀哪一個版本。還要在文檔中對修改歷史做變更記錄，包括何人何時因為何種原因做的修改(詳見第27章)。下面將描述軟件需求規范說明每個小節要包含的信息。
重點提示
? ? ? ?不要在軟件需求規格說明中簡單地復制信息，但可以參考其他現有的項目文檔來組織材料。文檔之間的超鏈接就可以實現上述目標，這與需求管理工具定義的可追蹤鏈接是一個道理。但是，
如果文檔文件夾層次結構發生變化，超鏈接就有被打亂的風險。
1.引言
? ? ? ?引言提出的是一個整體介紹，有助于讀者了解SRS是如何組織的，如何使用它。
1.1 目的
? ? ? ?對產品或應用進行定義，在這個文檔中說明產品或應用程序的需求，包括修訂或者發行版本號。如果這個SRS只與某個復雜系統的一部分有關，就只定義這個部分或子系統。描述文檔所針對的不同讀者類型，如開發人員、項目經理、營銷人員、用戶、測試人員和文檔作者。
1.2 文本約定
? ? ? ?描述所用的標準或排版約定，包括具體的文本風格、高亮或符號的意思。如果是在手動標注需求，也許還要在此說明你采用的格式，以便他人后期再添加內容。
1.3 項目范圍
? ? ? ?簡要描述所制定的軟件及其目的。將軟件與用戶、公司目標及業務目標和策略相關聯。如果有一個獨立愿景和范圍或其他類似文檔可用，可以將其作為參考，但不要將內容復制到此處。如果軟件需求規范說明規定要對一個演化產品進行增量式發布，那么就要將其自身的范圍說明包含進來，并將其作為長期戰略產品愿景的一部分。可能還要針對發布所包含的主要特性或者其要完成的重要功能，提供一個概要性的小結摘要。
1.4 參考文獻
? ? ? ?列舉本軟件需求規范說明所參考的文件或其他資源。如果參考文獻的位置不變，也可以列出其超鏈接。這可能包括用戶界面風格指南、合同、標準、系統需求規范說明、界面規范說明或者相關產品的軟件需求規范說明。給出的信息要足夠詳盡，包括標題、作者、版本號、日期、出處、存儲位置或URL, 以便讀者查閱每一個參考文獻。
2.整體描述
? ? ? ?這一部分高度概述產品及其使用的環境、預期的用戶和已知約束、假設及依賴。
2.1 產品前景
? ? ? ?描述產品的背景和起源。該產品是仍在發展中的產品系列中的下一成員? 成熟系統的下一版本?還是現有應用程序的替代品?或一個全新的產品?如果軟件需求規范說明定義了大型系統的一個組成部分,那么就要說明該軟件是如何與整個系統相關聯的，并且要確定兩者之間的主要接口。還要考慮將視覺模型包含進來，如背景圖或生態系統圖(詳見第5章)，展示產品與其他系統之間的關聯。
2.2 用戶類別和特征
? ? ? ?確定你覺得可能使用該產品的不同用戶類別并描述其相關特征。(詳見第6章)有些需求可能只與特定的用戶類別相關。確定出你的優待用戶。用戶類別代表的只是干系人的一部分，這點在愿景和范圍文檔中會有所描述。對用戶類的描述是一種可再利用的資源。如果你手頭上有一份重要用戶類別目錄，就可以合并對用戶類的描述，只需在目錄中簡單提及，無需在此復制信息。
2.3 運行環境
? ? ? ?描述軟件運行環境，包括硬件平臺;操作系統和版本;用戶、服務器和數據庫的地理位置;容納相關數據庫、服務器和網站的組織。列出系統必須與之共存的其他軟件組件或應用程序。如果還需要做一些額外的技術基礎設施工作以便與開發中的新系統相結合,就要考慮創建一個單獨的基礎設施需求規范說明來細化工作。
2.4 設計和實現約束
? ? ? 有時我們必須使用某種特定的編程語言,以及需要對特定代碼庫花費時間再次開發以便可以使用等等。描述限制開發人員選擇的因素，并說明每個約束的基本原理。如果需求包含或者寫入解決方案思路，而不是以需要為前提，就是在施加無意義的設計約束，所以要引起我們的警覺。第14章將對約束進行深入的探討。
2.5 假設和依賴
? ? ? ?假設就是在沒有確鑿證據或明確知識的情況下假定為真的說明。如果假設是錯誤的、過時的、不能共享或發生了變化，問題就會隨之而來，因此某些假設會給項目帶來風險。軟件需求規范說明的某一個讀者可能假設產品符合一個特殊的用戶界面約定，而另一個讀者卻可能不這樣認為;開發人員可能假設某組特定的功能是專門為這個應用程序而寫,業務分析師可能假設該功能在以前的項目中使用過，而項目經理可能希望獲取一個商業性功能庫。這里所包含的假設要與系統功能相關;與業務相關的假設包含在愿景和范圍文檔中。
? ? ? ?確定開發中的項目或者程序對外部因素或者其控制之外的組件存在的所有依賴關系。例如，在程序運行之前，必須安裝Microsoft.NET Framework 4.5或更新版本，這就是依賴。
3.系統特性
? ? ? ?圖中的模板顯示的是由系統特性所組織的功能需求，而這只是眾多組織方式中的一種。其他組織性選項還包括按照功能領域、工藝流程、用例、操作模式、用戶類別、刺激和響應來排列功能需求。我們還可以對這些要素進行層級組合，例如將用例和用戶類相結合。條條大路通羅馬，只要選擇的組織方法便于讀者理解產品的預期功能。下面描述的是某個特性方案示例。
3.x 系統特性X
? ? ? ?寥寥幾個單詞就可以說明特性的名稱，例如“3.1拼寫檢查”。針對每種特性，都可以用3.x中的下一小節3.x.1和3.x.2來重述。
3.x.1描述
? ? ? ?對系統特性進行簡要描述，表明它級別是高、中還是低。優先級是動態的，往往在項目過程中不斷變化。如果你使用需求管理工具，則要為需求屬性設置優先級。
3.x.2 功能需求
? ? ? ?列出與此特性相關的具體功能需求。這些軟件性能必須先完成，用戶才能執行特性的服務或者完成用例。描述產品如何響應可預知的錯誤條件以及無效的輸入和動作。正如本章前面所描述的那樣，每個功能需求都要有獨一無二的標識。如果是在使用需求管理工具，可以為每個功能需求創建多個屬性，例如基本原理、起源和狀態。
4.數據需求
? ? ? ?信息系統通過處理數據來提供價值。使用模板中的這一部分來描述各方面的數據，系統會將其作為輸入來消耗，將其以某種形式來加工，或者將其作為輸入來創建。Stephen Withall(2007)闡述了精確記錄數據(也稱之為信息)需求的多種模式。
4.1 邏輯數據模型
? ? ? ?數據模型從視覺上呈現了系統要處理的數據目標和集合以及它們之間的關系。數據建模中含有大量的符號，包括實體關系圖和UML類圖。你可能還要為系統所強調的業務運作納入一個數據模型，或者針對系統要處理的數據展示其邏輯關系。這與納入一個數據模型不是一回事，這樣的模型將會以數據庫設計的形式來實現。
4.2 數據字典
數據字典定義數據結構的組成及其意義、數據類型、長度、格式以及組成這些結構的數據元素的允許值。商業數據建模工具通常包括一個數據字典組件。在大多數情況下，都應將數據字典存儲為一個獨立的工件，而不是將它嵌入在軟件需求規范說明之中。這樣一來，其他項目也可以重用它。
4.3 報告
? ? ? ?不管應用程序形成什么報告，都要將其在此確定出來并描述特征。如果報告必須要與某個具體的預定義的布局相吻合，可以將其定義為一個約束，可能還要有一個示例。否則，就將重點放在報告內容、排列順序、總體水平等的邏輯描述上，并將詳細的報告布局推遲到設計階段。
4.4 數據獲取、整合、保存和處理
? ? ? ?如果有涉及，就要描述數據是如何獲取和保存的。例如，當開始填入庫存數據時，可能首先需要將所有庫存數據“導入”接收系統之中，后面無須填入有變化的數據。陳述任何涉及需要系統數據完整性保護方面的需求。確定必要的具體技術，如備份、檢查點、鏡像或數據準確性驗證。陳述系統保持或者銷毀數據時必須執行的政策，包括臨時數據、元數據、殘留數據(如已刪除的記
錄)、緩存數據、本地副本、歸檔和臨時備份。
5.外部接口需求
? ? ? ?這部分所提供信息是為了保證系統與用戶、與外部硬件或軟件元素之間的正常通信。外部與系統內部接口無縫對接是軟件行業公認的最佳實踐之一(Brown 1996)。如果一個復雜系統有多個組成部分，則應創建一個獨立的接口規范說明或者系統架構規范說明。接口文檔可以吸納其他文檔中的材料作為參考。例如，它可以指向硬件設備手冊，手冊中列有設備發送到軟件的錯誤代碼。
?
接口之爭
? ? ? ? 兩個軟件團隊合作為A.Datum公司開發一款旗艦產品。知識庫團隊用 C++語言開發了一款復雜的推理引擎，應用程序團隊用Java語言實現用戶接口。這兩個子系統之間通過應用程序編程接口(API)交互。不幸的是，知識庫團隊定期修改API，導致系統不能完整開發并正確執行。應用程序團隊花好幾個小時才診斷出他們發現的每一個問題，后來才發現根本原因在于API的變更。兩個團隊對這些變更沒有達成一致意見，所以這些變更沒有傳達給受到影響的各方，而且沒有用Java代碼體現相應的修改。接口的變更需要個人、團體或系統在此接口的其他方面進行交的修改。接口的變更需要個人、團體或系統在此接口的其他方面進行交流。接口將系統組件(包括用戶)結合在一起，因此，整個項目變更控制過程中，需要記錄接口細節并同步必要的修改。
5.1 用戶界面
? ? ? 描述系統所需的每個用戶界面的邏輯特征。下面是可能涉及的一些內容:
- 參考將要遵循的用戶界面標準或是產品線風格指南
- 字體、圖標、按鈕標簽、圖像、色彩方案、字段序列、常用控件、品牌圖形、版權和隱私聲明等標準
- 屏幕大小、布局或分辨率約束顯示在每一屏上的標準按鈕、功能或導航鏈接，例如幫助按鈕
- 快捷鍵
- 信息顯示和語法規則
- 數據驗證準則(如輸入值的限制和何時驗證字段內容)
- 便于軟件本地化的布局標準
- 為視力受損者、色盲或其他受限用戶提供的便利方案
5.2 軟件接口
? ? ? ? 描述該產品與其他軟件組件(由名稱和版本來標識)之間的關聯，包括其他應用程序、數據庫、操作系統、工具、庫、網站和集成的商業組件;陳述目的、格式和信息內容、數據和控件值，這些都要在軟件組件之間進行交換;指定系統與任何轉換之間的輸入和輸出數據地圖,使數據從一個系統轉到其他系統;描述外部軟件組件所需或者引申出來的服務以及內部組件間通信的性質;確定在軟件組件之間交換或者共享的數據;指出影響接口的非功能需求，例如針對響應時間和頻率的服務等級，或安全控制和限制。其中一些信息可能會被歸為數據需求或者互通性需求(質量屬性)。
?
5.3 硬件接口
? ? ? ? 硬件接口描述軟件組件和硬件組件之間每個界面(還可能包括系統)的特征。這部分描述可能包括支持的設備類型、軟硬件之間的數據和控制交互以及將會用到的通信協議。列出輸入和輸出、其格式、有效值或范圍以及開發人員需要注意的時機問題。如果這節的信息量很大，可以考慮創建一個獨立的接口規范說明文檔。
5.4 通信接口
? ? ? ?陳述與產品通信功能相關的所有需求，包括電子郵件、瀏覽器、網際協議和電子表單。定義任何相關的信息格式。規定通信安全和加密問題、數據傳輸率、信號交換和同步機制。陳述對這些接口的任何約束，例如電子郵件中特定的附件類型能否接受。
6.質量屬性
? ? ? ?本節主要規定非功能需求而非約束和外部界面需求。質量需求必須是確定的、定量的并可驗證的。表明各種屬性的相對優先級，例如易用程度要優于易學程度，保密性優于性能。相比簡單的描述性陳述，諸如planguage這樣內涵深刻的規范說明符號更能解釋清楚每種質量的需求級別。
6.1 易用性
? ? ? ?易用性需求涉及易學程度、易用程度、錯誤的規避和恢復、交互效率和可理解性。這里所規定的易用性需求將幫助用戶界面設計師開發出最佳用戶體驗。
6.2 性能
? ? ? ?陳述針對各種系統操作的具體性能需求。如果不同的功能需求或特性有不的性能需求，最好將性能目標與相應功能需求結合在一起進行規定，而不是在這一部分收集它們。
6.3 保密性
? ? ? ?這里規定的需求都關系到限制產品進入或使用的涉及保密或隱私問題的需求。主要包括物理、數據或軟件方面的保密性。保密性需求通常起源于業務規則，因此要確定產品必須遵守的保密或隱私政策或法規。如果這些都已記錄在業務規則庫中，參考它們即可。
6.4 安全性
? ? ? ?這里規定的需求涉及產品在使用過程中可能遭受的損失、破壞或傷害。規定必須采取的安全保障措施或行動以及必須預防的有潛在危險的行動。確定產品必須遵守的安全證書、政策或法規。
6.x【其他]
? ? ? ?針對每一個額外的產品質量屬性，在軟件需求規范說明中單獨設置一節來描述對客戶、開發人員和維護人員都很重要的特征。這些需求可能涉及易用性、效率、可安裝性、完整性、互操作性、可修改性、可移植性、可靠性、可重用性、穩健性、可擴展性和可驗證性。
7.國際化和本地化需求
國際化和本地化需求確保產品適用于不同國家、文化和地理區域而非產品開發所在地。此類需求注重的是貨幣的差異;日期格式、數字、地址和電話號碼;語言(包括不同國家對同種語言的拼寫習慣，例如美式英語與英式英語)、使用的符號和字符設置;姓氏和名字的順序;時區;國際法律法規;文化和政治問題;所用紙張尺寸;度量衡;電壓和插頭形狀;等等。國際化和本地化需求可以跨項目重復使用。
8.[其他需求]
? ? ? ?定義軟件需求規范說明中沒有涵蓋的其他一些需求。例如與法律、法規或財務合規和標準相關的需求;用于產品安裝、配置、啟動和關閉的需求;用于登陸、監測和審計跟蹤的需求。不能簡單地把上述這些都劃歸到“其他”名下，任何與你項目有關的新內容都要添加到模板之中。如果這一節的需求已經出現在其他小節，就將其省略。
附錄 A:詞匯表
? ? ? ?定義所有專用詞條，以便讀者能夠理解軟件需求規范說明，包括首字母縮略詞和縮寫詞。將每個首字母縮略詞拼寫出來并給出定義。可以考慮建立一個可重復利用的企業級詞匯表，此表可以跨項目使用，并且吸納與本項目相關的其他術語。然后，每個軟件需求規范說明只定義針對單個項目、不出現在企業級詞匯表中的術語。注意:數據定義屬于數據字典，而非詞匯表。
附錄B:分析模型
? ? ? ?這一節是可選，包含或涉及相關的分析模型，例如數據流程圖、特性樹、狀態轉化圖或是實體關系圖。如果將相關模型放在規范說明的相關章節之中，而不是將其放在結尾處，對讀者的幫助會更大。
