需求分析類文檔模板
編者說明：
許多有經驗的開發團隊在開始需求調查的時候，總會將“軟件客戶需求權利書”和“軟件客戶需求義務書”提交給客戶，讓客戶明確其權利與義務，將會對需求調研、分析的工作帶來意想不到的效果，你可以一試。
軟件客戶需求權利書
1.要求分析人員使用符合客戶語言習慣的表達；
2.要求分析人員瞭解客戶系統的業務及目標；
3.要求分析人員組織需求獲取期間所介紹的信息，並編寫軟件需求規格說明。
4.要求開發人員對需求過程中所產生的工作結果進行解釋說明；
5.要求開發人員在整個交流過程中保持和維護一種合作的職業態度；
6.要求開發人員對產品的實現及需求都要提供建議，拿出主意。
7.描述產品使其具有易用、好用的特性；
8.可以調整需求，允許重用已有的軟件組件；
9.當需要對需求進行變更時，對成本、影響、得失有個真實可信的評估；
10.獲得滿足客戶功能和質量要求的系統，並且這些要求是開發人員同意的。
軟件客戶需求義務書
1.給分析人員講解業務及說明業務方面的術語等專業問題；
2.抽出時間清楚地說明需求並不斷完善；
3.當說明系統需求時，力求準確詳細；
4.需要時要及時對需求做出決策；
5.要尊重開發人員的成本估算和對需求的可行性分析；
6.對單項需求、系統特性或使用實例劃分優先級；
7.評審需求文檔和原型；
8.一旦知道要對項目需求進行變更，要馬上與開發人員聯繫；
9.在要求需求變更時，應遵造開發組織確定的工作過程來處理；
10.尊重需求工程中開發人員採用的流程（過程）。
軟件項目視圖和範圍
編者說明：
項目所涉及的內容與所解決的問題都是有限的，而且項目應該是十分有目的性的，是爲了實現某個可度量的目標而做的。因此，在需求分析的前期應該將“項目的目標與範圍”這一項目的本質文檔化，讓每一個項目成員對其達成共識。該文檔是十分重要，但卻又是十分容易被忽視的。該文檔模板比較適用於定製開發項目。
1.業務需求
[業務需求說明了提供給客戶和產品開發商的新系統的最初利益。不同產品可能會有不同的側重點。本部分描述了你爲什麼要從事此項項目的開發，以及它將給開發者和購賣者帶來的利益。]
1.1 背景
[在這一部分，總結新產品的理論基礎，並提供關於產品開發的歷史背景或形勢的一般性描述。]
1.2 業務機遇
[描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市場和信息系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案，並指出所建議的產品爲什麼具有吸引力和它們所能帶來的競爭優勢。認識到目前只能使用該產品才能解決的一些問題，並描述產品是怎樣順應市場趨勢和戰略目標的。]
1.3 業務目標
[用一個定量和可測量的合理方法總結產品總結產品所帶來的重要商業利潤。關於給客戶帶來的價值在後面闡述，這裏僅把重點放在給業務的價值上。這些目標與收入預算或節省開支有關，並影響到投資分析和最終產品的交付日期。]
1.4 客戶或市場需求
[描述一些典型客戶的需求，包括不滿足現在市場上的產品或信息系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能運行的軟、硬件平臺。定義了較高層次的關鍵接口或性能要求，但避免設計或實現細節。把這些要求寫到列表中，可以反過來跟蹤調查特殊用戶和功能需求。]
1.5 提供給客戶的價值
[確定產品給客戶帶來的價值，並指明產品怎樣滿足客戶的需要。可以用下列言辭表達產品帶給客戶的價值：
Ø 提高生產效率，減少返工；
Ø 節省開支；
Ø 業務過程的流水線化；
Ø 先前人工勞動的自動化；
Ø 符合相關標準和規則；
Ø 與目前的應用產品相比較，提高了可用性或減少了失效程度。]
1.6 業務風險
[總結開發（或不開發）該產品有關的主要業務風險，例如市場競爭、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能採取的減輕風險的措施。]
2.項目視圖的解決方案
[文檔中的這一部分爲系統建立了一個長遠的項目視圖，它將指明業務目標。這一項目視圖爲在軟件開發生存期中作出決策提供了相關環境背景。這部分不包括詳細的功能需求和項目計劃信息。]
2.1 項目視圖陳述
[編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場企業框架。組織的戰略方向和資源侷限性爲基礎。]
[如："化學制品跟蹤系統"可使科學家查詢到化學制品倉庫或供應商將提供的化學制品容器。系統可隨時瞭解公司每一個化學制品容器所處的位置，容器中所剩餘的藥品劑量，任何時候每個容器所處的位置和用法的歷史記錄。通過充分利用公司內部的可用化學制品，廢棄極少量已使用或過期失效的化學制品，使用標準的化學制品的購買過程等將在化學制品上節省25%開支。"化學制品跟蹤系統"還能產生符合政府部門規定所要求的全部報表，包括化學制品的使用、存儲和廢棄等報表。]
2.2 主要特徵
[包括新產品將提供的主要特性和用戶性能的列表。強調的是區別於以往產品和競爭產品的特性。可以從用戶需求和功能需求中得到這些特性。]
2.3 假設和依賴環境
[在構思項目和編寫項目視圖和範圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。如果你把它們都記錄下來，並加以評論，就能對項目內部隱含的基本假設達成共識。比如，"化學制品跟蹤系統"的開發者假設：該系統可以替代現有的倉庫存貨系統，並能與有關採購部門的應用相連接。把這些都記錄下來以防止將來可能的混淆和衝突。還有，記錄項目所依賴的主要環境，比如：所使用的特殊的技術、第三方供應商、開發夥伴及其它業務關係。]
3.範圍和侷限性
[項目範圍定義了所提出的解決方案和概念和適用領域，而侷限性則指出產品所不包括的某些性能。如果一般客戶所提出的需求超出項目的範圍時就應當拒絕它，除非這些需求是很有益的。記錄這些需求以及拒絕它們的原因，以待查。]
3.1 首次發行的範圍
[總結首次發行的產品所具有的性能。描述了產品的質量特性，這些特性使產品可以爲不同的客戶羣提供預期的成果。應當避免將想到的每一個特性都包括到1.0版本產品中去。開發者應把重點放在能提供最大價值、花花費最合理的開發費用及普及率最高的產品上。]
3.2 隨後發行的範圍
[如果你想象一個週期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，並期待隨後版本發行的日期。]
3.3 侷限性和專用性
[明確定義包括和不包括的特性和功能的界線是處理範圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能。]
4.業務環境
[這一部分總結了一些項目的業務問題。]
4.1 客戶概貌
[客戶概述明確了這一產品的不同類型客戶的一些本質特點，以及目標市場部門和在這些部門中的不同客戶的特徵。對於每一種客戶類型，概述要包括：
Ø 各種客戶類型將從產品中獲得的主要益處；
Ø 它們對產品所持的態度；
Ø 感興趣的關鍵產品的特性；
Ø 哪一類型客戶能成功使用；
Ø 必須適應任何客戶的限制。]
4.2 項目的優先級
[一旦明確建立項目的優先級，風險承擔者和項目的參與者就能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟件項目的五個方面：性能、質量、計劃、成本和人員。在所給的項目中，其每一方面應與下面三個因素之一相適應。
Ø 一個驅動----一個最高級別的目標；
Ø 一個約束----項目管理者必須操縱一個對象的限制因素；
Ø 一個自由度----項目管理能權衡其它方面，進而在約束限制的範圍內完成 目標的一個因素。
未必所有的因素都能成爲驅動，或所有的因素都能成爲約束因素。在項目開始時記錄和分析哪一個因素適用於哪一類型，將有助於使每一個人的努力和期望與普遍認可的優先級相一致。]
5.產品成功的因素
[明確產品的成功是如何定義和測量的，並指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的範圍內的事務，還要包括我部素。如果可能，可建立測量的標準，用於評價是否達到業務目標，如：市場股票、銷售量及收入、客戶滿意度、交易處理量和準確度。]
編者說明：
這個文檔模板與“軟件項目視圖與範圍”文檔的功能十分接近，只不過該文檔更適合於產品型項目。其注重對項目的用戶、市場進行分析，緊抓項目相關人員（也叫做風險承擔者）的需求的本質。
1.文檔簡介
[軟件需求規格說明書的整個內容還是鎖定於整個系統的操作、使用層面之上的功能性需求，只是解決了How的問題，而並未回答Why的問題。這使得系統在開發過程中，開發團隊經常陷入知其然，而不知其所以然的困境，造成了不必要的誤解與錯誤。因此，需要一個側重於對項目的風險承擔者、目標用戶需要的文檔，不僅要了解他們需要的功能，還要找到他們提出這些需求的原因。這就是“項目構想”文檔所要描述的重要內容。]
[本節的內容主要是提供項目構想文檔的目的、範圍、定義、參考資料以及對其的摘要性概述。]
1.1 目的
[說明該文檔的寫作目的。]
1.2 範圍
[範圍主要用來說明該文檔描述的項目內容，以及與其相關的其它東西。]
1.3 定義、首字母縮寫詞和縮略語
[與其它文檔一樣，該文檔也需要將本文檔中所涉及的所有術語、縮略語進行詳細的定義。還有一種可簡明的做法，就是維護在一個項目詞彙表中，這樣就可以避免在每個文檔中都重複很多內容。]
1.4參考資料
[在這一小節中，應完整地列出該文檔引用的所有文檔。對於每個引用的文檔都應該給出標題、標識號、日期以及來源，爲閱讀者查找這些文檔提供足夠詳細的信息。]
1.5 概述
[在本小節中，主要是說明項目構想各個部分所包含的主要內容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。]
2.定位
2.1 商業機會
[如果該項目是一個產品型項目，那麼應該在本小節中描述該產品所針對的商業機會。如果是定製開發項目，那麼可以省去本小節。]
2.2 問題說明
[使用表格的形式，將該項目將要解決的問題進行概要性地描述：]
|
存在的問題 |
[問題的簡要說明] |
|
受影響的人羣 |
[該問題對哪些人羣帶來了影響] |
|
導致的後果 |
[該問題帶來的不利因素] |
|
希望的解決方案 |
[列出解決方案所能夠解決的問題，以及其相應的優點。] |
2.3 產品定位說明
[如果是產品型項目，則該小節將以表格的形式對產品的定位進行明確，如果是定製開發項目，可以省略本小節。]
|
目標市場 |
[描述產品目標客戶羣體] |
|
目標客戶需求 |
[說明客戶的需要或者潛在的機會] |
|
產品類別 |
[說明該產品屬於什麼領域] |
|
主要優點 |
[描述讓目標客戶產生興趣和購買慾的理由] |
|
主要競爭對手 |
[列出與該產品有競爭的其它廠商的產品] |
|
主要優勢 |
[針對競爭產品的分析] |
[一個具有清晰定位的產品，在開發過程中，團隊將更好地理解，更容易開發出滿足目標市場的產品，因而該部分內容是十分重要的。]
3.項目相關人員和用戶說明
[瞭解用戶、瞭解所有與該項目相關的人員，是有效地滿足他們對系統、產品需求的基礎。你應該在本小節中將所有的項目相關人員以及用戶收羅在一起，並對他們進行簡要的描述，對他們的需求、習慣、角度進行說明。這些內容將有助於開發團隊更好的理解用戶的需求本質。]
3.1 產品用戶分析
[如果是產品型項目，那麼你應該本節中對目標客戶進行分析。可以在市場調查的基礎上，對其市場的規模和增長率進行研究，從而估計其潛在的用戶數量。另外，還應結合目標市場的實際情況，分析你的組織是否在該市場上有拓展的優勢，如何獲得這些優勢。如果是定製開發項目，可以省略這一小節。]
3.2 項目相關人員一覽表
[使用下面的表格，對項目相關人員進行分析。]
|
人員類別 |
代表 |
作用 |
|
[指明項目相關人員的類別] |
[列舉該類人員的代表] |
[說明其對產品、項目開發的影響] |
3.3 用戶一覽表
[使用下面的表格，對項目、產品的用戶進行分析。]
|
用戶類型 |
說明 |
代表 |
|
[指明用戶類別] |
[簡要說明他們在系統中代表的對象和充當的作用] |
[列舉出代表] |
3.4 用戶環境
[瞭解用戶在使用環境下使用系統或產品，是十分有意義的事，也是實現產品更好地滿足需求，提供更加方便的使用界面的基礎。例如：該任務由多少人來完成？是否總在變化？一個任務週期需要多長時間？執行每項活動要用多長時間？是否總在變化？是否有特殊的環境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統平臺？以後會使用哪些平臺？還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？他們的計算機硬件系統的環境情況如何？他們都是在什麼樣的工作環境中使用系統的？]
3.5 項目相關人員的簡要說明
[以下表的形式，將各類項目相關人員的基本情況進行說明，以幫助開發團隊更好地瞭解他們的情況。爲每一類人員生成一張表格。]
|
代表 |
[列出該類項目相關人員的代表。] |
|
說明 |
[對該類人員進行簡要說明。] |
|
專業技能 |
[描述本類人員的技能特長、技術背景以及電腦系統操作的熟練程度（可以分成業務用戶、專家用戶、熟練用戶、初級用戶等）] |
|
職責 |
[描述本類人員對系統開發所承擔的職責，以及應享有的利益。] |
|
驗收標準 |
[描述驗證系統是否滿足其職責的標準。] |
|
參與方式 |
[該類人員是否參與系統開發，如果參與將以什麼形式參加。] |
|
項目成果 |
[說明該類項目相關人員是否參與項目成果的開發，是否有與其相關的項目成果。] |
|
意見/問題 |
[列出與該類項目成員相關的問題與建議。] |
3.6 用戶簡要說明
[以下表的形式，將與系統相關的各種用戶的信息整理出來，以方便開發團隊針對性的工作。要注意的是，用戶會有不同的類型，有些用戶需要的是靈活性、方便快速操作的高級功能，而有些用戶則側重與用戶界面的友好性。這些與該用戶的基本情況直接相關，瞭解用戶才能夠真正地開發出符合用戶習慣和水平的系統。爲每類用戶生成一張表。]
|
代表 |
[列出該類用戶的代表。] |
|
說明 |
[對該類用戶進行簡要說明。] |
|
專業技能 |
[描述該用戶的技能特長、技術背景和對計算機系統操作的熟練程度。] |
|
職責 |
[列出該用戶對所開發的系統負有的關鍵職責，如記錄詳細信息、撰寫報告、協調工作等。] |
|
驗收標準 |
[描述驗證系統符合用戶需求的標準。] |
|
參與方式 |
[說明該類用戶是否參與開發，如何參與。] |
|
項目成果 |
[說明是否有依賴於該類用戶的項目成果。] |
|
意見/問題 |
[列出一些該類用戶對系統提出的一個意見與建議，並且收集其認爲該系統將遇到的問題。] |
3.7 關鍵的項目相關人員/用戶需要
[列出項目相關人員提出的針對對於該解決方案的關鍵問題。對於列出的每個問題，需澄清：爲什麼會出現這一問題？目前的解決方案是什麼？他們需要什麼要的解決方案？或者對新的解決方案有什麼樣的預期？]
[還有一個很關鍵的內容就是，每個需求的優先級，這將對制定迭代計劃時提供有效的基礎，而優先級的確定，應該採用分級、累積投票等方法從用戶、項目相關人員那裏獲得。應充分考慮項目客戶方的要求。如果是產品型項目，則應該從產品經理、市場調查資料裏獲得。]
[經過整理後，將內容填入下表：]
|
需求 |
優先級 |
要點 |
目前解決方案 |
提議的解決方案 |
|
|
|
|
|
|
3.8 備選方案和競爭
[如果是產品型項目，應在此小節列舉出客戶除了購買該產品這外的選擇，其中包括購買競爭對手的產品、自行設計解決方案甚至是維持現狀。對所有潛在的競爭產品做一個列表，並根據客戶的實際情況來確認主要優缺點。]
[而如果是定製開發型項目，則應該瞭解競爭對手提供的解決方案，比在此進行相應的比較。]
4. 產品概述
[本節主要從產品級、系統級的視角，高度概括產品的功能、與其它應用程序的交互以及所需的系統配置等。]
4.1 產品總體效果
[本小節主要將產品話在用戶環境、使用環境的角度來介紹。如果是自成一體，則說明用戶將如何使用；如果是與其它的應用系統進行交互的，則在此小節說明如何與這些系統進行交互？它們之間採用什麼樣的通訊方式和接口。在這裏最適合的方式是使用UML的部署圖，讓用戶對系統最終的運行環境有一個較宏觀的瞭解。]
4.2 主要功能
[本小節不是對系統或產品所有功能的羅列，而是將能夠體現系統、產品主要優點和特性功能在此列出。在內容組織方面，應該直接與“客戶能夠通過產品獲得的好處”相聯繫，使讀者能夠將系統的功能與客戶的價值直接聯繫起來，在開發時能夠從本質出發，構建出更加符合客戶需要的系統。]
4.3 假設與依賴關係
[在此小節中，列出所有會影響該文檔中所述特性的各種因素。也就是列舉出所有可能讓該文檔發生變化的假設條件。]
4.4 成本與定價
[該小節主要是對該項目的成本進行覈算，對給出相應的定價策略。對於定製開發的項目，其成本主要包括開發的人工成本、公司管理成本、項目額外開支、相關軟硬件工具投資等方面。而對於產品型項目而言，還包括分銷成本、用戶手冊製作、CD製作等方面的成本。這裏的成本覈算爲最終的合同價格以及產品的銷售價值將提供一個基礎的依據，因此也是十分重要的。]
4.5 許可與安裝
[該小節中主要列出影響開發工作的一些許可和安裝相關的問題。例如是否需要加密，如果驗證用戶合法性，安裝界面的要求是什麼。這方面對於產品型項目而言顯得更加重要，也是對軟件知識產權保護的一個重要措施。]
5.產品特性
[在本節中將列出系統或產品的特性，特性是指實現用戶價值的系統功能。每一個特性都是一個所需的服務，通常是通過一系列操作實現預期結果。在FDD中，也就是特徵。通常一個特徵會由一個或多個用例來實現，通常系統的特性應該進行整合打包，以25-99項爲合適。]
[本小節的描述應該能夠讓用戶、操作人員、外部系統直接從系統的外邊感受到每項特性，這些特性應該包括功能性說明以及一些可用性問題。但是要注意，在這裏不要過早地引入設計的內容，這裏說明的是What，而不是How。]
[另外，因在所有特性的描述中，確定其優先級。]
6.約束
[記錄用戶、項目相關人員提供出的一些約束條件，以及與其它系統之間的依賴關係，這是制訂解決方案時必須考慮到的問題。]
7.質量要求
[對於整個系統的質量要求，如可靠性、可用性、性能、容錯等質量要求，在這此節中詳細地定義與描述。]
8.其他產品需求
[一些要求符合的標準、硬件基礎要求、軟件基礎要求、環境要求等。]
8.1 適用的標準
[列出產品必須符合的所有標準。其中可能包括法律和法規（FDA、UCC）標準、通訊標準（TCP/IP、ISDN）、平臺一致性標準（Windows、Unix 等）以及質量和安全標準（UL、ISO、CMM）。]
8.2 系統需求
[確定支持該應用程序所必需的任何系統需求。其中可能包括操作系統、網絡環境、系統配置、內存大小、硬盤大小、外圍設備和配套軟件。]
8.3 性能需求
[本節用於詳細說明性能需求。性能問題可能包括在各種負載條件下的用戶負載因素、帶寬或通信容量、吞吐量、精確度以及可靠性或響應時間。]
8.4 環境需求
[對於基於硬件的系統，環境因素可以包括溫度、振盪、溼度、輻射等。對於軟件應用系統，環境因素可以包括使用條件、用戶環境、資源可用性、維護問題、錯誤處理和恢復。]
9. 文檔需求
[列舉用戶所需的與該系統或產品相關的文檔。]
9.1 用戶手冊
[用戶手冊的製作說明，例如手冊篇幅、詳細程序、是否需要圖、主要關心的點、要不要建立索引、詞彙表，採用教程式還是速查手冊式。]
9.2 聯機幫助
[聯機幫助是一種用戶界面友好的服務，它可以爲用戶提供實時的協助。]
9.3 安裝指南、配置文件、自述文件
9.4 標籤與包裝
10. 功能需求屬性
[爲了在項目開發過程中，對每個功能需求進行跟蹤管理，在此對所有的功能進行一個總體的描述。]
[可以生成一張功能需求屬性表，每條記錄代表一條功能，每個功能包括以下字段：]
1）狀態：標識該功能的最新狀態。
Ø 已提出：已經提出來，但是還沒有經過正式的複審而確定的需求；
Ø 已批准：已經經過正式的渠道複審而確定，準備實施的需求；
Ø 已加入：已經加入到需求管理基線中的特性。
2）利益：根據客戶的態度，確定每個需求的重要程序，也是確定系統開發優先級的基礎數據。
Ø 關鍵：必不可少的特性，缺少這些特性的系統將無法滿足客戶的要求，這些特性通常會在最早安排到迭代開發中去；
Ø 重要：對於系統來說，該特性是十分重要的，很難以通過其它方式來彌補，如果這些特性沒有第一時間實現，將會使得客戶滿意度大大降低。因此是第二優先實現的特性；
Ø 有用：這些是一些有效，但使用頻率較低的功能特性。如果沒有在第一時間實現，也不會對客戶滿意度造成很大的影響；
Ø 無用：對於系統來說是“鍍金”需求，有也可以，沒有也行的。
3）工作量：根據特性所需的時間和資源進行估算，給出團隊開發的工作時間或個人開發的工作時間。也可以估算出代碼行數或功能點數，這也將爲迭代開發計劃的制定提供良好的基礎。
4）風險：列出該特性開發的最大風險，可以對這些風險進行級別細分，對於影響較大的風險還應該制定相應的應對措施。
5）穩定性：對該特性需求是否容易變化進行一個預估，以幫助設計人員在設計解決方案時更加有效地避免變化對體系結構的影響，從而節省時間。
6）基線：確定其是否已經納入基線；
7）職責分配：列出負責實現該特性的團隊；
8）原因：列出提出該特性的原因，也可以將與客戶交流的記錄等資料放在這裏，以幫助開發團隊更好的理解客戶的本意。
需求規格說明書(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（[url]www.atlsysguild.com[/url]）公司所提供的Volere需求過程與軟件需求規格說明書模板則充分利用了現代軟件工程思想與技術，是一個十分實用、完善的SRS模板。其所提供的Volere需求記錄卡也十分實用，強烈推薦。
注：從Atlantic System Guild公司網站[url]www.atlsysguild.com[/url]上獲得，並稍做修改
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 Guild |
|
Volere
|
注：顧客滿意度是指完成該項功能顧客滿意的程度，而顧客不滿意度則是指未實現該功能顧客不滿意的程度。
編者說明：
如果在需求分析時採用了用例（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者是無歧義的。
2） 要求最終產品的每一個特性用某一術語描述；
3） 若某一術語在某一特殊的行文中使用時具有多種歧義，那麼對該術語的每種含義作出解釋並指出其適用場合。
需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。
4.3.2 完整性
如果一個SRS能滿足下列要求，則該SRS就是完整的：
1） 包括全部有意義的要求，無論是關係到功能的、性能的、設計約束的，還是關係到屬性或外部接口方面的需求；
2） 對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響應做出規定；
3） 要符合SRS要求。如果個別章節不適用，則在SRS中要保留章節號；
4） 填寫SRS中的全部插圖、表、圖示標記和參照，並且定義全部術語和度量單位。
4.3.2.1 關於使用“待定”一詞的規定
任何一個使用“待定”的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 輸入、輸出說明
用輸入輸出序列來描述一個軟件產品所要求的特性是很有效的。
5.1.1.1 途徑
根據被描述的軟件的性質，至少有三種不同的途徑：
1） 有些軟件產品（如報表系統）要求着重說明輸出。一般情況下，致力於輸出的系統主要是在數據文捲上操作。用戶的輸入通常是致力於提供控制信息和啓動數據文卷的處理；
2） 有些軟件產品需要着重說明輸入、輸出特性。關注輸入、輸出的系統主要是在當前的輸入上操作，要求生成與輸入相匹配的輸出（類似於數據轉換例行程序或一個數學函數包）；
3） 還有一些系統（如過程控制系統）要求記憶它們的狀態。可以根據本次輸入和上一次輸入進行應答。也就是說，它的行爲如同一個有限狀態機。在此種情況下，既要關注輸入/輸出對，又要關注這些輸入/輸出對的次序。
5.1.1.2 困難
多數軟件產品可能接收無限的序列作爲輸入，於是，爲了通過輸入輸出序列完整地說明產品的特性，就要求SRS包括一個無限長的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。
5.1.2 典型例子
一種選擇是用典型例子來說明要求的特性。例如，假設一個系統中當接收“0”時用“1”來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統的特性。下面是一組四種對話的典型的例子，用它描述系統特性。
0101
010101010101
01
010101
這些對話僅提供了要求的輸入和輸出之間的關係，但是不能完全描述系統的特性。
5.1.3 模型
另一種表達需求的方法是模型的方式，這是表達複雜需求的精確和有效方法。 至少可以提出三種可供使用的通用模型：數學型、功能型、計時型。應注意區別各種模型的應用場合，參考5.1.3.5。
5.1.3.1 數學模型
數學模型是使用數學關係描述軟件特性的模型。數學模型對某些特殊應用領域是特別有用的。例如，導航、線性規劃、計量經濟、信號處理和氣象分析等。
用數學模型能夠對5.1.2中所討論的典型例子描述如下：
（01）*。
這裏，“*”號表示括號內的字符串可以重複一次或多次。
5.1.3.2 功能模型
功能模型是提供從略語以輸出映象的模型。象有限狀態機或Petri網，這些功能模型可以有助於標識和定義軟件的各種特點，或者可以表示系統所要進行的操作。
對前面用數學模型描述的例子。可用圖1所示的有限狀態機形式的功能模型來描述。圖中進入的箭頭表示啓動狀態。雙線的方框表示接收狀態。在各線記號x/y的含義是：x代表接受的輸入，而y是產生的輸出。
5.1.3.3 計時模型
計時模型是一種增加了時間限制的模型。這種模型對於表達軟件特性的形式和細節特別有用。尤其是實時系統或考慮人爲因素的系統。
計時模型可以把下列限制加到圖1的模型中去：
1）激活因素0將在進入S1狀態30S之內出現；
2）響應1將在進入S2狀態2S之內出現。
5.1.3.4 其他模型
除了上面提及的模型外。對一些特殊的應用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統可以使用表格。要注意的是，對SRS使用形式需求語言，通常含有使用特殊模型的意思。
5.1.3.5 警告
無論使用哪一類型的模型，都要在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其他章條中；
Ø 描述所使用的計算機硬件、外圍設備。這裏僅僅是一個綜述性描述。
在本條的描述中，用一個方框圖來表達一個較大的系統或項目的主要組成部分、相互聯繫和外部接口是非常有幫助的。
本條既不用來強迫進行設計方案的描述，也不是描述在解決問題時的設計約束。本條應對在以後具體需求一章中說明的設計約束提供理由。
6.2.2 產品功能（SRS的2.2條）
本條是爲將要完成的軟件功能提供一個摘要。例如，對於一個記帳程序來說，SRS可以用這部分來描述：客戶帳目維護、客戶財務報表和發票製作，而不必把功能所要求的大量的細節描寫出來。
有時，如果存在較高層次的規格說明時，則功能摘要可直接從中取得，這個較高層次的規格說明爲軟件產品分配了特殊的功能，爲了清晰起見，請注意：
1） 編制功能的一種方法是製作功能表，以便客戶或者第一次讀這個文件的人都可以理解；
2） 用方框圖來表達不同的功能和它們的關係也是有幫助的。但要牢記，這樣的圖不是產品設計時所需求的，而只是一種有效的解釋性的工具。
這一條不用作陳述具體需求，只是對後來SRS中具體需求一章中爲什麼要描述的某些需求提供理由。
6.2.3 用戶特點（SRS的2.3條）
本條要描述影響具體需求的產品的最終用戶的一般特點。
許多人在軟件生存週期的操作和維護階段與系統相關。而這些人中有用戶、操作員、維護人員和系統工作人員。這些人的某些特點，象教育水平、經驗、技術、專長等，都是施加於系統操作環境的重要約束。
如果系統的大多數用戶是一些臨時用戶，那麼就要求系統包含如何完成基本功能的提示，而不是假設用戶已經從過去的會議或從閱讀用戶指南中瞭解到這些細節。
這一條的內容不能用來陳述具體需求或強加若干特殊的設計約束，本條應對在SRS的具體需求一章之中的某些具體需求或設計約束的描述提供理由。
6.2.4 一般約束（SRS的2.4條）
本條對設計系統陽限制開發者選擇的其他一些項作一般性描述。而這些項將限定開發者在設計系統時的任選項。這些包括：
1） 管理方針；
2） 硬件的限制；
3） 與其他應用間的接口；
4） 並行操作；
5） 審查功能；
6） 控制功能；
7） 所需的高級語言；
8） 通信協議；
9） 應用的臨界點；
10）安全和保密方面的考慮。
本條不陳述具體需求或具體設計約束：而對SRS的具體需求一章中爲什麼要確定某些具體需求和設計約束提供理由。
6.2.5 假設和依據（SRS的2.5條）
本條列出影響SRS中陳述的需求的每一個因素。這些因素不是軟件的設計約束，但是它們的改變可能影響到SRS中的需求。例如：假定一個特定的操作系統是在被軟件產品指定的硬件上使用的，然而，事實上這個操作系統是不可能使用的，於是，SRS就要進行相應的改變。
6.3 具體需求（SRS的第3章）
本章應包括軟件開發者在建立設計時需要的全部細節。這是SRS中篇幅最大和最重要的部分。
1） 根據本指南第4章所規定的準則（如可驗證性、無歧義性等），對每一個需求細節作具體描述；
2） 在SRS的前言、項目概述、附錄部分的有關討論中，要提供對任何一個具體需求交叉引用的背景；
3） 具體需求分類的方法如下：
Ø 功能需求；
Ø 性能需求；
Ø 設計約束；
Ø 屬性；
Ø 外部接口需求。
本章中要注意的二點是：
1） 符合邏輯的和可讀的方式組織；
2） 詳細描述每個需求，使該需求應達到目標能夠用指定的方法進行客觀的驗證。
6.3.1 具體需求的內容
6.3.1.1 功能需求
本條描述軟件產品的輸入怎樣變換成輸出。即軟件必須完成的基本動作。對於每一類功能或者有時對於每一個功能，需要具體描述其輸入、加工和輸出的需求。這通常由四個部頒組成：
1） 引言
這部分描述的是功能要達到的目標、所採用的方法和技術，還應清楚說明功能意圖的由來和背景。
2） 輸入
這部分應包括：
Ø 詳細描述該功能的所有輸入數據，如：輸入源、數量、度量單位、時間設定、有效輸入範圍（包括精度和公差）；
Ø 操作員控制細節的需求。其中有名字、操作員活動的描述、控制檯或操作員的位置。例如：當打印檢查時，要求操作員進行格式調整；
Ø 指明引用接口說明或接口控制文件的參考資料。
3） 加工
定義輸入數據、中間參數，以獲得預期輸出結果的全部操作。它包括如下的說明：
Ø 輸入數據的有效性檢查；
Ø 操作的順序，包括事件的時間設定；
Ø 異常情況的響應，例如，溢出、通信故障、錯誤處理等；
Ø 受操作影響的參數；
Ø 降級運行的要求；
Ø 用於把系統輸入變換成相應輸出的任何方法（方程式、數學算法、邏輯操作等）；
Ø 輸出數據的有效性檢查。
4） 輸出
這部分應包括：
Ø 詳細描述該功能所有輸出數據，例如：輸出目的地、數量、度量單位、時間關係、有效輸出的範圍（包括精度和公差）、非法值的處理、出錯信息；
Ø 有關接口說明或接口控制文件的參考資料。
此外，對着重於輸入輸出行爲的系統來說，SRS應指定所有有意義的輸入、輸出對及其序列。當一個系統要求記憶它的狀態時，需要這個序列，使得它可以根據本次輸入和以前的狀態作出響應。也就是說，這種情況猶如有限狀態機。
6.3.1.2 設計約束
設計約束受其他標準、硬件限制等方面的影響。
1） 其他標準的約束：本項將指定由現有的標準或規則派生的要求。例如：報表格式、數據命名、財務處理、審計追蹤等等。
2） 硬件的限制：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括：硬件配置的特點（接口數，指令系統等）、內存儲器和輔助存儲器的容量。
6.3.1.3 屬性
在軟件的需求之中有若干個屬性，下面指出其中的幾個（注意：對這些決不應理解爲是一個完整的清單）。
1） 可用性：可以指定一些因素，如檢查點、恢復和再啓動等，以保證整個系統有一個確定的可用性級別。
2） 安全性：這裏指的是保護軟件的要素，以防止各種非法的訪問、使用，修改、破壞或者泄密。這個領域的具體需求必須包括：
Ø 利用可靠的密碼技術；
Ø 掌握特定的記錄或歷史數據集；
Ø 給不同的模塊分配不同的功能；
Ø 限定一個程序中某些區域的通信；
Ø 計算臨界值的檢查和。
3） 可維護性：這裏規定若干需求以確保軟件是可維護的。例如：
Ø 軟件模塊所需要的特殊的耦合矩陣；
Ø 對微型裝置指定特殊的數據/程序分割要求。
4） 可轉移/轉換性：這裏規定把軟件從一種環境移植到另一種環境所要求的用戶程序，用戶接口兼容方面的約束等等。
5） 警告：指定所需屬性十分重要，它使得人們能用規定的方法去進行客觀的驗證。
6.3.1.4 外部接口要求
1） 用戶接口：提供用戶使用軟件產品是地的接口需求。例如，如果系統的用戶通過顯示終端進行操作，就必須指定如下要求：
Ø 對屏幕格式的要求；
Ø 報表或菜單的頁面打印格式和內容；
Ø 輸入輸出的相對時間；
Ø 程序功能鍵的或用性。
2） 硬件接口：要指出軟件產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什麼樣的設備，如何支撐這些設備，有何約定。
3） 軟件接口：在這裏應指定需使用的其他軟件產品（例如，數據管理系統，操作系統，或者數學軟件包），以及同其他應用系統之間的接口。對每一個所需的軟件產品，要提供名字、助記符、規格說明號、版本號、來源等內容。 對於每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，並根據信息的內容和格式定義接口，這裏不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。
4） 通信接口：這裏指定各種通信接口，例如，局部網絡的協議等等。
6.3.1.5 其他需求
根據軟件和用戶組織的特性等，某些需求放在下面各項中描述。
1） 數據庫：本項對作爲產品的一部分進行開發的數據庫規定一些需求，它們可能包括：
Ø 在6.3.1.1條中標識的信息類別；
Ø 用的頻率；
Ø 存取能力；
Ø 數據元素和文卷描述符；
Ø 數據元素、記錄和文卷的關係；
Ø 靜態和動態的組織；
Ø 數據保存要求。
注：如果使用一個現有的數據庫包，這個包應在“軟件接口”中命名，並在那裏詳細說明其用法。
2） 操作：這裏說明用戶要求的常規的和特殊的操作。
Ø 在用戶組織之中各種方式的操作。例如，用戶初始化操作；
Ø 交互作用操作的同期和無人操作的週期；
Ø 數據處理支持功能；
Ø 後援和恢復操作。
注：這裏的內容有時是用戶接口的一部分。
3） 場合適應性需求：這裏包括：
Ø 對給定場合、任務或操作方式的任何數據或初始化順序的需求進行定義。例如，柵值，安全界限等等。
Ø 指出場合或相關任務的特點，這裏可以被修改以使軟件適合特殊配製的要求。
6.3.2 具體要求的組織
本條通常是SRS所有部分中最大並且最複雜的部分。
1） 可以根據軟件實現功能的基本類型，將本條分成若干段。例如：考慮一個大的交互記帳系統，在裏層可以分爲操作軟件（它支持近乎實時的事務處理）、支撐軟件（聯機功能、磁盤備份、裝入磁帶等等）以及診斷軟件（診斷硬件、通信等），外一層是應收款帳以及應付款帳等等；
2） 結構細分的目的是提高SRS的可讀性，而不是進行概要設計。
對於SRS中的第3章的具體需求部分的最好的組織方案取決於所說明的軟件產品的應用範圍和性質。 文中最後部分提供了四種可能的組織方案。
1） 大綱1中首先說明全部功能需求，然後說明四種類型的接口要求，最後是其他需求；
2） 大綱2中，把對應每個特定功能的四種接口需求和該功能需求放在一起描述，然後說明其他需求；
3） 大綱3中，與功能需求有關的全部內容放在一起首先說明，然後是其他需求的描述。對每一種外部接口的需求重複上述過程；
4） 大綱4中，接口需求和其餘的需求作爲每一個功能需求的附屬部分來說明。
SRS的具體需求的組織形式必須選擇可讀性最好的方法來描述。
6.4 支持信息
支持信息是指目錄表，附錄和索引。以便使SRS易於使用。
1）目錄表和索引很重要，而且應按照可以接受的好的文件規則來編寫。
2）對一個實際的需求規格說明來說，若有必要應該編寫附錄。附錄中可能包括：
Ø 輸入輸出格式樣本，成本分析研究的描述或用戶調查結果；
Ø 有助於理解SRS的背景信息；
Ø 軟件所解決問題的描述；
Ø 用戶歷史、背景、經歷和操作特點；
Ø 交叉訪問表。按先後次序進行編排，使一些不完全的軟件需求得以完善（參見4.3.2條和4.3.3條）；
Ø 特殊的裝配指令用於編碼和媒體，以滿足安全、輸出、初始裝入或其他要求。
3）6.4.3 當包括附錄時，SRS必須明確地說明附錄是不是需求要考慮的部分。
|
SRS大綱1
3 具體需求
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 引言 3.1.1.2 輸入 3.1.1.3 加工 3.1.1.4 輸出
3.1.2 功能需求2
……
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用戶接口 3.2.2 硬件接口 3.2.3 軟件接口 3.2.4 通信接口
3.3 性能需求
3.4 設計約束
3.4.1 其他標準的約束 3.4.2 硬件的限制 …………
3.5 屬性
3.5.1 安全性 3.5.2 可維護性 …………
3.6 其他需求
3.6.1 數據庫 3.6.2 操作 3.6.3 場合適應性 ………… |
|
SRS大綱2
3 具體需求
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 規格說明
3.1.1.1.1 引言 3.1.1.1.2 輸入 3.1.1.1.3 加工 3.1.1.1.4 輸出
3.1.1.2 外部接口
3.1.1.2.1 用戶接口 3.1.1.2.2 硬件接口 3.1.1.2.3 軟件接口
3.1.1.2.4 通信接口
3.1.2 功能需求2
…………
3.1.n 功能需求n
3.2 性能需求
3.3 設計約束
3.4 屬性
3.4.1 安全性 3.4.2 可維護性 …………
3.5 其他需求
3.5.1 數據庫 3.5.2 操作 3.5.3 場合適應性 ………… |
|
SRS大綱4
3 具體需求
3.1 功能需求1
3.1.1 引言 3.1.2 輸入 3.1.3 加工 3.1.4 輸出
3.1.5 外部接口
3.1.5.1 用戶接口 3.1.5.2 硬件接口
3.1.5.3 軟件接口 3.1.5.4 通信接口
3.1.6 性能需求
3.1.7 設計約束
3.1.8 屬性
3.1.8.1 安全性 3.1.8.2 可維護性 …………
3.1.9 其他需求
3.1.9.1 數據庫 3.1.9.2 操作 3.1.9.3 場合適應性 …………
3.2 功能需求2
…………
3.n 功能需求n |
|
SRS大綱3
3 具體需求
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 引言 3.1.1.2 輸入 3.1.1.3 加工 3.1.1.4 輸出
3.1.1.5 性能需求
3.1.1.6 設計約束
3.1.1.6.1 其他標準的約束 3.1.1.6.2 硬件的限制 …………
3.1.1.7 屬性
3.1.1.7.1 安全性 3.1.1.7.2 可維護性 …………
3.1.1.8 其他需求
3.1.1.8.1 數據庫 3.1.1.8.2 操作 3.1.1.8.3 場合適應性
…………
3.1.2 功能需求2
…………
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用戶接口
3.2.1.1 性能需求
3.2.1.2 設計約束
3.2.1.2.1 其他標準的約束 3.2.1.2.2 硬件的限制 …………
3.2.1.3 屬性
3.2.1.3.1 安全性 3.2.1.3.2 可維護性 …………
3.2.1.4 其他需求
3.2.1.4.1 數據庫 3.2.1.4.2 操作 3.2.1.4.3 場合適應性
…………
3.2.2 硬件接口 3.2.3 軟件接口 3.2.4 通信接口 |
用例說明模板1(經典模板)
編者說明：
隨着UML的日益普及，用例（Use case）分析技術也在需求實踐中廣泛被採用。但是也有許多團隊在使用該技術時，只畫出了用例圖，而缺少了用例說明，其實這是一個嚴重的誤區。而本模板就將指導你編寫該說明。
1.用例名稱
1.1 簡要說明
[簡要說明用例的作用和目的。該小節的篇幅不要太長。]
2.上下文圖
[在此小節中，有一個只包括本用例和所有與該用例相關的Actor和其它用例組成的，一個用例圖的局部。]
3. 事件流
3.1 基本流
[當Actor採取行動時，用例也就隨即開始。用例總是由Actor啓動的，用例應說明Actor的行爲及系統的響應，可按照Actor與系統進行對話的形式來逐步引入用例。]
[要注意的是，用例描述應該說明系統內發生的事情，而不是事件發生的方式與原因。如果進行了信息交換，則需指出來回傳遞的具體信息。例如，只表述主角輸入了客戶信息就不夠明確。最好明確地說主角輸入了客戶姓名和地址。當然你也可以通過項目詞彙表來定義這些信息，使得用例中的內容被簡化，從而不致於讓用例描述陷入過多的細節內容。]
[如果存在一些相對比較簡單的備選流，只需少數幾句話就可以說明清楚，那麼也可以直接在這一部分中描述。但是如果比較複雜，還是應該單獨放在備選流小節中描述。]
[一幅圖勝過千言萬語，因此建議在這一小節中，除了敘述性文字之外，你還可以引用UML中的活動圖、順序圖、協作圖、狀態圖等手段，對其進行補充說明。]
3.2 備選流
3.2.1 第一備選流
[正如前面所述，對於較複雜的備選流應單獨地說明。]
3.2.1.1 備選支流
[如果能使表達更明確，備選流又可再分爲多個支流。]
3.2.2 第二備選流
[在一個用例中很可能會有多個備選流。爲了使表達更清晰，應將各個備選流分開說明。使用備選流可以提高用例的可讀性，並防止將用例分解爲過多的層次。應切記，用例只是文本說明，其主要目的是以清晰、簡潔、易於理解的方式記錄系統的行爲。]
4. 非功能需求
[在這個小節中，主要對該用例所涉及的非功能性需求進行描述。由於其通常很難以在事件流中進行表述，因此單列爲一小節進行闡述。這些需求通過包括法律法規、應用程序標準、質量屬性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及設計約束等方面的需求。在這些需求的描述方面，一定要注意使其可度量、可驗證，否則就容易流於形式，形同擺設。]
5. 前置條件
[用例的前置條件是執行用例之前必須存在的系統狀態。]
6. 後置條件
[用例的後置條件是用例一執行完畢系統可能處於的一組狀態。]
7. 擴展點
[此用例的擴展點，通常是用例圖中的extent關係。]
用例說明模板2(單列表格式)
編者說明：
如果你覺得文本描述不夠清晰，也可以採用如本文檔模板所示的表格式的描述方式。
|
用例# |
[用例名應是一個動詞短語，應讓讀者一目瞭然地從名字中就可以知道該用例的目標。] | |||
|
使用語境 |
[用例目標，是一個較長的描述，甚至包括觸發條件。] | |||
|
範圍 |
[用例的設計範圍，在設計時將系統作爲一個黑盒來考慮。] | |||
|
級別 |
[概要、用戶目標、子功能三者之一。] | |||
|
主執行者 |
[也就是該用例的主Actor，在此應列出其名稱，並簡要描述。] | |||
|
項目相關人員利益 |
項目相關人員 |
利益 | ||
|
[項目相關人員名稱] |
[項目相關人員取得的利益] | |||
|
…… |
…… | |||
|
前置條件 |
[也就是激發該用例，所應該滿足的條件。] | |||
|
後置條件 |
[也就是該用例完成之後，將執行什麼動作。] | |||
|
成功保證 |
[描述當目標完成後，環境的變化情況。] | |||
|
觸發事件 |
[什麼引發用例，例如時間事件。] | |||
|
描述 |
步驟 |
活動 | ||
|
1 |
[在這裏寫出觸發事件到目標完成以及清除的步驟。] | |||
|
2 |
[……] | |||
|
3 |
| |||
|
擴展 |
步驟 |
分支動作 | ||
|
1a |
[引起分支的條件] | |||
|
|
[活動或子用例名稱] | |||
|
技術和數據變化 |
|
| ||
|
1 |
[變化列表] | |||
用例說明模板3(雙列表格式)
編者說明：
本模板是對上一模板的補充，如果你想更好地捕捉系統的響應，那麼就可以採用本表格所示的格式。
有時，爲了更好地捕獲系統的響應，對於場景描述（主成功場景、擴展場景）在上表的基礎上變成如下表所示的雙列：
|
步驟 |
用戶 |
系統 |
|
|
|
|
|
|
|
|
用例說明模板4(文本式)
編者說明：
相信用過用例分析技術的，對用例應該多少細有很大的疑問，而Alistair Cockburn率先將其進行分級：概要、用戶目標、子功能，如果你對他的思想有認同，則該模板就適合於你。
1.用例名：
[用例名應是一個動詞短語，應讓讀者一目瞭然地從名字中就可以知道該用例的目標。]
2.使用語境：
[用例目標，是一個較長的描述，甚至包括觸發條件。]
3.範圍：
[用例的設計範圍，在設計時將系統作爲一個黑盒來考慮。]
4.級別：
[用來表示該用例是在描述哪個級別上的功能，通常包括概要、用戶目標、子功能三種。這三種級別的劃分是Alistair Cockburn在《編寫有效用例》一書是提出的。]
5.主執行者：
[也就是該用例的主Actor，在此應列出其名稱，並給予簡要描述。]
1. 項目相關人員利益
[說明該用例對項目相關人員能夠帶來什麼好處。]
2. 前置條件：
[也就是激發該用例，所應該滿足的條件。]
3. 後置條件：
[也就是該用例完成之後，將執行什麼動作。]
4. 成功保證：
[描述當目標完成後，環境的變化情況。]
5. 觸發事件：
[什麼引發用例，例如時間事件。]
6. 主成功場景
[在這裏寫出觸發事件到目標完成以及清除的步驟。]
[步驟編號＃：動作描述]
[步驟編號＃：動作描述]
……
7. 擴展：
[在這裏寫出擴展情況，每次寫一個擴展，每個擴展都應指向主場景的特定步驟。]
[被改變步驟 條件：動作或子用例]
[被改變步驟 條件：動作或子用例]
……
8. 技術和數據變化列表
[在這裏寫出場景中因技術或數據變化而引起的可能分支。]
[步驟或變化編號＃：變化列表]
[步驟或變化編號＃：變化列表]
……
9. 相關信息
[項目所需要的所有附加信息。]
數據要求說明書(ISO標準)
編者說明：
如果在你的項目中有大量要求數據存儲、數據採集等方面的需求，那麼你就應該專門將這些需求進行整理，以數據要求說明書的形式表現出來。
1．引言
1.1編寫目的
[說明編寫這份數據要求說明書的目的，指出預期的讀者。]
1.2背景
a.待開發軟件系統的名稱；
b.列出本項目的任務提出者、開發者、用戶以及將運行該項軟件的計算站或計算機網絡系統。
1.3定義
[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。]
1.4參考資料
[列出有關的參考資料。]
2．數據的邏輯描述
[對數據進行邏輯描述時可把數據分爲動態數據和靜態數據。]
2.1靜態數據
[列出所有作爲控制或參考用的靜態數據元素。]
2.2動態輸入數據
[列出動態輸入數據元素。]
2.3動態輸出數據
[列出動態輸出數據元素。]
2.4內部生成數據
[列出向用戶或開發單位中的維護調試人員提供的內部生成數據。]
2.5數據約定
[說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制。對於在設計和開發中確定是臨界性的限制更要明確指出。]
3．數據的採集
3.1要求和範圍
[按數據元的邏輯分組來說明數據採集的要求和範圍，指明數據的採集方法，說明數據採集工作的承擔者是用戶還是開發者。]
3.2輸入的承擔者
[說明預定的對數據輸入工作的承擔者。如果輸入數據同某一接口軟件有關，還應說明該接口軟件的來源。]
3.3預期處理
[對數據的採集和預處理過程提出專門的規定，包括適合應用的數據格式、預定的數據通信媒體和對輸入的時間要求等。對於需經模擬轉換或數字轉換處理的數據量，要給出轉換方法和轉換因子等有關信息，以便軟件系統使用這些數據。]
3.4影響
[說明這些數據要求對於設備、軟件、用戶、開發單位所可能產生的影響。]