理順軟件開發各個環節-5

4.4.2 軟件需求規格書（SRS）編寫要點

　　這裏分享一下我以前一直使用的SRS的文檔模板，根據個人經驗，按照這個文檔模板來作軟件需求分析，能夠提升軟件需求分析的質量。

　　模板中有一些要點和例子直接來自網上，時間好久了，來源已不可考。

　　文檔模板中的斜體字爲示例。

 

　　章節一、概述

　　概述提出了對軟件需求說明的縱覽，這有助於讀者理解文檔如何編寫、如何閱讀。如：

　　本章說明XXX產品的軟件需求規格書（簡稱SRS，下同）的編寫目的、編寫約定、預期讀者和參考文獻。

 

　　章節1.一、編寫目的

　　指出這個軟件需求規格書預期的目的。如：

　　編寫本SRS，以期達到下列目的：

• 規定產品的系統邊界；

• 描述本產品的用戶類型和特徵；

• 規定產品應該實現的系統特性，包括功能需求、非功能需求、外部接口及其它需求，分別在第三、四、五、6章說明。

 

　　章節1.二、文檔約定

　　描述編寫文檔時所採用的標準或排版約定，包括正文風格、提示區或重要符號。例如，說明了高層需求的優先級是否能夠被其全部細化的需求所繼承，或者每一個需求陳述是否都有其自身的優先級。

 

　　章節1.2.一、通用規則

　　1.編號及應用規則

•  對節、小節和單個需求的號碼編排必須一致。
• 單個需求的編號（ID）必須惟一，且不得隨意更改，以便於不一樣文檔之間的引用和管理；
• 正確使用各類可視化強調標誌(例如，黑體、下劃線等)；
• 需求分級表示，父需求能夠用子需求展開，父需求用父標題，子需求用子標題，做爲功能描述的全部子標題所有將相應變化；
• 模版列出的標題項目，若是具體使用過程當中沒有使用到，應予以保留，不能刪除；
• 做爲標題的需求項，應包含需求ID，以便從目錄中可觀察到ID；
• 建立目錄表和索引表有助於讀者尋找所需的信息；
• 使用交叉引用功能來查閱文檔中其它項或位置，而不是經過手工輸入的頁碼或節號方式。

　　2.在正式開發以前， TBD（to be determined）項均應該消除。

　　3.需求描述建議：

• 保持語句和段落的簡短；
• 採用主動語態的表達方式；
• 編寫具備正確的語法、拼寫和標點的完整句子；
• 使用的術語與詞彙表中所定義的應該一致；
• 需求陳述應該具備一致的樣式，例如「系統必須……」或者「用戶必須……」，並緊跟一個行爲動做和可觀察的結果。例如，「倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的化學藥品容器清單。」；
• 爲了減小不肯定性，必須避免模糊的、主觀的術語，例如，用戶友好、容易、簡單、迅速、有效、支持、許多、最新技術、優越的、可接受的和健壯的。當用戶說「用戶友好」或者「快」或者「健壯」時，你應該明確它們的真正含義而且在需求中闡明用戶的意圖；
• 避免使用比較性的詞彙，例如：提升、最大化、最小化和最佳化。定量地說明所須要提升的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該「處理」、「支持」或「管理」某些事情時，你應該能理解客戶的意圖。含糊的語句表達將引發需求的不可驗證；
• 不該該把多個需求集中在一個冗長的敘述段落中。在需求中諸如「和」，「或」之類的連詞就代表了該部分集中了多個需求。務必保證，不要在需求說明中使用「和/或/等等」之類的連詞。

　　4.其它約定：

• 優先級使用1-5級，5級最高，1級最低；
• 若是父需求的優先級與子需求的優先級不一致，則以子需求的優先級爲準。
• 黑體字代表有相應的數據字典定義。

 

　　章節1.2.二、編號規則

　　章節1.2.2.一、ID編號規則

　　ID =需求類型 + 4位編號

　　需求類型：

　　　　功能需求 SF（Software Function）

　　　　性能需求 SP（Software Performance）

　　　　非功能需求 NF（None-Function）

