这篇博文的标题是一个疑问句。在回答这个问题之前，首先应该想到的是：提出这个问题，实际上已经先认定了需求管理工具是必要的。那么，需求管理工具是否真的必要呢？
　　这里的“需求”不是个抽象概念，它指的是需求分析文档、需求规格说明文档这样的需求分析成果；需求管理是对这些成果（包括中间成果）的管理。从这个角度来看，需求管理工具是必要的，至少在绝大多数情况下是这样。根据经验，我至少能够列出以下两个理由：
　　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、每个节点可以展开（显示子节点）和收拢（不显示子节点）。