需求分析在資料庫生命周期中至關重要，通常也是涉及人員最多的步驟。資料庫設計師在這個階段必須走訪最終使用者，與他們進行訪談，進而确定使用者想在系 統中存儲什麼資料以及想怎樣使用這些資料。
我們将需求分析分為兩個步驟：1.了解使用者需求；2.提取業務規則。這次我們先讨論“了解使用者需求”。
設計定制化産品——無論是一個資料庫、一幅平面廣告或一個玩具，都是一個“翻譯”的過程。我們需要把浮現在客戶腦海中的模糊想法、願望挖掘出來，并“翻譯”成滿足他們需求的現實産品。
這個“翻譯”過程的第一步就是了解使用者的需求。設計最好的訂單處理系統對于需要一個電路設計工具的客戶來說毫無意義。對客戶需求了解的不完全會造成錯誤或無用的設計與開發，這浪費了你、你的團隊還有客戶的時間與金錢。(牢記資料庫是整個應用開發的根基)
制定一個計劃
我們首先制定了一個計劃，其中包含挖掘客戶需求的一系列步驟。遵循這些步驟能更好地了解客戶需求，但在一些項目中我們不需要遵循所有的步驟。舉例來 說，如果客戶是單個人且需求很明确時，我們就不需要進行“搞清誰是誰”與“頭腦風暴”了。當客戶的資料需要保密時，我們就不能“嘗試客戶的工作”了。在另 一些項目中，調整這些步驟的順序會更為合适。例如我們可能在去拜訪客戶和觀察他們工作之前先進行“頭腦風暴”。
以下按照最普遍的順序列出了各個步驟。大家根據不同項目的情況可進行靈活調整，目标隻有一個就是更好地了解使用者需求。
列出問題清單
拜訪客戶
搞清誰是誰
挖掘客戶大腦
嘗試客戶的工作
學習現有操作
頭腦風暴
展望未來
了解客戶的質疑
弄清客戶的真正需求
優先級
确認你的了解
撰寫需求文檔
下面我們将一一解釋每一個步驟。
我們需要思考，向客戶問些什麼問題可以幫助我們了解項目的目标和範疇（scope）。以下幾個方面的問題可以作為起始點。
功能：
以下問題主要涉及系統應完成的功能與目标。
系統應該做些什麼?
為什麼你想建這個系統?
系統看上去應該是怎樣的?
需要些什麼報表?
使用者需要自己定義新報表嗎?
系統的操作者會是誰?
資料需求：
這些問題是為了弄清項目的資料需求。了解需要些什麼資料能幫助我們定義資料庫表。
系統界面上需要展現哪些資料?
這些資料應該由誰來提供?
這些資料是如何關聯的?
這些工作現在是如何處理的?資料來自哪裡?
資料完整性：
這些問題能幫助我們在建構資料庫時定義完整性限制。
哪些資料是必須填寫的?(eg: 一條客戶記錄必須有電話資訊嗎?)
資料的有效域是什麼?(eg: 電話号碼是否有格式規定?位址資料應有多長?)
系統是否需要根據郵編來檢驗城市的有效性?
系統中是否必須在定義了客戶之後才能下訂單?
系統要求多高的可用性等級?(系統需要7×24的可用性嗎?資料的備份頻率要多高?)
安全性：
這些問題能幫助我們了解客戶對權限控制與審計方面的需求。
是否每個使用者都需要一個不同的密碼?
是否需要控制不同的使用者所能通路的資料?(eg: 銷售代表有權限看到客戶的信用卡賬号，但訂單錄入專員卻不能)
存儲在資料庫中的資料是否需要加密?
誰做了什麼操作是否需要記錄以便于審計?(eg: 記錄銷售代表提高客戶級别的操作，在需要時可以追溯操作的原因)
系統中的客戶分成幾個級别?每個級别的客戶有多少?
是否已有文檔記錄了使用者的工作與權責?
環境：
這些問題能幫助我們了解目前項目将代替其他什麼系統或流程，以及項目将與其他哪些系統進行互動。
1.目前項目是要代替或更新現有的某系統嗎?
•是否有描述現有系統的文檔?
•現有系統的哪些功能是需要的?哪些是不需要的?
•現有系統處理些什麼資料?這些資料是如何存儲的?資料之間是如何關聯的?
•是否有關于現有系統資料的文檔?
2.目前項目必須與其他哪些系統互動?
•項目與其他系統之間如何互動?
•新項目是否需要向現有系統提供資料?如何提供?
•新項目是否需要接收現有系統的資料?如何接收?
•是否有關于其他系統的文檔?
3.客戶的整個業務流程是怎樣的?(了解在整個業務流程中目前項目的作用)
了解我們要設計和搭建的系統的最好方式是詢問客戶。拿着我們在上一步中準備的問題清單安排與客戶進行會面。這不會像閑聊那麼輕松，向客戶了解需求是一個冗長且折磨人的過程。
有時我們的窮追猛問會使客戶筋疲力竭感到不快。在這些時候我們必須更為耐心，可以分幾次多次會議來了解需求，每次針對幾個問題或流程。我們的目标是對我們要解決的問題有一個完全且徹底的了解。
即使我們的項目隻是去解決整個業務中的一小部分問題，我們也要試圖去了解客戶的整體業務流程，這可能會給我們帶來意想不到的收獲。
意識到不同的客戶可能對項目有不同的願景。我們需要分辨出誰是上司，誰是積極支援者，誰是旁觀者，誰是唱反調者。
以下列出了一些常見的客戶角色：
項目發起人——一般是管理層的某位上司，他是項目的最高推動者。他會為項目協調資源，解決項目遇到的一些障礙，但他不會參與到項目每天的事務中。
項目執行負責人——他對于客戶的需求和整個業務最為了解。他是了解使用者需求階段最重要的人，他必須有足夠的時間來幫助我們定義項目目标以及回答我們的問題。當别人對某業務環節遲疑不決時，我們需要向他請教。
客戶代表——客戶代表是回答我們問題的人，他們也可能成為系統的最終使用者。他們可能是某一部分業務的專家，我們需要與多個客戶代表進行訪談來了解業務全貌。
利益相關者——這是項目将影響到的人，其中某些人可能同時也是客戶代表。這些人可能對項目也有興趣，但未必對系統都有發言權。我們在進行系統設計時也需要考慮對這些人的影響(特别是附帶損害)。
唱反調者——這是我們需要關注的一些人。如果唱反調者隻是讓其他人理性或現實地來看待項目，而并不是徹底反對這個項目的話，他将是我們非 常好的資源，他将幫助我們說服其他對項目抱有不切實幻想的客戶。而如果唱反調者對整個項目抱有抵觸時，我們就必須非常小心，有時需要項目執行負責人出面來 協調這些人。
一旦搞清楚誰是誰之後，我們就要與項目執行負責人讨論客戶需要什麼。客戶希望的解決方案是怎樣的，需要包含什麼資料，怎樣呈現，以及不同資料之間如何關聯。
與盡可能多的利益相關者進行交流，我們需要考慮每個人的意見，但心中要牢記項目執行負責人最為了解客戶的需求并具有最終決定權。
根據項目的規模，這一過程短則幾個小時，長則需要幾周才能完成。
觀察客戶每日的工作能幫助我們更好的了解業務。如果我們能做一會兒客戶的工作來了解其中包括的内容那就最好了。
即使我們不能實際嘗試客戶的工作，一般我們還是可以坐在他們身邊近距離觀察。告訴客戶我們将稍稍降低他們的工作效率并問一些愚蠢且惱人的問題，之後 我們就可以開問了。在這個過程中要進行記錄，學習盡可能多的東西。有些時候外行者的一些看法可能轉化為客戶怎麼也不會想到的好主意。
在嘗試客戶的工作之後，我們還可以看一下是否有其他途徑能了解現有流程。通常公司有描述客戶角色和職責的操作手冊或文檔。
尋找客戶現在使用的資料存儲方式，可能是關系型資料庫系統或是電子表格或是紙質的單據等等。了解這些資料是怎樣使用的，之間是如何關聯的。一般實體資料庫之間是通過包含備援資訊來互相關聯的，如：客戶id。
此刻我們已經對客戶的業務和需求較為了解了。為了确認沒有什麼遺漏，我們需要安排頭腦風暴。召集項目執行負責人和盡可能多的客戶代表與利益相關者，向他們描述前期了解到的需求情況，之後讓他們暢所欲言談談其中有什麼問題或還缺什麼。
在這個過程中我們不急于答應或排除任何客戶的要求，我們先把客戶說到的東西記錄下來，并确定這些方面我們已經考慮到了。在正式開發前，我們會與項目執行負責人一起根據項目的規模與傳遞期限确定需求的優先級。
在頭腦風暴過程中思考一下将來的需求。問問客戶他們的業務在将來是否會變化或他們希望系統将來能包含什麼功能。
我們可以把他們的一些想法放入目前的項目中，即使不能也可以使我們知道将來可能會有些什麼擴充，在設計資料庫時我們能預先留有餘地。
一些熱心且懂些技術的使用者會跑來建議我們如何設計系統，應該建立怎樣結構的資料表。我們可能覺得這些建議毫無意義甚至可笑。但在忽視這些建議之前我 們應謹慎思考使用者提出這些建議或質疑的深層原因是什麼。客戶比我們更了解業務，他們的建議或質疑中可能蘊含着我們還未了解到的業務變化點或某些特殊業務情 況。
有時客戶并不了解自己的真正需求。他們能看到問題的表象，但未必清楚其根源。我們需要幫助客戶尋找到問題的根源并針對問題的源頭提出解決方案。
有時客戶認為資料庫或新系統能神奇般的提高銷售，減少成本。事實上一個設計精良的資料庫能減少輸入差錯，提高操作效率，提供資料報表，幫助客戶管理資料等等。我們在與客戶溝通的過程中需要告訴他們新系統能做些什麼，不能做些什麼，讓客戶建立起正确的預期。
經過先前的步驟，我們已列出一張長長的期望功能清單。其中的某些功能可能不切實際或超出了目前項目的範疇。為了使項目規模可控，我們要與客戶一起定義功能的優先級。
一般我們可以把功能分為三個等級。第一優先級是在本期開發中必須包含的功能，沒有完成這些功能意味着項目的失敗。第二優先級是可以放到下一期開發的 功能，當第一優先級的功能完成後，我們可以把第二優先級的部分功能提到當期開發。第三優先級是那些相對不重要或超出項目範疇的功能，我們可以忽略這些功 能。
有些情況下優先級是可能轉化的。當第一優先級的某功能非常難實作時，我們可以與客戶進行溝通，确認該功能是否如此重要，是否能移到第二優先級中以避 免影響項目進度。當第二優先級中的某些功能很容易實作，我們可以把該功能調整到第一優先級清單中。但做這些調整之前必須與客戶溝通，得到客戶的認可。
驗證你的了解
梳理我們對業務和需求的了解，并一一與客戶進行确認。當客戶說“但是”、“除了”、“有時”等詞時，我們要特别當心，确認客戶隻是強調了我們已經知道的東西，而沒有出現新的情況。在這個階段客戶可能會想到他們之前沒有考慮到的例外情況。
例外情況是資料庫設計的大害。在需求分析階段把例外情況挖掘出來，我們才能在資料庫設計時有所準備。例如，我們向客戶确認退貨流程說：“到這裡收貨 員會輸入rma号并點選完成按鈕是嗎?”客戶可能會說：“嗯…這是大多數情況，但有時沒有rma号，收貨員會填入none。”這就是一個客戶之前沒有告訴 我們的重要例外情況，我們必須立刻記錄下來。再有一個例子，假設客戶使用的紙質訂單有配送位址與賬單位址兩個欄目。我們向客戶确認時說：“訂單需要有一個 配送位址和一個賬單位址。”客戶打斷說：“有時我們需要兩個配送位址，因為訂單不同部分可能要送到不同的地方。”，并找出一張訂單，第二個配送位址被标注
在訂單的邊沿處。這是一個重大例外，在紙上可以很容易的進行标注，但在資料庫的一個表單元中增加一個位址是不可能的。隻有知道這一例外，我們才能用設計的 方法解決這一需求。
需求文檔描述了我們要建構的系統，該文檔也被稱為需求規格說明。需求文檔要講清楚我們将建構怎樣的系統，該系統會完成什麼工作，包含哪些功能點，并描述客戶如何使用該系統來解決他們的問題。需求文檔明确了項目将完成的功能，這也避免了系統傳遞時出現争執的情況。
需求文檔中應定義可傳遞成果，即裡程碑。裡程碑是可直覺展現并能驗證的中間成果。客戶通過裡程碑能衡量項目的進度。在需求文檔中還需定義最終傳遞成果，這也是确定項目是否完成的标準。
用例圖是一種非常好的需求分析工具，可以作為需求文檔的一部分。用例圖的最主要功能就是用來表達系統的功能性需求或行為。用例圖從業務角度上展現誰 來使用系統、使用者希望系統提供什麼樣的服務，以及使用者需要為系統提供的服務，也便于軟體開發人員最終實作這些功能。在官方文檔中用例圖包含六個元素，分别 是：參與者(actor)、用例(use case)、關聯關系(association)、包含關系(include)、擴充關系(extend)以及泛化關系 (generalization)。但是有些uml的繪圖工具多提供了一種直接關聯關系(directed
association)。
參與者：是指使用者在系統中扮演的角色
用例：是指外部可見的系統功能，對系統提供的服務進行描述
關聯關系：連接配接參與者和用例，表示該參與者代表的外部系統實體與該用例描述的系統需求有關
包含關系：是來自于用例的抽象，即從數個不同的use case中，分離出公共的部分，而成為可以複用的用例
擴充關系：表示某一個用例的對話流程中，可能會根據條件臨時插入另外一個用例，而前者稱為基礎用例後者稱為擴充用例
泛化關系：一個用例可以被特别列舉為一個或多個用例，這被稱為用例泛化
eg：使用者管理的用例圖如下所示，圖中人形圖示表示參與者，橢圓表示用例（圖的出處請參見“總結與參考”）
主要内容回顧
1. 搞清哪個客戶扮演哪個角色
2. 從客戶的腦海中挖掘資訊
3. 尋找關于使用者角色、職責、現有流程和現有資料的文檔
4. 觀察客戶的工作，學習他們的業務操作
5. 進行頭腦風暴，把收集到的功能需求點按優先級分成第一、第二和第三級
6. 确認對客戶需求的了解
7. 撰寫需求文檔，包含可驗證的裡程碑和用例
參考：
<a target="_blank" href="http://blog.sina.com.cn/s/blog_77500e110100wy47.html">http://blog.sina.com.cn/s/blog_77500e110100wy47.html</a>