完整版軟件需求分析報告模板需求文檔模板 _經驗分享

產品需求文檔模板首先告訴你產品需求文檔肯定是有的！一個經過實際工作檢驗、經歷過“質疑”、“挑戰”和“斗爭”之后沉淀下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標準化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種“標準”的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。
不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，并在此過程中形成自己對于模板的理解，進而形成對于產品需求文檔的理解，在理解中使用，裁剪和優化。
要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：
一、描述-解釋-預測-監控
描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。
解釋，是回答 “為什么”，是對于描述的理解、歸類、定義和解釋。其目標是將描述內容背后的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對于描述內容有更清晰、更細致、全面的了解。
預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，準確地表達內在聯系，從中推導出正確的預測。
監控，是對于預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而采取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的“響應”機制，并任其自然發生或者通過提供“系統”的自制能力來實現。
二、需求準備、編寫和檢查
回歸到產品經理的日常工作中，在時間占比上較為集中的就是產品需求管理了，包括了需求的準備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，并可以幫助理解、形成并固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。
1. 描述
描述的過程是客觀的進行“需求向”描述的過程，是一個“背景”信息的補充，用來說明，這個需求文檔的源出是什么，是針對什么問題，這個問題是在具體什么領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什么，參與者是怎么解決的，解決的情況怎么樣，是好，還是不好，還是勉強可以，對于新的需求的緊迫性是什么樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和“溝通字典”，避免在溝通中因為誤解而產生不必要的偏差。
需求準備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；
需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；
需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干系人角色和影響范圍；
需求檢查的過程：需求的背景、目標、過程、干系人、結果預測和預防的完整性檢查；
2. 解釋
解釋在需求來源的基礎上描述了 “為什么”接下來這個需求可以解決遇到的問題，同時還加入了“是什么”和“怎么樣”的部分。就是這個需求是通過怎么樣的方法解決了“描述”過程中提到的問題，這個新的解決方法需要要做什么，對于原有的業務過程有哪些改變，會提升什么，會降低什么，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上占比最大的一部分。
這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對于運營的影響，對于前端市場的影響，對于用戶的影響，對于財務、法務的影響；從技術開發、技術實現維度，比如對于前端開發的影響、對于服務端開發的影響、對于數據平臺的影響，還可能涉及到對于運維資源的影響等；因此對應到實際的產品需求工作中：
需求準備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；
需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；
需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與后服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先級；系統架構、干系人角色和影響范圍；
需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；
【完整版軟件需求分析報告模板需求文檔模板】3. 預測與監控
預測與監控在產品需求文檔的管理上是聯動的，是對于預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對于設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 “非規劃”的使用，也就是我們通常說的“用戶并不總是按照產品設計的方式來使用產品，而且，往往相反。”因此，這部分內容很大的比例需要來對于用戶的行為進行預測和監控，并提供“預防”或者“解決”方案。其中：
預防在于，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最后操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多采用導航、提示等，不同的系統都有各自標準化的控價，我們在這里不做展開。
解決在于，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了“非標”、“超規”使用“掉出”原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來“回轉”用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過“導航”引導“跳轉”和“返回”、“回退”來實現。對應到實際的產品需求工作中：
需求準備的過程：了解用戶特征和使用水平、評估、比較不同方式實現需求對于用戶行為的可控性和“非常規”操作的危害程度；
需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；
需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；
需求檢查的過程：需求“異常”流程和相應引導、控制地完整性檢查；
在需求管理的過程中，就可以按照這個描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之后的檢查。
四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標準。所謂標準文檔，就可以按照這四個模塊作為框架、內容和格式。
寫在最后
產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，并最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。
需求工程過程中可能產生的文檔有需求工程過程中可能產生的文檔有：
A、前景和范圍文檔
B、用例使用說明文檔
C、需求規格說明文檔
大部分場景下需求提出方和需求承接方都存在不小的信息差，需求提出方常用的語句是“我需要做成這樣”、“越快越好”、“怎么用你不用管，給我就行”、“這不是我想要的”、“我想要的其實是那樣” 。
一百種需求有一千種提法，但需求中的事項相差卻無幾。這里給出了一份需求文檔模板，大家可以將其用在工作當中，作為不同人員之間的信息傳遞媒介。
要注意的是，需求和執行是雙生相伴的，因此這里的下面這份參照文檔與其說是需求文檔，不如說是任務執行記錄，因為它記錄著這個任務從產生到執行完畢的完整生命周期。
軟件工程需求分析的模板需求規格說明闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的
基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟件需求規格說明不應該包括設計、構造、測試或工程管理的細
節。
1)采用軟件需求規格說明模版:
采用需求規格說明書模板在你的組織中要為編寫軟件需求文檔定義一種標準模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統一的結構。注
意，其目的并非是創建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。許多組織一開始都采用IEEE標準
830-1998(IEEE 1998)描述的需求規格說明書模板。要相信模板是很有用的，但有時要根據項目特點進行適當的改動。
1
2
3
4
5
6
A引言
目的
文檔約定
預期的讀者和閱讀建議
產品的范圍
參考文獻
B綜合描述
產品的前景
產品的功能
用戶類和特征
運行環境
設計和實現上的限制
假設和依賴附錄
C外部接口需求附錄
用戶界面附錄
硬件接口
軟件接口
通信接口
D系統特性
說明和優先級
激勵/響應序列
功能需求
E 其它非功能需求
性能需求
安全設施需求
安全性需求
軟件質量屬性
業務規則
用戶文檔
F其它需求
G附件
詞匯表
分析模型
待確定問題的列表
表2 需求規格說明模板
a. 引言
引言提出了對軟件需求規格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。
a . 1 目的
對產品進行定義，在該文檔中詳盡說明了這個產品的軟件需求，包括修正或發行版本號。如果這個軟件需求規格說明只與整個系統的一部分有關系，那么就只定義文檔中說明的部分或子系統。
a.2 文檔約定
描述編寫文檔時所采用的標準或排版約定，包括正文風格、提示區或重要符號。
a.3 預期的讀者和閱讀建議
列舉了軟件需求規格說明所針對的不同讀者，例如開發人員、項目經理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩余部分的內容及其組織結構。提出了最適合于每一類型讀者閱讀文檔的建議。
a.4 產品的范圍
提供了對指定的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業目標或業務策略相聯系。可以參考項目視圖和范圍文檔而不是將其內容復制到這里。
用戶需求說明書文檔模板怎么編寫？用戶需求說明書模板文檔標識：當前版本：1.0當前狀態：草稿發布日期：2009-1-1發布ü修改歷史日期版本作者修改內容評審號變更控制號目錄1 引言... 31.1 編寫目的... 31.2 項目背景... 31.3 術語定義... 31.4 參考資料... 32 綜合描述... 32.1 產品介紹... 32.2 目標范圍... 32.3 用戶特性... 42.4 約定假設... 43 用戶需求（可剪裁）... 43.1 總體需求（可剪裁）... 43.2 內容需求（可剪裁）... 54 功能需求... 54.1 數據需求（可剪裁）... 54.2 接口需求（可剪裁）... 64.3 權限控制需求（可剪裁）... 64.3.1 系統安全要求（軟硬件）... 64.3.2 用戶角色... 64.3.3 角色權限控制... 65 非功能需求... 65.1 用戶界面需求（可剪裁）... 65.2 性能需求（可剪裁）... 75.3 壓力需求（可剪裁）... 75.4 主流技術應用需求（可剪裁）... 75.5 安全需求（可剪裁）... 75.6 故障處理需求（可剪裁）... 75.7 環境需求（可剪裁）... 75.8 產品質量需求... 75.9 其他需求（可剪裁）... 86 需求優先級... 87 附加說明（可剪裁）... 81 引言 1.1 編寫目的本節描述編寫該用戶需求說明書的目的，并指出預期的讀者。1.2 項目背景本節描述用戶需求說明書中所定義的產品的背景和起源，以及同其他系統或其他機構的基本相互關系等。當在已有的系統上進行特性開發時，如果新特性與已有系統的特性之間存在關系，則應在本節說明其相互之間的關系。1.3 術語定義本節可列出本文件中用到的專門術語的定義、外文首字母組詞的原詞組等。1.4 參考資料本節列舉編寫用戶需求說明書時所參考的資料或其他資源，這可能包括用戶合同、公司規范、技術書籍等。在這里應該給出詳細的信息，包括資料名稱、版本號、作者、日期、出版單位或資料來源，以方便讀者查閱這些文獻，可用以下格式表示：資料名稱版本號作者日期出版單位/資料來源備注2 綜合描述 2.1 產品介紹本節簡要描述產品的特性。2.2 目標范圍本節簡要描述產品的應用目標、作用范圍等。2.3 用戶特性本節可能包括本產品各類最終用戶的特點，如操作、維護等人員的知識水平和技術專長等，也可能包括用戶組織關系結構圖以及組織、部門、崗位的隸屬關系與職能。這將是后續工作的重要依賴條件。2.4 約定假設本節列舉出在對軟件用戶需求說明書中影響需求陳述的假設因素（與已知因素相對立）。這可能包括將要使用的組件、特殊的用戶界面設計約定、產品預期使用頻度等。如果這些假設不正確、不一致或被更改，就會使項目受到影響。3 用戶需求（可剪裁）每一項需求必須進行唯一標識，并給出該項需求的優先級。需求優先級的定義，一般需要根據用戶意見結合商業價值、交付成本、交付日期、復雜程度、風險等因素來進行考慮。高優先級需求表示本系統產品中必須實現的需求，中優先級需求表示必須但是根據時間情況有可能會被推遲到下一版本的產品中去實現的需求，低優先級需求表示如果沒有充足的時間或資源就可以被放棄的需求。具體描述請參考《需求跟蹤矩陣》！需求編號方式可以根據項目實際情況進行自定義，也可以采用“項目代號”＋“-”＋“R”＋“需求類型”＋“序號”的形式。其中“R”表示Requirement，“需求類型”可用下表表示，“序號”以自然數表示，位數不限。需求類型英文名稱中文名稱FFunction功能PPerformance性能DData數據UUser Interface用戶界面IInterface接口SSecurity安全MMalfunction故障處理OOther其他示例：OLTP-RI5表示為OLTP項目的第5項用戶界面需求。3.1 總體需求（可剪裁）描述項目總體需求，簡述項目特性等內容。3.2 內容需求（可剪裁）按照內容（如產品包、組件等）展開用戶需求。4 功能需求詳細列出系統各模塊/主題/子系統的功能需求。提示：將功能性需求先粗分再細分，下表中的 Feature A, Function A.1等符號應當被替換成有含義的名稱（可考慮加上需求的優先級別）。在描述中要簡要闡述該需求項將依賴于哪些需求項。功能類別標識符子功能名稱描述Feature AFunction A.1…Feature BFunction B.1…Feature CFunction C.1…產品包提示：針對本功能進行說明描述（包含其要做什么、什么流程、相關的財務、特殊要求、需要的數據等），可以采用相關的圖表來更容易地表達信息。① 功能描述：描述需求項的功能。② 業務描述：描述該需求項的業務流程、相關的對象的狀態、涉及到的業務角色等。③ 數據描述：描述需求項的數據項、數據精度、輸出的格式等要求。④ 輸入描述：描述該需求項的相關依賴（包括業務依賴和需求項的依賴）和輸入條件。⑤ 輸出描述：描述需求功能執行后，相應的輸出產物、數據、對象狀態等。4.1 數據需求（可剪裁）詳細列出系統的數據需求，可能包括數據類型、載體、格式、數值范圍、精度、規模等需求。4.2 接口需求（可剪裁）詳細列出系統的接口需求，可能包括與其他系統之間的接口、數據通信協議、內部模塊之間的接口等需求。4.3 權限控制需求（可剪裁） 4.3.1 系統安全要求（軟硬件）提示：說明對本產品系統的功能方面的安全的要求，如用戶名密碼加密、系統訪問安全等。4.3.2 用戶角色提示：闡述本產品的各種角色及其職責。各種角色的具體行為將在功能性需求中描述。角色例如：系統管理員（SuperAdmin-Lowest Level）內部操作管理員（OperatorAdmin-Mid Level）外部操作管理員（ResellerAdmin-Midhigh Level）終端用戶管理員（UserAdmin – High Level）角色名稱職責描述4.3.3 角色權限控制提示：描述上述各用戶角色的權限控制要求5 非功能需求 5.1 用戶界面需求（可剪裁）詳細列出系統的界面需求，可能包括圖形用戶界面標準、產品系統風格、屏幕布局或解決方案的限制、快捷鍵、錯誤信息顯示標準等。5.2 性能需求（可剪裁）詳細列出系統的性能需求，可能包括時間特性要求、軟件靈活性、容錯性、容量需求等。提示：說明本產品的整體性能必須達到程度，特別是一些關鍵功能點。5.3 壓力需求（可剪裁）提示：說明本產品使用必須滿足的壓力峰值要求5.4 主流技術應用需求（可剪裁）提示：說明本產品需要使用何種主流技術。如果不清楚或不明白可以不填后面由項目開發組提出技術方案再進行選擇。5.5 安全需求（可剪裁）詳細列出系統的安全需求，可能包括安全設施需求和安全性需求等。安全設施需求是指產品使用過程中可能發生的，與損失、破壞或危害相關的需求。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產品必須遵從的安全標準、策略或準則。一個安全設施需求的范例如下：“如果油箱的壓力超過了規定的最大壓力的95%，那么必須在1秒鐘內終止操作” 。安全性需求是指與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創建或使用的數據的保護。定義用戶身份確認或授權需求。明確產品必須滿足的安全性或保密性策略。一個安全性需求的范例如下：“每個用戶在第一次登錄后，必須更改他的最初登錄密碼。最初的登錄密碼不能重用。5.6 故障處理需求（可剪裁）詳細列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。5.7 環境需求（可剪裁）詳細列出各種環境需求，可能包括開發環境、測試環境、運行環境等需求。具體內容可能涉及到網絡、服務器、數據庫、前臺、測試工具等的軟件、硬件方面。5.8 產品質量需求描述產品預期達到的質量要求，包括多個質量特性，以下的質量屬性僅為參考，各項目可以根據需要補充或刪除某些質量特性。主要質量屬性詳細需求正確性可靠性健壯性性能、效率易用性清晰性安全性可擴展性兼容性可移植性 … 5.9 其他需求（可剪裁）詳細列出在前文中沒有包括的所有需求，可能包括用戶對可維護性、可補充性、易讀性、可移植性等方面的特殊需求，或者國際化或法律上的需求。6 需求優先級根據用戶的需要程度，初步列出各需求的優先級，參見《需求跟蹤矩陣》。7 附加說明（可剪裁）描述該用戶需求說明書采集的方法，如訪談、現場體驗、慣例綜合等。參見的競爭產品和相應的用戶需求獲取文檔，如用戶故事、需求采集表等類似文檔。Download: template-requirement-analysis.rarREF:http://www.mspsw.cn/wp-content/upload_s/2009/06/requirement-analysis-template.doc軟件設計文檔國家標準(GB8567--88)GB8567——88
項目需求怎么寫?(java web)A、三種編寫方法
1、用好的結構化和自然語言編寫文本型文檔；
2、建立圖形化模型，這些模型可以描繪轉換過程、系統狀態、和它們之間的變化、數據關系、邏輯流或對象類和他們的關系；
3、編寫形式化規格說明，這可以通過使用數學上精確的形式化邏輯語言來定義需求。
多種編寫方法可在同一個文檔使用，根據需要選擇，或互為補充，以能夠把需求說明白為目的。
B、應有成果
　1、各業務手工辦理流程文字說明；
　2、各業務手工辦理流程圖；
　3、各業務手工辦理各環節輸入輸出表單、數據來源；
　4、目標軟件系統功能劃分（示意圖及文字說明）；
　5、目標軟件系統中各業務辦理流程文字說明；
　6、目標軟件系統中各業務辦理流程圖（模型）；
　7、目標軟件系統中各業務辦理各環節數據、數據采集方式、數據間的內在聯系分析。
　8、目標軟件系統用戶界面圖、各式系統邏輯模型圖及說明
C、文檔工具推薦
　1、調研結果《需求分析說明書》格式參照開發文檔模板；
　2、單位組織結構圖、功能模塊分解圖用VISIO繪制，或直接用WORD中的畫圖工具；
　3、業務流程圖用VISIO中的FLOWCHART模板繪制；
　4、系統邏輯模型使用ROSE繪制活用VISIO中的UML模板繪制；
　5、軟件用戶界面用VISIO中的WIN95 USER INTERFACE模板繪制；
　6、數據物理模型用POWERDESINER繪制；
D、需求文檔編寫原則
　1、句子簡短完整，具有正確的語法、拼寫和標點；
　2、使用的術語與詞匯表中所定義的一致；
　3、需求陳述應該有一致的樣式，例如“系統必須..”或者“用戶必須..”，并緊跟一個行為動作和可觀察的結果。；
　4、避免使用模糊、主觀的術語，減少不確定性，如“界面友好、操作方便”；
　5、避免使用比較性詞語，如“提高”，應定量說明提高程度
軟件需求分析報告模板(完整版)軟件需求分析報告文檔;
軟件概要設計報告文檔;
軟件詳細設計報告文檔;
軟件數據庫設計報告文檔;
軟件測試（驗收）大綱hi.gta123如有幫助，別忘了采納喲！goto365testing,測評網,
關于需求文檔模板和的內容就分享到這兒！更多實用知識經驗，盡在 m.apearl.cn

完整版 軟件需求分析報告模板 需求文檔模板

完整版軟件需求分析報告模板需求文檔模板