需求管理??需求的结构
在各类方法论和标准中，都大量提到了需求如何开发/描述/跟踪等内容，唯独关于需求结构的描述甚少，本文尝试比较几种需求结构的优劣及应用环境，供读者使用。
万事都不是的，切勿生搬硬套。
用户需求-产品需求型
--------------------------------------------------------------------------------
这个是做CMMI的企业熟悉的，因为RD过程域里边正好有着两样东西。
这种表述方式适合“产品-项目型”项目，也是说企业整体上有一个成型的产品，并通过定制这个产品来销售给特定的客户。
简介：
用户需求是用户需要用我们的软件来做什么，常常包含很多非软件功能的描述，比如（银行软件）“在开户时，用户凭身份证，身份证复印件，开户申请单（签字确认）可开户。”看似很简单，却有几个问题：复印件是一张纸，还是想用联机的摄像头拍摄一个？（航空安检是这样的）开户申请单，是一张纸还是指屏幕上的一个表单？如果是表单，应该打印出来签字吧？
产品需求解答上面的问题的：这个（些）客户需求需要我们产品具体做什么呢？
几个明显地是应该选择这种需求结构的判定条件：
1. 几乎每次销售都需要二次开发才能完成
2. 几乎每个客户都是大客户（因此才值得做二次开发）
3. 我能把客户分类并描述他们的业务特点，以及为什么购买我的产品
使用这种需求结构应该注意的地方：
1. 要善于让多个用户需求复用一个产品需求
2. 要善于从多个重复的用户需求中提炼并产品化产品需求
常见问题：
1. 这种方法没有颗粒度的概念，需要自己把握
2. 这种方法没有条目化的概念，很多企业理解为只要编写《用户需求说明书》《产品需求说明书》即可
更详细的内部结构：
1. 客户需求和产品需求可能各自还包含若干个层次
成功要诀：
1. 正确处理对不同级别的需求，典型地（不要生搬硬套）：
若一个需求仅来自于单个客户，应“轻视”之，只保留简单文档并进行简单测试，但要记录“有人要了这个需求”以便复用或提炼
若一个需求被提炼为产品需求，应建立基本的需求和设计文档及适当的测试手段。
若一个需求被列入产品核心模块（如工作流/信息流/组织结构等可复用内容），则应该建立健全的文档供5～10年内查阅，并确保自动化测试（每日冒烟测试和版本发布测试）
