“记忆中，我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎的越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，他们最终都沉默了。。。”这是《人月神话》中的一段话，每每读到，都会产生强烈的共鸣——软件产品（这里我会严格区分程序和软件产品）着实值得令人敬畏。不像任何其他产业，软件项目有着极高的失败率，也曾给社会的发展的造成了巨大的损失。于是我们不断反思“到底是什么成就了软件的极高的风险率?”，看法自然是仁者见仁。
当我们试图分析并且给出软件系统失败的原因时，我们可曾想过“软件产品的失败到底是怎么定义的？”
A：软件没能及时的交付。
B：软件的功能、质量不过关。
C：软件开发超出了预算。
D：软件的鲁棒性、可读性、维护性、兼容性差。
。。。
Z：Anyway，客户不买单。
这种执果索因式地原因分析，也许我们都似曾相识。对于A、B、C，任何软件项目一定有明确的来自交付的时间节点、产品的功能性能和与产品相关预算的界定，从软件工程的角度他们应该都是需求规格不可分割的一部分。对于D，可读性、可维护性、兼容性、鲁棒性作为软件的一种属性（应该是每一位软件工程师孜孜不倦的职业追求），也应该被写进需求规格。综上，矛头貌似都指向了——“需求”。
对于需求，我们都希望它是精确的（没有歧义），完备的（多一分不多少一分不少），可实现的（可行的）同时又是可测试的（能够被验证）。而且事实证明，对于需求再多的投入都是值得的。然而对于需求，也有很多事实，我们也必须承认，a：没有什么项目从立项起，需求便是明确的（因为可能客户对他自己想要什么也不是很清楚）——需求总是不断的增加，不断的删除，不断的修改，反反复复，反复无常，直到慢慢地变得越来越清晰，越来越明确。但是从软件生命周期的角度来说，很少有项目真正的遵循“需求分析-概要设计-详细设计-实现-测试-交付-维护”的线性序列，真实的场景是，这些阶段之间出现了很大程度的重叠甚至是并行，很明显这是一个混沌。当需求的变化与设计实现无法及时的同步，再加上测试人员的话，事情可能就更糟糕了，失控的感觉有没有。b：对需求变更引起的风险分析与项目进度预估的过于盲目，为了追赶时间节点不得不加班加点的赶工，而赶工其实很大程度就意味着失控（如果不能有效的掌握并评估进度）。
总结下，如何更好的管理需求，从而使需求变更能及时反映到软件的设计，实现与测试中，是我们得以能够跳出混沌状态的必经之路！可以从以下几个方面着手。
1、总体的需求把控，top-down，关注业务逻辑，选择性的忽略一些细节。
2、架构设计要足够灵活，是之能够适应业务逻辑的变化。
3、建立一套稳健的机制，跟踪“需求-》架构设计-》详细设计-》测试”这个链条，使得任何一个环节的变化能及时反映到后续的活动中。形成文档变更记录，代码变更历史，缺陷管理系统，测试用例设计，使得所有环节产生关联，达到软件的可跟踪可追溯。
4、科学的管理。。。
