以下纯属个人意淫：
当我们接手到一个新项目的时候,通常的开发流程是:
需求分析->系统设计->编码->测试
需求分析阶段:
我们需要反复的客户沟通,弄明白他真正需要的是什么,而通常大多数的人的做法只是传声机,简单的把客户的要求转述给他人
在需求分析阶段,我们应该先调查客户所在的行业,清楚的了解客户所在行业的业务逻辑,这样才能在清楚客户真正想要的是什么的前提下,同时在清楚的理解客户需求后,结合自身技术经验 适当给客户讨论更加完美的方案,并可以提炼出客户真正想要的需求
系统设计阶段：
系统设计的重要性在于你可以不加设计的去盖一间小房子,但是你无法在不加设计的前提下去盖摩天大厦,这也是为什么很多时候很多项目不去做系统设计的原因,（我要盖的只是房子,能住就行了）。但是如果一个项目需要长久的运行下去,并在可见的时间内需要不断维护,没有一个清晰的系统设计肯定是不行的,它最终会在一阵大风中倒下。如何设计一个系统？
在第一步明白客户需求后,将客户的需求详细的写在纸上,
1：开始找名词。这是第一步 叫领域建模
2：在领域建模的基础上,开始创建对象,对象就是建模中的一个个模型,而对象的属性就是模型中的名词,同时我们在需求说明书中寻找动词,然后将动词归类到不同模型中,这就是方法（通常这一步比较困难,很难分清哪一个行为属于哪一个模型）
3：连接 将每一个对象通过各种设计原则和设计模式连接起来(这里面表述不正确,目前不是为了使用设计原则和设计模式) 你可以不使用设计原则,但使用设计原则一定更好,不使用设计原则的后果是在未来某一天你有可能会掉进坑里
编码：
通过编码实现系统设计阶段的设计,（这是不是很多码农自嘲是码农的原因？）,这一步含金量真不多,类似于翻译，哭。。。
测试：
测试的责任很重大,他是产品面世前的最后一道关。。。
在面对瀑布流需求的情况下,如何应对？
瀑布流需求就是 每天 每小时 都会有新的需求来到,同时这些需求之间毫无关联,举一个例子：
1：给钢铁侠加一个翅膀
2：给钢铁侠加一个尾巴
3：钢铁侠的翅膀需要是红色
4：钢铁侠可以喷火。。。
毕竟是客户的需求,不管是什么样子都需要满足,客户并不关心在一个成熟的系统上增加一个功能有多么困难,这是开发的事情,（怎么就不懂换位思考呢？）很显然 如果走正常的流程： 需求分析-系统设计-编码-测试，那肯定是无法在指定时间内完成了,所以这个时候大多数的做法是忽略系统设计阶段(比较浪费时间),然后利用自己对项目的熟悉经验 在短时间内添加某个字段,这种情况如果是老手 则可以正常通过,如果是新手 那有可能得到的是灾难。所以应对瀑布流的解决方案不在开发,而在缺少系统设计环节。
系统设计环节是在考虑整个系统的架构前提下新增需求。在需求分析和编码开发之间必须有一道环节,这个环节是把纷繁复杂的需求整理成可预期 有规划的项目工程说明书,需求分析是按照每小时的速度进来的,而系统设计给到开发是每周给出一个文档,甚至两周,这样才能解决瀑布流需求的频繁性与软件开发的稳定性之间的矛盾。系统设计的前提是 负责设计的人必须非常熟悉项目代码结构和业务逻辑,否则设计出来的也是很难使用的。