❶ 如何做好跨产品线需求管理
众所周知，产品的从0到1是最难的，也是最考验产品经理个人能力的阶段，但是一旦产品进入了平台期，就会催生N多产品。比如网络围绕搜索引擎构建的产品服务多达上百个；小米以手机为起点在短短数年内发布了超过200款产品；苹果公司在鼎盛时期旗下产品数量超过1000个。管理如此多的产品绝对是一个挑战，我们称这样的产品管理者为产品VP（高级副总裁）或CPO（首席产品官）。为了便于管理我们会根据其相关性、属性、业务模块等特点划分为若干产品线，由具体的产品负责人去管理，这样的管理者我们称之为产品总监。在产品总监所带领的产品部门治下会有不同的产品经理去负责所对应的具体产品。由此可见，在需求管理上涉及多产品，多产品线与我们通常处理需求的方式有很大的不同。这要求产品经理不仅在专业上有实践，还要在综合管理素质上有沉淀。
在第1章我们已经对产品、产品线、产品组合等产品概念有了一定的认识。从概念定义上我们不难看出产品、产品线和产品组合是在面临多用户、多场景、多类型、多需求的情况下，为便于管理而进行的需求解决方案组合。因此，在复杂的产品体系下进行统一需求管理，首先要划清界限，在需求提出时就应该明确该需求走那条路径，不同路径对需求的处理和应对机制不同。在本书的框架下，多产品线需求管理路径如图7-4所示，仅供参考。
大型企业都已经建立了标准、规范的需求管理流程，针对短期需求，可以通过瀑布迭代即时发现，即时开发，即时验证，即时发布；针对长期需求，可以列入产品版本计划迭代上线；跨产品的需求需要产品线负责人进行整体的规划，制定产品路线图，进而按计划实施交付；跨产品线需求则需要根据需求的大小、价值度、紧急度等因素进行区分，一般规模小、价值低、非紧急的需求可以通过协调跨产品线工作解决，规模大、价值高、紧急的需求要走产品组合投资决策立项流程。以上路径构成了需求管理体系，基本可以承接所有需求。
伴随着互联网的高速发展，市场竞争日趋激烈，对需求的响应速度要求越来越高，同时系统也变得越来越复杂，效率和成本问题日益突出。由此，企业在应对市场客户需求时，逐步的演化出了业务中台、产品中台、技术中台的管理概念，均在于提升前台需求解决效率、降低成本、提升综合经营效益。另外，工欲善其事，必先利其器。在大公司，还会有诸多现成的工具辅助；在创业公司需要自己寻觅。好在市场上各种工具繁多，任你挑选，比如禅道、Tower、Worktile等。
❷ 如何把控需求的重要性和紧迫性
需求管理源于业务需要，始于需求挖掘，继而需求分析，需求定义，需求验证。周而复始。
一，业务需要说明需求产生的原因，可能是高层制定的目标，中层对工作流程的调整，基层碰到无法解决的问题，用户需要，外部环境变化，竞争对手策略变化或者政府政策调整等。需求人员在明确业务需要时，首先明确干系人，其次获取干系人要求/需求。可以采用的方法包括：行业基准（竞品），业务规则分析（产品分析），头脑风暴，焦点小组，功能分解，根源分析等。
二，需求挖掘阶段的目标是找出干系人的真实需求。单方面的口头描述或者规范章程都可能与实际需求相差甚远，因此需要需求人员收集各方面需要，交叉验证，合理推导，发掘出用户的实际需求。工作步骤：确认干系人，收集实际情况，整合多方面信息，确认实际需要。方法包括：访谈，观察，问卷，焦点小组，头脑风暴，可用性测试，竞品分析，数据分析，文档分析，咨询专家等。
三，需求分析阶段则是对已经收集的真实需求进行规整，包括两部分内容，组织整理需求和对需求排优先级。组织整理需求采用相同粒度描述需求，并描述需求间关系。主要方法包括：功能分解，业务规则分析，数据模型，流程模型，范围模型，用户经历，场景和用例，组织模型。需求优先级划分通过定义需求的优先级，为计划安排提供有价值的参考。可以参考的定义维度包括：时间，预算，业务价值，业务和技术风险，实施难度，成功可能性，规范和政策，与其他需求的关系，与干系人的协议，紧急程度等。可采用3/4级优先级定义，或者MoSCoW模型定义，其中M=必须S=应该C=能够W=将要。
四，需求定义主要工作为根据前期整理的相关文档整理需求说明。输出包括：业务需要，需求陈述，组织整理后的需求以及需求优先级。需求说明主要包括：业务需要，业务需求和系统需求。·五，需求验证包括需求检验和需求确认，即需求过程中的检查和需求完成的测试。需求跟踪矩阵是个好东西，可以在需求分析阶段产出。
❸ 现代IT项目中的需求管理如何做
在项目管理中，需求是为了成功完成项目而必须完成的一组任务或条件。它包括产品功能、行为、服务甚至是流程。这些需求的目的是确保资源和公司的长期目标在项目结束时保持一致。
一般情况下，需求可以分为以下几类：
业务需求：指业务的总体需求，旨在实现项目。属于这一类的需求是更基本的、与组织的长期目标相一致的长期需求。
解决方案需求：更多以产品为中心，并深入研究。它们可以是功能性的，也可以是非功能性的，确保产品的最终结果既满足产品需要做的事，也满足产品应该做的事。
利害关系人需求：描述了关键人员，他们在里程碑上签字，完成工作，最终确定可交付成果等等。有时他们可以是客户、团队成员、业务伙伴或关键领导。它需要一个坚韧的项目经理来确保所有利害关系人的需求在整个项目中得到很好的平衡。这对于良好的利害关系人管理必不可少。
你也可以定义适合项目的需求类别。
8Manage PM提供了一个用于项目需求管理的平台。系统自动侦查需求的变化，并把需求变化与项目的各个阶段关联，以此提醒用户，让用户更好地了解需求变化所带来的影响。系统也能自动追踪需求依赖及间接变化，让用户尽早了解其潜在影响。
该企业级工具拥有在整个项目过程中准确捕获和传达需求、目标、进度和相互依存关系的能力。团队可以使用该系统来缩短周期时间，提高质量，减少返工并最大程度地减少证明合规性的工作。
无效的需求管理流程，或更常见的是不采用任何需求流程，已被确定为项目失败的主要原因。从项目生命周期开始就实施的需求流程的投资最终会得到回报。
❹ 如何分析和管理产品需求
有效地管理产品需求
产品经理首先需从用户那里收集反馈信息，分析用户需求，再根据用户需求进行产品功能规划，这些待实现的产品功能对于产品来说就是产品需求。
将用户需求转化为产品需求
用户需求收集的来源与方法有很多，包括竞品分析、访谈、问卷调查、焦点小组、可行性测试、现场观察、数据分析、任务和场景分析等，在不同阶段应用的收集方法是不一样的，需求收集是持续的过程，贯穿产品发展的生命周期。
之所以将用户需求转换为产品需求再进行管理，是因为多数时候凭借经验根据用户需求制定初步的产品解决方案并不需要耗费多大的精力，却可以让我们更加深入地理解用户需求以及产品需求和产品之间的关系，同时也方便我们准确的评估满足用户需求的产品新方案的技术可行性和优先级。
记录产品需求的属性和信息
选择性的记录产品需求的一些重要属性，将有助于我们更好的管理产品需求，如产品需求所属模块、产品需求的需求类型、需求方代表等。
#产品需求所属模块
一个产品往往是一个复杂的功能系统，为了产品更容易分析和开发，产品会被分解为几个功能模块，每个功能模块负责完成产品一部分的系统功能。需求所属模块就是产品需求所隶属的模块，用来直观地说明产品需求在产品结构中的具体位置。比如微博数据中心分为粉丝分析、内容分析、互动分析、行业趋势分析四个模块，而页面访问分析是隶属互动分析这个模块。
#需求类型
对产品需求进行必要的分类，不仅可以帮助我们更好的管理需求，而且还可以更好的分析需求，对每个需求的价值大小做出更准确的判断。同样的产品需求可以按照不同的维度进行分类，具体采用哪种维度可以根据实际需要来决定。比如微博数据中心的后台管理支持系统就要针对代理商需求与零售商需求进行区分。
#需求方代表
需求方代表就是最初提出该用户需求的人员，在产品功能规划与版本升级时，如果需求方案不得不调整，那么产品经理可以迅速找到相应的需求方代表进行沟通。比如运营人员提出发票录入系统的相关问题，在产品实施过程中如果需要进行调整可以快速找到其进行沟通，确保新的产品需求能够正确无误地反映用户的真实意愿。
确定产品需求优先级
❺ 如何做好产品需求管理
需求不总是显而易见的,而且它可来自各个方面。需求并不总是容易用文字明白无误地表达。存在不同种类的需求,其详细程度各不相同。如果不加以控制,需求的数量将难以管理。需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。需求有唯一的特征或特征值。例如，它们既非同等重要，处理的难度也不同。需求涉及众多相关利益责任方，意味着需求要由跨职能的各组人员来管理。需求可能发生变更。需求对时间敏感。当这些问题同时出现，如果没有需求管理或处理技能不足以及缺乏易用工具等情况时，业务就会进入混乱，甚至是面临瘫痪与失败。为此我们不得不重视和加强需求管理。
需求管理是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知产品需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一个需求池，然后通过管道（流程规范）进行流转，将产品价值交付客户。可以说，需求管理指明了产品开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合，如图7-3所示。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
图7-3 需求管理流程（示例）
建立需求管理流程的首要任务在于使产品团队对于需求管理都有一个明确的认识，并明确每一个人在项目中所起的作用，进而对整个项目有一个整体把握。因此，需求管理需要解决的第一位也是最基本的任务就是建立需求流程和规范，并使所有相关人员达成共识。
为了建立一个真正满足工作需要的需求管理系统,产品团队首先必须确定系统要解决的问题，即需求来源。然后,团队必须将采集到的所有需求进行汇总，归入需求池中进行统一管理。继而对需求的有效性、真伪、分类、时效、优先级进行分析、再确定需求是否要接纳进行开发，并做好状态标记。接着对已确定的高优先级需求指定需求负责人对其进行详细分析，并提交评审，通过后列入版本计划。最后由产品开发团队负责需求实现，交由测试人员严重通过后对外发布。如果客户或内部需求提出人员对交付的结果不满意，可以进入需求管理循环处理改进，直到客户满意或解决问题为止。
需求管理是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。
❻ 产品经理如何对产品质量进行有效把控
作为产品人员，对产品的管理主要体现在两个方面，其一是对产品需求的管理，其二是对产品质量进行有效的把控。只有对这两个方面都管理好了之后，才能比较好地让产品符合需求目标，并循序渐进地完成落地。
本文主要讨论产品经理如何对产品质量进行有效把控。
一个产品，想要保证质量是没有问题的，可以对下面几个方面进行测试验证：
1. 功能、流程走通，接口符合要求
2. 交互界面，UI设计符合体验预期
3. 性能优，能承受一定用户量同时使用压力
4. 符合其他安全性，兼容性要求
一个产品的完整的测试过程，从需求评审之后那一刻开始就进行了。我们可把测试分为三类测试。第一类是开发人员自己的测试，第二类是第三方人员测试，第三类是测试人员的测试。如下所示：
在开发人员开发之前，产品人员，可对开发的开发完成成果提出要求，如要求属于开发职责范围内的开发内容，需要自测，并保证流程完整，逻辑正确，同时界面交互需要保证没有明显错误。这样做的好处是，能有一个比较清晰的界限让开发也知道做到怎样的程度才算是完成开发任务，才能正式地交付给测试。
在开发开发过程中，就会一边开发一边自测。而开发完成了之后，提交测试之前，建议多一个开发结果的检查环节，让开发能从用户的使用角度，自己演示自己的开发结果给到团队的核心成员。这样，一方面让开发能为自己做出来的东西负责，另一个方面，也可以在投入测试资源之前能对开发的结果进行检查，避免需要测试的内容却是还没有开发的内容，这样测试的效率就会低很多。
在测试这个环节，产品人员，运营人员，UI人员，交互人员等，以及其他的非开发和测试，但有参与到项目中的人，都可以叫做第三方人员。第三方人员可以在开发过程，开发完成之后，参与到测试当中。但是各类第三方人员参与测试的测试重点是不同的。
产品人员需要仔细检查关键流程，功能实现情况，以及实现效果有没有符合用户的使用体验。交互设计人员，需要检查交互细节。UI人员，需要检查界面，元素，以及UI细节。
在产品进行需求评审之后，产品人员可对测试人员的测试提出相关的要求。测试人员可根据产品的需求说明书，或产品的原型进行测试用例的编写。编写了之后的用例，是否符合产品的输出要求，需要进行详细的测试用例评审，评审完成之后，才能进入测试。
在测试过程中，则可对产品的功能，接口、兼容性进行测试，另外，可进行性能相关的测试，如压力测试，安全性测试等。最终出具测试结果报告，以及BUG清单，给到相关人员，向上汇报，向下提供给到开发人员进行相应的修改调整。
通过以上的分析，可以看到，产品人员需要做下面几件事情：
1. 需要为产品的测试提供详细的产品需求说明/产品原型，为测试提供产品测试的依据。
2. 需要对测试用例进行详细评审，为测试确定目标。
3. 需要自行进行产品的功能，流程，交互，UI等相关的测试
4. 需要在开发人员开发之前，提供开发完成的标准（如功能，流程走通，界面基本美观等）
5. 需要在开发开发完成只有，听取开发对开发结果的讲解，并确定是否可以进入到测试流程。
❼ 需求管理的手段有哪些
本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。
01 概述
本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。知识方法无定论，任何内容先看思路，实战为主。
在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？
说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。
02 需求定义
1. 什么是需求？
需是是用户在某种场景下的未被满足的期望。
为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。
我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。
我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。
看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。强调：需求不是独立存在的，是依附于用户+场景一起存在的。
用户需求案例： 小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）
2. 什么是需求分析？
需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。
这里强调两点：
找到用户需求
解决用户问题
案例： 还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。如，提供早餐外卖，小明可以提前在手机上预定早餐外卖，一起床就有早餐可以吃。这是一个较完整的产品需求。
03 为什么要做需求分析
产品首先要满足的就是用户需求，为用户产生价值，才能创造商业价值。满足用户需求是产生商业价值的本源。
04 在什么阶段做需求分析
需求分析贯穿在产品整个生命周期。
1. 产品概念期
这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD需求文档。（或类似的相关的文档，如需求调研报告、市场调研报告等）
2. 产品设计开发期
这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段交付物：产品原型+PRD操作文档。
3. 上线后-成长期
上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。
4. 成熟运营期
本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。
5. 产品衰退期
当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。
05 需求分析方法
需求分析可以分为三大步： 明确问题–拆解需求–提供解决方案。
1. 明确问题
明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。
需求获取渠道
以下是我们常用的一手需求获取渠道：
收集到的一手需求还不是真正的需求，要先进行一个清洗过程，把一些无用的无根据的站不住脚的异常的等等都过滤掉。具体过程不做介绍啦。
明确问题（提出要解决的问题）
这里一定要注意，提问题的标准：提出的问题要聚焦，明确、开放。不能泛，模糊。要又用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。
正确的问题VS错误的问题：
明确需求的价值：
2. 拆解问题（需求）
拆解需求指的是把已经明确的问题，从多个维度进行拆解，目的就是为了找到更合适的解决方案。 该方法是某课程老师总结的拆解方法，笔者认为非常好，非常清晰和明确的一个方法，这里直接引用。（该方法也是老师对《六顶思考帽》里的解决问题方法做的灵活应用，同时书也推荐给大家）
拆解问题的5个维度：
积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。
否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。
转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。
拆解：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。
脑洞：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。
案例： 问题：某视频APP，用户次日留存率低于30%，需要提高次日留存率 拆解过程如下图：
注意在拆解问题的时候，不要去考虑能不能实现，先去拆解一切想到的问题，最后在分析解决方案的时候再来进一步筛选。
3. 提供解决方案
问题拆解完后，对所有提出的问题列出解决方案，这里注意，一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。
06 需求管理
需求管理指的是如何安排已经明确产生的需求，工作中我们通常会遇到四面八方包括产品经理自己给的需求，但是资源和精力无法让做到有求必应，我们需要去把需求做一个分类和排序，尽可能的去做性价比高的需求开发。 这里我们介绍几种方法，帮助我们做需求分类和排序。
1. Kano 模型
KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。
Kano模型把需求分为5类：
基本型需求
该类需求代表的用户的核心痛点，是产品的必备功能，如果没有该功能，用户会极度不满，甚至不用你的产品。但是如果有了该功能，用户并不会对你的产品的满意度增加。如微博的发布微博功能、社交APP的聊天功能、共享单车的开锁功能等。
期望型需求
这类需求代表的是用户的痒点，代表的是品质，对用户来讲是最好有的功能。好比我们的生活，我们都期望我的生活是有一定品质的。拥有此功能，用户满意度会明显提升（过的还可以），没有此功能，用户满意度会明显下降，但是凑合可以用户（过得下去）。这种需求一定要去努力挖掘和分析，并做好。代表了产品的竞争优势。如社交软件的语音聊天视频功能。
兴奋型需求
这类需求所在暗处，用户自己都想不到的需求。拥有此功能，即便表现的并不完善或完美，用户满意度也显着提升，但即便没有此功能，用户也并不会对产品对满意度降低。如，在微信刚刚推出红包功能的时候，这是一个非常典型的兴奋型需求。
无差异型需求
该功能对用户来讲，是不痛不痒的需求。可用可不用，有或者没有都不会影响用户的满意度。如，我们在设计某个按钮，是20px，还是22px，是第一个还是第二个位置。无论怎么做，对用户并无明显影响。我们就尽量不要去花精力在这上面，只需要执行任意一种即可。
反向型需求
该类需求提供对应的功能后，用户会对产品的满意度降低。该类需求，最好不做。如，前段时间上热搜的一款监测学生上课是否集中注意力的智能科技“紧箍咒”，得到的是网友几乎一边倒的差评和抵制。
Kano模型实施方法：
如何评估需求属于Kano模型中的哪一类需求，我们可以实施以下方法：
Kano模型问卷调研法 可以直接设计问卷调研，通过定量问卷调研得出需求属于哪一种：
按照上表的格式，对每一个功能做一个的调研，充分收集用户的数据并得出结果。
2. 时间管理四象限法
本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序，避免盲目排序。
3. ICE排序法
ICE排序法也是一种比较严谨科学的需求排序方法，通过从几个维度考虑给需求打分，以总分高低去排序。
I（Impact）：影响范围
C（confidence）：对上线效果的自信程度评估
E（ease）：开发难易程度（工作量+技术难易程度）评估
应用实例：
本文由 @娟姐 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
❽ 如何进行需求管理
会面前做充分的准备
你一定要拿出事先准备的问题列表，利用日事清的管理系统看板的强大功能，针对每一个功能点对员工进行提问，一个都不能放过。对非功能的需求也同样不能放过，如客户需要的系统至少连续运行多少小时不出问题，系统在若干数量的访问者访问时的响应时间范围等。
一、 让客户打开话匣子
对客户进行提问，引导客户说出他们的需求，是非常关键的，这里面的学问也是很大的，问恰当的问题，问能让客户打开话匣子的问题，你就胜利了。 这时你会面前的准备工作就显得尤为重要了，你要针对他们要做的软件的功能，一部分一部分的问，不能着急，要深入，并细致，
二、 千万不要浪费客户的时间
和客户面谈时特别要注意一点，就是千万不能浪费客户的时间，让他觉得非常无聊，这是捕获需求最大的忌讳
三、 发挥原型的效力
原型对于提高客户对软件的认知程度有很好的效果，他能使客户对软件有一个直观的认识，面对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。
四、 充分利用需求确认会议
需求确认会议通常由全体涉众（利益相关人）参加，这可是个确认需求的难得的机会，大家能聚在一起，这样的机会其实很难得，所以一定要珍惜
❾ 软件需求该如何管理
启动软件项目的原因是软件需求的存在,软件开发模型有瀑布模型、快速模型和增量模型等,但无论采用哪一种模型,软件需求分析是软件开发过程的基础。在软件开发统计数据中,软件项目中40%~60%的问题都是在需求分析阶段埋下的隐患。而在以往失败的软件项目中,80%的失败项目是由于需求分析的结果不明确造成的。因此，一个软件项目成功的关键因素之一就是对需求分析的把握程度,而软件项目的整体风险往往表现出需求不明确、业务流程不合理,所以,需求管理是项目管理的重要一环。
软件需求是:①用户为解决某一问题或达到某一目标所需条件或权能;②系统或系统构件为了满足合同、规约、标准或其他正式实行的文档所需具有的条件或权能;③一种反映上述①或②所述条件或权能的文档说明。它包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,例如性能要求、质量标准,或者设计限制。
软件需求就是指用户希望软件能做什么事情,实现什么样的功能,达到什么样的性能。因此,软件项目管理人员要准确地理解用户所提出的要求,进行细致的需求调查分析,将用户的非形式化的需求陈述转化为完整的需求定义,并依据此定义转化为需求规格说明书。