可惜，软件毕竟不同于工业产品，在工业化生产的过程中，质量检测的一个方法是在产品出厂前设置质量检测，通过质量检测的出厂，否则回收。这种方法无法适用于软件。后来，质量检测逐渐倾向于生产过程，在过程中监测产品质量。这种方法比起前一种方法进步了很多，但是它需要对生产全过程进行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。

在《软件工程》一书中，作者把软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。软件过程中充满了各种各样的方法论，从需求到最后的维护。要在自己软件组织中应用所有的方法是不可能的。所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话，打消那种念头，从零做起。

2、需求过程

需求过程是软件过程的一个很重要的部分。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的"祸根"（Leffingwell 1997）。我在自己的身边也做过一次小范围的调查，结果显示成功的项目都离不开成功的需求（一个重要的标志是用户的支持）。

需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理，他们所涉及到的具体工作流如图所示：

需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。

3、需求过程和CMM

软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。（更详细的定义和说明请参看《CMM白皮书》）。

CMM中和需求有关系的是第2级（可重复级）中对需求管理的要求和第3级（已定义级）中对需求跟踪能力的要求。必须指出的是，CMM只是规定成熟的软件组织应该达到的关键能力，是一种改进软件过程的策略，对具体的方法并没有做限制规定。所以CMM中没有涉及到需求开发的内容。

4、需求过程和软件生命周期模型

任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。