四、客户对需求的影响

　　目前很多系统分析员在进行需求分析的时候，把主要精力放在了解客户的业务流程，并试图将其用形式化的手段描述。而事实上，这样了解到的客户需求往往是不完整的，甚至具有很大的片面性。除了隐含需求的定义比较困难以外，客户本身也是影响需求质量的一个重要因素。

　　1、客户有不同的需要。一些客户知道他们需要什么，而另外一些人知道他们不需要什么。一些客户希望进行详细讨论，而另外一些客户则满足于模糊的承诺。

　　2、客户有不同的个性。

　　3、客户和供应商之间有着不同的通信方式。一些人非常熟悉产品以及生产厂商，而另外一些人则可能素未谋面，仅仅通过信件往来和几个匆忙的电话与生产厂商沟通。

　　4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。

　　客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。

　　五、目前控制需求质量的手段

　　目前，项目经理和系统分析员主要通过听证、评审、确认等手段控制软件需求的质量。

　　 听证：主要是指通过正式或者非正式的渠道召开有关人员的会议，听求大家对新的软件系统的要求和意见。
评审：组织有关的专家对软件需求进行评价，指出目前的需求由那些不合理的地方，以及修改的意见等。评审一般发生在初步的软件需求已经形成以后。

　　确认：开发方将整理过的需求分析说明书交给客户确认。如果客户认可该需求分析说明书，就形成正式的需求分析文档，并作为一个重要基线管理。

　　这些需求控制手段可以提高软件需求的质量，但是仍然无法保证需求是可用的。因为：

　　 1、听证会的参与者并不一定代表使用者的真实意图。实践中经常遇到这样的情况。即使他是目标软件的最主要使用者，他也经常会遗忘一些他觉得是很基本的，而事实上对于软件系统是很重要的细节。

　　2、参与评审的专家并不一定对软件的最终质量负责，因此，他可能把工作的重点放在发现需求中的问题，而不是确认需求是否可行。

　　3、客户确认只代表客户对需求负责人，不代表客户承认需求的质量。如果因为需求的质量导致软将项目无法进展，客户只能承担经济上的责任，而项目小组并不能因此缓解软件项目陷入的尴尬。

　　六、用逆向沟通改善需求的质量

　　逆向沟通，就是在需求调研的过程中，除了了解客户的情况，同时，向客户提出一些建议，供客户参考。

　　一般认为，客户在其所在的领域具有比较资深的经历，因此需要严格遵守客户的意见。事实上，客户虽然在其所在的领域内很资深，但是，他们的角度是单纯的业务流程，而不是从实现信息技术角度构件的业务流程。因此，系统分析员要充分的说明对于实现一个业务系统而言，现有的业务流程应该做如何的剪裁，以及需要注意哪些要点。

　　虽然，逆向沟通不能完全保证需求的质量，有效的逆向沟通可以大大减少因为对业务流程的理解不一致而造成的需求质量的下降。