先说一个现象：BI数据类系统与业务系统在开发模式上是一致的，核心流程都是采用“瀑布模型”，即：需求分析、系统分析、系统设计、开发、测试、上线。
二者采用相同的模式，但最终效果有很大差别。数据类系统常常有上线即过时的问题，而最常见的解决方法也仅仅是缩短项目周期。
为什么会这样？因为BI数据类系统与业务系统在很多方面存在差异，先看一下业务系统的特点：
§ 需求类型：功能需求。
§ 需求时效性：功能需求尽管也存在变更的需要，但其功能框架流程的变化相对较小，更多是流程中的某些环节、参数的变更。
§ 系统架构：业务系统可以通过流程标准化、参数化，及微服务、ESB等技术来增强系统的可扩展性。
与此对应，BI数据类系统的特点如下：
§ 需求类型：统计分析需求，或内容需求。
§ 需求时效性：统计分析业务框架也相对保持稳定，同时，具体的统计内容会根据运营、监管、管理的需要而变化。
§ 系统架构：数据类系统更多关注数据架构，及数据的分布、模型。
对比一下，业务系统的需求可以简单总结为：业务流程框架+参数，同时，系统架构中对应地实现了框架与参数的分离。
BI数据类系统的需求也可以简单总结为：业务分析框架+具体内容，很不幸，系统架构中没有考虑业务分析框架的实现。
为什么这样？需求提出分析方面，二者存在巨大的差别。
业务系统。
业务人员提需求时，关注业务流程，自然而然地表达：先做***，然后**，如果遇到**情况，就如何如何，如果遇到这种情况，就如何如何。
显然，一个合格的需求分析人员是很容易将需求提炼为：业务流程框架+参数的模式。
在看一下BI数据类系统。
业务人员提需求时，大都关注具体的内容：我需要***张报表，每个报表的表样***，报表的统计口径***，报表之间的核对关系***。或，我需要查询***信息，包括哪些数据项，需要***的过滤条件。
根据业务人员的需求，需求分析人员很容易地就整理一个完备的需求清单（报表清单、查询清单、文件服务清单），按照这个清单进行设计、开发、测试是顺理成章的，且以此进行项目管理也非常清晰。
看，BI数据类系统的业务分析框架很难出现。
怎么走出这个困境？无他，通过项目的知识积累，以及需求分析的“五连问”来解决。“五连问”指，面对业务提出的需求如一张报表，分析人员需要明确：
1. 为什么需要这张报表？
2. 报表使用的场景？
3. 在这些场景中，你关注哪些信息？
4. 采用什么方法来分析、监控这些信息？
5. 这张报表与哪些报表有关联？
在与业务人员调研、讨论这些问题过程中，需求分析人员将设计、完善“业务分析框架”。
业务分析框架包含哪些内容？
业务分析框架应该包括：场景、指标、分析方法、可视化、工具功能、数据及可得性、人员技能要求等。
最后的话。
提炼整理业务分析框架，肯定需要更多、更高级的人员投入，明显增加项目成本。如果一个金融企业招标中过于强调价格因素，不论中标厂商是否拥有框架的咨询设计能力，厂商大概率不会提供这类“五连问”的服务。
转自：https://www.bigdatas.cn/forum.php?mod=viewthread&tid=88281&fromuid=8897
