[修订]关于需求管理的胡思乱想
先来张图
图解：
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 |
