项目需求分析项目需求报告要怎么写？

做程序，项目需求分析，一般做多久。

国内很多老一辈的根本不注重这一点。

但国外的，很小的开始实战写需求了。

因为他们一直认为需求是相当重要。

每次都做项目前都是，乱七八操的需求分析，像个草搞。

偶尔做一下，改一下。

改一下需求，那么，原来的框架，编码都要改。

而我同学他们的虽然做需求做了一个月多，但却是按需求很顺利的一气搞定。

我问的是：无论是多大，还是多小的项目，都要把需求写清楚再做。

项目目标与任务需求分析应该怎么写？

项目目标与任务需求分析=项目的目标和任务。

目标是具体可量化的,由目的而生,计划是达成目的的筹划,而任务就是计划中的每个完成点 一般先有目的,再有计划,后有目标,用任务完成目标 项目目标（Project Objectives）：简单地说就是实施项目所要达到的期望结果，即项目所能交付的成果或服务。

项目的实施过程实际就是一种追求预定目标的过程，因此，从一定意义上讲，项目目标应该是被清楚定义，并且可以是最终实现的。

项目目标包括：可测量的项目成功标准。

项目可能有各种各样的经营，费用，进度，技术和质量目标。

项目目标可能还包括费用，进度和质量指标。

每一个项目目标都有属性，例如费用目标就有美元单位或人民币单位。

需求分析：开发人员准确地理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。

基本任务: ⑴问题识别：双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求。

⑵分析与综合，导出软件的逻辑模型 ⑶编写文档：包括编写"需求规格说明书","初步用户使用手册","确认测试计划","修改完善软件开发计划"

什么叫做需求分析

业务定义与有效需求分析 蔡颖安 珠海市供水总公司 摘要 在计算机应用系统建设过程中，有效需求分析是最关键的一步，本文深入分析了有效需求分析的概念，并讨论了有效需求分析的处理过程，最后讨论了做有效需求分析的前提条件。

关键词 业务定义、目标确认、需求调查、需求分析、效果分析 1为什么要进行业务定义 计算机技术支持的业务运营支撑系统是随着市场经营的需要不断得到完善和提高的。

系统功能上经历了从最初的资料录入管理到生产派单管理、生产流程管理、统计管理、业务组织管理，一直到决策支持管理的过程。

人们对计算机应用系统的态度上也经历了从开始的拒绝、怀疑、喜欢、依靠到最后渴望其无所不能的过程。

但是，我们也发现，一方面，随着业务支撑系统性能的不断提高，系统的使用人员对系统的抱怨反而越来越大——使用不方便、使用效率低、系统缺陷严重等；另外一方面，系统的造价也呈指数增长，从最初的几十万元、到几百万元到现在的上千万元。

为什么会出现这种矛盾的情况呢？开发方说需求方的业务太复杂、变动太频繁、业务与流程不规范；建设方说开发方的开发能力差，开发代价高，系统缺陷和错误多多。

那么，真正的原因到底在哪里呢？ 我们通过对现行系统及应用情况的分析得出的结论是：需求方与开发商之间对业务的理解和定义的混乱是造成这种状况的根本原因。

由于在业务管理的过程中同时也在业务系统的建设过程中，我们都没有对业务进行定义或定义不够清晰准确，业务本身在执行过程中就出现概念不清和流程不畅等情况，那么作为以机器支撑的业务系统当然就天生具有很大的缺陷。

如何准确定义一个业务呢？这的确是一个科学加艺术的课题。

但是因应系统建设的需要，我们必须给出一个清晰的合理的业务定义——需求分析就是一个比较合适的方法。

所谓需求分析就是以市场运作中的业务定义为基础，重新定义一个业务在业务系统中的概念、业务流程、数据流程、业务间关系、数据间关系等，以便于计算机高效的实现这个业务。

需求分析既可以用于一个业务的具体分析，也可以用于一类业务的分析和整个业务支撑系统的分析。

我们用图1示意需求分析方法的应用层次。

2 为什么是有效需求分析 实际上，在做任何一个业务系统的过程中，我们都提到了要做需求调查和需求分析，并且投入了最多的力量做需求及分析，但效果却比较差。

