的产品。从这层意义上说，需求管理是产品质量的基础。
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
根据上面描述的具体方法及步骤，由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险，应引起项目相关干系人的注意。这些风险主要表现如下：
1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。从另一方面来看，他们对于计算机的理解肯定不是很到位，而我们如何引导，正确梳理出正确的需求就需要先从工作业务流程出发，而不是先从计算机方面来考虑问题。
2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。针对此类问题我们一般的做法是在项目开始阶段先确定好一个与客户沟通过的需求调研计划，当然这样还是经常会有变动，但相对来讲从责任上来讲，客户也会有一定的压力，因为如果不配合可能会导致系统进度的延误，其实这也不是客户希望看到的。
3）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。针对这类需求变更的问题，个人认为是影响进度的最大的敌人，目前我们的做法是每次根据客户的需求整理出一个书面的文件，由客户签字确认。当然这里还有一个很重要的问题就是不是每个需求都是必须做的，我们要学习如何拒绝客户。
4）需求的完整程度。需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员带来挫折感，降低他们完成项目的信心。
5）需求的细化程度。需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。
6）需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理