今天給各位分享用戶需求文檔模板的知識，其中也會對用戶需求書是什么意思進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關注本站，現(xiàn)在開始吧！

本文目錄一覽：

• 1、如何寫一份易用的產(chǎn)品需求文檔？
• 2、產(chǎn)品需求文檔模板
• 3、產(chǎn)品需求說明書 模板
• 4、用戶需求說明書文檔模板怎么編寫？

如何寫一份易用的產(chǎn)品需求文檔？

產(chǎn)品需求文檔分很多種，這里我只說一種讓程序員看起來舒服的需求文檔格式吧：

作為程序員，在需求文檔當中，最關注的內容是哪幾種呢？

1、流程：包括業(yè)務流程和基本流程；

2、數(shù)據(jù)：包括輸入數(shù)據(jù)和展示數(shù)據(jù)；

3、事件流：特別是分支事件流和例外事件流，感覺很多需求文檔中，缺少了這部分；

那么，文檔的模板是怎么樣的呢？

1、需求說明：主要闡述為什么要做這個需求；

2、業(yè)務流程：最好使用VISIO來繪制，畫出整個業(yè)務的流程圖，特別是其中所要涉及的判定，分支等，都要畫出來，越詳細越好；

3、基本流程：繼續(xù)使用VISIO，畫出基本流程即可，一般來說都是業(yè)務流程中的最主要部分，但是可以加入更多的細節(jié)；

4、分支事件流：VISIO，各種分支事件的詳細流程，越詳細越好；

5、例外事件流：這里要使用表格，示例如下：主要是系統(tǒng)判定和對應的提示；6、輸入數(shù)據(jù)：用戶可以輸入數(shù)據(jù)的字段，已經(jīng)相應的定義，包括是否必填，字段長度，錄入方式，對應規(guī)則等；

7、顯示數(shù)據(jù)：頁面顯示給用戶的數(shù)據(jù)，對應的字段，取數(shù)規(guī)則，對應規(guī)則等;

8、補充說明；這個需求文檔模板，更傾向于傳統(tǒng)的軟件模板，而不是網(wǎng)絡上比較流行的AXURE文檔。

產(chǎn)品需求文檔模板

首先告訴你產(chǎn)品需求文檔肯定是有的！一個經(jīng)過實際工作檢驗、經(jīng)歷過“質疑”、“挑戰(zhàn)”和“斗爭”之后沉淀下來的模板，肯定是已經(jīng)吸收了各類人的偏好、意見，固化了很多符合實際業(yè)務必須的內容要求，能夠起到很好的業(yè)務承接作用。格式化、標準化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種“標準”的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。

不過，在享受別人智力和經(jīng)驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，并在此過程中形成自己對于模板的理解，進而形成對于產(chǎn)品需求文檔的理解，在理解中使用，裁剪和優(yōu)化。

要理解和分析模板，理解和分析產(chǎn)品需求文檔，可以運用以下幾個方法：

一、描述-解釋-預測-監(jiān)控

描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據(jù)自己的觀察得到的現(xiàn)象、由此現(xiàn)象所產(chǎn)生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現(xiàn)象的反應等信息進行描述。

解釋，是回答 “為什么”，是對于描述的理解、歸類、定義和解釋。其目標是將描述內容背后的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對于描述內容有更清晰、更細致、全面的了解。

預測，根據(jù)以因果關系為內容的內在聯(lián)系，相互影響來推導未來的發(fā)展或者將要發(fā)生的事情。通過研究解釋內在的聯(lián)系，準確地表達內在聯(lián)系，從中推導出正確的預測。

監(jiān)控，是對于預測行為、現(xiàn)象的觀察和監(jiān)督，包括了觀察到的預測中的行為、現(xiàn)象的發(fā)生或者預測以外的行為、現(xiàn)象的外發(fā)生，以及因此而采取的對應的反映動作；這些反映動作是預測過程中根據(jù)內在聯(lián)系制定的“響應”機制，并任其自然發(fā)生或者通過提供“系統(tǒng)”的自制能力來實現(xiàn)。

二、需求準備、編寫和檢查

回歸到產(chǎn)品經(jīng)理的日常工作中，在時間占比上較為集中的就是產(chǎn)品需求管理了，包括了需求的準備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監(jiān)控這個通用的科學分析過程也同樣使用，且可以貫穿其中，并可以幫助理解、形成并固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。

