关于DWBI项目需求收集的一些思考

对于用户的需求，一定要想清楚目的是什么，对于业务分析有什么样的帮助。而不是简单的为了数据仓库而数据仓库。

我们常常可以听到：这 是客户需求，客户要求这么做的。这是一个非常危险的信号！这句话通常意味着我们对于需求还没有深刻理解和把握。需求收集应该是一个不断访谈的过程，是一个交互的过程，而不是一个简单灌输的过程。访谈最终用户是主动的需求收集方式；而灌输，则是非常被动的方式。灌输的方式表现为，在数据仓库初期，我们可能会收到各种各样的报表 表样，用以帮助理解客户的各种业务KPI和分析维度。然后会一次集中的类似于疑问解答的会议，客户业务部门帮助解释表样中KPI含义。之后，开发团队就基 于这些所谓的“报表需求“，以及对源系统的简单调研，开始了后续的设计和开发任务。这种方式，是一种非常危险而原始的需求收集方式和开发模式。不可否认， 报表应用是BI应用最广大，也是最基础的应用之一，但是，一旦我们把项目目标只定义为报表输出，那么，这个BI系统最终只能沦落为一个“报表平台“。甚至 可能是一个维护性很差的报表平台。因为设计人员的着眼点可能就是那么几张报表。如果我们对于需求的理解有限，如何指望底层模型健壮而灵活？报表需求一定是 层出不穷的，随着业务的发展，业务分析人员的不断成熟，他需要的数据越来越多，越来越细，分析角度变化多端，原先的报表终究无法满足他分析需要。这时，需 要不断变更模型和架构以满足日益增长，新的报表需求，如此，日积月累，原有的模型和架构必然坍塌。

而主动的需求收集方式，应当是循序渐进 的，不断访谈，沟通的过程，这需要需求收集人员有比较深的相关业务背景。才有可能与业务部门持续沟通，而不是刚一接触，除了被动接受需求，就没茬了。

在 一些不太成熟或者不够专业的BI团队中，对于需求收集的过程，大多是被动的过程。与业务部门沟通极少，只有零星的几次碰面。碰到问题，也仅仅是和客户的技 术接口人打个照面，这种方式，无法理解客户的业务过程，无法了解业务部门的关注重点，自然也无法实施出令人满意的BI系统。业务部门对于BI系统的体验和 评价好坏，才真正决定了BI项目的成败与否。

有时候，用户可能会提出一些非常奇怪的需求，比如，一些看似不具备公共维度的度量，需要在报表 中一同展现。那么，这种分析的意义何在呢？是我们对需求理解有误？又或者其实业务用户就是希望有一张信息量大而全的报表，而不太关注各度量之间的内在联系 呢？

与业务部门紧密而持续沟通，是保证BI项目成功的必要举措。或许，有人会认为，这样会显得我们的团队不够专业，怎么老是要去麻烦客户，问这问那。有这样的顾虑，基本上由于甲方过于强势，乙方实施能力不强，底气不足。而实际上，对于业务需求没有半点疑问或者只有很少疑问的团队，才是真正意义上不够专业的团队。这样的团队实施出来的BI多半是经不住时间考验的。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12870376/viewspace-1034941/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12870376/viewspace-1034941/