文章目录一、需求怎么来的就像盖房子前先画图纸愿景分析搞清楚要盖什么房子上下文图画出房子的边界需求分析详细规划房子要有什么功能二、如何判断掌握的需求全不全就像检查购物清单二维需求观从两个维度检查需求ADMEMS矩阵系统性地检查需求三、从需求向设计转化的关键思维是什么就像做菜功能决定架构的骨架质量完善架构的血肉约束限制架构的选择总结回答三个核心问题核心观点需求开发就像盖房子前先画图纸必须搞清楚要盖什么房子愿景分析和房子要有什么功能需求分析。判断需求全不全就看功能、质量、约束三类需求是否都覆盖了。从需求到设计的转化关键在于理解这三类需求影响架构的不同方式——功能决定架构的骨架质量完善架构的血肉约束限制架构的选择。很多架构师对需求开发存在三个核心困惑需求怎么来的就像盖房子前要先知道要盖什么房子一样需求开发 愿景分析 需求分析。如何判断掌握的需求全不全就像检查购物清单功能、质量、约束三类需求都不能漏。从需求向设计转化的关键思维是什么就像做菜功能决定要做什么菜质量决定菜的味道约束决定能用什么食材。一、需求怎么来的就像盖房子前先画图纸需求开发 愿景分析 需求分析。愿景分析回答要盖什么房子需求分析回答房子要有什么功能。想象一下盖房子的过程。在动工之前你需要先知道这房子是给谁住的要几层预算多少这就是愿景分析。然后你需要详细规划几个房间每个房间多大要不要车库这就是需求分析。愿景分析搞清楚要盖什么房子愿景分析要解决的是项目的起源问题。就像盖房子前房主和建筑师要先达成一致要盖一栋什么样的房子是别墅还是公寓预算多少什么时候要愿景分析最重要的工作成果是《愿景与范围文档》。记得有一位大师当被问及如果软件开发中只能有一份文档应当是哪一份时他毫不犹豫地回答说是《愿景文档》。由此可见《愿景与范围文档》的重要性。你可能在不同类型的软件企业工作对《愿景与范围文档》有着不同的叫法。例如有的产品型公司称为《市场需求文档》MRD有的产品型公司称为《产品需求文档》PRD有的以做项目为主的公司称为《项目立项书》。但无论叫什么名字它们的作用都是一样的明确系统要解决什么问题系统的边界在哪里。上下文图画出房子的边界上下文图就像房子的平面图清晰地标出房子的边界以及房子和周围环境的关系。在《愿景与范围文档》中上下文图Context Diagram扮演着重要角色。上下文图是一种辅助说明需求范围的方式它清晰地描述了待开发系统与周围所有事物之间的界限与联系。想象一下你要盖一栋房子。上下文图就像房子的平面图它告诉你这栋房子在哪里周围有什么和邻居的房子有什么关系但它不告诉你房子内部有几个房间每个房间怎么布置——那是后续设计的工作。上下文图有两个要点内容原则关注本系统以及和本系统有关联的因素但不关注本系统内部——既不关注内部功能也不关注内部结构。形式原则明确标识出要研发的是什么系统保持它为黑盒将它画在上下文图的中央位置其他相关因素环绕周围。例如银行综合前置系统的上下文图以综合前置系统为中心理清了和综合前置黑盒子有关联的4类系统分别是主机、外挂、第三方、渠道。就像房子的平面图它告诉你这栋房子和周围环境的关系但不告诉你房子内部的结构。需求分析详细规划房子要有什么功能需求分析就像详细规划房子的每个房间将愿景细化为可指导设计的《软件需求规格说明书》。从软件过程全局看需求分析是一个承上启下的阶段——上承愿景下接设计。上游进行愿景分析、研究可行性、输出《愿景与范围文档》需求分析要进一步完善和细化软件需求。后续要进行的设计活动以需求分析活动定义的功能需求、质量属性需求以及约束性需求等为基本参考。我们经常说的需求分析工作其背后其实涉及的活动包含需求捕获、需求分析、系统分析。这三个活动虽然名称不同但必须相互伴随、交叉进行而不能分阶段执行。将需求捕获和需求分析视为两个阶段这是错误的。就像盖房子时你不能先收集完所有需求再集中分析。而应该边收集边分析边分析边发现新需求。这种捕获得到全部需求之后再集中进行分析的做法不务实、效果差、容易引起大量需求变更。需求分析应交付一份明确的、规范的需求定义——《软件需求规格说明书》Software Requirements SpecificationSRS。《SRS》精确地阐述了一个软件系统必须提供的功能、必须达到的质量属性指标以及它必须遵守的约束。其中当前最常用的是用例Use Case技术用例图立足整个系统刻画系统能为外部用户或系统提供的服务用例规约聚焦每个功能刻画系统应提供的具体行为。二、如何判断掌握的需求全不全就像检查购物清单判断需求是否全面的标准是功能、质量、约束三类需求都不能漏。就像购物清单你不能只写买吃的还要写买什么吃的、“要新鲜的”、“预算100元”。很多程序员向架构师转型时容易陷入需求列表的思维陷阱。作为程序员你经常看到项目经理打开Excel表格根据Feature List分配工作一个程序员负责实现几项倍儿清楚。如此种种使你确信需求就是列表List。但作为架构师你会关注功能需求、质量、约束等各种需求类别更不希望因为没有需求大局观而造成需求遗漏。这时需求列表对你的架构设计工作的支持已经捉襟见肘。实践一再表明忽视质量属性和约束性需求常常导致架构设计最终失败。就像盖房子你不能只关注有几个房间功能需求还要关注房子要结实质量需求和预算有限约束需求。如果只关注功能你可能会设计出一个功能齐全但质量很差、超出预算的房子。二维需求观从两个维度检查需求二维需求观就像检查购物清单从谁要买层次和买什么方面两个维度全面梳理需求。突破需求列表思维应以二维需求观来看待需求。首先需求是分层次的。就像购物清单不同的人要买不同的东西组织级需求老板说要买办公用品预算1万元月底前要到位。这是组织级需求。用户级需求员工说要买好用的笔不要断水的。这是用户级需求。开发级需求采购员说要买能批量采购的方便管理的。这是开发级需求。其次需求还必须从不同方面进行考虑。就像购物清单你不能只写买笔还要写功能需求买什么笔圆珠笔还是钢笔质量属性要什么质量的好写的还是便宜的约束需求有什么限制预算多少什么时候要只有同时考虑层次和方面才能确保需求分析的完整性。ADMEMS矩阵系统性地检查需求ADMEMS矩阵就像购物清单的检查表系统性地检查每个层次、每个方面的需求是否都已考虑。作为设计人员经常问的一个问题是我掌握的需求全不全有没有遗漏《一线架构师实践指南》一书提出的ADMEMS矩阵又称需求层次-需求方面矩阵可以作为需求梳理和需求评审的工具以一种直观易行的Checklist思维帮助设计人员全面梳理和评价需求。ADMEMS矩阵将需求的三个层次组织级、用户级、开发级和三个方面功能、质量、约束组合成一个矩阵确保需求分析的全面性。就像购物清单的检查表你可以系统性地检查组织级的功能需求有没有用户级的质量需求有没有开发级的约束需求有没有只有全面覆盖这九个维度才能确保需求分析的完整性。三、从需求向设计转化的关键思维是什么就像做菜从需求向设计转化的关键思维是功能、质量、约束影响架构的不同原理是核心。功能决定架构的骨架要做什么菜质量完善架构的血肉菜的味道约束限制架构的选择能用什么食材。不重视需求设计必死。对需求的重视停留在口头却不能体现到设计中设计也会死。我们都知道整个设计过程中的关键一环是从需求向设计的转化或过渡。少了这一环“重视需求就是一句口号需求和设计就是两层皮”设计就沦为了拍脑袋。功能、质量、约束影响架构的方式完全不同只有理解了这些不同的原理才能进行理性设计而非拍脑袋。就像做菜你不能只考虑要做什么菜功能还要考虑菜要好吃质量和能用什么食材约束。这三者影响做菜的方式完全不同。功能决定架构的骨架功能通过职责协作链影响架构就像做菜时功能决定要做什么菜然后决定需要哪些食材和工具。任何一项功能都是由一条特定的职责协作链完成的。作为完整的软件系统它在支持每一个具体功能时都必然涉及软件不同部分之间的相互配合。系统的控制权在这些不同的部分之间来回传递形成一条职责协作链可以完成非常复杂的功能。就像做菜你要做一道宫保鸡丁需要准备食材鸡肉、花生、辣椒→切菜→炒菜→装盘。每一步都需要不同的部分工具、食材、技能配合形成一条职责协作链。反过来在设计架构时就是要通过为功能规划职责协作链来发现职责再将职责分配到子系统等软件单元中去后续就可以定义接口确定协作方式了。这意味着功能需求是架构设计的起点通过分析功能的职责协作链我们可以发现系统需要哪些软件单元以及这些单元之间如何协作。质量完善架构的血肉质量是完善架构设计的驱动力就像做菜时质量要求菜要好吃会推动你调整做菜的方法。质量是完善架构设计的驱动力不考虑质量的系统是无法走出实验室的。基于中间设计成果进一步质疑是其中基本的思维方式。例如如果只考虑功能页面缓存的设计就永远不会被引入它是质疑性能、调整设计的结果。就像做菜你做了第一版宫保鸡丁但发现不够香。于是你调整做法先炒花生再炒鸡丁最后一起炒。这就是质量要求推动你完善做菜方法。必须注意第一抛开功能、单依据质量要求是不可能设计出架构的。就像你不能只说要好吃而不说要做什么菜。第二实际的设计过程是质量是一种评价、一种针对已然存在的设计的评价我们基于当前的架构设计中间成果进一步考虑具体质量要求对设计中间成果进行细化、调整、甚至推倒重来。这意味着质量需求不是架构设计的起点而是完善架构设计的驱动力它推动我们在已有设计基础上不断优化。约束限制架构的选择约束需求以直接制约、转化为功能需求、转化为质量属性需求三种方式影响架构设计就像做菜时约束能用什么食材会限制你的选择。设计并不自由。对于架构设计而言来自方方面面的约束性需求中潜藏了大量风险因素。所以有经验的架构师都懂得主动分析约束影响、识别架构影响因素以便在架构设计中引入相应决策予以应对。就像做菜你不能想用什么食材就用什么。如果预算有限你不能用昂贵的食材如果厨房设备有限你不能做需要特殊设备的菜。约束需求以不同的具体方式影响架构设计直接制约设计决策的约束。例如“系统运行于UNIX平台之上作为一条约束架构师直接遵守即可。就像只能用现有的锅”你直接遵守就行。转化为功能需求的约束。例如本银行系统必须严格执行人民银行统一规定的利率是一条约束但分析后发现正是它引出了一条功能需求即必须提供调整利率设置的实用功能。就像不能用猪肉这个约束引出了要用鸡肉这个功能需求。转化为质量属性需求的约束。例如有经验的系统分析员发现了一条重要约束“任职于各储蓄所和分理处的柜员计算机水平普遍不高”。由此未来的软件系统必须具有很高的易用性否则不会用和鲁棒性否则可能把系统搞瘫痪了就是非常必要的。就像厨房很小这个约束引出了要简单易做这个质量要求。这意味着约束需求对架构设计的影响是多样化的架构师不能简单地遵守约束而要主动分析约束可能带来的影响并采取相应的设计决策。总结回答三个核心问题需求开发是架构设计的基础本文围绕三个核心问题展开1. 需求怎么来的需求开发 愿景分析 需求分析。就像盖房子前先画图纸愿景分析回答要盖什么房子需求分析回答房子要有什么功能。通过上下文图明确系统边界通过需求捕获、需求分析、系统分析三个相互伴随的活动将愿景转化为具体的需求规格。2. 如何判断掌握的需求全不全功能、质量、约束三类需求都不能漏。就像检查购物清单不能只写买吃的还要写买什么吃的、“要新鲜的”、“预算100元”。通过二维需求观层次×方面和ADMEMS矩阵系统性地梳理和检查需求。需求分三个层次组织级、用户级、开发级分三个方面功能、质量、约束只有全面覆盖这九个维度才能确保需求分析的完整性。3. 从需求向设计转化的关键思维是什么功能、质量、约束影响架构的不同原理是核心。就像做菜功能决定要做什么菜决定架构的骨架质量决定菜的味道完善架构的血肉约束决定能用什么食材限制架构的选择。只有理解了这三者影响架构的不同方式才能进行理性设计而非拍脑袋。架构师必须全面了解需求不能只关注功能需求而忽视质量和约束。只有通过ADMEMS矩阵等工具全面梳理需求理解功能、质量、约束影响架构的不同原理才能设计出合适的软件架构。这意味着需求开发不是简单的文档编写工作而是架构设计的基础和前提只有做好了需求开发才能设计出真正合适的软件架构。参考《软件架构设计》—温昱