1. 描述

描述的過程是客觀的進行“需求向”描述的過程，是一個“背景”信息的補充，用來說明，這個需求文檔的源出是什么，是針對什么問題，這個問題是在具體什么領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現(xiàn)之前，當前的解決方案存在的問題是什么，參與者是怎么解決的，解決的情況怎么樣，是好，還是不好，還是勉強可以，對于新的需求的緊迫性是什么樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統(tǒng)一作為背景去理解一個現(xiàn)實的業(yè)務場景和“溝通字典”，避免在溝通中因為誤解而產(chǎn)生不必要的偏差。

需求準備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業(yè)、同業(yè)規(guī)則現(xiàn)狀等）；

需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；

需求編寫的過程：描述需求目的、背景、時間和結果要求、業(yè)務流程、交互過程、系統(tǒng)架構、干系人角色和影響范圍；

需求檢查的過程：需求的背景、目標、過程、干系人、結果預測和預防的完整性檢查；

2. 解釋

解釋在需求來源的基礎上描述了 “為什么”接下來這個需求可以解決遇到的問題，同時還加入了“是什么”和“怎么樣”的部分。就是這個需求是通過怎么樣的方法解決了“描述”過程中提到的問題，這個新的解決方法需要要做什么，對于原有的業(yè)務過程有哪些改變，會提升什么，會降低什么，會影響哪些人、哪些業(yè)務部分、哪些業(yè)務系統(tǒng)以及哪些數(shù)據(jù)的產(chǎn)生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上占比最大的一部分。

這里的解釋根據(jù)產(chǎn)品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對于運營的影響，對于前端市場的影響，對于用戶的影響，對于財務、法務的影響；從技術開發(fā)、技術實現(xiàn)維度，比如對于前端開發(fā)的影響、對于服務端開發(fā)的影響、對于數(shù)據(jù)平臺的影響，還可能涉及到對于運維資源的影響等；因此對應到實際的產(chǎn)品需求工作中：

需求準備的過程：了解需求可能涉及的相關業(yè)務系統(tǒng)及系統(tǒng)對應的數(shù)據(jù)流程和邏輯、了解需求可能涉及的外部服務的數(shù)據(jù)流程和邏輯；了解面向的內外部用戶的產(chǎn)品使用水平、學習能力和使用習慣；

需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；

需求編寫的過程：詳細描述需求的業(yè)務流程，通過各種圖表格式說明新的解決方法在各服務系統(tǒng)之間、各業(yè)務部門之間、用戶與產(chǎn)品，產(chǎn)品與后服務之間的數(shù)據(jù)、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業(yè)務節(jié)點明確的輸出物和節(jié)點標志，重要性和優(yōu)先級；系統(tǒng)架構、干系人角色和影響范圍；

需求檢查的過程：需求的流程、用戶交互動作、系統(tǒng)信息交互等完整性檢查；

3. 預測與監(jiān)控

預測與監(jiān)控在產(chǎn)品需求文檔的管理上是聯(lián)動的，是對于預測的事件發(fā)生的時候，進行管理的機制，監(jiān)控=預測+干預。在產(chǎn)品需求文檔的管理上，對于設計好的業(yè)務流程、使用功能，在實際過程中可能會出現(xiàn)這樣或者那樣的 “非規(guī)劃”的使用，也就是我們通常說的“用戶并不總是按照產(chǎn)品設計的方式來使用產(chǎn)品，而且，往往相反。”因此，這部分內容很大的比例需要來對于用戶的行為進行預測和監(jiān)控，并提供“預防”或者“解決”方案。其中：

預防在于，預測產(chǎn)品的用戶在使用的過程中，可能會進行的一些超過產(chǎn)品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業(yè)務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產(chǎn)品、功能沒有包容性，缺乏引導性，導致了最后操作的失敗，預想的結果沒有實現(xiàn)，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多采用導航、提示等，不同的系統(tǒng)都有各自標準化的控價，我們在這里不做展開。

