什么是需求？
数仓需求的来源,以及流程。
需求
概述:
- 业务需求(business requirement)表示组织或客户高层次的目标
- 用户需求(user requirement)描述的是用户的目标,或是用户要求系统必须完成的任务
- 功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
需求是数仓的核心,无论从广度还是深度的层面上做好需求调研的工作,对数仓的建设百利而无一害
需求分类
- 项目需求:搭建数仓需要完成哪些基础目标,以模板作为导向
- 业务部门的需求:通过需求调研,了解业务部门希望在数仓搭建完成后,能对业务有多少实质性的帮助
需求调研步骤
1.确定调研对象
在数仓调研过程中,不可避免的会遇到业务人员以为某项功能可以很轻松的实现,而技术人员完全听不懂专业的业务术语,会影响整个项目进度,而且在需求不清晰地情况下盲目的进行工作,会给日后的工作留下很多隐患.
数仓团队中往往会存在一个业务咨询师的角色,主要就是负责技术和业务两方面的需求调研工作
我记得以前做过一个银行数仓的搭建项目,整个团队埋头苦干,一个星期整理的需求分析的可用度不高,公司调来了一位高级咨询师,只用了三天,就把大致的需求分析做完了.
术业有精通,这就是提高了整个项目的工作效率,数据仓库团队在进行需求调研时,需要把业务人员、技术人员和类似业务咨询师的项目成员召集起来一起反复谈论需求的细节
2.了解源系统
需要了解业务的源系统,包括源系统的所有者,源系统的业务流程,源系统的数据规范,源系统的数据存储方式,源系统的数据流程,源系统是否存在更新换代情况,源系统的数据库类型,源系统的源表等等,可以按照下图进行源系统文档的整理.
3.需求调研
需求调研的目标是发现问题以及找到现阶段未发现的边界范围
调查系统需求,主要是通过面谈、问卷调查法、观察法、体验法等方式,了解用户对系统的期待性功能,从而找到系统对应的相关事件,需求调研的重点应该放在业务过程上,而不是侧重于业务部门,例如有三个部门在某一个业务上存在交叉,那这个时候就不应该把部门需求放在第一位,首先应该梳理业务需求,数据服务于部门,而不是部门服务于业务.
如果基于业务部门建立数据仓库总线矩阵雏形,会造成很多数据的重复性和交叉性,无法完成在数据应用上的目标.
需要先对源数据进行初步评估,以便日后进行源数据处理
4.需求分析的内容
需求分析的内容主要可以分为下面三步:
- 1.对象
拿到一个需求之后首先要分析的就是这个需求的主体是什么，关键对象是什么，然后再来分析于此相关联的对象都有什么，是否有什么漏洞
- 2.约束
每一个需求之间都多多少少有关联，而需求分析的难点就在于把众多业务联系在一个平面上，从而解决数据搭建过程中的边界问题。需求的约束有哪些？限制有哪些？这些问题才是重点。
例如：在银行数仓大环境中，同一个业务名称的指标在不同的业务部门之间会有不同的逻辑，对于A指标，财务部和风险部对其定义可能存在不一样的逻辑，这个时候就需要在需求分析过程中对该指标进行细化调研，搞明白该指标在不同的部门中的逻辑约束关系，为何会出现一个指标，而存在不同逻辑。当这些搞清楚后，对于轻度化汇总的宽表设计会有很大帮助。
- 3.关系
需求之间的关系往往错综复杂，一层套一层。即便不能搞清楚数仓搭建过程中所有的需求关系，但是重要的指标需求一定要搞清楚，避免给以后留下坑。
例如：A部门的一个需求指标可能是由其他部门的指标加工而来的，或许还存在一些人工录入的数据，搞清楚这些后，可以解决基础层数据存储和模型层逻辑加工的很多问题。
银行数仓中，有很多指标是交叉的，例如存量贷款这个词在财务中可能只需要未核销未结清的贷款部分，而在风险部中不仅需要这部分，还需要90天转表外的不良贷款金额，而这部分的金额是记录在外部账中，不始于财务的统计规则。
5.编写需求文档
经过以上步骤产出的文档主要有需求规格文档、源系统跟踪报告、总线矩阵文档、数据评估报告。
下边大概为大家分享总结一些流程以及文档规范。
需求流程
分析需求
可行性分析：数据产品经理主导，邀请设计、数据安全与合规人员，对需求进行评估。
- 需求合理性：评估该需求的合理性。
- 数据可行性：评估当前已有数据能否支撑需求开发，如果缺少数据，则需要另行规划缺失数
据的抽取方案。
同时建议进行深入的数据探查，包括但不限于数据完整性、字段离散值分布情况、空值、零
值、重复值占比等情况。 - 技术可行性：评估当前已有数据模型能否支撑需求开发，如果不能，则需要规划模型改造方
案，并充分评估其影响。同时在测试环境进行模型测试。
数据仓库业务模板
单元测试报告
数据评估报告
