这个是做CMMI的企业最熟悉的，因为RD过程域里边正好有着两样东西。
这种表述方式适合“产品-项目型”项目，也就是说企业整体上有一个成型的产品，并通过定制这个产品来销售给特定的客户。
简介：
用户需求就是用户需要用我们的软件来做什么，常常包含很多非软件功能的描述，比如（银行软件）“在开户时，用户凭身份证，身份证复印件，开户申请单（签字确认）可开户。”看似很简单，却有几个问题：复印件是一张纸，还是想用联机的摄像头拍摄一个？（航空安检就是这样的）开户申请单，是一张纸还是指屏幕上的一个表单？如果是表单，应该打印出来签字吧？
产品需求就解答上面的问题的：这个（些）客户需求需要我们产品具体做什么呢？
几个明显地是应该选择这种需求结构的判定条件：
1. 几乎每次销售都需要二次开发才能完成
2. 几乎每个客户都是大客户（因此才值得做二次开发）
3. 我能把客户分类并描述他们的业务特点，以及为什么购买我的产品
使用这种需求结构应该注意的地方：
1. 要善于让多个用户需求复用一个产品需求
2. 要善于从多个重复的用户需求中提炼并产品化产品需求
常见问题：
1. 这种方法没有颗粒度的概念，需要自己把握
2. 这种方法没有条目化的概念，很多企业理解为只要编写《用户需求说明书》《产品需求说明书》即可
更详细的内部结构：
1. 客户需求和产品需求可能各自还包含若干个层次
成功要诀：
1. 正确处理对不同级别的需求，典型地（不要生搬硬套）：
若一个需求仅来自于单个客户，应“轻视”之，只保留简单文档并进行简单测试，但要记录“有人要了这个需求”以便复用或提炼
若一个需求被提炼为产品需求，应建立基本的需求和设计文档及适当的测试手段。
若一个需求被列入产品核心模块（如工作流/信息流/组织结构等可复用内容），则应该建立健全的文档供5～10年内查阅，并确保自动化测试（每日冒烟测试和版本发布测试）
即基于功能点分析进行组织，特别适合于需要招标-报价的项目。
简介：
所谓文件，就是一组用户可以理解的逻辑数据，比如在“会议管理系统”中，会议/会议室/参加人都是文件。在OA/MIS等数据库系统众所，一个文件一般对应若干个物理表。
所谓操作，就是围绕某个文件展开的操作，比如会议的计划/通知/召开/总结/上传附件等；会议室的增加/修改/预订等；参加人的增加/删除/通知/统计等。操作必须是“基本过程”，也就是说包含了所有分支/异常等，以最终操作者达成操作意图为终点。
文件和操作对应若干功能点及造价，文件15（外部）或35点（内部），操作4～5点不等，每点对应1.5人天左右大约1000多元成本。
此方法比较新，已有配套的培训教程，包括如何利用功能来计算工作量/成本/工期，并有配套免费工具。
以下产品与之匹配：当需要向甲方竞标和报价的时候，用次方法可以迅速准确地计算价格，且双方均可理解。
几个明显地是应该选择这种需求结构的判定条件：
1. 政府行业
2. 需要向甲方报价
3. 这个系统是一个以数据和操作的数量为主要因素决定产品规模进而影响报价的（比如类似OA）
使用这种需求结构应该注意的地方：
1. 文件和操作的概念是有判定标准的，不要望文生义
常见问题：
1. 这种表达方式适合表达要做什么，但无法表达“做到什么程度”
更详细的内部结构：
1. 客户需求和产品需求可能各自还包含若干个层次
成功要诀：
1. 此方法的目的在于向客户确认是否“有必要做”成这个样子，每个功能的增加将带来造价的增加。
如果用别的方法描述需求，客户总是希望做得更全更好，但这个方法