界定需求范围.docVIP

界定需求范围 界定需求范围这个事，很多时候确实非常令人头痛。客户提出某些需求时，你做吧，就可能会牵扯出另外一些更多的需求，而且有些需求会对已经设计好的结构产生伤筋动骨的影响；你不做吧，客户又显得很不高兴，一副回头验收时有你好看的样子，又特别让人担心。 特别是当客户提出某些新需求的时候，软件系统的编码都已经进行到一多半了。这时如果有新需求被提出，将打乱之前所有的规划。勉强纳入到软件系统中，可能使整个工程的开发量、时间都大大增加。 如何解决这种困局?这仍然需要回到需求主线上来。从需求主线的角度，对需求，可以进行完全分类，分为以下三种类别： 1)第一类是为了满足需求主线，所必需的功能模块，并且在需求调研过程中，已经纳入视线，并经过整理和分析的需求；这是我们所喜闻乐见的。 2)第二类是与需求主线关联不大，但在实际调研中，被纳入了需求范围。 项目中，这一类需求可以定义为超范围需求，应在后续整理分析中，尽可能去掉。它不仅大量吞噬公司的运营成本，而且可能会给客户带来许多麻烦，是导致项目失败一个潜在危险因素。要知道并不是软件系统的功能越多越好，功能越多，意味着软件系统的使用成本就可能越高。 使用成本是一个新概念，这里需要解释一下。所谓使用成本，就是客户在使用软件系统的时候，需要的人力、精力、培训或者相关配套措施的成本的总合。 举个例子，假设有个客户需要建立一个销售管理系统，那么就可以有两种方式，一种是客户每天下班时只需填写一个当日销售数量到系统之中，另一种是客户每笔销售都要实时记录，类似于超市的POS系统。 虽然从理论上来说，后一种方式更精确。但实际使用时，就需要考虑到挂单、退货、取消其中一种商品，并且需要实时打开电脑输入销售品种和数量，培训也更为复杂。那么显然客户的使用成本要更高。 3)第三类是与需求主线关联密切，如果没有这些功能模块，就会使得系统不可运行或残缺，而实际调研中，却没有被纳入需求范围。 这类需求是必须要纳入到系统中，而且要尽可能早的发现，并纳入到需求之中。如果没有这些需求的支撑，项目成功机率很小。原因很简单，后面客户在试用或使用过程中，必然会要求加入。那时候再改动代价惊人。 很多时候，我们抱怨客户总是在增加需求，其实并不一定就是客户想少花钱多办事，而是我们没有在需求调研期间，没有把这第三类需求纳入到我们的需求范围。毕竟对于客户而言，软件系统满足他的核心诉求才是头等大事。 项目中，完全做到排除第二类需求，纳入第三类需求，很不容易。但是要做到大部分的第二类需求被排除，大部分第三类需求被纳入，却也不是太难的事情。做到这一点，有一个前提条件：确认项目整体轮廓已经清晰，需求主线已经无遗漏。这也就是为何一再强调需求主线的重要性的原因。 在这个前提条件被确认的情况下，逐级逐条的检查各个分支需求。 发现第二类需求的做法是：如果发现在某个分支需求，与需求主线的关系并不密切，那么这个分支需求就标记为第二类需求。这意味着这个需求可以被排除在范围之外。当然，排除之前，要与客户沟通，获得客户的确认。这个过程中，你会发现有许多需求原来并不需要实现。 而发现第三类需求相对困难一些，通常的做法是检查本级需求和下级需求之间的逻辑。首先将本级需求所有的要求，都标记为无法得到下级需求支持的，未满足需求。然后再去检查下级需求中，是否能够满足到这些要求。如果不能被满足，就意味着需求逻辑出现了断层，那么需求分析人员就要针对这些断层，再次调研，直到这些逻辑通畅为止。 从发现第二类、第三类需求的方法之中，可以清晰地看到以下几点： 1)为什么需求主线如此重要，没有整理出需求主线的项目，成功率为什么很低，开发和实施成本为什么很高； 2)把需求分出层级，在整个调研中的重要性。需求分析，永远都是从上到下，从主干到细节的。这就解释了为什么不能一上来就收集日常工作中的表单，询问工作流程； 3)将需求分析说明书，分为不同的文件的好处。分为不同的文件，就可以快速查找到相关的内容，便于对需求进行标记和修改。