需求分析是軟件開發過程中很重要的一個環節，目前需求分析完成後輸出的文檔有2種體系，一個是SRS（Software Requirements Specification，軟件需求規格說明書），一個是PRD（Product Requirements Document，產品需求文檔）。它們都用於需求分析，但是什麼場合下使用SRS、什麼場景適用PRD，很難給出明確的答案，它們之間的相似與區別可以從以下幾個方面借鑑一下：出處、使用用戶、編寫要點、編寫內容。
一、出處
1. SRS的出處
SRS 出自《GB/T 11457-2006 信息技術 軟件工程術語》、《GB/T 8567-2006 計算機軟件文檔編制規範》，並且在《GB/T 9385-2008-軟件需求規格說明書規範》中進行了標準化。
《GBT9385-2008-軟件需求規格說明書規範》描述了軟件需求規格說明的編制方法。它基於以下設想，即軟件需求規格說明確定過程的結果是一份明確和完備的規格說明文檔。本標準將有助於：
- 軟件的顧客準確地描述其希望得到什麼；
- 軟件的供方正確地理解顧客想要什麼；
- 對於實現以下目標的有關單位和人員：
● 爲其所在的組織編制一份標準的軟件需求規格說明（SRS）提綱；
● 定義其具體軟件需求規格說明的格式和內容；
● 編制其他的本地支持資料，如，SRS質量檢查清單、或SRS編寫者手冊。
2. PRD的出處
歷史上第一份PRD據推測應該是誕生於寶潔這家公司，因爲據史料記載，寶潔在二十世紀二三十年代第一次提出了產品經理的概念，並誕生了第一位產品經理。產品經理大約從2015年開始發展，有自己的一套成熟理論體系，成爲大型軟件服務公司的標配。 BRD（商業需求文檔）、MRD（市場需求文檔）、PRD（產品需求文檔）三種文檔已經成爲產品經理的標配。（參見：產品經理系列1——起源發展篇 | 人人都是產品經理 (woshipm.com) ）
BRD（Business Requirements Document，商業需求文檔）
這是產品生命週期中最早的文檔，其內容涉及市場分析，銷售策略，盈利預測等。BRD要講明白：用戶價值（爲什麼用你的產品）、商業價值（爲什麼要做這個產品），市場分析、目標市場、競爭對手、時機、規模、趨勢，產品功能、原型、實施計劃、願景，成本、ROI分析，風險及應對措施。文檔重點放在定義項目的商業需求。BRD要能說出客戶碰到的一個或多個商業問題，並且通過公司的產品能夠解決這些問題。
BRD，就是戰略需求文檔，呈現形式很多，可以是商業可行性分析，可以是建模方法論等等，取決於這份文檔的讀者，務必根據讀者的特點進行撰寫，這樣通過的概率會大大增加。
MRD（Market Requirements Document，市場需求文檔）
BRD評審通過後就是寫MRD文檔，說明產品的定位。具體來說要有更細緻的市場與競爭對手分析，通過哪些功能來實現商業目的，功能/非功能需求分哪幾塊，功能的優先級等等。
MRD重點放在爲一個被提議的新產品或者現有產品的改進定義市場需求，MRD更深入提議解決方案的細節。它包括一些或者所有這些細節：
a. 解決商業問題所需要的特色
b. 市場競爭分析
c. 功能和非功能需求
d. 特色/需求的優先級
e. 用例
PRD（Product Requirements Document，產品需求文檔）
MRD通過評審後就要編寫PRD文檔。PRD是在MRD的基礎上，詳細的給出了UI（User Interface 用戶界面）和UE（User Experience 用戶體驗）。PRD文檔的核心，是需求分析並根據需求開始落實產品原型，輸出產品的DEMO，針對不同的閱讀人羣嘗試重點的偏移，比如技術讀者注重流程圖的邏輯和原型備註，UI和測試注重原型和需求描述。PRD也就是傳統意義上的需求分析，要給出功能使用的具體描述（每個UC（use case）一般有用例簡述、行爲者、前置條件、後置條件、UI描述、流程/子流程/分支流程等幾大塊）。
二、使用用戶
1. SRS的用戶
SRS可由來自供方、顧客或雙方的一個或者多個人員編寫，推薦由來自供方和顧客雙方的人員聯合編寫。
《GB/T 8567-2006 計算機軟件文檔編制規範》中明確SRS的使用人員包括：開發人員和維護人員。
《GB/T 9385-2008-軟件需求規格說明書規範》中明確：SRS可以爲顧客和供方之間的協議建立基礎、作爲開發合同的一部分、爲估計成本和進度提供基礎。
2. PRD的用戶
PRD由產品經理撰寫，使用用戶包括：
1.產品同事
2.運營
3.設計師
4.開發工程師
5.其他需求方(相關業務部門等)
三、編寫要點
1. SRS的編寫要點
SRS是對在具體環境中執行確定功能的特定軟件產品、程序或一組程序的規格說明。SRS 編寫人員應關注以下基本點：
ａ） 功能———軟件將執行什麼功能？
ｂ） 外部接口———軟件如何與人、系統的硬件及其他硬件和其他軟件進行交互？
ｃ） 性能———各種軟件功能的速度、響應時間、恢復時間等是多少？
ｄ） 屬性———軟件的可用性、可靠性、可移植性、正確性、可維護性、安全性如何？
ｅ） 影響產品實現的設計約束———是否有使用標準、編程語言、數據庫完整性方針、資源限制、運行環境等方面的要求？
編寫適當的 SRS 限定了正確設計的範圍，但不規定任何具體的設計：
ａ）宜正確地定義所有軟件需求。由於將要處理的任務的性質或項目的具體特性，則軟件需求是存在的。
ｂ）不宜描述任何設計或實現的細節。這些內容應當在項目的設計階段進行描述。
ｃ）不宜對軟件設置附加的限制條件。這些內容可在其他文件中規定，如，軟件質量保證計劃。
好的SRS具備以下特徵：
ａ）正確；
ｂ）無歧義；
ｃ）完備；
ｄ）一致；
ｅ）重要性和／或穩定性分級；
ｆ）可驗證；
ｇ）可修改；
ｈ）可追蹤。
2. PRD的編寫要點
根據PRD使用的不同對象，PRD包含的內容也會有差別。爲了能夠使得PRD的目標用戶更好的去獲取到他想要的信息，一份PRD至少就應該包含以下內容：業務流程圖、功能結構圖、功能細節描述、界面原型等。
三、編寫內容
1. SRS的編寫內容
SRS文檔包含以下內容：
- 引言
1.1 目的
1.2 範圍
1.3 定義、簡寫和縮略語
1.4 引用文件
1.5 綜述- 總體描述
2.1 產品描述
2.2 產品功能
2.3 用戶特點
2.4 約束
2.5 假設和依賴關係
2.6 需求分配- 具體需求（按照運行模式、用戶類別、對象、系統特徵、激勵、功能層次分類，具體需求描述方式不同，下面只給出按照用戶類別的描述內容）
3.1 外部接口需求
3.1.1 用戶界面
3.1.2 硬件接口
3.1.3 軟件接口
3.1.4 通信接口
3.2 功能需求
3.2.1 用戶類別1
3.2.1.1 功能需求1.1
...
3.2.1.n 功能需求1.n
3.2.2 用戶類別2
...
3.2.m 用戶類別m
3.2.m.１ 功能需求m.1
...
3.2.m.n 功能需求m.n
3.3 性能需求
3.4 設計約束
3.5 軟件系統屬性
3.6 其他需求
附錄
索引
2. PRD的編寫內容
文檔目錄
修訂記錄
- 產品概述
1.1 產品背景
1.2 目標用戶
1.3 產品目標- 需求列表
列出需求模塊、子模塊、需求簡述和優先級- 功能結構
- 需求明細
4.1 功能性需求
4.1.1 用戶場景
4.1.2 優先級
4.1.3 前置條件
4.1.4 需求描述
4.1.4.1 用戶界面
4.1.4.2 界面描述
4.1.4.3 基本流程
4.1.4.4 異常流程
4.1.5 後置條件
4.1.6 流程圖
4.2 非功能性需求
4.2.1 性能需求
4.2.2 統計需求
4.2.3 安全需求- 其它內容