开发BI系统时的需求分析研究

3/20/2013 10:56:42 AM

我们知道MIS,知道ERP,知道GIS等等,这些系统在管理限制上有很多的冲突,管理和被管理,开放和限制等等,然而BI在开始就不是这样的。BI要求的就是易用还要易于扩展,首先是报表,这个是你无条件的需要去做的,其次是adhoc和analysis,同样的岗位有不同的需求,这不是权限,管理等等的需要,而是一种习惯。

实施BI project的时候,我们经常遇到这样的情况:

1:花少量的时间去理解客户的要求,比如reporting,了解一般的字段的数据出处,然后就开始data modeling,开始搭建DW,ETL等等。

2:中间出现大量的业务计算。

3:客户需求修改,增加需求。

4:数据不完整,数据口径不一致。

5:性能底下。

6:schedule delay。

然后:

1:重新调研需求,了解维度数据,实时数据,关系计算。

2:修改模型,etl process,cube。

3:重新设计接口。

如果处理不当,我们可能会遇到一下几种情况。

1:overtime

2:rework again and again

3:restructure

4:game over

不管是哪一种,都是我们不愿意去看到的,我们没有办法去指责用户的需求对不对,应该不应该。他们是付钱了的,我们做得就是一种services,如果我们遇到这样的问题应该怎么办了,应该怎么去分析了。或者说事前应该做一些什么样的准备了。

这其实需要一种平衡,客户需求和公司利润,当然,如果是甲方自己去做的话,那就是不满意和责罚之间去平衡了。

很多人会说当初定下来的范围边界,如果有需求重新增加的话,只能放到第二期里面去。其实这样的办法其实也是一种办法,只是可以对新的需求,有一个工作量的评估吧。

其实我们定需求的时候可以由大到小,还要兼顾将来系统的扩展性。

当前情况:

1:用户的使用习惯,包括如何分析数据,如何查找数据,如何在reporting导出数据,自己进行的处理。

2:用户的使用不便之处,包括计算,查询数据,统计,甚至在EXCEL里面做的变动或者计算。

3:现有系统的权限设置。

4:数据统计时间,生成时间,归档时间,汇报时间等等。

边界需求

1:确认业务边界,BI,BI,business在前面,所以我们必须先了解业务上的边界在哪里,很多公司在HR和finance都比较保密,这些都不纳入DW/BI的范围,那我们就要确定清楚,是不是真的不纳入,如果中途纳入的话应该怎么处理。这些我们可以留下接口,将HR和finance综合在一起。

2:确认系统边界,就是这个project包含哪些源系统,这些源系统又有什么特点,数据量,表,还有各个系统的详细描述,特点,已经相互间的逻辑关系等等,这些东西就和我们将来做data profiling和ETL有关系了。

3:确认功能边界,就是做Ad-hoc,reporting,analysis,dashboard等等,需要这些吗,每一种的具体需求又是什么,包含多少的量,每一种的dimension对应的又是什么,reporting的格式,数据源 ,dashboard的对应的KPI是什么等等,在查询,查找,参看数据的时候,需要哪些功能。

权限需求

1:确认系统将来使用,开始上线和最终平稳使用时涉及到的部门,人员,还有每个人的权限。

2:确认系统需要涉及到的维度,部门,时间,产品等等,往往权限是和这些维度有关系的。

3:将来如何去控制用户的访问权限,是有windows的AD控制还是ldap控制,或者用维度和用户关系表去空,考虑以后如果发生变化,时候便于维护,如何去做一个维护权限的UI。

数据质量

1:各功能(adhoc,reporting,analysis,dashboard)涉及到的数据表结构。

2:分析各系统的数据质量,最好有数据质量报告。包括维度,空值,一致性,完整性的检查。

需求记录

不管我们和用户谈到什么,只要是和系统有关系的,最好能写出报告的形式,然后再和用户讨论,谈谈你的理解,看用户是否认可,有记录,我们不一定要用户去签字,只是为了以后我们出现人员变动或者最后做UAT测试的时候方便。

如果你真的没有时间做上面的这些事情,那你一定要做好一下的工作。

1:多多了解系统各个岗位的人员的要求,不管是Ad-hoc,reporting,还是analysis,dashboard,听听他们所说什么,有什么要求。

2:分析主题,归纳需求的相似点。看看有没有统一实现的方法。

3:逐个的去完成用户的功能,记住,要一个一个的去完成,完成一个后,就和相应的人员去确认是否是他想要的。不行就again。

4:关注说话有分量的人,比如leader,mananger或者high level manager等等,多和他们沟通,或者尽量完成他们的要求,做到他们满意。

其实需求分析不仅只是在项目开始的时候做,如果我们吧BI/DW的项目当作一个过程的话,每一个时间点都可可以看做是一个小项目的开始。