解決在于，預測產(chǎn)品的用戶在使用產(chǎn)品的過程中，因誤解、操作手誤而進行了“非標”、“超規(guī)”使用“掉出”原本設計的業(yè)務流程和操作流程的情況下，需要提供額外的流程和控制來“回轉”用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過“導航”引導“跳轉”和“返回”、“回退”來實現(xiàn)。對應到實際的產(chǎn)品需求工作中：

需求準備的過程：了解用戶特征和使用水平、評估、比較不同方式實現(xiàn)需求對于用戶行為的可控性和“非常規(guī)”操作的危害程度；

需求分析的過程：選擇和確定需求實現(xiàn)方案，評估行為管理方式和管理機制；

需求編寫的過程：詳細描述需求的業(yè)務流程和交互過程中可能出現(xiàn)的用戶異常操作，相應異常操作中系統(tǒng)反應，系統(tǒng)對應的控制和引導；

需求檢查的過程：需求“異?！绷鞒毯拖鄳龑?、控制地完整性檢查；

在需求管理的過程中，就可以按照這個 描述——解釋——預測——監(jiān)控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之后的檢查。

四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標準。所謂標準文檔，就可以按照這四個模塊作為框架、內容和格式。

寫在最后

產(chǎn)品需求文檔作為產(chǎn)品經(jīng)理同視覺設計、交互設計以及技術開發(fā)人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創(chuàng)作。一個完整的、充分溝通確認，并最終達成多方理解和共識的產(chǎn)品需求文檔，能夠最大限度的還原產(chǎn)品、功能的設計，保證產(chǎn)品、功能的實現(xiàn)，最大限度的減少因為各方理解的偏差而造成的時間、人力和經(jīng)濟資源的浪費及復工。

產(chǎn)品需求說明書 模板

新人建議收藏

鏈接：

?密碼：r1an

文檔版本號：?1.0文檔編號：2018080910

文檔密級：僅限項目組歸屬部門/項目：

產(chǎn)品名：?子系統(tǒng)名：

編寫人：Xxx編寫日期：

修訂記錄：

版本號??修訂人??修訂日期??修訂描述

V?1.0

目錄

一、?簡介????4

1、?目的?4

2、?范圍?4

二、?用戶角色描述????4

三、?產(chǎn)品概述????4

1、?目標?4

2、?總體流程?4

3、?功能摘要?4

四、?產(chǎn)品特性????5

1、?第一部分??功能模塊1?5

1.1產(chǎn)品概述?5

1.2產(chǎn)品結構（功能摘要）?5

1.3狀態(tài)說明?5

1.4特性說明?6

1.4.1特性1：功能點1?6

1.4.2特性2：功能點2?9

2、?第二部分??功能模塊2?9

2.1產(chǎn)品概述?9

2.2產(chǎn)品結構（功能摘要）?9

2.3狀態(tài)說明?9

2.4特性說明?9

2.4.1特性1：功能點1?9

2.4.2特性2：功能點2?10

五、?其它產(chǎn)品需求????10

1、?性能需求?10

2、?監(jiān)控需求?11

3、?兼容性需求?11

六、?風險分析????11

七、?相關文檔????11

八、?附件????11

[if?!supportLists]一、?[endif]?簡介

[?產(chǎn)品需求說明書?文檔的簡介應提供整個文檔的概述。它應包括此?產(chǎn)品需求說明書?文檔的目的、范圍、定義、首字母縮寫詞、縮略語、參考資料和概述。]

[if?!supportLists]1、?[endif]?目的

[闡明此產(chǎn)品需求說明書文檔的目的，如：

本文檔為“陌生視界v1.0.0”的產(chǎn)品需求文檔，主要作為確認需求以及系統(tǒng)分析設計的依據(jù)。]

[if?!supportLists]2、?[endif]?范圍

[簡要說明此產(chǎn)品需求說明書文檔的范圍、它的相關產(chǎn)品，以及受到此文檔影響的任何其他事物。]

[if?!supportLists]二、?[endif]?用戶角色描述

用戶角色用戶描述

[if?!supportLists]三、?[endif]?產(chǎn)品概述

[此節(jié)高度概括產(chǎn)品的功能與介紹]

[if?!supportLists]1、?[endif]???目標

[描述產(chǎn)品的目標]

[if?!supportLists]2、?[endif]?總體流程

[描述產(chǎn)品的總體流程圖]

[if?!supportLists]3、?[endif]?功能摘要

