一、能否将用户需求、软件需求、业务需求合并，减少这些文档的数量？
一般会将需求文档分为用户需求和产品需求：一类是面向客户，用用户的术语来表达的需求，称之为用户需求；另一类是开发人员理解用户需求后，用技术的术语来表达的需求，称之为产品需求。如果想把这两个需求文档放在一个文档里面，是可以的，CMMI评估也是认可的。
拿UserStory来举例，UserStory包括角色、功能、目的三段论。如果仅仅描述了这3部分，可以认为这是一个用户需求，这个需求粗略地说明了“我要什么”。产品或开发人员通过需求细化，来形成验收标准、实例化需求，通过原型来把需求具体化。这个时候这个需求就可以称之为产品需求了。那如果把这两种需求都放在一个Excel表里，前三列是角色、功能、目的，后三列是验收标准、优先级以及界面原型。可以将这种形式的需求称为需求定义，在评估的时候完全可以这样去评估，也能够通过评估。
需要去思考的一点是，合到一个文档里了，是不是也需要站在用户的角度来描述需求，站在产品的角度、开发的角度，把需求做细化？放在了一个文档里面，还是会有两个侧重点。
当然，还有的公司会更往前延伸，描述业务背景（我原来是什么样的？我原来的作业是如何做的……）等等。需求描述的概略、详细程度不一样，可能Zui开始描述比较粗，随后会一步步细化，可以将它分成多个文档。有的公司有可能会写3、4份文档，这些都是可以的，都非常灵活。
二、问题跟踪表、风险表、机会表，这几个能合并吗？
需要把概念区分开。问题跟踪是已发生了，发生的概率已等于1，已经成为客观事实。对问题，只要去找应对的措施，去关闭它就OK。风险是可能发生的坏事，在风险没发生之前，去预防它的发生，采取的一些预防措施。机会是预料之外的好事，也要去跟踪它状态的变化，可以提供一些便利措施使这个机会能够来临，或者机会一旦来临了，要采取措施抓住它。
这三个概念先区别开，再看看在你们公司中能不能合并。如果单纯问能不能的话，那肯定是可以的。如果问提倡不提倡这么做，建议是不太提倡合并的。
三、CMMI与IPD流程的区别及侧重点？
IPD是定义了主流程，定义了生命周期模型。CMMI只给了实践。如果落地IPD的时候，需要再去定义自己的流程，把IPD大的阶段划分，再做细化。当你做细化的时候，这时候就会用CMMI的实践帮你填充流程。
