需求分析在數據庫生命週期中至關重要，通常也是涉及人員最多的步驟。數據庫設計師在這個階段必須走訪最終用戶，與他們進行訪談，從而確定用戶想在系 統中存儲什麼數據以及想怎樣使用這些數據。
我們將需求分析分爲兩個步驟：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：用戶管理的用例圖如下所示，圖中人形圖標表示參與者，橢圓表示用例（圖的出處請參見“總結與參考”）
主要內容回顧
-
搞清哪個客戶扮演哪個角色
-
從客戶的腦海中挖掘信息
-
尋找關於用戶角色、職責、現有流程和現有數據的文檔
-
觀察客戶的工作，學習他們的業務操作
-
進行頭腦風暴，把收集到的功能需求點按優先級分成第一、第二和第三級
-
確認對客戶需求的理解
-
撰寫需求文檔，包含可驗證的里程碑和用例
參考：
http://blog.sina.com.cn/s/blog_77500e110100wy47.html