需求开发：从愿景到规格的完整路径

核心观点：需求开发就像盖房子前先画图纸，必须搞清楚"要盖什么房子"（愿景分析）和"房子要有什么功能"（需求分析）。判断需求全不全，就看功能、质量、约束三类需求是否都覆盖了。从需求到设计的转化，关键在于理解这三类需求影响架构的不同方式——功能决定架构的骨架，质量完善架构的血肉，约束限制架构的选择。

很多架构师对需求开发存在三个核心困惑：

1. 需求怎么来的？ 就像盖房子前要先知道"要盖什么房子"一样，需求开发 = 愿景分析 + 需求分析。
2. 如何判断掌握的需求全不全？ 就像检查购物清单，功能、质量、约束三类需求都不能漏。
3. 从需求向设计转化的关键思维是什么？ 就像做菜，功能决定要做什么菜，质量决定菜的味道，约束决定能用什么食材。

一、需求怎么来的？就像盖房子前先画图纸

需求开发 = 愿景分析 + 需求分析。愿景分析回答"要盖什么房子"，需求分析回答"房子要有什么功能"。

想象一下盖房子的过程。在动工之前，你需要先知道：这房子是给谁住的？要几层？预算多少？这就是愿景分析。然后，你需要详细规划：几个房间？每个房间多大？要不要车库？这就是需求分析。

愿景分析：搞清楚"要盖什么房子"

愿景分析要解决的是项目的起源问题。就像盖房子前，房主和建筑师要先达成一致：要盖一栋什么样的房子？是别墅还是公寓？预算多少？什么时候要？

愿景分析最重要的工作成果是《愿景与范围文档》。记得有一位大师，当被问及"如果软件开发中只能有一份文档，应当是哪一份"时，他毫不犹豫地回答说是《愿景文档》。由此可见《愿景与范围文档》的重要性。

你可能在不同类型的软件企业工作，对《愿景与范围文档》有着不同的叫法。例如：有的产品型公司，称为《市场需求文档》（MRD）；有的产品型公司，称为《产品需求文档》（PRD）；有的以做项目为主的公司，称为《项目立项书》。但无论叫什么名字，它们的作用都是一样的：明确系统要解决什么问题，系统的边界在哪里。

上下文图：画出房子的边界

上下文图就像房子的平面图，清晰地标出房子的边界，以及房子和周围环境的关系。

在《愿景与范围文档》中，上下文图（Context Diagram）扮演着重要角色。上下文图是一种"辅助说明"需求范围的方式，它清晰地描述了待开发系统与周围所有事物之间的界限与联系。

想象一下，你要盖一栋房子。上下文图就像房子的平面图，它告诉你：这栋房子在哪里？周围有什么？和邻居的房子有什么关系？但它不告诉你房子内部有几个房间，每个房间怎么布置——那是后续设计的工作。

上下文图有两个要点：

1. 内容原则：关注本系统，以及和本系统有关联的因素，但不关注本系统内部——既不关注内部功能，也不关注内部结构。

2. 形式原则：明确标识出要研发的是什么系统，保持它为黑盒，将它画在上下文图的中央位置，其他相关因素环绕周围。

例如，银行"综合前置系统"的上下文图，以"综合前置系统"为中心，理清了和综合前置黑盒子有关联的4类系统，分别是主机、外挂、第三方、渠道。就像房子的平面图，它告诉你这栋房子和周围环境的关系，但不告诉你房子内部的结构。
 

需求分析：详细规划"房子要有什么功能"

需求分析就像详细规划房子的每个房间，将愿景细化为可指导设计的《软件需求规格说明书》。

从软件过程全局看，需求分析是一个承上启下的阶段——"上承"愿景，"下接"设计。上游，进行愿景分析、研究可行性、输出《愿景与范围文档》，需求分析要进一步完善和细化软件需求。后续，要进行的设计活动，以需求分析活动定义的功能需求、质量属性需求以及约束性需求等为基本参考。

我们经常说的"需求分析"工作，其背后其实涉及的活动包含：需求捕获、需求分析、系统分析。这三个活动虽然名称不同，但必须相互伴随、交叉进行，而不能分阶段执行。

将需求捕获和需求分析视为两个阶段，这是错误的。 就像盖房子时，你不能先收集完所有需求，再集中分析。而应该边收集边分析，边分析边发现新需求。这种"捕获得到全部需求，之后再集中进行分析"的做法不务实、效果差、容易引起大量需求变更。

需求分析应交付一份明确的、规范的需求定义——《软件需求规格说明书》（Software Requirements Specification，SRS）。《SRS》精确地阐述了一个软件系统必须提供的功能、必须达到的质量属性指标，以及它必须遵守的约束。其中，当前最常用的是用例（Use Case）技术，用例图"立足整个系统"刻画系统能为外部用户或系统提供的服务，用例规约"聚焦每个功能"刻画系统应提供的具体行为。
 

