没怎么搞过实际项目，但是也觉得需求分析确实是很重要的。在进行数据的ETL时，归拢需求很关键，涉及到收集并整理所有已知的需求、实际情况和影响ETL系统的约束。
关于ETL系统设计和开发有一下几个方面的需求。
1、业务需求
这里业务需求很直接，就是DW/BI系统用户的信息需求，后面的过程需要那些数据，我的ETL就应该以其为目标。
2、合规性
合规性是说提供的表报中的数据必须是正确和完整的，并没有经过任何篡改。
一般数据仓库中应该特别注意的需求有：
- 保存数据源和随后数据登台的副本；
- 为改变任何数据结果的完整性的事物处理流程提供证明；
- 完整记录用于分配、调整和推导的算法；
- 随时间推移为数据副本的保密性提供证明，包括在线和离线。
3、数据质量
数据质量的重要性怎么强调都不过分。
- 好的数据质量对于数据挖掘的效果来说其关键性作用，好数据，好业务；
- 数据源大多都是分布式的，需要对各种不同的数据进行有效集成；
- 合规性的需求使得不能对数据进行粗心大意的处理。
4、安全性
数据仓库行业对于数据安全性的心态是矛盾的，数据仓库本身追求如何向决策制定者广泛的发布数据，
而安全性则要求对数据进行限制，只有需要了解的用户才有权访问。
5、数据集成
数据集成最终目标是要是所有的系统无缝联接、协调工作。数据集成表现在数据仓库中的一致性维度和一致性事实。
一致性维度是指确立整个业务过程中公共的维度属性。
一致性事实是说对各个独立数据库的公共业务指标达成一致。
6、数据等待时间
数据等待时间描述了源系统数据通过DW/BI系统提供给业务用户的速度有多快。
数据等待时间对ETL的架构有重大影响。
巧妙的处理算法、并行化处理和强有力的硬件支持可以加速传统的面向批处理的数据流。
如果要求等待时间很急迫，ETL系统架构即必须从批处理转向流处理。
7、存档和沿袭
建议是在ETL管道的每个主要活动（抽取、清洗和一致化，以及提交）之后都将数据写入磁盘。
8、用户提交界面
ETL的最后一步是将数据移交给BI应用程序，必须对数据内容和结构负责。
否则导致BI应用程序复杂度大大增加，降低查询和创建报表的速度，并使用户感觉数据过于复杂。
9、可用的技能
有些ETL决策必须基于建立和管理系统时所能获得的人力资源来制定。
比如团队自身没有C++编程能力或者无法达到相应的水平，就不应该建立一个严重依赖于C++语言的处理模块。
如果有了主流厂商的ETL工具相关技能，心里就有谱多了。
另一个是手工编写代码生成ETL工具，还是使用厂商的开发包。
10、遗留许可证
这个还没看懂啥意思，许可证？软件的许可证？