在学校里学计算机语言时以为，编程和架构是整个软件生命周期里最了不起的部分，但实际工作后才发现在商业产品里需求管理（包括新需求的发掘）更是一个商业软件成功与否的关键。在以下我和大家分享一点在90年代我经历的一些需求管理小故事，希望能对刚进入软件行业的精英们有点概念性的帮助。请理解在这么小的篇幅里，我们更多地只是概念性地理解需求管理的重要性而已，绝非是要提供完善的解决办法。
软件工程里的许多问题，诸如缺陷及资源运用不当，都是源于需求的不确定。在90年代，我曾在美国一个拥有数千员工的公司里从事大型软件开发工作。该软件主要是卖给汽车修复厂用的，它可估算出修复汽车的零件及劳力两项费用，甚至还可以找到提供新零件及旧零件的厂家。软件的的复杂度相当地高，要界定什么样的界面和功能是最适合市场的着实不易。所以，需求一变再变。在聊天时有个同事戏称：“需求变更乃万恶之源！”其他的人纷纷响应。当时，所有的需求都是写在Word文档里的，那些文档不是放在一个共享的服务器里，就是交由负责编写程序的人员管理。虽然没用什么管理平台及工具，但在团队成员的配合和默契下，一切事情都有序地在进展着。
但有一天产品经理换了个新的，一切事情似乎就全改变了。新的产品经理原是某汽车修复厂的经理，他对修汽车及车厂管理有不少的经验，但对软件的开发是很不懂的。很快地下列问题出现了：
（一）需求描述不清楚，导致开发任务的时间估算误差可到100%，甚至200%；
（二）优先及全由产品经理决定，有时不太重要的任务先做了，重要的反倒后做；
（三）需求变更一再发生，并且当某需求变更了，它的连锁反应会冲击其他的部分，许多缺陷因此产生了。
我们几个资深人员分析整个过程，发现造成问题的原因是这样的：
（一）我们的现有需求文档管理太乱，通常是找不到所要的版本。就算是找到要的文档，常常也没法找到要的那段内容。
（二）可判断任务优先级的因素颇多，可以是在商业层面或技术层面，每人的视角不同，公说公有理，婆说婆有理。
（三）需求文档、代码、测试用例及其他的工件（artifacts）之间应是相关联的，但在系统中我们无法从其中任一个工件找到其他的工件。
由于文档不全，这位新的产品经理很难在短时间内对整个系统有个概括性的了解。当他和资深人员沟通产品设计理念及历史缘由时，资深人员也没能明确地回答他的问题，这导致需求设计不完善，优先级也有误。找到原因后，我们想既然需求变更这一头凶猛野兽是杀不死的，那我们所能做的大概也就是将这兽关在笼子里，使它温驯点。 为解决这问题，我们建立了以下的体制。
（一）细化需求的时间估算 – 我们将需求分解到程序员能清楚估算出完成时间的小单位，原则上每单位是可以让一个程序员及一个测试人员在二至十天内做完，而且每个单位都有个编号。
（二）使用版本控制系统管理需求文档 – 所有需求文档全保存在一中枢版本控制系统里。
（三）将需求分组并设优先级 – 所有的需求单位按照不同的版本区分开来，每个需求单位都有个优先级。
（四）建立工件之间的关联性 – 将程序及测试用例与相对应的需求单位连接上，明确地写上需求编号。
（五）建立评审团队 – 当需求产生或变更时，产品经理及干系人要一起评审，通过后才做更改。
我们开了好些培训会，务必保证每个程序员、测试人员及产品经理都遵照制度走。在会议室的白板上画出很多间隔，贴了满满的纸条。当然，我们也使用了Excel及一些小工具帮助我们管理需求。当年我们虽不知敏捷方法为何物，但却采用了好些敏捷操作，如站立会议等。
花了三个月把这个体制建立好后，团队气象一新。整个软件生产的过程严谨了许多，需求成为软件生命周期的核心。在任何阶段，需求及相对应的代码都有人负责。对需求的严格审核使得后期的修改及对缺陷的修复减少了许多，效率提高起来。
整体来说，当时我们所作的改进是有成效的。但我们也发现，对这体制的维护相当不易的。举例来说，需求变更的评审是需要有个流程的。但不同类型的需求要由不同组的人评审，甚至有些是外部修车厂的人员。更糟糕的是，评审流程也随需求种类的不同而不同。我们将流程写在文档里，但流程图及相关的人员经常在变动。我们不仅需要有专人来维护，有调整时还要开会通知，费力且常发生错误。
另外，在大系统里需求变更所产生的连锁反应是相当可怕的。曾经有一次，我们根据需求的变更找到了出现问题的某些代码，非常高兴地把代码改了，以为问题得到了解决。但不久，客户反馈我们在另两个地方发生错误。（实际上恐怕还不止两处呢！）我们把这两处改了后，又发现这些修改造成了更多其他多个问题。在代码的层面这可以是因软件代码的耦合。但它不仅是在代码的层面，更可能是在商业逻辑的层面。比如说，某公司在同一领域发展了三个互补性的软件产品。这三个产品可能共享一套工具模块（utility）。当工具模块里的某个程序被改了，我们需要查验它是否对其他的两个产品造成冲击了。这是在代码层面的，还相对容易些。在商业逻辑层面的就更难了。这三个软件产品在设计时必然是建立在一套完整商业逻辑上的。改了其一，必要检视是否也要对其他两个做对等的修改。要解决这问题，要依靠知识系统的全备及人员的经验。我们当时在需求、测试案例及相关工件之间建立的关联性也仅仅是在项目层面，而非组织（公司）层面。（呵呵！所以，路还遥远的很。）
两年之后，因为项目将要完成，人员减少了60%。我是外聘人员（contractor），也在最后一批中离开了。我发现，虽然我们花了不少力气在需求管理上，虽取得一点成效，但收获颇为有限。主要的原因是人员变动太多、流程不断在修改以及太多的机械性工作。现在市面上已有许多相当不错的需求管理工具及ALM （Application Lifecycle Management）研发管理平台，它们可以帮忙作需求整理、需求量化、版本控制及需求变更控制，ALM 研发管理平台里相关的工件可以彼此连接，甚至一个需求单元在整个软件的生命周期的历史都可以完全追踪。这解放了大量的人力成本，跟当年比起来事情应该是要容易得多了。
原文链接：http://www.techexcel.com.cn/newsevents/relatedarticles/20100419_1
------解决方案--------------------------------------------------------
Mark，学习。。。
------解决方案--------------------------------------------------------
哎，太长了，最好能精简一点。
------解决方案--------------------------------------------------------
问LZ个问题，为什么CMMI不先做需求开发，而要先做需求管理呢？开发都没有开发出来，管理什么呢？
------解决方案--------------------------------------------------------
CMMI的需求开发是关于“如何做好需求开发”而非“把需求开发出来的”，里边包括了需求的层次化/用例化/风险与限制分析等等工程内容。
而需求管理则是关于如何与客户沟通需求/控制变更/保持需求追溯（其实就是“保持需求被开发出来别忘了”）等。
为何需求管理在2级，而需求开发在3级？
因为如果反观失败的项目，前两位的显然是“计划过于乐观”和“需求不断变更和蔓延”，而需求的工程化水平则在其次。所以CMMI选择把PP/PMC/REQM选择为2级核心内容，以保证项目整体不会失败。
当然作为美国军标，CMMI管理的多数为大型军事软件或嵌入式软件，只保证“整体不失败”是不行的，所以3级引入了大量工程化内容，且实际上只有满足3级才能成为国防部供应商，2级只是一个很基础的跳板。