我们知道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的项目当作一个过程的话，每一个时间点都可可以看做是一个小项目的开始。