前面我們已經(jīng)就數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個(gè)階段進(jìn)行了討論。在這些階段中，常常會(huì)出現(xiàn)這樣的關(guān)鍵時(shí)刻，即數(shù)據(jù)庫開發(fā)人員必須獲取繼續(xù)進(jìn)行數(shù)據(jù)庫系統(tǒng)開發(fā)所必需的實(shí)況（fact）。這些必要的實(shí)況包括該企業(yè)使用的工作術(shù)語、在使用當(dāng)前系統(tǒng)時(shí)遇到的問題、新系統(tǒng)可能為企業(yè)帶來的機(jī)遇、新的系統(tǒng)中對(duì)數(shù)據(jù)和用戶添加的必要的約束、新系統(tǒng)中需求的輕重緩急程度。要想獲得這些實(shí)況就需要借助于實(shí)況發(fā)現(xiàn)（fact-finding）技術(shù)。

實(shí)況發(fā)現(xiàn)（fact-finding）：使用面談、問卷調(diào)查等技術(shù)手段收集關(guān)于系統(tǒng)、需求和優(yōu)先考慮（preference）等實(shí)況信息的規(guī)范化過程。

1. 使用實(shí)況發(fā)現(xiàn)技術(shù)的時(shí)機(jī)

在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期中有很多的時(shí)機(jī)可以使用實(shí)況發(fā)現(xiàn)技術(shù)，但是，在生命周期的前期階段，包括數(shù)據(jù)庫規(guī)劃、系統(tǒng)定義和需求收集與分析階段，實(shí)況發(fā)現(xiàn)顯得尤為關(guān)鍵。在這些階段，數(shù)據(jù)庫開發(fā)人員需要獲取一些重要的實(shí)況，這些實(shí)況是數(shù)據(jù)庫系統(tǒng)開發(fā)所必須的。盡管在數(shù)據(jù)庫設(shè)計(jì)以及生命周期的后期階段也會(huì)用到實(shí)況發(fā)現(xiàn)技術(shù)，但其重要性沒有在前期階段那么強(qiáng)。比如，在物理數(shù)據(jù)庫設(shè)計(jì)期間，當(dāng)數(shù)據(jù)庫開發(fā)人員試圖了解更多的關(guān)于 DBMS 選型的信息時(shí)。，會(huì)用到實(shí)況發(fā)現(xiàn)技術(shù)。同樣，在最后的運(yùn)行維護(hù)階段，可以應(yīng)用實(shí)況發(fā)現(xiàn)技術(shù)來確定系統(tǒng)是否需要調(diào)優(yōu)以提高性能，或者未滿足新的需求而進(jìn)一步開發(fā)。

注意，對(duì)于一個(gè)數(shù)據(jù)庫項(xiàng)目，實(shí)現(xiàn)對(duì)實(shí)況發(fā)現(xiàn)所需的時(shí)間和投入做一個(gè)大概的估計(jì)是非常重要的。前面曾提到，考慮過細(xì)會(huì)陷入分析僵局（paralysis by analysis），然而，考慮過粗會(huì)導(dǎo)致在理解錯(cuò)誤的基礎(chǔ)上繼續(xù)尋求錯(cuò)誤的解決方案，從而導(dǎo)致不必要的時(shí)間和金錢的浪費(fèi)。

2. 收集實(shí)況的類型

在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期期間，數(shù)據(jù)庫開發(fā)人員需要獲取現(xiàn)有系統(tǒng)或新系統(tǒng)的實(shí)況。下表的示例中給出了在生命周期各個(gè)階段需要采集的數(shù)據(jù)分類以及每個(gè)階段生成的文檔。前文曾提到過，數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個(gè)階段并非嚴(yán)格遵循既有順序，而是存在一定程度的迭代，即通過反饋重復(fù)先前階段的活動(dòng)。對(duì)于數(shù)據(jù)采集和文檔的生成也是如此。比如，在數(shù)據(jù)庫設(shè)計(jì)階段遇到的問題可能有必要重返需求收集與分析階段，以采集更多的數(shù)據(jù)。

3. 實(shí)況發(fā)現(xiàn)技術(shù)

數(shù)據(jù)庫開發(fā)人員在一個(gè)數(shù)據(jù)庫項(xiàng)目的開發(fā)期間通常會(huì)使用幾種實(shí)況發(fā)現(xiàn)技術(shù)，以下是五種經(jīng)常使用的實(shí)況發(fā)現(xiàn)技術(shù)：

