项目需求分析

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇项目需求分析范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

项目需求分析范文第1篇

2 什么是需求分析

结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前，会进行前期的可行性研究；在运行开始以后，还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下，国内软件开发公司在做欧美和日本的项目时，对前期的可行性研究参与得较少，一般都是对方已经做完可行性研究，国内软件开发公司从需求分析开始做起，直到软件开发后的运行和维护。所谓需求分析，是指对要解决的问题进行详细的分析，弄清楚客户的需求，包括需要输入什么数据，要得到什么结果，最后应输出什么，等等。可以说，软件工程当中的需求分析就是确定要计算机做什么。

3 需求分析的重要性

从需求分析的定义上，就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对，后面的步骤做得再好，也只能是南辕北辙，无法满足客户的要求。研究表明，改正产品付诸应用后所发现的一个需求方面的缺陷，比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但若在系统测试时发现则需要5-17个小时来修复。

需求工程的成功与否直接关系到系统给的命运，需求工程绝对不是软件开发的前期任务，而应该在整个系统的生命周期里都扮演着重要角色。在需求工程阶段解决和根除需求引起的问题可以大大降低生产和维护的成本，提高用户的满意度。在软件开发的过程中，需求工程阶段是了解用户需求的最佳时期，但很大一部分用户不知道、不了解需求工程，以至于在和他们交流的时候，他们都不能准确完整的说出自己的需求，因而对于从事需求工程的人员来说，能够正确的理解用户的需求观点，利用一些方法和技巧来启发用户阐述清楚自己的需求是很重要的。需求工程作为了解并实现软件开发者的目标的重要手段，有着不可替代的作用。

比如一个失败的案例：由于和客户签订了合同，5个月必须交付软件，开发时间紧迫，导致项目计划时做需求分析的时间只给了2周时间（理由是客户的文档已经提供好了，照着做即可）。结果，由于前期对客户文档理解得不是很清楚，导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论：如果要满足客户的要求，则需要对整体架构进行修改。虽然最后按期交付了软件，但是整个项目组最后两个月每天都在加班，包括周末，而且软件质量也没有得到客户的充分认可。

再如我們在了解客户需求的同时，应该尽量了解客户为什么要这么做，帮客户一起想需求，以便我们开发的软件能够更好地为客户服务。每天开完会后，我们应该把客户的需求整理好，发给同事进行研究分析，建立简单的基础模型并研究技术可行性。需求分析结束后，保持每周至少3次电话会议与客户进行沟通，随时了解客户的需求。最后正因为在前期阶段进行了这种细致的需求分析，项目组在很少加班的情况下，不但按时交付了项目，并且得到客户的充分认可。

4 软件需求分析的任务

软件工程的发展来源于信息需求对它的推动，现在互联网技术和应用越来越成熟，信息的获取也逐渐变得简单和完整，但是由于资源的开放性、系统与系统的相互渗透性、用户的变动性让需求变得多目的、多变化，增加了软件制作的难度，但同样带来了巨大的用户市场。需求的获取同样也是困扰软件工程的绊脚石。需求与资源的搭配不合理，就会影响软件工程的发展。未来适应变化多端的用户需求，必须让软件也随之变化。要满足多样化的信息需求，提取合适的信息需求建立模式，就要有相应的系统对需求信息进行分析和总结，通过程序化的模式来制定切实可行的软件方案。

国项目中，在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组，每天技术人员会对分析的结果提出技术实现的难点以及改进的方法，笔者在随后的会议上就会和客户进行讨论，尽量在满足客户需求的同时，使用更简单可行的技术，这样就为以后的开发奠定了基础，使开发时的工作量大大减少。测试人员也在需求时提出从测试角度看到的问题，同样在需求分析阶段得到解决，节省了大量的开发时间。

需求工程在未来发展中会有如下几个方面的着重考虑：（1）缩小需求工程在理论研究阶段取得的成果同实际应用中得到的效果的差距，通过得到的结论来更好的设计软件；（2）规范需求工程的各种机制，可以有需求工程规格数据的搜集、整理、制作、实现以及维护，也可以有需求工程的问题的解决办法；（3）保证需求工程有较高的质量。这一点是需求工程最为关键的要求，质量的高低直接影响了未来实现效果的好坏。需求工程就是对未知问题进行探索、处理的过程。未来必然会朝着对象具体化、分析自动化的方向发展。

