，他会想当然个认为新的软件系统会和他以前所熟悉的某一个系统类似。而事实并非如此。当他发现新的软件系统不方便使用的时候，就会提出修改的建议。有的时候，这种修改对软件系统的影响是灾难性的。
可以保证操作质量：一般，系统分析员会认为客户应该勾画出系统运行过程中可能发现的重要风险，然后在系统实现的时候予以考虑。然而，在沟通的过程中，客户认为的重要的风险会和系统分析员所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因为对于客户而言，这些内容应该是显而易见的；而系统分析员一把并不了解这些事实。例如，在一个管理保险公司客户的系统里面，修改职业是需要严格审核的，如果系统分析员以前接触的业务以电子商务居多，他可能自然而然的认为客户修改职业仅仅是一个一般性的变更。
五、目前控制需求质量的手段
目前，项目经理和系统分析员主要通过听证、评审、确认等手段控制软件需求的质量。
听证：主要是指通过正式或者非正式的渠道召开有关人员的会议，听求大家对新的软件系统的要求和意见。
评审：组织有关的专家对软件需求进行评价，指出目前的需求由那些不合理的地方，以及修改的意见等。评审一般发生在初步的软件需求已经形成以后。
确认：开发方将整理过的需求分析说明书交给客户确认。如果客户认可该需求分析说明书，就形成正式的需求分析文档，并作为一个重要基线管理。
这些需求控制手段可以提高软件需求的质量，但是仍然无法保证需求是可用的。因为：
1、听证会的参与者并不一定代表使用者的真实意图。实践中经常遇到这样的情况。即使他是目标软件的最主要使用者，他也经常会遗忘一些他觉得是很基本的，而事实上对于软件系统是很重要的细节。
2、参与评审的专家并不一定对软件的最终质量负责，因此，他可能把工作的重点放在发现需求中的问题，而不是确认需求是否可行。
3、客户确认只代表客户对需求负责人，不代表客户承认需求的质量。如果因为需求的质量导致软将项目无法进展，客户只能承担经济上的责任，而项目小组并不能因此缓解软件项目陷入的尴尬。
六、用逆向沟通改善需求的质量
逆向沟通，就是在需求调研的过程中，除了了解客户的情况，同时，向客户提出一些建议，供客户参考。
一般认为，客户在其所在的领域具有比较资深的经历，因此需要严格遵守客户的意见。事实上，客户虽然在其所在的领域内很资深，但是，他们的角度是单纯的业务流程，而不是从实现信息技术角度构件的业务流程。因此，系统分析员要充分的说明对于实现一个业务系统而言，现有的业务流程应该做如何的剪裁，以及需要注意哪些要点。
虽然，逆向沟通不能完全保证需求的质量，有效的逆向沟通可以大大减少因为对业务流程的理解不一致而造成的需求质量的下降。
七、逆向沟通的主要要点
1、所提出的业务需求是否符合行业的规范。
不同的行业对于业务流程有一定的规范，例如财务，审计，工程设计，都具有一定的行业规范，这些规范一方面是对行业行为的一种约束，同时，也是行业内经验的归纳和总结。例如，审计准则不但约束了审计过程中的不规范行为，同时也保护了注册会计师的利益。部分企业由于所处的状况的不同，没有完全遵守行业规范，这造成了需求变更的隐患。系统分析员在探讨业务流程的过程中，应该留一客户的业务流程是否符合行业规范，如果有不符合的地方，应该进行适当的引导。即使客户目前实施行业规范有难度，也应该注意其理由，以预测其业务流程变更的可能性。
2、展望系统发展环