精品文檔需求規格說明書(ISO標準版)編者說明： 當需求調查、分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟件需求規格說明書，也就是SRS。這是在軟件項目過程中最有價值的一個文檔。ISO所提供的標準雖然已經時間久遠，但還是頗具參考價值的。1引言1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者。1.2背景a.待開發的系統的名稱;b.本項目的任務提出者、開發者、用戶；c.該系統同其他系統或其他機構的基本的相互來往關系。1.3定義 列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料 列出用得著的參考資料。2任務概述2.1目標敘述該系統開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該系統開發的背景材料。解釋被開發系統與其他有關系統之間的關系。2.2用戶的特點列出本系統的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本系統的預期使用頻度。2.3假定和約束 列出進行本系統開發工作的假定和約束。3需求規定 3.1對功能的規定用列表的方式，逐項定量和定性地敘述對系統所提出的功能要求，說明輸入什么量、經怎么樣的處理、得到什么輸出，說明系統的容量,包括系統應支持的終端數和應支持的并行操作的用戶數等指標。3.2 對性能的規定3.2.1精度 說明對該系統的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3.2.2時間特性要求 說明對于該系統的時間特性要求。3.2.3靈活性說明對該系統的靈活性的要求，即當需求發生某些變化時，該系統對這些變化的適應能力。3.3輸入輸出要求解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對系統的數據輸出及必須標明的控制輸出量進行解釋并舉例。3.4數據管理能力要求（針對軟件系統）說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。3.5故障處理要求列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。3.6其他專門要求如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。4運行環境規定4.1設備 列出運行該軟件所需要的硬設備。說明其中的新型設備及其專門功能，包括：a.處理器型號及內存容量b.外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量c.輸入及輸出設備的型號和數量，聯機或脫機；d.數據通信設備的型號和數量e.功能鍵及其他專用硬件4.2支持軟件列出支持軟件，包括要用到的操作系統、編譯程序、測試支持軟件等。4.3接口 說明該系統同其他系統之間的接口、數據通信協議等。4.4控制 說明控制該系統的運行的方法和控制信號，并說明這些控制信號的來源。需求規格說明書(Volere版)編者說明： Atlantic System Guild（）公司所提供的Volere需求過程與軟件需求規格說明書模板則充分利用了現代軟件工程思想與技術，是一個十分實用、完善的SRS模板。其所提供的Volere需求記錄卡也十分實用，強烈推薦。注：從Atlantic System Guild公司網站上獲得，并稍做修改1.產品的目標1.1 該項目工作的用戶問題或背景對引發開發任務的工作和情況的描述。同時也應描述用戶希望用將要交付的軟件來完成的工作。該節內容為該項目提供了合法的理由，你應該考慮用戶的問題是否嚴重，是否應該解決和為什么應該解決。1.2 產品的目標用一句話或很少的幾句話來說明“我們希望該產品做什么？”換言之，即開發該產品的真正原因。項目如果沒有一個表述清晰、易于理解的目標，就會迷失在產品開發的沙漠中。產品必須帶來某種優勢。典型的優勢是產品會增加組織在市場上的價值，減少運作成本，或提供更好的客戶服務。這個優勢應該是可度量的，這樣才能夠讓您確定交付的產品是否達到目標。2.客戶、顧客和其它風險承擔者2.1 客戶是為開發付費的人，并將成為所交付產品的擁有者 這一項必須給出客戶的姓名，三個以內是合理的。客戶最終將接受該產品，因此必須對交付的產品滿意。如果你無法找到一個客戶的姓名，那么也許你就不應該構建該產品。2.2 顧客是將花錢購買該產品的人 也給出姓名和相關的信息2.3 其它風險承擔者 其他的一些人或組織的名稱，他們或者受到產品的影響，或影響產品。1） 經理或項目負責人；2） 業務領域專家；3） 技術人員；4） 系統開發者；5） 市場人員；6） 產品經理；7） 測試和質量保證人員；8） 審查員，諸如安全審查員或審計人員；9） 律師；10）易用性專家；11）你所處行業的專業人員。3.產品的用戶3.1 產品的用戶 產品的潛在用戶或操作員的列表。針對每種類型的用戶，提供以下信息：1） 用戶分類2） 用戶工作的任務；3） 主要相關的經驗；4） 技術經驗；5） 其他用戶特征：包括身體、智力、工作態度、對技術的態度、教育程度、語言技能、年齡、性別等。用戶是為了完成工作而與產品交互的人，你了解用戶，就越可能提交適合用戶工作方式的產品。3.2 對用戶設的優先級 在每類用戶后面附上一個優先級，這區別了用戶的重要性和優先地位：1） 關鍵用戶：對產品的后續成功至關重要；2） 次要用戶：他們使用產品，但對產品的長期成功并無影響；3） 不重要的用戶：不常用、未授權和沒有技能的用戶。如果認為某些用戶對產品或組織更重要，那么應該寫明，因為它會影響你設計產品的方式。4.需求限制條件4.1 解決方案限制條件此處明確了限制條件，它們規定了解決問題必須采取的方式。您可以認為它們是指令式的解決方案。仔細描述該解決方案，以及測試是否符合的度量標準。如果可能，您應該解釋使用該解決方案的原因。換一句話說，就是要求軟件解決方案滿足哪些限制條件！4.2 實現環境 此處描述產品將被實施的技術環境和物理環境。 該環境也將成為設計解決方案時的限制條件之一。4.3 伙伴應用 此處描述那些不屬于產品的一部分，但產品卻又必須與其協作的應用程序。4.4 COTS 此處描述實現產品需求所必須使用的COTS(商業組件)。4.5 預期的工作場地環境此處描述用戶工作和使用該產品的工作場地。此處應該描述任何可能對產品設計產生影響的工作場地特征。4.6 開發者構建該產品需要多少時間 任何已知的最后期限，或商業機會的時限，應在此處說明。4.7 該產品的財務預算是多少 該產品的預算，以金錢的形式或可得資源的形式說明。5.命名標準和定義定義項目中使用到的所有術語，包括同義詞。這里的內容就是一個字典，包括在需求規格說明書中使用的所有名稱的含義。這個字典應該使用你的組織或行業使用的標準名稱。這些名稱也應該反映出在工作領域中當前使用的術語。該字典包括項目中用到的所有名稱。請仔細地選擇名稱，以避免傳達不同的、不期望的含義。為每個名字寫下簡明扼要的定義，這些定義必須經過相應的風險承擔者同意。6.相關事實可能對產品產生影響的外部因素，但不是命令式的需求限制條件。7.假定列出開發者所做的假設。將所有的假設列在此的目的是讓每一個項目成員都意識到這個假設。8.產品的范圍8.1 工作的上下文范圍上下文范圍圖用來表示將要開發的系統、產品與其它系統之間的關系，以確定系統邊界。8.2 工作切分 一個事件清單，確定系統要響應的所有業務事件。清單包括：1） 事件名稱2） 輸入和輸出8.3 產品邊界 你可以使用用例圖(use-case)來確定了用戶與產品之間的邊界。9.功能性需求與數據需求9.1 功能性需求 對產品必須執行的動作的描述。 每個功能性需求必須有一個驗收標準。9.2 數據需求 與產品/系統有密切關系的主題域相關的業務對象、實體、類的說明書。 進行問題域建模，生成相應的類圖。10.觀感需求一些與產品的用戶界面相關的需求描述。11.易用性需求11.1 易于使用 描述如何構建符合最終用戶期望的產品。11.2 學習的容易程序 學習使用該產品應該多容易的說明。通常是有學習時間來衡量。12.性能要求12.1 速度需求 明確完成特定任務需要的時間，這常常指響應時間。12.2 安全性的需求 對可能造成人身傷害、財產損失和環境破壞所考慮到的風險進行量化描述。12.3 精度需求 對產品產生的結果期望的精度進行量化描述。12.4 可靠性和可用性需求本節量化產品所需的可靠性。這常常表述為允許的兩次失敗之間無故障運行時間，或允許的總失敗率。12.5 容量需求 本節明確處理的吞吐量和產品存儲數據的容量。13.操作需求13.1 預期的物理環境 本節明確產品將操作的物理環境，以及這種環境引起的任何特殊需求。13.2 預期的技術環境 硬件和其它組成新產品操作環境的設備的規范。13.3 伙伴應用程序 對產品必須與之交互的其它應用程序的描述。14.可維護性和可移植性需求14.1 維護該產品需要多容易 對產品作特定修改所需時間的量化描述。14.2 是否存在一些特殊情況適用于該產品的維護 關于預期的產品發布周期和發布將采取的形式的規定。14.3 可移植性需求 對產品必須支持的其他平臺或環境的描述。15.安全性需求15.1 該產品是保密的嗎？ 關于該被授權使用該產品，以及在什么樣的情況下授權等方面的描述。15.2 文件完整性需求 關于需要的數據庫和其他文件完整性方面的說明。15.3 審計需求 關于需要的審計檢查方面的說明。16.文件和政策需求本節包括針對社會和政策的因素的規格說明，這些因素會影響產品的可接受性。如果你開發的產品是針對外國市場的，可能要特別注意這些需求。問一下是否產品的目標是你所不熟悉的文化環境，是否其它國家的人或其他類型的組織的人會使用該產品。人們是否有與你的文化不同的習慣、節日、迷信、文化上的社會行為規范。17.法律需求17.1 該產品是否受到某些法律的管制 明確該產品的法律需求的描述。17.2 是否有一些必須符合的標準 明確適用的標準和參考的詳細標準的描述。18.Opend問題對未確定但可能對產品產生重要影響的因素的問題描述。按照需求分析的術語還說，就是TBD（To Be Define）的問題。19.COTS解決方案19.1 是否有一些制造好的產品可以購買 應該調查現存產品清單，這些產品可以作為潛在的解決方案。19.2 該產品是否可使用制造好的組件 描述可能用于該產品的候選組件，包括采購的和公司自己的產品。列出來源。19.3 是否有一些我們可以復制的東西 其他相似產品的清單。20.新問題20.1 新產品會在當前環境中帶來什么問題 關于新產品將怎樣影響當前的實現環境的描述。20.2 新的開發是否將影響某些已實施的系統 關于新產品將怎樣與現存系統協同工作的描述。20.3 是否我們現有的用戶會受到新開發的敵對性影響 關于現有用戶可能產生的敵對性反應的細節。20.4 預期的實現環境會存在什么限制新產品的因素 關于新的自動化技術、新的組織結構方式的任何潛在問題的描述。20.5 是否新產品會帶來其他問題 確定我們可能不能處理的情況。21.任務21.1 為提交該產品已經做了哪些事用來開發產品的生命周期和方法的細節。畫一個高層的過程圖展示各項任務和它們之間的接口，這可能是溝通這方面信息的最好辦法。21.2 開發階段 關于每個開發階段和操作環境中的組件的規格說明。22.移交22.1 我們要讓已有數據和過程配合新產品，有什么特殊要求 一個移交活動的列表，一個實現的時間表。22.2 為了新產品，哪些數據必須修改/轉換 數據轉換任務清單，同時確定新產品需要轉換的數據。23. 風險23.1 當你開發該產品時，要面對什么風險23.2 你制定了怎樣的偶然緊急情況計劃24.費用 需求的其他費用是你必須投入到產品構建中去的錢或工作量。當需求規格說明書完成時，你可以使用一種估算方法來評估費用，然后以構建所需的資金或時間的形式表述出來。25.用戶文檔用戶文檔的清單，這些文檔將作為產品的一部分交付。26.后續版本的需求這里記錄下一些希望今后版本中實現的需求。Volere需求記錄卡編者說明：正如前面所述，Atlantic System Guild還提供了一個配套的Volere需求記錄卡，這個記錄卡十分實用。建議大家在需求調查、分析過程中，將需求記錄在一系列的Volere需求記錄卡上，這個卡讓你能夠很好的理清需求之間的關系，需求提出的背景，用戶對需求的期望，有了這些素材，整理SRS時將變得更加簡單。需求#： 需求類型： 事件/用例#：描述：理由：來源：驗收標準：顧客滿意度： 顧客不滿意度：依賴關系： 沖突：支持材料：歷史：Copyright Atiantic system GuildVolere注：顧客滿意度是指完成該項功能顧客滿意的程度，而顧客不滿意度則是指未實現該功能顧客不滿意的程度。軟件需求規格說明書頁：9 注，以RUP軟件需求規約進行修改。（RUP版）編者說明： 如果在需求分析時采用了用例（Use case）技術，那么該需求規格說明書將更加符合你的需要。當然，你也可以結合Volere需求規格說明書對該模板進行必要的修改。1. 文檔概述該部分主要是對軟件需求規格說明書文檔進行基本的描述，包括該文檔的目的、范圍、術語定義、參考資料以及概要。軟件需求規格說明書用來系統、完整地記錄系統的軟件需求。該軟件需求說明書的基礎是用例分析技術。因此該文檔中應包括用例模型、補充規約等內容。1.1目的在此小節中，主要對軟件需求規格說明書的目的做一概要性說明，通常軟件需求規格說明書應詳細地說明應用程序、子系統的外部行為，還要說明非功能性需求、設計約束，以及其它的相關因素。1.2范圍系統是有范圍的，而不是無限擴展的，對于無限擴展的需求是無法進行描述的。因此，在本小節應該對該說明書所涉及的項目范圍進行清晰的界定。指定該規格說明書適用的軟件應用程序、特性或者其它子系統分組、其相關的用例模型。當然在此也需要列出會受到該文檔影響的其它文檔。1.3 定義、首字母縮寫詞和縮略語與其它文檔一樣，該文檔也需要將本文檔中所涉及的所有術語、縮略語進行詳細的定義。還有一種可簡明的做法，就是維護在一個項目詞匯表中，這樣就可以避免在每個文檔中都重復很多內容。1.4參考資料在這一小節中，應完整地列出該文檔引用的所有文檔。對于每個引用的文檔都應該給出標題、標識號、日期以及來源，為閱讀者查找這些文檔提供足夠詳細的信息。1.5 概述在本小節中，主要是說明軟件需求規格說明書各個部分所包含的主要內容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。2. 整體說明在本節中，將對整個軟件需求進行總體性的描述，以期讓讀者對整個軟件系統的需求有一個框架性的認識。也就是說，該節中主要包括影響產品及其需求的一般因素，而不列舉 具體的需求。主要包括產品總體效果、產品功能、用戶特征、約束、假設與依賴關系、需求子集等方面的內容。2.1用例模型在本小節中，將列出該軟件需求的用例模型，該模型處于系統級，對系統的特性進行宏觀的描述。在此應該列出所有的用例和Actor的名稱列表，并且對其做出簡要的說明，以及在圖中的各種關系。2.2 假設與依賴關系在軟件系統的開發過程中，存在許多假設和依賴關系。在本小節中應列舉出所有的重要的技術可行性假設、子系統或構件可用性假設，以及一些可行性的假設。3. 具體需求如果說第二章節是框架，那么本節就是血肉。在本節中，應該詳細列出所有的軟件需求，其詳細程序應使設計人員能夠充分理解并且進行設計的要求，同時也應該給予測試人員足夠的信息，以幫助他們來驗證系統是否滿足了這些需求。整個需求的組織可以采用用例描述進行。3.1用例描述如果你使用用例建模技術，那么你已經通過用例定義了系統的大部分功能性需求和一些非功能性需求。因此，在軟件需求規格說明書只需將這些具體的用例描述，整理在一起，全部放在該小節之中。當然也可以將用例描述做為附件，在此列出引用，只是這樣做并不利于閱讀。建議在組織形式上采用以“軟件需求”為線索，在每個需求中，填入對應的1個或幾個用例描述。3.2補充需求由于用例畢竟主要針對功能性需求，因此還會有一些其它的補充需求遺漏，因此在本小節中就是將這些東西補充出來。這些補充需求大部分集中在非功能需求之上，包括以下幾個方面的內容：1） 易用性：例如指出普通用戶和高級用戶要高效地執行某個特定操作所需的培訓時間；指出典型任務的可評測任務次數；或者指出需要滿足的可用性標準（如IBM的CUA標準、Microsoft的GUI標準。2） 可靠性：包括系統可用性（可用時間百分比、使用小時數、維護訪問權、降紙模式操作等）；平均故障間隔時間（MTBF，通常表示為小時數，但也可表示為天數、月數或年數）；平均修復時間（MTTR，系統在發生故障后可以暫停運行的時間）；精確度（指出系統輸出要求具備的精密度、分辨率和精確度）；最高錯誤或缺陷率（通常表示為bugs/KLOC，即每千行代碼的錯誤數目或 bugs/function-point，即每個功能點的錯誤數目）；錯誤或缺陷率（按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重”錯誤進行界定，例如：數據完全丟失或完全不能使用系統的某部分功能）。3） 性能：包括對事務的響應時間（平均、最長）；吞吐量（例如每秒處理的事務數）；容量（例如系統可以容納的客戶或事務數）；降級模式（當系統以某種形式降級時可接受的運行模式）；資源利用情況：內存、磁盤、通信等。4） 其它：包括用戶界面要求、聯機幫助系統要求、法律許可、外購構件，以及操作系統、開發工具、數據庫系統等設計約束。4.支持信息支持信息用于使軟件需求規格說明書更易于使用。它包括：目錄、索引、附錄等。計算機軟件需求說明編制指南（國標版）編者說明： 軟件需求規格說明是十分重要的文檔，因此為開發團隊提供一份詳細的編制指南是十分有意義和必要的。本文檔就是一個編制指南的例子，你可以根據該指南，結合自己的實際情況進行修改。1引言 1.1 目的和作用 本指南為軟件需求實踐提供了一個規范化的方法。本指南不提倡把軟件需求說明（Software Requirements Specifications，以下簡稱SRS）劃分成等級，避免把它定義成更小的需求子集。 本指南適用對象： 1）軟件客戶（Customers），以便精確地描述他們想獲得什么樣的產品。 2）軟件開發者（Suppliers），以便準確地理解客戶需要什么樣的產品。 對于任一要實現下列目標的單位和（或）個人： 1）要提出開發規范化的SRS提綱； 2）定義自己需要的具體的格式和內容； 3）產生附加的局部使用條款，如SRS質量檢查清單或者SRS作者手冊等。 SRS將完成下列目標： 1） 在軟件產品完成目標方面為客戶和開發者之間建立共同協議創立一個基礎。對要實現的軟件功能做全面描述，幫助客戶判斷所規定的軟件是否符合他們的要求，或者怎樣修改這種軟件才能適合他們的要求； 2） 提高開發效率。編制SRS的過程將使客戶在設計開始之前周密地思考全部需求，從而減少事后重新設計、重新編碼和重新測試的返工活動。在SRS中對各種需求仔細地進行復查，還可以在開發早期發現若干遺漏、錯誤的理解和不一致性，以便及時加以糾正； 3） 為成本計價和編制計劃進度提供基礎。SRS提供的對被開發軟件產品的描述，是計算機軟件產品成本核算的基礎，并且可以為各方的要價和付費提供依據。SRS對軟件的清晰描述，有助于估計所必須的資源，并用作編制進度的依據； 4） 為確認和驗證提供一個基準。任何組織將更有效地編制他們的確認和驗證計劃。作為開發合同的一部分，SRS還可以提供一個可以度量和遵循的基準（然而，反之則不成立，即任一有關軟件的合同都不能作為SRS。因為這種文件幾乎不包括詳盡的需求說明，并且通常不完全的）； 5） 便于移植。有了SRS就便于移值軟件產品，以適應新的用戶或新的機種。客戶也易于移植其軟件到其他部門，而開發者同樣也易于把軟件移植到新的客戶； 6） 作為不斷提高的基礎。由于SRS所討論的是軟件產品，而不是開發這個產品的設計。因此SRS是軟件產品繼續提高的基礎。雖然SRS也可能要改變，但是原來的SRS還是軟件產品改進的可靠基礎。 1.2 范圍 本指南適用于編寫軟件需求規格說明，它描述了一個SRS所必須的內容和質量，并且在第6章中提供了SRS大綱。 2引用標準 GB 8566 計算機軟件開發規范 GB 8567 計算機軟件產品開發文件編制指南 GB/T 11457 軟件工程術語 3定義 GB/T 11457所列術語和下列定義適用于本指南。 合同（contract）：是由客戶和開發者共同簽署的具有法律約束力的文件。其中包括產品的技術、組織、成本和進度計劃要求等內容。 客戶（customer）：指個人或單位，他們為產品開發提供資金，通常（但有時也不必）還提出各種需求。文件中的客戶和開發者也可能是同一個組織的成員。 語言（language）：是具有語法和語義的通信工具，包括一組表達式、慣例和傳遞信息的有關規則。 分割（partitioning）：把一個整體分成若干部分。 開發者（supplier）：指為客戶生產某種軟件產品的個人或集團。在本指南中，客戶和開發者可能是同一個組織的成員。 用戶（user）：指運行系統或者直接與系統發生交互作用的個人或集團。用戶和客戶通常不是同一些人。 4編寫SRS的背景信息 4.1 SRS的基本要求 SRS是對要完成一定功能、性能的軟件產品、程序或一組程序的說明。對SRS的描述有兩項基本要求： 1）必須描述一定的功能、性能； 2）必須用確定的方法敘述這些功能、性能。 4.2 SRS的環境 必須認識到SRS在整個軟件開發規范（見GB 8566）所規定的有關階段都起作用。正因為如此，SRS的起草者必須特別注意不要超出這種作用的范圍。這意味著要滿足下列要求： 1） SRS必須正確地定義所有的軟件需求； 2） 除設計上的特殊限制之外，SRS中一般不描述任何設計、驗證或項目管理細節。 4.3 SRS的特點 4.3.1 無歧義性 當且僅當它對每一個需求只有一種解釋時，SRS者是無歧義的。 1） 要求最終產品的每一個特性用某一術語描述； 2） 若某一術語在某一特殊的行文中使用時具有多種歧義，那么對該術語的每種含義作出解釋并指出其適用場合。 需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。 4.3.2 完整性 如果一個SRS能滿足下列要求，則該SRS就是完整的： 1） 包括全部有意義的要求，無論是關系到功能的、性能的、設計約束的，還是關系到屬性或外部接口方面的需求； 2） 對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響應做出規定； 3） 要符合SRS要求。如果個別章節不適用，則在SRS中要保留章節號； 4） 填寫SRS中的全部插圖、表、圖示標記和參照，并且定義全部術語和度量單位。 關于使用“待定”一詞的規定 任何一個使用“待定”的SRS都是不完全的。 1） 若萬一遇到使用“待定”一詞時，作如下處理： 對產生“待定”一詞的條件進行描述，使得問題能被解決； 描述必須干什么事，以刪除這個“待定”；2） 包含有“待定”一詞的任何SRS的項目文件應該： 標識與此特定文件有關的版本號或敘述其專門的發布號； 拒絕任何仍標識為“待定”一詞的SRS章節的許諾。 4.3.3 可驗證性 當且僅當SRS中描述的每一個需求都是可以驗證的，該SRS才是可以驗證的；當且僅當在某一性能價格比可取的有限處理過程，人或機器能通過該過程檢查軟件產品能否滿足需求時，才稱這個需求是可以驗證的。 4.3.4 一致性 當且僅當SRS中各個需求的描述是不矛盾時SRS才是一致的。 4.3.5 可修改性 如果一個SRS的結構和風格在需求有必要改變時是易于實現的、完整性的、一致的，那么這個SRS就是可以修改的。可修改性要求SRS具備以下條件： 1） 具有一個有條不紊的易于使用的內容組織，具有目錄表，索引和明確的交叉引用表； 2） 沒有冗余。即同一需求不能在SRS中出現多次。 冗余本身不是錯誤，但是容易發生錯誤。冗余可增加SRS的可讀性，但是在一個冗余文件被更新時容易出現問題。例如：假設一個明確的需求在兩個地方詳細列出，后來發現這個需求需要改變，若只修改一個地方，于是SRS就變得不一致了。 不管冗余是否必須，SRS一定要包含一個詳細的交叉引用表，以便SRS具備可修改性。 4.3.6 可追蹤性 如果每一個需求的源流是清晰的，在進一步產生和改變文件編制時，可以方便地引證每一個需求，則該SRS就是可追蹤的。建議采用如下兩種類型的追蹤： 1） 向后追蹤（即向已開發過的前一階段追蹤）。根據先前文件或本文件前面的每一個需求進行追蹤。 2） 向前追蹤（即是向由SRS派生的所有文件追蹤）。根據SRS中具有唯一的名字和參照號的每一個需求進行追蹤。 當SRS中的一個需求表達另一個需求的一種指派或者是派生的，向前、向后的追蹤都要提供。例如： 1） 從總的用戶響應時間需求中分配給數據庫操作響應時間； 2） 識別帶有一定功能和用戶接口的需求的報告格式； 3） 支持法律或行政上需要的某個軟件產品（例如，計算稅收）。在這種情況下，要指出軟件所支持的確切的法律或行政文件。 當軟件產品進入運行和維護階段時，SRS的向前可追蹤性顯得特別重要。當編碼和設計文件作修改時，重要的是要查清這些修改所影響的全部需求。 4.3.7 運行和維護階段的可使用性 SRS必須滿足運行和維護階段的需要，包括軟件最終替換。 1） 維護常常是由與原來開發無聯系的人來進行的。局部的改變（修正）可以借助于好的代碼注釋來實現。對于較大范圍的改變。設計和需求文件是必不可少的，這里隱含了兩個作用： 如4.3.5 條指出，SRS必須是可修改的； SRS中必須包括一個記錄，它記錄那些應用于各個成分的所有具體條文。例如：它們的危急性（如故障可能危及完全或導致大量財政方面和社會方面的損失）；它們僅與暫時的需要相關（如支持一種可立即恢復原狀的顯示）；它們的來源（如某功能是由已存在的軟件產品的全部拷貝復制而成）。 2） 要求在SRS中清楚地寫明功能的來源和目的，因為對功能的來源和引入該功能的目的不清楚的話，通常不可能很好地完成軟件的維護。 4.4 SRS的編制者 軟件開發的過程是由開發者和客戶雙方同意開發什么樣的軟件協議開始的。這種協議要使用SRS的形式，應該由雙方聯合起草。這是因為： 1） 客戶通常對軟件設計和開發過程了解較少，而不能寫出可用的SRS； 2） 開發者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個令人滿意的系統需求。 4.5 SRS的改進 軟件產品的開發過程中，在項目的開始階段不可能詳細說明某些細節，在開發過程中可能發現SRS的缺陷、缺點和錯誤之類的問題，所以可能要對SRS進行改進。 在SRS的改進中，應注意如下事項： 1） 盡管可以預見校正版本的開發以后不可避免，而對需求還必須盡可能完全、清楚地描述。 2） 一旦最初識別出項目的變化，應引入一個正式的改變規程來標識、控制、追蹤和報告項目的改變。批準了的需求改變，用如下的方法編入SRS之中： 提供各種改變后的正確的、完全的審查記錄； 允許對SRS當前的和被替代部分的審查。 4.6 SRS的編制工具 編制SRS最顯而易見的方法是用自然語言來描述。盡管自然語言是豐富多彩的，但不易精確，用形式化的方法較好。 4.6.1 形式化說明方法 在SRS中是否使用形式化方法要依據下列因素： 1) 程序規模和復雜性； 2) 客戶合同中是否要求使用； 3) SRS是否是一個合同工具或僅僅是一個內部文件； 4) SRS文件是否成為設計文件的根據； 5) 具有支持這種方法的計算機設備。 4.6.2 生產工具 軟件產品生產中有多種生產工具。比如，計算機的字處理器就是非常有用的生產輔助工具。一個SRS通常有若干作者。可能經歷若干版本，并且要進行多次重新組織內容。故生產工具是必要的。 4.6.3 表達工具 在SRS中有許多詞匯，特別是許多名詞和動詞，專門涉及到系統的實體和許多活動，所以表達SRS需要若干工具。比如： 1) 可以驗證實體或活動，無論在SRS中什么地方都是同一名字。2) 可以標識一個特殊的實體或動作在規格說明中的描述位置。 此外，可以使用若干種形式化方法，以便允許自動處理SRS內容，只要作某些限制就可以做到：用一些表格或圖示法來顯示需求。 用詳細分層體系自動檢查SRS的需求，這里每一個分層自身是完全的，但是也可以擴展為下一層，或是上一層的一個組成成分。 自動檢查SRS具有在4.3條描述的部分或全部特點。5 軟件需求 SRS中每一個軟件需求是要求開發軟件產品的某些基本功能和性能的一個陳述。 5.1 表達軟件需求的方法 軟件需求可以用若干種方法來表達： 1）通過輸入、輸出說明； 2）使用代表性的例子； 3）用規范化的模型。 5.1.1 輸入、輸出說明 用輸入輸出序列來描述一個軟件產品所要求的特性是很有效的。 途徑 根據被描述的軟件的性質，至少有三種不同的途徑： 1） 有些軟件產品（如報表系統）要求著重說明輸出。一般情況下，致力于輸出的系統主要是在數據文卷上操作。用戶的輸入通常是致力于提供控制信息和啟動數據文卷的處理； 2） 有些軟件產品需要著重說明輸入、輸出特性。關注輸入、輸出的系統主要是在當前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數據轉換例行程序或一個數學函數包）； 3） 還有一些系統（如過程控制系統）要求記憶它們的狀態。可以根據本次輸入和上一次輸入進行應答。也就是說，它的行為如同一個有限狀態機。在此種情況下，既要關注輸入/輸出對，又要關注這些輸入/輸出對的次序。 困難 多數軟件產品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列完整地說明產品的特性，就要求SRS包括一個無限長的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。 5.1.2 典型例子 一種選擇是用典型例子來說明要求的特性。例如，假設一個系統中當接收“0”時用“1”來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統的特性。下面是一組四種對話的典型的例子，用它描述系統特性。 0101 010101010101 01 010101 這些對話僅提供了要求的輸入和輸出之間的關系，但是不能完全描述系統的特性。 5.1.3 模型 另一種表達需求的方法是模型的方式，這是表達復雜需求的精確和有效方法。 至少可以提出三種可供使用的通用模型：數學型、功能型、計時型。應注意區別各種模型的應用場合，參考。 數學模型 數學模型是使用數學關系描述軟件特性的模型。數學模型對某些特殊應用領域是特別有用的。例如，導航、線性規劃、計量經濟、信號處理和氣象分析等。 用數學模型能夠對5.1.2中所討論的典型例子描述如下： （01）*。 這里，“*”號表示括號內的字符串可以重復一次或多次。 功能模型 功能模型是提供從略語以輸出映象的模型。象有限狀態機或Petri網，這些功能模型可以有助于標識和定義軟件的各種特點，或者可以表示系統所要進行的操作。 對前面用數學模型描述的例子。可用圖1所示的有限狀態機形式的功能模型來描述。圖中進入的箭頭表示啟動狀態。雙線的方框表示接收狀態。在各線記號x/y的含義是：x代表接受的輸入，而y是產生的輸出。 計時模型 計時模型是一種增加了時間限制的模型。這種模型對于表達軟件特性的形式和細節特別有用。尤其是實時系統或考慮人為因素的系統。 計時模型可以把下列限制加到圖1的模型中去： 1）激活因素0將在進入S1狀態30S之內出現； 2）響應1將在進入S2狀態2S之內出現。 其他模型 除了上面提及的模型外。對一些特殊的應用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統可以使用表格。要注意的是，對SRS使用形式需求語言，通常含有使用特殊模型的意思。 警告 無論使用哪一類型的模型，都要在SRS中或在SRS涉及到的一個文件中對它嚴格定義。這個定義應該規定： 1）模型中的參數所要求的范圍； 2）使用時的限定值； 3）結果的精確度； 4）負載的能力； 5）要求的執行時間； 6）缺省或失敗時的響應。 必須注意，在需求的定義域內要保持一個模型定義。每當一個SRS使用一個模型時： 1）它意味著此模型提供一個十分有效和精確的方法說明需求； 2）并不意味著軟件產品的實現必須基于這個模型。 一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現可能并不是最適宜的。 5.2 軟件需求的注釋 有關軟件產品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是對于生命攸關的應用。而另一些可能并不那么重要。 SRS中每一個需求必須進行注釋，以便區別其重要的程度。 有這種方法注釋需求，可以： 1） 幫助客戶對每個需求給予更周密的考慮，通常可以在需求中澄清隱藏的假設； 2） 幫助開發者做出正確的設計決定，并對軟件產品不同部分作出相應的努力。 5.2.1 穩定性 注釋需求的一種方法是使用穩定性量綱。當一個需求在軟件預期的生存期間內描述不改變的話，可以認為該需求是穩定的，否則可以認為是易變的。 5.2.2 必要性等級 注釋的另一種方法是把需求分成必須保證級、期望級和任選級。 5） 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受； 6） 期望是指這些需求將提高軟件產品的功能，但如果缺省的話也是可接受； 7） 任選是給開發者一個機會，可以提供某些超出SRS規定的目標。 5.2.3 注意事項 在注釋需求之前，必須徹底理解這種注釋的實質性含義。 5.3 在表達需求時遇到的共同弊病 SRS的基本點是它必須說明由軟件獲得的結果，而不是獲得這些結果的手段。編寫需求的人必須描述的基本問題是： 1） 功能所設計的軟件要做什么；2） 性能是指軟件功能在執行過程中的速度、可使用性、響應時間、各種軟件功能的恢復時間、吞吐能力、精度、頻率等等； 3） 強加于實現的設計限制在效果、實現的語言、數據庫完整性、資源限制、操作環境等等方面所要求的標準； 4） 屬性可移植性、正確性、可維護性及安全性等方面的考慮因素； 5） 外部接口與人、硬件、其他軟件和其他硬件的相互關系。 編寫需求的人應當避免把設計或項目需求寫入SRS之中，應當對說明需求設計約束與規劃設計兩者有清晰的區別。 5.3.1 在SRS中嵌入了設計 在SRS中嵌入設計說明，會過多地約束軟件設計，并且人為地把具有潛在危險的需求放入SRS中。 1） SRS必須描述在干什么數據上、為誰完成什么功能、在什么地方、產生什么結果。SRS應把注意力集中在要完成的服務目標上。通常不指定如下的設計項目： 把軟件劃分成若干模塊； 給每一個模塊分配功能； 描述模塊間的信息流程或者控制流程； 選擇數據結構。 2） 把設計完全同SRS隔離開來始終是不現實的。安全和保密方面的周密考慮可能增加一些直接反映設計約束的需求。例如： 在一些分散的模塊中保持某些功能； 允許在程序的某些區域之間進行有限的通訊； 計算臨界值的檢查和。 3） 通常應考慮到，若要為軟件選擇高層次的設計，就可能需要大量的資源（可能占整個產品開發成本的10%-20%以上）。有兩種選擇： 不顧本指南的警告，在SRS中描述了設計。這意味著，或者將一個潛在不適當的設計作為一個需求進行描述（因為，若要得到好的設計，所花費的時間是不夠的），或者在需求階段花費了過多的時間（因為在SRS完成之前整個設計分析都要完成）； 采用本指南中5.1.3條中的建議，用模型設計描述需求，這種模型設計只用于輔助描述需求，而不使之成為實際的設計。 5.3.2 在SRS中嵌入了一些項目要求 SRS應當是描寫一個軟件產品，而不是描述生產軟件產品的過程。 項目要求表達客戶和開發者之間對于軟件生產方面合同性事宜的理解（因此不應當包括在SRS中）例如： 1） 成本； 2） 交貨進度； 3） 報表處理； 4） 軟件開發方法； 5） 質量保證； 6） 確認和驗證的標準； 7） 驗收過程。 項目需求在另外文件中描述。在SRS中提供的只是關于軟件產品本身的需求。6 SRS大綱本章著重討論SRS的每一個基本部分，可以作為一個SRS的大綱。表1給出該大綱目錄，表2至表5給出大綱中第3章的具體需求內容。各開發者和客戶應當根據所描述的實際情況，按本指南有關規定編寫自己的SRS。 1 前言 1.1 目的 1.2 范圍 1.3 定義、縮寫詞、略語 1.4 參考資料 2 項目概述 2.1 產品描述 2.2 產品功能 2.3 用戶特點 2.4 一般約束 2.5 假設和依據 3 具體需求 （參閱本指南6.3.2 條中具體需求的組織形式） 附錄 索引 6.1 前言（SRS第1章） 本章提供整個SRS綜述。 6.1.1 目的（SRS的1.1條） 在這一條包括下列內容： 1）描述實際SRS的目的； 2）說明SRS所預期的讀者。 6.1.2 范圍（SRS的1.2條） 1） 通常應考慮到，若要為軟件選擇高層次的設計，就可能需要大量的資源（可能占整個產品開發成本的10%-20%以上）。有兩種選擇： 2） 用一個名字標識被生產的軟件產品。比如：數據庫系統，報表生成程序等等； 3） 說明軟件產品將干什么，如果需要的話，還要說明軟件產品不干什么； 4） 描述所說明的軟件的應用。應當： 盡可能精確地描述所有相關的利閃、目的、以及最終目標。 如果有一個較高層次的說明存在，則應該使其和高層次說明中的類似的陳述相一致（例如，系統的需求規格說明）。 6.1.3 定義、縮寫詞、略語（SRS的1.3條） 本條中必須提供全部需求的術語、縮寫詞及略語的定義，以便對SRS進行適當的解釋。這些信息可以由SRS的附錄提供。也可以參考其他的文件。 6.1.4 參考資料（SRS的1.4條） 本條應包括： 1） 在SRS中各處參照的文件的全部清單，如經核準的計劃任務書，上級機關批文、合同等； 2） 列出其他參考資料，如屬本項目的其他已發表的文件和主要文獻等。每一個文件、文獻要有標題，索引號或文件號，發布或發表日期以及出版單位； 3） 詳細說明可以得到該參考文件的來源。這個信息可以通過引用附錄或其他文件提供。 6.2 項目概述（SRS第2章） 本章應描述影響產品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。6.2.1 產品描述（SRS的2.1條） 這一條是把一個產品用其他有關的產品或項目來描述。 1） 如果這個產品是獨立的，而且全部內容自含，應在此說明； 2） 如果SRS定義的產品是一個較大的系統或項目中的一個組成部分，那么本條應包括如下內容： 要概述這個較大的系統或項目的每個組成部分的功能，并說明其接口； 指出該軟件產品主要的外部接口。在這里，不要求對接口詳細地描述，詳細描述放在SRS其他章條中； 描述所使用的計算機硬件、外圍設備。這里僅僅是一個綜述性描述。 在本條的描述中，用一個方框圖來表達一個較大的系統或項目的主要組成部分、相互聯系和外部接口是非常