開發(fā)BI系統(tǒng)時的需求分析研究
我們知道MIS,知道ERP，知道GIS等等，這些系統(tǒng)在管理限制上有很多的沖突，管理和被管理，開放和限制等等，然而BI在開始就不是這樣的。BI要求的就是易用還要易于擴展，首先是報表，這個是你無條件的需要去做的，其次是adhoc和analysis，同樣的崗位有不同的需求，這不是權(quán)限，管理等等的需要，而是一種習慣。
實施BI project的時候，我們經(jīng)常遇到這樣的情況：
1：花少量的時間去理解客戶的要求，比如reporting，了解一般的字段的數(shù)據(jù)出處，然后就開始data modeling，開始搭建DW，ETL等等。
2：中間出現(xiàn)大量的業(yè)務(wù)計算。
3：客戶需求修改，增加需求。
4：數(shù)據(jù)不完整，數(shù)據(jù)口徑不一致。
5：性能底下。
6：schedule delay。
然后：
1：重新調(diào)研需求，了解維度數(shù)據(jù)，實時數(shù)據(jù)，關(guān)系計算。
2：修改模型，etl process，cube。
3：重新設(shè)計接口。
如果處理不當，我們可能會遇到一下幾種情況。
1：overtime
2：rework again and again
3：restructure
4：game over
不管是哪一種，都是我們不愿意去看到的，我們沒有辦法去指責用戶的需求對不對，應(yīng)該不應(yīng)該。他們是付錢了的，我們做得就是一種services，如果我們遇到這樣的問題應(yīng)該怎么辦了，應(yīng)該怎么去分析了。或者說事前應(yīng)該做一些什么樣的準備了。
這其實需要一種平衡，客戶需求和公司利潤，當然，如果是甲方自己去做的話，那就是不滿意和責罰之間去平衡了。
很多人會說當初定下來的范圍邊界，如果有需求重新增加的話，只能放到第二期里面去。其實這樣的辦法其實也是一種辦法，只是可以對新的需求，有一個工作量的評估吧。
其實我們定需求的時候可以由大到小，還要兼顧將來系統(tǒng)的擴展性。
當前情況：
1：用戶的使用習慣，包括如何分析數(shù)據(jù)，如何查找數(shù)據(jù)，如何在reporting導出數(shù)據(jù)，自己進行的處理。
2：用戶的使用不便之處，包括計算，查詢數(shù)據(jù)，統(tǒng)計，甚至在EXCEL里面做的變動或者計算。
3：現(xiàn)有系統(tǒng)的權(quán)限設(shè)置。
4：數(shù)據(jù)統(tǒng)計時間，生成時間，歸檔時間，匯報時間等等。
邊界需求
1：確認業(yè)務(wù)邊界，BI，BI，business在前面，所以我們必須先了解業(yè)務(wù)上的邊界在哪里，很多公司在HR和finance都比較保密，這些都不納入DW/BI的范圍，那我們就要確定清楚，是不是真的不納入，如果中途納入的話應(yīng)該怎么處理。這些我們可以留下接口，將HR和finance綜合在一起。
2：確認系統(tǒng)邊界，就是這個project包含哪些源系統(tǒng)，這些源系統(tǒng)又有什么特點，數(shù)據(jù)量，表，還有各個系統(tǒng)的詳細描述，特點，已經(jīng)相互間的邏輯關(guān)系等等，這些東西就和我們將來做data profiling和ETL有關(guān)系了。
3：確認功能邊界，就是做Ad-hoc，reporting，analysis，dashboard等等，需要這些嗎，每一種的具體需求又是什么，包含多少的量，每一種的dimension對應(yīng)的又是什么，reporting的格式，數(shù)據(jù)源 ，dashboard的對應(yīng)的KPI是什么等等，在查詢，查找，參看數(shù)據(jù)的時候，需要哪些功能。
權(quán)限需求
1：確認系統(tǒng)將來使用，開始上線和最終平穩(wěn)使用時涉及到的部門，人員，還有每個人的權(quán)限。
2：確認系統(tǒng)需要涉及到的維度，部門，時間，產(chǎn)品等等，往往權(quán)限是和這些維度有關(guān)系的。
3：將來如何去控制用戶的訪問權(quán)限，是有windows的AD控制還是ldap控制，或者用維度和用戶關(guān)系表去空，考慮以后如果發(fā)生變化，時候便于維護，如何去做一個維護權(quán)限的UI。
數(shù)據(jù)質(zhì)量
1：各功能（adhoc，reporting，analysis，dashboard）涉及到的數(shù)據(jù)表結(jié)構(gòu)。
2：分析各系統(tǒng)的數(shù)據(jù)質(zhì)量，***有數(shù)據(jù)質(zhì)量報告。包括維度，空值，一致性，完整性的檢查。
需求記錄
不管我們和用戶談到什么，只要是和系統(tǒng)有關(guān)系的，***能寫出報告的形式，然后再和用戶討論，談?wù)勀愕睦斫猓从脩羰欠裾J可，有記錄，我們不一定要用戶去簽字，只是為了以后我們出現(xiàn)人員變動或者***做UAT測試的時候方便。
如果你真的沒有時間做上面的這些事情，那你一定要做好一下的工作。
1：多多了解系統(tǒng)各個崗位的人員的要求，不管是Ad-hoc，reporting，還是analysis，dashboard，聽聽他們所說什么，有什么要求。
2：分析主題，歸納需求的相似點。看看有沒有統(tǒng)一實現(xiàn)的方法。
3：逐個的去完成用戶的功能，記住，要一個一個的去完成，完成一個后，就和相應(yīng)的人員去確認是否是他想要的。不行就again。
4：關(guān)注說話有分量的人，比如leader，mananger或者high level manager等等，多和他們溝通，或者盡量完成他們的要求，做到他們滿意。
其實需求分析不僅只是在項目開始的時候做，如果我們吧BI/DW的項目當作一個過程的話，每一個時間點都可可以看做是一個小項目的開始。
【編輯推薦】
