我不接触CMM已经有好几年了，写《解读CMMI》这本书的想法来源于一次午餐时与同事的讨论。通过这次讨论，我感到大多数人对于CMMI的理解只是停留在书本中，无法将书本中的要求转化为实际工作中。其实我也很长时间没有考虑CMM或是CMMI了，但是那段谈话却又从新激起我对CMM的热情。

　　如果从我97年接触ISO9000开始算起，我已经做质量18个年头了。在这11年里我经历了从感触到迷茫，从迷茫到重新的认知，到抛弃CMM，直至今天的感悟。这是一个漫长的路程，也是每个质量人员可能都会经历的路程。当我有2年时间不作CMMI而专做生产质量、工程质量后的今天，我感到对CMMI又有个更深一步的感悟，这也许该感谢我的这2年，它让我更有时间进行思考。

　　这里面也会融合一些敏捷的实践，这是我在2003-2004年做XP以后又在2013年2015年进行SCRUM敏捷开发和精益创业结合地实践得到的感悟。不得不说敏捷开发是一种继承也是一种颠覆，我会在这里逐渐介绍这两种敏捷的内容与不同之处。

　　我也希望博客上的内容得到更多人的关注并针对一些问题进行讨论，这样我们就能有更多的实例，我会尽快将这些实例梳理后放到博客上面。

　　第一PA：需求管理

　　CMMI的第一个PA就是需求管理，因为需求是一切开发的基础，他直接影响着以后的各个PA。所以对于一个刚刚起步的公司，首要搞好两个部分：第一个就是需求管理，还有一个是测试。只要抓住这一头一尾，研发质量就会有很大改观。

　　需求管理在CMMI中目的只有两点，第一是维护、跟踪需求，另一个是确认需求。www.mypm.net

　　针对这两个目标，CMMI将需求管理分成了5个SP。

　　SP1.求得对需求的理解。即：如何捕获需求。

　　我们的需求人员需要将用户需要转化成量化、可测量的用户需求，这个关键点在于：

　　1. 定出用户代表，即谁能代表用户确认用户需求:

　　只有先正确定出用户代表才有可能作出正确的用户需求。有的人认为领导就是用户代表，这很大程度上是正确的(至少在中国是这样)。但是我这么说你也可以理解为这么做是错误的。比如我最早在钢厂做自动化控制，一个厂家不太懂事，直接和我们领导定下了需求，等到开发完成后一运行完全不能使，没办法我们领导不能替他们背黑锅，损失他们厂家自己担了，所以领导有时又不一定是用户代表。

　　那么如何选定用户代表?我建议：先建立业务模型后，将模型分层，每层再找用户代表，这种方式在OO(面向对象)开发中极为有用，这样可以分解找用户代表的难度和风险。这个如果有时间我可以给大家介绍一下，如何进行业务建模后的分层和按层找到用户代表。

　　2. 将用户需要转变为用户需求：

　　往往用户提出的要求是需要而不是需求，我们需求人员要将需要量化并确认可实现、可测量，这时才是我们需要的用户需求。举个简单例子：用户会告诉我们一个非功能性需要：打开某某页面时速度一定要快。好了，用户要求快，那什么是快?1秒还是2秒?这个就需要我们来诱导用户来明确。还有一些是隐含需求。用户以为你的产品本来就应该达到的，但是往往你并没有意识到，那样也比较糟糕。例如：用户买冰箱，他觉得你是大品牌厂家，低噪音是本来就应该具备的，那么你的产品是这样的吗?另外捕获用户隐含需求，有时还可以使你的产品增值或提高竞争力。仍是以买冰箱为例，如果你挖掘出用户还有冰箱门左右都可安装的需求，而这个需求你的产品是支持的。嘿嘿，你的机会可能就真的到了。

　　3. 需求出口要唯一：

　　当需求人员比较多时要明确答应用户需求的流程，出口一定要唯一。如果每个需求人员都可以确认用户需求，我们可以想象，我们的需求可能有重复的、相互茅盾的，需求将会一团糟。

　　SP1.2 求得对需求的承诺，即：如何进行需求确认

本文原自http://www.mypm.net/articles/show_article_content.asp?articleID=30112