需求作为设计的输入，应当被提升到KPI的高度，像对待自己的KPI一样对待需求是每个工程师都应该具备的品质。一份完备精细的需求可以给软件工程师节省很多不必要的时间开销，使其快速的投入到架构设计中，不可置否会有大量的业务细节困扰着架构设计，因此区别并抽象地对待需求就显得格外重要，否则设计就会被淹没在无尽的琐碎中。架构设计的过程对应于问题解决过程的抽象、建模的过程（计算机科学其实并不仅仅是研究计算机的组成，更多的是解决各种各样的问题），也可以说是一个将各种不可控因素转变成部分可控+部分不可控的过程。
那么回到需求，架构设计也应该甄别并区分出需求，将需求按照分组、分层的方式进行划分。良好的需求层次结构应该正确的反应业务，层次结构体现的是一种依赖，高层次的specific的需求的实现需要基于低层的general的实现，层次之间通过协议（接口）进行通信，底层的需求实现后可以以做加法的方式实现上层的需求。分组是将同一层次的需求按照某一规则进行划分，它的好处是架构设计只要保证一个组中的某一需求能够被实现，那么因为分组的平等、等效原理，其他处于同一组中的需求自然也全部可以得到满足。需求分档的好坏除了是否能够反应用户真正的需要这一刚性条件之外，还有就是需求本身的体现的逻辑性，上述步骤无疑是一个整理一件混乱房间的过程。这个分解过程，其实是是一个从问题域到实现域转化的中间过程，通过需求的分层，其实是对需求进行了优先级的划分，当然general的需求优先级高应该被先实现。分组的需求可能被划分成独立的模块，有可能具有等价性。
架构设计除了需要对需求进行分层分组之外，还需要有变与不变的维度思考，这里的变与不变都是相对的，基于对业务逻辑的深刻认知。架构设计更多的关注相对恒定的部分，同时为相对易变的部分提供支持。
通过以上步骤基本可以确定业务模型（基于不变的部分）结合用例图、时序图。。。
结束语：做每件事情都是有原因的，反之因为各种各样的需求想法，才驱动人们采取行动。所以可以说是需求驱动着商业公司的运作，淡化或者忽视需求犹如“无源之水，无本之木”。然而见于对需求的管理，变更的追踪以及某些软件工程师对需求的偏见，方方面面还有极大的空间需要去提升。如果你曾经尝试去看一些优秀的开源代码，或者新入职一家公司上来就看代码，你一定会有看不太懂的感觉。了解需求可以使你开发出更好的产品同时也能使你更快的了解遗留代码，可以说代码和需求是对同一概念的不同的表现形式。了解需求同样对于你去学习新技术也会带来很大的帮助，从问题入手。。。
