软件项目的需求过滤

作者：武汉开目信息技术有限责任公司 严晓光

欢迎访问e展厅 展厅 3 管理咨询与服务展厅 企业文化, 战略管理, 生产管理/工业工程, 营销管理, 知识管理, ... 如果项目策划时将必须实现的基本需求项安排得太多，当发生重大风险时几乎必然会导致项目延期。 1. 需求过滤的一般概念 需求过滤对应的英语词汇是“Requirement Triage”，“Triage”的基本含义是“分类、拣选”，与需求联系在一起时译为“过滤”；“需求过滤”的基本含义则是对各种来源、形形色色的需求项进行分级。 对一个软件项目而言，策划时收集到的需求可以大致分为3级，第1级为项目必需完成的基本需求；第2级为当项目进展顺利时可以纳入项目边界，若项目发生重大风险时允许剔出项目边界的备选需求；第3级则是在当前软件项目中不予考虑的需求。 2. 软件项目需要需求过滤 软件项目通过初步的需求获取可能从各种来源得到许多需求项，典型的来源包括顾客提出的新需求或反馈的修订以前版本缺陷的需求，软件组织的规划部门基于市场开发、产品发展提出的新需求，以及组织内各岗位员工提出的改进建议类新需求等。 并非所有收集到的原始需求项都需要在下一个版本中满足，最根本的原因在于软件组织通常没有资源和能力在一个版本中实现太多的需求项，需要进行过滤以剔出部分原始需求。需要过滤的另一个重要原因是在软件项目执行过程中存在太多的风险，例如人力资源异动、需求重大变更、关键技术需要更大的研究工作量、相关方的协同工作未能及时到位等。风险是否发生是概率事件，如果项目策划时将必须实现的基本需求项安排得太多，当发生重大风险时几乎必然会导致项目延期；如果要实现的需求项安排得太少，则当风险不发生或少发生时项目组的工作量可能不够饱满。因此，在项目策划时主动安排备选需求项是保证按时完成项目基本目标的重要策略之一。 如果简单地询问顾客、销售经理或实施经理哪些需求项最重要，得到的反馈往往会是每个人提出的需求项都重要。也许所有的原始需求项真的都重要，但是资源有限，必须采用适当的、可操作的需求过滤方法对原始需求项划分等级。 3. 软件项目需求过滤的预备工作 实用中将所有的原始需求项都拿出来进行正式的需求过滤往往会浪费资源，要先做一些预备工作。预备工作可以由产品规划经理完成，典型的需求过滤预备工作包括： 3.1 原始需求初步过滤 对收集到的原始需求项进行“出口评审”，对那些下在一个版本中明显必须完成的基本需求或不可能实现的需求作出必须完成或不予考虑的属性标识，其他原始需求项将成为需求过滤的主要对象。 3.2 重新组织原始需求项 初步的原始需求项中往往会有类似的需求，有些需求项会具有对其它需求项的依赖关系，因此有必要适当重组原始需求项，合并类似的需求，标识出依赖关系。 3.3 初步估算需求项的工作量 对准备纳入需求过滤的原始需求项，以及标识为必须完成的需求项，进行初步的工作量估算，给出工作量属性标识。在此过程中需要将原始需求项初步拆分为功能点，大致估算需求项的复杂程度、实现需求项所需的工作产品规模，然后估算出工作量。 4. 软件项目需求过滤的基本方法 软件项目需求过滤的基本方法是召集所有主要的顾客、营销、实施、产品规划等方面的代表，按照一定的规则投票决定需求的级别。常用的投票规则包括： 4.1 赞成或反对状态投票法 例如，可以采取－2，－1，0，1，2等五种状态的表决。－2表示强烈反对、不考虑该需求项，－1表示反对，0表示不关心，1表示同意，2表示强烈同意。所有的代表对全部需求项逐项投票。 对得分很高或很低的需求项容易决定取舍，但对得分居中的需求项需要分析。同样为0分，可能有0×n＝0，或(－2×n/2)＋(2×n/2)。前者的含义是大家都不关心此需求项，将该需求项纳入项目边界没有什么价值；后者说明可能需要两个系统、两个版本。 4.2 限额投票法 当出于市场要求确定了项目最后期限，由于资源所限必须将相当多的需求项剔出项目边界时，限额投票是相当有效的实用方法。设有100个需求项，由于资源限制只能在项目边界中纳入50个基本需求项和20个备选需求项，则可以对参与需求过滤的人员每人给50个1级需求建议币，20个2级需求建议币，请参与人员以1个需求建议币为单位去购买这些需求。 限额投票法可以演变出一些变型方法，例如允许以多个需求建议币去购买同一个需求项，不区分1级需求建议币和2级需求建议币，对VIP代表给予比一般代表更多的需求建议币限额等。 对使用限额投票法得到的结果也需要分析，例如当允许以多个需求建议币去购买同一个需求项时，有可能某一个人对某一个需求项投入了大量需求建议币。结果这个需求项看起来得到的钱很多，但这些钱主要来自同一个人。 5. 结束语 软件项目需求过滤本身是非常重要、复杂的活动，运用需求过滤基本方法得到的结论一方面不一定就是最终结论，另一方面又是确定项目边界的重要依据。 如果有代表强烈要求纳入个别过滤掉的需求或反对纳入某项需求，就需要认真考虑，不能僵化、简单地“少数服从多数”。 需求过滤归根结底要以顾客为中心，过滤不是简单地从原始需求、从“愿望(desire)”中滤掉一些看起来不必要、不实用的东西。是否必要要由顾客说了算。软件设计、开发中的常见误区之一是不考虑顾客的工作习惯、不能从顾客的角度去考虑功能实现的方式，最终确定项目边界时需要认真考虑顾客的愿望。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (5/17/2005)