BI传奇 之 龙虎斗（上）

刘庆
20060320

跨入二十一世纪，在遥远的米国，在商务智能领域（其实更确切地说应当叫做数据仓库领域）有两大门派，都是教众很多，却为了各自掌门的一些理念在不停地争论着。这¬两大门派就是郁闷派和球派，掌门分别就是郁闷先生和金球先生。其中郁先生被称为现代数据仓库之父，因为他对数据仓库的定义比较流行。而金先生，则没有如此炫目的¬头衔，但在数据仓库实施方面提供了丰富的方法论和技巧。

就在两派教众对峙，为一些无谓的问题，诸如自上而下或是自下而上、维度建模还是第三范式争论的时候。其实他们不知道一个秘密，一个封存二十多年的秘密。但世上没¬有不透风的墙，终于有一天，一份绝密的叉叉档案中，记录了这段往事。

那还是上个世纪六七十年代的事情了，郁闷和金球都正当少年，青春焕发，他们是非常好的朋友，从小一起长大，一起读小学、中学。两人的性格迥异，阿闷外向活泼而阿¬球内向寡言，家境也不一样，郁家也算富甲一方，加上小阿闷长得很帅气，从小便沉迷于于姑娘的戏耍当中。而阿球早年丧父，全由母亲拉扯大。从小学开始，小球就帮助¬小闷写作业以补贴家用，为他们的亲密关系打下基础。后来考大学的时候，大家都能猜得到，阿闷考的不好，当然以其家境来说，花钱上个大学没问题。阿球考的非常好，¬可家里没钱供他上学，因此阿球决定去工作。作为哥们儿，阿闷也不想在念书了，便和阿球一道，找了一家公司上班，两人并肩闯荡江湖。

他们的第一份工作是给公司作经营分析报表。在他们那个年代，作报表是非常痛苦的，数据很不好获取，一大堆零碎的软件系统，还有一些根本就没有系统的。所以，每个¬月初，因为报表做的总是太慢，他们俩经常要被老板骂一通。

久而久之，他们也习惯了，这也不是他们不努力，报表实在太多，数据来源太杂，同一份数据在很多不同地方出现，要梳理他们总是要花费一些时间。有一个月，公司的竞¬争对手搞了几个促销活动，老板非常急于要了解自己公司受到的冲击情况，可他们俩熬了三天三夜才从一堆堆资料里面得到了几张报表。等交给老板时，老板又是大骂一通¬。这次骂得比较难听，并且扬言让他们俩滚蛋。阿闷也非常气氛，一拍桌子，"老子辛辛苦苦搞了这么长时间，你他妈还唧唧歪歪，不干就不干了。"拉着阿球就走了。

两人找了个小酒馆，一人一扎啤酒，商量下一步怎么办，阿闷提议举杯庆贺从此脱离苦海，重拾自由。但阿球的眉宇间似有一丝忧郁。

他说道，"老板确实是非常让人恼火的，不过你有没有发现，我们作报表的时间也确实太长了些，有没有一种办法去缩短这个周期呢？"

阿闷哈哈大笑，"其实要缩短这个周期也容易啊，你看，我们主要的时间都花在哪儿？都在提取数据上面了，他们那个系统也太烂了些。如果有个集中的，稳定地保存历史¬数据，我们分析起来不就容易了吗。"

"闷子，你说的很对，其实我们可以考虑跟老板推荐建立这样的数据中心"，阿球举杯说道。

"别傻了，小球球。老板哪里会听我们的，其实我们可以自己开个公司嘛，你看现在每个公司都得作报表，都没有做的快的。我们就专门搞个帮人作数据整合，提供数据分¬析服务的公司，如何？可以让我爸投点资，不过还有个大问题，我们虽然有这个想法，不过具体还有很多细节不清楚，不知道有没有哪儿可以借鉴的经验哦。"

"嗯，我最近看了一些东方古文化的书籍，在古老的中国，曾经有好多前辈在必爱方面有非常深刻的见解和实战经验，诸如一个姓孙的必爱世家，还有黑皮、猛男等身经百¬战的人，要不我们去取经吧。"

"咋去呢？"

"可以用时间机器，这是我从一本书上学着组装的，可以将人带到任何年代的任何地点，不过我用的都是二手零器件，性能似乎还不是非常稳定，而且只能设定三天的时间¬。"
"好耍好耍，那咱们就动身吧"，阿闷兴奋地和阿球碰了一杯，一饮而尽。

当天晚上，他们就来到阿球的家里，在地窖里面，摆着一个酷似浴缸的玩意儿。哦，原来真的就是用浴缸改装的，在浴缸壁上有许许多多开关和连线。他们俩一起躺进去，¬一人一头，稍稍有些挤。

