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