　　　　外部接口:

　　　　　　用戶界面 UI（User Interface）

　　　　　　硬件接口 HI（Hardware Interface）

　　　　　　軟件接口 SI（Software Interface）

　　　　　　通訊接口 CI（Communication Interface）

　　　　質量屬性 QA（Quality Attribute）

　　　　業務規則 BR（Business Rule）

　　　　用戶文檔要求 UD（User Document）

　　　　其它需求 OR（Other Requirement）

　　4位編號：由四位字符組成，每一個字符能夠爲0~9，A-Z，無次序要求，但上下文是惟一的。

　　注：若是爲大產品，需求項不少，可以使用5位編號。

 

　　章節1.2.2.二、需求過程描述項編號規則

　　Number = 描述分類 + 4位編號

　　描述分類：

　　　　前置條件 C

　　　　後置條件 R

　　　　正常過程 N

　　　　異常過程 E

　　　　可選過程 A

　　4位編號：從0XXY開始。XX從01開始，Y從0開始，開始時Y以零編號，修改時，可從中間插入。採用4位數字編號。

 

　　章節1.2.2.三、需求過程描述項編號規則

　　REF =產品（項目）編號 + 「.」 + 需求規格書類型 + 「.」 + 最高級ID + 「.」 + 次級ID + 「.」 + … + 最低級ID

　　產品（項目）編號：產品的編號（如只有項目，就用項目編號），如P001等。

　　需求規格書類型

　　　　用戶需求 URS

　　　　產品需求 PRS

　　　　軟件需求 SRS

　　　　子系統需求 SSRS

　　　　模塊需求 MRS

 

　　如：P001.SRS.SF0001.A0001.B0002.N0010表示P001產品的軟件需求規格書的SF0001需求項的A0001子項的B0002子項的N0010項。

 

　　章節1.三、預期讀者和閱讀建議

　　列舉了軟件需求規格書所針對的不一樣讀者，例如開發人員、項目經理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩餘部分的內容及其組織結構。提出了最適合於每一類型讀者閱讀文檔的建議。如：

 

　　預期的讀者和閱讀建議參見表1.1。

　　　　　　　　　　　　　　　　　　　　　表1.1

讀者分類	閱讀重點及目的	備註
項目經理	全文，並據此編制/修訂項目開發計劃等。
設計與開發工程師	需求的完整性、正確性、可行性、優先級、無二義性
產品及運營經理	需求的完整性、必要性、優先級，並據此開展運營工做。
測試工程師	需求的可驗證性，並據此準備（軟件）系統測試方案。

 

 

　　章節1.四、術語和定義

　　術語（Terms）能夠理解爲數據字典的數據項（詞條），將本文引用的部分羅列出來。如：

 

　　術語和定義參見表1.2。

　　　　　　　　　　　　表1.2

(拼音首)字母	名詞	解釋
C	產品地域	產品地域是指產品所屬的銷售範圍，產品能夠是全省的，也能夠只是針對某個地市的。
C	產品參數	產品參數是產品在訂購時須要指定的用戶參數。這些用戶參數將在產品的具體資費計算過程當中使用。
D	代收	接受其它單位的委託，代其收取業務費用的過程。
G	工單	工單是指爲了完成某個服務請求或訂單而派發的跨業務處理流程環節的協同工做單。

 

 

　　章節1.五、縮略語

　　縮略語（Abbreviations）爲專業詞彙或自定義詞彙的縮寫（通常是英文縮寫）。如：

 

　　縮略語參見表1.3。

　　　　　　　　　　　　　　　　　　　　　　表1.3

縮略語	英文原文	中文含義
GPRS	General Packet Radio Service	通用分組無線服務技術
HLR	Home Location Register	歸屬位置寄存器
ICCID	CCID IC Card Identity	SIM卡識別號

 

　　章節1.六、參考文獻

　　列舉了編寫軟件需求規格書時所參考的資料或其它資源。這可能包括用戶界面風格指導、合同、標準、系統需求規格說明、使用實例文檔，或產品需求規格書。若有可能，給出詳細的信息，包括標題名稱、做者、版本號、日期、出版單位或資料來源，以方便讀者查閱這些文獻。

 

