备选方案文档的需求分析框架：5W + 1H + 8C

架构设计中”备选方案”文档的核心是把需求全方位描述清楚，书中给出的框架分三层。第一层是5W：Who（需求利益干系人，包括开发者、使用者、购买者、决策者等）、When（需求使用时间，包括季节、时间、里程碑等）、What（需求的产出是什么，包括系统、数据、文件、开发库、平台等）、Where（需求的应用场景，包括国家、地点、环境等，例如测试平台只会在测试环境使用）、Why（需求需要解决的问题，通常和需求背景相关）。第二层是1H（How）——这里的How不是设计方案也不是架构方案，而是关键业务流程；如果业务系统本身比较简单，1H就是几句话说清楚核心功能，如果是复杂的业务系统，这部分甚至可以独立成一份”用例文档”。第三层是8C，即8个约束和限制（Constraints）：Performance性能、Cost成本、Time时间、Reliability可靠性、Security安全性、Compliance合规性、Technology技术性、Compatibility兼容性。一个容易被忽略但很关键的提醒是：需求中涉及的性能、成本、可靠性等约束仅仅是利益关联方提出的诉求，不一定准确——如果经过分析发现某个约束没有必要，或者成本太高、难度太大，这些约束本身是可以被架构师提出来调整的，而不是照单全收当成铁律。以书中”前浪微博”消息队列为例：Who是各业务子系统；When是子系统需要发送异步通知时；What是需要开发的消息队列系统本身；Where是开发、测试、生产环境都要部署；Why是把子系统解耦、把同步调用改为异步通知；1H是”业务子系统发消息给消息队列”和”业务子系统从消息队列获取消息”两大核心功能；8C则具体列出了性能要达到Kafka水平、成本不超过10台服务器、3个月内上线第一版、可靠性99.99%、仅内网使用无需考虑网络安全（消息若含敏感信息由发送方自行加密）、按公司DevOps规范开发、团队主要用Java所以最好用Java开发、无历史系统所以无需考虑兼容性。

结构图：

flowchart TB
  A["需求分析三层框架"]
  A --> B["5W：Who/When/What/Where/Why<br/>需求全景描述"]
  A --> C["1H：How<br/>=关键业务流程(非设计方案)"]
  A --> D["8C：8个约束Constraints<br/>性能/成本/时间/可靠性/安全性/合规性/技术性/兼容性"]
  D --> E["约束不一定准确<br/>可分析后调整，不是照单全收"]