老翅寒暑

需求很重要，但是很多公司做不好。根本還是在需求的理解和管理組織的問題。朋友正好問了我這個問題，所以整理下來發一篇。

對于To B的軟件需求階段，需求評審只是最后一道關，主要是前期工作要到位做足，在正式評審時候要講究效率。

這里有幾個假設：
1. 評委一定是不認真的。會前不看資料，會中不仔細聽講，會后撒手不管
2. 評委的意見一定是基于自身經驗的應激性反應，不是經過深思熟慮之后的發問
3. 評委一定不是天才，他們都是某些方面有豐富經驗的普通人。如果觸發到他們經驗的開關，也會給出非常好的意見和建議

因此，需求評審規范包含幾個部分：
1. 需求的編寫，要寫明白需求
2. 組織評審會議的準備工作
3. 評審會議的高效進展
4. 會議之后的改進和溝通機制

其中2,4很多會議組織的規范里都講了，我更看重1和3

需求的編寫是重中之重。

首先要確保需求是整體的而非離散的。簡而言之，就是必須有一個時刻在維護的需求樹，從愿景開始逐層分解，所有的需求無論多細都應該在這棵樹中存在位置。無法歸納到這個樹中的需求就一定不是真實需求，要不就是樹的分解有問題。一般需求分為業務需求，功能需求，系統需求和技術需求。業務需求滿足的是客戶的目標，功能需求滿足的是用戶的目標，系統需求滿足的模塊的目標，技術需求滿足的是業務邏輯的目標。

其次，需求的描述必須是完整的，很多需求編寫規范可以參考，大致是每個需求都有用戶，有明確的業務和技術目標，有前后依賴關系，有具體的操作步驟，有例外情況，有些還包含算法說明。如果再分解下去發現沒有用戶了，或者用戶變成了技術概念，說明業務需求變成了功能需求。

評審會議的時候，講述非常重要。我們剛才說評委都是普通人，就意味著他們有和普通人的特點：對于陌生的事物，無法進行抽象的理解。所以，評審會議的講述主要分為三個部分：

1. 概念部分。目的是向評委灌輸產品的定位和來龍去脈，如果是新版本，則是表述我們遇到了什么樣的問題，決定要在新版本中加入這些新功能。這個講述邏輯一定是沿著需求樹自頂向下開始講，講完業務需求，也可以到第一層的功能需求。

2. 產品的使用。所有的功能需求最好用原型配合進行講解。講解的次序不是原型的頁面次序，依然是需求樹中的順序，按照功能在樹中的排列次序，依次講解，逐層深入。用術語講就是在一個大功能內部采用廣度優先而非深度優先的講解順序。廣度優先的講解順序有助于保持聽眾的全局感。深度優先通常會引發一些不必要的爭議，會打亂演講的節奏。

3. 一些需要關注或特別說明的點。例如一些特別的技術攻關需求，一些復雜邏輯的專題說明等。

4. 最后是答疑部分。這個也在標準的會議議程中，不再贅述。

總而言之，如果真的想要有成效的需求規范，需求的一致性和完整性是核心，正確的講述邏輯和次序是外表。如果想依賴評審給出什么特別的建議，一方面概率不大，另一方面表示需求準備階段是失敗的。

需求評審的參考資料
1. 這個形式主義的說法 https://baijiahao.baidu.com/s?id=1657592380716314568
2. 這個講到了一些本質的東西 https://zhuanlan.zhihu.com/p/319447037
3. 軟件需求分層處理的多種常見方式 https://blog.csdn.net/zhangmike/article/details/49529587