什么架构，就是搭建业务到代码实现之间的桥梁。关于架构的第一步，就是需求。
如何整理需求，才能覆盖整个系统，才能没有太重要的遗漏，很多人无从下手。方法是关键。
如果你的需求只是一个一维需求列表，那么你就彻底失败了（针对大型系统而言）。
首先，需求是分层次的。如果不分层次，有很多需求会遗漏，而且也很难发现需求间约束。并且，部分层次的需求，很难发现开发中的软件质量和约束，而这些，则很能导致最后项目的失败。
需求划分为3个层次：
1.业务需求。你的软件目标。甲方和乙方是否在愿景上达到一致。
2.用户需求。你的系统能帮用户做什么，不能做什么。
3.开发需求。你的开发环境，需要甲方或者公司提供什么。
其次，关注3个层次的涉众。
1.业务层次。考虑涉众，根据业务环境分析业务环境对系统的约束和业务环境中关心的软件质量。
2.用户需求。考虑涉众，同上。
3.开发需求。考虑涉众，同上。
3个层次的涉众可以是多个。
只有按照层次获取需求，分析需求，才能做到真正覆盖系统，才能发现关键质量和约束。很多公司都是一张一维的需求列表，需求很零散，所以很难会考虑到涉众，也很难考虑到环境，所以会有很多遗漏的需求，质量和约束。将需求分为3个层次，然后考虑每个层次的涉众，需求，质量，约束，并研究这几点的约束和衍生出的需求，这样才能让开发顺风顺水，减少有返工，开发的项目不是想要的，减少遗漏的目的。而且，按照一定方法分析，不会有无从下手的感觉。