[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:ru":205,"related:post:adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing:ru:1":2053},{"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","ru","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":2052},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1034,"featuredImage":1035,"featuredImageAlt":1036,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1037,"publishedAt":1038,"createdAt":1039,"updatedAt":1040,"seoLocalePaths":1041,"categories":1050,"author":1071,"translations":1076},"482","ADR vs NFR: архитектурные решения и качество системы — это не одно и то же","adr-vs-nfr-architecture-decisions-and-system-quality-are-not-the-same-thing","\u003Cp>\u003Cstrong>Нефункциональное требование (НФТ)\u003C\u002Fstrong> описывает качество, ограничение или условие эксплуатации, которым должна удовлетворять система. \u003Cstrong>Запись об архитектурном решении (ADR)\u003C\u002Fstrong> фиксирует архитектурно значимый выбор, сделанный в ответ на требования, ограничения, риски и компромиссы. Они связаны, но не взаимозаменяемы: НФТ утверждает, что должно быть истинным; 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>НФТ = требуемое качество или ограничение системы. 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>НФТ\u003C\u002Fstrong> широко используется, но не является полностью стандартизированным. В этой статье он применяется как практическое сокращение для требований к качеству и соответствующих ограничений. Актуальные стандарты были перепроверены \u003Cstrong>8 октября 2026 года\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\">В чём разница между НФТ и ADR?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Что такое НФТ в точных архитектурных терминах?\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\">Когда NFR становится архитектурно значимым?\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\">В чём разница между НФТ и ADR?\u003C\u002Fh2>\n\u003Cp>Самое простое различие — грамматическое. Требование описывает условие, которому должна удовлетворять система. Запись о решении описывает выбор, сделанный командой.\u003C\u002Fp>\n\u003Cp>Например, \u003Cstrong>«API должен возвращать 95% запросов на чтение в течение 300 мс при согласованной эталонной нагрузке»\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\">НФТ и 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\">НФТ \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\">Что такое НФТ в точных архитектурных терминах?\u003C\u002Fh2>\n\u003Cp>«Нефункциональное требование» — удобный отраслевой ярлык, но он может скрывать несколько разных видов утверждений. В архитектурной работе полезно различать \u003Cstrong>функциональное поведение\u003C\u002Fstrong>, \u003Cstrong>требования к качеству\u003C\u002Fstrong> и \u003Cstrong>ограничения\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>ISO\u002FIEC 25010:2023 предоставляет модель качества продукта с девятью характеристиками и подхарактеристиками, которые можно использовать при спецификации и оценке качества ИКТ и программных продуктов. Работа SEI по архитектуре аналогично рассматривает требования к атрибутам качества как основные драйверы программной архитектуры.\u003C\u002Fp>\n\u003Cp>Полезное НФТ, следовательно, — это не «система должна быть быстрой» или «платформа должна быть безопасной». Такие утверждения называют стремления. Требование, влияющее на архитектуру, должно делать ожидаемое свойство достаточно проверяемым, чтобы можно было оценивать альтернативы проектирования и последующие доказательства относительно него.\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 95% операций X завершается в течение 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\">Система поддерживает нагрузку W при параллелизме C, соблюдая пороги задержки и частоты ошибок\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>\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>Запись об архитектурном решении — это компактная запись важного архитектурного решения. Оригинальная формулировка 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>Предположим, владелец продукта и команда инженеров согласны, что конечная точка поиска должна возвращать первую страницу результатов в течение 400 мс на 95-м процентиле при определённой эталонной нагрузке.\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\">ADR без классического NFR\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\">Использовать Row Level Security 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\">Использовать провайдера X в регионе Y\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\">Задержка API на 95-м процентиле ≤ 300 мс при нагрузке W\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, потому что ожидается, что он удовлетворит требование R при допущениях A».\u003Cbr>\u003Cstrong>Валидация:\u003C\u002Fstrong> «Измеренные или проанализированные доказательства E показывают, действительно ли реализованная система удовлетворяет R».\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-38\">Когда NFR становится архитектурно значимым?\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>Наиболее полезная связь между NFR и 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 NFR\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 должны ссылаться на соответствующую документацию по продукту или требованиям. Это сохраняет цепочку от продуктового замысла через требования и решения к реализации, а не превращает бэклог в источник истины архитектуры.\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\u002FNFR\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\">Продуктовая цель, возможность, эпик, пользовательская история, критерии приёмки, технические задачи; требования могут включать 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\">Целостность решений\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» без обоснования underlying потребности\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>Терминология может развиваться. ISO\u002FIEC\u002FIEEE 29148:2018 остаётся текущим опубликованным стандартом инженерии требований по состоянию на 8 октября 2026 года, но ISO указывает проект международного стандарта, предназначенный для его замены. Если новое издание изменит соответствующую терминологию или руководство по требованиям, ссылки на конкретную версию в этой статье следует обновить.\u003C\u002Fp>\n\u003Cp>Шаблоны ADR также могут развиваться, не меняя центрального различия. Минимальный шаблон Майкла Нигарда, 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>Таким образом, самая сильная цепочка — это не «НФТ → 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 против НФТ\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\">Нет. НФТ описывает требуемое качество, ограничение или условие эксплуатации. 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\">Должно ли каждое НФТ иметь ADR?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Только требования, которые существенно влияют на архитектуру, нуждаются в архитектурных решениях, которые стоит сохранять. Одно НФТ также может порождать несколько 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» быть НФТ?\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\">Что делает НФТ архитектурно значимым?\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\">НФТ\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>В этой статье текущие стандарты отделены от доказательств реализации проекта. ISO\u002FIEC\u002FIEEE 29148:2018 остаётся действующим по состоянию на 8 октября 2026 года, но помечен для пересмотра; 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\">Текущая модель качества продукта с девятью характеристиками качества, используемая для определения, измерения и оценки качества ИКТ и программных продуктов.\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 — Коллекция методов Attribute-Driven Design\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 — Коллекция Views and Beyond\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Руководство по документированию архитектуры, подчёркивающее важность релевантных представлений и фиксацию необходимых проектных решений как части архитектурной работы.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1033},1791476243976,[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,743,747,751,780,784,830,834,838,842,846,850,854,858,862,866,870,874,878,882,915,919,951,955,959,969,977,985,993,1001,1009,1017,1025],{"id":215,"data":216,"type":218},"intro",{"text":217},"\u003Cstrong>Нефункциональное требование (НФТ)\u003C\u002Fstrong> описывает качество, ограничение или условие эксплуатации, которым должна удовлетворять система. \u003Cstrong>Запись об архитектурном решении (ADR)\u003C\u002Fstrong> фиксирует архитектурно значимый выбор, сделанный в ответ на требования, ограничения, риски и компромиссы. Они связаны, но не взаимозаменяемы: НФТ утверждает, что должно быть истинным; ADR объясняет, что было решено, почему и с какими последствиями.","paragraph",{"id":220,"data":221,"type":225},"direct",{"body":222,"title":223,"variant":224},"\u003Cstrong>НФТ = требуемое качество или ограничение системы. ADR = зафиксированное архитектурное решение.\u003C\u002Fstrong> Целевая задержка, цель по доступности, правило изоляции, ограничение на развёртывание или требование к сопровождаемости могут влиять на архитектуру. Затем ADR фиксирует значимый выбор, сделанный для учёта одного или нескольких таких драйверов. ADR не заменяет требование, и наличие ADR не доказывает, что требование было удовлетворено.","Прямой ответ","info","callout",{"id":227,"data":228,"type":225},"version-note",{"body":229,"title":230,"variant":231},"Термин \u003Cstrong>НФТ\u003C\u002Fstrong> широко используется, но не является полностью стандартизированным. В этой статье он применяется как практическое сокращение для требований к качеству и соответствующих ограничений. Актуальные стандарты были перепроверены \u003Cstrong>8 октября 2026 года\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},"В чём разница между НФТ и 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 должен возвращать 95% запросов на чтение в течение 300 мс при согласованной эталонной нагрузке»\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","НФТ и ADR отвечают на разные вопросы","table",[292,295],{"id":293,"label":294},"nfr","НФТ \u002F требование к качеству",{"id":296,"label":297},"adr","ADR \u002F архитектурное решение","comparison",{"id":300,"data":301,"type":42},"h-nfr",{"text":302,"level":237},"Что такое НФТ в точных архитектурных терминах?",{"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 предоставляет модель качества продукта с девятью характеристиками и подхарактеристиками, которые можно использовать при спецификации и оценке качества ИКТ и программных продуктов. Работа SEI по архитектуре аналогично рассматривает требования к атрибутам качества как основные драйверы программной архитектуры.",{"id":312,"data":313,"type":218},"p-nfr-3",{"text":314},"Полезное НФТ, следовательно, — это не «система должна быть быстрой» или «платформа должна быть безопасной». Такие утверждения называют стремления. Требование, влияющее на архитектуру, должно делать ожидаемое свойство достаточно проверяемым, чтобы можно было оценивать альтернативы проектирования и последующие доказательства относительно него.",{"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 95% операций X завершается в течение T миллисекунд","Определяет нагрузку, операцию, метрику и порог",[328,329,330],"Сервис должен быть доступным","Сервис S достигает согласованной цели по доступности за период измерения M, исключая явно определённые условия обслуживания","Делает доступность измеримой и определяет область",[332,333,334],"Данные арендатора должны быть защищены","Запрос, аутентифицированный для арендатора A, никогда не должен получать или изменять данные арендатора B через поддерживаемые пути приложения","Превращает расплывчатую цель безопасности в свойство изоляции",[336,337,338],"Система должна масштабироваться","Система поддерживает нагрузку W при параллелизме C, соблюдая пороги задержки и частоты ошибок","Связывает масштаб с измеримым поведением сервиса",[340,341,342],"Нам нужен PostgreSQL","Само по себе не НФТ; сначала укажите требуемые качества персистентности или внешнее ограничение","Выбор технологии обычно является решением, а не требованием, которое он должен удовлетворять",{"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},"Запись об архитектурном решении — это компактная запись важного архитектурного решения. Оригинальная формулировка 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},"Предположим, владелец продукта и команда инженеров согласны, что конечная точка поиска должна возвращать первую страницу результатов в течение 400 мс на 95-м процентиле при определённой эталонной нагрузке.",{"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","ADR без классического NFR",{"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],"Использовать Row Level Security PostgreSQL для выбранных таблиц в области арендатора","Архитектурное решение","Выбирает механизм, предназначенный помочь удовлетворить свойство изоляции",[526,527,528],"Целевая среда развёртывания должна работать в одобренной среде, управляемой в ЕС","Ограничение \u002F условие эксплуатации, подобное NFR","Ограничивает, где система может работать",[530,531,532],"Использовать провайдера X в регионе Y","Архитектурное \u002F инфраструктурное решение, если не предписано извне","Выбирает конкретное решение внутри разрешённой границы",[534,535,536],"Задержка API на 95-м процентиле ≤ 300 мс при нагрузке W","Требование к качеству","Определяет измеримое поведение производительности",[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, потому что ожидается, что он удовлетворит требование R при допущениях A».\u003Cbr>\u003Cstrong>Валидация:\u003C\u002Fstrong> «Измеренные или проанализированные доказательства E показывают, действительно ли реализованная система удовлетворяет R».","Не путайте замысел с доказательством",{"id":558,"data":559,"type":42},"h-asr",{"text":560,"level":237},"Когда NFR становится архитектурно значимым?",{"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},"Наиболее полезная связь между NFR и 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 NFR","Что система должна достичь или соблюсти.",{"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 должны ссылаться на соответствующую документацию по продукту или требованиям. Это сохраняет цепочку от продуктового замысла через требования и решения к реализации, а не превращает бэклог в источник истины архитектуры.",{"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\u002FNFR",[659,660,661],"Продукт \u002F структура требований","Продуктовая цель, возможность, эпик, пользовательская история, критерии приёмки, технические задачи; требования могут включать NFR и метод валидации","Сохраняет, что должно быть достигнуто и как будет проверяться успех",[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,711,715,719,723,727,731,735,739],[708,709,710],"Сценарий отказа","Что происходит","Последствие",[712,713,714],"Технология, замаскированная под требование","Предпочтительное решение записывается как «должно использоваться X» без обоснования underlying потребности","Альтернативы никогда не оцениваются, и архитектура преждевременно фиксируется",[716,717,718],"NFR скрыт только внутри ADR","В решении упоминается цель по производительности\u002Fбезопасности, отсутствующая в базовой линии требований","Цель трудно проверить, приоритизировать или управлять ею независимо",[720,721,722],"ADR рассматривается как доказательство","Предполагается, что документированный выбор означает выполнение требования","Архитектурный замысел заменяет измерение или верификацию",[724,725,726],"Расплывчатый NFR","Слова вроде быстрый, масштабируемый, безопасный или поддерживаемый не имеют измеримой области применения","Разные заинтересованные стороны могут считать, что одно и то же требование означает разные вещи",[728,729,730],"Альтернативы не зафиксированы","Команда записывает только выбранную технологию","Будущие сопровождающие не могут восстановить, почему другой вариант был отклонён",[732,733,734],"Нет модели замены","Старые ADR редактируются или удаляются при изменении архитектуры","Исторические обоснования исчезают, а устаревшие решения могут оставаться неоднозначными",[736,737,738],"Каждая деталь реализации становится ADR","Репозиторий заполняется записями низкой ценности","Важные архитектурные решения становится трудно найти",[740,741,742],"Бэклог становится единственным источником истины по архитектуре","Задачи Jira рассматриваются как единственное объяснение системы","Состояние поставки сохраняется, но архитектурное обоснование и драйверы качества теряются",{"id":744,"data":745,"type":42},"h-decision-framework",{"text":746,"level":237},"Структура принятия решений ADR–NFR",{"id":748,"data":749,"type":218},"p-framework-1",{"text":750},"Когда команда сталкивается с новой архитектурной задачей, следующая последовательность помогает определить, что относится к требованиям, что относится к ADR, а что относится к доказательствам.",{"id":752,"data":753,"type":437},"decision-flow",{"steps":754,"title":779,"orientation":436},[755,758,761,764,767,770,773,776],{"label":756,"description":757},"1. Это требуемое свойство или внешнее ограничение?","Если да, запишите или сошлитесь на требование до выбора механизма.",{"label":759,"description":760},"2. Можно ли это проверить?","Определите область применения, условие, метрику, правило приёмки, метод анализа или другие необходимые доказательства.",{"label":762,"description":763},"3. Это архитектурно значимо?","Определите, существенно ли требование влияет на структуру, технологию, данные, развёртывание или сквозные компромиссы.",{"label":765,"description":766},"4. Есть ли значимые альтернативы?","Сравните жизнеспособные тактики или варианты архитектуры, а не переходите сразу к предпочтительной технологии.",{"label":768,"description":769},"5. Стал ли выбор авторитетным?","Создайте или обновите ADR с контекстом, решением, обоснованием, альтернативами, компромиссами, статусом и последствиями.",{"label":771,"description":772},"6. Решение реализовано?","Проследите ADR в проектировании, задачах, коде, конфигурации и эксплуатации.",{"label":774,"description":775},"7. Требование выполнено?","Соберите доказательства проверки применительно к самому требованию.",{"label":777,"description":778},"8. Изменились ли условия?","Пересмотрите требование и, при необходимости, замените ADR, не стирая историю.","Тест классификации ADR–NFR",{"id":781,"data":782,"type":42},"h-what-not",{"text":783,"level":237},"Чем ADR и NFR не являются",{"id":785,"data":786,"type":298},"not-comparison",{"rows":787,"title":820,"layout":290,"columns":821},[788,794,799,806,813],{"id":293,"label":789,"values":790},"NFR \u002F требование к качеству",{"not":791,"why":792,"term":793},"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":795},{"not":796,"why":797,"term":798},"The complete architecture description","Architecture also needs views, interfaces, models, responsibilities and other documentation","A record of an architecturally significant decision",{"id":800,"label":801,"values":802},"test","Доказательство проверки",{"not":803,"why":804,"term":805},"The ADR itself","Documented intent is different from measured or analyzed system behavior","Evidence that checks whether a requirement is satisfied",{"id":807,"label":808,"values":809},"backlog","Элемент бэклога",{"not":810,"why":811,"term":812},"A durable substitute for architecture rationale","Task state answers what is being delivered, not necessarily why the architecture exists","Actionable delivery work",{"id":814,"label":815,"values":816},"constraint","Ограничение",{"not":817,"why":818,"term":819},"Always an internally chosen architecture decision","Some constraints come from regulation, contracts, existing platforms or organizational boundaries","A condition that restricts the solution space","Типичные категориальные ошибки",[822,825,828],{"id":823,"label":824},"term","Понятие",{"id":826,"label":827},"not","Это не",{"id":829,"label":516},"why",{"id":831,"data":832,"type":42},"h-change",{"text":833,"level":237},"Что могло бы изменить этот ответ?",{"id":835,"data":836,"type":218},"p-change-1",{"text":837},"Терминология может развиваться. ISO\u002FIEC\u002FIEEE 29148:2018 остаётся текущим опубликованным стандартом инженерии требований по состоянию на 8 октября 2026 года, но ISO указывает проект международного стандарта, предназначенный для его замены. Если новое издание изменит соответствующую терминологию или руководство по требованиям, ссылки на конкретную версию в этой статье следует обновить.",{"id":839,"data":840,"type":218},"p-change-2",{"text":841},"Шаблоны ADR также могут развиваться, не меняя центрального различия. Минимальный шаблон Майкла Нигарда, MADR, шаблоны для конкретных организаций, инструменты архитектурных знаний или структурированные базы решений — все они могут фиксировать решения. Устойчивый вопрос заключается в том, сохраняет ли запись достаточно контекста и обоснования, чтобы понять архитектурно значимый выбор.",{"id":843,"data":844,"type":218},"p-change-3",{"text":845},"Различие исчезло бы только в том случае, если бы организация сознательно выбрала объединённый артефакт, хранящий данные и требования, и решения в одном документе. Даже тогда семантические роли остаются разными: одно поле указывает требуемый результат или ограничение; другое фиксирует выбранный ответ.",{"id":847,"data":848,"type":42},"h-limitations",{"text":849,"level":237},"Ограничения",{"id":851,"data":852,"type":218},"p-limit-1",{"text":853},"В этой статье \u003Cstrong>NFR\u003C\u002Fstrong> используется как практическое сокращение. Некоторые инженерные методы предпочитают такие термины, как требование к атрибуту качества, требование к качеству, качество системы, ограничение, целевой уровень обслуживания или архитектурно значимое требование. Эти термины не являются полностью взаимозаменяемыми, и терминология проекта должна быть явной.",{"id":855,"data":856,"type":218},"p-limit-2",{"text":857},"Не каждое требование можно свести к одному числовому порогу. Безопасность, защищённость, поддерживаемость, интероперабельность, удобство использования, объяснимость, переносимость и управление могут требовать комбинаций сценариев, структурных правил, анализов, процедурных контролей и качественных доказательств. «Измеримый» должен означать достаточно проверяемый для решения, а не искусственно числовой.",{"id":859,"data":860,"type":218},"p-limit-3",{"text":861},"Не каждое архитектурное решение требует формального ADR. Стоимость документирования должна быть пропорциональна архитектурной значимости, долговечности, неопределённости, сложности компромиссов и стоимости потери обоснования.",{"id":863,"data":864,"type":42},"h-conclusion",{"text":865,"level":237},"Заключение",{"id":867,"data":868,"type":218},"p-conclusion-1",{"text":869},"ADR и NFR принадлежат разным слоям архитектурной работы. \u003Cstrong>NFR определяет цель по качеству, ограничение или условие эксплуатации. ADR фиксирует значимый архитектурный ответ на один или несколько драйверов.\u003C\u002Fstrong>",{"id":871,"data":872,"type":218},"p-conclusion-2",{"text":873},"Сохранение этих слоёв раздельными упрощает рассуждения об архитектуре. Требования можно проверять независимо от технологии. Решения можно заменять, не переписывая историю. Альтернативы и компромиссы остаются видимыми. Работу по поставке можно проследить до архитектурного замысла. Доказательства могут показать, действительно ли полученная система удовлетворяет требованию.",{"id":875,"data":876,"type":218},"p-conclusion-3",{"text":877},"Таким образом, самая сильная цепочка — это не «НФТ → ADR → готово». Это \u003Cstrong>потребность → требование → архитектурные драйверы → варианты → решение → реализация → валидация → изменение\u003C\u002Fstrong>. Такая цепочка превращает архитектурную документацию из статичной бумажной работы в проверяемую запись о том, почему система имеет именно такую форму.",{"id":879,"data":880,"type":42},"h-faq",{"text":881,"level":237},"Часто задаваемые вопросы",{"id":883,"data":884,"type":883},"faq",{"items":885,"title":914},[886,890,894,898,902,906,910],{"id":887,"answer":888,"question":889},"faq1","Нет. НФТ описывает требуемое качество, ограничение или условие эксплуатации. ADR фиксирует архитектурно значимый выбор, сделанный в ответ на требования, ограничения, риски и компромиссы.","Является ли ADR нефункциональным требованием?",{"id":891,"answer":892,"question":893},"faq2","Нет. Только требования, которые существенно влияют на архитектуру, нуждаются в архитектурных решениях, которые стоит сохранять. Одно НФТ также может порождать несколько ADR, а один ADR может отвечать на несколько требований.","Должно ли каждое НФТ иметь ADR?",{"id":895,"answer":896,"question":897},"faq3","Только когда PostgreSQL действительно навязан как внешнее ограничение. В противном случае сначала следует выразить лежащую в основе потребность, а выбор PostgreSQL обычно следует рассматривать как архитектурное решение.","Может ли «использовать PostgreSQL» быть НФТ?",{"id":899,"answer":900,"question":901},"faq4","Нет. ADR фиксирует намерение и обоснование. Требование подтверждается соответствующими доказательствами, такими как тестирование, измерение, анализ, аудит или эксплуатационная телеметрия.","Доказывает ли ADR, что требование к производительности или безопасности выполнено?",{"id":903,"answer":904,"question":905},"faq5","Как минимум ADR должен ясно описывать контекст и решение. Распространённые структуры также включают статус и последствия. Команды могут добавлять альтернативы, обоснование, компромиссы, ссылки на требования, доказательства, ответственных, даты и связи замещения.","Что должен содержать ADR?",{"id":907,"answer":908,"question":909},"faq6","Требование является архитектурно значимым, когда оно существенно формирует структуру системы, технологии, потоки данных, развёртывание, сквозное поведение или сложные компромиссы по качеству, особенно когда отказ несёт высокие бизнес- или миссионные последствия.","Что делает НФТ архитектурно значимым?",{"id":911,"answer":912,"question":913},"faq7","Обычно нет. Заменяющее решение должно, как правило, замещать старую запись, чтобы историческое обоснование оставалось отслеживаемым.","Следует ли удалять старый ADR при изменении архитектуры?","ADR против НФТ",{"id":916,"data":917,"type":42},"h-glossary",{"text":918,"level":237},"Глоссарий",{"id":920,"data":921,"type":920},"glossary",{"title":922,"entries":923},"Ключевые архитектурные термины",[924,927,931,934,938,940,944,947],{"term":925,"anchor":293,"definition":926},"НФТ","Нефункциональное требование: практическое сокращение для требуемого качества системы, ограничения или условия эксплуатации; точная терминология зависит от метода и стандарта.",{"term":928,"anchor":929,"definition":930},"Требование к атрибуту качества","quality-attribute-requirement","Требование, описывающее свойство качества, которое система должна демонстрировать в определённых условиях, например производительность, доступность, безопасность, надёжность или модифицируемость.",{"term":932,"anchor":296,"definition":933},"Запись архитектурного решения (ADR)","Долговременная запись архитектурно значимого решения и достаточного контекста, чтобы понять, почему был сделан этот выбор и какие последствия из него вытекают.",{"term":935,"anchor":936,"definition":937},"Архитектурно значимое требование (ASR)","asr","Требование с достаточно далеко идущим архитектурным влиянием, которое существенно влияет на проектирование системы.",{"term":815,"anchor":814,"definition":939},"Условие, ограничивающее пространство решений, включая внешнюю политику, регулирование, платформу, совместимость, договорные или организационные границы.",{"term":941,"anchor":942,"definition":943},"Компромисс","trade-off","Проектное соотношение, при котором улучшение одной цели, свойства или стоимостного измерения может ухудшить другое.",{"term":945,"anchor":495,"definition":946},"Валидация","Работа по получению доказательств, используемая для определения того, удовлетворяет ли реализованная система заявленному требованию в соответствующих условиях.",{"term":948,"anchor":949,"definition":950},"Замещённый ADR","superseded-adr","Историческая запись решения, которая была заменена более новым авторитетным решением, но остаётся доступной для отслеживаемости.",{"id":952,"data":953,"type":42},"h-sources",{"text":954,"level":237},"Первоисточники и доказательства реализации",{"id":956,"data":957,"type":218},"p-sources-note",{"text":958},"В этой статье текущие стандарты отделены от доказательств реализации проекта. ISO\u002FIEC\u002FIEEE 29148:2018 остаётся действующим по состоянию на 8 октября 2026 года, но помечен для пересмотра; ISO\u002FIEC 25010:2023 и ISO\u002FIEC\u002FIEEE 42010:2022 являются текущими опубликованными редакциями. SenseFlow — это оригинальное доказательство проекта для описанной выше модели отслеживаемости и целостности решений.",{"id":960,"data":961,"type":968},"src-iso-29148",{"link":962,"meta":963},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F72089.html",{"image":964,"title":966,"description":967},{"url":965},"","ISO\u002FIEC\u002FIEEE 29148:2018 — Инженерия требований","Текущий опубликованный стандарт по инженерии требований. ISO указывает, что редакция 2018 года была рассмотрена и подтверждена в 2024 году и, как ожидается, будет заменена проектом DIS, который сейчас разрабатывается.","linkTool",{"id":970,"data":971,"type":968},"src-iso-29148-dis",{"link":972,"meta":973},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F94091.html",{"image":974,"title":975,"description":976},{"url":965},"ISO\u002FIEC\u002FIEEE DIS 29148 — Инженерия требований","Проект международного стандарта, который сейчас разрабатывается и предназначен для замены ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":978,"data":979,"type":968},"src-iso-25010",{"link":980,"meta":981},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F78176.html",{"image":982,"title":983,"description":984},{"url":965},"ISO\u002FIEC 25010:2023 — Модель качества продукта","Текущая модель качества продукта с девятью характеристиками качества, используемая для определения, измерения и оценки качества ИКТ и программных продуктов.",{"id":986,"data":987,"type":968},"src-iso-42010",{"link":988,"meta":989},"https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F74393.html",{"image":990,"title":991,"description":992},{"url":965},"ISO\u002FIEC\u002FIEEE 42010:2022 — Описание архитектуры","Текущий стандарт описания архитектуры. Он определяет понятия описания архитектуры и требования соответствия, не предписывая единый формат записи, нотацию, процесс или инструмент.",{"id":994,"data":995,"type":968},"src-nygard",{"link":996,"meta":997},"https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions",{"image":998,"title":999,"description":1000},{"url":965},"Michael Nygard — Документирование архитектурных решений","Оригинальная влиятельная статья об ADR, описывающая лёгкие записи, сосредоточенные на контексте, решении, статусе и последствиях, с сохранением замещённых решений для исторического понимания.",{"id":1002,"data":1003,"type":968},"src-sei-asr",{"link":1004,"meta":1005},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Frelating-business-goals-to-architecturally-significant-requirements-for-software-systems\u002F",{"image":1006,"title":1007,"description":1008},{"url":965},"SEI — Связь бизнес-целей с архитектурно значимыми требованиями","Отчёт SEI, объясняющий, как требования к атрибутам качества и бизнес-цели определяют архитектуру программного обеспечения и почему архитектурно значимые требования нуждаются в явном выявлении.",{"id":1010,"data":1011,"type":968},"src-sei-nfr",{"link":1012,"meta":1013},"https:\u002F\u002Fwww.sei.cmu.edu\u002Fhistory-of-innovation\u002Fdefining-non-functional-system-qualities\u002F",{"image":1014,"title":1015,"description":1016},{"url":965},"SEI — Определение нефункциональных качеств системы","Обзор SEI, связывающий нефункциональные атрибуты\u002Fатрибуты качества с архитектурой, сценариями, компромиссами и объективной оценкой системы.",{"id":1018,"data":1019,"type":968},"src-sei-add",{"link":1020,"meta":1021},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fattribute-driven-design-method-collection\u002F",{"image":1022,"title":1023,"description":1024},{"url":965},"SEI — Коллекция методов Attribute-Driven Design","Метод проектирования архитектуры, основанный на функциональных требованиях, требованиях к атрибутам качества и ограничениях, с выбором архитектурных тактик и паттернов для удовлетворения сценариев качества.",{"id":1026,"data":1027,"type":968},"src-sei-doc",{"link":1028,"meta":1029},"https:\u002F\u002Fwww.sei.cmu.edu\u002Flibrary\u002Fviews-and-beyond-collection\u002F",{"image":1030,"title":1031,"description":1032},{"url":965},"SEI — Коллекция Views and Beyond","Руководство по документированию архитектуры, подчёркивающее важность релевантных представлений и фиксацию необходимых проектных решений как части архитектурной работы.","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":1042,"de":1043,"sr":1044,"es":1045,"fr":1046,"it":1047,"ru":1048,"zh":1049},"\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",[1051,1055,1059,1063,1067],{"id":1052,"name":1053,"slug":1054},72,"Критерии приёмки","acceptance-criteria",{"id":1056,"name":1057,"slug":1058},67,"KPI и критерии приёмки","kpis",{"id":1060,"name":1061,"slug":1062},77,"Измерение и мониторинг","measurement",{"id":1064,"name":1065,"slug":1066},76,"Бюджеты производительности","budgets",{"id":1068,"name":1069,"slug":1070},68,"Риски, контроли и доказательства","risks-and-controls",{"id":1072,"login":1073,"email":1074,"displayName":1075},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1077,1722],{"lang":1078,"title":1079,"content":1080,"contentJson":1081,"excerpt":1721},"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":1082,"blocks":1083,"version":1720},1791475659420,[1084,1087,1091,1095,1098,1101,1104,1107,1110,1134,1137,1140,1143,1146,1173,1177,1180,1183,1186,1189,1224,1227,1230,1233,1255,1259,1262,1265,1268,1291,1294,1297,1300,1330,1333,1336,1339,1343,1346,1349,1352,1374,1377,1380,1407,1410,1414,1417,1420,1423,1452,1456,1459,1462,1465,1468,1507,1510,1513,1541,1544,1566,1569,1572,1575,1578,1581,1584,1587,1590,1593,1596,1599,1602,1605,1630,1633,1660,1663,1666,1672,1678,1684,1690,1696,1702,1708,1714],{"id":215,"data":1085,"type":218},{"text":1086},"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":1088,"type":225},{"body":1089,"title":1090,"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":1092,"type":225},{"body":1093,"title":1094,"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":1096,"type":238},{"title":1097,"maxLevel":236,"minLevel":237},"Contents",{"id":240,"data":1099,"type":42},{"text":1100,"level":237},"What is the difference between an NFR and an ADR?",{"id":244,"data":1102,"type":218},{"text":1103},"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":1105,"type":218},{"text":1106},"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":1108,"type":218},{"text":1109},"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":1111,"type":298},{"rows":1112,"title":1128,"layout":290,"columns":1129},[1113,1116,1119,1122,1125],{"id":260,"label":1114,"values":1115},"Primary question",{"adr":263,"nfr":264},{"id":266,"label":1117,"values":1118},"Typical content",{"adr":269,"nfr":270},{"id":272,"label":1120,"values":1121},"Lifecycle role",{"adr":275,"nfr":276},{"id":278,"label":1123,"values":1124},"What proves it?",{"adr":281,"nfr":282},{"id":284,"label":1126,"values":1127},"When it changes",{"adr":287,"nfr":288},"NFR and ADR answer different questions",[1130,1132],{"id":293,"label":1131},"NFR \u002F quality requirement",{"id":296,"label":1133},"ADR \u002F architecture decision",{"id":300,"data":1135,"type":42},{"text":1136,"level":237},"What is an NFR in precise architectural terms?",{"id":304,"data":1138,"type":218},{"text":1139},"“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":1141,"type":218},{"text":1142},"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":1144,"type":218},{"text":1145},"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":1147,"type":290},{"content":1148,"stretched":43,"withHeadings":14},[1149,1153,1157,1161,1165,1169],[1150,1151,1152],"Weak statement","More useful requirement shape","Why the difference matters",[1154,1155,1156],"The API must be fast","For workload W, 95% of operation X completes within T milliseconds","Defines workload, operation, metric and threshold",[1158,1159,1160],"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",[1162,1163,1164],"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",[1166,1167,1168],"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",[1170,1171,1172],"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":1174,"type":225},{"body":1175,"title":1176,"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":1178,"type":42},{"text":1179,"level":237},"What is an Architecture Decision Record?",{"id":354,"data":1181,"type":218},{"text":1182},"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":1184,"type":218},{"text":1185},"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":1187,"type":218},{"text":1188},"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":1190,"type":290},{"content":1191,"stretched":43,"withHeadings":14},[1192,1196,1200,1204,1208,1212,1216,1220],[1193,1194,1195],"ADR field","What it preserves","Why it matters",[1197,1198,1199],"Context","The problem, forces, requirements, assumptions and environment surrounding the choice","Future readers can reconstruct why a choice was necessary",[1201,1202,1203],"Decision","The choice that became authoritative","Separates the selected option from discussion",[1205,1206,1207],"Status","Proposed, accepted, rejected, deprecated, superseded, or another controlled state","Prevents old decisions from silently remaining active",[1209,1210,1211],"Alternatives","Other viable options considered","Shows that the selected solution was not the only imaginable one",[1213,1214,1215],"Rationale \u002F trade-offs","Why the option was selected and what it gives up","Makes architecture reasoning inspectable",[1217,1218,1219],"Consequences","Expected positive and negative effects, follow-up work, risks","Connects a local choice to system impact",[1221,1222,1223],"Date \u002F version","When the decision became valid","Supports historical traceability and later supersession",{"id":402,"data":1225,"type":42},{"text":1226,"level":237},"The simplest example: latency requirement → architecture decision",{"id":406,"data":1228,"type":218},{"text":1229},"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":1231,"type":218},{"text":1232},"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":1234,"type":437},{"steps":1235,"title":1254,"orientation":436},[1236,1239,1242,1245,1248,1251],{"label":1237,"description":1238},"1. State the requirement","Define the quality target, workload, scope, threshold and validation method.",{"label":1240,"description":1241},"2. Identify architectural significance","Determine whether the requirement materially influences structure, technology, deployment, data flow or operating model.",{"label":1243,"description":1244},"3. Evaluate options","Compare alternatives such as indexing, caching, denormalization, asynchronous work, partitioning, or a different query architecture.",{"label":1246,"description":1247},"4. Record the decision","Capture the selected architecture choice, rationale, alternatives, trade-offs, status and consequences in an ADR.",{"label":1249,"description":1250},"5. Implement","Turn the decision into code, infrastructure, configuration and operational behavior.",{"label":1252,"description":1253},"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":1256,"type":225},{"body":1257,"title":1258,"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":1260,"type":42},{"text":1261,"level":237},"NFRs and ADRs usually have a many-to-many relationship",{"id":449,"data":1263,"type":218},{"text":1264},"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":1266,"type":218},{"text":1267},"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":1269,"type":298},{"rows":1270,"title":1283,"layout":290,"columns":1284},[1271,1274,1277,1280],{"id":461,"label":1272,"values":1273},"One NFR → many ADRs",{"adr":464,"nfr":465,"validation":466},{"id":468,"label":1275,"values":1276},"Many NFRs → one ADR",{"adr":471,"nfr":472,"validation":473},{"id":475,"label":1278,"values":1279},"ADR without a classic NFR",{"adr":478,"nfr":479,"validation":480},{"id":482,"label":1281,"values":1282},"Requirement stable, ADR changes",{"adr":485,"nfr":486,"validation":487},"Why the relationship is not one-to-one",[1285,1287,1289],{"id":293,"label":1286},"Requirement side",{"id":296,"label":1288},"Decision side",{"id":495,"label":1290},"Validation side",{"id":498,"data":1292,"type":42},{"text":1293,"level":237},"A technology choice is not automatically a requirement",{"id":502,"data":1295,"type":218},{"text":1296},"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":1298,"type":218},{"text":1299},"“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":1301,"type":290},{"content":1302,"stretched":43,"withHeadings":14},[1303,1307,1311,1315,1319,1323,1327],[1304,1305,1306],"Statement","Classification","Reason",[1308,1309,1310],"All tenant-scoped reads must enforce tenant isolation","Requirement \u002F security property","Describes a property that must hold",[1312,1313,1314],"Use PostgreSQL Row Level Security for selected tenant-scoped tables","Architecture decision","Chooses a mechanism intended to help satisfy the isolation property",[1316,1317,1318],"The deployment target must run in an approved EU-operated environment","Constraint \u002F NFR-like operating condition","Restricts where the system may operate",[1320,1321,1322],"Use provider X in region Y","Architecture \u002F deployment decision unless externally mandated","Selects a particular solution inside the allowed boundary",[1324,1325,1326],"95th-percentile API latency ≤ 300 ms under workload W","Quality requirement","Defines measurable performance behavior",[1328,1313,1329],"Introduce a cache for endpoint X","Selects a tactic intended to improve the measured behavior",{"id":541,"data":1331,"type":42},{"text":1332,"level":237},"An ADR is not proof that an NFR has been satisfied",{"id":545,"data":1334,"type":218},{"text":1335},"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":1337,"type":218},{"text":1338},"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":1340,"type":225},{"body":1341,"title":1342,"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":1344,"type":42},{"text":1345,"level":237},"When does an NFR become architecturally significant?",{"id":562,"data":1347,"type":218},{"text":1348},"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":1350,"type":218},{"text":1351},"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":1353,"type":437},{"steps":1354,"title":1373,"orientation":436},[1355,1358,1361,1364,1367,1370],{"label":1356,"description":1357},"1. Ask whether the requirement changes structure","Would different values force different components, boundaries, data paths or deployment topology?",{"label":1359,"description":1360},"2. Ask whether it constrains major technology choices","Does it eliminate otherwise viable implementation options?",{"label":1362,"description":1363},"3. Ask whether it creates cross-cutting behavior","Does it affect many components, teams, interfaces or lifecycle stages?",{"label":1365,"description":1366},"4. Ask whether it creates a difficult trade-off","Does improving this property materially affect another quality, cost, schedule, complexity or risk?",{"label":1368,"description":1369},"5. Ask whether failure is expensive","Would missing the requirement create material operational, security, regulatory, financial or product impact?",{"label":1371,"description":1372},"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":1375,"type":42},{"text":1376,"level":237},"A stronger architecture model: requirement → decision → implementation → validation",{"id":597,"data":1378,"type":218},{"text":1379},"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":1381,"type":437},{"steps":1382,"title":1406,"orientation":436},[1383,1386,1389,1392,1395,1397,1400,1403],{"label":1384,"description":1385},"Need \u002F business goal","Why the quality or constraint matters.",{"label":1387,"description":1388},"Requirement \u002F NFR","What the system must achieve or respect.",{"label":1390,"description":1391},"Architecture drivers","Which requirements are significant enough to shape the design.",{"label":1393,"description":1394},"Options","Plausible ways to address the driver.",{"label":617,"description":1396},"The selected choice, rationale, alternatives, trade-offs and consequences.",{"label":1398,"description":1399},"Implementation","Code, data model, infrastructure, interfaces and operational mechanisms that realize the decision.",{"label":1401,"description":1402},"Validation evidence","Tests, measurements, analysis or audits demonstrating whether the original requirement is actually satisfied.",{"label":1404,"description":1405},"Change \u002F supersession","New evidence or changed requirements can trigger a new ADR while preserving historical reasoning.","Architecture traceability chain",{"id":630,"data":1408,"type":42},{"text":1409,"level":237},"Implementation evidence: how I separate requirements and decisions in SenseFlow",{"id":634,"data":1411,"type":225},{"body":1412,"title":1413,"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":1415,"type":218},{"text":1416},"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":1418,"type":218},{"text":1419},"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":1421,"type":218},{"text":1422},"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":1424,"type":290},{"content":1425,"stretched":43,"withHeadings":14},[1426,1430,1434,1438,1441,1444,1448],[1427,1428,1429],"SenseFlow layer","What it contains","Role in ADR\u002FNFR separation",[1431,1432,1433],"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",[1435,1436,1437],"Decision integrity","Decision, reason, alternatives, trade-offs, status, date\u002Fversion","Preserves why an architecturally significant choice became authoritative",[667,1439,1440],"Requirements, architecture, research, decision records, risks, roadmap and supporting sources","Maintains conceptual and historical Source of Truth",[671,1442,1443],"Initiatives\u002Fgoals, epics, stories, tasks and delivery state","Executes approved work without becoming the conceptual Source of Truth",[1445,1446,1447],"Change management","Current state → new evidence → proposed change → impact → decision","Allows decisions to evolve without erasing the reasoning trail",[1449,1450,1451],"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":1453,"type":225},{"body":1454,"title":1455,"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":1457,"type":42},{"text":1458,"level":237},"Enterprise project context: requirements should precede architecture choices",{"id":692,"data":1460,"type":218},{"text":1461},"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":1463,"type":218},{"text":1464},"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":1466,"type":42},{"text":1467,"level":237},"Common failure modes when ADRs and NFRs are mixed",{"id":704,"data":1469,"type":290},{"content":1470,"stretched":43,"withHeadings":14},[1471,1475,1479,1483,1487,1491,1495,1499,1503],[1472,1473,1474],"Failure mode","What happens","Consequence",[1476,1477,1478],"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",[1480,1481,1482],"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",[1484,1485,1486],"ADR treated as proof","A documented choice is assumed to mean the requirement is satisfied","Architecture intent replaces measurement or verification",[1488,1489,1490],"Vague NFR","Words such as fast, scalable, secure or maintainable have no measurable scope","Different stakeholders can believe the same requirement means different things",[1492,1493,1494],"No alternatives recorded","The team records only the selected technology","Future maintainers cannot reconstruct why another option was rejected",[1496,1497,1498],"No supersession model","Old ADRs are edited or deleted when the architecture changes","Historical reasoning disappears and stale decisions can remain ambiguous",[1500,1501,1502],"Every implementation detail becomes an ADR","The repository fills with low-value records","Important architecture choices become difficult to find",[1504,1505,1506],"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":744,"data":1508,"type":42},{"text":1509,"level":237},"The ADR–NFR decision framework",{"id":748,"data":1511,"type":218},{"text":1512},"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":752,"data":1514,"type":437},{"steps":1515,"title":1540,"orientation":436},[1516,1519,1522,1525,1528,1531,1534,1537],{"label":1517,"description":1518},"1. Is this a required property or external constraint?","If yes, write or reference the requirement before choosing a mechanism.",{"label":1520,"description":1521},"2. Can it be validated?","Define the scope, condition, metric, acceptance rule, analysis method or other evidence needed.",{"label":1523,"description":1524},"3. Is it architecturally significant?","Identify whether the requirement materially shapes structure, technology, data, deployment or cross-cutting trade-offs.",{"label":1526,"description":1527},"4. Are there meaningful alternatives?","Compare viable tactics or architecture options rather than jumping directly to a preferred technology.",{"label":1529,"description":1530},"5. Has a choice become authoritative?","Create or update the ADR with context, decision, rationale, alternatives, trade-offs, status and consequences.",{"label":1532,"description":1533},"6. Is the decision implemented?","Trace the ADR into design, tasks, code, configuration and operations.",{"label":1535,"description":1536},"7. Is the requirement satisfied?","Collect validation evidence against the requirement itself.",{"label":1538,"description":1539},"8. Did conditions change?","Re-evaluate the requirement and, when necessary, supersede the ADR without erasing history.","ADR–NFR classification test",{"id":781,"data":1542,"type":42},{"text":1543,"level":237},"What ADR and NFR are not",{"id":785,"data":1545,"type":298},{"rows":1546,"title":1559,"layout":290,"columns":1560},[1547,1549,1551,1553,1556],{"id":293,"label":1131,"values":1548},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1550},{"not":796,"why":797,"term":798},{"id":800,"label":1401,"values":1552},{"not":803,"why":804,"term":805},{"id":807,"label":1554,"values":1555},"Backlog item",{"not":810,"why":811,"term":812},{"id":814,"label":1557,"values":1558},"Constraint",{"not":817,"why":818,"term":819},"Common category errors",[1561,1563,1565],{"id":823,"label":1562},"Concept",{"id":826,"label":1564},"It is not",{"id":829,"label":1306},{"id":831,"data":1567,"type":42},{"text":1568,"level":237},"What would change this answer?",{"id":835,"data":1570,"type":218},{"text":1571},"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":839,"data":1573,"type":218},{"text":1574},"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":843,"data":1576,"type":218},{"text":1577},"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":847,"data":1579,"type":42},{"text":1580,"level":237},"Limitations",{"id":851,"data":1582,"type":218},{"text":1583},"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":855,"data":1585,"type":218},{"text":1586},"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":859,"data":1588,"type":218},{"text":1589},"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":863,"data":1591,"type":42},{"text":1592,"level":237},"Conclusion",{"id":867,"data":1594,"type":218},{"text":1595},"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":871,"data":1597,"type":218},{"text":1598},"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":875,"data":1600,"type":218},{"text":1601},"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":879,"data":1603,"type":42},{"text":1604,"level":237},"FAQ",{"id":883,"data":1606,"type":883},{"items":1607,"title":1629},[1608,1611,1614,1617,1620,1623,1626],{"id":887,"answer":1609,"question":1610},"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":891,"answer":1612,"question":1613},"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":895,"answer":1615,"question":1616},"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":899,"answer":1618,"question":1619},"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":903,"answer":1621,"question":1622},"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":907,"answer":1624,"question":1625},"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":911,"answer":1627,"question":1628},"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":916,"data":1631,"type":42},{"text":1632,"level":237},"Glossary",{"id":920,"data":1634,"type":920},{"title":1635,"entries":1636},"Core architecture terms",[1637,1640,1643,1646,1649,1651,1654,1657],{"term":1638,"anchor":293,"definition":1639},"NFR","Non-functional requirement: practical shorthand for a required system quality, constraint, or operating condition; exact terminology varies by method and standard.",{"term":1641,"anchor":929,"definition":1642},"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":1644,"anchor":296,"definition":1645},"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":1647,"anchor":936,"definition":1648},"Architecturally Significant Requirement (ASR)","A requirement with sufficiently far-reaching architectural impact that it materially influences the system design.",{"term":1557,"anchor":814,"definition":1650},"A condition that restricts the solution space, including external policy, regulation, platform, compatibility, contractual or organizational boundaries.",{"term":1652,"anchor":942,"definition":1653},"Trade-off","A design relationship in which improving one objective, property or cost dimension can worsen another.",{"term":1655,"anchor":495,"definition":1656},"Validation","Evidence-producing work used to determine whether the implemented system satisfies the stated requirement under the relevant conditions.",{"term":1658,"anchor":949,"definition":1659},"Superseded ADR","A historical decision record that has been replaced by a newer authoritative decision while remaining available for traceability.",{"id":952,"data":1661,"type":42},{"text":1662,"level":237},"Primary sources and implementation evidence",{"id":956,"data":1664,"type":218},{"text":1665},"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":960,"data":1667,"type":968},{"link":962,"meta":1668},{"image":1669,"title":1670,"description":1671},{"url":965},"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":970,"data":1673,"type":968},{"link":972,"meta":1674},{"image":1675,"title":1676,"description":1677},{"url":965},"ISO\u002FIEC\u002FIEEE DIS 29148 — Requirements Engineering","Draft International Standard currently under development and intended to replace ISO\u002FIEC\u002FIEEE 29148:2018.",{"id":978,"data":1679,"type":968},{"link":980,"meta":1680},{"image":1681,"title":1682,"description":1683},{"url":965},"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":986,"data":1685,"type":968},{"link":988,"meta":1686},{"image":1687,"title":1688,"description":1689},{"url":965},"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":994,"data":1691,"type":968},{"link":996,"meta":1692},{"image":1693,"title":1694,"description":1695},{"url":965},"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":1002,"data":1697,"type":968},{"link":1004,"meta":1698},{"image":1699,"title":1700,"description":1701},{"url":965},"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":1010,"data":1703,"type":968},{"link":1012,"meta":1704},{"image":1705,"title":1706,"description":1707},{"url":965},"SEI — Defining Non-Functional System Qualities","SEI overview connecting non-functional\u002Fquality attributes with architecture, scenarios, trade-offs and objective system evaluation.",{"id":1018,"data":1709,"type":968},{"link":1020,"meta":1710},{"image":1711,"title":1712,"description":1713},{"url":965},"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":1026,"data":1715,"type":968},{"link":1028,"meta":1716},{"image":1717,"title":1718,"description":1719},{"url":965},"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":1723,"excerpt":1034},{"time":212,"blocks":1724,"version":1033},[1725,1727,1729,1731,1733,1735,1737,1739,1741,1757,1759,1761,1763,1765,1774,1776,1778,1780,1782,1784,1795,1797,1799,1801,1810,1812,1814,1816,1818,1833,1835,1837,1839,1849,1851,1853,1855,1857,1859,1861,1863,1872,1874,1876,1887,1889,1891,1893,1895,1897,1907,1909,1911,1913,1915,1917,1929,1931,1933,1944,1946,1963,1965,1967,1969,1971,1973,1975,1977,1979,1981,1983,1985,1987,1989,1999,2001,2012,2014,2016,2020,2024,2028,2032,2036,2040,2044,2048],{"id":215,"data":1726,"type":218},{"text":217},{"id":220,"data":1728,"type":225},{"body":222,"title":223,"variant":224},{"id":227,"data":1730,"type":225},{"body":229,"title":230,"variant":231},{"id":233,"data":1732,"type":238},{"title":235,"maxLevel":236,"minLevel":237},{"id":240,"data":1734,"type":42},{"text":242,"level":237},{"id":244,"data":1736,"type":218},{"text":246},{"id":248,"data":1738,"type":218},{"text":250},{"id":252,"data":1740,"type":218},{"text":254},{"id":256,"data":1742,"type":298},{"rows":1743,"title":289,"layout":290,"columns":1754},[1744,1746,1748,1750,1752],{"id":260,"label":261,"values":1745},{"adr":263,"nfr":264},{"id":266,"label":267,"values":1747},{"adr":269,"nfr":270},{"id":272,"label":273,"values":1749},{"adr":275,"nfr":276},{"id":278,"label":279,"values":1751},{"adr":281,"nfr":282},{"id":284,"label":285,"values":1753},{"adr":287,"nfr":288},[1755,1756],{"id":293,"label":294},{"id":296,"label":297},{"id":300,"data":1758,"type":42},{"text":302,"level":237},{"id":304,"data":1760,"type":218},{"text":306},{"id":308,"data":1762,"type":218},{"text":310},{"id":312,"data":1764,"type":218},{"text":314},{"id":316,"data":1766,"type":290},{"content":1767,"stretched":43,"withHeadings":14},[1768,1769,1770,1771,1772,1773],[320,321,322],[324,325,326],[328,329,330],[332,333,334],[336,337,338],[340,341,342],{"id":344,"data":1775,"type":225},{"body":346,"title":347,"variant":348},{"id":350,"data":1777,"type":42},{"text":352,"level":237},{"id":354,"data":1779,"type":218},{"text":356},{"id":358,"data":1781,"type":218},{"text":360},{"id":362,"data":1783,"type":218},{"text":364},{"id":366,"data":1785,"type":290},{"content":1786,"stretched":43,"withHeadings":14},[1787,1788,1789,1790,1791,1792,1793,1794],[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":1796,"type":42},{"text":404,"level":237},{"id":406,"data":1798,"type":218},{"text":408},{"id":410,"data":1800,"type":218},{"text":412},{"id":414,"data":1802,"type":437},{"steps":1803,"title":435,"orientation":436},[1804,1805,1806,1807,1808,1809],{"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":1811,"type":225},{"body":441,"title":442,"variant":443},{"id":445,"data":1813,"type":42},{"text":447,"level":237},{"id":449,"data":1815,"type":218},{"text":451},{"id":453,"data":1817,"type":218},{"text":455},{"id":457,"data":1819,"type":298},{"rows":1820,"title":488,"layout":290,"columns":1829},[1821,1823,1825,1827],{"id":461,"label":462,"values":1822},{"adr":464,"nfr":465,"validation":466},{"id":468,"label":469,"values":1824},{"adr":471,"nfr":472,"validation":473},{"id":475,"label":476,"values":1826},{"adr":478,"nfr":479,"validation":480},{"id":482,"label":483,"values":1828},{"adr":485,"nfr":486,"validation":487},[1830,1831,1832],{"id":293,"label":491},{"id":296,"label":493},{"id":495,"label":496},{"id":498,"data":1834,"type":42},{"text":500,"level":237},{"id":502,"data":1836,"type":218},{"text":504},{"id":506,"data":1838,"type":218},{"text":508},{"id":510,"data":1840,"type":290},{"content":1841,"stretched":43,"withHeadings":14},[1842,1843,1844,1845,1846,1847,1848],[514,515,516],[518,519,520],[522,523,524],[526,527,528],[530,531,532],[534,535,536],[538,523,539],{"id":541,"data":1850,"type":42},{"text":543,"level":237},{"id":545,"data":1852,"type":218},{"text":547},{"id":549,"data":1854,"type":218},{"text":551},{"id":553,"data":1856,"type":225},{"body":555,"title":556,"variant":443},{"id":558,"data":1858,"type":42},{"text":560,"level":237},{"id":562,"data":1860,"type":218},{"text":564},{"id":566,"data":1862,"type":218},{"text":568},{"id":570,"data":1864,"type":437},{"steps":1865,"title":591,"orientation":436},[1866,1867,1868,1869,1870,1871],{"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":1873,"type":42},{"text":595,"level":237},{"id":597,"data":1875,"type":218},{"text":599},{"id":601,"data":1877,"type":437},{"steps":1878,"title":628,"orientation":436},[1879,1880,1881,1882,1883,1884,1885,1886],{"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":1888,"type":42},{"text":632,"level":237},{"id":634,"data":1890,"type":225},{"body":636,"title":637,"variant":231},{"id":639,"data":1892,"type":218},{"text":641},{"id":643,"data":1894,"type":218},{"text":645},{"id":647,"data":1896,"type":218},{"text":649},{"id":651,"data":1898,"type":290},{"content":1899,"stretched":43,"withHeadings":14},[1900,1901,1902,1903,1904,1905,1906],[655,656,657],[659,660,661],[663,664,665],[667,668,669],[671,672,673],[675,676,677],[679,680,681],{"id":683,"data":1908,"type":225},{"body":685,"title":686,"variant":348},{"id":688,"data":1910,"type":42},{"text":690,"level":237},{"id":692,"data":1912,"type":218},{"text":694},{"id":696,"data":1914,"type":218},{"text":698},{"id":700,"data":1916,"type":42},{"text":702,"level":237},{"id":704,"data":1918,"type":290},{"content":1919,"stretched":43,"withHeadings":14},[1920,1921,1922,1923,1924,1925,1926,1927,1928],[708,709,710],[712,713,714],[716,717,718],[720,721,722],[724,725,726],[728,729,730],[732,733,734],[736,737,738],[740,741,742],{"id":744,"data":1930,"type":42},{"text":746,"level":237},{"id":748,"data":1932,"type":218},{"text":750},{"id":752,"data":1934,"type":437},{"steps":1935,"title":779,"orientation":436},[1936,1937,1938,1939,1940,1941,1942,1943],{"label":756,"description":757},{"label":759,"description":760},{"label":762,"description":763},{"label":765,"description":766},{"label":768,"description":769},{"label":771,"description":772},{"label":774,"description":775},{"label":777,"description":778},{"id":781,"data":1945,"type":42},{"text":783,"level":237},{"id":785,"data":1947,"type":298},{"rows":1948,"title":820,"layout":290,"columns":1959},[1949,1951,1953,1955,1957],{"id":293,"label":789,"values":1950},{"not":791,"why":792,"term":793},{"id":296,"label":617,"values":1952},{"not":796,"why":797,"term":798},{"id":800,"label":801,"values":1954},{"not":803,"why":804,"term":805},{"id":807,"label":808,"values":1956},{"not":810,"why":811,"term":812},{"id":814,"label":815,"values":1958},{"not":817,"why":818,"term":819},[1960,1961,1962],{"id":823,"label":824},{"id":826,"label":827},{"id":829,"label":516},{"id":831,"data":1964,"type":42},{"text":833,"level":237},{"id":835,"data":1966,"type":218},{"text":837},{"id":839,"data":1968,"type":218},{"text":841},{"id":843,"data":1970,"type":218},{"text":845},{"id":847,"data":1972,"type":42},{"text":849,"level":237},{"id":851,"data":1974,"type":218},{"text":853},{"id":855,"data":1976,"type":218},{"text":857},{"id":859,"data":1978,"type":218},{"text":861},{"id":863,"data":1980,"type":42},{"text":865,"level":237},{"id":867,"data":1982,"type":218},{"text":869},{"id":871,"data":1984,"type":218},{"text":873},{"id":875,"data":1986,"type":218},{"text":877},{"id":879,"data":1988,"type":42},{"text":881,"level":237},{"id":883,"data":1990,"type":883},{"items":1991,"title":914},[1992,1993,1994,1995,1996,1997,1998],{"id":887,"answer":888,"question":889},{"id":891,"answer":892,"question":893},{"id":895,"answer":896,"question":897},{"id":899,"answer":900,"question":901},{"id":903,"answer":904,"question":905},{"id":907,"answer":908,"question":909},{"id":911,"answer":912,"question":913},{"id":916,"data":2000,"type":42},{"text":918,"level":237},{"id":920,"data":2002,"type":920},{"title":922,"entries":2003},[2004,2005,2006,2007,2008,2009,2010,2011],{"term":925,"anchor":293,"definition":926},{"term":928,"anchor":929,"definition":930},{"term":932,"anchor":296,"definition":933},{"term":935,"anchor":936,"definition":937},{"term":815,"anchor":814,"definition":939},{"term":941,"anchor":942,"definition":943},{"term":945,"anchor":495,"definition":946},{"term":948,"anchor":949,"definition":950},{"id":952,"data":2013,"type":42},{"text":954,"level":237},{"id":956,"data":2015,"type":218},{"text":958},{"id":960,"data":2017,"type":968},{"link":962,"meta":2018},{"image":2019,"title":966,"description":967},{"url":965},{"id":970,"data":2021,"type":968},{"link":972,"meta":2022},{"image":2023,"title":975,"description":976},{"url":965},{"id":978,"data":2025,"type":968},{"link":980,"meta":2026},{"image":2027,"title":983,"description":984},{"url":965},{"id":986,"data":2029,"type":968},{"link":988,"meta":2030},{"image":2031,"title":991,"description":992},{"url":965},{"id":994,"data":2033,"type":968},{"link":996,"meta":2034},{"image":2035,"title":999,"description":1000},{"url":965},{"id":1002,"data":2037,"type":968},{"link":1004,"meta":2038},{"image":2039,"title":1007,"description":1008},{"url":965},{"id":1010,"data":2041,"type":968},{"link":1012,"meta":2042},{"image":2043,"title":1015,"description":1016},{"url":965},{"id":1018,"data":2045,"type":968},{"link":1020,"meta":2046},{"image":2047,"title":1023,"description":1024},{"url":965},{"id":1026,"data":2049,"type":968},{"link":1028,"meta":2050},{"image":2051,"title":1031,"description":1032},{"url":965},"Post erfolgreich abgerufen",{"items":2054,"source":2083,"manualIds":2084,"manualMatchedIds":2085},[2055,2062,2069,2076],{"id":2056,"slug":2057,"title":2058,"excerpt":2059,"featuredImage":2060,"publishedAt":2061},"455","zbt-z8102ax-dual-sim-failover-test","Резервное переключение Dual-SIM на ZBT Z8102AX: что работает, чего не хватает и что требует лучшей прошивки","ZBT Z8102AX — это 5G-роутер OpenWrt с поддержкой двух SIM-карт, но одно лишь аппаратное обеспечение с поддержкой двух SIM-карт — это не то же самое, что интеллектуальное резервирование. Роутер распознает SIM-карту и успешно подключается, но автоматическое переключение, восстановление модема, решения на основе сигнала и четкая логика резервирования все еще требуют более глубокого тестирования.","\u002Fuploads\u002F2026\u002F06\u002Fopenwrt-router-review-dual-sim-03-1781620592829-7t77j7.webp","2026-06-16T10:40:00.000Z",{"id":2063,"slug":2064,"title":2065,"excerpt":2066,"featuredImage":2067,"publishedAt":2068},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Освоение рабочего процесса SEO: Основные стратегии оптимизации для органического роста","Структурированный рабочий процесс SEO крайне важен для устойчивого органического роста. Изучите десять основополагающих стратегий, от исследования ключевых слов и технической оптимизации до качества контента и анализа производительности.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":2070,"slug":2071,"title":2072,"excerpt":2073,"featuredImage":2074,"publishedAt":2075},"435","ultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks","Ultimate Guide to Acceptance Criteria for LLM Adoption in Enterprise Playbooks","Освойте искусство определения точных критериев приемки для обеспечения успешной интеграции LLM в корпоративной среде. Это всеобъемлющее руководство предоставляет практические фреймворки, примеры и лучшие практики, адаптированные для внедрения на основе плейбуков.","\u002Fuploads\u002F2026\u002F09\u002Fultimate-guide-to-acceptance-criteria-for-llm-adoption-in-enterprise-playbooks-1788540267775-zgr6mm.webp","2026-09-06T11:50:00.000Z",{"id":2077,"slug":2078,"title":2079,"excerpt":2080,"featuredImage":2081,"publishedAt":2082},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же","Генеративный ИИ — это больше, чем модель. Узнайте, как модели, поиск информации, инструменты, контекст, среды выполнения и приложения сочетаются друг с другом в производственных системах ИИ.","\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","fallback",[],[]]