如何对待软件需求？
平时，我们最常见到的有关需求的话题是：如何调研需求，以及如何管理需求。我今天遇到了一件事，我以“对待需求”为题发起这个讨论：
面对用户提出的各种需求，我们应该持以何种心态来对待用户的需求？今天，有个项目经理告诉我：用户的需求是会变的，我们不需要非常细致的把控它，很多业务是模糊的，用户都说不清，我们不一定非得搞得那么清楚。而我的部门主管也比较赞同这种说法。但是，我并不同意这种看法。我仅仅说明我个人的观点：需求本身是客观存在的，它到底有多细致，某种程度上取决于我们调研和理解的深度。做好一款软件，对需求越是深入的了解，越能发现需求背后的业务含义。明确的和细致的需求理解有助于我们设计系统的时候能有良好且灵活的把控。那个项目经理还告诉我：用户自己有时候都说不清自己需要什么。我想问：这难道成了我们不需要详细了解需求的理由了吗？恰恰是因为用户不能明确表达自己的需求，我们这些软件人员才有责任去协助和引导用户发现自己的需求。另外，有时候，用户说怎么做我们就怎么考虑的想法也是不对的。用户有时表达的需求其实是他们想要的东西，这就像是用户直接给我们一个解决方案了，其实，用户真正遇到了什么问题，他真实的需求是什么，这才是我们做需求发掘的目的所在。那为什么要发掘需求呢？也是为了更为细致地了深刻地理解需求。而这一切，应该讲都是为了更好地开发一款能为用户带来价值的软件。
上面，是我初步的想法，我很希望和大家一起理性、客观地看待和深入地讨论这个问题。在我工作的这几年中，我越来越发现“对待需求”的心态就决定了这个系统的成败！
[解决办法]
1.作为一个技术人员,难得楼主有这样的认识;
2.让开发人员做调研不是个好主意;
3.尽量避免正面调研,调研者到处走走看看,然后跟他们轻松地、随性的谈谈管理、谈谈业务，然后你能“揣摩”出他们想要什么；
4.在业务领域而不是数据上明确需求边界，比如你要确定：是不是要解决采购计划流程，而不是确定有哪些字段，如果实现确定没有采购计划，而后来加入了，那就要增加费用；如果是处理流程的变更或者字段变更，那么这属于应用程序的设置功能；
5.对于存在竞争对手的领域，尽量发掘出别人没有发现的需求
[解决办法]
我们面对的客户是多样性的，根据具体客户要采取不同的调研方法，楼主的思想是准确的。既要实现客户的业务需求，又要把握系统的实现难度。
[解决办法]
快速原型、快速迭代；让产品经理成为领域专家。
[解决办法]
赞同楼主的观点。
的确很多客户都不清楚自己到底想要什么，挖掘出客户真正的需求不仅会减少需求变动的可能，更加能获得客户充分的信任，从而根据我们的需要去影响客户的想法
[解决办法]