二、如何判断掌握的需求全不全？就像检查购物清单

判断需求是否全面的标准是：功能、质量、约束三类需求都不能漏。就像购物清单，你不能只写"买吃的"，还要写"买什么吃的"、“要新鲜的”、“预算100元”。

很多程序员向架构师转型时，容易陷入"需求列表"的思维陷阱。作为程序员，你经常看到项目经理打开Excel表格，根据"Feature List"分配工作，一个程序员负责实现几项，倍儿清楚。如此种种，使你确信需求就是列表（List）。

但作为架构师，你会关注功能需求、质量、约束等各种需求类别，更不希望因为没有"需求大局观"而造成需求遗漏。这时，需求列表对你的架构设计工作的支持已经捉襟见肘。

实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。 就像盖房子，你不能只关注"有几个房间"（功能需求），还要关注"房子要结实"（质量需求）和"预算有限"（约束需求）。如果只关注功能，你可能会设计出一个功能齐全但质量很差、超出预算的房子。

二维需求观：从两个维度检查需求

二维需求观就像检查购物清单，从"谁要买"（层次）和"买什么"（方面）两个维度全面梳理需求。

突破"需求列表"思维，应以"二维需求观"来看待需求。

首先，需求是分层次的。就像购物清单，不同的人要买不同的东西：

• 组织级需求：老板说"要买办公用品，预算1万元，月底前要到位"。这是组织级需求。
• 用户级需求：员工说"要买好用的笔，不要断水的"。这是用户级需求。
• 开发级需求：采购员说"要买能批量采购的，方便管理的"。这是开发级需求。

其次，需求还必须从不同方面进行考虑。就像购物清单，你不能只写"买笔"，还要写：

• 功能需求：买什么笔？圆珠笔还是钢笔？
• 质量属性：要什么质量的？好写的还是便宜的？
• 约束需求：有什么限制？预算多少？什么时候要？

只有同时考虑层次和方面，才能确保需求分析的完整性。

 

ADMEMS矩阵：系统性地检查需求

ADMEMS矩阵就像购物清单的检查表，系统性地检查每个层次、每个方面的需求是否都已考虑。

作为设计人员，经常问的一个问题是：我掌握的需求全不全，有没有遗漏？《一线架构师实践指南》一书提出的ADMEMS矩阵（又称"需求层次-需求方面矩阵"）可以作为需求梳理和需求评审的工具，以一种直观易行的"Checklist思维"帮助设计人员全面梳理和评价需求。

ADMEMS矩阵将需求的三个层次（组织级、用户级、开发级）和三个方面（功能、质量、约束）组合成一个矩阵，确保需求分析的全面性。就像购物清单的检查表，你可以系统性地检查：组织级的功能需求有没有？用户级的质量需求有没有？开发级的约束需求有没有？只有全面覆盖这九个维度，才能确保需求分析的完整性。

 

三、从需求向设计转化的关键思维是什么？就像做菜

从需求向设计转化的关键思维是：功能、质量、约束影响架构的不同原理是核心。功能决定架构的骨架（要做什么菜），质量完善架构的血肉（菜的味道），约束限制架构的选择（能用什么食材）。

不重视需求，设计必死。对需求的重视停留在口头，却不能体现到设计中，设计也会死。我们都知道，整个设计"过程"中的关键一环是从需求向设计的"转化"或"过渡"。少了这一环，“重视需求"就是一句口号，需求和设计就是"两层皮”，设计就沦为了"拍脑袋"。

功能、质量、约束影响架构的方式完全不同，只有理解了这些不同的原理，才能进行"理性设计"而非"拍脑袋"。 就像做菜，你不能只考虑"要做什么菜"（功能），还要考虑"菜要好吃"（质量）和"能用什么食材"（约束）。这三者影响做菜的方式完全不同。

功能：决定架构的骨架

功能通过职责协作链影响架构，就像做菜时，功能决定要做什么菜，然后决定需要哪些食材和工具。

任何一项功能都是由一条特定的"职责协作链"完成的。作为完整的软件系统，它在支持每一个具体功能时，都必然涉及软件不同"部分"之间的相互配合。系统的控制权在这些不同的"部分"之间来回传递，形成一条"职责协作链"，可以完成非常复杂的功能。

就像做菜，你要做一道"宫保鸡丁"，需要：准备食材（鸡肉、花生、辣椒）→切菜→炒菜→装盘。每一步都需要不同的"部分"（工具、食材、技能）配合，形成一条"职责协作链"。