阿球教阿闷如何设定去往年代和去往地点，大致设在2500年以前的中国，具体地方反正他们也不知道，到哪儿再说吧。

在按下总开关之前，阿球表情严肃地对阿闷说，"闷子，咱们此去会是怎样的结果不好说啊，其实我也是第一次用这个玩意儿，如果出了什么意外，不要怪我啊！"

"妈的，这个时候说这样的废话，都上了贼船了，你不按我来按"，说着，阿闷猛地按下那个红色按钮。飙的一声，两人不见了。

预知后事如何，下回分解。

对于产品和项目的需求分析有什么不同

丁西宁
20060317

请教大家一个问题：

刘庆在“分析问题的模式”中把需求分析分为需求调研和分析两种行为进行描述，那么同样是做需求分析，目标是做产品而非做项目，两者的需求分析又有何不同呢？
公司现在要做一个数据仓库的产品，正出于需求分析阶段。所以请大家给参谋参谋！
Ewen
20060321

个人认为，需求调研对二者没什么不同，主要是在分析阶段，做项目偏重于以解决问题为目的，而做产品要在解决问题的基础上提炼出与业务无关的通用需求。 比如调研时需求为每天根据某个字段（如时间戳）同步营业信息， 做项目，考虑将时间戳区分增量的情况算作一类，甚至直接考虑单个表如何同步都行。 做产品，恐怕要考虑同步方法（增量还是全量）、判断方法（时间戳还是日志）、可实现手段（程序方式、工具方式）等等吧。

Liu Annie
20060321

数据仓库，产品化的道理是曲折和艰难的。

需求调研和分析，是两个不同的内容，调研指的是通过各种途径了解客户需求，不仅限
于和客户探讨，专家建议，行业动向，诸如此类。这个客户，作项目，指的是甲方，研
发产品，是目标客户。需求调研的目的，是想了解客户要什么，目标客户所需要的功能
，系统应包含的内容。需求分析，是指在调研结果的基础上，为了软件开发的需要，粒
度非常细的分析工作。需求分析的结果，是设计人员，可以根据需求分析说明书，进行
概要设计和详细设计了。

数据仓库项目，如果剔除其中业务的东西，剩下的通用需求，估计也不值什么钱了。

Tiger
20060321

*什么是业务？
*什么是业务流程？
*什么是业务需求？
*什么是用户需求？
*什么是软件需求？
*什么是BI需求？

刘庆
20060321

好问！这些名词确实充斥平常的口语甚至文档当中，我先给出自己的理解噢。

**什么是业务？*

1、业务是企业向其客户提供的服务。
例如银行为客户提供储蓄、贷款服务，这是它的业务，电信提供通讯服务，这是它的业务。
2、业务是组织维持自身运作的所有活动。

包括人事、财务、生产等各个对客户的，对伙伴的，对员工的活动，一般在建模的时候，业务指的是这个意思。

**什么是业务流程？*

业务流程是指组织的活动涉及到的人、物，以及活动之间发生的先后顺序、依赖关系。
**什么是业务需求？

*什么是用户需求？*

业务需求和用户需求得放在一块说，因为我区分不出来。

它们都是指软件服务的对象提出的对软件的期望。还未成为现实，甚至未被认可，这是需求调研的结果。

**什么是软件需求？*

软件需求是对软件系统的规格定义，这个软件是什么，不是什么，为谁服务，如何服务，流程如何。这是需求分析的结果，作为软件设计的输入。

**什么是BI需求？*

必爱需求是软件需求的一种，用面向对象术语说，前者是后者的子类，符合软件需求的定义。

Hawk
20060321

我看到happy的问题很困惑，"一个数据仓库的产品"是什么？数据仓库本身并不是一种产品，而是一种体系，组成这个体系会有很多产品，而这些产品并非就是BI¬里经常用的一些产品，其实原来没有出现数据仓库时用的一些产品，依然可以在这种体系里用。而BI经常用的一些工具，同样也可以用于非数据仓库体系的应用里。所以¬要想做一个产品，首先对于这个产品的使用范畴，应该有一个说明，然后其他的人才可以根据你想要做成的产品来分析：这个产品的需求和项目的需求有何不同？同样后期¬的分析也是不一样的。目前能做的产品，我觉的，以中国公司的实力，应该做小而精的东西，而不应该做大而全的东西。能做一个小的东西来，然后OEM到那些列强的产¬品中，我觉的就不简单了。但中国人都认为自己聪明，总想自己来做，但至今为止，在列强的产品中，经常能看到瑞典人，以色列人，爱尔兰人所做的模块，但就不见中国¬人做的，不知中国人聪明到哪里了？

刘庆
20060323

