需求获取过程中的逆向沟通
需求分析是构建软件系统的一个重要过程。一般，把需求类型分成三个类型:
1、业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。
2、用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
3、功能需求(functionalrequirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。
二、需求的质量分解
一般情况下，采用如下的手段描述软件需求的质量：
正确性：所有需求必须是正确的、合理的、满足任务书要求的。
必要性：所有需求必须是为完成指定任务所必需的。
可行性：在指定的环境和条件下，所有的需求必须是可行的。
完备性：为完成指定任务，这些需求是完备的、无遗漏的。
一致性：所有需求相互之间没有矛盾，是一致的。
非退化：任一需求的引入都不会导致软件性能的退化。
无歧义：任一需求的陈述都是确定的、不会导致多义性的。
可验证：任一需求都是可以测试、可以验证的。
可追踪：人以需求都可以追踪到项目的任务书或规格说明的需求。
三、需求的隐含质量要求
除了这些可以量化的质量标准，还有一些需求的标准是隐含的。这些要求及时客户没有提出来，在实现的时候也应该考虑到，否则，可能导致项目的失败。
操作方便：每一个客户都会有操作方面的要求，只是具体的表现方式不一样。一般，客户在开始的时候对操作很难对操作有很具体的考虑，他会想当然个认为新的软件系统会和他以前所熟悉的某一个系统类似。而事实并非如此。当他发现新的软件系统不方便使用的时候，就会提出修改的建议。有的时候，这种修改对软件系统的影响是灾难性的。
可以保证操作质量：一般，系统分析员会认为客户应该勾画出系统运行过程中可能发现的重要风险，然后在系统实现的时候予以考虑。然而，在沟通的过程中，客户认为的重要的风险会和系统分析员所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因为对于客户而言，这些内容应该是显而易见的；而系统分析员一把并不了解这些事实。例如，在一个管理保险公司客户的系统里面，修改职业是需要严格审核的，如果系统分析员以前接触的业务以电子商务居多，他可能自然而然的认为客户修改职业仅仅是一个一般性的变更。