项目需求分析_需求分析应该由谁来做？ _生活经验

项目需求分析文档都包括哪些内容？需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：

项目需求说明书,怎么写一：引言
1、编写目的：说明编写这份项目需求说明书的目的，指出预期的读者。
2、背景说明：待开发的软件系统的名称。本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。该软件系统同其他系统或其他机构的基本的相互来往关系。
3、定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
4、参考资料
列出用得着的参考资料，项目相关的计划书，或者合同，批文之类的。
二：任务概述
1、目标
叙述该项目开发的意图、应用目标、作用范围以及其它应向读者说明的有关该软件开发的背景材料。解释被开发软件与其它有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。
2、用户的特点
列出本项目的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
3、假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
三：需求规定
1、对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。
2、对性能的规定：精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。时间特性要求：说明对于该软件的时间特性要求。
四：运行环境规定
1、设备
列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能。
2、支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
3、接口
说明该软件同其他软件之间的接口、数据通信协议等。
4、控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
五数据要求
数据的逻辑描述：
对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据．包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。

文章插图
扩展资料需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
参考资料百度百科-需求分析
怎么做项目需求分析报告做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。听棠所说到的几点，感受特别深： “其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析” “客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。” 还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。
java项目需求分析怎么写需求文档一般分两类：需求调研报告、需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：项目的背景、项目的目标、项目的范围、用户特点、相关技术、规范标准等。相关约束、用户的组织结构、角色等用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出
项目需求该怎么写如果是一个软件系统的项目，站在项目角度需求管理包括项目需求、用户需求、业务需求、功能需求、非功能需求等内容。而项目管理文档中主要是项目需求，在项目实施文档中主要是用户需求分析报告、软件（或系统）需求规格说明书等。项目需求主要包括：（不同的项目还会有适当增减，由于不清楚你的项目具体情况，所以把总体上项目需求包括的内容都罗列一下）

项目目标与任务需求分析应该怎么写？项目目标与任务需求分析=项目的目标和任务。
目标是具体可量化的,由目的而生,计划是达成目的的筹划,而任务就是计划中的每个完成点一般先有目的,再有计划,后有目标,用任务完成目标
项目目标（Project Objectives）：简单地说就是实施项目所要达到的期望结果，即项目所能交付的成果或服务。项目的实施过程实际就是一种追求预定目标的过程，因此，从一定意义上讲，项目目标应该是被清楚定义，并且可以是最终实现的。项目目标包括：可测量的项目成功标准。项目可能有各种各样的经营，费用，进度，技术和质量目标。项目目标可能还包括费用，进度和质量指标。每一个项目目标都有属性，例如费用目标就有美元单位或人民币单位。
【项目需求分析_需求分析应该由谁来做？】需求分析：开发人员准确地理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。
基本任务: ⑴问题识别：双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求。
⑵分析与综合，导出软件的逻辑模型
⑶编写文档：包括编写"需求规格说明书","初步用户使用手册","确认测试计划","修改完善软件开发计划"需求分析应该由谁来做？一般情况下来说，需求分析是由产品经理或者项目经理提出来的。而不是通过研发人员或者是测试人员来做。
产品经理一般是被划分在产品部或者是市场部门，这两个职能部门一般情况下更为了解客户需求以及市场行情。而项目经理呢，会有着相对丰富的资源，可以从别的部门找来相应资源来进行整合，故此如是。
另，很多工业公司或者是IT公司，走的都是这个架构。楼主可以有时间研究一下IT公司的架构，如SAP, Oracle, Peoplesoft, Cisco 和腾讯， Ali 的架构。
希望能有所帮助
扩展
谢谢你的回答，我想问的是需求分析的这个阶段，也就是你指的产品部或市场部整理的需求到研发转成概要设计之间的这个阶段，这个阶段是应该产品部或市场部直接交由研发进行分析，还是应该在测试先进行一轮需求分析，然后交由研发进行概要设计。
PS：这方面的流程和负责人有么有专业的理论支持，例如CMMI流程等

补充
应该是由研发进行需求分析在进行概要设计。CMMI流程应该是套用在整个项目开始的阶段一直贯穿到项目结束。理论支持，是看贵公司产品的业务大?。?如果项目比较庞大，是需要相关人士进行流程支持。