我们都知道在软件开发过程中需求变更往往是不可避免的。通常是软件开发主管花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着软件开发工程师不应该做这方面的工作，软件开发工程师对于需求变更的正确态度应该和软件测试的态度一样，在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。软件开发工程师切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。

相比于需求软件开发工程师而言，软件需求用户可能对需求变更了解不足，认为他们出钱，软件开发人员或软件开发公司就要为它服务，因此软件需求用户对需求变更往往更加肆无忌弹，将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由软件需求用户和项目开发者共同承担。通过这样做，让软件需求用户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到软件开发人员开始编码了，才提出以前原本在需求分析时就可以提出的需求。

让软件需求用户明白减少需求变更的严重性后，需求分析人员应该采取合适的方法同软件需求用户交流，帮助他们明确他们的需求。需求分析人员和软件需求用户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和软件需求用户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合软件需求用户需求的软件，因此需求分析人员除了记录软件需求用户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助软件需求用户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请软件开发工程师和软件需求用户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由软件需求用户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，软件开发工程师采用原型的方法启发软件需求用户思考功能需求也不失为一个好办法。

虽然需求不可能是完备的、变更不可能没有的，但是在项目开始设计时使得需求尽可能完备还是应该的，也是值得的，完备需求的过程也就相应的减少了因为需求不清楚而产生变更的几率。