[簡要描述產(chǎn)品的功能點和每個功能點的優(yōu)先級，參考格式如下]

功能模塊主要功能點功能描述優(yōu)先級

功能模塊1功能點1?高

功能點2?中

功能模塊2功能點1?低

[if?!supportLists]四、?[endif]?產(chǎn)品特性

[列出產(chǎn)品的特性。特性是為讓用戶獲益而必須具備的高級系統(tǒng)功能。每一項特性都是外部所需的服務，它通常需要一系列輸入來實現(xiàn)預期的結果。

此節(jié)為設計的系統(tǒng)功能性需求,一般以用例結合自然語言來表達。此節(jié)通常按特性來組織，但也可能會有其他適用的組織方式，例如按用戶或子系統(tǒng)組織的方式。

這一節(jié)應包含所有的產(chǎn)品需求，其詳細程度應使架構設計人員和軟件需求設計人員能夠設計出可以滿足這些需求的系統(tǒng)，不包括可選流程和異常流程，不對具體語義做約束。]

[if?!supportLists]1、?[endif]?第一部分??功能模塊1

[if?!supportLists]1.1?[endif]?產(chǎn)品概述

[概述功能模塊1的產(chǎn)品特性及效果]

[if?!supportLists]1.2?[endif]?產(chǎn)品??結構（功能摘要）

[概述功能模塊1的產(chǎn)品結構或包含組件，如：

[if?!supportLists]1)?[endif]播放區(qū)：播放區(qū)定義及功能說明；

[if?!supportLists]2)?[endif]緩沖區(qū)：緩沖區(qū)定義及功能說明；

[if?!supportLists]3)?[endif]播放列表區(qū)：播放列表區(qū)定義及功能說明；]

[if?!supportLists]1.3?[endif]?狀態(tài)說明

[列出產(chǎn)品的各種狀態(tài)及狀態(tài)轉換圖，如：

[if?!supportLists]1)?[endif]狀態(tài)1：狀態(tài)1定義及可執(zhí)行操作說明；

[if?!supportLists]2)?[endif]狀態(tài)2：狀態(tài)2定義及可執(zhí)行操作說明；

狀態(tài)轉換圖：

]

[if?!supportLists]1.4?[endif]?特性??說明

[if?!supportLists]1.4.1?[endif]?特性1：功能點1

用戶場景：

[列出用戶通過什么操作或途徑觸發(fā)功能點1，如：

用戶點擊大學生社區(qū)—行政樓，或者點擊其他引導到該板塊的鏈接]

輸入??/??前置條件：

[列出用戶觸發(fā)功能點1的前置條件和必要條件，如：

用戶已登錄，且為社團成員]

流程說明：?（用例圖、流程圖）

[通過用例圖、流程圖的形式，對功能點1的流程進行說明，如：

]

需求描述：

[詳細描述功能點1的具體需求，包括約束條件、輸入輸出、排序規(guī)則、狀態(tài)轉換等等，如：

當用戶點擊“行政樓”菜單時，展示學校的新聞中心和管理層介紹，大致示意圖如下：

行政樓主要版塊包括：

[if?!supportLists]1.?[endif]新聞發(fā)布中心

新聞發(fā)布中心主要展示編輯后臺發(fā)布的校園新聞及系統(tǒng)公告；

列表形式按發(fā)布時間由近到遠順序展示，默認顯示前若干條（具體條數(shù)視最終頁面設計）]

補充??說明：

[相關需要特殊說明的補充事項]

[if?!supportLists]1.4.2?[endif]?特性??2：功能點2

用戶場景：

輸入\前置條件：

流程說明：?（用例圖、時序圖）

需求描述：

補充??說明：

[if?!supportLists]2、?[endif]?第??二??部分??功能模塊2

[if?!supportLists]2.1?[endif]?產(chǎn)品概述

[if?!supportLists]2.2?[endif]?產(chǎn)品??結構（功能摘要）

[if?!supportLists]2.3?[endif]?狀態(tài)說明

[if?!supportLists]2.4?[endif]?特性??說明

[if?!supportLists]2.4.1?[endif]?特性1：功能點1

用戶場景：

輸入\前置條件：

狀態(tài)說明??：

流程說明：?（用例圖、時序圖）

需求描述：

補充說明：