　　章節二、綜合描述

　　這一部分概述了正在定義的產品以及它所運行的環境、使用產品的用戶和已知的限制、假設和依賴。

 

　　章節2.一、產品背景

　　描述了軟件需求規格書中所定義的產品的背景和起源。說明了該產品是不是產品系列中的下一成員，是不是成熟產品所改進的下一代產品、是不是現有應用程序的替代品，或者是不是一個新型的、自含型產品。若是軟件需求規格說明定義了大系統的一個組成部分，那麼就要說明這部分軟件是怎樣與整個系統相關聯的，而且要定義出二者之間的接口。

 

　　章節2.二、產品的範圍

　　給出系統邊界圖和描述。

 

　　章節2.三、產品整體功能

　　概述了產品所具備的主要功能。其詳細內容將在第3~6章中描述，因此在此只須要概略地總結，例如用列表的方法給出。很好地組織產品的功能，使每一個讀者都易於理解。用圖形表示主要的需求分組以及它們之間的聯繫，例如數據流程圖的頂層圖或類圖，都是有用的。

 

　　章節2.四、用戶類型和特徵

　　肯定你以爲可能使用該產品的不一樣用戶類型並描述它們相關的特徵。有一些需求可能只與特定的用戶類型相關。將該產品的重要用戶類型與那些不過重要的用戶類型區分開。

 

　　章節2.五、運行環境

　　描述了軟件的運行環境，包括硬件平臺、操做系統和版本，還有其它的軟件組件或與其共存的應用程序。

 

　　章節2.六、設計和實現上的限制

　　肯定影響開發人員自由選擇的問題，並說明這些問題爲何成爲一種限制。可能的限制包括以下內容：

•  必須使用或者避免的特定技術、工具、編程語言和數據庫；
•  所要求的開發規範或標準；
• 所使用的設計符號表示和編碼標準；
• 企業策略、政府法規或工業標準；
• 硬件限制，例如定時需求或存儲器限制；
• 數據轉換格式標準；
• 等等...。

 

　　章節2.七、假設和依賴

　　列舉出在對軟件需求規格書中影響需求陳述的假設因素(與已知因素相對立)。

　　這可能包括你打算要用的商業組件或有關開發或運行環境的問題。你可能認爲產品將符合一個特殊的用戶界面設計約定，可是另外一個SRS讀者卻可能不這樣認爲。若是這些假設不正確、不一致或被更改，就會使項目受到影響。

　　此外，肯定項目對外部因素存在的依賴。例如，若是你打算把其它項目開發的組件集成到系統中，那麼你就要依賴那個項目按時提供正確的操做組件。若是這些依賴已經記錄到其它文檔(例如項目計劃)中了，那麼在此就能夠參考其它文檔。

 

　　章節三、功能需求

　　詳列出與該特性相關的詳細功能需求。這些是必須提交給用戶的軟件功能，使用戶能夠用所提供的特性執行服務或者使用所指定的「使用實例」（Use Case）執行任務。描述產品如何響應可預知的出錯條件、非法輸入或動做，你必須惟一地標識每一個需求。

 

　　章節3.一、SF0100 功能需求1

　　需求描述：

　　優先級：

　　參與者/角色（用戶）：

　　前置條件：

　　後置條件：

　　正常過程：

　　可選過程：

　　異常過程：

　　非功能需求：

　　注：功能需求的描述，使用Use Case方式，後面將給出一個書寫示例。

 

　　章節3.二、SF0105 功能需求2

　　需求描述：

　　優先級：

　　參與者/角色（用戶）：

　　前置條件：

　　後置條件：

　　正常過程：

　　可選過程：

　　異常過程：

　　非功能需求：

 

　　章節四、其它非功能需求

　　這部分列舉出了全部非功能需求，外部接口需求和限制不在此處描述。

 

　　章節4.一、性能需求

　　闡述了不一樣的應用領域對產品性能的需求，並解釋它們的原理以幫助開發人員做出合理的設計選擇。

