需求分析是构建软件系统的一个重要过程。一般，把需求类型分成三个类型:  
　　1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。 
　　2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。 
　　3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 
　　业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。 
　　二、需求的质量分解 
　　一般情况下，采用如下的手段描述软件需求的质量： 
　　正确性：所有需求必须是正确的、合理的、满足任务书要求的。 
　　必要性：所有需求必须是为完成指定任务所必需的。 
　　可行性：在指定的环境和条件下，所有的需求必须是可行的。 
　　完备性：为完成指定任务，这些需求是完备的、无遗漏的。 
　　一致性：所有需求相互之间没有矛盾，是一致的。 
　　非退化：任一需求的引入都不会导致软件性能的退化。 
　　无歧义：任一需求的陈述都是确定的、不会导致多义性的。 
　　可验证：任一需求都是可以测试、可以验证的。 
　　可追踪：人以需求都可以追踪到项目的任务书或规格说明的需求。 
　　三、需求的隐含质量要求 
　　除了这些可以量化的质量标准，还有一些需求的标准是隐含的。这些要求及时客户没有提出来，在实现的时候也应该考虑到，否则，可能导致项目的失败。 
　　 操作方便：每一个客户都会有操作方面的要求，只是具体的表现方式不一样。一般，客户在开始的时候对操作很难对操作有很具体的考虑，他会想当然个认为新的软件系统会和他以前所熟悉的某一个系统类似。而事实并非如此。当他发现新的软件系统不方便使用的时候，就会提出修改的建议。有的时候，这种修改对软件系统的影响是灾难性的。 
　　可以保证操作质量：一般，系统分析员会认为客户应该勾画出系统运行过程中可能发现的重要风险，然后在系统实现的时候予以考虑。然而，在沟通的过程中，客户认为的重要的风险会和系统分析员所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因为对于客户而言，这些内容应该是显而易见的；而系统分析员一把并不了解这些事实。例如，在一个管理保险公司客户的系统里面，修改职业是需要严格审核的，如果系统分析员以前接触的业务以电子商务居多，他可能自然而然的认为客户修改职业仅仅是一个一般性的变更。 
　　四、客户对需求的影响 
　　目前很多系统分析员在进行需求分析的时候，把主要精力放在了解客户的业务流程，并试图将其用形式化的手段描述。而事实上，这样了解到的客户需求往往是不完整的，甚至具有很大的片面性。除了隐含需求的定义比较困难以外，客户本身也是影响需求质量的一个重要因素。 
　　1、客户有不同的需要。一些客户知道他们需要什么，而另外一些人知道他们不需要什么。一些客户希望进行详细讨论，而另外一些客户则满足于模糊的承诺。 
　　2、客户有不同的个性。 
　　3、客户和供应商之间有着不同的通信方式。一些人非常熟悉产品以及生产厂商，而另外一些人则可能素未谋面，仅仅通过信件往来和几个匆忙的电话与生产厂商沟通。 
　　4、客户也经常是矛盾的。事实上，很少有客户能够明确的知道怎样的一个系统对自己是最有益处的，他们往往在集中方案之间徘徊，于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。 
　　客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任，但是，当一个软件项目因为客户事先没有预料到的情况而导致失败的时候，即使客户不会追究开发方的责任，就软件项目本身而言，也已经是失败的。 
　　五、目前控制需求质量的手段 
　　目前，项目经理和系统分析员主要通过听证、评审、确认等手段控制软件需求的质量。 
　　听证：主要是指通过正式或者非正式的渠道召开有关人员的会议，听求大家对新的软件系统的要求和意见。 
　　评审：组织有关的专家对软件需求进行评价，指出目前的需求由那些不合理的地方，以及修改的意见等。评审一般发生在初步的软件需求已经形成以后。 
　　确认：开发方将整理过的需求分析说明书交给客户确认。如果客户认可该需求分析说明书，就形成正式的需求分析文档，并作为一个重要基线管理。 
　　这些需求控制手段可以提高软件需求的质量，但是仍然无法保证需求是可用的。因为： 
　　1、听证会的参与者并不一定代表使用者的真实意图。实践中经常遇到这样的情况。即使他是目标软件的最主要使用者，他也经常会遗忘一些他觉得是很基本的，而事实上对于软件系统是很重要的细节。 
　　2、参与评审的专家并不一定对软件的最终质量负责，因此，他可能把工作的重点放在发现需求中的问题，而不是确认需求是否可行。 
　　3、客户确认只代表客户对需求负责人，不代表客户承认需求的质量。如果因为需求的质量导致软将项目无法进展，客户只能承担经济上的责任，而项目小组并不能因此缓解软件项目陷入的尴尬。  
　　六、用逆向沟通改善需求的质量 
　　逆向沟通，就是在需求调研的过程中，除了了解客户的情况，同时，向客户提出一些建议，供客户参考。 
　　一般认为，客户在其所在的领域具有比较资深的经历，因此需要严格遵守客户的意见。事实上，客户虽然在其所在的领域内很资深，但是，他们的角度是单纯的业务流程，而不是从实现信息技术角度构件的业务流程。因此，系统分析员要充分的说明对于实现一个业务系统而言，现有的业务流程应该做如何的剪裁，以及需要注意哪些要点。 
　　虽然，逆向沟通不能完全保证需求的质量，有效的逆向沟通可以大大减少因为对业务流程的理解不一致而造成的需求质量的下降。 
　　七、逆向沟通的主要要点 
　　1、所提出的业务需求是否符合行业的规范。 
　　不同的行业对于业务流程有一定的规范，例如财务，审计，工程设计，都具有一定的行业规范，这些规范一方面是对行业行为的一种约束，同时，也是行业内经验的归纳和总结。例如，审计准则不但约束了审计过程中的不规范行为，同时也保护了注册会计师的利益。部分企业由于所处的状况的不同，没有完全遵守行业规范，这造成了需求变更的隐患。系统分析员在探讨业务流程的过程中，应该留一客户的业务流程是否符合行业规范，如果有不符合的地方，应该进行适当的引导。即使客户目前实施行业规范有难度，也应该注意其理由，以预测其业务流程变更的可能性。 
　　2、展望系统发展环境，留有适当的扩展接口。 
　　每个行业的发展趋势应该有一定的规律可遵循。企业本身的发展变化是引起需求变更的最主要因素，因此，提前预测行业的发展趋势对于软件预留一定的发展接口是很重要的。 
　　客户没有预料到行业的变化趋势，一方面，可能参与软件需求的客户代表并不是关注行业和企业发展趋势的人员；另一方面，客户关注需求的程度可能和系统实现人员不同，有些客户会很自然接受的变化，会对系统有很重大的影响，相反，一些客户认为很重大的变化，可能对系统的影响是很小的。 
　　3、探索适合于信息化的工作流程。 
　　客户有的时候会提出对信息系统的要求，但是，客户所提到的要求，是在他的理解中，信息系统应该具有的样子。系统分析员应该深入挖掘这些要求背后的隐含目标，以便设计最适合客户，也最有利于实现的系统框架。例如，为了控制员工的工作时间，客户可能要求在软件限时使用。可是，能够实现控制员工工作时间的手段有很多，而且，客户提到的并不一定是最适合、最有效的方式。 
　　4、合理使用批处理方式。 
　　对于一些规模不大的系统，集中处理（批处理）的方式是合适的。可是，如果系统的规模很大，涉及的交易很多，而且对交易的实时性要求很高，集中的批量处理不是一个很好的方法。是否使用批处理方式，要根据业务需求的类型，系统的容量，以及以后的发展趋势决定。 
　　5、留有操作痕迹 
　　一个数据的产生，应该有一定的来由，不应该有没有根源的数据。 
　　保留操作痕迹可能造成数据空间的急剧增加，但是，对于一些重要的数据，必须做到操作可以追溯。追溯的内容根据操作的重要程度有所不同，一般可能包括以下内容：操作人员，操作时间，操作以前的状况，操作以后的状况，操作所通过的模块，操作的机器信息。 
　　6、操作可以恢复 
　　对于错误的操作，可以恢复到操作以前的状况。恢复过程作为一个重要的操作，应该留有痕迹。也就是说，业务数据恢复到了操作以前的状况，但是系统必须纪录前一次操作和本次逆向操作的有关信息，以备核查。同时，逆操作应该比操作本身具有更高的授权级别和操作限制。 
　　7、重要流程有校验的功能 
　　所谓重要流程，指对下一步操作有重要影响的流程，或者无法回溯的流程。例如，发送客户对账单，对账单发到客户手里以前还可以重新打印已修复一些错误，但是，如果已经发给客户，即使可以修复，也会产生一定的不良影响。因此，在这些流程上应该进行比较细致的校验。校验可以采用自动校验，前提是有比较可靠的校验算法，否则，通过有经验的操作员进行校验是比较有效的方式。另外，一旦发现校验失败的案例，必须把这些案例作为重要的时间进行核查，以找到原因，纠正以前的校验算法。 
　　八、逆向沟通的实现条件 
　　1、熟悉业务流程的业务逻辑分析师