目前,在周围的项目开发中出现了这样的现象:用户基本上已经对需求进行了初步确认,但是由于一些原因不能立即(需要一些时间)或者完全进行确认(需求没有确认).此时项目组为了不影响进度已经开始了需求阶段之后的后继工作(此时需求基线是没有发布的).因为需求基线没有发布,此后的设计基线以及测试基线都不能发布,直至项目结尾时用户才有可能完全的对需求进行确认.但那时项目即将结束,在那时发布需求基线的意义就不大了.
  而且,在此期间(没有发布需求基线---项目临近收尾),项目的进展状况是由PM来控制的,QA人员很难在对项目进行控制,监督工作进行的也很吃力，有没有什么办法能让用户的需求确认不影响开发流程而且QA人员也能很好地对项目进行控制了？大家有什么好办法吗或者同样也遇到过这样的现象,最终是怎么解决的呢？

大家谈谈自已的意见和想法,如上面所述,怎样才能管理好用户需求呢?

首先要让你的客户明白，做好需求是双方的负责。当然在现实中，很多问题都是客户直接提出，而确认只有到他看到实际的东西出来之后才下判断。
对于这种需求不明确的情况，可采取增量的开发模式，这就要求对项目要有很强的管理控制能力。
至于需求的基线可包括所有明确的需求，对于不明确的需求依次区分，在下一个版本中进行体现。

定义需求的优先级，一个阶段内只实现当前优先级最高的feature；
每周推出一个用户可以使用的新版本，使用户能够方便的提出其真正想要的需求；
建议看一本书《敏捷与秩序》，其讲到的rup的最佳实践会非常有助于你们的项目。

迭代；或者用快速原型法让客户确认需求

客户在项目初期, 不可能就对此项目的整体需求进行确认, 他们的思想总徘徊在模糊状态, 这时, 我个人同意楼上的看法, 采用原形法, 快速实现项目整体的棱阔, 让客户模糊的思想逐渐变得清晰, 然后对清淅的部分, 进行逐步精化, 确认, 实现.........欢迎指正!

用户特别是政府机关用户完全没有耐心和你做需求

也许是有些需求用户自身也不是很清晰，我们的做法是先基于确定部分开始编码，测试及提供给用户可运行版本．用户在试用了该版本后，也许会提出需求变更，之前未确认的需求也许会取消．虽然这种方法不是最好的，至少仅供参考．

用迭代的全生命周期或原型法

大家说的都是很不错的好办法,但对于我们出现这种情况的项目的客户几乎都是政府部门,强势得很.就像tigergun所说的,他们不会和你进行需求确认,拿去原型给他们看,往往也没有什么提出来的建议,反而是在开发过程中随便提出这样或那样的要求.变更变得频繁和无法控制.这样在很大程度上浪费时间,人力资源,成本.对待这样用户还有什么好办法吗?