需求管理-需求的结构

在各类方法论和标准中，都大量提到了需求如何开发/描述/跟踪等内容，唯独关于需求结构的描述甚少，本文尝试比较几种需求结构的优劣及应用环境，供读者使用。

万事都不是绝对的，切勿生搬硬套。

用户需求-产品需求型

---

这个是做CMMI的企业最熟悉的，因为RD过程域里边正好有着两样东西。

这种表述方式适合“产品-项目型”项目，也就是说企业整体上有一个成型的产品，并通过定制这个产品来销售给特定的客户。

 

简介：

用户需求就是用户需要用我们的软件来做什么，常常包含很多非软件功能的描述，比如（银行软件）“在开户时，用户凭身份证，身份证复印件，开户申请单（签字确认）可开户。”看似很简单，却有几个问题：复印件是一张纸，还是想用联机的摄像头拍摄一个？（航空安检就是这样的）开户申请单，是一张纸还是指屏幕上的一个表单？如果是表单，应该打印出来签字吧？

产品需求就解答上面的问题的：这个（些）客户需求需要我们产品具体做什么呢？

 

几个明显地是应该选择这种需求结构的判定条件：

1. 几乎每次销售都需要二次开发才能完成

2. 几乎每个客户都是大客户（因此才值得做二次开发）

3. 我能把客户分类并描述他们的业务特点，以及为什么购买我的产品

 

使用这种需求结构应该注意的地方：

1. 要善于让多个用户需求复用一个产品需求

2. 要善于从多个重复的用户需求中提炼并产品化产品需求

 

常见问题：

1. 这种方法没有颗粒度的概念，需要自己把握

2. 这种方法没有条目化的概念，很多企业理解为只要编写《用户需求说明书》《产品需求说明书》即可

 

更详细的内部结构：

1. 客户需求和产品需求可能各自还包含若干个层次

 

成功要诀：

1. 正确处理对不同级别的需求，典型地（不要生搬硬套）：

若一个需求仅来自于单个客户，应“轻视”之，只保留简单文档并进行简单测试，但要记录“有人要了这个需求”以便复用或提炼

若一个需求被提炼为产品需求，应建立基本的需求和设计文档及适当的测试手段。

若一个需求被列入产品核心模块（如工作流/信息流/组织结构等可复用内容），则应该建立健全的文档供5～10年内查阅，并确保自动化测试（每日冒烟测试和版本发布测试）

 

文件-操作型

---

即基于功能点分析进行组织，特别适合于需要招标-报价的项目。

 

简介：

所谓文件，就是一组用户可以理解的逻辑数据，比如在“会议管理系统”中，会议/会议室/参加人都是文件。在OA/MIS等数据库系统众所，一个文件一般对应若干个物理表。

 

所谓操作，就是围绕某个文件展开的操作，比如会议的计划/通知/召开/总结/上传附件等；会议室的增加/修改/预订等；参加人的增加/删除/通知/统计等。操作必须是“基本过程”，也就是说包含了所有分支/异常等，以最终操作者达成操作意图为终点。

 

文件和操作对应若干功能点及造价，文件15（外部）或35点（内部），操作4～5点不等，每点对应1.5人天左右大约1000多元成本。

 

详情可参考造价估算标准文件：http://ishare.iask.sina.com.cn/f/7997845.html?retcode=0

此方法比较新，已有配套的培训教程，包括如何利用功能来计算工作量/成本/工期，并有配套免费工具，请参考http://www.cspin.org.cn/。

 

以下产品与之匹配：当需要向甲方竞标和报价的时候，用次方法可以迅速准确地计算价格，且双方均可理解。

 

几个明显地是应该选择这种需求结构的判定条件：

1. 政府行业

2. 需要向甲方报价

3. 这个系统是一个以数据和操作的数量为主要因素决定产品规模进而影响报价的（比如类似OA）

 

使用这种需求结构应该注意的地方：

1. 文件和操作的概念是有判定标准的，不要望文生义

 

常见问题：

1. 这种表达方式适合表达要做什么，但无法表达“做到什么程度”

 

更详细的内部结构：

1. 客户需求和产品需求可能各自还包含若干个层次

 

成功要诀：

1. 此方法的目的在于向客户确认是否“有必要做”成这个样子，每个功能的增加将带来造价的增加。

如果用别的方法描述需求，客户总是希望做得更全更好，但这个方法可以避免。

 

场景-故事型

---

敏捷中非常推崇的方法，但多数敏捷方法只提到了故事，而较少谈及场景。

即使不使用敏捷，也可以使用这种方法。

 

简介：

故事只有一句话，但却很好地表达了几个重要内容，比如（银行软件）“三次密码错误锁定”这个功能会写成“作为用户，我希望在取款时尝试密码第三次错误后锁定账号，以防止有人恶意尝试我的帐号密码。”角色-操作-目标 是故事中最重要的三个要素。很多传统的需求描述方法文字冗长，却未能覆盖这三个要点。

场景呢，则是某种应用环境，围绕场景可以发生若干故事。比如“取款”就是一种场景，包括了密码正确正常取款/密码可以重试两次/三次密码锁定等若干故事。

 

 

以下产品与之匹配：有一定的创意，很希望通过创意生成故事，进而增进产品的功能。

 

几个明显地是应该选择这种需求结构的判定条件：

1. 产品的吸引力不在于功能多少（否则应该用上面的文件-操作型），而是实现到何种程度（故事中的“目标”）

2. 针对一种场景，可以想象很多故事以增进产品价值（简直是无穷的，因此需要排列优先级）

 

使用这种需求结构应该注意的地方：

1. 故事必须是一个能/也必须整体交付的功能，这是故事的一个天然颗粒度把握方法。

 

常见问题：

1. 故事写得不好。问题很多，买本书看看：用户故事与敏捷方法 http://www.china-pub.com/196596。很可惜，里边没有怎么提到用户故事如何组织。

 

更详细的内部结构：

1. 很多场景各自还包含若干个层次

 

成功要诀：

1. 一定要面向用户价值描述用户故事，否则经常无法达到预期效果。比如一款杀毒软件，每次安装其他软件时，需要多次修改注册表和硬盘，因此弹出的拦截界面很多；尽管可以选择“相同操作不再提醒”，但仍然弹出。因为用户理解的“相同操作”（同一个软件的安装过程中）和程序员理解的“相同操作”（同一个注册表项的修改）不同。

 

用例型

UML的方法。

没好好学过UML，所以也不太清楚。

 

只记得非常重要的一句话：只描述那些对客户有价值的用例，登录/修改密码/XXX都别写（潘家宇说的）。

从这一点上看，UML的组织方法是面向开发团队的。

想想也是，别看都是图形化的，UML可真不是写给客户看的，包括UC图。而且UC图下面马上接上的是Sequence等技术图，如果一个UC下面没有或者不必要画那些技术图，这个UC也就可以消失了。

 

待续（重要的也就这几个了，有需要听其他的读者请跟帖，我接着写）