5 进行需求分析的注意事项

5.1 需求分析是分析人员与用户共同的责任

用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人员则要认真了解用户的要求，细致地进行调查分析，把用户做什么的要求最终转换成一个完全的、精细的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的要求。在一些项目中，由于时间紧迫，一些模糊问题没有及时澄清，导致最后返工，影响了项目进度。

5.2 需求分析阶段研究的对象是软件项目的用户要求

需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。在一些项目中，针对客户提出的需求，了解客户的意图后，发现技术上实现有很大难度。我们了解到这个需求对客户来说不是十分重要，于是和客户商量出一个折中的解决方案，绕过技术难点，并且没有降低客户满意度。

5.3 主动积极了解客户业务和相关知识

求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语教给分析人员，而客户不一定要懂得计算机行业的术语。由于通常情况下客户对计算机术语了解不多，需求分析人员应该尽量将计算机术语转化成通俗易懂的语言，这样便于和客户沟通。而对于客户方面的术语，一方面不懂的时候一定要问；另一方面也要多学习。

项目需求分析范文第2篇

关键词：水利；集成项目设计；需求分析

中图分类号：TV512 文献标识码：A 文章编号：1006-8937（2013）08-0158-02

随着我国的经济发展速度的加快，各种基础建设步伐也逐年加快，在水利建设中的投资也空前巨大。而在水利工程投资项目中，自动化系统的投入作为一股新兴行业受到广泛关注。越来越多的大型泵站、水闸项目为了实现对工程的实时监控和信息管理，提高工程的运行管理水平，要求投入自动化系统以确保水工建筑物的安全使用，并提高工程效益。

这就要求有一大批素质高、善管理、会经营、懂技术的项目管理人才参与其中。怎样管理好工程，在建设施工中节省资金、降低损耗、节省劳动力以保证项目质量目标、进度目标如期实现。要实现这些目标，项目经理以及其所在的项目组首先要做的就是做好需求分析，弄清系统该做什么，不做什么，严格为业主把好关，为系统的成功实施打好基础。基础打的牢不牢就像一栋大楼的地基一样，对整个工程的实施至关重要，是项目实施成败的关键一步。

水利工程自动控制系统项目同一般的信息系统集成项目的过程一样，分为启动阶段、计划阶段、实施阶段、收尾阶段。启动阶段是正式认可一个新项目的存在，或者是对一个已经存的项目让其继续进行下一阶段工作的过程。其中需求分析属于启动阶段的工作范畴，是新项目启动阶段的主要工作环节。

在具体项目中，需求的来源通常来自于以下几个方面。

1 合同制约因素

当业主招标书后，其内部定义的所有制约因素，就成为界定需求分析范围的重要考虑因素。也是项目组编制投标文件，中标后签定合同的重要依据。当项目完成后，合同条款就成为验收审核的重要标准，项目经理要考虑的就是一切按合同完成功能。

例如在一项水闸自动化项目招标书中提出：自动化系统投运后，要具备测量和数据处理功能，其中包括：检测显示所有设备的开关状态；测量显示上、下游水位和闸门的启闭高度；测量各电量及电动机的电流等值；在引水或排涝工况下，根据设定的水位条件，自动进行开关闸预告；在开闸运行中自动计算瞬时流量、日平均流量、每闸次的引排水量。

项目组在前期需求分析的过程中就必须把这些功能以及实现这些功能需要设计的硬件、软件资源全部考虑进去。

2 业主客户要求

每一个项目都具有其独特性，使用者在使用过程中都会有一些特殊的要求，而这些功能往往是在合同中不曾涵盖的。这就需要在项目的前期启动过程中，与用户先行进行沟通，了解他们是否有什么具体要求。但由于很多情况下用户前期对项目理解不够，往往在初期无法提出具体需求，随着项目的日趋推进，业主对整个项目有了一定直观的了解后，可能需求也随之增加。这些增加的可能性越大项目风险就会越大，因为很多需求是偏离整个项目的最终目的的。我们在需求分析的时候就要充分考虑到哪些需求是相对固定的，哪些可能会是产生变动的，考虑到他的可变性和可增加性，这样前期功能设计的时候不会因为后面的变动和增加而影响整个工程。这一部分的需求往往难以把握，这就需要项目组成员根据历史资料和丰富实战经验进行先期考虑。

3 历史资料和实战经验

