上篇文章給大家介紹了用戶及應用場景“ 產品經理的需求文檔怎么寫？應該包括什么內容？（二） ”，下面看看接下來的內容。
2.系統/產品的目標

通俗一點講，就是要解決什么問題、帶來什么價值。這本質上是要明確產品需要滿足用戶的什么需求。但凡需求，均有價值和優先級。判斷需求的價值，可用 PST方法分析，但通常這個理論都比較繁瑣。其實優先級很容易得出，通常User急切想要的東西，或者急切想要借助一個系統或一款產品來幫助他解決業務當中棘手的問題時，這些都是優先級比較高的需求。

這一章節的內容，它決定了，我們要設計什么樣的產品，用這個產品能夠用來做些什么。比如一個績效系統，主要就是要實現企業不同部門，不同層級、角色的績效指標的自動化計算、匯總、可視化呈現。做的好一點，時間維度、能夠自由而靈活界定， 準確而便捷地評鑒個體的績效趨勢和走向方便績效的精細化管理和追蹤。另一方面能夠從全面的職責維度出發，對比和觀測不同職責的績效表現與趨勢。能夠更加容易、全面、公正地績效考評并有效聯動獎金激勵機制。

3.功能模塊概要介紹

這一章節是概要地介紹，你要設計和規劃的產品都需要具備哪些功能模塊、功能點、大致會有哪些主要的功能頁面來支撐這個功能模塊。

模塊的定位、模塊間的劃分與交互都需要有基本的介紹。目的主要有2個：

一方面，是為了方便PM清晰地將產品規劃的功能落地下來，因為這些瑣碎的創意和設計，只有在你具體去描述它的時候、并畫出它的Mockup的時候，它的局限性、用戶交互、用戶體驗等種種缺陷才會展現出來，你才能進行持續的思考和摒棄。通過這樣的過程，PM把這些星星點點的創意和設計，經過一個產品化（系統化）的體系思考、演繹之后變得生動和流暢起來。

另一方面，功能概述的意義旨在為程序員服務，程序員前期不參與需求、系統規劃和設計，拿到需求規格說明書后，如果立馬進入到具體某個頁面、功能點的詳盡規格描述里，通常都會一臉懵逼，然后開罵和抱怨。

所以功能模塊概要需要用盡量簡練的語言將各個功能模塊里的主要功能點提煉概述而過，不拖泥帶水、不瞻前顧后。最好圖文并茂地將功能模塊的profile像一張藍圖呈現在程序員面前。這是他們讀需求規格說明書的一個前奏，要不然都不能愉快地編碼和玩耍。

而所有有才的程序員，大多數都是機智過人的漢子，你若遇見冰雪聰明的妹子，可以一塊共事，那該是多么大的小確幸，且行且珍惜。

有點才華的PM遍地都是，但才華橫溢的程序員真的是千里難尋。因為在編碼和玩耍的世界里，不存在“三個臭皮匠頂一個諸葛亮”程式，一個有才而好學的程序員遠遠勝過10個平庸的呆笨男。

接下來就是功能需求詳細規格說明，下篇文章繼續給大家分享，趕緊去看看吧！

以上就是“產品經理的需求文檔怎么寫？應該包括什么內容？（三）”的內容了，如果你還想了解其他相關內容，可以來 產品壹佰 官方網站。