身為乙個初學者,領導交代的任務當然得努力完成啊,本著害怕忘記的心態寫下了這篇部落格產品需求文件是將商業需求文件（brd）和市場需求文件（mrd）用更加專業的語言進行描述。該文件是產品專案由「概念化」階段進入到「圖紙化」階段的最主要的乙個文件。當然，這個定義針對的是乙個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標使用者、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等，本文主要討論的是戰術部分。
產品需求文件是將商業需求文件（brd）和市場需求文件（mrd）用更加專業的語言進行描述。該文件是產品專案由「概念化」階段進入到「圖紙化」階段的最主要的乙個文件。當然，這個定義針對的是乙個全新的產品。廣義上來講，產品需求的描述，應該包含有產品的戰略和戰術，戰略是指：產品定位、目標市場、目標使用者、競爭對手等。戰術是指產品的結構、核心業務流程、具體用例描述、功能&內容描述等，本文主要討論的是戰術部分。
那麼我們需要寫哪些內容呢?
命名規則:xx產品***x需求_prd的版本號.
歷史版本記錄:包括，編號、文件版本、章節、修改原因、日期、修改人。編號只是為了記錄修改的順序，文件版本顯示的當前修改的內容屬於文件的第幾個版本(或第幾次修改，一次修改一般為乙個版本)，章節是具體到修改內容屬於的功能模組，以便閱讀人及時找到修改後的內容，修改原因說明為什麼要修改該需求，讓閱讀者直觀的了解原因。日期是指需求文件修改的時間，修改人是指需求內容的修改者。
目錄:一般為自動生成
產品概述：解釋說明該產品研發的背景以及核心功能。
產品roadmap：為產品規劃的藍圖，每個關鍵階段完成的核心任務。產品研發是個不斷迭代的過程，需要經過若干個版本的迭代，，對乙個功能點做了n個迭代後最終又回歸到了第乙個迭代是很常見。產品經理需要做好心理準備。產品roadmap並不需要全部規劃好所有的階段目標，但是對產品未來發展趨勢的一種預估，要達到目標，需要更多的更新和迭代。清晰的呈現產品的roadmap可以幫助產品經理把握產品的全貌，更好的控制研發過程。
預期讀者：文件的使用物件
成功的定義和判斷標準：旨在說明產品的目標
名詞說明：名稱、說明。名稱就是對文件中會出現的比較新的名稱，說明則是對這些名稱進行解釋。
5.需求概述:需求概述通常包括需求概覽、使用者類與特徵、執行環境、設計和實現上的限制、專案計畫、產品風險等等。
需求概覽：分兩部分，一是業務流程圖，對產品整個業務流程的發生過程做圖形化的展示，是對產品整體功能流程的闡釋。二是需求清單，對本次要開發的需求任務做分類，給出簡明扼要的需求描述並標註優先順序。
使用者類與特徵：產品的終端使用者，確定產品的終端使用者，並對使用者的角色和操作行為做出說明。
執行環境：該產品上線後的使用環境，比如支援的瀏覽器及其版本，作業系統、資料庫的要求等等，測試人員在看到環境要求後會在測試時重點測試，而最終上線產品時需要把最佳的運營環境告知給使用者。設計和實現上的限制：比如控制項的開發環境、介面的呼叫方式等等。
專案計畫：對於prd中要開發的內容，給出關鍵里程碑，比如需求評審通過的時間、開發的完成時間、上線時間等等。
產品風險：描述產品可能存在的風險，比如效能瓶頸，沒有解決的問題，使用者不當使用的風險等等。
6.功能需求:功能需求一般是由功能詳情和主流程說明兩大部分。功能詳情是所有的產品功能的描述和規劃。功能詳情包括以下內容：
場景描述，產品在哪種情況下會被使用者使用，就是使用者場景模擬。這也是產品經理講「好」故事的必備條件。
業務規則：每上產品在開發時都有相應的業務規則，將這些規則清晰的描述出來，讓開發、測試人員能夠直觀的明白該規則，且沒有產生歧義。業務規則必需是完整的、準確的、易懂的。業務規則的描述上如果涉及到頁面互動或者頁面的修改，建議給出頁面的草圖或者頁面截圖在圖上說明要修改的內容。另外也建議對頁面的輸入框、下拉框的內容格式、長度、控制項之間的關聯性做出說明，什麼時候可見，不可見，灰掉或點亮的條件在文件中都給出說明。方便閱讀者理解業務規則。
介面原型：如前所述，涉及到頁面互動的部分，產品經理需要設計頁面原型。原型設計通常需要產品經理和ui設計師一起來完成。建議的做法是，產品經理可設計乙個頁面框架，將該頁面要呈現的字段及其特徵以及頁面要使用的場景向互動設計師解釋清楚。之後互動和視覺設計師完成產品的原型設計。
使用者說明：對產品使用者做出說明，可融入簡要說明中。
前置條件：該需求實現依賴的前提條件。比如，上傳**時，需要存有影象檔案。
後置條件：操作後引發的後續處理。
主流程：把主流放在最後是有道理的，結合上面所說的，做出主流程說明，對每個功能流程走向分點說明(這是非常重要的)。
看過很多的prd，文件中對既沒有前提條件，也沒有後置條件，只對主流程做了說明，但是在描述主流程時卻沒有描寫主流程中每個功能流程的各種走向，只有乙個主走向，讓人感覺prd成了操作手冊。事實上，對分支的介紹是非常重要的，開發和測試中提出的各類問題均與對分支的定義不明有關。乙個合格的prd不僅要描述主流程，同時對分支流程所出現的各類問題都要做詳細闡述並給出解決辦法。prd的特徵一定是明確的、全面的闡述需求及各類異常情況的處理而不是等到開發和測試階段發現問題後再給以答案(雖然prd不可能百分之百的覆蓋所有的可能，但是最大化的思考所有的業務問題是編制prd時必須遵守的原則)。另外，在描寫功能需求時給出的辦法中不能出現「可能」、「或者」等詞，一定是明確的，唯一的描述。如果有別的方案，建議寫入「可選方案」，在產品構建的早期可選方案可以為功能實現提供更多的選擇，當方案確定後可在文件中註明本次使用了哪種方案。
推薦乙個方法：「用例」，在物件導向的軟體設計模型中，用例是乙個被闡述的內容，用例是對功能使用場景的解釋。用例很條理的介紹了每個功能的前置、後置條件，主流程介紹，幫助開發、測試等角色快速的了解產品功能。
編寫產品需求文件
1做好準備工作 你需要去了解你的顧客 競爭對手 產品團隊的實力和需要的技術。你需要從顧客 使用者 競爭對手 分析師 產品團隊 銷售隊伍 市場 公司職員等收集他們能發現的問題和可能的解決辦法。這裡有很多的工作需要你去完成,在 成功的產品背後 這篇文章中有詳細的描述。2確定產品的目的 注意你不需要闡述太...
編寫專案需求文件
color darkred b 需求分析文件要點 b color color darkred 以下需求文件要點適合瀑布式開發過程。color 一般在最前面有編寫者及文件版本和變更記錄等。color darkred b 引言 b b 編寫目的 b color 術語及縮寫解釋 預期的讀者和閱讀建議 co...
需求文件的編寫
需求的寫作形式一般分為兩種，物件導向和面向過程。對於不同的受眾和應用,採取不同的形式。面向過程的形式 主要的思想是ipo的原則，也就是 輸出 處理 輸出 文件格式，一 首先是對於整體系統的簡略介紹 目的，確定文件描述的物件和大體內容 二 系統上下文，介紹系統和其他系統之間的關係，邊界如何劃分 三 系...