软件架构强调的是整体，而整体性的设计决策必须基于对需求的全面认识;
软件架构应该是稳定的，而遗漏了重要需求的架构设计面临的是返工的命运。
一言以蔽之，全面认识需求，是生产出高质量软件所必须的“第一项修炼”。
作为一个软件架构师，也不应对所有需求“胡子眉毛一把抓”，而是应全面认识需求——分门别类地将需求梳理清楚。
要全面认识需求，意味着我们必须从不同级别来考察需求：组织级、用户级、开发级，还要对每个级别考虑不同类型的需求：功能需求、质量属性、约束。
一方面，需求是分层次的。一个成功的软件系统，对客户高层而言能够帮助他们达到业务目标，这些目标就是客户高层眼中的需求;对实际使用系统的最终用户而言，系统提供的能力能够辅助他们完成日常工作，这些能力就是最终用户眼中的需求;对开发者而言，有着更多用户没有觉察到的“需求”要实现……
关注需求层次的实践意义在于，在需求之间建立起“可跟踪性”，避免因遗漏需求而造成软件“达不到要求”，也避免开发人员一厢情愿地为用户“制造”没有实际意义的无用功能。理解了需求分层的道理，软件人员在听到客户方的老板说“需求就是我希望这套软件能帮我赚更多的钱”时，就不会觉得好笑了，因为他知道这可能就是创建这套软件系统的商业目标，并会对其他需求和设计产生影响。
另一方面，需求应该被分为不同的类型。例如，一个网上书店系统的功能需求可能包括“浏览书目”、“下订单”、“跟踪订单状态”、“为书籍打分”等，质量属性需求包括“互操作性”和“安全性”等，而“必须运行于Linux平台之上”属于约束性需求之列。实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。
总之，通过需求分类，将有助于全面认识需求、分门别类地把握需求、设计出高质量的软件架构。
全面认识需求还有一层含义，那就是应当在深思熟虑之后做出合适的需求权衡和取舍。一方面，众多质量属性需求之间往往会有冲突，我们必须权衡。另一方面，如果通过复杂设计所支持的变化根本不会发生，那么这种过度设计(Overengineering)就造成了资源的浪费并增加了开发难度。有人主张不要预测未来，本书并不同意，本书认为应当有依据地支持未来变化，对变化的判断应该来自对需求及需求背景的深刻把握。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
