項目需求分析是任何項目開始前的必經階段，也別認為是項目開發中最重要的一環。書店和網絡上關于如何進行需求分析的文章已經很多了。在這里我也談一下自己的理解。

眾所周知，在我們第一次從用戶那里獲取需求的時候，往往得到的是一些很模糊、籠統的要求，而且這些要求主要都是集中在功能要求方面，對性能要求則少有提及。比如我最近負責的一個項目，用戶交過來的項目需求只有簡簡單單的一張A4紙，上面只提到6個方面的要求，這些需求都很模糊，更別提性能方面的要求了。要想根據這樣的需求來開發一個系統難度和后果可想而知。

下面就以其中一個“用戶管理”為例來說明我的方法，先簡單介紹一下我的分析過程：

·這個功能到底是什么？

·這個功能由誰來做，功能操作的對象是誰？

·這個功能操作的前置條件是什么？

·這個功能操作的后續流程是什么？

分析過程:

(一)、是什么功能

很明顯，從客戶的要求上來看，系統必須提供一個可用對用戶的日常行為、操作進行監權、限制、管理的功能。具體應該包括：

·顯示用戶：顯式所有的活躍、鎖定用戶

·增加用戶：增加一個下級用戶，該用戶具備有初始化屬性，而且用戶日后也可以修改部分屬性。用戶的活動狀態可以由上級管理員控制

·修改用戶：修改一個用戶

·刪除用戶：刪除一個用戶

·權限控制：控制該用戶可以做什么，不可以做什么


(二)、由誰來執行這項功能，功能操作的目標對象是誰

從“用戶管理”這四個字來看，我們不難看出，具備用戶管理這一個權限的用戶肯定不能是普通用戶，那么誰才具有管理用戶的權限，又要有多少人來執行管理呢？管理的對象具體包括那些人呢？從這里開始我們就可以開始一步步擴展了。

首先我們來確定這個功能的執行者，經過和客戶的討論溝通，最終確定這系統的用戶包括三種類型：

超級管理員--->部門管理員--->普通用戶

也就是說具備管理權限的人只有兩類：超級管理員和管理員，被管理的對象是普通用戶。


(三)、執行這項功能的前置條件是什么

既然要執行“用戶管理”，需要什么前置條件呢？很明顯，用戶必須首先是具備管理權限的用戶、其次用戶必須正確登陸系統(其中包括了用戶名和密碼驗證、權限驗證)。

OK，既然是用戶必須首先登陸，那么系統必然要提供一個使用戶能耐登陸的界面，同時對用戶的用戶名、密碼、權限進行驗證，不同的用戶定向到不同的初始化頁面，所以從這里我們又可以細化出一個需求：登陸驗證

(四)、執行這項功能的后果是什么

管理員在登陸系統、執行相應的操作后有什么響應呢？總不能什么都不給吧，所以我們必須能夠將用戶操作的結果顯式給用戶。這就是功能執行的后續結果－從操作頁面跳轉到顯式頁面，顯式當前修改用戶或所有用戶的狀態。

在我們分析每一個需求的過程中，我們會不斷得重復以上這四個步驟，直到我們覺得這個功能已經可以被抽象成一個單獨的類或接口了，那意味著我們已經到了需求的葉子節點了(此處我用數據結構中的葉子節點形容已經不能或不需要再細分下去的需求了，其實在某些時候我們必須將某些非葉子節點當成葉子節點，否則需求無限制地細分下去，會沒完沒了的－－這一點對于項目時間比較緊急或采用敏捷開發的項目來說更是如此，前者不用說，后者是因為敏捷軟件開發認為不可能在項目的一開始就完全認清楚項目的所有需求，而是通過不斷的迭代和重構來細化需求)。

從“用戶管理”這4個簡簡單單的四個字開始，我們可以不斷地發現需求點，然后把這些點按操作或時間順序連接起來會形成一條線，接著再往下擴展，我們會發展需求由一條線變成了一棵樹，隨著系統其它各個子模塊需求的進一步分析，樹和樹之間的需求會有交叉點，最終形成一張圖。

(未完待續)