首先要明白 需求 和 （代码）实现 是怎样的对应关系。
假设需求和实现是一一对应的。那么需求改变一处，代码也必然改变一处。
有人想要需求变了，却也不改写实现，是不符合逻辑的。
变化有三种，一句话：增删改。对三种情况作分析：
增：不需要改写原来的，而增加新的实现。
删：只需要去掉对应的部分。
改：改掉对应的部分。
因此，结论是，软件设计，应该满足在增加功能的时候，不修改固有代码这个原则。虽然删除需求的需求不多见~嗯~~~，这个其实是上一个规则的不同表诉。改，嗯~~~本质上也是第一个规则。
如何应对需求不断的变化？这是折磨软件设计者的难题。
需求变了，不改变实现是不可能的。我们要做到的是变化多少，改动多少，做到平滑的伸缩性。
要很好的实践这个标准，要求设计者：
1.把需求实现
2.把需求变化作为需求
比如要做个表格，原来三个字段，能满足用户的当前需求了。但是您也是知道的，用户9成9在将来会要求增加字段。这种对需求变化的需求，虽然是隐性的，但确实存在，某种层度上也不难预见，只是因为懒惰不去实现罢了。
回到原点，如果把需求变化的需求实现了，那么相对实现来说，需求就没有变化，不需要改动了。这是一个绕口的表述，但是表明了：
1.需求变化的需求不能都实现，只是相对性而言。
设计者何种程度上满足需求变化的需求，还是要具体项目具体实现，这是对软件维护阶段深入解读的结果。