项目需求分析项目需求分析的内容？

如何做好数据仓库项目需求分析

一、简述数据仓库项目是一个复杂的过程，项目的开发涉及到多方面的问题和风险：技术风险、数据质量问题、项目管理问题，但最项目中中最隐蔽、最容易忽略、最难控制的一环，就是需求的调研和分析。

需求分析不深入、不准确的结果就是系统完成后没有人愿意使用它。

因此我们要采取有效的措施的来避免这种情况。

　　二、需求分析的原则 1、 让用户参与，尽力让用户的高层参与，双方要紧密配合 2、 要迅速、全面的理解用户的业务及工作流程3、培训 ，要不停的向用户灌输数据仓库与传统业务系统的不同做法 4、 不要求完美，而要求实用，应用将是螺旋上升的。

5、 项目有整体规划 ，调研可以全面，但一定要向用户界定好各阶段的范围。

　　备注：对我们来讲，我们不但要了解用户使用那些报表来完成那些任务，同时我们还要了解业务系统对用户需求的支持，同时，由于我们在这一行业已经积累了一些经验，也了解我们可以为用户解决那些问题，因此，从某种角度来讲，我们会比客户更多的理解系统的功能。

所以在需求调研的时候，一定要提出自己的见解，哪怕是错误的也不要紧；另外，需求会因为业务变化，因此，与其等用户的业务变化再跟着改，不如主动了解业务，建议用户按照自己的想法做。

另外，由于用户对数据仓库的概念和认识是非常模糊的，他们不清楚数据仓库到底能实现什么，能解决什么问题。

因此，我们经常会发现，我们完成了系统，用户却只用系统1%的功能，这就需要我们在对用户的培训方面和直观教育方面多下一点功夫。

我们应该准备一些以前做过的相关案例 　　三、需求分析方法要了解听众对演讲内容的看法、员工对项目组的看法、员工对公司的看法、用户对系统的看法，最好的途径就是设置调查表。

实际上，在生活中，向长者请教、拜访用户、参加培训，事先这种问题的设计都非常重要，也非常有效，调查表可以使访谈直奔主题，使调研逻辑层次分明，使调研全面同时又重点突出。

　　四、需求分析的对象对于数据仓库项目来讲，需求分析实际上应该分为两大类： 1、 系统功能分析任何系统都是前端用户的需求也就是用户对系统的功能要求，是用户期望系统能够为他们解决的问题。

在对用户调研时，要注意分清楚用户的类别，不同用户对系统的要求是不同的。

通常我们会将用户分为查询用户、报表用户、决策者，然后分析这些用户各自的行为、职责；同时我们要注意客户中还存在这样一类人，这些人是业务系统专家或信息系统人员，他们提供业务和IT的转换支持，他们推动这个项目的进行，但他们并不是最终用户。

在调研中调研一定要注意分清，这些人可能非常愿意帮你，给你讲解他们理解的系统应该具备哪些功能，但往往这些理解是有很大偏差的。

在做调研时，要注意适时对用户讲解数据仓库的框架，让用户了解自己系统构建完毕后，自己所处的位置和能够解决的问题。

因此，不但要注意整理相关的调研单（主要是设计一些问题），更要注意准备一些合适的演示资料，帮助用户理清思路，发挥想象力，争取最大限度的获取用户的需求信息。

　　2、 后台的数据接口调研 　　① 对于数据接口来讲，由于我们是建立其他业务系统之上，原有的业务系统开发商对我们有一种自然的抵触，因此，在与他们打交道的时候，最好是通过客户，即便是后期的问题交流也最好通过客户，这样做有两个好处：一是通过客户，我们和对方的为客户所做的工作可以向用户表明；二是通过用户可以避免对方对我们不理睬或对我们工作的拖延。

　　② 在三方配合工作时，在适当的时候，我们要提供接口确认文挡，将各家的责任明确，并签字认可。

这两部分需求调研的开始并没有严格的先后顺序，但是最终的后台接口的需求确认必须在用户需求定义以后。

　　五、需求分析阶段 　　1、调研准备阶段从项目有意向开始，到项目合同签定，开始实施的这一段时间，都可以认为是项目的准备阶段。

在这一阶段，我们可能会根据用户的要求，配合市场人员完成售前的技术支持工作。

虽然在这一阶段，我们不会对用户具体的业务细节进行询问，但项目从这个阶段就已经启动，我们必须从这个时候就可是积累与此项目相关的资料，必须从这个阶段就在可利用的各个场合了解用户的信息。

(转载)

如何做需求分析

一、 我们应当如何做需求分析 需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。

