需求获取过程中的逆向沟通

来源：长理培训发布时间：2017-12-26 19:49:05

一、需求的分类

　　需求分析是构建软件系统的一个重要过程。一般，把需求类型分成三个类型:

　　1、业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目的要求，它们在项目视图与范围文档中予以说明。

　　2、用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。

　　3、功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

　　业务需求和用户需求是软件需求分析的基础，也是软件构建的前提。系统分析员通过对业务需求和用户需求的分解，将其转换成克一形式化描述的软件功能需求。开发软件系统最为困难的部分，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。

　　二、需求的质量分解

　　一般情况下，采用如下的手段描述软件需求的质量：

　　正确性：所有需求必须是正确的、合理的、满足任务书要求的。

　　必要性：所有需求必须是为完成指定任务所必需的。

　　可行性：在指定的环境和条件下，所有的需求必须是可行的。

　　完备性：为完成指定任务，这些需求是完备的、无遗漏的。

　　一致性：所有需求相互之间没有矛盾，是一致的。

　　非退化：任一需求的引入都不会导致软件性能的退化。

　　无歧义：任一需求的陈述都是确定的、不会导致多义性的。

　　可验证：任一需求都是可以测试、可以验证的。

　　可追踪：人以需求都可以追踪到项目的任务书或规格说明的需求。

　　三、需求的隐含质量要求

　　除了这些可以量化的质量标准，还有一些需求的标准是隐含的。这些要求及时客户没有提出来，在实现的时候也应该考虑到，否则，可能导致项目的失败。

　　操作方便：每一个客户都会有操作方面的要求，只是具体的表现方式不一样。一般，客户在开始的时候对操作很难对操作有很具体的考虑，他会想当然个认为新的软件系统会和他以前所熟悉的某一个系统类似。而事实并非如此。当他发现新的软件系统不方便使用的时候，就会提出修改的建议。有的时候，这种修改对软件系统的影响是灾难性的。

　　可以保证操作质量：一般，系统分析员会认为客户应该勾画出系统运行过程中可能发现的重要风险，然后在系统实现的时候予以考虑。然而，在沟通的过程中，客户认为的重要的风险会和系统分析员所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因为对于客户而言，这些内容应该是显而易见的；而系统分析员一把并不了解这些事实。例如，在一个管理保险公司客户的系统里面，修改职业是需要严格审核的，如果系统分析员以前接触的业务以电子商务居多，他可能自然而然的认为客户修改职业仅仅是一个一般性的变更。

　　四、客户对需求的影响

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

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

　　2、客户有不同的个性。

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

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

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

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

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

　　听证：主要是指通过正式或者非正式的渠道召开有关人员的会议，听求大家对新的软件系统的要求和意见。

　　评审：组织有关的专家对软件需求进行评价，指出目前的需求由那些不合理的地方，以及修改的意见等。评审一般发生在初步的软件需求已经形成以后。

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