在需求分析阶段修复错误。

* 如果错误保持到系统设计阶段，定位和修复要多花5倍的代价；

* 如果保持到编码阶段，要多花10倍的代价；

* 如果保持到单元测试阶段，要多花20倍的代价；

* 如果保持到交付阶段，要多花200倍的代价。

Boehm, B., "Software Engineering" IEEE Transactions on Computers, 25, 12(Dec. 1976), pp. 1226-1241.

正确的做法是：立刻不计代价，尽可能多地获取需求信息。

> 需求难以理解，更难以说明。错误的办法是草率地完成需求规则说明，匆忙地进行设计和编码，然后徒劳地希望：

* 任何系统都比没有系统要好；
* 需求迟早会解决；
* 或者，设计师在开发过程中会明确可以开发什么。

> 正确的解决办法：
* 和客户交谈；
* 收集数据，把理解的需求记录下来，并规划构建一个满足这些需求的系统；
* 如果预期需求会发生很大变化，可以用增量的方式开发（原则14）；
* 做好需求规格说明。

Boehm, B., "Verifying and Validating Software Requirements and Design Specifications", IEEE Software, 1, 1(Jan. 1984), pp. 75-88.

方案的变化总是比构建系统的成本低。

* 不要匆忙提供解决方案；

* 不同解决方案的成本、风险、时间差别巨大，任何一个方案生效，都取决于特定的场景；

* 针对面临问题的人及问题的本质，要确保深入分析了所以的可能选择；

* 解决问题时，不要被最初方案带来的潜在兴奋所蒙蔽，方案的变化总是比构建系统的成本低。

Gause, D.,and G. Weinberg, Are Your Lights On? New York: Dorset House, 1990.

造成低质量成本估算的前5个原因，都与需求分析流程有关。

1. 频繁的需求变更；

2. 不完整的需求列表；

3. 不充足的用户沟通；

4. 低质量的需求规则说明；

5. 不充分的需求分析

> 为此
* 使用原型，降低需求不准确的风险；
* 使用配置管理，控制需求变更；
* 使用正式的方法，进行需求分析和编写需求规则说明。

lederer, A., and J. Prasad, "Nine Management Guidelines for Better Cost Estimating." Communications of the ACM, 35, 2(February 1992), pp. 51-59.

用最好的方法也可能产出糟糕的设计，最过时的方法也可能做出精致的设计。

* 不要有任何借口；

* 系统的开发者，要承担把系统做好的责任。

Hoare, C.A.R , "Software Engineering: A keynote Address", IEEE 3rd International Conference on Software Engineering, 1978, pp. 1-4.

研究再转化不可行.

> 软件研究所中令人难以置信的技术成就，有大量报道。但他们很少能应用于软件开发实战，原因是：
* 一般来说，软件研究者很少有开发实际系统的经验；

* 软件研究者发现，在解决一些技术问题的时候没有必要花费过多时间去“适配”真实场景，这样可使解决问题变得更快更容易；

* 研究者和实践者在用语上存在巨大的分歧，导致他们很难相互沟通。

> So
* 工业界萌发想法并验证效果，而不是在想法成型后再去做技术转化。

Basili, V. and J. Musa, "The future Engineering of software: A Management Perspective", IEEE Computer,24, 9(Sep. 1991), pp. 90-96.

技术文档中，必须使用相同的术语来表示相同的概念。

* 为了不让读者困惑，不至于浪费时间去确认是否有新的技术信息；

* 此原则可以应用于规格说明、用户手册、设计文档、代码中的注释。

Meyer,B. "On Formalism in Specifications" IEEE Software, 2, 1 (January 1985), pp. 6-26

索引通常是文档所使用的所有术语和概念和列表，标记术语在哪里被定义，对后续的维护和优化也很重要。

：当阅读文档遇到不懂的术语时，我们都会感到沮丧。但当我们在术语表中查到说明时，沮丧的情绪顷刻就烟消云散了。

* 定义中使用的任何单词，都应该尽量避免再去术语表中查找定义；

* 术语说明文字中，要用特殊字体标识

如果项目、组织或客户要求遵循一套文档标准，那就要遵循它。

* 遵循标准，理智地之行；

* 无论标准怎么规定，把你知道的应有内容包含进去；

* 如果文档没有被要求遵循某个标准，至少使用检查清单来检查是否有重大遗漏；

* IEEE / W3C发布的文档标准，是我所知道的最广泛的可用软件文档标准之一。

IEEE Computer Society, Software Engineering Standards Collection, Washington D.C.: IEEE Computer Society Press, 1993.