編輯導語：需求文檔和需求規格說明書，二者都與産品有關，但是其所應用的場景又有所差異。産品經理可以利用需求規則說明書進行系統的校驗或評判，使之更好地為實際場景所服務。本篇文章裡，作者闡述了他所理解的需求規格說明書，一起來看一下。

作為一個需求工作經驗（ToB端）2年的小白，在沒有大手子知道的情況下摸爬滾打磕磕絆絆，屬實有點閉門造車，希望大家多指點指點，如何才能更好地完成需求工作。

另一方面，想讓自己的胡思亂想可以記錄下來，避免真的變成了胡思亂想。

為什麼要将需規的編寫目的放在第一位？

作為産品崗來說，發掘用戶需求是我們的最終目标。針對這種思維結構，那麼在探讨如何寫好需規的前提，我們要想明白需規存在的含義是什麼？為了什麼而存在？我們不妨繼續通過用戶場景來分析，我們在什麼場景下使用需規呢？

• 場景A：需求人員在需求傳遞環節，通過需規來與開發團隊的成員講述我們的系統要做功能A、功能B、功能C等等。
• 場景B：開發同事發現業務A，有兩種理解方式，不清楚該使用哪一種。
• 場景C：項目進入需求驗證階段，需求同事要驗證系統是否通過。
• 場景D：測試同事提了一個BUG，但開發同事認為這不是BUG，認為需求如此。

針對以上四種場景，我們可感受到，我們需要利用需規去指導、去校驗、去評判當前開發的系統是否是正确的。從場景中分析的需規作用，可以理解為一種解決方案。

我們再進一步地去思考，是否可以認為，需規的根本目的是“保證所開發的系統就是客戶想使用的系統”。

一樣又不一樣。

說他倆一樣。因為他使用的主要對象都有：開發、測試、項目經理；都是要描述核心業務、具體用例描述、功能&内容描述等。

說他倆不一樣。因為需求文檔是站在産品的角度去講述。而需求是站在系統的角度去講述的。

兩者都有交集，但沒有必要去劃分的很清楚到底一不一樣。在面對矛盾的時候我們要理解矛盾點在哪裡。

一般來說，矛盾大多是由利益矛盾産生的。那麼是誰的利益矛盾呢？

無非是閱讀者與編寫者的矛盾。閱讀者想要快速地、簡練地獲取到自己想要的信息，因為懶！畢竟冗長的文檔讀起來對讀者是精神與肉體的雙重折磨。而編寫者，總是想要把事情說的足夠詳細避免産生二義性，又或者還是懶！

所以我認為，需求文檔更側重于對産品的描述，産品的定位、目标市場、目标用戶及其競争産品。而需規更側重于系統的描述，實現邏輯、約束、輸入輸出條件等。

既然需規的目的是“保證所開發的系統就是客戶想使用的系統”（我們先假定我們的需規内容與客戶的想法一緻）。我們先從可能存在的場景去分析需規應該有哪些内容。

1. 一定要有業務場景描述

其實關于業務場景的描述，更多地想要讓文檔讀者更快地帶入到系統中。由于公司資源調整，項目裡很多同事換來換去的，直接參照着文檔講，容易給同事們講的一臉懵逼。所以能夠讓團隊成員更容易理解，更容易融入其中，對于業務場景的描述也是至關重要的。

我們在描述場景的時候，最好講明“誰”（參與者），在“什麼樣的場景下”，為了完成某個“目的”，而做了“什麼操作”。

通過上述的幾個要素，個人覺得可以通俗易懂的講述需求背景。

2. 盡量用用例的方式去劃分功能點

“一千個讀者一千個哈姆雷特”，關于需規的結構每個人的理解必然不一樣，個人覺得要保持中心思想去做需規：用戶可以通過系統完成什麼事情。

即系統的用例，我們通過各種方式來梳理出系統的用例有哪些，這樣就可以更直觀地看出系統有哪些功能。

例如：在“場景A”的情況中，我們要來指導開發團隊去開發功能，那麼我們需要盡量描述清楚每一個功能，一定要保證功能不存在遺漏項。

那麼怎樣的邏輯才能讓功能描述得全呢？我認為在項目做規劃的時候，要把模塊範圍劃分清楚，每一個模塊的定義、目的、适用範圍，然後再根據模塊規劃用例。這樣就可以保證開發的内容保持功能全覆蓋。讀者在看的時候也可以很直觀地看到，原來我們的系統可以完成這這這等等功能。

3. 複雜邏輯功能的流程圖很重要

為什麼要單獨提出來重點功能這個概念呢？我們會發現場景B、C、D總結下來就是我們針對功能的理解都不一樣。

文字描述總會有其弊端，斷句、描述順序、描述邏輯都存在偏向主觀。所以我們可以通過畫流程圖來輔助對文字的描述。

同時，我們一定要确定好我們的流程圖的範圍，是針對業務流程進行的還是對這個用例進行描述的。因為我遇到過把業務場景跟用例畫在一起的操作。這樣很容易誤導讀者，使讀者的迷惑。

那麼為什麼要單指複雜邏輯功能呢？其實，我們完成了目的，講明白需求就可以了，所有的功能都畫的話，很浪費時間跟精力的，所以挑重點說就好。

本文由 @小鐘也會胡思亂想 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0協議。