在项目范围界定期内，应该考虑以前项目计划的有关历史资料。大多数同类型工程项目都有其特定的规律，项目组完全可以根据以前类似项目界定工作范围。

例如每个水闸自动化项目中都需要相应的报表，以实现对闸门的实时查询和历史查询。但假如在自动化项目具体的招标书中并没有具体实际的要求，项目组成员不能对这个方面不予考虑，而是要依据以往工程所做的报表，总结出大致报表的规律。如报表可分为两大类：事件类和数据类。事件类是指运行事件和重要的系统操作，如全部的报警记录、闸门启闭记录、手动命令等。数据类是采集的实时水位和闸门开度，计算的实时流量、引排水量，存储的每日8时流量、8时水位、最位和最低潮位等各特征值，为生成各种报表、曲线和图形所用。中央控制室配有打印机，可定时或实时打印各类报表。总结后把大致规律与本工程相结合，总结出适合本工程的几类报表，先行把各类资源考虑进去。否则当工程交付时，用户提出再进行功能追加，势必会造成工期延误，影响整个项目的顺利进展。

但是毕竟不是每个分析人员都是专业而合格的，所以需求分析报告不一定很完善，会存在或多或少的缺陷。为避免这种情况的发生，需求分析必须经过项目组内部成员和业主的共同审核，讨论达成一致后双方共同签字，确认。

在多个工程具体实施中，发现在此阶段可能出现的问题如下：

①需求分析过于笼统，只关注到面上，没有关注到点上。往往开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。

②需求报告没有获得业主的评审，因为业主早期对项目的不确定，如果只有我方评审通过，不去向业主仔细的分析和解释，只求客户签字，就会在后期造成隐患。因为很多时候具体用户在自动化系统未投入运行阶段对其认知非常模糊，有时甚至要到系统投运后才能有完全深刻的理解。虽然业主签字即能够给日后出现问题时划清我们的责任，但是却不能保证业主的满意，不能保证项目实施成功。

③需求分析中含有技术实施上有难度的功能。很多时候，客户的想法在实际实施过程中是不现实的，一味的求全和盲目按照客户的设想，势必造成整个项目实施过程中受阻。此时，项目经理要做的就是与客户进行协调磋商，分析具体的性价比，建议用更为简便的方法来替代。例如曾有客户要求在一个闸门自动控制系统中加入对闸门土建方面以及钢结构方面的检测数据，而要满足这项功能需要购置大量相应设备与自动化项目进行整合，这样前期设备采购成本和后期系统通讯调试工作量都大幅提高。而此项工作完成后，仅仅是在几年甚至是十几年后才有可能发挥起真正作用，这是与一个自动化项目的生命周期是不相吻合的。故与用户协商后，建议过一段时间后请专职水利勘测人员进行检测，达到最高性价比。

④项目的完成度受业主预算的限制。当前大部分项目都是经过论证、概预算、招投标等多步发展最终确认的。在项目投入上是有上限的，在此情况下，项目的功能完成度将受影响，毕竟功能越多越完善，相应的软硬件开发成本就越高。如果一味追求功能多，将势必损失质量。这种局限性需要事先告知客户并得到理解。

⑤此项工作的繁琐枯燥，势必造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项反复的工作，需要和业主之间不断的商讨和确认，不断的被驳回和不断的修改。大部分的客户虽然安排专人负责这项工作，但是该负责人大多数情况下都是相关部门领导，本身对项目细节就不是非常理解，特别当他被很多其它的事务缠身，无心细看需求报告，他很可能会仓促签字认可，造成对设计没有完全理解和认可。

参考文献：

[1] 柳纯录，刘明亮，高章舜.信息系统项目管理师教程[M].北京：清华大学出版社，2008.

项目需求分析范文第3篇

[关键词]项目策划人才；社会需求；调查分析

项目策划，本身是一种思维过程，兼具建设性和逻辑性。该过程主要体现在总结所有可能对决策造成影响的决定，使其起到指导、控制未来的作用，以便借此实现方案的目标。现如今，项目策划的受关注度越来越高，而该类人才的社会需求，也在与日俱增。笔者针对此进行简单的调查和分析。

1.项目策划人才的社会需求调研设计

笔者于2015年春季，采用调查问卷、电话访谈、座谈会、企业调研、网络查询等形式完成调查，共发放300份调查问卷，回收270份，有效问卷259份，问卷的有效率在96%左右。本次调研，主要在各个单位的策划部、大型庆典策划场所等，就体育、旅游、公关、文化、房地产等领域的项目策划人才展开调查，调查覆盖面较广。

