編輯導(dǎo)語：需求文檔和需求規(guī)格說明書，二者都與產(chǎn)品有關(guān)，但是其所應(yīng)用的場(chǎng)景又有所差異。產(chǎn)品經(jīng)理可以利用需求規(guī)則說明書進(jìn)行系統(tǒng)的校驗(yàn)或評(píng)判，使之更好地為實(shí)際場(chǎng)景所服務(wù)。本篇文章里，作者闡述了他所理解的需求規(guī)格說明書，一起來看一下。

一、前言

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

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

二、編寫需規(guī)的目的是什么？

為什么要將需規(guī)的編寫目的放在第一位？

作為產(chǎn)品崗來說，發(fā)掘用戶需求是我們的最終目標(biāo)。針對(duì)這種思維結(jié)構(gòu)，那么在探討如何寫好需規(guī)的前提，我們要想明白需規(guī)存在的含義是什么？為了什么而存在？我們不妨繼續(xù)通過用戶場(chǎng)景來分析，我們?cè)谑裁磮?chǎng)景下使用需規(guī)呢？

• 場(chǎng)景A：需求人員在需求傳遞環(huán)節(jié)，通過需規(guī)來與開發(fā)團(tuán)隊(duì)的成員講述我們的系統(tǒng)要做功能A、功能B、功能C等等。
• 場(chǎng)景B：開發(fā)同事發(fā)現(xiàn)業(yè)務(wù)A，有兩種理解方式，不清楚該使用哪一種。
• 場(chǎng)景C：項(xiàng)目進(jìn)入需求驗(yàn)證階段，需求同事要驗(yàn)證系統(tǒng)是否通過。
• 場(chǎng)景D：測(cè)試同事提了一個(gè)BUG，但開發(fā)同事認(rèn)為這不是BUG，認(rèn)為需求如此。

針對(duì)以上四種場(chǎng)景，我們可感受到，我們需要利用需規(guī)去指導(dǎo)、去校驗(yàn)、去評(píng)判當(dāng)前開發(fā)的系統(tǒng)是否是正確的。從場(chǎng)景中分析的需規(guī)作用，可以理解為一種解決方案。

我們?cè)龠M(jìn)一步地去思考，是否可以認(rèn)為，需規(guī)的根本目的是“保證所開發(fā)的系統(tǒng)就是客戶想使用的系統(tǒng)”。

三、需求文檔和需求規(guī)格說明書有什么區(qū)別

一樣又不一樣。

說他倆一樣。因?yàn)樗褂玫闹饕獙?duì)象都有：開發(fā)、測(cè)試、項(xiàng)目經(jīng)理；都是要描述核心業(yè)務(wù)、具體用例描述、功能&內(nèi)容描述等。

說他倆不一樣。因?yàn)樾枨笪臋n是站在產(chǎn)品的角度去講述。而需求是站在系統(tǒng)的角度去講述的。

兩者都有交集，但沒有必要去劃分的很清楚到底一不一樣。在面對(duì)矛盾的時(shí)候我們要理解矛盾點(diǎn)在哪里。

一般來說，矛盾大多是由利益矛盾產(chǎn)生的。那么是誰的利益矛盾呢？

無非是閱讀者與編寫者的矛盾。閱讀者想要快速地、簡(jiǎn)練地獲取到自己想要的信息，因?yàn)閼?！畢竟冗長(zhǎng)的文檔讀起來對(duì)讀者是精神與肉體的雙重折磨。而編寫者，總是想要把事情說的足夠詳細(xì)避免產(chǎn)生二義性，又或者還是懶！

所以我認(rèn)為，需求文檔更側(cè)重于對(duì)產(chǎn)品的描述，產(chǎn)品的定位、目標(biāo)市場(chǎng)、目標(biāo)用戶及其競(jìng)爭(zhēng)產(chǎn)品。而需規(guī)更側(cè)重于系統(tǒng)的描述，實(shí)現(xiàn)邏輯、約束、輸入輸出條件等。

四、從遇到的問題中反思

既然需規(guī)的目的是“保證所開發(fā)的系統(tǒng)就是客戶想使用的系統(tǒng)”（我們先假定我們的需規(guī)內(nèi)容與客戶的想法一致）。我們先從可能存在的場(chǎng)景去分析需規(guī)應(yīng)該有哪些內(nèi)容。

1. 一定要有業(yè)務(wù)場(chǎng)景描述

其實(shí)關(guān)于業(yè)務(wù)場(chǎng)景的描述，更多地想要讓文檔讀者更快地帶入到系統(tǒng)中。由于公司資源調(diào)整，項(xiàng)目里很多同事?lián)Q來換去的，直接參照著文檔講，容易給同事們講的一臉懵逼。所以能夠讓團(tuán)隊(duì)成員更容易理解，更容易融入其中，對(duì)于業(yè)務(wù)場(chǎng)景的描述也是至關(guān)重要的。

我們?cè)诿枋鰣?chǎng)景的時(shí)候，最好講明“誰”（參與者），在“什么樣的場(chǎng)景下”，為了完成某個(gè)“目的”，而做了“什么操作”。

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

2. 盡量用用例的方式去劃分功能點(diǎn)

“一千個(gè)讀者一千個(gè)哈姆雷特”，關(guān)于需規(guī)的結(jié)構(gòu)每個(gè)人的理解必然不一樣，個(gè)人覺得要保持中心思想去做需規(guī)：用戶可以通過系統(tǒng)完成什么事情。

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

例如：在“場(chǎng)景A”的情況中，我們要來指導(dǎo)開發(fā)團(tuán)隊(duì)去開發(fā)功能，那么我們需要盡量描述清楚每一個(gè)功能，一定要保證功能不存在遺漏項(xiàng)。

那么怎樣的邏輯才能讓功能描述得全呢？我認(rèn)為在項(xiàng)目做規(guī)劃的時(shí)候，要把模塊范圍劃分清楚，每一個(gè)模塊的定義、目的、適用范圍，然后再根據(jù)模塊規(guī)劃用例。這樣就可以保證開發(fā)的內(nèi)容保持功能全覆蓋。讀者在看的時(shí)候也可以很直觀地看到，原來我們的系統(tǒng)可以完成這這這等等功能。

3. 復(fù)雜邏輯功能的流程圖很重要

為什么要單獨(dú)提出來重點(diǎn)功能這個(gè)概念呢？我們會(huì)發(fā)現(xiàn)場(chǎng)景B、C、D總結(jié)下來就是我們針對(duì)功能的理解都不一樣。

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

同時(shí)，我們一定要確定好我們的流程圖的范圍，是針對(duì)業(yè)務(wù)流程進(jìn)行的還是對(duì)這個(gè)用例進(jìn)行描述的。因?yàn)槲矣龅竭^把業(yè)務(wù)場(chǎng)景跟用例畫在一起的操作。這樣很容易誤導(dǎo)讀者，使讀者的迷惑。

那么為什么要單指復(fù)雜邏輯功能呢？其實(shí)，我們完成了目的，講明白需求就可以了，所有的功能都畫的話，很浪費(fèi)時(shí)間跟精力的，所以挑重點(diǎn)說就好。

本文由 @小鐘也會(huì)胡思亂想 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0協(xié)議。