反过来，在设计架构时，就是要通过为功能规划职责协作链来发现职责，再将职责分配到子系统等软件单元中去，后续就可以定义接口，确定协作方式了。这意味着功能需求是架构设计的起点，通过分析功能的职责协作链，我们可以发现系统需要哪些软件单元，以及这些单元之间如何协作。

 

质量：完善架构的血肉

质量是完善架构设计的驱动力，就像做菜时，质量要求（菜要好吃）会推动你调整做菜的方法。

质量，是完善架构设计的驱动力，不考虑质量的系统是无法走出实验室的。基于中间设计成果进一步质疑是其中基本的"思维方式"。例如，如果只考虑功能，"页面缓存"的设计就永远不会被引入，它是质疑性能、调整设计的结果。

就像做菜，你做了第一版"宫保鸡丁"，但发现不够香。于是你调整做法：先炒花生，再炒鸡丁，最后一起炒。这就是质量要求推动你完善做菜方法。

必须注意：
第一，抛开功能、单依据质量要求，是不可能设计出架构的。就像你不能只说"要好吃"，而不说"要做什么菜"。
第二，实际的设计过程是，质量是一种评价、一种针对"已然存在"的设计的评价，我们基于当前的架构设计中间成果，进一步考虑具体质量要求，对设计中间成果进行细化、调整、甚至推倒重来。

这意味着质量需求不是架构设计的起点，而是完善架构设计的驱动力，它推动我们在已有设计基础上不断优化。

 

约束：限制架构的选择

约束需求以直接制约、转化为功能需求、转化为质量属性需求三种方式影响架构设计，就像做菜时，约束（能用什么食材）会限制你的选择。

设计并不自由。对于架构设计而言，来自方方面面的约束性需求中潜藏了大量风险因素。所以，有经验的架构师都懂得主动分析约束影响、识别架构影响因素，以便在架构设计中引入相应决策予以应对。

就像做菜，你不能想用什么食材就用什么。如果预算有限，你不能用昂贵的食材；如果厨房设备有限，你不能做需要特殊设备的菜。

约束需求以不同的具体方式影响架构设计：

• 直接制约设计决策的约束。例如，“系统运行于UNIX平台之上"作为一条约束，架构师直接遵守即可。就像"只能用现有的锅”，你直接遵守就行。

• 转化为功能需求的约束。例如，"本银行系统必须严格执行人民银行统一规定的利率"是一条约束，但分析后发现，正是它引出了一条功能需求，即必须提供调整利率设置的实用功能。就像"不能用猪肉"这个约束，引出了"要用鸡肉"这个功能需求。

• 转化为质量属性需求的约束。例如，有经验的系统分析员发现了一条重要约束：“任职于各储蓄所和分理处的柜员，计算机水平普遍不高”。由此，未来的软件系统必须具有很高的易用性（否则不会用）和鲁棒性（否则可能把系统搞瘫痪了）就是非常必要的。就像"厨房很小"这个约束，引出了"要简单易做"这个质量要求。

这意味着约束需求对架构设计的影响是多样化的，架构师不能简单地"遵守"约束，而要主动分析约束可能带来的影响，并采取相应的设计决策。

 

总结：回答三个核心问题

需求开发是架构设计的基础，本文围绕三个核心问题展开：

1. 需求怎么来的？ 需求开发 = 愿景分析 + 需求分析。就像盖房子前先画图纸，愿景分析回答"要盖什么房子"，需求分析回答"房子要有什么功能"。通过上下文图明确系统边界，通过需求捕获、需求分析、系统分析三个相互伴随的活动，将愿景转化为具体的需求规格。

2. 如何判断掌握的需求全不全？ 功能、质量、约束三类需求都不能漏。就像检查购物清单，不能只写"买吃的"，还要写"买什么吃的"、“要新鲜的”、“预算100元”。通过二维需求观（层次×方面）和ADMEMS矩阵，系统性地梳理和检查需求。需求分三个层次（组织级、用户级、开发级），分三个方面（功能、质量、约束），只有全面覆盖这九个维度，才能确保需求分析的完整性。

3. 从需求向设计转化的关键思维是什么？ 功能、质量、约束影响架构的不同原理是核心。就像做菜，功能决定要做什么菜（决定架构的骨架），质量决定菜的味道（完善架构的血肉），约束决定能用什么食材（限制架构的选择）。只有理解了这三者影响架构的不同方式，才能进行"理性设计"而非"拍脑袋"。

架构师必须全面了解需求，不能只关注功能需求而忽视质量和约束。只有通过ADMEMS矩阵等工具全面梳理需求，理解功能、质量、约束影响架构的不同原理，才能设计出合适的软件架构。这意味着需求开发不是简单的文档编写工作，而是架构设计的基础和前提，只有做好了需求开发，才能设计出真正合适的软件架构。