　　肯定相互合做的用戶數或者所支持的操做、響應時間以及與實時系統的時間關係。

　　你還能夠在這裏定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。

　　儘量詳細地肯定性能的需求。可能須要針對每一個功能需求或特性分別陳述其性能需求，而不是把它們都集中在一塊兒陳述。

 

　　章節4.二、質量屬性

　　下列質量屬性中，選擇你須要描述的部分，加以說明，或者加上你認爲須要的其它質量屬性。

 

　　章節4.2.一、有效性

　　有效性指的是在預約的啓動時間中，系統真正可用而且徹底運行時間所佔的百分比。更正式地說，有效性等於系統的平均故障時間(MTTF)除以平均故障時間與故障修復時間之和。有些任務比起其它任務具備更嚴格的時間要求，此時，當用戶要執行一個任務但系統在那一時刻不可用時，用戶會感到很沮喪。詢問用戶須要多高的有效性，而且是否在任什麼時候間，對知足業務或安全目標有效性都是必須的。如：

　　一個有效性需求可能這樣說明：「工做日期間，在當地時間早上6點到午夜，系統的有效性至少達到99.5％，在下午4點到6點，系統的有效性至少可達到99.95％。」

 

　　章節4.2.二、效率

　　效率是用來衡量系統如何優化處理器、磁盤空間或通訊帶寬。

　　若是系統用完了全部可用的資源，那麼用戶遇到的將是性能的降低，這是效率下降的一個表現。拙劣的系統性能可激怒等待數據庫查詢結果的用戶，或者可能對系統安全性形成威脅，就像一個實時處理系統超負荷同樣。如：

　　爲了在不可預料的條件下容許安全緩衝，你能夠這樣定義：「在預計的高峯負載條件下，10％處理器能力和15％系統可用內存必須留出備用。」

　　在定義性能、能力和效率目標時，考慮硬件的最小配置是很重要的。

 

　　章節4.2.三、靈活性

　　就像咱們所知道的可擴充性、增長性、可延伸性和可擴展性同樣，靈活性代表了在產品中增長新功能時所需工做量的大小。若是開發者預料到系統的擴展性，那麼他們能夠選擇合適的方法來最大限度地增大系統的靈活性。靈活性對於經過一系列連續的發行版本，並採用漸增型和重複型方式開發的產品是很重要的。

　　靈活性目標可以下設定：「一個至少具備6個月產品支持經驗的軟件維護程序員能夠在一個小時以內爲系統添加一個新的可支持硬拷貝的輸出設備。」

 

　　章節4.2.四、安全性

　　安全性(或完整性)主要涉及：防止非法訪問系統功能、防止數據丟失、防止病毒入侵併防止私人數據進入系統。

　　安全性對於經過WWW執行的軟件已成爲一個重要的議題。電子商務系統的用戶關心的是保護信用卡信息，Web的瀏覽者不肯意那些私人信息或他們所訪問過的站點記錄被非法使用。安全性的需求不能犯任何錯誤，即數據和訪問必須經過特定的方法徹底保護起來。用明確的術語陳述安全性的需求，如身份驗證、用戶特權級別、訪問約束或者須要保護的精確數據。

　　一個安全性的需求樣本能夠這樣描述：「只有擁有查帳員訪問特權的用戶才能夠查看客戶交易歷史。」

 

　　章節4.2.五、互操做性

　　互操做性代表了產品與其它系統交換數據和服務的難易程度。爲了評估互操做性是否達到要求的程度，你必須知道用戶使用其它哪種應用程序與你的產品相鏈接，還要知道他們要交換什麼數據。

　　「XX系統」的用戶習慣於使用Office excel表格工具，因此他們提出以下的互操做性需求：「XX系統應該可以導入和導出excel格式的數據。」

 

　　章節4.2.六、可靠性

　　可靠性是軟件無端障執行一段時間的機率，健壯性和有效性有時可當作是可靠性的一部分。

　　衡量軟件可靠性的方法包括正確執行操做所佔的比例，在發現新缺陷以前系統運行的時間長度和缺陷出現的密度。根據若是發生故障對系統有多大影響和對於最大的可靠性的費用是否合理，來定量地肯定可靠性需求。