[if?!supportLists]2.4.2?[endif]?特性??2：功能點2

用戶場景：

輸入\前置條件：

狀態(tài)說明??：

流程說明：?（用例圖、時序圖）

需求描述：

補充說明：

[if?!supportLists]五、?[endif]???其它產(chǎn)品需求

[從業(yè)務視角提出各項可用性指標的大致需求。具體的技術指標會體現(xiàn)在產(chǎn)品的設計文檔中（根據(jù)項目實際情況增刪）]

[if?!supportLists]1、?[endif]???性能需求

[?如果產(chǎn)品對性能要特殊需求，請詳細描述，如：大致響應時間、最大并發(fā)數(shù)等。]

[if?!supportLists]2、?[endif]???監(jiān)控需求

[如果產(chǎn)品需要特殊的監(jiān)控和統(tǒng)計，請詳細描述，如：PV、點擊、登錄數(shù)等。]

[if?!supportLists]3、?[endif]?兼容性需求

[如果產(chǎn)品需要對兼容性提出特殊的需求，請詳細描述，如：兼容IE8、Chrome等。]

[if?!supportLists]六、?[endif]???風險分析

[風險內容描述，說明風險產(chǎn)生原因，可能造成的危害以及相應出現(xiàn)的頻率信息，另外在此處還需要描述相關風險預防措施及風險出現(xiàn)后的應對措施信息。此處不包括任何系統(tǒng)技術實現(xiàn)層面的風險，例如：系統(tǒng)的備份，監(jiān)控，模塊依賴，etc.]

風險可能性嚴重性應對策略可應對性

[if?!supportLists]七、?[endif]???相關文檔

[產(chǎn)品所需的其余相關文檔，如：產(chǎn)品市場需求說明書（MRD）、產(chǎn)品功能介紹PPT、產(chǎn)品規(guī)劃書。]

[if?!supportLists]八、?[endif]?附件

[將產(chǎn)品需求的demo作為附件。]

m

用戶需求說明書文檔模板怎么編寫？

