引言
　　引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔。

　　1.1 編寫目的
　　說明這份軟件產品需求分析報告是為哪個軟件產品編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件產品需求分析報告詳盡說明了該軟件產品的需求規格，包括修正和(或)發行版本號，從而對該軟件產品進行準確的定義。
　　如果這份軟件產品需求分析報告只與整個系統的某一部分有關系，那么只定義軟件產品需求分析報告中說明的那個部分或子系統。
　　1.2 項目風險
　　具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：
　　● 任務提出者；
　　● 軟件開發者；
　　● 產品使用者。
　　1.3 文檔約定
　　描述編寫文檔時所采用的標準(如果有標準的話)，或者各種排版約定。排版約定應該包括：
　　● 正文風格；
　　● 提示方式；
　　● 重要符號；
　　也應該說明高層次需求是否可以被其所有細化的需求所繼承，或者每個需求陳述是否都有其自己的優先級。
　　1.4 預期讀者和閱讀建議
　　列舉本軟件產品需求分析報告所針對的各種不同的預期讀者，例如，可能包括：
　　● 用戶；
　　● 開發人員；
　　● 項目經理；
　　● 營銷人員；
　　● 測試人員；
　　● 文檔編寫入員。
　　并且描述了文檔中，其余部分的內容及其組織結構，并且針對每一類讀者提出最適合的文檔閱讀建議。
　　1.5 產品范圍
　　說明該軟件產品及其開發目的的簡短描述，包括利益和目標。把軟件產品開發與企業目標，或者業務策略相聯系。
　　描述產品范圍時需注意，可以參考項目視圖和范圍文檔，但是不能將其內容復制到這里。
　　1.6 參考文獻
　　列舉編寫軟件產品需求分析報告時所用到的參考文獻及資料，可能包括：
　　● 本項目的合同書；
　　● 上級機關有關本項目的批文；
　　● 本項目已經批準的計劃任務書；
　　● 用戶界面風格指導；
　　● 開發本項目時所要用到的標淮；
　　● 系統規格需求說明；
　　● 使用實例文檔；
　　● 屬于本項目的其它己發表文件；
　　● 本軟件產品需求分析報告中所引用的文件、資料；
　　● 相關軟件產品需求分析報告；
　　為了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：
　　● 標題名稱；
　　● 作者或者合同簽約者；
　　● 文件編號或者版本號；
　　● 發表日期或者簽約日期；
　　● 出版單位或者資料來源。
　2. 綜合描述
　　這一部分概述了正在定義的軟件產品的作用范圍以及該軟件產品所運行的環境、使用該軟件產品的用戶、對該軟件產品己知的限制、有關該軟件產品的假設和依賴。
　　2.1 產品的狀況
　　描述了在軟件產品需求分析報告中所定義的軟件產品的背景和起源。說明了該軟件產品是否屬于下列情況：
　　● 是否是產品系列中的下一成員；
　　● 是否是成熟產品所改進的下一代產品；
　　● 是否是現有應用軟件的替代品(升級產品)；
　　● 是否是一個新型的、自主型的產品。
　　如果該軟件產品需求分析報告定義的軟件系統是：
　　● 大系統的一個組成部分；
　　● 與其它系統和其它機構之間存在基本的相互關系。
　　那么必須說明軟件產品需求分析報告定義的這部分軟件是怎樣與整個大系統相關聯的，或者（同時）說明相互關系的存在形式，并且要定義出兩者之間的全部接口。
　　2.2 產品的功能
　　因為將在需求分析報告的第4部分中詳細描述軟件產品的功能，所以在此只需要概略地總結。僅從業務層面陳述本軟件產品所應具有的主要功能，在描述功能時應該 針對每一項需求準確地描述其各項規格說明。如果存在引起誤解的可能，在陳述本軟件產品主要功能的作用領域時，也需要對應陳述本軟件產品的非作用領域，以利 讀者理解本軟件產品。
　　為了很好地組織產品功能，使每個讀者都容易理解，可以采用列表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們之間的聯系使用數據流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。
　　參考用戶當前管理組織構架，了解各個機構的主要職能，將有助于陳述軟件產品的主要功能。
　　2.3 用戶類和特性
　　確定有可能使用該軟件產品的不同用戶類，并且描述它們相關的特征。往往有一些軟件需求，只與特定的用戶類有關。描述時，應該將該軟件產品的重要用戶類與非重要用戶類區分開。
　　用戶不一定是軟件產品的直接使用者，通過報表、應用程序接口、系統硬件接口得到軟件產品的數據和服務的人、或者機構也有他們的需求。所以，應該將這些外部需求視為通過報表、應用程序接口、系統硬件接口附加給軟件產品的附加用戶類。
　　2.4 運行環境
　　描述了本軟件的運行環境，一般包括：
　　● 硬件平臺；
　　● 操作系統和版本；
　　● 支撐環境(例如：數據庫等)和版本；
　　● 其它與該軟件有關的軟件組件；
　　● 與該軟件共存的應用程序。
　　2.5 設計和實現上的限制
　　確定影響開發人員自由選擇的問題，并且說明這些問題為什么成為一種限制?？赡艿南拗瓢ㄏ铝袃热?#xff1a;
　　● 必須使用的特定技術、工具、編程語言和數據庫；
　　● 避免使用的特定技術、工具、編程語言和數據庫；
　　● 要求遵循的開發規范和標準
　　例如，如果由客戶的公司或者第三方公司負責軟件維護，就必須定義轉包者所使用的設計符號表示和編碼標準；
　　● 企業策略的限制；
　　● 政府法規的限制；
　　● 工業標準的限制；
　　● 硬件的限制
　　例如，定時需求或存儲器限制；
　　● 數據轉換格式標淮的限制。
　　2.6 假設和約束(依賴)
　　列舉出對軟件產品需求分析報告中，影響需求陳述的假設因素(與己知因素相對立)。如果這些假設因素不正確、不一致或者被修改，就會使軟件產品開發項目受到影響。這些假設的因素可能包括：
　　● 計劃使用的商業組件，或者其它軟件中的某個部件；
　　● 假定產品中某個用戶界面將符合一個特殊的設計約定；
　　● 有關本軟件用戶的若干假定(例如：假定用戶會熟練使用SQL語言。)；
　　● 有關本軟件開發工作的若干假定(例如：用戶承諾的優惠、方便、上級部門給予的特殊政策和支持等。)；
　　● 有關本軟件運行環境的一些問題；
　　此外，確定本軟件開發項目對外部約束因素所存在的依賴。有關的約束可能包括：
　　● 工期約束；
　　● 經費約束；
　　● 人員約束；
　　● 設備約束；
　　● 地理位置約束；
　　● 其它有關項目約束；
　　3. 外部接口需求
　　通過本節描述可以確定，保證軟件產品能和外部組件正確連接的需求。關聯圖僅能表示高層抽象的外部接口，必須對接口數據和外部組件進行詳細描述，并且寫入數 據定義中。如果產品的不同部分有不同的外部接口，那么應該把這些外部接口的全部詳細需求并入到這一部分實例中。
　　注意：必須將附加用戶類的特征與外部接口需求加以區分，附加用戶類的特征描述的是通過接口取得軟件產品的數據和服務的人的需求；而外部接口需求描述的是接口本身的需求。
　　3.1 用戶界面
　　陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而不是用戶界面。以下是可能包括的一些特征：
　　● 將要采用的圖形用戶界面(GUl)標準或者產品系列的風格；
　　● 有關屏幕布局或者解決方案的限制；
　　● 將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能包括：
　　選單；
　　標準按鈕；
　　導航鏈接；
　　各種功能組件；
　　消息欄；
　　● 快捷鍵；
　　● 各種顯示格式的規定，可能包括：
　　不同情況下文字的對齊方式；
　　不同情況下數字的表現格式與對齊方式；
　　日期的表現方法與格式；
　　計時方法與時間格式；
　　等等。
　　● 錯誤信息顯示標準；
　　對于用戶界面的細節，例如：一個特定對話框的布局，應該寫入具體的用戶界面設計說明中，而不能寫入軟件需求規格說明中。
　　如果采用現成的、合適的用戶界面設計規范(標準)，或者另文描述，可以在這里直接說明，并且將其加入參考文獻。
　　3.2 硬件接口
　　描述待開發的軟件產品與系統硬件接口的特征，若有多個硬件接口，則必須全都描述。接口特征的描述內容可能包括：
　　● 支持的硬件類型；
　　● 軟、硬件之間交流的數據；
　　● 控制信息的性質；
　　● 使用的通訊協議；
　　3.3 軟件接口
　　描述該軟件產品與其它外部組件的連接，這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：
　　● 操作系統；
　　● 數據庫；
　　● 工具；
　　● 函數庫；
　　● 集成的商業組件
　　說明：這里所說的“集成的商業組件”，是指與系統集成的商業組件，而不是與軟件產品集成的商業組件。例如：中間件、消息服務，等等。
　　描述并且明確軟件產品與軟件組件之間交換數據或者消息的目的。描述所需要的服務，以及與內部組件通訊的性質。確定軟件產品將與組件之間共享的數據。如果必 須使用一種特殊的方法來實現數據共享機制，例如：在多用戶系統中的一個全局數據區，那么就必須把它定義為一種實現上的限制。
　　3.4 通訊接口
　　描述與軟件產品所使用的通訊功能相關的需求，包括：
　　● 電子郵件；
　　● WEB瀏覽器；
　　● 網絡通訊標準或者協議；
　　● 數據交互用電子表格；
　　必須定義相關的：
　　● 消息格式；
　　● 通訊安全或加密問題；
　　● 數據傳輸速率；
　　● 同步和異步通訊機制；
　　4. 系統功能需求
　　需要進行詳細的需求記錄，詳細列出與該系統功能相關的詳細功能需求，并且，唯一地標識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供 的功能執行服務或者使用所指定的使用實例執行任務。描述軟件產品如何響應己知的出錯條件、非法輸入、非法動作。
　　如果每一項功能需求都能用一項，也只需要用一項測試用例就能進行驗證，那么就可以認為功能需求已經適當地進行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。
　　功能需求是根據系統功能，即軟件產品所提供的主要服務來組織的?？梢酝ㄟ^使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內容，也可以便用這些元素的組合?？偠灾?#xff0c;必須選擇一種是讀者容易理解預期產品的組織方案。
　　用簡短的語句說明功能的名稱，例如：“4.1系統參數管理”。按照服務組織的順序，逐條闡述系統功能。無論說明的是何種功能，都應該針對該系統功能重復敘述4.1~ 4.3這三個部分。
　　可以通過各種方式來組織這一部分內容，例如采用：使用實例、運行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。其最終目的是，讓讀者容易理解 即將開發的軟件產品。一般來說，每個使用實例都對應一個系統功能，因而按照使用實例來組織內容比較容易讓用戶理解。
　　對應一些被共享的獨立使用實例，可以定義一些公用系統功能。
　　必須特別注意的是，在2.2節“產品的功能”中描述的全部需求，以及它們的規格說明；必須在某個系統功能描述中有所反映，而且不應重復。
　　4.1 說明和優先級
　　對該系統功能進行簡短的說明，并且指出該系統功能的優先級是：高、中、還是低。需要的話，還可以包括對特定優先級部分的評價，例如：利益、損失、費用和風險，其相對優先等級可以從1(低)到9(高)。
　　4.2 激勵／響應序列
　　列出輸入激勵(用戶動作、來自外部設備的信號或者其它觸發)并且定義針對這——功能行為的系統響應序列，這些序列將與使用實例中相關的對話元素相對應。
　　描述激勵／響應序列時，不僅需要描述基本過程，而且應該描述可選(擴充)過程，包括例外(引起任務不能順序完成的情況稱為例外)。疏忽了可選過程，有可能影響軟件產品的功能；如果遺漏例外過程，則有可能會引發系統崩潰。
　　如果采用流程圖來描述激勵／響應序列，比較容易讓用戶理解。
　　4.3 輸入／輸出數據
　　列出輸入數據(用戶輸入、來自外部接口的輸入或者其它輸入)并且定義針對這些輸入數據的處理(計算)方法，以及相應地輸出數據，描述對應區別：輸入數據和輸出數據。
　　當有大量數據需要描述時，也可以分類描述數據，并且注明各項數據的輸入、輸出屬性。
　　對于每一項數據，均需要描述：
　　● 數據名稱；
　　● 實際含義；
　　● 數據類型；
　　● 數據格式；
　　● 數據約束；
　　對于復雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳細的計算過程，并且列出每一步具體使用的實際算式；如果計算過程中涉及查表、判斷、迭代等處理方法，應該給出處理依據和相關數據。如果計算方法很簡單，也可以將其從略，不加描述。
　5. 其它非功能需求
　　在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。
　　5.1 性能需求
　　闡述不同應用領域對軟件產品性能的需求，并且說明提出需求的原理或者依據，以幫助開發人員做出合理的設計選擇。盡可能詳細地描述性能需求，如果需要，可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定：
　　● 相互合作的用戶數量；
　　● 系統支持的并發操作數量；
　　● 響應時間；
　　● 與實時系統的時間關系：
　　● 容量需求
　　存儲器；
　　磁盤空間；
　　數據庫中表的最大行數。
　　5.2 安全措施需求
　　詳盡陳述與軟件產品使用過程中可能發生的損失、破壞、危害相關的需求。定義必須采取的安全保護或動作，以及必須預防的潛在危險動作。明確軟件產品必須遵從的安全標準、策略、或規則。
　　5.3 安全性需求
　　詳盡陳述與系統安全性、完整性問題相關的需求，或者與個人隱私問題相關的需求。這些問題將會影響到軟件產品的使用，和軟件產品所創建或者使用的數據的保 護。定義用戶身份認證，或備授權需求。明確軟件產品必須滿足的安全性或者保密性策略。也可以通過稱為完整性的質量屬性來闡述這些需求。一個典型的軟件系統 安全需求范例如下：“每個用戶在第一次登錄后，必須更改他的系統預置登錄密碼，系統預置的登錄密碼不能重用?！?br />　　5.4 軟件質量屬性
　　詳盡陳述對客戶和開發人員至關重要的在軟件產品其它方面表現出來的質量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應該指明不同屬性的相對側重點，例如：易用性優于易學性，或者可移植性優于有效性。
　　5.5 業務規則
　　列舉出有關軟件產品的所有操作規則，例如：那些人在特定環境下可以進行何種操作。這些本身不是功能需求，但是他們可以暗示某些功能需求執行這些規則。一個 業務規則的范例如下：“進行達到或者超過10，000，00元人民幣的儲蓄業務時，必須通過附加的管理員認證?！?br />　　列舉業務規則時，可以根據規則的數量，選取合適的編目方式。
　　5.6 用戶文檔
　　列舉出將與軟件產品一同交付的用戶文檔，并且明確所有己知用戶文檔的交付格式或標準，例如：
　　● 安裝指南
　　紙質文檔，16開本；
　　● 用戶手冊
　　紙質文檔，16開本；
　　● 在線幫助
　　● 電子文檔，與軟件產品一同分發、配置；
　　● 使用教程電子文檔，與軟件產品一同分發、配置。
　　6. 詞匯表
　　列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原詞)。為了便于非軟件專業或者非計算機專業人士閱讀軟件產品需求分析 報告，要求使用非軟件專業或者非計算機專業的術語描述軟件需求。所以這里所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術 語。但是，對于無法回避的軟件專業或者計算機專業術語，也應該列入詞匯表并且加以準確定義。
　　7. 數據定義
　　數據定義是一個定義了應用程序中使用的所有數據元素和結構的共享文檔，其中對每個數據元素和結構都準確描述：含義、類型、數據大小、格式、計量單位、精度 以及取值范圍。數據定義的維護獨立于軟件需求規格說明，并且在軟件產品開發和維護的任何階段，均向風險承擔者開放。
　　如果為軟件開發項目創建一個獨立的數據定義，而不是為每一項特性描述有關的數據項，有利于避免冗余和不一致性。但是卻不利于多人協同編寫需求分析報告，容 易遺漏數據，也不方便閱讀。因此還是建議為每個特性描述有關的數據項，匯總數據項創建數據定義，再根據數據定義復核全部數據，使得它們的名稱和含義完全一 致。必須注意的是，為了避免二義性，在匯總數據項時應該根據數據項所代表的實際意義匯總，而不是根據數據項的名稱匯總。
　　在數據定義中，每個數據項除了有一個中文名稱外，還應該為它取一個簡短的英文名稱，該英文名稱應該符合命名規范，因為在軟件開發時將沿用該英文名稱?？梢允褂玫忍柋硎緮祿?#xff0c;名稱寫在左邊，定義寫在右邊。常見數據項的描述方式如下：
　　● 原數據元素
　　一個原數據元素是不可分解的，可以將一個數量值賦給它。定義原數據元素必須確定其
　　含義、類型、數據大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行
　　注釋文本，描述原數據元素的定義。
　　● 選擇項
　　選擇項是一種只可以取有限離散值的特殊原數據元素，描述時一一枚舉這些值，并用方
　　括號括起來寫在原數據元素的定義前。在兩項離散值之間，使用管道符分隔。
　　● 組合項
　　組合項是一個數據結構或者記錄，其中包含了多個數據項。這些數據項可以是原數據元
　　素，也可以是組合數據項，各數據項之間用加號連接。其中每個數據項都必須是數據定
　　義中定義過的，結構中也可以包括其它結構，但是絕對不允許遞歸。如果數據結構中有
　　可選項，使用圓括號把該項括起來。
　　● 重復項
　　重復項是組合項的一種特例，其中有一項將有多個實例出現在數據結構中，使用花括號
　　把該項括起來。如果知道該項可能允許的范圍，就按“最小值：最大值”的形式寫在花
　　括號前。
　　8. 分析模型
　　這是一個可選部分，包括或涉及到相關的分析模型，例如：
　　● 數據流程圖；
　　● 類圖；
　　● 狀態轉換圖；
　　● 實體-關系圖。
　　9. 待定問題列表
　　編輯一張在軟件產品需求分析報告中待確定問題時的列表，把每一個表項都編上號，以便跟蹤調查。

最新內容請見作者的GitHub頁：http://qaseven.github.io/

總結

以上是生活随笔為你收集整理的软件产品需求分析模板的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。