架构关键需求是那些在决定系统架构时扮演重要角色的需求。这些需求需要特别关注。对架构而言，并非所有的需求都具有平等的意义。

架构关键需求是在架构被认为“稳定”之前需要的满足需求，是全部需求的子集。通常，这些需求是技术挑战、技术约束，或者系统的核心目标。此外，通常系统对架构关键需求的变化会更敏感，因此识别并沟通这些需求有助于其他人理解变化带来的潜在影响。

对架构关键的需求可以是显式或隐式的。显式的关键需求常常是明显的技术，如性能指标、和其它系统的接口、必须支持的用户数、或者安全需求。隐式的关键需求可能定义了系统功能行为的本质（例如，从在线商店上购买）。

决定某个需求是否是架构关键需求常常是一个判断的问题。判断需求是否“对架构关键”通常由几个关键因素所驱动：

• 需求对涉众的价值：关键的、重要的或有用的。
• 需求对架构的影响：无影响、扩展或变更。可能存在某些对架构没有影响或者影响很小的关键需求，也可能存在某些低价值的需求却对架构有重要影响。对架构有重要影响但却是低价值的需求，需要项目经理评估并尽可能从项目范围中移除。
• 降低风险：性能、产品可用性、以及组件的匹配性。
• 覆盖了整个架构。
• 其它战术目标或约束，如针对用户的示例，等等。

可能存在两个需求需要相同的组件或处理相似的风险。如果先实现了A，那么B就不是架构关键需求。如果先实现了B，那么A就不是架构关键需求。这依赖于需求之间的实现顺序，当这些需求变化时应当重新评估它们的顺序。

以下是优秀的架构关键需求示例：

• 系统必须记录对客户记录的每一次修改，以满足审计要求
• 系统必须在5秒内响应
• 系统必须部署在WindowXP和Linux上
• 系统必须加密所有网络流
• ATM系统发放现金前必须验证账户持有人是否有足够的资金。

架构关键需求也描述了系统需要执行的关键行为。这些场景代表了关键抽象之间的重要交互，应该被识别为架构关键需求。例如：对一个在线书店来说，描述软件处理场景“订购一本书和查看购物车”的方式，通常已足够沟通架构的本质。