無論是互聯網產品還是IT項目，所有這一切的開端都始於需求分析，一份好的需求文檔往往是項目成功的先決條件，對一個IT產品經理或項目經理來說就顯得尤為重要。如何才能寫出一份讓客戶，開發人員都能讀懂且滿意的文檔？

掌握需求分析的方法

需求分析的方法，是寫好一份需求文檔的內功；毛主席曾教導我們說「沒有調查就沒有發言權」，那麼一份憑空臆想出來的需求文檔，最後的結果也可想而知。需求分析也有各種方法，但終究起目的都是解決下面4個問題。

1. 誰提出的想法？要解決什麼問題？
2. 需要哪些業務來處理這個想法？
3. 這些業務是由什麼信息支撐的？
4. 這些業務的支撐需要什麼樣的環境？

接下來，我會以「XXX校園安全平台的需求」為例，其原始的信息源如下，通過需求分析的方法來回答上面的問題。

XXX學校，希望對學生的出勤率，歸寢情況進行統計；並希望使用信息化的手段，對學生的請假進行管理；而且學校了解到，現在的AI攝像機能進行人臉識別，希望能運用到新系統中，成為他們學校安全的一個亮點。

方法1：梳理出需求涉及的人員、組織機構及他們的訴求和職責

在圍繞校園安全的需求中，大多數人都能分析出如下角色及職責：

但是這裡他們犯了一個錯誤，混淆了客戶與用戶的概念。以上分析只是站在使用系統人的及（最終用戶）角度來進行的，但是要知道最終付錢的（客戶）還有想法的，所以上面的角色及職責應該還可以擴展成如下的表格才較完整。

上面只是通過原始信息源分析得到的，在通過不斷需求訪談或挖掘中，你會發現的人員角色還在不斷的擴展，這種就是通過人員與人員之間關聯來的到的。所以最終的角色表大致如下：

組織機構圖如下：

由上可見我們要避免如下錯誤：

1. 不要混淆了用戶和客戶的概念，優先考慮客戶，因為錢是他付的，想法是他提的；
2. 用戶角色的梳理中，需要考慮到關聯的人員是否也有可能在系統中；例如學生—家長，學生—保安

有了上面的角色，業務及業務流程就有了來源，我們就可以開始來回答第二個問題了。

方法2：找到支撐這些訴求及職責的業務或業務流程

什麼是業務了？我的理解一般就是大家平常說的做事的流程或者做事的步驟。一般情況下我們可以根據用戶的訴求就梳理出大致的業務及流程，再通過一對一的訪談就能達到你想要的業務。

根據上述的用戶角色及訴求，我梳理了如下的業務。這裡只做部分列舉，不做詳細說明。

• 學生出勤業務：學生上學通過AI攝像機進行到校，離校簽到，系統記錄相關數據。
• 學生歸寢業務：學生上學通過AI攝像機進行歸寢，離寢簽到，系統記錄相關數據。
• 學生請銷假業務：學生在系統進行請假申請，提交到班主任處；學生憑藉假條出入學校。

注意事項：由於信息化系統的引入，很多原有的業務流程需要再造。

例如在學生請銷假業務由於AI攝像機和平板的引入其流程就會再造，再造後的流程如下：

學生在系統進行請假申請，提交到班主任處；或由班主任直接創建請假申請；通過後學生在非上下學時間離開時，AI攝像頭識別到該學生後，會在門衛的PAD上顯示該學生的請假信息，核實後允許其離校，離校時會將信息推送給家長。

考慮業務流程中的異常業務

大家分析業務時，都是正常流程很容易，但是一定要考慮其異常流程的處理，因為誰都沒有一直順的時候，例如下面這個異常業務。

• 學生歸校異常業務：學生請假時間已過或未經請假就出校後歸校，這個對於正常的請銷假業務而言是個異常業務了。
• 學生未按時歸寢業務，這個也是歸寢業務的異常業務。

複雜業務使用流程圖更直觀：有些業務比較複雜，這個時候使用業務流程圖可以很清晰的表達出該業務，與客戶溝通時可以取得事倍功半的效果。

找到支撐業務的數據信息

任何業務離開了數據信息，都是瞎說，所以發現業務背後的數據很重要，那麼數據從何而來了？

收集客戶日常流程使用到的單據：

角色日常工作我們經常會看到各種單據，具體到本文中，我們至少可以發現下面兩種單據，學生的假條，訪客進校的登記表，宿管查寢的登記表等。

跟蹤客戶的日常工作，找到他們用到的非正式表格

注意事項：原始表單並不能直接放入到需求中，需要加工成數據字典。

例如請假條：

我們要把他們轉換成對應的數據字典或表格如下圖所示：

梳理要實現以上業務的環境

按理說，完成了以上的業務梳理後我們對需求有了很深入的了解了，能寫出較好的需求文檔了。但是我們還要考慮實現這些的業務的軟硬體環境，外部介面。就本例而言需要考慮如下的環境。

政策環境：

• 公安局對校園安裝攝像頭的要求
• 教育局是否有對校園安全的政策文件等

系統運行的環境例如：

• 伺服器是物理伺服器還是雲伺服器；
• 操作系統使用的是Linux還是，Windows的某個版本
• 資料庫需要使用Mysql Oracle Sqlserver的哪個版本
• 物理伺服器是否需要硬體防火牆，是否需要牽專線

外部介面：

• 罪犯的人臉頭像庫如何提供
• 學籍信息，教師信息，年級班級信息如何提供

通過需求分析，其實我們已經掌握了很多的業務，流程，角色信息等，我們或多或少也使用了一些文檔，例如需求訪談表，文檔最終的目的是減少溝通的成本，確保能清晰的解釋需求。

如果說需求分析方法是寫好需求文檔的內功，那麼規範專業的文檔目錄及內容，則是寫好需求文檔的外功。再好的內功，只有使用恰當的外功才能發揮其效果。

需求文檔

這裡主要介紹三種需求文檔的模版及其作用：

• 原始需求訪談表—記錄用戶最原始的需求文檔；
• 需求規格說明書—對現有業務整理或流程改造後的系統需求文檔；
• 需求清單及功能結構腦圖—用於時間人力等資源進行估算成本計劃。

1. 原始需求訪談表記錄表

我們在與用戶溝通交流時，每次都有必要做好需求的溝通記錄。有了該文檔，我們每次的需求訪談的效率和質量才會更高，而避免不必要的瞎扯，浪費大家時間。

需求的訪談記錄的格式可包含如下要素：

2. 需求規格說明書

需求規格說明書是對原始需求進行加工後，可供開發使用的文檔，所以需求規格說明書的需求是高於原始需求的，對原始需求中的某些內容進行了增刪，確保按照新系統的方式進行的業務能滿足用戶的需求。

好的一份需求規格說明書會節省開發系統設計的大部分時間。需求規格說明書應包含如下結構：

3. 需求清單

需求清單是根據需求規格文檔，按子系統，模塊，功能進行分解後的功能清單；可以通過腦圖進行分解展示，也可以通過Excle文檔進行分類確定。

使用腦圖便於分析和講解：

使用Excle文檔，方便統計和時間估計：