我们需要什么样的需求管理工具?

这篇博文的标题是一个疑问句。在回答这个问题之前,首先应该想到的是:提出这个问题,实际上已经先认定了需求管理工具是必要的。那么,需求管理工具是否真的必要呢?
  这里的“需求”不是个抽象概念,它指的是需求分析文档、需求规格说明文档这样的需求分析成果;需求管理就是对这些成果(包括中间成果)的管理。从这个角度来看,需求管理工具是必要的,至少在绝大多数情况下是这样。根据经验,我至少能够列出以下两个理由:
  1、在绝大多数情况下,需求是复杂的。
  2、在绝大多数情况下,需求是变化的。
  需求分析过程往往是这样的:从用户关于系统的一些模糊的、顶层的概念和想法出发,不断地进行明确和分解,形成数量众多的需求条目,直到最终成为可以指导开发的用例。随着这一过程的进行,当程序员因为需求越来越清晰而备受鼓舞时,不幸的项目经理却很可能陷入苦恼中:这么多条需求,谁知道是否有遗漏呢?谁知道这些条目之间是否有很紧密的关联呢?如果需求条目比较少,或许项目经理还能够在脑子里把这些问题理清楚;但是如果条目很多,谁又能保证不出错呢?
  需求的变化有多种来源:有可能用户的想法发生了改变;有可能用户的想法并没有变,但一开始他没有说清楚,或者我们的理解有误;实际上,需求分解本身就意味着我们对需求的认识在不断地深入和细化。
  所以我们可以借助工具管理好需求,以结构化的形式(例如树形图、表格等)来组织需求条目,让项目经理能够比较方便地查看、追踪、回溯需求分解,理解需求条目之间的关系。
  所以我们可以借助工具管理好需求,不但要能够很方便地进行“增删查改”,最好还能像代码版本控制那样,对需求分析的成果也能进行版本控制。
  事实上,在行为驱动开发(Behavior Driven Development, BDD)或者验收测试驱动开发(Acceptance Test Driven Development, ATDD)中,需求与验收测试代码最终合二为一,即所谓specification by example。所以对需求进行管理,就像对代码进行管理一样,是非常自然的事情。
  那么,什么样的需求应该被工具管理起来呢?
  我们可以把需求分为三类:
  1、功能需求:即系统应当提供哪些功能,例如“支持在用户登录时进行用户身份认证”;
  2、性能需求:即性能方面的指标,例如“当用户登录请求并发数不大于200时,身份认证处理时延不大于3秒”;
  3、特性:对某项功能实现的方式、界面、操作步骤、外观、接口等进行规定的需求,例如“服务器与客户端之间的消息传输采用HTTP协议”。
  性能需求会对系统技术路线的选择、架构设计等产生直接的影响,但是通常不易被分解为更细的条目;特性往往会体现在某项功能的实现方式或呈现形式上,通常我们都是把功能需求进行分解,并且在分解时注意把相应的特性包括进去。因此,实际上需求管理工具首先应该管理的是功能需求。
  所以,为了较好地支持BDD或者ATDD,我觉得需求管理工具至少应该具有以下功能:
  一、能够以树形图或表格的方式浏览所有需求条目。以下以树形图为例进行说明:
  1、树形图具有唯一的根节点,就是“系统功能需求”,根节点以下可以有任意多层分支节点;
  2、每个节点是一个需求条目,具有编号、名称、说明3项内容;
  3、采用多级编号,编号能够体现需求条目之间的逻辑关系;
  4、如果系统包括多个子系统(例如多个软件),那么第1层分支节点是系统功能,从第2层分支节点开始是子系统功能,即第1层分支节点只把系统功能需求进行分解,不按子系统分解;从第2层分支节点开始,按子系统进行分解,第2层分支节点应注明是“客户端xxx功能”还是“服务器xxx功能”;
  5、最末端的分支节点(即叶子节点)采用BDD验收测试代码的feature文件的形式(例如cucumber的feature文件);
  6、每个节点可以展开(显示子节点)和收拢(不显示子节点)。
树形图如下图所示:
系统功能需求--+--1.用户登录--+--CLIT.1.1客户端登录界面
+              +
+              +--SERV.1.1服务器身份认证
+              +
+              +--SERV.1.2服务器维护用户登录会话状态
+
+--2.XXXX--+--CLIT.2.1XXXX--+--CLIT2.1.1XXXX
+          +                +
+          +--CLIT.2.2XXXX  +--CLIT2.1.2XXXX
+          +
+          +--SERV.2.1XXXX
+          +
+          +--SERV.2.2XXXX--+--SERV2.2.1XXXX--+--SERV2.2.1.1XXXX
+                           +                 +
+                           +--SERV2.2.2XXXX  +--SERV2.2.1.2XXXX
+                           +
+                           +--SERV2.2.3XXXX
+--3.XXXX
  二、对每个节点可以进行以下操作:
  1、通常的操作有:编辑、添加下级分支节点、添加叶子节点、改变上级节点(从而可以改变节点之间的逻辑关系);
  2、如果已经是叶子节点,则不能再添加下级。
  三、能够把所有叶子节点导出为feature文件,这些feature文件可以直接在测试代码中使用。
  1、每个叶子节点是一个单独的feature文件;
  2、feature文件分目录存放,目录结构与树形图的分层结构一致。
  四、能够把所有节点导出为一个文本文件,文本文件的章节结构与树形图的分层结构一致。

最新内容请见作者的GitHub页:http://qaseven.github.io/ 
上一篇:SQL Server 复制订阅


下一篇:SQL Server 2008 标准版不支持Reporting Services的数据驱动订阅