3.1 分析文檔資料

分析文檔資料有助于了解一些內(nèi)幕信息，比如對(duì)數(shù)據(jù)庫的需求是如何提出的。此外，還可以幫助我們找到與解決所遇問題有關(guān)的企業(yè)這一方的有用信息。如果問題與當(dāng)前運(yùn)行的系統(tǒng)相關(guān)，那么就應(yīng)該存在與該系統(tǒng)相關(guān)的文檔資料，通過分析這些文檔、表單、報(bào)表和文件，便能夠迅速的理解該系統(tǒng)。

3.2 面談

面談是最常使用，通常也是最有用的實(shí)況發(fā)現(xiàn)技術(shù)。面談通過與人面對(duì)面的交流來收集信息。使用面談?dòng)羞@樣幾個(gè)目的：發(fā)現(xiàn)實(shí)況、核實(shí)實(shí)況、澄清實(shí)況、激發(fā)熱情、使終端用戶也參與進(jìn)來、明確需求、匯集想法和意見。然而，面談技術(shù)的使用需要良好的溝通技能，只有這樣才能有效的與那些具有不同價(jià)值觀、地位、想法、動(dòng)機(jī)和個(gè)性的人交流。同其他的實(shí)況發(fā)現(xiàn)技術(shù)相比，面談并不是對(duì)所有情形都是最好的方法。

面談的方式有兩種：無組織的和有組織的。無組織的面談 在訪問者的腦海里只有一個(gè)大概的目標(biāo)。幾乎沒有什么明確的問題。訪問者依靠被訪問者建立面談的框架，由被訪問者引導(dǎo)面談的方向。無組織的面談通常會(huì)偏離談話的主題，也正是由于這個(gè)原因，這類會(huì)談對(duì)數(shù)據(jù)庫的分析和設(shè)計(jì)幫助并不大。

在 有組織的面談 中，訪問者準(zhǔn)備了一組明確的問題對(duì)被訪問者提問。根據(jù)被訪問者的回答，訪問者將提出更多的問題以澄清問題或?qū)栴}加以擴(kuò)展。開放式問題（open-ended question）允許被訪問者隨心所欲的回答，只要言之有理即可。例如 “你為什么對(duì)客戶注冊(cè)報(bào)表不滿意？” 就是一個(gè)開放式問題。封閉式問題（closed-ended question）將答案限定為要么給出明確的選擇要么簡(jiǎn)短的直接回答?！澳闶欠衲軌驕?zhǔn)時(shí)收到客戶的注冊(cè)報(bào)表？” 或者 “用戶注冊(cè)報(bào)表上的信息是否正確？” 都屬于封閉式問題，這兩個(gè)問題僅僅需要回答 “是” 或 “不是”。

要想保證面談的成功，需要選擇合適的被訪問者、事先做好充分準(zhǔn)備以及以高效且有效的方式引導(dǎo)面談的進(jìn)行。

3.3 觀察企業(yè)的運(yùn)作

要理解一個(gè)系統(tǒng)的運(yùn)作方式，最有效的實(shí)況發(fā)現(xiàn)技術(shù)就是觀察。應(yīng)用這種技術(shù)，你就有可能通過親身參與或僅僅是在一旁觀看一個(gè)人的活動(dòng)來了解系統(tǒng)。當(dāng)對(duì)采用其他方法收集到的有效數(shù)據(jù)還存在疑問時(shí)，或者由于系統(tǒng)某些方面的復(fù)雜性使得終端用戶無法清楚解釋時(shí)，觀察就會(huì)顯得特別有用。

與其他的實(shí)況發(fā)現(xiàn)技術(shù)不太一樣，成功的觀察需要精心的準(zhǔn)備。為了確保觀察的成功，很重要的一點(diǎn)事盡可能多的了解將要觀察的人或業(yè)務(wù)活動(dòng)。例如，觀察者需要深入了解 “所要觀察的業(yè)務(wù)活動(dòng)的低發(fā)、正常和高峰時(shí)段分別是什么時(shí)候？” 以及 “若有人在旁觀察并記錄，被觀察者的行為是否會(huì)失常？” 等問題。

3.4 研究