这就是敏捷开发倡导的需求反馈。

敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。

只有这样才能及时纠正需求理解的偏差，保证项目的成功。

二、我们应当怎样做需求调研 1.初识。

我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。

如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。

这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。

(1)高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析,应当与高层领导谈。

(2)中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。

他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。

(3)基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。

他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。

但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。

另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。

而他们关心的则是每项操作的细节。

俗话说：万事开头难。

如果你在项目开始的时候总感觉千头万绪不知如何着手，在这里我给大家的三点建议： 1）树立良好的职业威信； 2）进行详细角色分析，将与会各方代表对号入座； 3）从宏观上制订目标与方案。

随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

2.拜访。

需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。

在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。

不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。

尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。

3.研讨会。

(1)由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部 分。

划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量； (2)集中式的业务研讨形式和分散式的业务研讨形式； (3)有效抑制个性化差异、分模块组织专项研讨会。

4.业务研讨 在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式： (1)由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。

这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。

(2)能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。

这类客户，他们能熟练使用电脑，对信息化管理是清楚的。

他们提出的业务需求从整体上应当是八九不离十的 。

但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。

(3)能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。

这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。

但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。

? ?解决办法: 业务领域分析:客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问 题？ (1)我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。

(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。

(3)还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。

(4)需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。

只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。

5.迭代 在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获······ (1)需求捕获:就是我们与客户在一起开研讨会，讨论需求的活动,客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。

一个功能，在需求列表中会有多个需求，而每个需求应当能够用 1、2 句话，在 20 个字以内就可以描述清楚 。

需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。

(2)需求整理:就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。

首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。

用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。

最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。

当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML 中的行动图，甚至一个简单的示意图，等等）,再在整体用例图的基础上，依次对每个用例绘制用例图。

每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。

如此这般地不断细化，直到我们认为需求已经描述清楚为止。

(3)领域模型 :是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。

需求人员对领域模型的分析，对业务理解的深度，对日后软件的设计，以及软件的功能扩展、升级演化，都起到了至关重要的作用。

(4)需求验证:需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。

首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。

需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。

我们则认真地记录，回来整理，并等待下一次的验证。

在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。

随后的设计开发阶段，我 们则应当以迭代开发的形式进行。

每开发完一个迭代周期，将开发的成果与客户反馈。

这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。

问题及时的解决，使我们修复问题的代价得以降至最小。

6.需求捕获 经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求 ，和客户压根儿就没有想到的需求 (1)什么是客户嘴中没有说出来的需求：并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。

然而 ，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。

如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。

要求我们在需求分析的整个过程，不断进行业务领域知识的学习。

在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。

你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？注意，在所有这些问题中，最后一个问题是最重要的。

客户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。

多问为什么，可以让我们深入地理解这些领域知识 。

站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求 (2)另一种就是客户压根儿没有想到的需求：在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。

作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。

站在这个基础上，再运用专业知识去整理、分析与设计。

我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。

先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的

什么是项目需求分析

就是做这个项目需要什么东西，比如说开发环境，开发语言，还有你的开发流程等等，这个需求分析和你的这个项目紧密地联系，项目的制作取决于这个需求分析。

他要需求分析也就是对你怎么开发这个项目有个了解，你必须把这个需求分析写的详细，把你开发中的各个细节都要写进去。

项目需求分析的内容？

项目需求分析的内容至少包括五个方面： 　　1．国家和地区需求分析 　　通过对一个国家或地区的地理位置、自然特征、人口状况、经济结构、经济发展水平等方面的了解和研究，进而对项目的产品供需格局及趋势进行分析。

这个分析是项目需求分析中最重要的一项，它直接关系到项目的发展前途。

　　2．社会需求分析 　　通过对社会和经济发展水平、产业结构、人文环境、自然生态环境、公众需求以及行业投资的了解和研究，进而对项目的社会需求进行分析。

这一分析决定了项目的社会价值和意义。

　　3．消费群体需求分析 　　通过对消费人群的年龄、经济收人、消费水平、职业状况、知识水平等方面的了解和研究，区别消费结构群，进而对项目的消费需求进行分析。

这一需求分析关系到项目的市场前景。

　　4．项目业主需求分析 　　通过对项目业主的投资期望和心态的了解和研究，进而对项目业主的需求进行分析。

这一分析决定了项目的取合。

　　5．项目实施需求分析 　　通过对项目所使用的原材料、燃料、技术、设备、资金、人力需求以及环境等内容的了解和研究，进而对项目的实施需求进行分析。

这一需求分析有利于提高项目的实施质量，保证项目顺利实施。