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

这篇博文的标题是一个疑问句。在回答这个问题之前，首先应该想到的是：提出这个问题，实际上已经先认定了需求管理工具是必要的。那么，需求管理工具是否真的必要呢？

　　这里的“需求”不是个抽象概念，它指的是需求分析文档、需求规格说明文档这样的需求分析成果；需求管理就是对这些成果（包括中间成果）的管理。从这个角度来看，需求管理工具是必要的，至少在绝大多数情况下是这样。根据经验，我至少能够列出以下两个理由：

　　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、通常的操作有：编辑、添加下级分支节点、添加叶子节点、改变上级节点（从而可以改变节点之间的逻辑关系）；

　　2、如果已经是叶子节点，则不能再添加下级。

　　三、能够把所有叶子节点导出为feature文件，这些feature文件可以直接在测试代码中使用。

　　1、每个叶子节点是一个单独的feature文件；

　　2、feature文件分目录存放，目录结构与树形图的分层结构一致。

　　四、能够把所有节点导出为一个文本文件，文本文件的章节结构与树形图的分层结构一致。

最新内容请见作者的GitHub页：http://qaseven.github.io/