2.项目策划人才的社会需求特征

此次调研中，被调研到的民营企业占了大多数，这些企业从事项目策划的人员并不多，往往不超过十人。通过反馈到的问卷，笔者发现有近七成的企业，在一年内打算招收项目策划方面的人才，项目策划人才的需求量明显呈递增趋势。还有部分企业，对项目策划人的工作经验颇为关注。

2.1人才素质需求特征

调查结果表明，项目策划相关单位，对员工往往涉及专业素养、职业道德素质及其他素质的需求。这些素质中，排在前三位的依次是认真负责的工作态度（21.2%）、吃苦耐劳的意志品质（19.6%）以及市场调研的能力（16.8%）。多数企业认为，首先，道德层面的素质是最重要的，其次才是学习能力、专业技能水平等职业素质。

2.2人才岗位需求特征

调查结果表明，项目策划人才的工作岗位一般分为两种：技术类岗位和营销推广类的岗位。其中，技术类岗位最典型的是策划师，其范围非常广泛，最典型如婚礼策划师、旅游策划师、房地产策划师等；营销推广类的岗位，典型如市场营销专员。在所有岗位中，房地产策划师占比高居榜首，笔者认为这可能和如今的房地产发展状况有一定关系。其次是网络营销、网站建设方面的策划师，占的比例也较大。

2.3人才能力需求特征

调查结果表明，近五成企业，需要复合型人才担任项目策划职务，28%左右的企业更看重信息收集整理、整合资源的能力；26%左右的企业更看重推广项目的能力，如沟通、组织能力等；22%左右的企业更看重专业技术。

3.项目策划人职业素养方面的能力要求

3.1市场调研能力

对于项目策划人才而言，市场调研能力至关重要。策划人的灵魂在于其能够将发展的机遇进行准确的预测并善于把握，抓住机会引领整个市场的潮流。市场调研能力，即策划人分析市场现状，进而针对未来的趋势进行预测的能力，它对策划工作人员未雨绸缪、深谋远虑的战略眼光，有着非常高的要求。市场调研能力强弱与策划结果息息相关。

3.2整合能力

整合能力不可或缺。项目策划人才并非比别人更加聪明，他们只是善于将不同的资源要素进行整合，针对各方面的力量加以协调形成合力，以达到策划的目标。整合能力，即策划人按照策划本身的需要，将零散的策划资源进行整合的能力。它包含了收集策划资料、找寻策划人才、制定策划方案等，即对人、事、物的统筹和安排。对于项目策划人才，特别是策划经理人而言，其整合能力会对策划的结果产生直接的影响。

3.3洞察能力

洞察能力，即策划人对客观现象，进行正确、全面、深入分析的能力。项目策划人才的洞察能力，关系到策划的结果质量如何。项目策划人才，要具备全面分析的能力，善于统观全局，并且能够通过现象抓牢事物的本质，还要着眼于未来的发展，对未来的形势进行科学的预见。这样，才能够保证项目策划的强针对性。对项目策划人才洞察力的要求，往往是“观察别人没有注意到的东西”，因此，项目策划人员要善于从曾经的、现在的信息资料中，寻找重要素材。

例如，一家公司欲进行广告宣传，为此寻找畅销的报纸或者杂志。公司苦于无法打探到报纸或杂志的真实发行量，也就无从判断那种报纸杂志是否畅销，是否值得在其上面登出广告。公司策划部门结合过往的信息资料，细致观察报纸和杂志是否摆上了街边的书报小摊，若摆上了即为畅销，街边的书报摊几乎不会卖不畅销的书报。就这样，公司据此选择了登广告的报刊，抓住了市场机会。

3.4创新能力

现在很多企业的项目策划离不开创新。项目策划展现了思考问题的智慧程度，其本身即是思维的革新。真正的策划决不能失去了创新元素。典型如婚礼策划师，在营造婚礼的浪漫情境中，创意和想象力非常重要。

3.5执行能力

项目策划不是纸上谈兵，策划人在进行细致缜密的构思后，就要采取实际行动。有时候，执行能力如何，甚至会成为项目策划方案是否取得成功的关键因素。更何况，项目策划不仅仅是做出一个策划方案，还要将切实可行的执行方式与流程设计出来，特别是在基层工作的项目策划者，必要时要做好监理、指挥工作，甚至要亲自执行。

