项目需求报告范文 第1篇
2 什么是需求分析
结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前，会进行前期的可行性研究；在运行开始以后，还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下，国内软件开发公司在做欧美和日本的项目时，对前期的可行性研究参与得较少，一般都是对方已经做完可行性研究，国内软件开发公司从需求分析开始做起，直到软件开发后的运行和维护。所谓需求分析，是指对要解决的问题进行详细的分析，弄清楚客户的需求，包括需要输入什么数据，要得到什么结果，最后应输出什么，等等。可以说，软件工程当中的需求分析就是确定要计算机做什么。
3 需求分析的重要性
从需求分析的定义上，就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对，后面的步骤做得再好，也只能是南辕北辙，无法满足客户的要求。研究表明，改正产品付诸应用后所发现的一个需求方面的缺陷，比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但若在系统测试时发现则需要5-17个小时来修复。
需求工程的成功与否直接关系到系统给的命运，需求工程绝对不是软件开发的前期任务，而应该在整个系统的生命周期里都扮演着重要角色。在需求工程阶段解决和根除需求引起的问题可以大大降低生产和维护的成本，提高用户的满意度。在软件开发的过程中，需求工程阶段是了解用户需求的最佳时期，但很大一部分用户不知道、不了解需求工程，以至于在和他们交流的时候，他们都不能准确完整的说出自己的需求，因而对于从事需求工程的人员来说，能够正确的理解用户的需求观点，利用一些方法和技巧来启发用户阐述清楚自己的需求是很重要的。需求工程作为了解并实现软件开发者的目标的重要手段，有着不可替代的作用。
比如一个失败的案例：由于和客户签订了合同，5个月必须交付软件，开发时间紧迫，导致项目计划时做需求分析的时间只给了2周时间（理由是客户的文档已经提供好了，照着做即可）。结果，由于前期对客户文档理解得不是很清楚，导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论：如果要满足客户的要求，则需要对整体架构进行修改。虽然最后按期交付了软件，但是整个项目组最后两个月每天都在加班，包括周末，而且软件质量也没有得到客户的充分认可。
再如我們在了解客户需求的同时，应该尽量了解客户为什么要这么做，帮客户一起想需求，以便我们开发的软件能够更好地为客户服务。每天开完会后，我们应该把客户的需求整理好，发给同事进行研究分析，建立简单的基础模型并研究技术可行性。需求分析结束后，保持每周至少3次电话会议与客户进行沟通，随时了解客户的需求。最后正因为在前期阶段进行了这种细致的需求分析，项目组在很少加班的情况下，不但按时交付了项目，并且得到客户的充分认可。
4 软件需求分析的任务
软件工程的发展来源于信息需求对它的推动，现在互联网技术和应用越来越成熟，信息的获取也逐渐变得简单和完整，但是由于资源的开放性、系统与系统的相互渗透性、用户的变动性让需求变得多目的、多变化，增加了软件制作的难度，但同样带来了巨大的用户市场。需求的获取同样也是困扰软件工程的绊脚石。需求与资源的搭配不合理，就会影响软件工程的发展。未来适应变化多端的用户需求，必须让软件也随之变化。要满足多样化的信息需求，提取合适的信息需求建立模式，就要有相应的系统对需求信息进行分析和总结，通过程序化的模式来制定切实可行的软件方案。
国项目中，在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组，每天技术人员会对分析的结果提出技术实现的难点以及改进的方法，笔者在随后的会议上就会和客户进行讨论，尽量在满足客户需求的同时，使用更简单可行的技术，这样就为以后的开发奠定了基础，使开发时的工作量大大减少。测试人员也在需求时提出从测试角度看到的问题，同样在需求分析阶段得到解决，节省了大量的开发时间。
需求工程在未来发展中会有如下几个方面的着重考虑：（1）缩小需求工程在理论研究阶段取得的成果同实际应用中得到的效果的差距，通过得到的结论来更好的设计软件；（2）规范需求工程的各种机制，可以有需求工程规格数据的搜集、整理、制作、实现以及维护，也可以有需求工程的问题的解决办法；（3）保证需求工程有较高的质量。这一点是需求工程最为关键的要求，质量的高低直接影响了未来实现效果的好坏。需求工程就是对未知问题进行探索、处理的过程。未来必然会朝着对象具体化、分析自动化的方向发展。
5 进行需求分析的注意事项
需求分析是分析人员与用户共同的责任
用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人员则要认真了解用户的要求，细致地进行调查分析，把用户做什么的要求最终转换成一个完全的、精细的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的要求。在一些项目中，由于时间紧迫，一些模糊问题没有及时澄清，导致最后返工，影响了项目进度。
需求分析阶段研究的对象是软件项目的用户要求
需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。在一些项目中，针对客户提出的需求，了解客户的意图后，发现技术上实现有很大难度。我们了解到这个需求对客户来说不是十分重要，于是和客户商量出一个折中的解决方案，绕过技术难点，并且没有降低客户满意度。
主动积极了解客户业务和相关知识
求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语教给分析人员，而客户不一定要懂得计算机行业的术语。由于通常情况下客户对计算机术语了解不多，需求分析人员应该尽量将计算机术语转化成通俗易懂的语言，这样便于和客户沟通。而对于客户方面的术语，一方面不懂的时候一定要问；另一方面也要多学习。
项目需求报告范文 第2篇
关键词：软件工程；需求分析与管理
The Requirements Analysis and Management of Software
Huang Degui
(Communications Information Branch,Zhanjiang Port(Group)Co.,Ltd.,Zhanjiang524019,China)
Abstract:In the process of software development requirements analysis and management,there are some paper analyzes the problems and issues reference for these recommendations and solutions.
Keywords:Software engineering;Requirements analysis and management
在软件项目开发过程中，需求分析与管理十分重要。但在实际的软件项目开发的需求分析与管理过程中存在一些问题，如果不重视这些问题，往往导致项目开发进度延期、超出项目预算甚至项目开发失败。
在软件工程理论中，需求分析是指构建一个新的系统或者完善现有系统时，确定系统的目标、范围、功能需求和非功能性需求等方面所涉及的工作。
需求分析是软件工程的一个关键过程，也是软件项目开发的一个关键阶段。软件需求分析人员需要准确、清晰和形象的表达和描述用户的真实需求。需求分析阶段的工作是否准确和充分、提交的软件需求说明书是否完善和规范、需求管理的方法是否正确将直接影响和决定整个项目开发是否能够按照时间进度和在项目预算范围内完成。
在项目开发过程中，经常出现如下情况：软件需求分析人员描述的用户需求不完整、用户需求经常发生变化、软件需求分析人员与系统设计人员的沟通障碍、开发人员边做需求分析边做开发、用户需求管理混乱、缺少专业的需求分析与管理工具等。这些情况的出现使整个项目管理风险加大、系统代码返工率高、项目团队士气日益低下和用户对项目开发进度的抱怨越来越多，最终可能导致整个项目开发失败。
软件需求分析人员描述的用户需求不完整主要原因：一种情况是没有专职的软件需求分析人员，兼职的软件需求分析人员同时担当该模块的设计及开发，导致需求分析没有真正从业务的角度来考虑，而是从技术实现的角度考虑。有的即使有专职的软件需求分析人员，该软件需求分析人员也不具备该行业的业务知识和经验，对行业术语不了解，有的甚至聘用刚刚毕业的学生去做需求分析，导致整个需求分析不准确甚至出现偏差。另外一种情况是专职的软件需求分析人员没有系统的学习和掌握软件需求分析的基本方法、原则和技巧，了解的业务需求不能准确直观的表达和描述，编制的软件需求说明书过于简单和形式化，导致项目开发的其他人员不能很好的理解用户需求，有的甚至要重新做软件需求分析。
为详细和准确的描述用户需求，需要注意以下几个方面：
首先需要由专职的人员担任需求分析工作，而且软件需求分析人员需要系统的学习和掌握需求分析的基本方法、原则和技巧。例如获取业务需求常用的方法有用户访谈、速记、谈话录音、会议纪要等；其中用户访谈的要点包括确定访谈的时间、访谈的对象、设计用户访谈计划并提前发送给用户等；速记要求软件需求分析人员能够快速准确的记录用户描述的业务需求和业务流程。谈话录音和会议纪要是为了更准确记录用户描述的业务需求，便于分析和理解用户需求；软件需求分析人员最好具备该行业的业务经验和知识或者聘请该行业的业务专家指导，这样有助于软件需求分析人员准确分析和理解行业术语、行业业务需求和行业业务流程。
其次，描述的软件需求说明书内容应该包括系统的目标、范围、功能需求、非功能性需求和系统界面原型等方面。非功能性需求主要包括系统界面的可用性、易用性、操作便捷、时间效率高、出错率低和操作系统需要的专业领域知识少等方面；系统界面原形是指使用专业界面原形工具（Axure等）或者直接使用开发工具（Visual Studio等）编制系统的初始用户界面，便于软件需求分析人员、系统设计人员和开发人员更直观和形象的与用户沟通和明确需求。非功能性需求和系统界面原形在需求分析阶段非常重要，我们在项目开发过程中应该注重非功能性需求和系统界面原形。
最后，对于软件需求分析人员编制的软件需求说明书要做好需求验证工作，参加需求验证工作的成员应该包括项目组所有成员、该行业的业务专家和最终用户。在需求验证会议上提供的需求验证材料应该简单、清晰、直观和明确，不能笼统的提供一些复杂的业务流程及繁琐的文字说明。在需求验证会议上可以通过情景模拟和系统界面原形的方式演示。情景模拟是根据不同业务角色模拟整个业务办理的情况。系统界面原形能让用户切身感受到系统的界面效果，便于直观、形象的沟通和交流业务细节和业务流程。
在项目开发过程中，用户需求发生变化的情况经常出现。我们不能避免和逃避用户需求变化情况的出现，但应该控制和管理用户需求变化，应该有需求变更的流程、需求变更的团队、需求变更的平台、需求变更的影响分析以及固定的需求变更周期。对于用户提出的需求变更，我们首先应该做好详细的记录，然后将需求变更的记录通过需求变更的流程提交给需求变更团队评估和确认，最终在需求变更的平台中反映出来，同时要做好需求变更的影响分析报告并及时反馈给用户。需要注意的是对于需求变更我们要有固定的需求变更周期，不能用户有需求变更马上要求项目团队及时更改系统，这样会加大项目管理的风险和影响项目团队的士气。
项目需求报告范文 第3篇
[关键词]项目策划人才；社会需求；调查分析
项目策划，本身是一种思维过程，兼具建设性和逻辑性。该过程主要体现在总结所有可能对决策造成影响的决定，使其起到指导、控制未来的作用，以便借此实现方案的目标。现如今，项目策划的受关注度越来越高，而该类人才的社会需求，也在与日俱增。笔者针对此进行简单的调查和分析。
1.项目策划人才的社会需求调研设计
笔者于2015年春季，采用调查问卷、电话访谈、座谈会、企业调研、网络查询等形式完成调查，共发放300份调查问卷，回收270份，有效问卷259份，问卷的有效率在96%左右。本次调研，主要在各个单位的策划部、大型庆典策划场所等，就体育、旅游、公关、文化、房地产等领域的项目策划人才展开调查，调查覆盖面较广。
2.项目策划人才的社会需求特征
此次调研中，被调研到的民营企业占了大多数，这些企业从事项目策划的人员并不多，往往不超过十人。通过反馈到的问卷，笔者发现有近七成的企业，在一年内打算招收项目策划方面的人才，项目策划人才的需求量明显呈递增趋势。还有部分企业，对项目策划人的工作经验颇为关注。
人才素质需求特征
调查结果表明，项目策划相关单位，对员工往往涉及专业素养、职业道德素质及其他素质的需求。这些素质中，排在前三位的依次是认真负责的工作态度（）、吃苦耐劳的意志品质（）以及市场调研的能力（）。多数企业认为，首先，道德层面的素质是最重要的，其次才是学习能力、专业技能水平等职业素质。
人才岗位需求特征
调查结果表明，项目策划人才的工作岗位一般分为两种：技术类岗位和营销推广类的岗位。其中，技术类岗位最典型的是策划师，其范围非常广泛，最典型如婚礼策划师、旅游策划师、房地产策划师等；营销推广类的岗位，典型如市场营销专员。在所有岗位中，房地产策划师占比高居榜首，笔者认为这可能和如今的房地产发展状况有一定关系。其次是网络营销、网站建设方面的策划师，占的比例也较大。
人才能力需求特征
项目需求报告范文 第4篇
关键词：水利；集成项目设计；需求分析
随着我国的经济发展速度的加快，各种基础建设步伐也逐年加快，在水利建设中的投资也空前巨大。而在水利工程投资项目中，自动化系统的投入作为一股新兴行业受到广泛关注。越来越多的大型泵站、水闸项目为了实现对工程的实时监控和信息管理，提高工程的运行管理水平，要求投入自动化系统以确保水工建筑物的安全使用，并提高工程效益。
这就要求有一大批素质高、善管理、会经营、懂技术的项目管理人才参与其中。怎样管理好工程，在建设施工中节省资金、降低损耗、节省劳动力以保证项目质量目标、进度目标如期实现。要实现这些目标，项目经理以及其所在的项目组首先要做的就是做好需求分析，弄清系统该做什么，不做什么，严格为业主把好关，为系统的成功实施打好基础。基础打的牢不牢就像一栋大楼的地基一样，对整个工程的实施至关重要，是项目实施成败的关键一步。
水利工程自动控制系统项目同一般的信息系统集成项目的过程一样，分为启动阶段、计划阶段、实施阶段、收尾阶段。启动阶段是正式认可一个新项目的存在，或者是对一个已经存的项目让其继续进行下一阶段工作的过程。其中需求分析属于启动阶段的工作范畴，是新项目启动阶段的主要工作环节。
在具体项目中，需求的来源通常来自于以下几个方面。
1 合同制约因素
当业主招标书后，其内部定义的所有制约因素，就成为界定需求分析范围的重要考虑因素。也是项目组编制投标文件，中标后签定合同的重要依据。当项目完成后，合同条款就成为验收审核的重要标准，项目经理要考虑的就是一切按合同完成功能。
例如在一项水闸自动化项目招标书中提出：自动化系统投运后，要具备测量和数据处理功能，其中包括：检测显示所有设备的开关状态；测量显示上、下游水位和闸门的启闭高度；测量各电量及电动机的电流等值；在引水或排涝工况下，根据设定的水位条件，自动进行开关闸预告；在开闸运行中自动计算瞬时流量、日平均流量、每闸次的引排水量。
项目组在前期需求分析的过程中就必须把这些功能以及实现这些功能需要设计的硬件、软件资源全部考虑进去。
2 业主客户要求
每一个项目都具有其独特性，使用者在使用过程中都会有一些特殊的要求，而这些功能往往是在合同中不曾涵盖的。这就需要在项目的前期启动过程中，与用户先行进行沟通，了解他们是否有什么具体要求。但由于很多情况下用户前期对项目理解不够，往往在初期无法提出具体需求，随着项目的日趋推进，业主对整个项目有了一定直观的了解后，可能需求也随之增加。这些增加的可能性越大项目风险就会越大，因为很多需求是偏离整个项目的最终目的的。我们在需求分析的时候就要充分考虑到哪些需求是相对固定的，哪些可能会是产生变动的，考虑到他的可变性和可增加性，这样前期功能设计的时候不会因为后面的变动和增加而影响整个工程。这一部分的需求往往难以把握，这就需要项目组成员根据历史资料和丰富实战经验进行先期考虑。
3 历史资料和实战经验
在项目范围界定期内，应该考虑以前项目计划的有关历史资料。大多数同类型工程项目都有其特定的规律，项目组完全可以根据以前类似项目界定工作范围。
例如每个水闸自动化项目中都需要相应的报表，以实现对闸门的实时查询和历史查询。但假如在自动化项目具体的招标书中并没有具体实际的要求，项目组成员不能对这个方面不予考虑，而是要依据以往工程所做的报表，总结出大致报表的规律。如报表可分为两大类：事件类和数据类。事件类是指运行事件和重要的系统操作，如全部的报警记录、闸门启闭记录、手动命令等。数据类是采集的实时水位和闸门开度，计算的实时流量、引排水量，存储的每日8时流量、8时水位、最位和最低潮位等各特征值，为生成各种报表、曲线和图形所用。中央控制室配有打印机，可定时或实时打印各类报表。总结后把大致规律与本工程相结合，总结出适合本工程的几类报表，先行把各类资源考虑进去。否则当工程交付时，用户提出再进行功能追加，势必会造成工期延误，影响整个项目的顺利进展。
但是毕竟不是每个分析人员都是专业而合格的，所以需求分析报告不一定很完善，会存在或多或少的缺陷。为避免这种情况的发生，需求分析必须经过项目组内部成员和业主的共同审核，讨论达成一致后双方共同签字，确认。
在多个工程具体实施中，发现在此阶段可能出现的问题如下：
①需求分析过于笼统，只关注到面上，没有关注到点上。往往开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。
②需求报告没有获得业主的评审，因为业主早期对项目的不确定，如果只有我方评审通过，不去向业主仔细的分析和解释，只求客户签字，就会在后期造成隐患。因为很多时候具体用户在自动化系统未投入运行阶段对其认知非常模糊，有时甚至要到系统投运后才能有完全深刻的理解。虽然业主签字即能够给日后出现问题时划清我们的责任，但是却不能保证业主的满意，不能保证项目实施成功。
③需求分析中含有技术实施上有难度的功能。很多时候，客户的想法在实际实施过程中是不现实的，一味的求全和盲目按照客户的设想，势必造成整个项目实施过程中受阻。此时，项目经理要做的就是与客户进行协调磋商，分析具体的性价比，建议用更为简便的方法来替代。例如曾有客户要求在一个闸门自动控制系统中加入对闸门土建方面以及钢结构方面的检测数据，而要满足这项功能需要购置大量相应设备与自动化项目进行整合，这样前期设备采购成本和后期系统通讯调试工作量都大幅提高。而此项工作完成后，仅仅是在几年甚至是十几年后才有可能发挥起真正作用，这是与一个自动化项目的生命周期是不相吻合的。故与用户协商后，建议过一段时间后请专职水利勘测人员进行检测，达到最高性价比。
④项目的完成度受业主预算的限制。当前大部分项目都是经过论证、概预算、招投标等多步发展最终确认的。在项目投入上是有上限的，在此情况下，项目的功能完成度将受影响，毕竟功能越多越完善，相应的软硬件开发成本就越高。如果一味追求功能多，将势必损失质量。这种局限性需要事先告知客户并得到理解。
⑤此项工作的繁琐枯燥，势必造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项反复的工作，需要和业主之间不断的商讨和确认，不断的被驳回和不断的修改。大部分的客户虽然安排专人负责这项工作，但是该负责人大多数情况下都是相关部门领导，本身对项目细节就不是非常理解，特别当他被很多其它的事务缠身，无心细看需求报告，他很可能会仓促签字认可，造成对设计没有完全理解和认可。
参考文献：
[1] 柳纯录，刘明亮，高章舜.信息系统项目管理师教程[M].北京：清华大学出版社，2008.