关于这个问题，和西宁私下沟通了过，明晰了一些。其实，我的回答并没有多少集中在差异上，而是对需求应该包含什么提出看法。

主要观点是，需求应该包括对系统边界的描述，不论这个系统是产品还是项目。所谓边界，也就是将这个系统看成一个黑盒子，和外界的交互。"这，是一个黑色的立方体，长45厘米，宽23厘米，高3厘米，盒子的每个角都不尖锐，上方平坦，并有柔软质感；下方在四角之处都有凹进去的螺丝口，可以接杆子，以作凳子用。"

这就是仅仅对其功用的描述，其目标是作凳子用。这可以看作是功能性需求，当然如果还有一些约束，例如"此立方体可以承受300斤胖人之重"，这就可以看作是非功能性需求。但同样还是在描述边界。而对于其内部构造如何，在需求中不要描述，例如盒子是空心的还是实心的，材质用钢板还是木头，这都不是需求，而是已经在设计了。

因此，在描述需求的时候，重要的就是界定系统的内外。看过很多的需求，自己也写过很多的需求，界定内外不是容易的事情。有几个原因，一是没有内外的概念，不知道需求描述的是什么；二是知道内外，然而对于边界的定义，没有足够的词语描述清楚，只能用对系统内部设计来代替。这样的结果是，一份需求书，你搞不清楚它是需求还是设计。

譬如有的需求书，它描述了系统内部模块划分，三层结构，数据存储、中间逻辑等等。比如专题分析的需求中，包含了对挖掘变量的描述，嗬，将上百个变量列在文档中确实能够让页数增加。然而这恐怕不是阅读对象关心的，也不符合分离变化与不变的原则。需求书的阅读对象关心的是系统是什么，而非如何实现。系统是什么是相对不变的，而实现方式却是相对变化的。例如上面盒子的例子，用它作凳子是不变的，而至于用木头或是钢材，是后面考虑，可能会反复变化的。对于专题分析也是如此，这个分析针对的业务问题，诸如哪些客户最有可能离网，这个目标是相对固定的。而你是考虑使用呼转次数或是话费突降的角度来考虑，这是变化的。因此，在需求中，绝对不要将设计的东西加入进去（除非你是想便于说明问题），因为那种东西不能够作为一种"规格"，用于验收、测试的标准。
当然，有时候根据客户在作要求的时候，并非完全从系统边界上考虑，而真的会从系统内部提要求。譬如说，这个凳子，你就得用钢板，不能用木板，至于为什么，可能这仅仅是他的喜好。软件系统也是如此，有时候他会提出要求，你就得用某种产品，你就得用分类模型或者是神经元算法来实现。面对这样的要求，我也不知道该如何在需求书中表述，难道写上一堆系统约束——必须用叉叉产品，不得在系统中出现任何英文字母…？

需求所描述的系统边界，用UML中的用例图来表示是比较简洁的，用例图中的"角色"既是外部与系统交互的人或物或其他系统，"用例"则是系统表现出来的功能，而上面还提到了一些"约束"，不知道在用例图中是否有对应，研究不够。

用例图是起到示意作用，在需求规格说明书中，需要对这些角色、用例、约束进行阐述。例如在描述事务型系统的时候，会涉及到业务流程中参与的各个角色，有必要对每种角色进行定义。而对于一个分析系统，总感觉其流程不似事务型系统般流程清晰，因此，在早期的经营分析系统需求书中，大量篇幅在定义分析主题的维度、度量构成，却忽视，这个分析主题真正的业务目标和流程（谁来用这个多维分析？产生什么输出？）

丁西宁
20060323

hawk老兄的疑问很值得仔细考虑！

很抱歉没有先我们要做的产品的概况给大家介绍出来！其实我是这么认为的：每一个行业，每一种业务都会有很大的差异，需求不同会导致产品定位不同，产品受众不同。如果根据需求来分析产品，可能你们产品适用的，在另一个产品中就不适用。但我想不同的产品之间也许应该有一些共性的东西，尤其是我们都做的是数据仓库，数据分析的应用的，那么共性的东西也许会更多。

没错！数据仓库是一个体系，在这个体系中有很多的产品，有实现数据转换抽取的、有实现数据展现的、有用来生成多维模型的。每一个产品都是为了完成某种功能的。

hawk认为应该做小而精的东西，这个我非常赞同。理由很多，就不一一列了。国外数据仓库厂商做了那么多的工具，留给我们能作的也只有业务块了。他们也提供了很多行业的业务模型，如果这些模块在中国都适用，那我们岂不是没的可做了！

那么在数据仓库领域里面，什么叫小呢？比如：只满足一部分需求或者实现某种业务。

所以，我对我们要做的产品的定位是：为了满足某种特定业务需求的分析架构。