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

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

　　用户需求-产品需求型

　　--------------------------------------------------------------------------------

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

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

　　简介：

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

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

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

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

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

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

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

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

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

　　常见问题：

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

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

　　更详细的内部结构：

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

　　成功要诀：

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

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

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

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