[修订]关于需求管理的胡思乱想

先来张图

图解：

 

1.来源分支不解释了。

2.内容分支

为什么需要名称？便于记忆、引用

为什么需要描述？定义需求的细节

为什么需要关系？这样才能知道某个需求变更会对其他需求、任务、模块带来什么影响

为什么需要属性？提供了分类的视角，便于检索、筛选、统计具有共性的需求

为什么需要ID？地球人都知道

为什么需要状态？对需求从被提出到被满足的全生命周期进行过程控制。

3.管理分支

• 需求需要什么样的版本管理？

首先是记录版本变迁过程：who在when对需求的where(这个where应该包括名称、描述、关系、属性、id，状态可以不管，因为过程控制会处理状态)做了what，当然还有why。

其次是比较版本差异：比如一个GUI需求，版本1说要outlook风格，版本2改成了office风格，需求分析师需要查找和比较版本差异，以便提高分析质量

再次是利用版本控制相关的事件执行动作：比如一个A需求的内容变更事件发生了，需要自动通知A需求相关的评审者吗？或者更进一步，除了A需求的评审者，还要通知与A需求相关的B需求的评审者？

当然要是提供二次开发接口就更完美了。

• 需求需要什么样的过程控制？

首先是记录状态变迁过程：who在when对需求的状态做了what，当然还有why。过程控制的基础就是基于状态的管理

再次是利用过程控制相关的事件执行动作：比如一个A需求的状态改变事件发生了，需要自动通知A需求相关的评审者吗？或者更进一步，除了A需求的评审者，还要通知与A需求相关的B需求的评审者？

• 需求需要什么样的检索筛选？

首先是基于属性的筛选：基于属性的筛选是把需求看做一个列表，然后从列表中选取一段。这个属性可以是优先级、复杂度、重要性....，项目经理也许要用优先级来安排进度，架构师也许要用复杂度来评估风险，产品经理也许要用重要性来权衡任务性价比，。。。总之，属性提供了一种多视角的分类法，让需求的各种使用者可以从自己的视角聚焦感兴趣的需求。

其次是基于关系的筛选：基于关系的筛选是把需求看做一张用户自定义的网，然后从网中选取一个子网。这个属性可以是优先级、复杂度、重要性....，项目经理也许要用优先级来安排进度，架构师也许要用复杂度来评估风险，产品经理也许要用重要性来权衡任务性价比，。。。总之，属性提供了一种多视角的分类法，让需求的各种使用者可以从自己的视角聚焦感兴趣的需求。

基于版本的筛选以及基于状态的筛选：可以被看做是基于属性筛选的特例。

基于文字的筛选：基于文字的筛选把需求看做一张基于文字自组织的网，只要这些需求的名称、描述中包含同样的搜索词，他们之间就发生关系。

• 需求需要什么样的统计？

基于文字、基于属性、基于状态、基于依赖关系的统计都要，有什么样的检索筛选自然就有什么样的统计

• 需求需要什么样的追踪？

需求与项目任务之间、与项目人员之间、与代码模块之间、与测试结果之间、与其他需求之间都可能存在依赖关系，追踪时两个问题必须考虑：追踪的方向性、追踪的颗粒度。

追踪的方向性是说从谁向谁追。比如需求与任务，查询速度要求从10s提到5s了，与之相关的数据库设计任务需要修改吗？一般是的，最起码要新增一些测试任务。那么提出了新的任务去实现原来的需求呢？比如把数据库从sqlserver换成mysql，原来的查询速度要求要变吗？一般不是的。所以需求和任务之间从需求追向任务就够了。但需求和需求之间呢，一个需求变了，关联需求需要变吗？可能性很大，所以需求追向需求要双向的。

追踪的颗粒度是说追到何种程度。需求是分层次的，任务是分层次的，代码模块也是分层次的，人员也是分层次的。一个需求要关联到任务的哪个层次，代码的哪个层次，人员的哪个层次？一种解决办法是消除层次。比如bug管理时，bug修改需求通常是独立的，需求没有层次了，代码的每次提交也是独立的，需求与代码之间都没层次了，所以我们在bug管理中常看到bug号直接和代码版本号关联。但是非bug类的需求呢？恕我浅薄，还没看到满意的好办法。这也许是个仁者见仁智者见智的问题。

 

4.工具分支

这些工具能支持需求管理吗？

项目	子项	excel	脑图	需求管理系统
内容记录		总评：良 excel表里记录需求的内容没有问题，但“关系”不好处理，因为需求与其他对象(其他需求/设计文档/实现代码)之间是多对多关系，而列表记录多对多关系是很麻烦的（想象一下，每个一对一需要一行，如果发生变更，可能需要手动修改多行，买糕的，千万别让我来维护）	总评：中 以mindmanager为例，名称用topic，描述就是note，属性就是text marker，关系不好办，需求与其他文档的关联还能hyperlink，需求之间的关系怎么办？Topic之间连上relationship，再加个text marker标记？需求少还好办，多了脑图就变迷宫图了。	总评：优 各项内容记录都支持
版本控制		总评：中	总评：中	总评：优
	记录状态变迁过程	借助svn把记录需求的excel文件管起来，需求变更的历史可以轻松搞定，但颗粒度只能细到文档级。	同excel	内置，颗粒度到需求级
	利用过程控制相关的事件执行动作	自己编程吧，学学VBA，:)	这回要学脑图软件的API了，如果它有的话	内置标准动作如email，自定义动作可以二次开发
过程控制		总评：中	总评：中	总评：优
	记录状态变迁过程	在excel中添加过程控制字段如“当前状态、变更时间...”也能实现，状态变迁历史当然也只能求svn，管理的颗粒度也是文档级	给topic加属性，加标记,颗粒度同excel	内置，颗粒度到需求级
	利用过程控制相关的事件执行动作	自己编程吧，学学VBA，:)	这回要学脑图软件的API了，如果它有的话	内置标准动作如email，自定义动作可以二次开发
检索筛选		总评：良	总评：中	总评：优
	基于属性	ok	基本ok，看具体脑图软件是否支持	ok
	基于关系	困难	困难	ok，需求与代码的关联看与svn等版本控制的结合度
	基于状态	ok	基本ok，看具体脑图软件是否支持	ok
	基于版本	利用svn，颗粒度文档级	利用svn，颗粒度文档级	ok
	基于文字	ok	基本ok，看具体脑图软件是否支持	ok，看软件本身是否支持
统计		总评：中	总评：差	总评：良
	基于属性	ok	困难，现有软件基本不支持	ok
	基于关系	困难	困难，现有软件基本不支持	ok，需求与代码的关联看与svn等版本控制的结合度
	基于状态	ok	困难，现有软件基本不支持	ok
	基于版本	困难	困难，现有软件基本不支持	ok
	基于文字	困难	困难，现有软件基本不支持	ok，看软件本身是否支持
追踪		总评：差	总评：差	总评：良
	需求与任务	困难，因为多对多关系	困难，现有软件基本不支持	ok
	需求与代码	困难，因为多对多关系	困难，现有软件基本不支持	ok，需求与代码的关联看与svn等版本控制的结合度
	需求与测试	困难，因为多对多关系	困难，现有软件基本不支持	ok
	需求与人员	困难，因为多对多关系	困难，现有软件基本不支持	ok