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

delia2010

delia2010 注：此贴系转载，原内容见：我们需要什么样的需求管理工具？

   在回答这个问题之前，首先应该想到的是：提出这个问题，实际上已经先认定了需求管理工具是必要的。那么，需求管理工具是否真的必要呢？
   这里的“需求”不是个抽象概念，它指的是需求分析文档、需求规格说明文档这样的需求分析成果；需求管理就是对这些成果（包括中间成果）的管理。从这个角度来看，需求管理工具是必要的，至少在绝大多数情况下是这样。根据经验，我至少能够列出以下两个理由：

   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文件分目录存放，目录结构与树形图的分层结构一致。

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

该贴已经同步到 delia2010的微博


上一篇：项目管理软技能模型
下一篇：1施工项目管理制度有哪些？建立时遵循的原则 2案例说明我国在建筑施工中推广合同管理的

牛哄哄

适用的工具，就是好工具啊。

foheydwo

众里寻他千百度，蓦然回首在这里！

Nifyfreef

很有见地的探讨，先收藏着~

泅人

看起来好像不错的样子

鎖骨上旳印迹

好帖是需要鼓励的~

亲爱的小孩

这么强,支持楼主，佩服

堕天翼

路过的帮顶

纯如小白

以我的经验来看，楼主的想法是可以执行的~

留不住的对白

不错 支持一个了

aiw-520

没人回帖。。。我来个吧！

狼少°

支持，赞一个

闲逛

顶不错 支持下