需求的三层次、三构成，及被忽视的约束条件

需求首先是分层次的：业务需求指系统出资方要达到的业务目标、预期投资和工期要求；用户需求指用户希望系统提供的功能；系统需求指系统要实现的功能范围——外部功能对应用户需求，内部功能对应系统需求，且内部功能通常是从外部功能推导出来的。需求内部还有三种构成：功能性需求描述系统能做什么，非功能性需求描述系统如何更好地完成这些功能，约束条件定义在什么条件下去实现前两者；非功能性需求又按系统所处阶段分两类——开发期（易理解性、可重用性、可测试性、可扩展性、可维护性、可移植性等）和运行期（高性能、安全性、高可用、易用性、可伸缩性、可靠性、鲁棒性、可监控性等）；约束条件涉及业务环境（预算、上线时间、法规等来自客户/出资方）、使用环境（用户年龄偏好、软硬件环境等来自用户）、构建环境（开发团队水平等来自开发/运维人员）、技术环境（技术平台、编程语言等）四类因素。这里有一个关键的架构设计洞察：功能性需求决定系统能否完成预期工作，但往往并不决定系统的架构——系统架构与功能性通常是正交的；真正更多影响架构设计的是非功能性需求。而约束条件是最容易被忽视的一环——大家通常熟悉功能性和非功能性需求，却容易忘了约束条件同样必不可少：实现需求时资源永远是有限的，约束条件正是用来划定这个资源边界的，告诉架构师”在什么资源边界内去完成功能性和非功能性需求”。可迁移启发：审查一份需求文档是否完整，除了检查功能性需求和非功能性需求是否齐全，一定要单独确认约束条件是否被明确写出来了——一份只谈”要做什么、要做多好”却不谈”在什么资源限制下做”的需求文档，本质上是不完整的，后续架构设计很容易因为撞上未被言明的预算/时间/法规红线而推倒重来。

结构图：

flowchart TB
  L["需求三层次"]
  L --> L1["业务需求(出资方目标/预期投资/工期)"]
  L --> L2["用户需求(对应外部功能)"]
  L --> L3["系统需求(对应内部功能,由外部功能推导)"]
  C["需求三构成"]
  C --> C1["功能性需求:系统能做什么<br/>(不决定架构,与架构正交)"]
  C --> C2["非功能性需求:如何更好完成<br/>(更多影响架构设计,分开发期/运行期)"]
  C --> C3["约束条件:资源边界<br/>(业务/使用/构建/技术环境,最易被忽视)"]