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