对于需求分析的过程，由于资料杂，现在有点晕，希望哪位高手能给整理一下。下面是我在不同的地方看到的对需求分析的认识，个有不同，晕了
1、网上资料说，需求分析有三层次，业务需求、用户需求和功能需求，除此之外还有非功能需求
2、软件工程书上说，需求分析任务有综合要求（包括功能需求、性能需求、可靠性需求等）、数据要求（包括系统处理的数据、系统应产生的数据等）、导出逻辑模型（数据流图、ER图、状态转换图、数据字典等）
3、数据库上说，需求分析主要是对数据模型、功能模型、行为模型的建立
到底我应该根据哪个准则去做需求分析呢，现在搞得需求分析到底按什么原则弄也搞不清了
我要对数据库设计，就要先对数据库做需求分析，我发现要在功能分析的基础上做，然而我看了很多资料基本都采用数据流图和数据字典，难道没别的了吗？我画ER图的时候都很怀疑我的ER图是怎么突然蹦出来的，我用面向对象的用例图和功能模块图做了功能上的需求分析，然后就直接画ER图去了，也就是直接从用例图跳到了ER图，总觉得这样不对，但是有想用ER图对数据进行设计，那么我怎么才能从UML的图中过渡过来。
------解决方案--------------------------------------------------------
如果是OOA和OOD的话,ER图可以用类图代替,在数据库设计中是概念数据模型的产物.需求分析有三层次，业务需求、用户需求和功能需求没错,其实从用户需求到功能需求的过程中应该有非功能性需求,非功能性需求与功能需求是并立的关系.软件工程书上说的也没错.性能需求、可靠性需求属于非功能需求,软件工程书上说的导出逻辑模型（数据流图、ER图、状态转换图、数据字典等）也没错,不过你看的那本书比价老了,写那本书时UML还不占统治地位时写的,应该是面向对象方法学三大巨人之一的方法,即Rumbaugh的OMT技术采用的方法,老教科书张海藩写的<<软件工程导论>>中面向对象的内容也是写这个,有空去了解下各方法学也有帮助的.
------解决方案--------------------------------------------------------
当要看你进行需求分析的站位角度
如果是站在业务规划、解决客户问题优化客户现有流程的角度，应该先以业务事件分析进行业务建模,再抽象自动化进行软件系统建模
如果站在信息系统功能划分的角度，直接进行系统建模地方
如果只是站在信息数据结构、信息存储，就会涉及到数据E-R
------解决方案--------------------------------------------------------
1.面向对象分析建模，建议不要一开始接触数据，而是一开始找到系统参与者（人、物、地点）与其担任的角色、执行的动作，以及相互的关系。也就是“领域建模”。
2.业务需求即功能需求，一般来说就是用户需求（有时候也包括非用户客户的需求，比如政策性的东西）。非功能需求不太好描述，就是系统中应该有的一些不容易提出来的东西，大概分成几个方面，比如易修改性、安全性等等，大概排个优先级，自己心里有数，但是不太容易与客户确认。
3.对于数据库确实要重视，但是不是在需求的时候，而是在架构与设计阶段，否则很容易从OO退化成为面向过程，职责划分不明，因为数据库表粒度比对象粒度大很多。
4.你说的问题，实质上不是需求问题，而是架构问题。关于架构，有很多不同的视角，比如数据视角，部署视角，逻辑视角等等。
5.UML图的问题，建议看一些ICONIX的书，其实先用哪个图后用哪个图是有讲究的，顺序对了事半功倍，顺序错了就乱七八糟了。