用戶需求說明書模板 文檔標識：當前版本：1.0當前狀態(tài)：草稿發(fā)布日期：2009-1-1發(fā)布ü修改歷史日期版本作者修改內容評審號變更控制號目錄1 引言... 31.1 編寫目的... 31.2 項目背景... 31.3 術語定義... 31.4 參考資料... 32 綜合描述... 32.1 產(chǎn)品介紹... 32.2 目標范圍... 32.3 用戶特性... 42.4 約定假設... 43 用戶需求（可剪裁）... 43.1 總體需求（可剪裁）... 43.2 內容需求（可剪裁）... 54 功能需求... 54.1 數(shù)據(jù)需求（可剪裁）... 54.2 接口需求（可剪裁）... 64.3 權限控制需求（可剪裁）... 64.3.1 系統(tǒng)安全要求（軟硬件）... 64.3.2 用戶角色... 64.3.3 角色權限控制... 65 非功能需求... 65.1 用戶界面需求（可剪裁）... 65.2 性能需求（可剪裁）... 75.3 壓力需求（可剪裁）... 75.4 主流技術應用需求（可剪裁）... 75.5 安全需求（可剪裁）... 75.6 故障處理需求（可剪裁）... 75.7 環(huán)境需求（可剪裁）... 75.8 產(chǎn)品質量需求... 75.9 其他需求（可剪裁）... 86 需求優(yōu)先級... 87 附加說明（可剪裁）... 81 引言 1.1 編寫目的 本節(jié)描述編寫該用戶需求說明書的目的，并指出預期的讀者。1.2 項目背景 本節(jié)描述用戶需求說明書中所定義的產(chǎn)品的背景和起源，以及同其他系統(tǒng)或其他機構的基本相互關系等。當在已有的系統(tǒng)上進行特性開發(fā)時，如果新特性與已有系統(tǒng)的特性之間存在關系，則應在本節(jié)說明其相互之間的關系。1.3 術語定義 本節(jié)可列出本文件中用到的專門術語的定義、外文首字母組詞的原詞組等。1.4 參考資料 本節(jié)列舉編寫用戶需求說明書時所參考的資料或其他資源，這可能包括用戶合同、公司規(guī)范、技術書籍等。在這里應該給出詳細的信息，包括資料名稱、版本號、作者、日期、出版單位或資料來源，以方便讀者查閱這些文獻，可用以下格式表示： 資料名稱版本號作者日期出版單位/資料來源備注 2 綜合描述 2.1 產(chǎn)品介紹 本節(jié)簡要描述產(chǎn)品的特性。2.2 目標范圍 本節(jié)簡要描述產(chǎn)品的應用目標、作用范圍等。2.3 用戶特性 本節(jié)可能包括本產(chǎn)品各類最終用戶的特點，如操作、維護等人員的知識水平和技術專長等，也可能包括用戶組織關系結構圖以及組織、部門、崗位的隸屬關系與職能。這將是后續(xù)工作的重要依賴條件。2.4 約定假設 本節(jié)列舉出在對軟件用戶需求說明書中影響需求陳述的假設因素（與已知因素相對立）。這可能包括將要使用的組件、特殊的用戶界面設計約定、產(chǎn)品預期使用頻度等。如果這些假設不正確、不一致或被更改，就會使項目受到影響。3 用戶需求（可剪裁） 每一項需求必須進行唯一標識，并給出該項需求的優(yōu)先級。需求優(yōu)先級的定義，一般需要根據(jù)用戶意見結合商業(yè)價值、交付成本、交付日期、復雜程度、風險等因素來進行考慮。高優(yōu)先級需求表示本系統(tǒng)產(chǎn)品中必須實現(xiàn)的需求，中優(yōu)先級需求表示必須但是根據(jù)時間情況有可能會被推遲到下一版本的產(chǎn)品中去實現(xiàn)的需求，低優(yōu)先級需求表示如果沒有充足的時間或資源就可以被放棄的需求。具體描述請參考《需求跟蹤矩陣》！需求編號方式可以根據(jù)項目實際情況進行自定義，也可以采用“項目代號”＋“-”＋“R”＋“需求類型”＋“序號”的形式。其中“R”表示Requirement，“需求類型”可用下表表示，“序號”以自然數(shù)表示，位數(shù)不限。 需求類型英文名稱中文名稱FFunction功能PPerformance性能DData數(shù)據(jù)UUser Interface用戶界面IInterface接口SSecurity安全MMalfunction故障處理OOther其他示例：OLTP-RI5表示為OLTP項目的第5項用戶界面需求。3.1 總體需求（可剪裁） 描述項目總體需求，簡述項目特性等內容。3.2 內容需求（可剪裁） 按照內容（如產(chǎn)品包、組件等）展開用戶需求。4 功能需求 詳細列出系統(tǒng)各模塊/主題/子系統(tǒng)的功能需求。提示：將功能性需求先粗分再細分，下表中的 Feature A, Function A.1等符號應當被替換成有含義的名稱（可考慮加上需求的優(yōu)先級別）。在描述中要簡要闡述該需求項將依賴于哪些需求項。 功能類別標識符子功能名稱描述Feature AFunction A.1…Feature BFunction B.1…Feature CFunction C.1…產(chǎn)品包提示：針對本功能進行說明描述（包含其要做什么、什么流程、相關的財務、特殊要求、需要的數(shù)據(jù)等），可以采用相關的圖表來更容易地表達信息。① 功能描述：描述需求項的功能。② 業(yè)務描述：描述該需求項的業(yè)務流程、相關的對象的狀態(tài)、涉及到的業(yè)務角色等。③ 數(shù)據(jù)描述：描述需求項的數(shù)據(jù)項、數(shù)據(jù)精度、輸出的格式等要求。④ 輸入描述：描述該需求項的相關依賴（包括業(yè)務依賴和需求項的依賴）和輸入條件。⑤ 輸出描述：描述需求功能執(zhí)行后，相應的輸出產(chǎn)物、數(shù)據(jù)、對象狀態(tài)等。4.1 數(shù)據(jù)需求（可剪裁） 詳細列出系統(tǒng)的數(shù)據(jù)需求，可能包括數(shù)據(jù)類型、載體、格式、數(shù)值范圍、精度、規(guī)模等需求。4.2 接口需求（可剪裁） 詳細列出系統(tǒng)的接口需求，可能包括與其他系統(tǒng)之間的接口、數(shù)據(jù)通信協(xié)議、內部模塊之間的接口等需求。4.3 權限控制需求（可剪裁） 4.3.1 系統(tǒng)安全要求（軟硬件） 提示：說明對本產(chǎn)品系統(tǒng)的功能方面的安全的要求，如用戶名密碼加密、系統(tǒng)訪問安全等。4.3.2 用戶角色 提示：闡述本產(chǎn)品的各種角色及其職責。各種角色的具體行為將在功能性需求中描述。角色例如：系統(tǒng)管理員（SuperAdmin-Lowest Level）內部操作管理員（OperatorAdmin-Mid Level）外部操作管理員（ResellerAdmin-Midhigh Level）終端用戶管理員（UserAdmin – High Level） 角色名稱職責描述 4.3.3 角色權限控制 提示：描述上述各用戶角色的權限控制要求5 非功能需求 5.1 用戶界面需求（可剪裁） 詳細列出系統(tǒng)的界面需求，可能包括圖形用戶界面標準、產(chǎn)品系統(tǒng)風格、屏幕布局或解決方案的限制、快捷鍵、錯誤信息顯示標準等。5.2 性能需求（可剪裁） 詳細列出系統(tǒng)的性能需求，可能包括時間特性要求、軟件靈活性、容錯性、容量需求等。提示：說明本產(chǎn)品的整體性能必須達到程度，特別是一些關鍵功能點。5.3 壓力需求（可剪裁） 提示：說明本產(chǎn)品使用必須滿足的壓力峰值要求5.4 主流技術應用需求（可剪裁） 提示：說明本產(chǎn)品需要使用何種主流技術。如果不清楚或不明白可以不填后面由項目開發(fā)組提出技術方案再進行選擇。5.5 安全需求（可剪裁） 詳細列出系統(tǒng)的安全需求，可能包括安全設施需求和安全性需求等。安全設施需求是指產(chǎn)品使用過程中可能發(fā)生的，與損失、破壞或危害相關的需求。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產(chǎn)品必須遵從的安全標準、策略或準則。一個安全設施需求的范例如下：“如果油箱的壓力超過了規(guī)定的最大壓力的95%，那么必須在1秒鐘內終止操作”。安全性需求是指與系統(tǒng)安全性、完整性或與私人問題相關的需求，這些問題將會影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的數(shù)據(jù)的保護。定義用戶身份確認或授權需求。明確產(chǎn)品必須滿足的安全性或保密性策略。一個安全性需求的范例如下：“每個用戶在第一次登錄后，必須更改他的最初登錄密碼。最初的登錄密碼不能重用。5.6 故障處理需求（可剪裁） 詳細列出可能的軟件、硬件故障以及對各項性能而言所產(chǎn)生的后果和對故障處理的要求。5.7 環(huán)境需求（可剪裁） 詳細列出各種環(huán)境需求，可能包括開發(fā)環(huán)境、測試環(huán)境、運行環(huán)境等需求。具體內容可能涉及到網(wǎng)絡、服務器、數(shù)據(jù)庫、前臺、測試工具等的軟件、硬件方面。5.8 產(chǎn)品質量需求 描述產(chǎn)品預期達到的質量要求，包括多個質量特性，以下的質量屬性僅為參考，各項目可以根據(jù)需要補充或刪除某些質量特性。 主要質量屬性詳細需求正確性 可靠性 健壯性 性能、效率 易用性 清晰性 安全性 可擴展性 兼容性 可移植性 … 5.9 其他需求（可剪裁） 詳細列出在前文中沒有包括的所有需求，可能包括用戶對可維護性、可補充性、易讀性、可移植性等方面的特殊需求，或者國際化或法律上的需求。6 需求優(yōu)先級 根據(jù)用戶的需要程度，初步列出各需求的優(yōu)先級，參見《需求跟蹤矩陣》。7 附加說明（可剪裁） 描述該用戶需求說明書采集的方法，如訪談、現(xiàn)場體驗、慣例綜合等。參見的競爭產(chǎn)品和相應的用戶需求獲取文檔，如用戶故事、需求采集表等類似文檔。Download: template-requirement-analysis.rarREF:軟件設計文檔國家標準(GB8567--88)GB8567——88

用戶需求文檔模板的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于用戶需求書是什么意思、用戶需求文檔模板的信息別忘了在本站進行查找喔。