產品開發需求文檔
A. 你覺得為什麼需要寫產品需求文檔
1）清晰明確地傳達產品需求；
2）保證各部門溝通順暢且有理有據；
3）確保工作傳承。
當初在黑馬程序員培訓時候，老師就說這是做產品經理必須要寫的東西。
B. 產品需求文檔規范-精品文檔
對於產品經理來說，產品需求文檔（PRD文檔）是工作的核心產出。一份嚴謹、優秀的產品需求文檔能夠給項目的其他人員，包括設計師，開發工程師，測試工程師，運營人員等帶來很大的幫助。但對於產品經理來說，撰寫一份完整的產品需求文檔往往需要花費相當多的時間和精力。
今天我們一起來看看，如何提升產品需求文檔的撰寫效率。
為什麼要寫產品需求文檔?
對於稍微大一點的產品開發團隊來說，產品經理未必能向所有團隊成員准確傳達產品開發需求，這時就需要一份完整的產品需求文檔供項目參與人員閱讀。
首先，產品經理可以根據項目的階段運營目標提出合理需求，通過PRD文檔闡述產品整體設計需求背景，設計思路，功能范圍，交互邏輯，頁面細節及其他信息。
其次，團隊的相關人員可以快速獲取自己需要的信息，節省反復溝通的時間成本，更好地開展工作。
最後，產品需求文檔也是一個產品項目投入開發前的重要附件之一。團隊領導可以根據產品需求文檔清晰了解為什麼需要開發這樣一款產品。項目的其他相關方也可以隨時參閱需求文檔，了解項目的基本信息。
總的來說，產品需求文檔有三個核心作用：
傳達產品開發需求；
保證團隊成員溝通順暢；
制定產品質量控制標准。
產品需求文檔的在項目中的重要性已經不言而喻。那麼對於產品經理來說，有哪些技巧可以更好地完成產品需求文檔的撰寫呢？
產品需求文檔包含哪些內容？
通過下圖，我們可以簡單了解產品需求文檔需要呈現的基本內容。
使用摹客等高效便捷的產品文檔撰寫工具，可以簡化產品文檔撰寫流程，提升產品經理的文檔撰寫能力，讓產品經理事半功倍。
總結
產品需求文檔作為產品開發團隊的重要溝通文檔，文檔的質量好壞會直接影響到各部門是否能夠明確產品的功能和邏輯。一份簡潔易懂、邏輯清晰的產品需求文檔，可以讓團隊溝通更加高效，從而有效提高產品開發團隊的工作效率。
C. Android APP開發需求文檔範本
軟體需求文檔格式的標准寫法
1．引言
1．1 編寫目的
· 闡明開發本軟體的目的；
1．2 項目背景
· 標識待開發軟體產品的名稱、代碼；
· 列出本項目的任務提出者、項目負責人、系統分析員、系統設計員、程序設計員、程序員、資料員以及與本項目開展工作直接有關的人員和用戶；
· 說明該軟體產品與其他有關軟體產品的相互關系。
1．3 術語說明
列出本文檔中所用到的專門術語的定義和英文縮寫詞的原文。
1．4 參考資料（可有可無）
列舉編寫軟體需求規格說明時所參考的資料，包括項目經核準的計劃任務書、合
同、引用的標准和規范、項目開發計劃、需求規格說明、使用實例文檔，以及相關產品
的軟體需求規格說明。
在這里應該給出詳細的信息，包括標題、作者、版本號、發表日期、出版單位或資
料來源。
2．項目概述
2．1 待開發軟體的一般描述
描述待開發軟體的背景，所應達到的目標，以及市場前景等。
2．2 待開發軟體的功能
簡述待開發軟體所具有的主要功能。為了幫助每個讀者易於理解，可以使用列表或
圖形的方法進行描述。使用圖形表示，可以採用：
· 頂層數據流圖；
· 用例UseCase圖；
· 系統流程圖；
· 層次方框圖。
2．3 用戶特徵和水平（是哪類人使用）
描述最終用戶應具有的受教育水平、工作經驗及技術專長。
2．4 運行環境
描述軟體的運行環境，包括硬體平台、硬體要求、操作系統和版本，以及其他的軟
件或與其共存的應用程序等。
2．5 條件與限制
給出影響開發人員在設計軟體時的約束條款，例如：
· 必須使用或避免使用的特定技術、工具、編程語言和資料庫；
· 硬體限制；
· 所要求的開發規范或標准。
3．功能需求
3．1 功能劃分
列舉出所開發的軟體能實現的全部功能，可採用文字、圖表或數學公式等多種方法
進行描述。
3．2 功能描述
對各個功能進行詳細的描述。
4．外部介面需求
4．1 用戶界面
對用戶希望該軟體所具有的界面特徵進行描述。以下是可能要包括的一些特徵：
· 將要採用的圖形用戶界面標准或產品系列的風格；
· 屏幕布局；
· 菜單布局；
· 輸入輸出格式；
· 錯誤信息顯示格式；
建議採用RAD開發工具， 比如Visio，構造用戶界面。
4．2 硬體介面
描述系統中軟體產品和硬體設備每一介面的特徵，以及硬體介面支持的設備、軟體與硬體介面之間，以及硬體介面與支持設備之間的約定，包括交流的數據和控制信息的性質以及所使用的通信協議。
4．3 軟體介面
描述該軟體產品與其有關軟體的介面關系，並指出這些外部軟體或組件的名字和版本號。比如運行在什麼操作系統上，訪問何種類型的資料庫，使用什麼資料庫連接組件，和什麼商業軟體共享數據等。
4．4 通信介面
描述和本軟體產品相關的各種通信需求，包括電子郵件、Web瀏覽器、網路通信協議等。
4．5 故障處理
對可能的軟體、硬體故障以及對各項性能而言所產生的後果進行處理。
5．性能需求
5．1 數據精確度
輸出結果的精度。
5．2 時間特性
時間特性可包括如下幾方面
·響應時間；
·更新處理時間；
·數據轉換與傳輸時間；
·運行時間等。
5．3 適應性
在操作方式、運行環境、與其他軟體的介面以及開發計劃等發生變化時，軟體的適應能力。
6．其他需求
列出在本文的其他部分未出現的需求。如果不需要增加其他需求，可省略這一部分。
7．數據描述
7．1 靜態數據
7．2 動態數據
包括輸入數據和輸出數據。
7．3 資料庫描述
給出使用資料庫的名稱和類型。
7．4 數據字典
對於數據流圖、層次方框圖中出現的所有圖形元素在數據字典中都要作為一個詞條加以定義，使得每一個圖形元素都有唯一的一個清晰明確的解釋。
數據字典中所有的定義必須是嚴密的、精確的，不可有二意性。
7．5 數據採集
·列出提供輸入數據的機構、設備和人員
·列出數據輸入的手段、介質和設備；
·列出數據生成的方法、介質和設備。
8．附錄
包括分析模型，待定問題圖表等。
D. 市場需求文檔和產品需求文檔區別是什麼
該文檔是軟體產品項目由「准備」階段進入到「實施」階段的第一文檔，其作用就是某個軟體產品進行市場層面的說明」，這個文檔的質量好壞直接影響到產品項目的開展，並直接影響到公司產品戰略意圖的實現。一般在互聯網企業中MRD都是由運營人員和產品設計人員共同制定完成的，互聯網軟體產品由於最終直接面向終端用戶，且需要長期運營，作為互聯網企業中的運營人員是最清晰市場動向？產品受眾是哪些人？為什麼需要產品人員配合呢，主要是因為運營人員很普遍的觀念是以運營商品的視角來考慮問題並未能深埋產品級的需求，所以兩者配合來制定編寫市場需求文檔是最合適不過的。產品需求文檔(Proct Requirement Document，PRD)，該文檔在產品項目中是一個「承上啟下」的作用，「向上」是對MRD內容的繼承和發展，「向下」是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。該文檔一般是由產品設計人員來完成，也就是傳統意義上的需求分析，其主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程、子流程、分支流程，等幾大塊），功能點業務流程框線圖，界面說明，Demo等。
E. 產品需求文檔中包含實現技術嗎
產品需求文檔 包含功能和業務需求，不包含實現方式，當然如果有特定技術需求的話可以包含實現技術條件
F. 產品需求文檔應該包含哪些內容
規范化軟體開發過程中的《需求說明書》的編寫，使之成為整個開發工作的基礎。
2 適用范圍
本規范適用於集團開發項目的（軟體）《需求說明書》的編寫。
3 編寫內容提示
1 引言
3.1.1 背景說明
說明被開發軟體的名稱，任務提出者，用戶及實現該軟體的計算機網路。
3.1.2 參考資料
列出有關資料(名稱，發表日期，出版單位，作者等)。
3.1.3 術語和縮寫詞
列出本文件中用到的專門術語的定義，及術語縮寫詞。
3.2 軟體總體概述
3.2.1 目標
軟體開發的意圖、應用目標、作用范圍以及需說明背景材料。
3.2.2 系統模型
圖示說明該軟體的所有功能及其相互關系和數據傳遞情況。
3.2.3 假設和約束
說明影響軟體開發、運行環境和系統能力（如預告出錯類型的能力）的某些假設和約束。3.3 詳細需求
詳細描述此軟體系統的功能需求和性能需求。
3.3.1 功能需求
對系統中每一個功能，要詳細描述（圖示或文字）。
概述 敘述功能名稱，目標和作用。
輸入 輸入該功能的信息。
處理 描述該功能做什麼，如何對輸入信息進行加工並轉換成輸出信息。
輸出 列出內部生成的文件。
3.3.2 性能需求
定量地描述此軟體系統應滿足的具體性能需求。可考慮以下方面：
3.3.2.1精度
說明系統的精度要求，如：
數據的精度要求。
數字計算的精度要求。
數據傳送的誤碼率要求。
3.3.2.2 時間特性
說明系統的時間特性要求，如：
解題時間。
詢問和更新數據文件的響應時間。
系統各項功能的順序關系。
3.3.2.3 靈活性
說明當需求發生某些變化時系統的適應能力，指出為適應這些變化而需要設計的軟體成分和過程。
3.3.2.4系統容量
包括系統的設計容量和理論（計算）容量。
3.3.3 輸入和輸出
解釋各輸入輸出數據類型，並逐項說明某媒體、格式、數值范圍等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。
3.3.4 數據管理能力
說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作估算。
3.3.5 故障處理
列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。
3.4 環境
描述所開發軟體運行所需的環境。
3.4.1 設備環境
描述運行軟體系統所需的設備能力，如：
處理器的型號和內存容量。
存儲媒體的數量。
通信網路（包括說明網路結構，線路速度及通訊協議等）。
3.4.2 支持軟體環境
列出與待開發的軟體互相配合的支持軟體（包括名稱，版本號和文件資料），必要時還應列出測試軟體，還要指出該軟體用的編程語言，編譯程序，操作系統和數據管理系統。
3.4.3 介面
說明本軟體與其他軟體之間的介面、數據通信協議等。
3.4.4其他
說明本軟體系統在安全和保密方面的要求以及用戶對使用方便、可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求。
G. 產品需求文檔模板
首先告訴你產品需求文檔肯定是有的！一個經過實際工作檢驗、經歷過「質疑」、「挑戰」和「斗爭」之後沉澱下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標准化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種「標准」的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。
不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，並在此過程中形成自己對於模板的理解，進而形成對於產品需求文檔的理解，在理解中使用，裁剪和優化。
要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：
一、描述-解釋-預測-監控
描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。
解釋，是回答 「為什麼」，是對於描述的理解、歸類、定義和解釋。其目標是將描述內容背後的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對於描述內容有更清晰、更細致、全面的了解。
預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，准確地表達內在聯系，從中推導出正確的預測。
監控，是對於預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而採取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的「響應」機制，並任其自然發生或者通過提供「系統」的自製能力來實現。
二、需求准備、編寫和檢查
回歸到產品經理的日常工作中，在時間佔比上較為集中的就是產品需求管理了，包括了需求的准備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，並可以幫助理解、形成並固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。
1. 描述
描述的過程是客觀的進行「需求向」描述的過程，是一個「背景」信息的補充，用來說明，這個需求文檔的源出是什麼，是針對什麼問題，這個問題是在具體什麼領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什麼，參與者是怎麼解決的，解決的情況怎麼樣，是好，還是不好，還是勉強可以，對於新的需求的緊迫性是什麼樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和「溝通字典」，避免在溝通中因為誤解而產生不必要的偏差。
需求准備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；
需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；
需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的背景、目標、過程、干係人、結果預測和預防的完整性檢查；
2. 解釋
解釋在需求來源的基礎上描述了 「為什麼」接下來這個需求可以解決遇到的問題，同時還加入了「是什麼」和「怎麼樣」的部分。就是這個需求是通過怎麼樣的方法解決了「描述」過程中提到的問題，這個新的解決方法需要要做什麼，對於原有的業務過程有哪些改變，會提升什麼，會降低什麼，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上佔比最大的一部分。
這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對於運營的影響，對於前端市場的影響，對於用戶的影響，對於財務、法務的影響；從技術開發、技術實現維度，比如對於前端開發的影響、對於服務端開發的影響、對於數據平台的影響，還可能涉及到對於運維資源的影響等；因此對應到實際的產品需求工作中：
需求准備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；
需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；
需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與後服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先順序；系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；
3. 預測與監控
預測與監控在產品需求文檔的管理上是聯動的，是對於預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對於設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 「非規劃」的使用，也就是我們通常說的「用戶並不總是按照產品設計的方式來使用產品，而且，往往相反。」因此，這部分內容很大的比例需要來對於用戶的行為進行預測和監控，並提供「預防」或者「解決」方案。其中：
預防在於，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最後操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多採用導航、提示等，不同的系統都有各自標准化的控價，我們在這里不做展開。
解決在於，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了「非標」、「超規」使用「掉出」原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來「回轉」用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過「導航」引導「跳轉」和「返回」、「回退」來實現。對應到實際的產品需求工作中：
需求准備的過程：了解用戶特徵和使用水平、評估、比較不同方式實現需求對於用戶行為的可控性和「非常規」操作的危害程度；
需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；
需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；
需求檢查的過程：需求「異常」流程和相應引導、控制地完整性檢查；
在需求管理的過程中，就可以按照這個 描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之後的檢查。
四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標准。所謂標准文檔，就可以按照這四個模塊作為框架、內容和格式。
寫在最後
產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，並最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。
H. 項目需求分析文檔都包括哪些內容
需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價內，最終形成容開發計劃的一個復雜過程在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段包括：
業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。
用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。
功能需求——定義了開發人員必須實現的軟體功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。
非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標准、規范和約束，操作界面的具體細節和構造上的限制。
需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。