[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:zh":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:zh":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:zh:1":2049},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","zh","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":2048},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1031,"featuredImage":1032,"featuredImageAlt":1033,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1034,"publishedAt":1035,"createdAt":1036,"updatedAt":1037,"seoLocalePaths":1038,"categories":1047,"author":1068,"translations":1073},"482","ADR 与 NFR：架构决策与系统质量并非同一回事","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>\u003Cstrong>非功能需求（NFR）\u003C\u002Fstrong>描述了系统预期满足的质量、约束或运行条件。\u003Cstrong>架构决策记录（ADR）\u003C\u002Fstrong>记录了为响应需求、约束、风险和权衡而做出的具有架构重要性的选择。它们相互关联，但不可互换：NFR 陈述必须为真的事项；ADR 解释决定了什么、为什么以及带来什么后果。\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">直接回答\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>NFR = 所需的系统质量或约束。ADR = 记录的架构决策。\u003C\u002Fstrong>延迟目标、可用性目标、隔离规则、部署限制或可维护性要求都可能影响架构。ADR 随后记录为解决一个或多个此类驱动因素而做出的重要选择。ADR 不能替代需求，且 ADR 的存在并不能证明需求已得到满足。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">术语和标准说明\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>NFR\u003C\u002Fstrong> 这一术语被广泛使用，但并未完全标准化。本文将其作为质量需求和相关约束的实用简称。当前标准已于 \u003Cstrong>2026年10月8日\u003C\u002Fstrong> 重新核查：ISO\u002FIEC\u002FIEEE 29148:2018 仍然现行但正在修订中；ISO\u002FIEC 25010:2023 和 ISO\u002FIEC\u002FIEEE 42010:2022 是此处引用的当前已发布版本。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"目录\">\u003Cstrong class=\"editorjs-toc__title\">目录\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-5\" class=\"editorjs-toc__link\">NFR 和 ADR 有什么区别？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">从精确的架构角度来说，什么是 NFR？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-16\" class=\"editorjs-toc__link\">什么是架构决策记录？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-21\" class=\"editorjs-toc__link\">最简单的例子：延迟需求 → 架构决策\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-26\" class=\"editorjs-toc__link\">NFR 和 ADR 通常具有多对多关系\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-30\" class=\"editorjs-toc__link\">技术选择并不自动成为需求\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-34\" class=\"editorjs-toc__link\">ADR 不是 NFR 已满足的证明\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-38\" class=\"editorjs-toc__link\">非功能需求何时变得具有架构意义？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-42\" class=\"editorjs-toc__link\">更强的架构模型：需求 → 决策 → 实现 → 验证\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">实现证据：我如何在 SenseFlow 中区分需求与决策\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-52\" class=\"editorjs-toc__link\">企业项目背景：需求应先于架构选择\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">当ADR和NFR混在一起时的常见失败模式\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-57\" class=\"editorjs-toc__link\">ADR–NFR决策框架\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">ADR和NFR不是什么\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-62\" class=\"editorjs-toc__link\">什么会改变这个答案？\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">局限性\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-70\" class=\"editorjs-toc__link\">结论\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-74\" class=\"editorjs-toc__link\">常见问题\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-76\" class=\"editorjs-toc__link\">术语表\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-78\" class=\"editorjs-toc__link\">主要来源与实施证据\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-5\">NFR 和 ADR 有什么区别？\u003C\u002Fh2>\n\u003Cp>最简单的区别在于语法。需求描述系统必须满足的条件。决策记录描述团队做出的选择。\u003C\u002Fp>\n\u003Cp>例如，\u003Cstrong>“在约定的参考负载下，API 必须在 300 毫秒内返回 95% 的读请求”\u003C\u002Fstrong> 是一项质量需求。\u003Cstrong>“对此工作负载使用读穿透缓存，因为仅使用数据库的实测路径无法在不产生不可接受成本的情况下满足延迟目标”\u003C\u002Fstrong> 是一项架构决策。\u003C\u002Fp>\n\u003Cp>即使实现发生变化，第一条陈述仍然有效。如果工作负载、技术、成本模型或证据发生变化，第二条陈述以后可能被另一项决策取代。\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">NFR 和 ADR 回答不同的问题\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">NFR \u002F 质量需求\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">ADR \u002F 架构决策\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">主要问题\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What quality, constraint, or operating condition must the system satisfy?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">What architecturally significant choice did we make, and why?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">典型内容\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurable target, scope, condition, constraint, acceptance or validation rule\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Context, decision, rationale, alternatives, trade-offs, status and consequences\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">生命周期角色\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A requirement to design for and validate\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A historical record of a significant decision\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">什么能证明它？\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Measurement, test, analysis, inspection, audit or other validation evidence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The record proves what was decided, not that the resulting system meets the requirement\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">何时变化\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When stakeholder need, operating conditions, policy or quality target changes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">When the decision is replaced, rejected, deprecated, or superseded\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-10\">从精确的架构角度来说，什么是 NFR？\u003C\u002Fh2>\n\u003Cp>“非功能需求”是一个方便的行业标签，但它可能掩盖几种不同类型的陈述。在架构工作中，有用的区分是\u003Cstrong>功能行为\u003C\u002Fstrong>、\u003Cstrong>质量需求\u003C\u002Fstrong>和\u003Cstrong>约束\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 25010:2023 提供了一个产品质量模型，包含九个特性和子特性，可用于规定和评估 ICT 及软件产品质量。SEI 架构工作同样将质量属性需求视为软件架构的主要驱动因素。\u003C\u002Fp>\n\u003Cp>因此，有用的 NFR 不是“系统应该快”或“平台必须安全”。这些陈述只是命名了愿望。驱动架构的需求应使预期属性足够可测试，以便能够根据它评估设计替代方案和后续证据。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">弱陈述\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">更有用的需求形式\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">为什么差异很重要\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">API 必须快\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">对于工作负载 W，操作 X 的 95% 在 T 毫秒内完成\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">定义了工作负载、操作、指标和阈值\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">服务必须可用\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">服务 S 在测量窗口 M 内满足约定的可用性目标，排除明确定义的维护条件\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">使可用性可衡量并定义了范围\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">租户数据必须安全\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">为租户 A 认证的请求绝不能通过受支持的应用程序路径检索或修改租户 B 的数据\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">将模糊的安全目标转化为隔离属性\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">系统应该可扩展\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">系统在并发 C 下支持工作负载 W，同时满足延迟和错误率阈值\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">将扩展性与可衡量的服务行为联系起来\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">我们需要 PostgreSQL\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">本身不是 NFR；首先陈述所需的持久化质量或外部约束\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">技术选择通常是解决方案，而不是它旨在满足的需求\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">需求应在机制之前描述需要\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">如果“使用 Kubernetes”、“使用 PostgreSQL”、“使用微服务”或“使用向量搜索”作为需求出现，请问它是否真的是外部约束，或者解决方案是否在底层质量需求被明确之前就已经写下来了。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-16\">什么是架构决策记录？\u003C\u002Fh2>\n\u003Cp>架构决策记录是对重要架构决策的简洁记录。Michael Nygard 最初的 ADR 表述强调\u003Cstrong>上下文\u003C\u002Fstrong>、\u003Cstrong>决策\u003C\u002Fstrong>、其\u003Cstrong>状态\u003C\u002Fstrong>以及由此产生的\u003Cstrong>后果\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Cp>重要的对象是决策，而不是模板。不同团队使用不同的 ADR 格式。更丰富的记录还可以保留替代方案、决策标准、权衡、证据、与需求的链接，以及决策适用的日期或版本。\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC\u002FIEEE 42010:2022 比 ADR 实践范围更广：它规定了架构描述及其概念的要求，同时明确不规定记录架构描述的单一过程、符号、工具、格式或媒介。因此，ADR 是一种实用的决策记录技术，而不是 ISO 42010 强制要求的格式。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">ADR 字段\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">它保留的内容\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">为什么重要\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">上下文\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">围绕选择的问题、力量、需求、假设和环境\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">未来的读者可以重建为什么这个选择是必要的\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">成为权威的选择\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">将选定的选项与讨论分开\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">状态\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">提议、接受、拒绝、弃用、取代或其他受控状态\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">防止旧决策悄然保持活跃\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">备选方案\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">考虑过的其他可行选项\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">表明所选解决方案并非唯一可想象的方案\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">理由 \u002F 权衡\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">为什么选择该选项以及它放弃了什么\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">使架构推理可被检查\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">后果\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">预期的正面和负面影响、后续工作、风险\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">将局部选择与系统影响联系起来\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">日期 \u002F 版本\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策何时生效\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">支持历史可追溯性和后续取代\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-21\">最简单的例子：延迟需求 → 架构决策\u003C\u002Fh2>\n\u003Cp>假设产品负责人和工程团队一致认为，在定义的参考工作负载下，搜索端点必须在第 95 百分位内于 400 毫秒内返回第一页结果。\u003C\u002Fp>\n\u003Cp>该目标不是 ADR。它是一个质量需求。架构工作始于询问在系统的其他约束下，什么设计可以满足它。\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">从需求到证据\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. 陈述需求\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">定义质量目标、工作负载、范围、阈值和验证方法。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. 识别架构重要性\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">确定该需求是否实质性地影响结构、技术、部署、数据流或运营模式。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. 评估选项\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">比较索引、缓存、反规范化、异步工作、分区或不同查询架构等备选方案。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. 记录决策\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">在 ADR 中记录所选的架构选择、理由、备选方案、权衡、状态和后果。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. 实施\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">将决策转化为代码、基础设施、配置和运营行为。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. 验证\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">根据原始需求测量真实系统。测试结果验证 NFR；仅 ADR 本身不能验证。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">简单示例止步之处\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">真实系统很少只有一个需求和一个决策。性能可能与成本、一致性、可运维性、安全性、可维护性、能源使用或交付风险进行权衡。因此，有用的模型是可追溯性图，而不是一对一的映射。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-26\">NFR 和 ADR 通常具有多对多关系\u003C\u002Fh2>\n\u003Cp>一个质量需求可以驱动多个架构决策。例如，租户隔离需求可以影响身份传播、数据库作用域、后台作业设计、缓存键、审计日志和管理工具。\u003C\u002Fp>\n\u003Cp>一个架构决策也可以同时响应多个需求。选择异步处理边界可能会提高响应能力和故障隔离，同时引入一致性、复杂性、可观测性和运营权衡。\u003C\u002Fp>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">为什么关系不是一对一的\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">需求侧\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">决策侧\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">验证侧\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">一个 NFR → 多个 ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A broad quality target can constrain several architectural boundaries\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several coordinated decisions may be required\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence may need multiple tests or measurements\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">多个 NFR → 一个 ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Several quality and constraint drivers can point at the same design problem\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">One decision may balance several drivers\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Each requirement still needs its own acceptance evidence\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">没有经典 NFR 的 ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The choice can still be architecturally significant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Validate against the actual driver, not an invented NFR\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">需求稳定，ADR 变化\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The target can remain unchanged\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A better or necessary implementation choice can supersede the old decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The new architecture must still be checked against the same target\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-30\">技术选择并不自动成为需求\u003C\u002Fh2>\n\u003Cp>一个反复出现的架构错误是将首选技术写入需求层，然后将由此产生的设计视为不可避免。\u003C\u002Fp>\n\u003Cp>如果合同、平台政策、兼容性要求、许可规则、组织标准或现有运营边界确实强制要求 PostgreSQL，那么“系统必须使用 PostgreSQL”可以是一个合法约束。但如果真正的需求是事务一致性、结构化查询、运营熟悉度或特定的恢复目标，需求应陈述该需求，技术选择应记录为决策。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">陈述\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">分类\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">原因\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">所有租户范围的读取必须强制租户隔离\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">需求 \u002F 安全属性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">描述必须保持的属性\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">对选定的租户范围表使用 PostgreSQL 行级安全\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">选择一种旨在帮助满足隔离属性的机制\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">部署目标必须在经批准的欧盟运营环境中运行\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">约束 \u002F 类似 NFR 的运营条件\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">限制系统可以在哪里运行\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在区域 Y 使用提供商 X\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构 \u002F 部署决策，除非外部强制要求\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在允许的边界内选择特定解决方案\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在工作负载 W 下，第 95 百分位 API 延迟 ≤ 300 毫秒\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">质量需求\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">定义可测量的性能行为\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">为端点 X 引入缓存\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">选择一种旨在改善测量行为的策略\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-34\">ADR 不是 NFR 已满足的证明\u003C\u002Fh2>\n\u003Cp>决策文档和系统验证回答不同的问题。ADR 可以表明性能、安全性、弹性或可维护性已被考虑。它本身不能证明交付的系统实际实现了这些属性。\u003C\u002Fp>\n\u003Cp>证明必须来自适合该需求的验证方法：基准测试、负载测试、故障测试、安全测试、架构分析、审计、检查、运营遥测、恢复演练、用户研究或其他形式的证据。\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">不要将意图与证据混为一谈\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>ADR：\u003C\u002Fstrong>“我们选择设计 X，因为预期它在假设 A 下能满足需求 R。”\u003Cbr>\u003Cstrong>验证：\u003C\u002Fstrong>“测量或分析得到的证据 E 表明已实现的系统是否实际满足 R。”\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">非功能需求何时变得具有架构意义？\u003C\u002Fh2>\n\u003Cp>并非每个非功能需求都值得做出架构决策。重要的子集是那些实质性地塑造架构或迫使整个系统进行权衡的需求。\u003C\u002Fp>\n\u003Cp>SEI 文献使用\u003Cstrong>架构重要需求\u003C\u002Fstrong>这一概念来指代具有深远架构影响的需求。性能、可靠性、安全性和可修改性等质量属性是此类驱动因素的常见来源，尤其是当它们承载高业务或任务价值时。\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">架构重要性测试\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. 询问该需求是否改变结构\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">不同的取值是否会迫使产生不同的组件、边界、数据路径或部署拓扑？\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. 询问它是否约束重大技术选择\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">它是否会排除原本可行的实现选项？\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. 询问它是否产生横切行为\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">它是否影响许多组件、团队、接口或生命周期阶段？\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. 询问它是否产生困难的权衡\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">改善此属性是否会实质性地影响另一个质量、成本、进度、复杂性或风险？\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. 询问失败是否代价高昂\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">未满足该需求是否会造成重大的运营、安全、监管、财务或产品影响？\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. 仅在推理值得保留之处记录决策\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">不要为每个局部编码选择创建 ADR；保留具有架构意义的决策及其理由。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-42\">更强的架构模型：需求 → 决策 → 实现 → 验证\u003C\u002Fh2>\n\u003Cp>非功能需求与 ADR 之间最有用的联系是可追溯性。需求应能够指向处理它的架构决策；ADR 应识别它所响应的驱动因素；实现工作应落实该决策；验证应回到原始需求。\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">架构可追溯性链\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">需求 \u002F 业务目标\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">该质量或约束为何重要。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">需求 \u002F 非功能需求\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">系统必须达成或遵守什么。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">架构驱动因素\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">哪些需求重要到足以塑造设计。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">选项\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">处理该驱动因素的可行方式。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">ADR\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">所选选择、理由、替代方案、权衡和后果。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">实现\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">实现该决策的代码、数据模型、基础设施、接口和运营机制。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">验证证据\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">测试、测量、分析或审计，证明原始需求是否实际得到满足。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">变更 \u002F 取代\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">新证据或需求变化可以触发新的 ADR，同时保留历史推理。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-45\">实现证据：我如何在 SenseFlow 中区分需求与决策\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">原始实现 \u002F 项目证据\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">以下部分描述我自己的 SenseFlow 项目结构。它是本文所述区分的实现证据，并非声称每个团队都必须使用相同的文档模型。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>在 SenseFlow 中，项目的事实来源明确将非功能需求置于需求结构内，与依赖关系、风险、假设、验收标准和验证方法放在一起。文档模型另行定义了重大决策的决策完整性。\u003C\u002Fp>\n\u003Cp>对于 SenseFlow 的重大决策，记录的字段为\u003Cstrong>决策、原因、替代方案、权衡、状态和日期 \u002F 版本\u003C\u002Fstrong>。重大架构和产品决策旨在保持历史可追溯，而不是在项目演进时被覆盖。\u003C\u002Fp>\n\u003Cp>SenseFlow 还为 Confluence 和 Jira 分配了不同的运营角色。Confluence 是结构化的知识和决策环境；Jira 管理可执行的交付工作。重大 Jira Epic 应链接回相关的产品或需求文档。这保留了从产品意图到需求、决策再到实现的链条，而不是让待办事项列表成为架构的事实来源。\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">SenseFlow 层\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">包含内容\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">在 ADR\u002F非功能需求区分中的角色\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">产品 \u002F 需求结构\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">产品目标、能力、史诗、用户故事、验收标准、技术任务；需求可包含非功能需求和验证方法\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">保留必须达成什么以及如何检查成功\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策完整性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策、原因、替代方案、权衡、状态、日期\u002F版本\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">保留具有架构意义的选择为何成为权威\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confluence\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">需求、架构、研究、决策记录、风险、路线图和支持来源\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">维护概念性和历史性的事实来源\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">倡议\u002F目标、史诗、故事、任务和交付状态\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">执行已批准的工作，而不成为概念性的事实来源\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">变更管理\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">当前状态 → 新证据 → 提议变更 → 影响 → 决策\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">允许决策演进而不抹去推理轨迹\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">端到端可追溯性\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">问题 → 需求 → 价值 → 产品目标 → 需求 → 实现 → 验证\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">保持决策文档与实际产品和证据生命周期相连\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">此实现展示了什么\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">需求和决策可以紧密共存，而不会被合并为一条记录。需求仍是目标；决策仍是推理历史；交付工作实现决策；验证回到目标。\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-52\">企业项目背景：需求应先于架构选择\u003C\u002Fh2>\n\u003Cp>同样的区分在面向企业的项目工作中也很有用。在需求、风险、约束和验收条件被充分理解之前做出的架构决策，可能会将偏好变成虚假的必需品。\u003C\u002Fp>\n\u003Cp>对于 Enterprise Aaasaasa 0.1，相关教训是方法论层面的，而不是关于某个特定 ADR 的主张：需求、架构、验证、里程碑、风险管理和验收属于一个相互连接的交付系统。架构选择应保持可追溯到它旨在处理的需求或约束。\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">当ADR和NFR混在一起时的常见失败模式\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">失败模式\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">会发生什么\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">后果\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">技术伪装成需求\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">在没有确立底层需求的情况下，将首选解决方案写成“必须使用X”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">从未评估替代方案，架构被过早固定\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">NFR仅隐藏在ADR中\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">决策提到了性能\u002F安全目标，但该目标不在需求基线中\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">该目标难以独立验证、排定优先级或管理\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">将ADR视为证明\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">假设有记录的选型就意味着需求已满足\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构意图取代了测量或验证\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">模糊的NFR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">诸如快速、可扩展、安全或可维护等词语没有可度量的范围\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">不同利益相关者可能认为同一需求意味着不同的事情\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">未记录替代方案\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">团队只记录所选技术\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">未来的维护者无法重建为何其他选项被拒绝\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">没有取代模型\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">架构变更时，旧ADR被编辑或删除\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">历史推理消失，过时决策可能仍然含糊不清\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">每个实现细节都成为ADR\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">仓库中充满低价值记录\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">重要的架构选择变得难以查找\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">待办事项成为架构的唯一事实来源\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Jira任务被视为系统的唯一解释\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">交付状态得以保留，但架构理由和质量驱动因素丢失\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-57\">ADR–NFR决策框架\u003C\u002Fh2>\n\u003Cp>当团队遇到新的架构关注点时，以下顺序有助于确定什么属于需求、什么属于ADR，以及什么属于证据。\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR–NFR分类测试\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. 这是必需属性还是外部约束？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">如果是，在选择机制之前先编写或引用该需求。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. 它可以被验证吗？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">定义所需的范围、条件、度量、验收规则、分析方法或其他证据。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. 它具有架构重要性吗？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">确定该需求是否实质性地影响结构、技术、数据、部署或横切权衡。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. 是否存在有意义的替代方案？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">比较可行的策略或架构选项，而不是直接跳到首选技术。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. 某个选择是否已成为权威？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">创建或更新ADR，包含上下文、决策、理由、替代方案、权衡、状态和后果。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. 决策是否已实现？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">将ADR追溯到设计、任务、代码、配置和运维。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. 需求是否已满足？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">针对需求本身收集验证证据。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. 条件是否发生变化？\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">重新评估需求，并在必要时取代ADR而不抹除历史。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-60\">ADR和NFR不是什么\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">常见类别错误\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">概念\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">它不是\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">原因\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">NFR \u002F 质量需求\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A required quality, constraint or operating condition\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A technology shopping list\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Requirements should preserve the need independently from one implementation when possible\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">ADR\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A record of an architecturally significant decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The complete architecture description\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Architecture also needs views, interfaces, models, responsibilities and other documentation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">验证证据\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Evidence that checks whether a requirement is satisfied\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">The ADR itself\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Documented intent is different from measured or analyzed system behavior\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">待办事项\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Actionable delivery work\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A durable substitute for architecture rationale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Task state answers what is being delivered, not necessarily why the architecture exists\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">约束\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">A condition that restricts the solution space\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Always an internally chosen architecture decision\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">Some constraints come from regulation, contracts, existing platforms or organizational boundaries\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-62\">什么会改变这个答案？\u003C\u002Fh2>\n\u003Cp>术语可能会演变。截至2026年10月8日，ISO\u002FIEC\u002FIEEE 29148:2018仍是当前发布的需求工程标准，但ISO列出了一项旨在取代它的国际标准草案。如果新版更改了相关术语或需求指南，本文中特定版本的引用应予以更新。\u003C\u002Fp>\n\u003Cp>ADR模板也可以演变，而不会改变核心区别。Michael Nygard的最小模板、MADR、组织特定模板、架构知识工具或结构化决策数据库都可以记录决策。持久的问题是，该记录是否保留了足够的上下文和理由，以理解一项具有架构重要性的选择。\u003C\u002Fp>\n\u003Cp>只有当组织有意选择一种组合工件，将需求和决策数据存储在同一文档中时，这种区别才会消失。即便如此，语义角色仍然不同：一个字段陈述所需的结果或约束；另一个字段记录所选的响应。\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">局限性\u003C\u002Fh2>\n\u003Cp>本文使用\u003Cstrong>NFR\u003C\u002Fstrong>作为实用简称。一些工程方法更倾向于使用质量属性需求、质量需求、系统质量、约束、服务水平目标或架构重要需求等术语。这些术语并非完全可以互换，项目术语应明确。\u003C\u002Fp>\n\u003Cp>并非每个需求都能简化为单一数值阈值。安全性、安全、可维护性、互操作性、可用性、可解释性、可移植性和治理可能需要场景、结构规则、分析、过程控制和定性证据的组合。“可度量”应意味着对决策足够可验证，而不是人为地数字化。\u003C\u002Fp>\n\u003Cp>并非每个架构决策都需要正式的ADR。文档成本应与架构重要性、寿命、不确定性、权衡复杂性和丢失理由的成本成比例。\u003C\u002Fp>\n\u003Ch2 id=\"section-70\">结论\u003C\u002Fh2>\n\u003Cp>ADR和NFR属于架构工作的不同层次。\u003Cstrong>NFR定义质量目标、约束或运行条件。ADR记录对一个或多个驱动因素的重要架构响应。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>保持这些层次分离可以使架构更容易推理。需求可以独立于技术进行验证。决策可以被取代而无需重写历史。替代方案和权衡保持可见。交付工作可以追溯到架构意图。证据可以显示最终系统是否实际满足需求。\u003C\u002Fp>\n\u003Cp>因此，最坚固的链条不是“NFR → ADR → 完成”。而是\u003Cstrong>需求 → 要求 → 架构驱动因素 → 选项 → 决策 → 实现 → 验证 → 变更\u003C\u002Fstrong>。这条链条将架构文档从静态文书转变为可测试的记录，说明系统为何具有其现有形态。\u003C\u002Fp>\n\u003Ch2 id=\"section-74\">常见问题\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">ADR 与 NFR\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">ADR 是非功能性需求吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不是。NFR 陈述的是所需的品质、约束或运行条件。ADR 记录的是针对需求、约束、风险和权衡所做的具有架构重要性的选择。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">每个 NFR 都应该有一个 ADR 吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不是。只有对架构产生实质性影响、值得保留架构级决策的需求才需要。一个 NFR 也可以驱动多个 ADR，一个 ADR 也可以响应多个需求。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">“使用 PostgreSQL”可以是 NFR 吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">只有当 PostgreSQL 确实作为外部约束被强制要求时才可以。否则，应首先表达底层需求，而选择 PostgreSQL 通常应被视为架构决策。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">ADR 能证明性能或安全需求得到满足吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">不能。ADR 记录的是意图和推理。需求通过适当的证据来验证，例如测试、测量、分析、审计或运行遥测。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">ADR 应包含什么？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">至少，ADR 应明确说明背景和决策。常见结构还包括状态和后果。团队可以添加备选方案、理由、权衡、需求链接、证据、负责人、日期和取代关系。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">什么使 NFR 具有架构重要性？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">当需求实质性影响系统结构、技术、数据流、部署、横切行为或困难的品质权衡时，尤其是当失败会带来高业务或任务影响时，该需求就具有架构重要性。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">架构变更时，旧的 ADR 应删除吗？\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">通常不应删除。替代决策通常应取代旧记录，以便历史推理仍可追溯。\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-76\">术语表\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">核心架构术语\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"nfr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">NFR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">非功能性需求：对所需系统品质、约束或运行条件的实用简称；确切术语因方法和标准而异。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"quality-attribute-requirement\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">质量属性需求\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">描述系统在既定条件下预期表现出的质量特性的需求，例如性能、可用性、安全性、可靠性或可修改性。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">架构决策记录（ADR）\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">对具有架构重要性的决策及其足够背景的持久记录，以便理解为何做出该选择以及会产生什么后果。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"asr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">架构重要需求（ASR）\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">具有足够深远架构影响、能实质性影响系统设计的需求。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"constraint\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">约束\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">限制解决方案空间的条件，包括外部政策、法规、平台、兼容性、合同或组织边界。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"trade-off\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">权衡\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">一种设计关系，其中改善一个目标、属性或成本维度可能会使另一个变差。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"validation\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">验证\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">用于确定已实现系统在相关条件下是否满足所述需求的证据生成工作。\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"superseded-adr\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">被取代的 ADR\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">已被更新的权威决策取代、但仍可用于追溯的历史决策记录。\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-78\">主要来源与实施证据\u003C\u002Fh2>\n\u003Cp>本文将当前标准与项目实施证据区分开来。截至 2026 年 10 月 8 日，ISO\u002FIEC\u002FIEEE 29148:2018 仍然有效，但已标记为待修订；ISO\u002FIEC 25010:2023 和 ISO\u002FIEC\u002FIEEE 42010:2022 是当前已发布的版本。SenseFlow 是上述可追溯性和决策完整性模型的原创项目证据。\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 29148:2018 — 需求工程\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">当前已发布的需求工程标准。ISO 表示，2018 年版已于 2024 年审查并确认，预计将由目前正在制定的 DIS 取代。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE DIS 29148 — 需求工程\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">目前正在制定、旨在取代 ISO\u002FIEC\u002FIEEE 29148:2018 的国际标准草案。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC 25010:2023 — 产品质量模型\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">当前产品质量模型，包含九个质量特性，用于规定、测量和评估 ICT 与软件产品质量。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">ISO\u002FIEC\u002FIEEE 42010:2022 — 架构描述\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">当前架构描述标准。它规定了架构描述概念和一致性要求，但不规定单一记录格式、表示法、过程或工具。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Michael Nygard — 记录架构决策\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">具有影响力的原始 ADR 文章，描述了以背景、决策、状态和后果为中心的轻量级记录，并保留被取代的决策以便理解历史。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — 将业务目标与架构重要需求关联起来\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">SEI 报告，解释质量属性需求和业务目标如何驱动软件架构，以及为何需要明确引出架构重要需求。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — 定义非功能性系统质量\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">SEI 概述，将非功能性\u002F质量属性与架构、场景、权衡和客观系统评估联系起来。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — 属性驱动设计方法集合\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">基于功能需求、质量属性需求和约束的架构设计方法，选择架构战术和模式以满足质量场景。\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">SEI — 视图与超越集合\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">架构文档指南，强调相关视图以及将必要设计决策作为架构工作的一部分记录下来。\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1030},1791476278027,[214,219,226,232,239,243,247,251,255,299,303,307,311,315,343,349,353,357,361,365,401,405,409,413,438,444,448,452,456,497,501,505,509,540,544,548,552,557,561,565,569,592,596,600,629,633,638,642,646,650,682,687,691,695,699,703,742,746,750,779,783,827,831,835,839,843,847,851,855,859,863,867,871,875,879,912,916,948,952,956,966,974,982,990,998,1006,1014,1022],{"id":215,"data":216,"type":218},"intro",{"text":217},"\u003Cstrong>非功能需求（NFR）\u003C\u002Fstrong>描述了系统预期满足的质量、约束或运行条件。\u003Cstrong>架构决策记录（ADR）\u003C\u002Fstrong>记录了为响应需求、约束、风险和权衡而做出的具有架构重要性的选择。它们相互关联，但不可互换：NFR 陈述必须为真的事项；ADR 解释决定了什么、为什么以及带来什么后果。","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>NFR = 所需的系统质量或约束。ADR = 记录的架构决策。\u003C\u002Fstrong>延迟目标、可用性目标、隔离规则、部署限制或可维护性要求都可能影响架构。ADR 随后记录为解决一个或多个此类驱动因素而做出的重要选择。ADR 不能替代需求，且 ADR 的存在并不能证明需求已得到满足。","直接回答","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"\u003Cstrong>NFR\u003C\u002Fstrong> 这一术语被广泛使用，但并未完全标准化。本文将其作为质量需求和相关约束的实用简称。当前标准已于 \u003Cstrong>2026年10月8日\u003C\u002Fstrong> 重新核查：ISO\u002FIEC\u002FIEEE 29148:2018 仍然现行但正在修订中；ISO\u002FIEC 25010:2023 和 ISO\u002FIEC\u002FIEEE 42010:2022 是此处引用的当前已发布版本。","术语和标准说明","note",{"id":233,"data":234,"type":238},"toc",{"title":235,"maxLevel":236,"minLevel":237},"目录",3,2,"tableOfContents",{"id":240,"data":241,"type":42},"h-meaning",{"text":242,"level":237},"NFR 和 ADR 有什么区别？",{"id":244,"data":245,"type":218},"p-meaning-1",{"text":246},"最简单的区别在于语法。需求描述系统必须满足的条件。决策记录描述团队做出的选择。",{"id":248,"data":249,"type":218},"p-meaning-2",{"text":250},"例如，\u003Cstrong>“在约定的参考负载下，API 必须在 300 毫秒内返回 95% 的读请求”\u003C\u002Fstrong> 是一项质量需求。\u003Cstrong>“对此工作负载使用读穿透缓存，因为仅使用数据库的实测路径无法在不产生不可接受成本的情况下满足延迟目标”\u003C\u002Fstrong> 是一项架构决策。",{"id":252,"data":253,"type":218},"p-meaning-3",{"text":254},"即使实现发生变化，第一条陈述仍然有效。如果工作负载、技术、成本模型或证据发生变化，第二条陈述以后可能被另一项决策取代。",{"id":256,"data":257,"type":298},"basic-difference",{"rows":258,"title":289,"layout":290,"columns":291},[259,265,271,277,283],{"id":260,"label":261,"values":262},"question","主要问题",{"adr":263,"nfr":264},"What architecturally significant choice did we make, and why?","What quality, constraint, or operating condition must the system satisfy?",{"id":266,"label":267,"values":268},"content","典型内容",{"adr":269,"nfr":270},"Context, decision, rationale, alternatives, trade-offs, status and consequences","Measurable target, scope, condition, constraint, acceptance or validation rule",{"id":272,"label":273,"values":274},"lifecycle","生命周期角色",{"adr":275,"nfr":276},"A historical record of a significant decision","A requirement to design for and validate",{"id":278,"label":279,"values":280},"evidence","什么能证明它？",{"adr":281,"nfr":282},"The record proves what was decided, not that the resulting system meets the requirement","Measurement, test, analysis, inspection, audit or other validation evidence",{"id":284,"label":285,"values":286},"change","何时变化",{"adr":287,"nfr":288},"When the decision is replaced, rejected, deprecated, or superseded","When stakeholder need, operating conditions, policy or quality target changes","NFR 和 ADR 回答不同的问题","table",[292,295],{"id":293,"label":294},"nfr","NFR \u002F 质量需求",{"id":296,"label":297},"adr","ADR \u002F 架构决策","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"从精确的架构角度来说，什么是 NFR？",{"id":304,"data":305,"type":218},"p-nfr-1",{"text":306},"“非功能需求”是一个方便的行业标签，但它可能掩盖几种不同类型的陈述。在架构工作中，有用的区分是\u003Cstrong>功能行为\u003C\u002Fstrong>、\u003Cstrong>质量需求\u003C\u002Fstrong>和\u003Cstrong>约束\u003C\u002Fstrong>。",{"id":308,"data":309,"type":218},"p-nfr-2",{"text":310},"ISO\u002FIEC 25010:2023 提供了一个产品质量模型，包含九个特性和子特性，可用于规定和评估 ICT 及软件产品质量。SEI 架构工作同样将质量属性需求视为软件架构的主要驱动因素。",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"因此，有用的 NFR 不是“系统应该快”或“平台必须安全”。这些陈述只是命名了愿望。驱动架构的需求应使预期属性足够可测试，以便能够根据它评估设计替代方案和后续证据。",{"id":316,"data":317,"type":290},"nfr-examples",{"content":318,"stretched":43,"withHeadings":14},[319,323,327,331,335,339],[320,321,322],"弱陈述","更有用的需求形式","为什么差异很重要",[324,325,326],"API 必须快","对于工作负载 W，操作 X 的 95% 在 T 毫秒内完成","定义了工作负载、操作、指标和阈值",[328,329,330],"服务必须可用","服务 S 在测量窗口 M 内满足约定的可用性目标，排除明确定义的维护条件","使可用性可衡量并定义了范围",[332,333,334],"租户数据必须安全","为租户 A 认证的请求绝不能通过受支持的应用程序路径检索或修改租户 B 的数据","将模糊的安全目标转化为隔离属性",[336,337,338],"系统应该可扩展","系统在并发 C 下支持工作负载 W，同时满足延迟和错误率阈值","将扩展性与可衡量的服务行为联系起来",[340,341,342],"我们需要 PostgreSQL","本身不是 NFR；首先陈述所需的持久化质量或外部约束","技术选择通常是解决方案，而不是它旨在满足的需求",{"id":344,"data":345,"type":225},"nfr-rule",{"body":346,"title":347,"variant":348},"如果“使用 Kubernetes”、“使用 PostgreSQL”、“使用微服务”或“使用向量搜索”作为需求出现，请问它是否真的是外部约束，或者解决方案是否在底层质量需求被明确之前就已经写下来了。","需求应在机制之前描述需要","success",{"id":350,"data":351,"type":42},"h-adr",{"text":352,"level":237},"什么是架构决策记录？",{"id":354,"data":355,"type":218},"p-adr-1",{"text":356},"架构决策记录是对重要架构决策的简洁记录。Michael Nygard 最初的 ADR 表述强调\u003Cstrong>上下文\u003C\u002Fstrong>、\u003Cstrong>决策\u003C\u002Fstrong>、其\u003Cstrong>状态\u003C\u002Fstrong>以及由此产生的\u003Cstrong>后果\u003C\u002Fstrong>。",{"id":358,"data":359,"type":218},"p-adr-2",{"text":360},"重要的对象是决策，而不是模板。不同团队使用不同的 ADR 格式。更丰富的记录还可以保留替代方案、决策标准、权衡、证据、与需求的链接，以及决策适用的日期或版本。",{"id":362,"data":363,"type":218},"p-adr-3",{"text":364},"ISO\u002FIEC\u002FIEEE 42010:2022 比 ADR 实践范围更广：它规定了架构描述及其概念的要求，同时明确不规定记录架构描述的单一过程、符号、工具、格式或媒介。因此，ADR 是一种实用的决策记录技术，而不是 ISO 42010 强制要求的格式。",{"id":366,"data":367,"type":290},"adr-anatomy",{"content":368,"stretched":43,"withHeadings":14},[369,373,377,381,385,389,393,397],[370,371,372],"ADR 字段","它保留的内容","为什么重要",[374,375,376],"上下文","围绕选择的问题、力量、需求、假设和环境","未来的读者可以重建为什么这个选择是必要的",[378,379,380],"决策","成为权威的选择","将选定的选项与讨论分开",[382,383,384],"状态","提议、接受、拒绝、弃用、取代或其他受控状态","防止旧决策悄然保持活跃",[386,387,388],"备选方案","考虑过的其他可行选项","表明所选解决方案并非唯一可想象的方案",[390,391,392],"理由 \u002F 权衡","为什么选择该选项以及它放弃了什么","使架构推理可被检查",[394,395,396],"后果","预期的正面和负面影响、后续工作、风险","将局部选择与系统影响联系起来",[398,399,400],"日期 \u002F 版本","决策何时生效","支持历史可追溯性和后续取代",{"id":402,"data":403,"type":42},"h-simple-example",{"text":404,"level":237},"最简单的例子：延迟需求 → 架构决策",{"id":406,"data":407,"type":218},"p-simple-1",{"text":408},"假设产品负责人和工程团队一致认为，在定义的参考工作负载下，搜索端点必须在第 95 百分位内于 400 毫秒内返回第一页结果。",{"id":410,"data":411,"type":218},"p-simple-2",{"text":412},"该目标不是 ADR。它是一个质量需求。架构工作始于询问在系统的其他约束下，什么设计可以满足它。",{"id":414,"data":415,"type":437},"simple-flow",{"steps":416,"title":435,"orientation":436},[417,420,423,426,429,432],{"label":418,"description":419},"1. 陈述需求","定义质量目标、工作负载、范围、阈值和验证方法。",{"label":421,"description":422},"2. 识别架构重要性","确定该需求是否实质性地影响结构、技术、部署、数据流或运营模式。",{"label":424,"description":425},"3. 评估选项","比较索引、缓存、反规范化、异步工作、分区或不同查询架构等备选方案。",{"label":427,"description":428},"4. 记录决策","在 ADR 中记录所选的架构选择、理由、备选方案、权衡、状态和后果。",{"label":430,"description":431},"5. 实施","将决策转化为代码、基础设施、配置和运营行为。",{"label":433,"description":434},"6. 验证","根据原始需求测量真实系统。测试结果验证 NFR；仅 ADR 本身不能验证。","从需求到证据","auto","processFlow",{"id":439,"data":440,"type":225},"simple-stop",{"body":441,"title":442,"variant":443},"真实系统很少只有一个需求和一个决策。性能可能与成本、一致性、可运维性、安全性、可维护性、能源使用或交付风险进行权衡。因此，有用的模型是可追溯性图，而不是一对一的映射。","简单示例止步之处","warning",{"id":445,"data":446,"type":42},"h-many-many",{"text":447,"level":237},"NFR 和 ADR 通常具有多对多关系",{"id":449,"data":450,"type":218},"p-many-1",{"text":451},"一个质量需求可以驱动多个架构决策。例如，租户隔离需求可以影响身份传播、数据库作用域、后台作业设计、缓存键、审计日志和管理工具。",{"id":453,"data":454,"type":218},"p-many-2",{"text":455},"一个架构决策也可以同时响应多个需求。选择异步处理边界可能会提高响应能力和故障隔离，同时引入一致性、复杂性、可观测性和运营权衡。",{"id":457,"data":458,"type":298},"relationship-map",{"rows":459,"title":488,"layout":290,"columns":489},[460,467,474,481],{"id":461,"label":462,"values":463},"one-many","一个 NFR → 多个 ADR",{"adr":464,"nfr":465,"validation":466},"Several coordinated decisions may be required","A broad quality target can constrain several architectural boundaries","Evidence may need multiple tests or measurements",{"id":468,"label":469,"values":470},"many-one","多个 NFR → 一个 ADR",{"adr":471,"nfr":472,"validation":473},"One decision may balance several drivers","Several quality and constraint drivers can point at the same design problem","Each requirement still needs its own acceptance evidence",{"id":475,"label":476,"values":477},"non-nfr","没有经典 NFR 的 ADR",{"adr":478,"nfr":479,"validation":480},"The choice can still be architecturally significant","The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition","Validate against the actual driver, not an invented NFR",{"id":482,"label":483,"values":484},"supersession","需求稳定，ADR 变化",{"adr":485,"nfr":486,"validation":487},"A better or necessary implementation choice can supersede the old decision","The target can remain unchanged","The new architecture must still be checked against the same target","为什么关系不是一对一的",[490,492,494],{"id":293,"label":491},"需求侧",{"id":296,"label":493},"决策侧",{"id":495,"label":496},"validation","验证侧",{"id":498,"data":499,"type":42},"h-technology",{"text":500,"level":237},"技术选择并不自动成为需求",{"id":502,"data":503,"type":218},"p-tech-1",{"text":504},"一个反复出现的架构错误是将首选技术写入需求层，然后将由此产生的设计视为不可避免。",{"id":506,"data":507,"type":218},"p-tech-2",{"text":508},"如果合同、平台政策、兼容性要求、许可规则、组织标准或现有运营边界确实强制要求 PostgreSQL，那么“系统必须使用 PostgreSQL”可以是一个合法约束。但如果真正的需求是事务一致性、结构化查询、运营熟悉度或特定的恢复目标，需求应陈述该需求，技术选择应记录为决策。",{"id":510,"data":511,"type":290},"tech-table",{"content":512,"stretched":43,"withHeadings":14},[513,517,521,525,529,533,537],[514,515,516],"陈述","分类","原因",[518,519,520],"所有租户范围的读取必须强制租户隔离","需求 \u002F 安全属性","描述必须保持的属性",[522,523,524],"对选定的租户范围表使用 PostgreSQL 行级安全","架构决策","选择一种旨在帮助满足隔离属性的机制",[526,527,528],"部署目标必须在经批准的欧盟运营环境中运行","约束 \u002F 类似 NFR 的运营条件","限制系统可以在哪里运行",[530,531,532],"在区域 Y 使用提供商 X","架构 \u002F 部署决策，除非外部强制要求","在允许的边界内选择特定解决方案",[534,535,536],"在工作负载 W 下，第 95 百分位 API 延迟 ≤ 300 毫秒","质量需求","定义可测量的性能行为",[538,523,539],"为端点 X 引入缓存","选择一种旨在改善测量行为的策略",{"id":541,"data":542,"type":42},"h-adr-proof",{"text":543,"level":237},"ADR 不是 NFR 已满足的证明",{"id":545,"data":546,"type":218},"p-proof-1",{"text":547},"决策文档和系统验证回答不同的问题。ADR 可以表明性能、安全性、弹性或可维护性已被考虑。它本身不能证明交付的系统实际实现了这些属性。",{"id":549,"data":550,"type":218},"p-proof-2",{"text":551},"证明必须来自适合该需求的验证方法：基准测试、负载测试、故障测试、安全测试、架构分析、审计、检查、运营遥测、恢复演练、用户研究或其他形式的证据。",{"id":553,"data":554,"type":225},"proof-rule",{"body":555,"title":556,"variant":443},"\u003Cstrong>ADR：\u003C\u002Fstrong>“我们选择设计 X，因为预期它在假设 A 下能满足需求 R。”\u003Cbr>\u003Cstrong>验证：\u003C\u002Fstrong>“测量或分析得到的证据 E 表明已实现的系统是否实际满足 R。”","不要将意图与证据混为一谈",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"非功能需求何时变得具有架构意义？",{"id":562,"data":563,"type":218},"p-asr-1",{"text":564},"并非每个非功能需求都值得做出架构决策。重要的子集是那些实质性地塑造架构或迫使整个系统进行权衡的需求。",{"id":566,"data":567,"type":218},"p-asr-2",{"text":568},"SEI 文献使用\u003Cstrong>架构重要需求\u003C\u002Fstrong>这一概念来指代具有深远架构影响的需求。性能、可靠性、安全性和可修改性等质量属性是此类驱动因素的常见来源，尤其是当它们承载高业务或任务价值时。",{"id":570,"data":571,"type":437},"asr-test",{"steps":572,"title":591,"orientation":436},[573,576,579,582,585,588],{"label":574,"description":575},"1. 询问该需求是否改变结构","不同的取值是否会迫使产生不同的组件、边界、数据路径或部署拓扑？",{"label":577,"description":578},"2. 询问它是否约束重大技术选择","它是否会排除原本可行的实现选项？",{"label":580,"description":581},"3. 询问它是否产生横切行为","它是否影响许多组件、团队、接口或生命周期阶段？",{"label":583,"description":584},"4. 询问它是否产生困难的权衡","改善此属性是否会实质性地影响另一个质量、成本、进度、复杂性或风险？",{"label":586,"description":587},"5. 询问失败是否代价高昂","未满足该需求是否会造成重大的运营、安全、监管、财务或产品影响？",{"label":589,"description":590},"6. 仅在推理值得保留之处记录决策","不要为每个局部编码选择创建 ADR；保留具有架构意义的决策及其理由。","架构重要性测试",{"id":593,"data":594,"type":42},"h-traceability",{"text":595,"level":237},"更强的架构模型：需求 → 决策 → 实现 → 验证",{"id":597,"data":598,"type":218},"p-trace-1",{"text":599},"非功能需求与 ADR 之间最有用的联系是可追溯性。需求应能够指向处理它的架构决策；ADR 应识别它所响应的驱动因素；实现工作应落实该决策；验证应回到原始需求。",{"id":601,"data":602,"type":437},"trace-flow",{"steps":603,"title":628,"orientation":436},[604,607,610,613,616,619,622,625],{"label":605,"description":606},"需求 \u002F 业务目标","该质量或约束为何重要。",{"label":608,"description":609},"需求 \u002F 非功能需求","系统必须达成或遵守什么。",{"label":611,"description":612},"架构驱动因素","哪些需求重要到足以塑造设计。",{"label":614,"description":615},"选项","处理该驱动因素的可行方式。",{"label":617,"description":618},"ADR","所选选择、理由、替代方案、权衡和后果。",{"label":620,"description":621},"实现","实现该决策的代码、数据模型、基础设施、接口和运营机制。",{"label":623,"description":624},"验证证据","测试、测量、分析或审计，证明原始需求是否实际得到满足。",{"label":626,"description":627},"变更 \u002F 取代","新证据或需求变化可以触发新的 ADR，同时保留历史推理。","架构可追溯性链",{"id":630,"data":631,"type":42},"h-senseflow",{"text":632,"level":237},"实现证据：我如何在 SenseFlow 中区分需求与决策",{"id":634,"data":635,"type":225},"senseflow-evidence",{"body":636,"title":637,"variant":231},"以下部分描述我自己的 SenseFlow 项目结构。它是本文所述区分的实现证据，并非声称每个团队都必须使用相同的文档模型。","原始实现 \u002F 项目证据",{"id":639,"data":640,"type":218},"p-sense-1",{"text":641},"在 SenseFlow 中，项目的事实来源明确将非功能需求置于需求结构内，与依赖关系、风险、假设、验收标准和验证方法放在一起。文档模型另行定义了重大决策的决策完整性。",{"id":643,"data":644,"type":218},"p-sense-2",{"text":645},"对于 SenseFlow 的重大决策，记录的字段为\u003Cstrong>决策、原因、替代方案、权衡、状态和日期 \u002F 版本\u003C\u002Fstrong>。重大架构和产品决策旨在保持历史可追溯，而不是在项目演进时被覆盖。",{"id":647,"data":648,"type":218},"p-sense-3",{"text":649},"SenseFlow 还为 Confluence 和 Jira 分配了不同的运营角色。Confluence 是结构化的知识和决策环境；Jira 管理可执行的交付工作。重大 Jira Epic 应链接回相关的产品或需求文档。这保留了从产品意图到需求、决策再到实现的链条，而不是让待办事项列表成为架构的事实来源。",{"id":651,"data":652,"type":290},"senseflow-table",{"content":653,"stretched":43,"withHeadings":14},[654,658,662,666,670,674,678],[655,656,657],"SenseFlow 层","包含内容","在 ADR\u002F非功能需求区分中的角色",[659,660,661],"产品 \u002F 需求结构","产品目标、能力、史诗、用户故事、验收标准、技术任务；需求可包含非功能需求和验证方法","保留必须达成什么以及如何检查成功",[663,664,665],"决策完整性","决策、原因、替代方案、权衡、状态、日期\u002F版本","保留具有架构意义的选择为何成为权威",[667,668,669],"Confluence","需求、架构、研究、决策记录、风险、路线图和支持来源","维护概念性和历史性的事实来源",[671,672,673],"Jira","倡议\u002F目标、史诗、故事、任务和交付状态","执行已批准的工作，而不成为概念性的事实来源",[675,676,677],"变更管理","当前状态 → 新证据 → 提议变更 → 影响 → 决策","允许决策演进而不抹去推理轨迹",[679,680,681],"端到端可追溯性","问题 → 需求 → 价值 → 产品目标 → 需求 → 实现 → 验证","保持决策文档与实际产品和证据生命周期相连",{"id":683,"data":684,"type":225},"senseflow-lesson",{"body":685,"title":686,"variant":348},"需求和决策可以紧密共存，而不会被合并为一条记录。需求仍是目标；决策仍是推理历史；交付工作实现决策；验证回到目标。","此实现展示了什么",{"id":688,"data":689,"type":42},"h-enterprise",{"text":690,"level":237},"企业项目背景：需求应先于架构选择",{"id":692,"data":693,"type":218},"p-enterprise-1",{"text":694},"同样的区分在面向企业的项目工作中也很有用。在需求、风险、约束和验收条件被充分理解之前做出的架构决策，可能会将偏好变成虚假的必需品。",{"id":696,"data":697,"type":218},"p-enterprise-2",{"text":698},"对于 Enterprise Aaasaasa 0.1，相关教训是方法论层面的，而不是关于某个特定 ADR 的主张：需求、架构、验证、里程碑、风险管理和验收属于一个相互连接的交付系统。架构选择应保持可追溯到它旨在处理的需求或约束。",{"id":700,"data":701,"type":42},"h-failures",{"text":702,"level":237},"当ADR和NFR混在一起时的常见失败模式",{"id":704,"data":705,"type":290},"failure-table",{"content":706,"stretched":43,"withHeadings":14},[707,710,714,718,722,726,730,734,738],[708,709,394],"失败模式","会发生什么",[711,712,713],"技术伪装成需求","在没有确立底层需求的情况下，将首选解决方案写成“必须使用X”","从未评估替代方案，架构被过早固定",[715,716,717],"NFR仅隐藏在ADR中","决策提到了性能\u002F安全目标，但该目标不在需求基线中","该目标难以独立验证、排定优先级或管理",[719,720,721],"将ADR视为证明","假设有记录的选型就意味着需求已满足","架构意图取代了测量或验证",[723,724,725],"模糊的NFR","诸如快速、可扩展、安全或可维护等词语没有可度量的范围","不同利益相关者可能认为同一需求意味着不同的事情",[727,728,729],"未记录替代方案","团队只记录所选技术","未来的维护者无法重建为何其他选项被拒绝",[731,732,733],"没有取代模型","架构变更时，旧ADR被编辑或删除","历史推理消失，过时决策可能仍然含糊不清",[735,736,737],"每个实现细节都成为ADR","仓库中充满低价值记录","重要的架构选择变得难以查找",[739,740,741],"待办事项成为架构的唯一事实来源","Jira任务被视为系统的唯一解释","交付状态得以保留，但架构理由和质量驱动因素丢失",{"id":743,"data":744,"type":42},"h-decision-framework",{"text":745,"level":237},"ADR–NFR决策框架",{"id":747,"data":748,"type":218},"p-framework-1",{"text":749},"当团队遇到新的架构关注点时，以下顺序有助于确定什么属于需求、什么属于ADR，以及什么属于证据。",{"id":751,"data":752,"type":437},"decision-flow",{"steps":753,"title":778,"orientation":436},[754,757,760,763,766,769,772,775],{"label":755,"description":756},"1. 这是必需属性还是外部约束？","如果是，在选择机制之前先编写或引用该需求。",{"label":758,"description":759},"2. 它可以被验证吗？","定义所需的范围、条件、度量、验收规则、分析方法或其他证据。",{"label":761,"description":762},"3. 它具有架构重要性吗？","确定该需求是否实质性地影响结构、技术、数据、部署或横切权衡。",{"label":764,"description":765},"4. 是否存在有意义的替代方案？","比较可行的策略或架构选项，而不是直接跳到首选技术。",{"label":767,"description":768},"5. 某个选择是否已成为权威？","创建或更新ADR，包含上下文、决策、理由、替代方案、权衡、状态和后果。",{"label":770,"description":771},"6. 决策是否已实现？","将ADR追溯到设计、任务、代码、配置和运维。",{"label":773,"description":774},"7. 需求是否已满足？","针对需求本身收集验证证据。",{"label":776,"description":777},"8. 条件是否发生变化？","重新评估需求，并在必要时取代ADR而不抹除历史。","ADR–NFR分类测试",{"id":780,"data":781,"type":42},"h-what-not",{"text":782,"level":237},"ADR和NFR不是什么",{"id":784,"data":785,"type":298},"not-comparison",{"rows":786,"title":817,"layout":290,"columns":818},[787,792,797,803,810],{"id":293,"label":294,"values":788},{"not":789,"why":790,"term":791},"A technology shopping list","Requirements should preserve the need independently from one implementation when possible","A required quality, constraint or operating condition",{"id":296,"label":617,"values":793},{"not":794,"why":795,"term":796},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":798,"label":623,"values":799},"test",{"not":800,"why":801,"term":802},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":804,"label":805,"values":806},"backlog","待办事项",{"not":807,"why":808,"term":809},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":811,"label":812,"values":813},"constraint","约束",{"not":814,"why":815,"term":816},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","常见类别错误",[819,822,825],{"id":820,"label":821},"term","概念",{"id":823,"label":824},"not","它不是",{"id":826,"label":516},"why",{"id":828,"data":829,"type":42},"h-change",{"text":830,"level":237},"什么会改变这个答案？",{"id":832,"data":833,"type":218},"p-change-1",{"text":834},"术语可能会演变。截至2026年10月8日，ISO\u002FIEC\u002FIEEE 29148:2018仍是当前发布的需求工程标准，但ISO列出了一项旨在取代它的国际标准草案。如果新版更改了相关术语或需求指南，本文中特定版本的引用应予以更新。",{"id":836,"data":837,"type":218},"p-change-2",{"text":838},"ADR模板也可以演变，而不会改变核心区别。Michael Nygard的最小模板、MADR、组织特定模板、架构知识工具或结构化决策数据库都可以记录决策。持久的问题是，该记录是否保留了足够的上下文和理由，以理解一项具有架构重要性的选择。",{"id":840,"data":841,"type":218},"p-change-3",{"text":842},"只有当组织有意选择一种组合工件，将需求和决策数据存储在同一文档中时，这种区别才会消失。即便如此，语义角色仍然不同：一个字段陈述所需的结果或约束；另一个字段记录所选的响应。",{"id":844,"data":845,"type":42},"h-limitations",{"text":846,"level":237},"局限性",{"id":848,"data":849,"type":218},"p-limit-1",{"text":850},"本文使用\u003Cstrong>NFR\u003C\u002Fstrong>作为实用简称。一些工程方法更倾向于使用质量属性需求、质量需求、系统质量、约束、服务水平目标或架构重要需求等术语。这些术语并非完全可以互换，项目术语应明确。",{"id":852,"data":853,"type":218},"p-limit-2",{"text":854},"并非每个需求都能简化为单一数值阈值。安全性、安全、可维护性、互操作性、可用性、可解释性、可移植性和治理可能需要场景、结构规则、分析、过程控制和定性证据的组合。“可度量”应意味着对决策足够可验证，而不是人为地数字化。",{"id":856,"data":857,"type":218},"p-limit-3",{"text":858},"并非每个架构决策都需要正式的ADR。文档成本应与架构重要性、寿命、不确定性、权衡复杂性和丢失理由的成本成比例。",{"id":860,"data":861,"type":42},"h-conclusion",{"text":862,"level":237},"结论",{"id":864,"data":865,"type":218},"p-conclusion-1",{"text":866},"ADR和NFR属于架构工作的不同层次。\u003Cstrong>NFR定义质量目标、约束或运行条件。ADR记录对一个或多个驱动因素的重要架构响应。\u003C\u002Fstrong>",{"id":868,"data":869,"type":218},"p-conclusion-2",{"text":870},"保持这些层次分离可以使架构更容易推理。需求可以独立于技术进行验证。决策可以被取代而无需重写历史。替代方案和权衡保持可见。交付工作可以追溯到架构意图。证据可以显示最终系统是否实际满足需求。",{"id":872,"data":873,"type":218},"p-conclusion-3",{"text":874},"因此，最坚固的链条不是“NFR → ADR → 完成”。而是\u003Cstrong>需求 → 要求 → 架构驱动因素 → 选项 → 决策 → 实现 → 验证 → 变更\u003C\u002Fstrong>。这条链条将架构文档从静态文书转变为可测试的记录，说明系统为何具有其现有形态。",{"id":876,"data":877,"type":42},"h-faq",{"text":878,"level":237},"常见问题",{"id":880,"data":881,"type":880},"faq",{"items":882,"title":911},[883,887,891,895,899,903,907],{"id":884,"answer":885,"question":886},"faq1","不是。NFR 陈述的是所需的品质、约束或运行条件。ADR 记录的是针对需求、约束、风险和权衡所做的具有架构重要性的选择。","ADR 是非功能性需求吗？",{"id":888,"answer":889,"question":890},"faq2","不是。只有对架构产生实质性影响、值得保留架构级决策的需求才需要。一个 NFR 也可以驱动多个 ADR，一个 ADR 也可以响应多个需求。","每个 NFR 都应该有一个 ADR 吗？",{"id":892,"answer":893,"question":894},"faq3","只有当 PostgreSQL 确实作为外部约束被强制要求时才可以。否则，应首先表达底层需求，而选择 PostgreSQL 通常应被视为架构决策。","“使用 PostgreSQL”可以是 NFR 吗？",{"id":896,"answer":897,"question":898},"faq4","不能。ADR 记录的是意图和推理。需求通过适当的证据来验证，例如测试、测量、分析、审计或运行遥测。","ADR 能证明性能或安全需求得到满足吗？",{"id":900,"answer":901,"question":902},"faq5","至少，ADR 应明确说明背景和决策。常见结构还包括状态和后果。团队可以添加备选方案、理由、权衡、需求链接、证据、负责人、日期和取代关系。","ADR 应包含什么？",{"id":904,"answer":905,"question":906},"faq6","当需求实质性影响系统结构、技术、数据流、部署、横切行为或困难的品质权衡时，尤其是当失败会带来高业务或任务影响时，该需求就具有架构重要性。","什么使 NFR 具有架构重要性？",{"id":908,"answer":909,"question":910},"faq7","通常不应删除。替代决策通常应取代旧记录，以便历史推理仍可追溯。","架构变更时，旧的 ADR 应删除吗？","ADR 与 NFR",{"id":913,"data":914,"type":42},"h-glossary",{"text":915,"level":237},"术语表",{"id":917,"data":918,"type":917},"glossary",{"title":919,"entries":920},"核心架构术语",[921,924,928,931,935,937,941,944],{"term":922,"anchor":293,"definition":923},"NFR","非功能性需求：对所需系统品质、约束或运行条件的实用简称；确切术语因方法和标准而异。",{"term":925,"anchor":926,"definition":927},"质量属性需求","quality-attribute-requirement","描述系统在既定条件下预期表现出的质量特性的需求，例如性能、可用性、安全性、可靠性或可修改性。",{"term":929,"anchor":296,"definition":930},"架构决策记录（ADR）","对具有架构重要性的决策及其足够背景的持久记录，以便理解为何做出该选择以及会产生什么后果。",{"term":932,"anchor":933,"definition":934},"架构重要需求（ASR）","asr","具有足够深远架构影响、能实质性影响系统设计的需求。",{"term":812,"anchor":811,"definition":936},"限制解决方案空间的条件，包括外部政策、法规、平台、兼容性、合同或组织边界。",{"term":938,"anchor":939,"definition":940},"权衡","trade-off","一种设计关系，其中改善一个目标、属性或成本维度可能会使另一个变差。",{"term":942,"anchor":495,"definition":943},"验证","用于确定已实现系统在相关条件下是否满足所述需求的证据生成工作。",{"term":945,"anchor":946,"definition":947},"被取代的 ADR","superseded-adr","已被更新的权威决策取代、但仍可用于追溯的历史决策记录。",{"id":949,"data":950,"type":42},"h-sources",{"text":951,"level":237},"主要来源与实施证据",{"id":953,"data":954,"type":218},"p-sources-note",{"text":955},"本文将当前标准与项目实施证据区分开来。截至 2026 年 10 月 8 日，ISO\u002FIEC\u002FIEEE 29148:2018 仍然有效，但已标记为待修订；ISO\u002FIEC 25010:2023 和 ISO\u002FIEC\u002FIEEE 42010:2022 是当前已发布的版本。SenseFlow 是上述可追溯性和决策完整性模型的原创项目证据。",{"id":957,"data":958,"type":965},"src-iso-29148",{"link":959,"meta":960},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":961,"title":963,"description":964},{"url":962},"","ISO\u002FIEC\u002FIEEE 29148:2018 — 需求工程","当前已发布的需求工程标准。ISO 表示，2018 年版已于 2024 年审查并确认，预计将由目前正在制定的 DIS 取代。","linkTool",{"id":967,"data":968,"type":965},"src-iso-29148-dis",{"link":969,"meta":970},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":971,"title":972,"description":973},{"url":962},"ISO\u002FIEC\u002FIEEE DIS 29148 — 需求工程","目前正在制定、旨在取代 ISO\u002FIEC\u002FIEEE 29148:2018 的国际标准草案。",{"id":975,"data":976,"type":965},"src-iso-25010",{"link":977,"meta":978},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":979,"title":980,"description":981},{"url":962},"ISO\u002FIEC 25010:2023 — 产品质量模型","当前产品质量模型，包含九个质量特性，用于规定、测量和评估 ICT 与软件产品质量。",{"id":983,"data":984,"type":965},"src-iso-42010",{"link":985,"meta":986},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":987,"title":988,"description":989},{"url":962},"ISO\u002FIEC\u002FIEEE 42010:2022 — 架构描述","当前架构描述标准。它规定了架构描述概念和一致性要求，但不规定单一记录格式、表示法、过程或工具。",{"id":991,"data":992,"type":965},"src-nygard",{"link":993,"meta":994},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":995,"title":996,"description":997},{"url":962},"Michael Nygard — 记录架构决策","具有影响力的原始 ADR 文章，描述了以背景、决策、状态和后果为中心的轻量级记录，并保留被取代的决策以便理解历史。",{"id":999,"data":1000,"type":965},"src-sei-asr",{"link":1001,"meta":1002},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1003,"title":1004,"description":1005},{"url":962},"SEI — 将业务目标与架构重要需求关联起来","SEI 报告，解释质量属性需求和业务目标如何驱动软件架构，以及为何需要明确引出架构重要需求。",{"id":1007,"data":1008,"type":965},"src-sei-nfr",{"link":1009,"meta":1010},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1011,"title":1012,"description":1013},{"url":962},"SEI — 定义非功能性系统质量","SEI 概述，将非功能性\u002F质量属性与架构、场景、权衡和客观系统评估联系起来。",{"id":1015,"data":1016,"type":965},"src-sei-add",{"link":1017,"meta":1018},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1019,"title":1020,"description":1021},{"url":962},"SEI — 属性驱动设计方法集合","基于功能需求、质量属性需求和约束的架构设计方法，选择架构战术和模式以满足质量场景。",{"id":1023,"data":1024,"type":965},"src-sei-doc",{"link":1025,"meta":1026},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1027,"title":1028,"description":1029},{"url":962},"SEI — 视图与超越集合","架构文档指南，强调相关视图以及将必要设计决策作为架构工作的一部分记录下来。","2.31","ADR 与 NFR 解析：了解系统质量需求如何驱动架构决策、ADR 如何记录权衡取舍，以及为什么验证保持独立。","\u002Fuploads\u002F2026\u002F10\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1.webp","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing-1791475921511-6zgen1","PUBLISHED","2026-10-08T12:11:00.000Z","2026-10-08T16:11:31.560Z","2026-10-08T17:31:47.443Z",{"en":1039,"de":1040,"sr":1041,"es":1042,"fr":1043,"it":1044,"ru":1045,"zh":1046},"\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fde\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fsr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fes\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Ffr\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fit\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fru\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u002Fzh\u002Fblog\u002Fadr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing",[1048,1052,1056,1060,1064],{"id":1049,"name":1050,"slug":1051},72,"验收标准","acceptance-criteria",{"id":1053,"name":1054,"slug":1055},67,"KPI与验收标准","kpis",{"id":1057,"name":1058,"slug":1059},77,"测量与监控","measurement",{"id":1061,"name":1062,"slug":1063},76,"性能预算","budgets",{"id":1065,"name":1066,"slug":1067},68,"风险、控制与证据","risks-and-controls",{"id":1069,"login":1070,"email":1071,"displayName":1072},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1074,1718],{"lang":1075,"title":1076,"content":1077,"contentJson":1078,"excerpt":1717},"en","ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing","{\"time\":1791475659420,\"blocks\":[{\"id\":\"intro\",\"data\":{\"text\":\"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.\"},\"type\":\"paragraph\"},{\"id\":\"direct\",\"data\":{\"body\":\"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.\",\"title\":\"Direct answer\",\"variant\":\"info\"},\"type\":\"callout\"},{\"id\":\"version-note\",\"data\":{\"body\":\"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.\",\"title\":\"Terminology and standards note\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"toc\",\"data\":{\"title\":\"Contents\",\"maxLevel\":3,\"minLevel\":2},\"type\":\"tableOfContents\"},{\"id\":\"h-meaning\",\"data\":{\"text\":\"What is the difference between an NFR and an ADR?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-meaning-1\",\"data\":{\"text\":\"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-2\",\"data\":{\"text\":\"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.\"},\"type\":\"paragraph\"},{\"id\":\"p-meaning-3\",\"data\":{\"text\":\"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.\"},\"type\":\"paragraph\"},{\"id\":\"basic-difference\",\"data\":{\"rows\":[{\"id\":\"question\",\"label\":\"Primary question\",\"values\":{\"adr\":\"What architecturally significant choice did we make, and why?\",\"nfr\":\"What quality, constraint, or operating condition must the system satisfy?\"}},{\"id\":\"content\",\"label\":\"Typical content\",\"values\":{\"adr\":\"Context, decision, rationale, alternatives, trade-offs, status and consequences\",\"nfr\":\"Measurable target, scope, condition, constraint, acceptance or validation rule\"}},{\"id\":\"lifecycle\",\"label\":\"Lifecycle role\",\"values\":{\"adr\":\"A historical record of a significant decision\",\"nfr\":\"A requirement to design for and validate\"}},{\"id\":\"evidence\",\"label\":\"What proves it?\",\"values\":{\"adr\":\"The record proves what was decided, not that the resulting system meets the requirement\",\"nfr\":\"Measurement, test, analysis, inspection, audit or other validation evidence\"}},{\"id\":\"change\",\"label\":\"When it changes\",\"values\":{\"adr\":\"When the decision is replaced, rejected, deprecated, or superseded\",\"nfr\":\"When stakeholder need, operating conditions, policy or quality target changes\"}}],\"title\":\"NFR and ADR answer different questions\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\"},{\"id\":\"adr\",\"label\":\"ADR \u002F architecture decision\"}]},\"type\":\"comparison\"},{\"id\":\"h-nfr\",\"data\":{\"text\":\"What is an NFR in precise architectural terms?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-nfr-1\",\"data\":{\"text\":\"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-2\",\"data\":{\"text\":\"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.\"},\"type\":\"paragraph\"},{\"id\":\"p-nfr-3\",\"data\":{\"text\":\"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.\"},\"type\":\"paragraph\"},{\"id\":\"nfr-examples\",\"data\":{\"content\":[[\"Weak statement\",\"More useful requirement shape\",\"Why the difference matters\"],[\"The API must be fast\",\"For workload W, 95% of operation X completes within T milliseconds\",\"Defines workload, operation, metric and threshold\"],[\"The service must be available\",\"Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions\",\"Makes availability measurable and defines scope\"],[\"Tenant data must be secure\",\"A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths\",\"Turns a vague security goal into an isolation property\"],[\"The system should scale\",\"The system supports workload W at concurrency C while meeting latency and error-rate thresholds\",\"Connects scale to measurable service behavior\"],[\"We need PostgreSQL\",\"Not an NFR by itself; state the required persistence qualities or external constraint first\",\"A technology choice is normally a solution, not the requirement it is meant to satisfy\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"nfr-rule\",\"data\":{\"body\":\"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.\",\"title\":\"A requirement should describe the need before the mechanism\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-adr\",\"data\":{\"text\":\"What is an Architecture Decision Record?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-adr-1\",\"data\":{\"text\":\"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-2\",\"data\":{\"text\":\"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.\"},\"type\":\"paragraph\"},{\"id\":\"p-adr-3\",\"data\":{\"text\":\"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.\"},\"type\":\"paragraph\"},{\"id\":\"adr-anatomy\",\"data\":{\"content\":[[\"ADR field\",\"What it preserves\",\"Why it matters\"],[\"Context\",\"The problem, forces, requirements, assumptions and environment surrounding the choice\",\"Future readers can reconstruct why a choice was necessary\"],[\"Decision\",\"The choice that became authoritative\",\"Separates the selected option from discussion\"],[\"Status\",\"Proposed, accepted, rejected, deprecated, superseded, or another controlled state\",\"Prevents old decisions from silently remaining active\"],[\"Alternatives\",\"Other viable options considered\",\"Shows that the selected solution was not the only imaginable one\"],[\"Rationale \u002F trade-offs\",\"Why the option was selected and what it gives up\",\"Makes architecture reasoning inspectable\"],[\"Consequences\",\"Expected positive and negative effects, follow-up work, risks\",\"Connects a local choice to system impact\"],[\"Date \u002F version\",\"When the decision became valid\",\"Supports historical traceability and later supersession\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-simple-example\",\"data\":{\"text\":\"The simplest example: latency requirement → architecture decision\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-simple-1\",\"data\":{\"text\":\"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.\"},\"type\":\"paragraph\"},{\"id\":\"p-simple-2\",\"data\":{\"text\":\"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.\"},\"type\":\"paragraph\"},{\"id\":\"simple-flow\",\"data\":{\"steps\":[{\"label\":\"1. State the requirement\",\"description\":\"Define the quality target, workload, scope, threshold and validation method.\"},{\"label\":\"2. Identify architectural significance\",\"description\":\"Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.\"},{\"label\":\"3. Evaluate options\",\"description\":\"Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.\"},{\"label\":\"4. Record the decision\",\"description\":\"Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.\"},{\"label\":\"5. Implement\",\"description\":\"Turn the decision into code, infrastructure, configuration and operational behavior.\"},{\"label\":\"6. Validate\",\"description\":\"Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.\"}],\"title\":\"From requirement to evidence\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"simple-stop\",\"data\":{\"body\":\"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.\",\"title\":\"Where the simple example stops\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-many-many\",\"data\":{\"text\":\"NFRs and ADRs usually have a many-to-many relationship\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-many-1\",\"data\":{\"text\":\"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.\"},\"type\":\"paragraph\"},{\"id\":\"p-many-2\",\"data\":{\"text\":\"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.\"},\"type\":\"paragraph\"},{\"id\":\"relationship-map\",\"data\":{\"rows\":[{\"id\":\"one-many\",\"label\":\"One NFR → many ADRs\",\"values\":{\"adr\":\"Several coordinated decisions may be required\",\"nfr\":\"A broad quality target can constrain several architectural boundaries\",\"validation\":\"Evidence may need multiple tests or measurements\"}},{\"id\":\"many-one\",\"label\":\"Many NFRs → one ADR\",\"values\":{\"adr\":\"One decision may balance several drivers\",\"nfr\":\"Several quality and constraint drivers can point at the same design problem\",\"validation\":\"Each requirement still needs its own acceptance evidence\"}},{\"id\":\"non-nfr\",\"label\":\"ADR without a classic NFR\",\"values\":{\"adr\":\"The choice can still be architecturally significant\",\"nfr\":\"The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition\",\"validation\":\"Validate against the actual driver, not an invented NFR\"}},{\"id\":\"supersession\",\"label\":\"Requirement stable, ADR changes\",\"values\":{\"adr\":\"A better or necessary implementation choice can supersede the old decision\",\"nfr\":\"The target can remain unchanged\",\"validation\":\"The new architecture must still be checked against the same target\"}}],\"title\":\"Why the relationship is not one-to-one\",\"layout\":\"table\",\"columns\":[{\"id\":\"nfr\",\"label\":\"Requirement side\"},{\"id\":\"adr\",\"label\":\"Decision side\"},{\"id\":\"validation\",\"label\":\"Validation side\"}]},\"type\":\"comparison\"},{\"id\":\"h-technology\",\"data\":{\"text\":\"A technology choice is not automatically a requirement\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-tech-1\",\"data\":{\"text\":\"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.\"},\"type\":\"paragraph\"},{\"id\":\"p-tech-2\",\"data\":{\"text\":\"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.\"},\"type\":\"paragraph\"},{\"id\":\"tech-table\",\"data\":{\"content\":[[\"Statement\",\"Classification\",\"Reason\"],[\"All tenant-scoped reads must enforce tenant isolation\",\"Requirement \u002F security property\",\"Describes a property that must hold\"],[\"Use PostgreSQL Row Level Security for selected tenant-scoped tables\",\"Architecture decision\",\"Chooses a mechanism intended to help satisfy the isolation property\"],[\"The deployment target must run in an approved EU-operated environment\",\"Constraint \u002F NFR-like operating condition\",\"Restricts where the system may operate\"],[\"Use provider X in region Y\",\"Architecture \u002F deployment decision unless externally mandated\",\"Selects a particular solution inside the allowed boundary\"],[\"95th-percentile API latency ≤ 300 ms under workload W\",\"Quality requirement\",\"Defines measurable performance behavior\"],[\"Introduce a cache for endpoint X\",\"Architecture decision\",\"Selects a tactic intended to improve the measured behavior\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-adr-proof\",\"data\":{\"text\":\"An ADR is not proof that an NFR has been satisfied\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-proof-1\",\"data\":{\"text\":\"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.\"},\"type\":\"paragraph\"},{\"id\":\"p-proof-2\",\"data\":{\"text\":\"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.\"},\"type\":\"paragraph\"},{\"id\":\"proof-rule\",\"data\":{\"body\":\"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”\",\"title\":\"Do not confuse intent with evidence\",\"variant\":\"warning\"},\"type\":\"callout\"},{\"id\":\"h-asr\",\"data\":{\"text\":\"When does an NFR become architecturally significant?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-asr-1\",\"data\":{\"text\":\"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.\"},\"type\":\"paragraph\"},{\"id\":\"p-asr-2\",\"data\":{\"text\":\"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.\"},\"type\":\"paragraph\"},{\"id\":\"asr-test\",\"data\":{\"steps\":[{\"label\":\"1. Ask whether the requirement changes structure\",\"description\":\"Would different values force different components, boundaries, data paths or deployment topology?\"},{\"label\":\"2. Ask whether it constrains major technology choices\",\"description\":\"Does it eliminate otherwise viable implementation options?\"},{\"label\":\"3. Ask whether it creates cross-cutting behavior\",\"description\":\"Does it affect many components, teams, interfaces or lifecycle stages?\"},{\"label\":\"4. Ask whether it creates a difficult trade-off\",\"description\":\"Does improving this property materially affect another quality, cost, schedule, complexity or risk?\"},{\"label\":\"5. Ask whether failure is expensive\",\"description\":\"Would missing the requirement create material operational, security, regulatory, financial or product impact?\"},{\"label\":\"6. Record decisions only where the reasoning is worth preserving\",\"description\":\"Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.\"}],\"title\":\"Architectural-significance test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-traceability\",\"data\":{\"text\":\"A stronger architecture model: requirement → decision → implementation → validation\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-trace-1\",\"data\":{\"text\":\"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.\"},\"type\":\"paragraph\"},{\"id\":\"trace-flow\",\"data\":{\"steps\":[{\"label\":\"Need \u002F business goal\",\"description\":\"Why the quality or constraint matters.\"},{\"label\":\"Requirement \u002F NFR\",\"description\":\"What the system must achieve or respect.\"},{\"label\":\"Architecture drivers\",\"description\":\"Which requirements are significant enough to shape the design.\"},{\"label\":\"Options\",\"description\":\"Plausible ways to address the driver.\"},{\"label\":\"ADR\",\"description\":\"The selected choice, rationale, alternatives, trade-offs and consequences.\"},{\"label\":\"Implementation\",\"description\":\"Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.\"},{\"label\":\"Validation evidence\",\"description\":\"Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.\"},{\"label\":\"Change \u002F supersession\",\"description\":\"New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.\"}],\"title\":\"Architecture traceability chain\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-senseflow\",\"data\":{\"text\":\"Implementation evidence: how I separate requirements and decisions in SenseFlow\",\"level\":2},\"type\":\"header\"},{\"id\":\"senseflow-evidence\",\"data\":{\"body\":\"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.\",\"title\":\"Original implementation \u002F project evidence\",\"variant\":\"note\"},\"type\":\"callout\"},{\"id\":\"p-sense-1\",\"data\":{\"text\":\"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-2\",\"data\":{\"text\":\"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.\"},\"type\":\"paragraph\"},{\"id\":\"p-sense-3\",\"data\":{\"text\":\"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.\"},\"type\":\"paragraph\"},{\"id\":\"senseflow-table\",\"data\":{\"content\":[[\"SenseFlow layer\",\"What it contains\",\"Role in ADR\u002FNFR separation\"],[\"Product \u002F requirement structure\",\"Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method\",\"Preserves what must be achieved and how success will be checked\"],[\"Decision integrity\",\"Decision, reason, alternatives, trade-offs, status, date\u002Fversion\",\"Preserves why an architecturally significant choice became authoritative\"],[\"Confluence\",\"Requirements, architecture, research, decision records, risks, roadmap and supporting sources\",\"Maintains conceptual and historical Source of Truth\"],[\"Jira\",\"Initiatives\u002Fgoals, epics, stories, tasks and delivery state\",\"Executes approved work without becoming the conceptual Source of Truth\"],[\"Change management\",\"Current state → new evidence → proposed change → impact → decision\",\"Allows decisions to evolve without erasing the reasoning trail\"],[\"End-to-end traceability\",\"Problem → need → value → product goal → requirement → implementation → validation\",\"Keeps decision documentation connected to the actual product and evidence lifecycle\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"senseflow-lesson\",\"data\":{\"body\":\"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.\",\"title\":\"What this implementation demonstrates\",\"variant\":\"success\"},\"type\":\"callout\"},{\"id\":\"h-enterprise\",\"data\":{\"text\":\"Enterprise project context: requirements should precede architecture choices\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-enterprise-1\",\"data\":{\"text\":\"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.\"},\"type\":\"paragraph\"},{\"id\":\"p-enterprise-2\",\"data\":{\"text\":\"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.\"},\"type\":\"paragraph\"},{\"id\":\"h-failures\",\"data\":{\"text\":\"Common failure modes when ADRs and NFRs are mixed\",\"level\":2},\"type\":\"header\"},{\"id\":\"failure-table\",\"data\":{\"content\":[[\"Failure mode\",\"What happens\",\"Consequence\"],[\"Technology disguised as requirement\",\"A preferred solution is written as “must use X” without establishing the underlying need\",\"Alternatives are never evaluated and architecture becomes prematurely fixed\"],[\"NFR hidden only inside an ADR\",\"The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline\",\"The target is hard to validate, prioritize or manage independently\"],[\"ADR treated as proof\",\"A documented choice is assumed to mean the requirement is satisfied\",\"Architecture intent replaces measurement or verification\"],[\"Vague NFR\",\"Words such as fast, scalable, secure or maintainable have no measurable scope\",\"Different stakeholders can believe the same requirement means different things\"],[\"No alternatives recorded\",\"The team records only the selected technology\",\"Future maintainers cannot reconstruct why another option was rejected\"],[\"No supersession model\",\"Old ADRs are edited or deleted when the architecture changes\",\"Historical reasoning disappears and stale decisions can remain ambiguous\"],[\"Every implementation detail becomes an ADR\",\"The repository fills with low-value records\",\"Important architecture choices become difficult to find\"],[\"Backlog becomes architecture SoT\",\"Jira tasks are treated as the only explanation of the system\",\"Delivery state survives, but architectural rationale and quality drivers are lost\"]],\"stretched\":false,\"withHeadings\":true},\"type\":\"table\"},{\"id\":\"h-decision-framework\",\"data\":{\"text\":\"The ADR–NFR decision framework\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-framework-1\",\"data\":{\"text\":\"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.\"},\"type\":\"paragraph\"},{\"id\":\"decision-flow\",\"data\":{\"steps\":[{\"label\":\"1. Is this a required property or external constraint?\",\"description\":\"If yes, write or reference the requirement before choosing a mechanism.\"},{\"label\":\"2. Can it be validated?\",\"description\":\"Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.\"},{\"label\":\"3. Is it architecturally significant?\",\"description\":\"Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.\"},{\"label\":\"4. Are there meaningful alternatives?\",\"description\":\"Compare viable tactics or architecture options rather than jumping directly to a preferred technology.\"},{\"label\":\"5. Has a choice become authoritative?\",\"description\":\"Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.\"},{\"label\":\"6. Is the decision implemented?\",\"description\":\"Trace the ADR into design, tasks, code, configuration and operations.\"},{\"label\":\"7. Is the requirement satisfied?\",\"description\":\"Collect validation evidence against the requirement itself.\"},{\"label\":\"8. Did conditions change?\",\"description\":\"Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.\"}],\"title\":\"ADR–NFR classification test\",\"orientation\":\"auto\"},\"type\":\"processFlow\"},{\"id\":\"h-what-not\",\"data\":{\"text\":\"What ADR and NFR are not\",\"level\":2},\"type\":\"header\"},{\"id\":\"not-comparison\",\"data\":{\"rows\":[{\"id\":\"nfr\",\"label\":\"NFR \u002F quality requirement\",\"values\":{\"not\":\"A technology shopping list\",\"why\":\"Requirements should preserve the need independently from one implementation when possible\",\"term\":\"A required quality, constraint or operating condition\"}},{\"id\":\"adr\",\"label\":\"ADR\",\"values\":{\"not\":\"The complete architecture description\",\"why\":\"Architecture also needs views, interfaces, models, responsibilities and other documentation\",\"term\":\"A record of an architecturally significant decision\"}},{\"id\":\"test\",\"label\":\"Validation evidence\",\"values\":{\"not\":\"The ADR itself\",\"why\":\"Documented intent is different from measured or analyzed system behavior\",\"term\":\"Evidence that checks whether a requirement is satisfied\"}},{\"id\":\"backlog\",\"label\":\"Backlog item\",\"values\":{\"not\":\"A durable substitute for architecture rationale\",\"why\":\"Task state answers what is being delivered, not necessarily why the architecture exists\",\"term\":\"Actionable delivery work\"}},{\"id\":\"constraint\",\"label\":\"Constraint\",\"values\":{\"not\":\"Always an internally chosen architecture decision\",\"why\":\"Some constraints come from regulation, contracts, existing platforms or organizational boundaries\",\"term\":\"A condition that restricts the solution space\"}}],\"title\":\"Common category errors\",\"layout\":\"table\",\"columns\":[{\"id\":\"term\",\"label\":\"Concept\"},{\"id\":\"not\",\"label\":\"It is not\"},{\"id\":\"why\",\"label\":\"Reason\"}]},\"type\":\"comparison\"},{\"id\":\"h-change\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-change-1\",\"data\":{\"text\":\"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-2\",\"data\":{\"text\":\"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.\"},\"type\":\"paragraph\"},{\"id\":\"p-change-3\",\"data\":{\"text\":\"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.\"},\"type\":\"paragraph\"},{\"id\":\"h-limitations\",\"data\":{\"text\":\"Limitations\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-limit-1\",\"data\":{\"text\":\"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-2\",\"data\":{\"text\":\"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.\"},\"type\":\"paragraph\"},{\"id\":\"p-limit-3\",\"data\":{\"text\":\"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.\"},\"type\":\"paragraph\"},{\"id\":\"h-conclusion\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-conclusion-1\",\"data\":{\"text\":\"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-2\",\"data\":{\"text\":\"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.\"},\"type\":\"paragraph\"},{\"id\":\"p-conclusion-3\",\"data\":{\"text\":\"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.\"},\"type\":\"paragraph\"},{\"id\":\"h-faq\",\"data\":{\"text\":\"FAQ\",\"level\":2},\"type\":\"header\"},{\"id\":\"faq\",\"data\":{\"items\":[{\"id\":\"faq1\",\"answer\":\"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.\",\"question\":\"Is an ADR a non-functional requirement?\"},{\"id\":\"faq2\",\"answer\":\"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.\",\"question\":\"Should every NFR have an ADR?\"},{\"id\":\"faq3\",\"answer\":\"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.\",\"question\":\"Can “use PostgreSQL” be an NFR?\"},{\"id\":\"faq4\",\"answer\":\"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.\",\"question\":\"Does an ADR prove that a performance or security requirement is met?\"},{\"id\":\"faq5\",\"answer\":\"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.\",\"question\":\"What should an ADR contain?\"},{\"id\":\"faq6\",\"answer\":\"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.\",\"question\":\"What makes an NFR architecturally significant?\"},{\"id\":\"faq7\",\"answer\":\"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.\",\"question\":\"Should an old ADR be deleted when the architecture changes?\"}],\"title\":\"ADR vs NFR\"},\"type\":\"faq\"},{\"id\":\"h-glossary\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"type\":\"header\"},{\"id\":\"glossary\",\"data\":{\"title\":\"Core architecture terms\",\"entries\":[{\"term\":\"NFR\",\"anchor\":\"nfr\",\"definition\":\"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.\"},{\"term\":\"Quality attribute requirement\",\"anchor\":\"quality-attribute-requirement\",\"definition\":\"A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.\"},{\"term\":\"Architecture Decision Record (ADR)\",\"anchor\":\"adr\",\"definition\":\"A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.\"},{\"term\":\"Architecturally Significant Requirement (ASR)\",\"anchor\":\"asr\",\"definition\":\"A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.\"},{\"term\":\"Constraint\",\"anchor\":\"constraint\",\"definition\":\"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.\"},{\"term\":\"Trade-off\",\"anchor\":\"trade-off\",\"definition\":\"A design relationship in which improving one objective, property or cost dimension can worsen another.\"},{\"term\":\"Validation\",\"anchor\":\"validation\",\"definition\":\"Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.\"},{\"term\":\"Superseded ADR\",\"anchor\":\"superseded-adr\",\"definition\":\"A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.\"}]},\"type\":\"glossary\"},{\"id\":\"h-sources\",\"data\":{\"text\":\"Primary sources and implementation evidence\",\"level\":2},\"type\":\"header\"},{\"id\":\"p-sources-note\",\"data\":{\"text\":\"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.\"},\"type\":\"paragraph\"},{\"id\":\"src-iso-29148\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering\",\"description\":\"Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-29148-dis\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering\",\"description\":\"Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-25010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC 25010:2023 — Product Quality Model\",\"description\":\"Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.\"}},\"type\":\"linkTool\"},{\"id\":\"src-iso-42010\",\"data\":{\"link\":\"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description\",\"description\":\"Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.\"}},\"type\":\"linkTool\"},{\"id\":\"src-nygard\",\"data\":{\"link\":\"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Michael Nygard — Documenting Architecture Decisions\",\"description\":\"Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-asr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Relating Business Goals to Architecturally Significant Requirements\",\"description\":\"SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-nfr\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Defining Non-Functional System Qualities\",\"description\":\"SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-add\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Attribute-Driven Design Method Collection\",\"description\":\"Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.\"}},\"type\":\"linkTool\"},{\"id\":\"src-sei-doc\",\"data\":{\"link\":\"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"SEI — Views and Beyond Collection\",\"description\":\"Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.\"}},\"type\":\"linkTool\"}],\"version\":\"2.31.0\"}",{"time":1079,"blocks":1080,"version":1716},1791475659420,[1081,1084,1088,1092,1095,1098,1101,1104,1107,1131,1134,1137,1140,1143,1170,1174,1177,1180,1183,1186,1221,1224,1227,1230,1252,1256,1259,1262,1265,1288,1291,1294,1297,1327,1330,1333,1336,1340,1343,1346,1349,1371,1374,1377,1404,1407,1411,1414,1417,1420,1449,1453,1456,1459,1462,1465,1504,1507,1510,1538,1541,1563,1566,1569,1572,1575,1578,1581,1584,1587,1590,1593,1596,1599,1602,1627,1630,1656,1659,1662,1668,1674,1680,1686,1692,1698,1704,1710],{"id":215,"data":1082,"type":218},{"text":1083},"An \u003Cstrong>non-functional requirement (NFR)\u003C\u002Fstrong> describes a quality, constraint, or operating condition the system is expected to satisfy. An \u003Cstrong>architecture decision record (ADR)\u003C\u002Fstrong> records an architecturally significant choice made in response to requirements, constraints, risks, and trade-offs. They are connected, but they are not interchangeable: an NFR states what must be true; an ADR explains what was decided, why, and with what consequences.",{"id":220,"data":1085,"type":225},{"body":1086,"title":1087,"variant":224},"\u003Cstrong>NFR = required system quality or constraint. ADR = recorded architecture decision.\u003C\u002Fstrong> A latency target, availability objective, isolation rule, deployment restriction, or maintainability requirement can influence architecture. An ADR then records a significant choice made to address one or more such drivers. The ADR does not replace the requirement, and the existence of an ADR does not prove that the requirement has been satisfied.","Direct answer",{"id":227,"data":1089,"type":225},{"body":1090,"title":1091,"variant":231},"The term \u003Cstrong>NFR\u003C\u002Fstrong> is widely used but not perfectly standardized. This article uses it as practical shorthand for quality requirements and relevant constraints. Current standards were re-checked on \u003Cstrong>8 October 2026\u003C\u002Fstrong>: ISO\u002FIEC\u002FIEEE 29148:2018 remains current but is under revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are the current published editions cited here.","Terminology and standards note",{"id":233,"data":1093,"type":238},{"title":1094,"maxLevel":236,"minLevel":237},"Contents",{"id":240,"data":1096,"type":42},{"text":1097,"level":237},"What is the difference between an NFR and an ADR?",{"id":244,"data":1099,"type":218},{"text":1100},"The simplest distinction is grammatical. A requirement describes a condition the system must satisfy. A decision record describes a choice the team made.",{"id":248,"data":1102,"type":218},{"text":1103},"For example, \u003Cstrong>“The API must return 95% of read requests within 300 ms under the agreed reference load”\u003C\u002Fstrong> is a quality requirement. \u003Cstrong>“Use a read-through cache for this workload because the measured database-only path cannot meet the latency target without unacceptable cost”\u003C\u002Fstrong> is an architecture decision.",{"id":252,"data":1105,"type":218},{"text":1106},"The first statement remains valid even if the implementation changes. The second statement can later be superseded by another decision if the workload, technology, cost model, or evidence changes.",{"id":256,"data":1108,"type":298},{"rows":1109,"title":1125,"layout":290,"columns":1126},[1110,1113,1116,1119,1122],{"id":260,"label":1111,"values":1112},"Primary question",{"adr":263,"nfr":264},{"id":266,"label":1114,"values":1115},"Typical content",{"adr":269,"nfr":270},{"id":272,"label":1117,"values":1118},"Lifecycle role",{"adr":275,"nfr":276},{"id":278,"label":1120,"values":1121},"What proves it?",{"adr":281,"nfr":282},{"id":284,"label":1123,"values":1124},"When it changes",{"adr":287,"nfr":288},"NFR and ADR answer different questions",[1127,1129],{"id":293,"label":1128},"NFR \u002F quality requirement",{"id":296,"label":1130},"ADR \u002F architecture decision",{"id":300,"data":1132,"type":42},{"text":1133,"level":237},"What is an NFR in precise architectural terms?",{"id":304,"data":1135,"type":218},{"text":1136},"“Non-functional requirement” is a convenient industry label, but it can hide several different kinds of statements. In architecture work, the useful distinction is between \u003Cstrong>functional behavior\u003C\u002Fstrong>, \u003Cstrong>quality requirements\u003C\u002Fstrong>, and \u003Cstrong>constraints\u003C\u002Fstrong>.",{"id":308,"data":1138,"type":218},{"text":1139},"ISO\u002FIEC 25010:2023 provides a product-quality model with nine characteristics and subcharacteristics that can be used when specifying and evaluating ICT and software product quality. SEI architecture work similarly treats quality attribute requirements as major drivers of software architecture.",{"id":312,"data":1141,"type":218},{"text":1142},"A useful NFR is therefore not “the system should be fast” or “the platform must be secure.” Those statements name aspirations. An architecture-driving requirement should make the expected property testable enough that design alternatives and later evidence can be evaluated against it.",{"id":316,"data":1144,"type":290},{"content":1145,"stretched":43,"withHeadings":14},[1146,1150,1154,1158,1162,1166],[1147,1148,1149],"Weak statement","More useful requirement shape","Why the difference matters",[1151,1152,1153],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1155,1156,1157],"The service must be available","Service S meets an agreed availability objective over measurement window M, excluding explicitly defined maintenance conditions","Makes availability measurable and defines scope",[1159,1160,1161],"Tenant data must be secure","A request authenticated for tenant A must never retrieve or mutate tenant B data through supported application paths","Turns a vague security goal into an isolation property",[1163,1164,1165],"The system should scale","The system supports workload W at concurrency C while meeting latency and error-rate thresholds","Connects scale to measurable service behavior",[1167,1168,1169],"We need PostgreSQL","Not an NFR by itself; state the required persistence qualities or external constraint first","A technology choice is normally a solution, not the requirement it is meant to satisfy",{"id":344,"data":1171,"type":225},{"body":1172,"title":1173,"variant":348},"If “use Kubernetes,” “use PostgreSQL,” “use microservices,” or “use vector search” appears as the requirement, ask whether it is truly an external constraint or whether the solution has been written down before the underlying quality need was made explicit.","A requirement should describe the need before the mechanism",{"id":350,"data":1175,"type":42},{"text":1176,"level":237},"What is an Architecture Decision Record?",{"id":354,"data":1178,"type":218},{"text":1179},"An Architecture Decision Record is a compact record of an important architecture decision. Michael Nygard’s original ADR formulation emphasizes the \u003Cstrong>context\u003C\u002Fstrong>, the \u003Cstrong>decision\u003C\u002Fstrong>, its \u003Cstrong>status\u003C\u002Fstrong>, and the resulting \u003Cstrong>consequences\u003C\u002Fstrong>.",{"id":358,"data":1181,"type":218},{"text":1182},"The important object is the decision, not the template. Different teams use different ADR formats. A richer record can also preserve alternatives, decision criteria, trade-offs, evidence, links to requirements, and the date or version from which the decision applies.",{"id":362,"data":1184,"type":218},{"text":1185},"ISO\u002FIEC\u002FIEEE 42010:2022 is broader than ADR practice: it specifies requirements for architecture descriptions and their concepts, while explicitly not prescribing one process, notation, tool, format, or medium for recording an architecture description. An ADR is therefore a practical decision-recording technique, not a format mandated by ISO 42010.",{"id":366,"data":1187,"type":290},{"content":1188,"stretched":43,"withHeadings":14},[1189,1193,1197,1201,1205,1209,1213,1217],[1190,1191,1192],"ADR field","What it preserves","Why it matters",[1194,1195,1196],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1198,1199,1200],"Decision","The choice that became authoritative","Separates the selected option from discussion",[1202,1203,1204],"Status","Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[1206,1207,1208],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1210,1211,1212],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1214,1215,1216],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1218,1219,1220],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1222,"type":42},{"text":1223,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1225,"type":218},{"text":1226},"Suppose a product owner and engineering team agree that a search endpoint must return the first page of results within 400 ms at the 95th percentile under a defined reference workload.",{"id":410,"data":1228,"type":218},{"text":1229},"That target is not an ADR. It is a quality requirement. Architecture work begins by asking what design can satisfy it under the system’s other constraints.",{"id":414,"data":1231,"type":437},{"steps":1232,"title":1251,"orientation":436},[1233,1236,1239,1242,1245,1248],{"label":1234,"description":1235},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1237,"description":1238},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1240,"description":1241},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1243,"description":1244},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1246,"description":1247},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1249,"description":1250},"6. Validate","Measure the real system against the original requirement. The test result validates the NFR; the ADR alone does not.","From requirement to evidence",{"id":439,"data":1253,"type":225},{"body":1254,"title":1255,"variant":443},"Real systems rarely have one requirement and one decision. Performance may trade against cost, consistency, operability, security, maintainability, energy use or delivery risk. The useful model is therefore a traceability graph, not a one-to-one mapping.","Where the simple example stops",{"id":445,"data":1257,"type":42},{"text":1258,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1260,"type":218},{"text":1261},"One quality requirement can drive several architecture decisions. A tenant-isolation requirement, for example, can influence identity propagation, database scoping, background-job design, cache keys, audit logging, and administrative tooling.",{"id":453,"data":1263,"type":218},{"text":1264},"One architecture decision can also respond to several requirements at once. Choosing an asynchronous processing boundary might improve responsiveness and failure isolation while introducing consistency, complexity, observability, and operational trade-offs.",{"id":457,"data":1266,"type":298},{"rows":1267,"title":1280,"layout":290,"columns":1281},[1268,1271,1274,1277],{"id":461,"label":1269,"values":1270},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1272,"values":1273},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1275,"values":1276},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1278,"values":1279},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1282,1284,1286],{"id":293,"label":1283},"Requirement side",{"id":296,"label":1285},"Decision side",{"id":495,"label":1287},"Validation side",{"id":498,"data":1289,"type":42},{"text":1290,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1292,"type":218},{"text":1293},"A recurring architecture error is to write a preferred technology into the requirements layer and then treat the resulting design as inevitable.",{"id":506,"data":1295,"type":218},{"text":1296},"“The system must use PostgreSQL” can be a legitimate constraint if a contract, platform policy, compatibility requirement, licensing rule, organizational standard, or existing operational boundary actually mandates PostgreSQL. But if the real need is transactional consistency, structured querying, operational familiarity, or a specific recovery objective, the requirement should state that need and the technology selection should be recorded as a decision.",{"id":510,"data":1298,"type":290},{"content":1299,"stretched":43,"withHeadings":14},[1300,1304,1308,1312,1316,1320,1324],[1301,1302,1303],"Statement","Classification","Reason",[1305,1306,1307],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1309,1310,1311],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1313,1314,1315],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1317,1318,1319],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1321,1322,1323],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1325,1310,1326],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1328,"type":42},{"text":1329,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1331,"type":218},{"text":1332},"Decision documentation and system validation answer different questions. An ADR can show that performance, security, resilience, or maintainability were considered. It cannot by itself demonstrate that the delivered system actually achieves those properties.",{"id":549,"data":1334,"type":218},{"text":1335},"The proof must come from the validation method appropriate to the requirement: benchmark, load test, failure test, security test, architecture analysis, audit, inspection, operational telemetry, recovery exercise, user study, or another form of evidence.",{"id":553,"data":1337,"type":225},{"body":1338,"title":1339,"variant":443},"\u003Cstrong>ADR:\u003C\u002Fstrong> “We selected design X because it is expected to satisfy requirement R under assumptions A.”\u003Cbr>\u003Cstrong>Validation:\u003C\u002Fstrong> “Measured or analyzed evidence E shows whether the implemented system actually satisfies R.”","Do not confuse intent with evidence",{"id":558,"data":1341,"type":42},{"text":1342,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1344,"type":218},{"text":1345},"Not every non-functional requirement deserves an architecture decision. The important subset is the requirements that materially shape the architecture or force trade-offs across the system.",{"id":566,"data":1347,"type":218},{"text":1348},"SEI literature uses the concept of \u003Cstrong>architecturally significant requirements\u003C\u002Fstrong> for requirements with far-reaching architectural effect. Quality attributes such as performance, reliability, security, and modifiability are frequent sources of such drivers, especially when they carry high business or mission value.",{"id":570,"data":1350,"type":437},{"steps":1351,"title":1370,"orientation":436},[1352,1355,1358,1361,1364,1367],{"label":1353,"description":1354},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1356,"description":1357},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1359,"description":1360},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1362,"description":1363},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1365,"description":1366},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1368,"description":1369},"6. Record decisions only where the reasoning is worth preserving","Do not create ADRs for every local coding choice; preserve architecturally significant decisions and their rationale.","Architectural-significance test",{"id":593,"data":1372,"type":42},{"text":1373,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1375,"type":218},{"text":1376},"The most useful connection between NFRs and ADRs is traceability. A requirement should be able to point to the architecture decisions that address it; an ADR should identify the drivers it responds to; implementation work should realize the decision; validation should return to the original requirement.",{"id":601,"data":1378,"type":437},{"steps":1379,"title":1403,"orientation":436},[1380,1383,1386,1389,1392,1394,1397,1400],{"label":1381,"description":1382},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1384,"description":1385},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1387,"description":1388},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1390,"description":1391},"Options","Plausible ways to address the driver.",{"label":617,"description":1393},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1395,"description":1396},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1398,"description":1399},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1401,"description":1402},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1405,"type":42},{"text":1406,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1408,"type":225},{"body":1409,"title":1410,"variant":231},"The following section describes my own SenseFlow project structure. It is implementation evidence for the separation in this article, not a claim that every team must use the same documentation model.","Original implementation \u002F project evidence",{"id":639,"data":1412,"type":218},{"text":1413},"In SenseFlow, the project Source of Truth explicitly places non-functional requirements inside the requirements structure together with dependencies, risks, assumptions, acceptance criteria, and a validation method. The documentation model separately defines decision integrity for significant decisions.",{"id":643,"data":1415,"type":218},{"text":1416},"For significant SenseFlow decisions, the recorded fields are \u003Cstrong>Decision, Reason, Alternatives, Trade-offs, Status, and Date \u002F Version\u003C\u002Fstrong>. Major architecture and product decisions are intended to remain historically traceable rather than being overwritten when the project evolves.",{"id":647,"data":1418,"type":218},{"text":1419},"SenseFlow also assigns different operational roles to Confluence and Jira. Confluence is the structured knowledge and decision environment; Jira manages actionable delivery work. Major Jira Epics should link back to the relevant product or requirements documentation. This preserves the chain from product intent through requirements and decisions into implementation rather than turning the backlog into the architecture Source of Truth.",{"id":651,"data":1421,"type":290},{"content":1422,"stretched":43,"withHeadings":14},[1423,1427,1431,1435,1438,1441,1445],[1424,1425,1426],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1428,1429,1430],"Product \u002F requirement structure","Product goal, capability, epic, user story, acceptance criteria, technical tasks; requirements can include NFRs and validation method","Preserves what must be achieved and how success will be checked",[1432,1433,1434],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1436,1437],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1439,1440],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1442,1443,1444],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1446,1447,1448],"End-to-end traceability","Problem → need → value → product goal → requirement → implementation → validation","Keeps decision documentation connected to the actual product and evidence lifecycle",{"id":683,"data":1450,"type":225},{"body":1451,"title":1452,"variant":348},"A requirement and a decision can live close together without being collapsed into one record. The requirement remains the target; the decision remains the reasoning history; delivery work implements the decision; validation returns to the target.","What this implementation demonstrates",{"id":688,"data":1454,"type":42},{"text":1455,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1457,"type":218},{"text":1458},"The same separation is useful in enterprise-oriented project work. Architecture decisions made before requirements, risks, constraints, and acceptance conditions are sufficiently understood can turn preferences into false necessities.",{"id":696,"data":1460,"type":218},{"text":1461},"For Enterprise Aaasaasa 0.1, the relevant lesson is methodological rather than a claim about one particular ADR: requirements, architecture, validation, milestones, risk management, and acceptance belong to a connected delivery system. An architecture choice should remain traceable to the requirement or constraint it is intended to address.",{"id":700,"data":1463,"type":42},{"text":1464,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1466,"type":290},{"content":1467,"stretched":43,"withHeadings":14},[1468,1472,1476,1480,1484,1488,1492,1496,1500],[1469,1470,1471],"Failure mode","What happens","Consequence",[1473,1474,1475],"Technology disguised as requirement","A preferred solution is written as “must use X” without establishing the underlying need","Alternatives are never evaluated and architecture becomes prematurely fixed",[1477,1478,1479],"NFR hidden only inside an ADR","The decision mentions a performance\u002Fsecurity target that is absent from the requirements baseline","The target is hard to validate, prioritize or manage independently",[1481,1482,1483],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1485,1486,1487],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1489,1490,1491],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1493,1494,1495],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1497,1498,1499],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1501,1502,1503],"Backlog becomes architecture SoT","Jira tasks are treated as the only explanation of the system","Delivery state survives, but architectural rationale and quality drivers are lost",{"id":743,"data":1505,"type":42},{"text":1506,"level":237},"The ADR–NFR decision framework",{"id":747,"data":1508,"type":218},{"text":1509},"When a team encounters a new architecture concern, the following sequence helps determine what belongs in requirements, what belongs in an ADR, and what belongs in evidence.",{"id":751,"data":1511,"type":437},{"steps":1512,"title":1537,"orientation":436},[1513,1516,1519,1522,1525,1528,1531,1534],{"label":1514,"description":1515},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1517,"description":1518},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1520,"description":1521},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1523,"description":1524},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1526,"description":1527},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1529,"description":1530},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1532,"description":1533},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1535,"description":1536},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":780,"data":1539,"type":42},{"text":1540,"level":237},"What ADR and NFR are not",{"id":784,"data":1542,"type":298},{"rows":1543,"title":1556,"layout":290,"columns":1557},[1544,1546,1548,1550,1553],{"id":293,"label":1128,"values":1545},{"not":789,"why":790,"term":791},{"id":296,"label":617,"values":1547},{"not":794,"why":795,"term":796},{"id":798,"label":1398,"values":1549},{"not":800,"why":801,"term":802},{"id":804,"label":1551,"values":1552},"Backlog item",{"not":807,"why":808,"term":809},{"id":811,"label":1554,"values":1555},"Constraint",{"not":814,"why":815,"term":816},"Common category errors",[1558,1560,1562],{"id":820,"label":1559},"Concept",{"id":823,"label":1561},"It is not",{"id":826,"label":1303},{"id":828,"data":1564,"type":42},{"text":1565,"level":237},"What would change this answer?",{"id":832,"data":1567,"type":218},{"text":1568},"The terminology can evolve. ISO\u002FIEC\u002FIEEE 29148:2018 remains the current published requirements-engineering standard as of 8 October 2026, but ISO lists a Draft International Standard intended to replace it. If the new edition changes relevant terminology or requirements guidance, the version-specific references in this article should be updated.",{"id":836,"data":1570,"type":218},{"text":1571},"ADR templates can also evolve without changing the central distinction. Michael Nygard’s minimal template, MADR, organization-specific templates, architecture knowledge tools, or structured decision databases can all record decisions. The durable question is whether the record preserves enough context and rationale to understand an architecturally significant choice.",{"id":840,"data":1573,"type":218},{"text":1574},"The distinction would only collapse if an organization deliberately chose a combined artifact that stores both requirement and decision data in one document. Even then, the semantic roles remain different: one field states the required outcome or constraint; another records the chosen response.",{"id":844,"data":1576,"type":42},{"text":1577,"level":237},"Limitations",{"id":848,"data":1579,"type":218},{"text":1580},"This article uses \u003Cstrong>NFR\u003C\u002Fstrong> as practical shorthand. Some engineering methods prefer terms such as quality attribute requirement, quality requirement, system quality, constraint, service-level objective, or architecturally significant requirement. Those terms are not perfectly interchangeable, and project terminology should be explicit.",{"id":852,"data":1582,"type":218},{"text":1583},"Not every requirement can be reduced to a single numeric threshold. Security, safety, maintainability, interoperability, usability, explainability, portability, and governance can require combinations of scenarios, structural rules, analyses, process controls, and qualitative evidence. “Measurable” should mean verifiable enough for the decision, not artificially numeric.",{"id":856,"data":1585,"type":218},{"text":1586},"Not every architecture decision needs a formal ADR. The documentation cost should be proportional to architectural significance, longevity, uncertainty, trade-off complexity, and the cost of losing the rationale.",{"id":860,"data":1588,"type":42},{"text":1589,"level":237},"Conclusion",{"id":864,"data":1591,"type":218},{"text":1592},"ADR and NFR belong to different layers of architecture work. \u003Cstrong>The NFR defines a quality target, constraint, or operating condition. The ADR records a significant architectural response to one or more drivers.\u003C\u002Fstrong>",{"id":868,"data":1594,"type":218},{"text":1595},"Keeping those layers separate makes architecture easier to reason about. Requirements can be validated independently of technology. Decisions can be superseded without rewriting history. Alternatives and trade-offs remain visible. Delivery work can be traced back to architectural intent. Evidence can show whether the resulting system actually satisfies the requirement.",{"id":872,"data":1597,"type":218},{"text":1598},"The strongest chain is therefore not “NFR → ADR → done.” It is \u003Cstrong>need → requirement → architectural drivers → options → decision → implementation → validation → change\u003C\u002Fstrong>. That chain turns architecture documentation from static paperwork into a testable record of why the system has the shape it has.",{"id":876,"data":1600,"type":42},{"text":1601,"level":237},"FAQ",{"id":880,"data":1603,"type":880},{"items":1604,"title":1626},[1605,1608,1611,1614,1617,1620,1623],{"id":884,"answer":1606,"question":1607},"No. An NFR states a required quality, constraint, or operating condition. An ADR records an architecturally significant choice made in response to requirements, constraints, risks and trade-offs.","Is an ADR a non-functional requirement?",{"id":888,"answer":1609,"question":1610},"No. Only requirements that materially influence architecture need architecture-level decisions worth preserving. One NFR can also drive several ADRs, and one ADR can respond to several requirements.","Should every NFR have an ADR?",{"id":892,"answer":1612,"question":1613},"Only when PostgreSQL is genuinely imposed as an external constraint. Otherwise the underlying need should be expressed first, and selecting PostgreSQL should normally be treated as an architecture decision.","Can “use PostgreSQL” be an NFR?",{"id":896,"answer":1615,"question":1616},"No. An ADR records intent and reasoning. The requirement is validated through appropriate evidence such as testing, measurement, analysis, audit or operational telemetry.","Does an ADR prove that a performance or security requirement is met?",{"id":900,"answer":1618,"question":1619},"At minimum, an ADR should make the context and decision clear. Common structures also include status and consequences. Teams can add alternatives, rationale, trade-offs, requirement links, evidence, owners, dates and supersession relationships.","What should an ADR contain?",{"id":904,"answer":1621,"question":1622},"A requirement is architecturally significant when it materially shapes system structure, technology, data flows, deployment, cross-cutting behavior or difficult quality trade-offs, especially when failure carries high business or mission impact.","What makes an NFR architecturally significant?",{"id":908,"answer":1624,"question":1625},"Usually no. A replacement decision should normally supersede the old record so the historical reasoning remains traceable.","Should an old ADR be deleted when the architecture changes?","ADR vs NFR",{"id":913,"data":1628,"type":42},{"text":1629,"level":237},"Glossary",{"id":917,"data":1631,"type":917},{"title":1632,"entries":1633},"Core architecture terms",[1634,1636,1639,1642,1645,1647,1650,1653],{"term":922,"anchor":293,"definition":1635},"Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1637,"anchor":926,"definition":1638},"Quality attribute requirement","A requirement describing a quality property the system is expected to exhibit under defined conditions, such as performance, availability, security, reliability or modifiability.",{"term":1640,"anchor":296,"definition":1641},"Architecture Decision Record (ADR)","A durable record of an architecturally significant decision and enough context to understand why the choice was made and what consequences follow.",{"term":1643,"anchor":933,"definition":1644},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1554,"anchor":811,"definition":1646},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1648,"anchor":939,"definition":1649},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":1651,"anchor":495,"definition":1652},"Validation","Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1654,"anchor":946,"definition":1655},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":949,"data":1657,"type":42},{"text":1658,"level":237},"Primary sources and implementation evidence",{"id":953,"data":1660,"type":218},{"text":1661},"This article separates current standards from project implementation evidence. ISO\u002FIEC\u002FIEEE 29148:2018 remains current as of 8 October 2026 but is marked for revision; ISO\u002FIEC 25010:2023 and ISO\u002FIEC\u002FIEEE 42010:2022 are current published editions. SenseFlow is original project evidence for the traceability and decision-integrity model described above.",{"id":957,"data":1663,"type":965},{"link":959,"meta":1664},{"image":1665,"title":1666,"description":1667},{"url":962},"ISO\u002FIEC\u002FIEEE 29148:2018 — Requirements Engineering","Current published requirements-engineering standard. ISO states that the 2018 edition was reviewed and confirmed in 2024 and is expected to be replaced by the DIS now under development.",{"id":967,"data":1669,"type":965},{"link":969,"meta":1670},{"image":1671,"title":1672,"description":1673},{"url":962},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":975,"data":1675,"type":965},{"link":977,"meta":1676},{"image":1677,"title":1678,"description":1679},{"url":962},"ISO\u002FIEC 25010:2023 — Product Quality Model","Current product-quality model with nine quality characteristics used to specify, measure and evaluate ICT and software product quality.",{"id":983,"data":1681,"type":965},{"link":985,"meta":1682},{"image":1683,"title":1684,"description":1685},{"url":962},"ISO\u002FIEC\u002FIEEE 42010:2022 — Architecture Description","Current architecture-description standard. It specifies architecture-description concepts and conformance requirements without prescribing one recording format, notation, process or tool.",{"id":991,"data":1687,"type":965},{"link":993,"meta":1688},{"image":1689,"title":1690,"description":1691},{"url":962},"Michael Nygard — Documenting Architecture Decisions","Original influential ADR article describing lightweight records centered on context, decision, status and consequences, with superseded decisions retained for historical understanding.",{"id":999,"data":1693,"type":965},{"link":1001,"meta":1694},{"image":1695,"title":1696,"description":1697},{"url":962},"SEI — Relating Business Goals to Architecturally Significant Requirements","SEI report explaining how quality attribute requirements and business goals drive software architecture and why architecturally significant requirements need explicit elicitation.",{"id":1007,"data":1699,"type":965},{"link":1009,"meta":1700},{"image":1701,"title":1702,"description":1703},{"url":962},"SEI — Defining Non-Functional System Qualities","SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1015,"data":1705,"type":965},{"link":1017,"meta":1706},{"image":1707,"title":1708,"description":1709},{"url":962},"SEI — Attribute-Driven Design Method Collection","Architecture design method based on functional requirements, quality attribute requirements and constraints, with architectural tactics and patterns selected to satisfy quality scenarios.",{"id":1023,"data":1711,"type":965},{"link":1025,"meta":1712},{"image":1713,"title":1714,"description":1715},{"url":962},"SEI — Views and Beyond Collection","Architecture-documentation guidance emphasizing relevant views and the recording of necessary design decisions as part of architecture work.","2.31.0","ADR vs NFR explained: learn how system quality requirements drive architecture decisions, how ADRs record trade-offs, and why validation stays separate.",{"lang":7,"title":208,"content":210,"contentJson":1719,"excerpt":1031},{"time":212,"blocks":1720,"version":1030},[1721,1723,1725,1727,1729,1731,1733,1735,1737,1753,1755,1757,1759,1761,1770,1772,1774,1776,1778,1780,1791,1793,1795,1797,1806,1808,1810,1812,1814,1829,1831,1833,1835,1845,1847,1849,1851,1853,1855,1857,1859,1868,1870,1872,1883,1885,1887,1889,1891,1893,1903,1905,1907,1909,1911,1913,1925,1927,1929,1940,1942,1959,1961,1963,1965,1967,1969,1971,1973,1975,1977,1979,1981,1983,1985,1995,1997,2008,2010,2012,2016,2020,2024,2028,2032,2036,2040,2044],{"id":215,"data":1722,"type":218},{"text":217},{"id":220,"data":1724,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1726,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1728,"type":238},{"title":235,"maxLevel":236,"minLevel":237},{"id":240,"data":1730,"type":42},{"text":242,"level":237},{"id":244,"data":1732,"type":218},{"text":246},{"id":248,"data":1734,"type":218},{"text":250},{"id":252,"data":1736,"type":218},{"text":254},{"id":256,"data":1738,"type":298},{"rows":1739,"title":289,"layout":290,"columns":1750},[1740,1742,1744,1746,1748],{"id":260,"label":261,"values":1741},{"adr":263,"nfr":264},{"id":266,"label":267,"values":1743},{"adr":269,"nfr":270},{"id":272,"label":273,"values":1745},{"adr":275,"nfr":276},{"id":278,"label":279,"values":1747},{"adr":281,"nfr":282},{"id":284,"label":285,"values":1749},{"adr":287,"nfr":288},[1751,1752],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1754,"type":42},{"text":302,"level":237},{"id":304,"data":1756,"type":218},{"text":306},{"id":308,"data":1758,"type":218},{"text":310},{"id":312,"data":1760,"type":218},{"text":314},{"id":316,"data":1762,"type":290},{"content":1763,"stretched":43,"withHeadings":14},[1764,1765,1766,1767,1768,1769],[320,321,322],[324,325,326],[328,329,330],[332,333,334],[336,337,338],[340,341,342],{"id":344,"data":1771,"type":225},{"body":346,"title":347,"variant":348},{"id":350,"data":1773,"type":42},{"text":352,"level":237},{"id":354,"data":1775,"type":218},{"text":356},{"id":358,"data":1777,"type":218},{"text":360},{"id":362,"data":1779,"type":218},{"text":364},{"id":366,"data":1781,"type":290},{"content":1782,"stretched":43,"withHeadings":14},[1783,1784,1785,1786,1787,1788,1789,1790],[370,371,372],[374,375,376],[378,379,380],[382,383,384],[386,387,388],[390,391,392],[394,395,396],[398,399,400],{"id":402,"data":1792,"type":42},{"text":404,"level":237},{"id":406,"data":1794,"type":218},{"text":408},{"id":410,"data":1796,"type":218},{"text":412},{"id":414,"data":1798,"type":437},{"steps":1799,"title":435,"orientation":436},[1800,1801,1802,1803,1804,1805],{"label":418,"description":419},{"label":421,"description":422},{"label":424,"description":425},{"label":427,"description":428},{"label":430,"description":431},{"label":433,"description":434},{"id":439,"data":1807,"type":225},{"body":441,"title":442,"variant":443},{"id":445,"data":1809,"type":42},{"text":447,"level":237},{"id":449,"data":1811,"type":218},{"text":451},{"id":453,"data":1813,"type":218},{"text":455},{"id":457,"data":1815,"type":298},{"rows":1816,"title":488,"layout":290,"columns":1825},[1817,1819,1821,1823],{"id":461,"label":462,"values":1818},{"adr":464,"nfr":465,"validation":466},{"id":468,"label":469,"values":1820},{"adr":471,"nfr":472,"validation":473},{"id":475,"label":476,"values":1822},{"adr":478,"nfr":479,"validation":480},{"id":482,"label":483,"values":1824},{"adr":485,"nfr":486,"validation":487},[1826,1827,1828],{"id":293,"label":491},{"id":296,"label":493},{"id":495,"label":496},{"id":498,"data":1830,"type":42},{"text":500,"level":237},{"id":502,"data":1832,"type":218},{"text":504},{"id":506,"data":1834,"type":218},{"text":508},{"id":510,"data":1836,"type":290},{"content":1837,"stretched":43,"withHeadings":14},[1838,1839,1840,1841,1842,1843,1844],[514,515,516],[518,519,520],[522,523,524],[526,527,528],[530,531,532],[534,535,536],[538,523,539],{"id":541,"data":1846,"type":42},{"text":543,"level":237},{"id":545,"data":1848,"type":218},{"text":547},{"id":549,"data":1850,"type":218},{"text":551},{"id":553,"data":1852,"type":225},{"body":555,"title":556,"variant":443},{"id":558,"data":1854,"type":42},{"text":560,"level":237},{"id":562,"data":1856,"type":218},{"text":564},{"id":566,"data":1858,"type":218},{"text":568},{"id":570,"data":1860,"type":437},{"steps":1861,"title":591,"orientation":436},[1862,1863,1864,1865,1866,1867],{"label":574,"description":575},{"label":577,"description":578},{"label":580,"description":581},{"label":583,"description":584},{"label":586,"description":587},{"label":589,"description":590},{"id":593,"data":1869,"type":42},{"text":595,"level":237},{"id":597,"data":1871,"type":218},{"text":599},{"id":601,"data":1873,"type":437},{"steps":1874,"title":628,"orientation":436},[1875,1876,1877,1878,1879,1880,1881,1882],{"label":605,"description":606},{"label":608,"description":609},{"label":611,"description":612},{"label":614,"description":615},{"label":617,"description":618},{"label":620,"description":621},{"label":623,"description":624},{"label":626,"description":627},{"id":630,"data":1884,"type":42},{"text":632,"level":237},{"id":634,"data":1886,"type":225},{"body":636,"title":637,"variant":231},{"id":639,"data":1888,"type":218},{"text":641},{"id":643,"data":1890,"type":218},{"text":645},{"id":647,"data":1892,"type":218},{"text":649},{"id":651,"data":1894,"type":290},{"content":1895,"stretched":43,"withHeadings":14},[1896,1897,1898,1899,1900,1901,1902],[655,656,657],[659,660,661],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],{"id":683,"data":1904,"type":225},{"body":685,"title":686,"variant":348},{"id":688,"data":1906,"type":42},{"text":690,"level":237},{"id":692,"data":1908,"type":218},{"text":694},{"id":696,"data":1910,"type":218},{"text":698},{"id":700,"data":1912,"type":42},{"text":702,"level":237},{"id":704,"data":1914,"type":290},{"content":1915,"stretched":43,"withHeadings":14},[1916,1917,1918,1919,1920,1921,1922,1923,1924],[708,709,394],[711,712,713],[715,716,717],[719,720,721],[723,724,725],[727,728,729],[731,732,733],[735,736,737],[739,740,741],{"id":743,"data":1926,"type":42},{"text":745,"level":237},{"id":747,"data":1928,"type":218},{"text":749},{"id":751,"data":1930,"type":437},{"steps":1931,"title":778,"orientation":436},[1932,1933,1934,1935,1936,1937,1938,1939],{"label":755,"description":756},{"label":758,"description":759},{"label":761,"description":762},{"label":764,"description":765},{"label":767,"description":768},{"label":770,"description":771},{"label":773,"description":774},{"label":776,"description":777},{"id":780,"data":1941,"type":42},{"text":782,"level":237},{"id":784,"data":1943,"type":298},{"rows":1944,"title":817,"layout":290,"columns":1955},[1945,1947,1949,1951,1953],{"id":293,"label":294,"values":1946},{"not":789,"why":790,"term":791},{"id":296,"label":617,"values":1948},{"not":794,"why":795,"term":796},{"id":798,"label":623,"values":1950},{"not":800,"why":801,"term":802},{"id":804,"label":805,"values":1952},{"not":807,"why":808,"term":809},{"id":811,"label":812,"values":1954},{"not":814,"why":815,"term":816},[1956,1957,1958],{"id":820,"label":821},{"id":823,"label":824},{"id":826,"label":516},{"id":828,"data":1960,"type":42},{"text":830,"level":237},{"id":832,"data":1962,"type":218},{"text":834},{"id":836,"data":1964,"type":218},{"text":838},{"id":840,"data":1966,"type":218},{"text":842},{"id":844,"data":1968,"type":42},{"text":846,"level":237},{"id":848,"data":1970,"type":218},{"text":850},{"id":852,"data":1972,"type":218},{"text":854},{"id":856,"data":1974,"type":218},{"text":858},{"id":860,"data":1976,"type":42},{"text":862,"level":237},{"id":864,"data":1978,"type":218},{"text":866},{"id":868,"data":1980,"type":218},{"text":870},{"id":872,"data":1982,"type":218},{"text":874},{"id":876,"data":1984,"type":42},{"text":878,"level":237},{"id":880,"data":1986,"type":880},{"items":1987,"title":911},[1988,1989,1990,1991,1992,1993,1994],{"id":884,"answer":885,"question":886},{"id":888,"answer":889,"question":890},{"id":892,"answer":893,"question":894},{"id":896,"answer":897,"question":898},{"id":900,"answer":901,"question":902},{"id":904,"answer":905,"question":906},{"id":908,"answer":909,"question":910},{"id":913,"data":1996,"type":42},{"text":915,"level":237},{"id":917,"data":1998,"type":917},{"title":919,"entries":1999},[2000,2001,2002,2003,2004,2005,2006,2007],{"term":922,"anchor":293,"definition":923},{"term":925,"anchor":926,"definition":927},{"term":929,"anchor":296,"definition":930},{"term":932,"anchor":933,"definition":934},{"term":812,"anchor":811,"definition":936},{"term":938,"anchor":939,"definition":940},{"term":942,"anchor":495,"definition":943},{"term":945,"anchor":946,"definition":947},{"id":949,"data":2009,"type":42},{"text":951,"level":237},{"id":953,"data":2011,"type":218},{"text":955},{"id":957,"data":2013,"type":965},{"link":959,"meta":2014},{"image":2015,"title":963,"description":964},{"url":962},{"id":967,"data":2017,"type":965},{"link":969,"meta":2018},{"image":2019,"title":972,"description":973},{"url":962},{"id":975,"data":2021,"type":965},{"link":977,"meta":2022},{"image":2023,"title":980,"description":981},{"url":962},{"id":983,"data":2025,"type":965},{"link":985,"meta":2026},{"image":2027,"title":988,"description":989},{"url":962},{"id":991,"data":2029,"type":965},{"link":993,"meta":2030},{"image":2031,"title":996,"description":997},{"url":962},{"id":999,"data":2033,"type":965},{"link":1001,"meta":2034},{"image":2035,"title":1004,"description":1005},{"url":962},{"id":1007,"data":2037,"type":965},{"link":1009,"meta":2038},{"image":2039,"title":1012,"description":1013},{"url":962},{"id":1015,"data":2041,"type":965},{"link":1017,"meta":2042},{"image":2043,"title":1020,"description":1021},{"url":962},{"id":1023,"data":2045,"type":965},{"link":1025,"meta":2046},{"image":2047,"title":1028,"description":1029},{"url":962},"Post erfolgreich abgerufen",{"items":2050,"source":2079,"manualIds":2080,"manualMatchedIds":2081},[2051,2058,2065,2072],{"id":2052,"slug":2053,"title":2054,"excerpt":2055,"featuredImage":2056,"publishedAt":2057},"455","zbt-z8102ax-dual-sim-failover-test","ZBT Z8102AX 双SIM卡故障切换：有效功能、缺失功能及固件需改进之处","ZBT Z8102AX是一款双SIM卡5G OpenWrt路由器，但仅具备双SIM卡硬件并不等同于智能故障切换。该路由器能识别SIM卡并成功连接，但自动切换、调制解调器恢复、基于信号的决策以及清晰的故障切换逻辑仍需更深入的测试。","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2059,"slug":2060,"title":2061,"excerpt":2062,"featuredImage":2063,"publishedAt":2064},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","生成式人工智能解析：模型、检索、工具与应用并非同一回事","生成式AI不仅仅是一个模型。了解模型、检索、工具、上下文、运行时和应用程序如何在生产AI系统中协同工作。","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":2066,"slug":2067,"title":2068,"excerpt":2069,"featuredImage":2070,"publishedAt":2071},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","企业剧本中采用大语言模型的验收标准终极指南","掌握定义精确验收标准的艺术，确保大型语言模型在企业环境中成功集成。本全面指南提供可操作的框架、实例及最佳实践，专为剧本驱动式应用量身定制。","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2073,"slug":2074,"title":2075,"excerpt":2076,"featuredImage":2077,"publishedAt":2078},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Mastering the SEO Workflow: Essential Optimization Strategies for Organic Growth","A structured SEO workflow is crucial for sustainable organic growth. Learn the ten foundational strategies, from keyword research and technical optimization to content quality and performance analysis.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z","fallback",[],[]]