第 2 部分 需求工程原则
原则 38 低质量的需求分析，导致低质量的成本估算
原则 39 先确定问题，再写需求
原则 40 立即确定需求
原则 41 立即修复需求规格说明中的错误
原则 42 原型可降低选择用户界面的风险
原则 43 记录需求为什么被引入
原则 44 确定子集
原则 45 评审需求
原则 46 避免在需求分析时进行系统设计
原则 47 使用正确的方法
原则 48 使用多角度的需求视图
原则 49 合理地组织需求
原则 50 给需求排优先级
原则 51 书写要简洁
原则 52 给每个需求单独编号
原则 53 减少需求中的歧义
原则 54 对自然语言辅助增强，而非替换
原则 55 在更形式化的模型前，先写自然语言
原则 56 保持需求规格说明的可读性
原则 57 明确规定可靠性
原则 58 应明确环境超出“可接受”时的系统行为
原则 59 自毁的待定项
原则 60 将需求保存到数据库
第５部分 测试原则
原则 107 依据需求跟踪测试
原则 108 在测试之前早做测试计划
原则 109 不要测试自己开发的软件
原则 110 不要为自己的软件做测试计划
原则 111 测试只能揭示缺陷的存在
原则 112 虽然大量的错误可证明毫无价值，但是
原则 112 虽然大量的错误可证明毫无价值，但是
零错误并不能说明软件的价值
原则 113 成功的测试应发现错误
原则 114 半数的错误出现在 15% 的模块中
原则 115 使用黑盒测试和白盒测试
原则 116 测试用例应包含期望的结果
原则 117 测试不正确的输入
原则 118 压力测试必不可少
原则 119 大爆炸理论不适用
原则 120 使用 McCabe 复杂度指标
原则 121 使用有效的测试完成度标准
原则 122 达成有效的测试覆盖
原则 123 不要在单元测试之前集成
原则 124 测量你的软件
原则 125 分析错误的原因
原则 126 对“错”不对人
第７部分 产品保证原则
原则 173 产品保证并不是奢侈品
原则 174 尽早建立软件配置管理过程
原则 175 使软件配置管理适应软件过程
原则 176 组织 SCM 独立于项目管理
原则 177 轮换人员到产品保证
原则 178 给所有中间产品一个名称和版本
原则 179 控制基准
原则 180 保存所有内容
原则 181 跟踪每一个变更
原则 182 不要绕过变更控制
原则 183 对变更请求进行分级和排期
原则 184 在大型开发项目使用确认和验证（V&V）
第８部分 演变原则
原则 185 软件会持续变化
原则 186 软件的熵增加
原则 187 如果没有坏就不要修理它
原则 188 解决问题，而不是症状
原则 189 先变更需求
原则 190 发布之前的错误也会在发布后出现
原则 191 一个程序越老，维护起来就越困难
原则 192 语言影响可维护性
原则 193 有时重新开始会更好
原则 194 首先翻新最差的
原则 195 维护阶段比开发阶段产生的错误更多
原则 196 每次变更后都要进行回归测试
原则 197 “变更很容易”的想法，会使变更更容易出错
原则 198 对非结构化代码进行结构化改造，并不一定会使它更好
原则 199 在优化前先进行性能分析
原则 200 保持熟悉
原则 201 系统的存在促进了演变