原因是什么呢？这是因为我们通常花了很大的精力去做业务需求的调查和总结，却忽略或轻视了需求分析这个最重要的当然也是最困难最复杂的过程。

为什么我们会忽略或轻视需求分析这个重大课题呢？通常做业务系统建设的人（包括建设方和开发方）都不承认他们不重视需求分析，而是他们所做的需求分析只是简单的做部分业务或某些技术方面分析，因为要做一个彻底的需求分析的确太难了。

我们不知道如何做需求的分析，做需求分析要达到的目的，做需求分析的流程，做需求分析的内容，效果的评估等我们都是不明确的。

所以，我们提出一种全新的需求分析方法——有效需求分析。

它的目的是要达到业务的清晰性、可操作性、高效性和完善性；它的内容含盖从需求调查到需求分析的全过程，它主要包括：目标确认、需求调查、需求分析、效果分析等几个循环往复的过程。

见图2。

在这里，我们特别强调了目标确认，因为我们如果不知道要做什么和达到什么目标，需求分析就无从着手、没有方向。

图2 有效需求分析的过程 （1）目标确认：首先我们必须清楚的定义我们建设一个系统或做一个业务的目标，如它包含的主要功能，它不包含的功能（通常我们都缺少这一点，而往往这一点非常重要）系统之间或业务之间的界面。

在进行目标确认时，我们必须用清晰的语言描述出我们的目标。

（2）需求调查：首先在不考虑目标的情况下做需求调查，尽可能详尽的掌握整个系统或业务的需求；然后对每个需求进行一致性的分析，确定其是否与已经确认的目标一致，或是修正目标，或是修正需求；最后确认该需求的合理性，并用清晰的语言描述该需求。

（3）需求分析：首先分析需求的内涵和相关的名词术语，必要时进行名词术语的重新定义；然后进行数据及流程、业务及流程等的定义与分析，以细化相应的需求；再次进行相关性分析——这是非常重要的一步，包括业务之间的相关性、数据之间的相关性、业务上和技术上的可行性等，并提出解决问题的方法，如果问题严重，还要考虑是否需要修改需求或修改目标。

最后也是要用清晰的语言描述该需求及其相关关系。

（4）效果分析：综合评估经过需求分析后的需求的效果，是否满足我们的预定目标，是否需要重新定义需求或目标等。

3 做有效需求分析的前提条件 正如我们在第二节讨论过的，有效需求分析是一个非常困难和非常复杂的过程，是一个科学分析与艺术加工相结合的过程，是考验人的能力和智慧的过程。

（5）分析人员必须有对项目的高度责任感； （6）分析人员必须具有非常扎实的理论基础，丰富的知识尤其是相关交叉学科的知识； （7）分析人员必须愿意和善于理论联系实际，并掌握了必要的工具； （8）分析人员必须具有强烈的研究分析事物的欲望和洞察、分析事物的能力； （9）分析人员必须具有很强的逻辑思维能力和创新能力； （10）分析人员必须具有很强的综合事物的能力，语言表达和语言描述的能力。

当然，除了对分析人员的要求外，还存在对开发环境的要求，这就是： （1）项目要有明确的目标，即该项目应该具备的功能和可以不具备的功能是明确的； （2）业务必须是可以定义的，即可以用术语和流程的来描述一个业务； （3）业务过程必须和目标保持一直，当业务过程与目标出现矛盾时，可以重新定义目标、或重新定义业务； 4 结束语 我们做了近十年的计算机应用系统的建设，在此过程中，我们深感系统建设理论的匮乏，导致我们在系统建设前、中、后等各个阶段都有一种茫然的感觉，不清楚要做什么，不知道在做什么，不知道做了什么。

本文试图从理论分析的角度对业务定义和有效需求分析做一个研究，希望能起到抛砖引玉的作用。

提供很多“需求分析”的例子！！

项目需求报告要怎么写？

听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。

需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。

其实，都是缺乏分析所一手造成的。

问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。

听棠所说到的几点，感受特别深： “其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析” 还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。

项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。

而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。

至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。

客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。

这其实也体现了系统的扩展性。

需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。

客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。

我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。

这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。

谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。