4.针对项目策划人才培养的建议

社会对项目策划类的人才，有着越来越大的需求。与此同时，社会对项目策划人才素质方面的要求也更高。正因为此，针对如今社会的需求，将现有的教育管理模式进行改革，使项目策划人才能更切合社会发展的需要，具有非常重要的现实意义。

4.1明确培养目标

现有研究成果指出，单纯的管理型项目策划人才，已难以满足社会需求，目前阶段项目策划人才培养亟待改革。现阶段社会需要的，是善于策划、通晓资源整合、极具创新精神和项目推广能力的项目策划人才。实际调查显示，在项目策划类人才的进修课程中，管理学高居榜首，其次是市场营销。笔者认为，课程设置中应该增加社会性、实践性强的课程数目，减少理论课，因为项目策划主要面向市场推广，在这个推广过程中，实践是必不可少的。

4.2改革培养方式

项目策划，有着很强的实践性，因此对每位策划者而言，资源与信息的整合能力、对问题的发现能力、市场调研能力、分析决策能力、洞察能力非常重要。也正因为此，组织机构要让策划者从理论知识环境走入实际策划环境中，让他们在特定事件下，拟定策划方案，从而对策划者的实战能力进行系统培养。策划者个人也要积极参与实训，通过有效的实训提高自己对信息的整合能力以及对趋势的分析与判断能力。可以选择一些热点问题让策划者去解决，从而锻炼其应变能力。

4.3提高该类人才的综合素质

对项目策划者而言，拥有较高的综合素质很重要。良好的团队精神、法制观念、品德修养，是项目策划人才必备的综合素质。人际交往与沟通能力，关系到项目的推广效果，因此这也是项目策划人才不可或缺的能力。所以在针对项目策划人员进行培养时，除了针对其专业素质进行培养外，综合素质也不能忽视。

项目需求分析范文第4篇

关键词：软件工程；需求分析与管理

中图分类号：TP311文献标识码：A文章编号：1007-9599 (2010) 15-0000-01

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 problems.This paper analyzes the problems and issues reference for these recommendations and solutions.

Keywords:Software engineering;Requirements analysis and management

在软件项目开发过程中，需求分析与管理十分重要。但在实际的软件项目开发的需求分析与管理过程中存在一些问题，如果不重视这些问题，往往导致项目开发进度延期、超出项目预算甚至项目开发失败。

在软件工程理论中，需求分析是指构建一个新的系统或者完善现有系统时，确定系统的目标、范围、功能需求和非功能性需求等方面所涉及的工作。

需求分析是软件工程的一个关键过程，也是软件项目开发的一个关键阶段。软件需求分析人员需要准确、清晰和形象的表达和描述用户的真实需求。需求分析阶段的工作是否准确和充分、提交的软件需求说明书是否完善和规范、需求管理的方法是否正确将直接影响和决定整个项目开发是否能够按照时间进度和在项目预算范围内完成。

在项目开发过程中，经常出现如下情况：软件需求分析人员描述的用户需求不完整、用户需求经常发生变化、软件需求分析人员与系统设计人员的沟通障碍、开发人员边做需求分析边做开发、用户需求管理混乱、缺少专业的需求分析与管理工具等。这些情况的出现使整个项目管理风险加大、系统代码返工率高、项目团队士气日益低下和用户对项目开发进度的抱怨越来越多，最终可能导致整个项目开发失败。

软件需求分析人员描述的用户需求不完整主要原因：一种情况是没有专职的软件需求分析人员，兼职的软件需求分析人员同时担当该模块的设计及开发，导致需求分析没有真正从业务的角度来考虑，而是从技术实现的角度考虑。有的即使有专职的软件需求分析人员，该软件需求分析人员也不具备该行业的业务知识和经验，对行业术语不了解，有的甚至聘用刚刚毕业的学生去做需求分析，导致整个需求分析不准确甚至出现偏差。另外一种情况是专职的软件需求分析人员没有系统的学习和掌握软件需求分析的基本方法、原则和技巧，了解的业务需求不能准确直观的表达和描述，编制的软件需求说明书过于简单和形式化，导致项目开发的其他人员不能很好的理解用户需求，有的甚至要重新做软件需求分析。