　　若是軟件知足了它的可靠性需求，那麼即便該軟件還存在缺陷，也可認爲達到其可靠性目標。要求高可靠性的系統也是爲高可測試性系統設計的。

　　如某些設備全天工做而且使用稀有的、昂貴的化學制品。用戶要求真正與實驗相關的那部分軟件要高可靠性，而其它系統功能，例如週期性地記錄溫度數據，則對可靠性要求不高。對於該系統的一個可靠性需求說明以下：「因爲軟件失效引發實驗失敗的機率應不超過千分之5」。

 

　　章節4.2.七、健壯性

　　健壯性指的是當系統或其組成部分遇到非法輸入數據、相關軟件或硬件組成部分的缺陷或異常的操做狀況時，能繼續正確運行功能的程度。健壯的軟件能夠從發生問題的環境中無缺地恢復而且可容忍用戶的錯誤。當從用戶那裏獲取健壯性的目標時，詢問系統可能遇到的錯誤條件而且要了解用戶想讓系統如何響應。

　　一個健壯性需求是這樣說明的：「全部的規劃參數都要指定一個缺省值，當輸入數據丟失或無效時，就使用缺省值數據。」

 

　　章節4.2.八、易用性

　　它所描述的是組成「用戶友好」的主要因素。易用性衡量準備輸入、操做和理解產品輸出所花費的努力。

　　「化學制品跟蹤系統」的分析員詢問用戶這樣的問題：「你能快速、簡單地請求化學制品並瀏覽其它信息，這對你有多重要?」和「你請求一種化學制品大概需花多少時間?」對於定義使軟件易於使用的許多特性而言，這只是一個簡單的起點。對於易用性的討論能夠得出可測量的目標，例如「一個培訓過的用戶應該能夠在平均3分鐘或最多5分鐘時間之內，完成從供應商目錄表中請求一種化學制品的操做。」

　　一樣，調查新系統是否必定要與任何用戶界面標準或常規的相符合，或者其用戶界面是否必定要與其它經常使用系統的用戶界面相一致。這裏有一個易用性需求的例子：

　　「在文件菜單中的全部功能都必須定義快捷鍵，該快捷鍵是由Ctrl鍵和其它鍵組合實現的。出如今Microsoft Word2000中的菜單命令必須與Word使用相同的快捷鍵」。

　　易用性還包括對於新用戶或不常使用產品的用戶在學習使用產品時的簡易程度。易學程度的目標能夠常常定量地測量，例如，

　　「一個新用戶用不到30分鐘時間適應環境後，就應該能夠對一個化學制品提出請求」，或者「新的操做員在一天的培訓學習以後，就應該能夠正確執行他們所要求的任務的95％」。

　　當你定義易用性或可學性的需求時，應考慮到在判斷產品是否達到需求而對產品進行測試的費用。

 

　　章節4.2.九、可維護性

　　可維護性代表了在軟件中糾正一個缺陷或作一次更改的簡易程度。可維護性取決於理解軟件、更改軟件和測試軟件的簡易程度，可維護性與靈活性密切相關。高可維護性對於那些經歷週期性更改的產品或快速開發的產品很重要。你能夠根據修復(fix)一個問題所花的平均時間和修復正確的百分比來衡量可維護性。

　　」在圖形引擎工程中，咱們知道，咱們必須不斷更新軟件以知足用戶日益發展的須要，所以，咱們肯定了設計標準以加強系統總的可維護性：「函數調用不能超過兩層深度」，而且「每個軟件模塊中，註釋與源代碼語句的比例至少爲1：20」認真並精確地描述設計目標，以防止開發者作出與預約目標不相符的愚蠢行爲。

 

　　章節4.2.十、可移植性

　　可移植性是度量把一個軟件從一種運行環境轉移到另外一種運行環境中所花費的工做量。軟件可移植的設計方法與軟件可重用的設計方法類似。可移植性對於工程的成功是不重要的，對工程的結果也可有可無。能夠移植的目標必須陳述產品中能夠移植到其它環境的那一部分，並肯定相應的目標環境。因而，開發者就能選擇設計和編碼方法以適當提升產品的可移植性。

 

