项目需报告要怎么写

[项目总结报告怎么写]XX项目总结报告 XX单位管理委员会（你要汇报的机构，不能针对个人）：受领导指派，我于XX年XX月XXX日负责XX项目。X个月来，在领导的大力支持及同志们的密切配合下，项目进展顺利。于XX年...+阅读

项目需报告要怎么写

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

需分析，不仅仅是拿到客户的需，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。

听棠所说到的几点，感受特别深：

“其实问题出在开头，客户需只是软件需分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需，而是要把客户的需进行分析”

还有客户的需本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要去做，当暴露这些问题时，你怪客户也没用啊。

项目需分析报告，在了解客户需时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需给你，有人会觉得这样了解客户需未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。

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

需分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需，并减少后期的修改。

软件工程需分析报告范文谢谢！

3.1 引言

3.1.1 编写目的

说明编写这份软件需说明书的目的，指出预期的读者。

3.1.2 背景

说明

a.待开发的软件系统的名称，

b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络

c.该软件系统同其他系统或其他机构的基本的相互来往关系。

3.1.3 定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

3.1.4 参考资料

列出用得着的参考资料，如：

a.本项目的经核准的计划任务书或合同、上级机关的批文；

b.属于本项目的其他已发表的文件，

c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

3.2 任务概述

3.2.1 目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的乒品是卢个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

3.2.2 用户的特点

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。

3.2.3 假定和约束

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。

3.3 需规定

如何做好软件项目需分析

需分析是介于系统分析和软件设计阶段之间的重要桥梁。一方面，需分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

需分析阶段的基本任务是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件其它有效的需。

最主要的原因是对于开发小组的使用成员（包括用户）来说，需确定是极具认知性和创造性的活动。需确定也许是仍在苦苦等待人工智能支持的最后领域之一。具体表现如下：

系统分析员对问题域的了解程度也是一大困难。

系统分析员感到需确定很困难的另一个原因是问题域的动态性。

生活是动态的，公司也是。

项目团队成员之间的沟通也一直是需确定的另一大困难。

每个问题域都有术语。

最后，需确定过程还会受到其它因素的影响。例如劳累、不舒服、开会时室内和窗外的干扰、团队成员的压力等等。