为详细和准确的描述用户需求，需要注意以下几个方面：

首先需要由专职的人员担任需求分析工作，而且软件需求分析人员需要系统的学习和掌握需求分析的基本方法、原则和技巧。例如获取业务需求常用的方法有用户访谈、速记、谈话录音、会议纪要等；其中用户访谈的要点包括确定访谈的时间、访谈的对象、设计用户访谈计划并提前发送给用户等；速记要求软件需求分析人员能够快速准确的记录用户描述的业务需求和业务流程。谈话录音和会议纪要是为了更准确记录用户描述的业务需求，便于分析和理解用户需求；软件需求分析人员最好具备该行业的业务经验和知识或者聘请该行业的业务专家指导，这样有助于软件需求分析人员准确分析和理解行业术语、行业业务需求和行业业务流程。

其次，描述的软件需求说明书内容应该包括系统的目标、范围、功能需求、非功能性需求和系统界面原型等方面。非功能性需求主要包括系统界面的可用性、易用性、操作便捷、时间效率高、出错率低和操作系统需要的专业领域知识少等方面；系统界面原形是指使用专业界面原形工具（Axure等）或者直接使用开发工具（Visual Studio等）编制系统的初始用户界面，便于软件需求分析人员、系统设计人员和开发人员更直观和形象的与用户沟通和明确需求。非功能性需求和系统界面原形在需求分析阶段非常重要，我们在项目开发过程中应该注重非功能性需求和系统界面原形。

最后，对于软件需求分析人员编制的软件需求说明书要做好需求验证工作，参加需求验证工作的成员应该包括项目组所有成员、该行业的业务专家和最终用户。在需求验证会议上提供的需求验证材料应该简单、清晰、直观和明确，不能笼统的提供一些复杂的业务流程及繁琐的文字说明。在需求验证会议上可以通过情景模拟和系统界面原形的方式演示。情景模拟是根据不同业务角色模拟整个业务办理的情况。系统界面原形能让用户切身感受到系统的界面效果，便于直观、形象的沟通和交流业务细节和业务流程。

在项目开发过程中，用户需求发生变化的情况经常出现。我们不能避免和逃避用户需求变化情况的出现，但应该控制和管理用户需求变化，应该有需求变更的流程、需求变更的团队、需求变更的平台、需求变更的影响分析以及固定的需求变更周期。对于用户提出的需求变更，我们首先应该做好详细的记录，然后将需求变更的记录通过需求变更的流程提交给需求变更团队评估和确认，最终在需求变更的平台中反映出来，同时要做好需求变更的影响分析报告并及时反馈给用户。需要注意的是对于需求变更我们要有固定的需求变更周期，不能用户有需求变更马上要求项目团队及时更改系统，这样会加大项目管理的风险和影响项目团队的士气。

项目需求分析范文第5篇

[关键词] 需求分析 需求变更 需求控制

一、问题的提出

什么是需求分析?

要知道需求变更是什么,首先要知道什么是需求分析。

需求分析是指理解客户需求,就软件功能与客户达成一致,估计软件风险和评估项目成本代价,最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。

什么是需求变更?

根据软件工程思想定义,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求,或对原有需求进行修改和削减,均属于需求变更。

二、需求变更的原因及影响

1.需求变更原因

一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后,在软件开发过程中用户改变了需求,这只能迫使开发工作返工,丢弃一些无法修正的部分。无疑这会造成一定的损失,但又无法完全避免。要求用户一次性把需求讲清楚,并且不允许此后需求有任何变更,这是不现实的。只能尽量减少需求变更,降低它所造成的影响。

二是系统因素:在系统内部,如计算机硬件、系统软件或数据的变更要求与其相适应。

三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更,或是业务要求变更导致的需求变更。

四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分,致使需求规格说明中隐含着问题,在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分,如未能如实获得用户的潜在需求等。

软件需求一旦出现变更,它可能要涉及到一些相关的代码和文档的修改,为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段,并且随着项目的进展,越晚的需求变更引起的损失越大。

2.需求变更给软件的开发工作带来的影响

需求变更对软件开发的影响是多方面的,概括的看,包括以下三个方面:

(1)增加项目的人员、费用开支,影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差,需要进行需求变更。这无疑要增加项目的人员、费用的开支,并对开发进度造成影响。更有甚者,如果变更频繁,可能对项目造成较大影响,严重时可能直接导致项目的失败。