　　章節4.2.十一、可重用性

　　從軟件開發的長遠目標上看，可重用性代表了一個軟件組件除了在最初開發的系統中使用以外，還能夠在其它應用程序中使用的程度。比起建立一個你打算只在一個應用程序中使用的組件，開發可重用軟件的費用會更大些。

　　可重用軟件必須標準化、資料齊全、不依賴於特定的應用程序和運行環境，並具備通常性。肯定新系統中哪些元素須要用方便於代碼重用的方法設計，或者規定做爲項目副產品的可重用性組件庫。

 

　　章節4.2.十二、可測試性

　　可測試性指的是測試軟件組件或集成產品時查找缺陷的簡易程度。若是產品中包含複雜的算法和邏輯，或若是具備複雜的功能性的相互關係，那麼對於可測試性的設計就很重要。若是常常更改產品，那麼可測試性也是很重要的，由於將常常對產品進行迴歸測試來判斷更改是否破壞了現有的功能性。

 

　　章節4.三、安全設施需求

　　詳盡陳述與產品使用過程當中可能發生的損失、破壞或危害相關的需求。定義必須採起的安全保護或動做，還有那些預防潛在危險的動做。明確產品必須聽從的安全標準、策略或規則。

　　一個安全設施需求的範例以下：「若是併發請求數的超過了規定的最大值的90％，那麼必須在1秒鐘內進行限流處理」

 

　　章節4.四、業務規則

　　列舉出有關產品的全部操做規則，例如什麼人在特定環境下能夠進行何種操做。這些自己不是功能需求，但它們能夠是某些功能需求需考慮的業務規則。

　　一個業務規則的範例以下：「只有持有管理員密碼的用戶才能執行$100.00或更大額的退款操做。」

 

　　章節4.五、用戶文檔需求

　　列舉出將與軟件一同發行的用戶文檔，例如，用戶手冊、在線幫助和教程。明確全部已知的用戶文檔的交付格式或標準。

 

　　章節五、外部接口需求

　　利用本章來肯定能夠保證新產品與外部組件正確鏈接的需求。關聯圖表示了高層抽象的外部接口。須要把對接口數據和控制組件的詳細描述寫入數據字典中。若是產品的不一樣部分有不一樣的外部接口，那麼應把這些外部接口的詳細需求併入到這一部分的實例中。

 

　　章節5.一、用戶界面

　　陳述所須要的用戶界面的軟件組件。描述每一個用戶界面的邏輯特徵。

　　如今有UI&UE設計，故能夠直接寫：

　　　　參見XXX UI&UE交互設計。

 

　　章節5.二、硬件接口

　　描述系統中軟件和硬件每一接口的特徵。這種描述可能包括支持的硬件類型、軟硬件之間交流的數據和控制信息的性質以及所使用的通訊協議。

 

　　章節5.三、軟件接口

　　描述該產品與其它外部組件(由名字和版本識別)的鏈接，包括數據庫、操做系統、工具、庫和集成的商業組件。

　　明確並描述在軟件組件之間交換數據或消息的目的。描述所須要的服務以及內部組件通訊的性質。肯定將在組件之間共享的數據。若是必須用一種特殊的方法來實現數據共享機制，例如在多任務操做系統中的一個全局數據區，那麼就必須把它定義爲一種實現上的限制。

 

　　章節5.四、通訊接口

　　描述與產品所使用的通訊功能相關的需求，包括電子郵件、Web瀏覽器、網絡通訊標準或協議及電子表格等等。定義了相關的消息格式。規定通訊安全或加密問題、數據傳輸速率和同步通訊機制。

 

　　章節六、其它需求

　　定義在軟件需求規格說明的其它部分未出現的需求，例如國際化需求或法律上的需求。你還能夠增長有關操做、管理和維護部分來完善產品安裝、配置、啓動和關閉、修復和容錯，以及登陸和監控操做等方面的需求。在模板中加入與你的項目相關的新部分。若是你不須要增長其它需求，就省略這一部分。