另一種有用的實(shí)況發(fā)現(xiàn)技術(shù)是就應(yīng)用和問題本身進(jìn)行詳細(xì)研究。計(jì)算機(jī)行業(yè)期刊、參考書籍和因特網(wǎng)（包括用戶組和公告板）都是很好的信息資源。這些信息資源能夠提供別人解決相似問題的方法，以及是否存在能夠解決或者部分解決該問題的軟件包。

3.5 問卷調(diào)查

通過問卷的方式進(jìn)行調(diào)查也是一種實(shí)況發(fā)現(xiàn)技術(shù)。問卷調(diào)查表是一類具有特定目的的文檔，利用問卷調(diào)查表能夠從大量的人群中收集實(shí)況，并且答案具有一定的可控性。當(dāng)面對(duì)大量的被調(diào)查者時(shí)，沒有哪種實(shí)況發(fā)現(xiàn)技術(shù)能夠像問卷調(diào)查一樣如此高效的收集到同樣多的實(shí)況信息。

問卷調(diào)查表里可以包括兩類問題，即自由格式和固定格式的問題。自由格式的問題 為回答問題者在作答時(shí)提供了較大的自由度。在問題后面，留有相應(yīng)的空白用來作答。自由格式的問題有 “你通常會(huì)收到哪些報(bào)表？ 如何使用它們？” 以及 “這些報(bào)表有什么問題嗎？ 如果有，請(qǐng)說明?！钡?。自由格式問題的難點(diǎn)在于被問卷者的答案難于列表統(tǒng)計(jì)，有的還可能答非所問。

固定格式的問題 需要明確作答。對(duì)于每一個(gè)問題，被問卷者都必須從給出的答案中選擇。這樣，很容易對(duì)問卷結(jié)果進(jìn)行列表統(tǒng)計(jì)。但從另一方面來看，被問卷者可能無法提供一些也許有用的額外信息。固定格式問題的示例是：“當(dāng)前適用的房屋的租賃報(bào)表是切實(shí)可行的，無需更改。” 被問卷者可能需要從 “是” 或 “否” 中選擇，或者從 “完全同意” “同意” “沒有意見” “不同意” 和 “強(qiáng)烈反對(duì)” 中選擇。

4. 使用實(shí)況發(fā)現(xiàn)技術(shù)的實(shí)例

這個(gè)小節(jié)首先概述 DreamHome 案例研究，然后使用該案例討論如何建立一個(gè)數(shù)據(jù)庫項(xiàng)目。我們將使用圖表的方式示范如何在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的前期階段（即數(shù)據(jù)庫規(guī)劃、系統(tǒng)定義和需求收集與分析階段）使用實(shí)況發(fā)現(xiàn)技術(shù)以及生成相應(yīng)的文檔。

4.1 DreamHome 案例研究——概述

1992 年，DreamHome 在英國(guó)的格拉斯哥（Glasgow）的第一家分公司開業(yè)。從那以后，這家公司穩(wěn)步發(fā)展，目前其分公司已經(jīng)遍布英國(guó)大多數(shù)的主要城市，甚至同一個(gè)城市擁有幾家分公司。然而，隨著公司規(guī)模的擴(kuò)大，需要聘用越來越多的員工處理日益增長(zhǎng)的大量文案工作。更糟糕的是，即使是在同一個(gè)城市里，各分公司之間也缺乏信息交流和信息共享。公司負(fù)責(zé)人 Sally Mellweadows 察覺到已經(jīng)有太多的錯(cuò)誤發(fā)生，如果她不及時(shí)采用措施挽救現(xiàn)狀的話，公司的成功將不會(huì)長(zhǎng)久。Sally 認(rèn)為數(shù)據(jù)庫可以解決一部分問題，并因此提出開發(fā)一個(gè)數(shù)據(jù)庫系統(tǒng)以支持 DreamHome 的運(yùn)作。她簡(jiǎn)要描述了 DreamHome 通常的運(yùn)作方式。

DreamHome 專門從事房地產(chǎn)管理，在希望出租房屋的業(yè)主和需要租賃房屋的客戶之間擔(dān)當(dāng)中介，DreamHome 目前擁有 100 個(gè)分公司，大約有 2000 名員工。當(dāng)有新員工進(jìn)入公司工作時(shí)，需要填寫 DreamHome 員工注冊(cè)表。