开发一个软件项目，如果采用瀑布模型(或改进型瀑布模型)的话，通常会包括以下几个开发阶段，即：需求分析、系统设计、系统编码、系统测试、系统交付(及后续维护)。在项目管理过程域中，主要包括：项目规划、立项管理、需求管理、项目监控、风险管理和结项管理等。
我们把所有与需求相关的活动统称为需求工程。需求工程的活动又可分为两大类，即需求开发和需求管理。需求分析师通过需求调查(调研)、需求分析和需求定义，完成需求开发工作。而项目经理则通过对需求确认、需求跟踪和需求变更控制的主导，实现需求管理。
软件需求工程是软件项目开发工作的一个重要源头。它是由两个角色共同完成的。需求分析师一定要尽可能准确的获取客户需求，尽量一次做对，编写出高质量的《用户需求说明书》和《产品需求规格书》，努力降低项目中后期因需求变更对项目的成本、质量和进度的影响。而项目经理则需通过加强需求管理，有效的防范和减少不必要的需求变更。曾有人做过统计分析，如果在需求分析阶段发生的需求变更对项目带来的额外工作量是5的话，那么在系统分析和系统编码阶段发生的需求变更对工作量的增加分别是20和100。
对于那些软件能力成熟度高的软件企业的项目经理而言，可以毫不夸张的说：只要把需求管理做好了，项目也就已经成功了一半。
CMMI中对需求管理流程的定义与我项目实践的体会
集成式能力成熟度模型(CMMI：Capability Maturity Model Integration)把需求管理流程划分为六部分，分别是：1、制定需求管理计划;2、求得对需求的理解;3、求得对需求的承诺;4、管理需求变更;5、维护对需求的双向跟踪;6、识别项目工作与需求之间的不一致性。
毋容置疑，上述六个部分是构成需求管理流程的重要组成部分。但在实际操作中，仅仅是机械的遵循这些标准流程和要点，往往又是不够的。根据我在过去十年在国内的多个大型软件项目(涉及仓储管理、物流园区信息平台、保税区海关联网监管系统，以及港口社区综合信息平台等)担任项目经理的管理实践，我的看法就是：要想成功的执行需求管理，涉及到的一些关键成功因素还远不止这些。以下就是我的一些经验和体会。
我的两点经验
一、应紧密结合国内企业的实际特点和人文环境，通过多种手段消除“需求的不确定性”
开发企业级大型应用软件项目，需要应对的重要挑战就是“需求的不确定性”。那么，什么是“需求的不确定性”呢?我这里先例举两个场景。场景一：开发人员没有行业背景，不能很好的理解业务需求。某个开发项目，尽管经过了多轮次、十分详尽和深入的需求研讨，而且开发人员都确信自己已经明白了客户提出的业务需求，但费尽千辛万苦把系统做出来以后，客户却说：“对不起，这并不是我想要的!”于是几百万，甚至上千万的开发投入打了水漂;场景二：开发人员具备丰富的行业经验，也确实理解了业务需求，但开发项目组因为没有很好的平衡各方利益关系，软件系统在上线后要么遭到全盘废弃，要么就只有那么一小部分功能得到实际应用。客户的大部分项目投资没能获得应有的收益。
从以上描述的两个场景可以看出：造成需求不确定的原因很多。它们包括但不限于：1、开发团队缺乏所开发项目的业务背景和行业经验，导致不能很好的理解客户的业务需求;2、由于客户方人员的素质良莠不齐，以至于有些人员不能完整、全面、系统、准确的阐述自身业务和对系统的需求，或者提出的需求难以通过IT技术加以实现，有些时候有些人甚至会从大方向上误导开发团队;3、客户方不熟悉软件项目开发方使用的工具、不理解项目需求