如果需求无法和客户确认，或者开发了原型，客户也没有提出什么建议或更改。
可以考虑这样做，基于原型制定需求基线，再和客户约定一个需求封闭时间，在封闭时间之后提出的需求都作为需求变更来处理。

那就公司高层出面, 和政府机关领导把关系勾兑好, 饭桌子上吃好喝好什么都好谈了, 那个时候用调侃点的口气给他们说说如果需求不定那公司做到最后就只有亏本, 想来这样会便于沟通些, 建议可以这样试试

这是软件开发公司的大难题，用户需求无法即时确认，开发公司也只能提醒和催客户，然后自己再慢慢往这方面靠罗。

出现这种情况首先要考虑你们的沟通是不是有问题。最好先要由公司高层把关系打好。政府高层发活之后，下面的人会好说话多了。不行的话，多请对面中层人员吃吃，玩一玩。

       你们具体做需求的时候，最好拿一下样例或原形让对方了解整体框架。然后确定关键流程，最好做好的流程图，请对方一一确认。根据上面的交流结果来写需求文档。完成之后，请对方签字确认。你们的所有开发都以这个别需求说明书来完成。对方如果任意变更需要，让对方填写变更确认书，由对方签字确认。把需求分为几级进行管理，主要需求变更，需要主管领导签字确认。明确要求增加项目金额或开发周期。小的需要变更，也要签字确认，做为管理依据。每隔一段时间向客户汇报项目进度。一般的工作人员，一旦知道自己的提的需求需要签字确认的时候，下回不会乱提需求的。

我是学生...先了解下...

個人想法最好在合約要有定義確認的方式,還有在某些情況下就算確認完畢。例如提交需求確認書，十四天內無提出異議就算同意。

把握用户的核心思想，针对最重要最紧急的需求先进行定制，以DEMO化的方式展示开发思路，保证所开发的东西和客户所要求的没有太大的偏差。

这类事情很多，不太容易得到干脆利落的解决。

迭代等方法都很好，另外，项目经理可以再去深入了解一下用户方的目标和开发方（自己所在公司）的目标到底是什么。有时候仅仅关注软件系统本身的功能和性能是不够的，要看软件系统在用户的整体业务中和自己公司的整体业务中承担的角色和可能达到的程度。

对双方的目标有底了，再决定开发工作时就有了心理准备。