任何在项目伊始就规划所有的可能需求之企图都会落败，并以客观的延误告终。-Pahl,Beitz 《Engineering Design》
关于需求：
项目伊始，有多少需求是有技术人员参与的？有多少需求是市场人员提供的？。。。
现实中，大部分此类需求只是客户那边的管理层，各自为阵提出自己的想法。而这些想法很多只是为了表明自己分量，现实自己工作多么重要，这是我亲身体验？
当年我作为客户方的代理人（甲方），领导说要搞信息化，然后下面的部门就忙乎起来，各自罗列自己的需求，倒也很认真（不认真会丢饭碗的，呵呵），这种状况持续一段时间后，大家都拿出各自的需求列表，在会议上，谁的需求列表长说话就有力，而需求列表短的则感觉脸面无光？
各人只关心各人的需求，没有人对需求进行相互沟通，整合（整合后的需求算谁的呢？年底奖金怎么算？呵呵），最后整个需求打印出来有一尺厚，大量的不知所谓的需求，谁也搞不清楚最终要干什么？没有人负责整理需求里的各种概念，大量交叉重复的需求，就这样交到程序员面前。
我记得非常清楚的是一件事情，一个需求里出现了“类型”的字样，另一个需求里出现了"类别"字样，大家围绕这两个概念有的说是Class,有的是Kind,也有说是Type...,因为 需求本身就没有统一，只是各个部门各自为阵的罗列，没有一个概念上的统一性，更没有人专门负责维护这种统一性，结果可想而知，这个项目开发了8年（甲方相当有钱），生产了无数的网页，可是大家却不知道可以干什么，如果不是纪律要求员工必须上这个网，否则谁也不会去看。
这种需求出台的画面可以想象：
每个列席人都有一个需求列表，这个列表最终在多大程序上被采纳，事关自我价值的认同和个人荣誉。
讨论会上大家一片和气，我不给你添堵，你也别找我麻烦。
可是，有谁在需求制定过程中为最终产品本身-概念完整性，高效性，经济性和健壮性摇旗呐喊呢？
系统架构师在目前阶段能干什么呢？在这个阶段，系统架构师还无法掌握足够的领域知识来以事实为依据说服众人，因为这是在经典的、基于瀑布模型的产品过程中， 需求是在设计开始之前就要确定下来的。
抵制需求的膨胀和蠕变
需求膨胀的原因大部分和上面的场景有相似之处，我们必须抵制，方法是防范于未然或将这种势头扼制在摇篮之中。成功的项目往往在实际之初都只有少量几个概要的需求，随着开发的推进，这些需求被精化成更具体的子需求，而不是一开始就要精化到这种力度，这是过于理想化的。
现代流行的敏捷开发正是采用了这种方式，从少数几个需求开始，经过不停地迭代过程，开发的过程也是需求的探索过程，需求探索过程结束开发过程也随之结束。这种设计模式下，不需要人为地为某需求定制优先级，强调重要性，实际上优先级和重要性高的需求在探索过程中总是会先被发现。这种探索而来的需求，肯定是客户的真正需求，有用的需求，那些冗余的需求在这里会被很自然地整合。
需求的蠕变，主要是因为人们具有天生的发散思维，总是喜欢探索当前需求之外的场景，结果是某个具体的需求被无限衍生其功能，而衍生出来的这些功能都是通过一时脑热 而想到的，并不代表客户的真正需求。解决需求蠕变的方法是及早任命手腕强硬，经验丰富，领域知识到位的经理。
下面是摘抄片段：
假定：
1，客户从不索求无度，非常乐意为他的架构师和建筑工人的专业技能和辛勤劳动支付合理的费用。
2，客户聘请的代理人，渴望用自己的才华和技能帮助客户发现其真正需求所在，并竭诚服务。
3，承包方充分理解并不折不扣地按照其要求做事，并在预算和工期范围内依照最佳性价比生产高质量的产品。
4，所有的项目成员都是诚实、本分的，并且他们之间的沟通非常到位。
那么，我认为
1，成本加成式付款安排将会为客户付出的每一美元都带来最大的价值。
2，设计-构建法将是构建一个项目最快的途径。
3，现实的螺旋型过程将能产出最符合客户需求的产品。
现实：
我们无法解释瀑布模型的生命力为何如此坚挺，尤其是在螺旋型模型和合作化模型已经赢得用户忠诚度达四分之一世纪的前提下仍旧如此。
答案：
因为人的罪念：骄傲，贪婪以及惰性。
“上面所有条件同时成立的概率几乎为0”。
因为人类堕落，我们无法信任彼此的动机；
同样是因为人类堕落，我们也无法保证沟通到位。
关于合同：
先在合同上把价格让步,然后等合同上的需求变化时再好好抬价。您有这体会吗？
希望需求，目标和约束条件早点确定下来，是形成合同的最佳需求。每个人心里都很清楚，在实施过程中，需求一定会发生变化的。合同最多只能描述几个概要的需求，而实际的需求一定会更加庞大，如果合同真正能描述需求，那么瀑布模型应该是非常好的设计模型，而现实相反，为什么呢？
合同说到底，通常是来自某个机构的要求，固定价格或者是固定需求。但是这种想法与事实完全相反，想要给任何复杂的项目通过最初的指定来完成一组完备的，精确的
需求实际上是不可能的（其实这就是理性模型，强调项目开始之前指定需求），只有通过设计过程中不断迭代交互才可能完成。