(2)影响软件质量。在一个复杂的软件系统中,需求之间具有一定的联系,相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节,就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时,这些错误一般难以被测试人员发现,将直接影响系统质量,严重时可导致系统崩溃。

(3)影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧,如果没有恰当处理,影响双方的互信,从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧,影响合作关系。

三、采取的对策

1.首先是预防

尽量做好需求分析工作,以期减少需求变更的频次,为此在需求分析阶段着重处理好以下问题,力图使需求分析的结果更接近目标。

(1)培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上,而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此,双方的参与者都需要认识到:要想获得成功,自己需要什么,合作方又需要什么。只有这样,才能建立融洽的合作关系。因此,培养正确的需求意识是双方都需要努力的,而开发人员在这个阶段应该发挥更加积极主动的作用。

首先,需求分析人员应该接受一定的正规培训,以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧,以及收集整理资料的能力等。在参与具体项目时,分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识,以更好地理解用户的需求。

其次,开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与,项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训,使他们真正理解需求分析的重要性和忽略需求带来的风险,并对计算机系统有一个大体的了解,这样用户才能够主动地参与需求分析。

同时,正因为不可能一次就完全了解用户的需求,而且在系统开发过程中还需要不断地请用户参与,因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此,需求分析人员需要对用户解释一些做法的必要性和合理性,以得到用户最大的支持与合作。

(2)从业务需求入手。用户认识到了需求分析的重要性,但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手,任何企业对自己的经营运作目标应该是比较清楚的,这样的经营背景让用户不仅有话说,也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离,只有当系统真正置身于它的社会和组织环境中,它的需求才能清晰地反映出来。

(3)充分利用需求来源。有了以上需求背景,就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多,可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡,对于直接用户的众多需求如何取舍等。

同时,用户往往对计算机期望过高,认为计算机可以解决当前存在的所有问题,因此会提出很多的功能需求,并且希望在很短的时间内看到成效。但是,由于技术、人力等资源的限制,并不一定能够在设定的时间期限内满足用户所有的期望,这时就应该尽早确定出交付的产品应具备的最重要功能,即设定需求的优先级。

在这个阶段,可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发,而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉,容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计,也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。

(4)提供选择方案。由于用户对软件系统缺乏经验,或者由于用户的运作机制还未完善,或者由于其他种种原因,用户可能仍然不能对一些需求做出明确的说明,收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点,供用户选择或者启发用户确定需求。

如果需求分析做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候,开发方一定要据理力争,此时这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。

2.分级管理客户需求

软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全的正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到了客户的投入收益,所以有的时候项目经理反倒应该为客户着想。

对于项目中的需求变更,可以实行分级管理,以达到对需求变更的控制。

一级需求变更是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成员的所有努力,所以定为“Urgent”。

二级需求变更是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续,所以是“Necessary”。一般新模块关键性的基础组件,属于这个级别。

三级需求是后续重要的需求,如果不被满足会令整体项目工作的价值下降,为了体现项目价值,也是开发人员自已的技术价值的证明,所以定为“Needed”。一般性的重大的有价值的全新模块开发,属于这个级别。

以上三个等级是应该实施的,但时间性上可以作优先级的排列。

四级需求是改良性需求,没有满足这类需求并不影响已有功能的使用,但如果实现了则会更好,定级为“Better”。界面和使用方式的需求,一般在这个档次。

五级需求是可选性需求,更多的是一种设想,以及一种可能,通常只是客户的的一种个人喜好而已,定级为“Maybe”。

对于四级需求,如果时间和资源条件都允许的话,不妨做下去。对于五级需求,正如对它的描述一样做与不做是“Maybe”。

3.加强需求变更的控制

在需求分析阶段工作完成后,需求变更仍可以会发生,因此就要加强对需求变更的控制,主要有以下原则:

(1)建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

(2)制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。

(3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。

(4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。

(5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。

(6)妥善保存变更产生的相关文档。

这六大原则看起来简单,但真正实施起来有难度,还需要依据理论知识配合开发项目组的实际工作情况,在实践中不断摸索总结。

四、总结

软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理,将需求变更的频次大幅度降低,从而为软件项目的顺利实施打下坚实基础。

参考文献:

[1]王 莉 吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展,2007,17(1):120～121

[2]王 强:软件开发项目中的需求变更管理[J].电脑知识与技术(学术交流),2007,(11)