ADR vs NFR: архитектурные решения и качество системы — это не одно и то же
Нефункциональное требование (НФТ) описывает качество, ограничение или условие эксплуатации, которым должна удовлетворять система. Запись об архитектурном решении (ADR) фиксирует архитектурно значимый выбор, сделанный в ответ на требования, ограничения, риски и компромиссы. Они связаны, но не взаимозаменяемы: НФТ утверждает, что должно быть истинным; ADR объясняет, что было решено, почему и с какими последствиями.
В чём разница между НФТ и ADR?
Самое простое различие — грамматическое. Требование описывает условие, которому должна удовлетворять система. Запись о решении описывает выбор, сделанный командой.
Например, «API должен возвращать 95% запросов на чтение в течение 300 мс при согласованной эталонной нагрузке» — это требование к качеству. «Использовать сквозной кэш чтения для этой нагрузки, потому что измеренный путь только через базу данных не может достичь целевой задержки без неприемлемых затрат» — это архитектурное решение.
Первое утверждение остаётся действительным, даже если реализация изменится. Второе утверждение может быть позже заменено другим решением, если изменятся нагрузка, технология, модель затрат или доказательства.
НФТ и ADR отвечают на разные вопросы
| НФТ / требование к качеству | ADR / архитектурное решение | |
|---|---|---|
| Основной вопрос | What quality, constraint, or operating condition must the system satisfy? | What architecturally significant choice did we make, and why? |
| Типичное содержание | Measurable target, scope, condition, constraint, acceptance or validation rule | Context, decision, rationale, alternatives, trade-offs, status and consequences |
| Роль в жизненном цикле | A requirement to design for and validate | A historical record of a significant decision |
| Что это доказывает? | Measurement, test, analysis, inspection, audit or other validation evidence | The record proves what was decided, not that the resulting system meets the requirement |
| Когда это меняется | When stakeholder need, operating conditions, policy or quality target changes | When the decision is replaced, rejected, deprecated, or superseded |
Что такое НФТ в точных архитектурных терминах?
«Нефункциональное требование» — удобный отраслевой ярлык, но он может скрывать несколько разных видов утверждений. В архитектурной работе полезно различать функциональное поведение, требования к качеству и ограничения.
ISO/IEC 25010:2023 предоставляет модель качества продукта с девятью характеристиками и подхарактеристиками, которые можно использовать при спецификации и оценке качества ИКТ и программных продуктов. Работа SEI по архитектуре аналогично рассматривает требования к атрибутам качества как основные драйверы программной архитектуры.
Полезное НФТ, следовательно, — это не «система должна быть быстрой» или «платформа должна быть безопасной». Такие утверждения называют стремления. Требование, влияющее на архитектуру, должно делать ожидаемое свойство достаточно проверяемым, чтобы можно было оценивать альтернативы проектирования и последующие доказательства относительно него.
| Слабое утверждение | Более полезная форма требования | Почему разница важна |
|---|---|---|
| API должен быть быстрым | Для нагрузки W 95% операций X завершается в течение T миллисекунд | Определяет нагрузку, операцию, метрику и порог |
| Сервис должен быть доступным | Сервис S достигает согласованной цели по доступности за период измерения M, исключая явно определённые условия обслуживания | Делает доступность измеримой и определяет область |
| Данные арендатора должны быть защищены | Запрос, аутентифицированный для арендатора A, никогда не должен получать или изменять данные арендатора B через поддерживаемые пути приложения | Превращает расплывчатую цель безопасности в свойство изоляции |
| Система должна масштабироваться | Система поддерживает нагрузку W при параллелизме C, соблюдая пороги задержки и частоты ошибок | Связывает масштаб с измеримым поведением сервиса |
| Нам нужен PostgreSQL | Само по себе не НФТ; сначала укажите требуемые качества персистентности или внешнее ограничение | Выбор технологии обычно является решением, а не требованием, которое он должен удовлетворять |
Что такое запись об архитектурном решении?
Запись об архитектурном решении — это компактная запись важного архитектурного решения. Оригинальная формулировка ADR Майкла Нигарда подчёркивает контекст, решение, его статус и возникающие последствия.
Важный объект — это решение, а не шаблон. Разные команды используют разные форматы ADR. Более богатая запись может также сохранять альтернативы, критерии решения, компромиссы, доказательства, ссылки на требования и дату или версию, с которой решение применяется.
ISO/IEC/IEEE 42010:2022 шире, чем практика ADR: он определяет требования к описаниям архитектуры и их концепциям, при этом явно не предписывая какой-либо один процесс, нотацию, инструмент, формат или носитель для записи описания архитектуры. Таким образом, ADR — это практическая техника записи решений, а не формат, предписанный ISO 42010.
| Поле ADR | Что оно сохраняет | Почему это важно |
|---|---|---|
| Контекст | Проблема, силы, требования, допущения и среда, окружающие выбор | Будущие читатели могут восстановить, почему выбор был необходим |
| Решение | Выбор, который стал авторитетным | Отделяет выбранный вариант от обсуждения |
| Статус | Предложено, принято, отклонено, устарело, заменено или другое контролируемое состояние | Не позволяет старым решениям молча оставаться активными |
| Альтернативы | Другие жизнеспособные рассмотренные варианты | Показывает, что выбранное решение не было единственным возможным |
| Обоснование / компромиссы | Почему вариант был выбран и от чего он отказывается | Делает архитектурные рассуждения проверяемыми |
| Последствия | Ожидаемые положительные и отрицательные эффекты, последующая работа, риски | Связывает локальный выбор с влиянием на систему |
| Дата / версия | Когда решение стало действительным | Поддерживает историческую прослеживаемость и последующую замену |
Простейший пример: требование к задержке → архитектурное решение
Предположим, владелец продукта и команда инженеров согласны, что конечная точка поиска должна возвращать первую страницу результатов в течение 400 мс на 95-м процентиле при определённой эталонной нагрузке.
Эта цель — не ADR. Это требование к качеству. Архитектурная работа начинается с вопроса, какой дизайн может удовлетворить его при других ограничениях системы.
От требования к доказательству
NFR и ADR обычно имеют отношение «многие ко многим»
Одно требование к качеству может порождать несколько архитектурных решений. Например, требование изоляции арендаторов может влиять на распространение идентичности, область базы данных, дизайн фоновых заданий, ключи кэша, аудит-логирование и административные инструменты.
Одно архитектурное решение также может отвечать сразу на несколько требований. Выбор асинхронной границы обработки может улучшить отзывчивость и изоляцию отказов, одновременно внося компромиссы по согласованности, сложности, наблюдаемости и эксплуатации.
Почему отношение не является взаимно однозначным
| Сторона требований | Сторона решений | Сторона проверки | |
|---|---|---|---|
| Один NFR → много ADR | A broad quality target can constrain several architectural boundaries | Several coordinated decisions may be required | Evidence may need multiple tests or measurements |
| Много NFR → один ADR | Several quality and constraint drivers can point at the same design problem | One decision may balance several drivers | Each requirement still needs its own acceptance evidence |
| ADR без классического NFR | The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition | The choice can still be architecturally significant | Validate against the actual driver, not an invented NFR |
| Требование стабильно, ADR меняется | The target can remain unchanged | A better or necessary implementation choice can supersede the old decision | The new architecture must still be checked against the same target |
Выбор технологии не является автоматически требованием
Повторяющаяся архитектурная ошибка — записать предпочитаемую технологию в слой требований, а затем рассматривать получившийся дизайн как неизбежный.
«Система должна использовать PostgreSQL» может быть законным ограничением, если контракт, политика платформы, требование совместимости, правило лицензирования, организационный стандарт или существующая операционная граница действительно предписывают PostgreSQL. Но если реальная потребность — транзакционная согласованность, структурированные запросы, операционная привычность или конкретная цель восстановления, требование должно формулировать эту потребность, а выбор технологии следует записывать как решение.
| Утверждение | Классификация | Причина |
|---|---|---|
| Все чтения в области арендатора должны обеспечивать изоляцию арендаторов | Требование / свойство безопасности | Описывает свойство, которое должно соблюдаться |
| Использовать Row Level Security PostgreSQL для выбранных таблиц в области арендатора | Архитектурное решение | Выбирает механизм, предназначенный помочь удовлетворить свойство изоляции |
| Целевая среда развёртывания должна работать в одобренной среде, управляемой в ЕС | Ограничение / условие эксплуатации, подобное NFR | Ограничивает, где система может работать |
| Использовать провайдера X в регионе Y | Архитектурное / инфраструктурное решение, если не предписано извне | Выбирает конкретное решение внутри разрешённой границы |
| Задержка API на 95-м процентиле ≤ 300 мс при нагрузке W | Требование к качеству | Определяет измеримое поведение производительности |
| Ввести кэш для конечной точки X | Архитектурное решение | Выбирает тактику, предназначенную улучшить измеряемое поведение |
ADR не является доказательством того, что NFR удовлетворён
Документирование решений и проверка системы отвечают на разные вопросы. ADR может показать, что производительность, безопасность, устойчивость или сопровождаемость были рассмотрены. Он сам по себе не может продемонстрировать, что поставленная система действительно достигает этих свойств.
Доказательство должно исходить из метода проверки, соответствующего требованию: бенчмарк, нагрузочный тест, тест на отказ, тест безопасности, архитектурный анализ, аудит, инспекция, операционная телеметрия, учения по восстановлению, исследование пользователей или другая форма доказательств.
Когда NFR становится архитектурно значимым?
Не каждое нефункциональное требование заслуживает архитектурного решения. Важное подмножество — это требования, которые существенно формируют архитектуру или вынуждают идти на компромиссы в масштабах системы.
В литературе SEI используется понятие архитектурно значимых требований для требований с далеко идущим архитектурным эффектом. Атрибуты качества, такие как производительность, надёжность, безопасность и модифицируемость, часто являются источниками таких движущих факторов, особенно когда они несут высокую бизнес- или миссионную ценность.
Тест на архитектурную значимость
Более сильная модель архитектуры: требование → решение → реализация → валидация
Наиболее полезная связь между NFR и ADR — это прослеживаемость. Требование должно указывать на архитектурные решения, которые его учитывают; ADR должен определять движущие факторы, на которые он отвечает; работа по реализации должна воплощать решение; валидация должна возвращаться к исходному требованию.
Цепочка прослеживаемости архитектуры
Доказательства реализации: как я разделяю требования и решения в SenseFlow
В SenseFlow источник истины проекта явно помещает нефункциональные требования внутрь структуры требований вместе с зависимостями, рисками, допущениями, критериями приёмки и методом валидации. Модель документации отдельно определяет целостность решений для значимых решений.
Для значимых решений SenseFlow записываемые поля — это Решение, Причина, Альтернативы, Компромиссы, Статус и Дата / Версия. Основные архитектурные и продуктовые решения должны оставаться исторически прослеживаемыми, а не перезаписываться при развитии проекта.
SenseFlow также назначает разные операционные роли Confluence и Jira. Confluence — это структурированная среда знаний и решений; Jira управляет действенной работой по поставке. Крупные эпики Jira должны ссылаться на соответствующую документацию по продукту или требованиям. Это сохраняет цепочку от продуктового замысла через требования и решения к реализации, а не превращает бэклог в источник истины архитектуры.
| Слой SenseFlow | Что он содержит | Роль в разделении ADR/NFR |
|---|---|---|
| Продукт / структура требований | Продуктовая цель, возможность, эпик, пользовательская история, критерии приёмки, технические задачи; требования могут включать NFR и метод валидации | Сохраняет, что должно быть достигнуто и как будет проверяться успех |
| Целостность решений | Решение, причина, альтернативы, компромиссы, статус, дата/версия | Сохраняет, почему архитектурно значимый выбор стал авторитетным |
| Confluence | Требования, архитектура, исследования, записи решений, риски, дорожная карта и вспомогательные источники | Поддерживает концептуальный и исторический источник истины |
| Jira | Инициативы/цели, эпики, истории, задачи и состояние поставки | Выполняет утверждённую работу, не становясь концептуальным источником истины |
| Управление изменениями | Текущее состояние → новые доказательства → предлагаемое изменение → воздействие → решение | Позволяет решениям развиваться, не стирая след обоснования |
| Сквозная прослеживаемость | Проблема → потребность → ценность → продуктовая цель → требование → реализация → валидация | Поддерживает связь документации решений с фактическим продуктом и жизненным циклом доказательств |
Контекст корпоративного проекта: требования должны предшествовать архитектурным выборам
То же разделение полезно в работе над корпоративно ориентированными проектами. Архитектурные решения, принятые до того, как требования, риски, ограничения и условия приёмки достаточно поняты, могут превратить предпочтения в ложные необходимости.
Для Enterprise Aaasaasa 0.1 соответствующий урок является методологическим, а не утверждением о конкретном ADR: требования, архитектура, валидация, вехи, управление рисками и приёмка принадлежат связанной системе поставки. Архитектурный выбор должен оставаться прослеживаемым к требованию или ограничению, которое он предназначен учитывать.
Типичные сценарии отказа при смешивании ADR и NFR
| Сценарий отказа | Что происходит | Последствие |
|---|---|---|
| Технология, замаскированная под требование | Предпочтительное решение записывается как «должно использоваться X» без обоснования underlying потребности | Альтернативы никогда не оцениваются, и архитектура преждевременно фиксируется |
| NFR скрыт только внутри ADR | В решении упоминается цель по производительности/безопасности, отсутствующая в базовой линии требований | Цель трудно проверить, приоритизировать или управлять ею независимо |
| ADR рассматривается как доказательство | Предполагается, что документированный выбор означает выполнение требования | Архитектурный замысел заменяет измерение или верификацию |
| Расплывчатый NFR | Слова вроде быстрый, масштабируемый, безопасный или поддерживаемый не имеют измеримой области применения | Разные заинтересованные стороны могут считать, что одно и то же требование означает разные вещи |
| Альтернативы не зафиксированы | Команда записывает только выбранную технологию | Будущие сопровождающие не могут восстановить, почему другой вариант был отклонён |
| Нет модели замены | Старые ADR редактируются или удаляются при изменении архитектуры | Исторические обоснования исчезают, а устаревшие решения могут оставаться неоднозначными |
| Каждая деталь реализации становится ADR | Репозиторий заполняется записями низкой ценности | Важные архитектурные решения становится трудно найти |
| Бэклог становится единственным источником истины по архитектуре | Задачи Jira рассматриваются как единственное объяснение системы | Состояние поставки сохраняется, но архитектурное обоснование и драйверы качества теряются |
Структура принятия решений ADR–NFR
Когда команда сталкивается с новой архитектурной задачей, следующая последовательность помогает определить, что относится к требованиям, что относится к ADR, а что относится к доказательствам.
Тест классификации ADR–NFR
Чем ADR и NFR не являются
Типичные категориальные ошибки
| Понятие | Это не | Причина | |
|---|---|---|---|
| NFR / требование к качеству | A required quality, constraint or operating condition | A technology shopping list | Requirements should preserve the need independently from one implementation when possible |
| ADR | A record of an architecturally significant decision | The complete architecture description | Architecture also needs views, interfaces, models, responsibilities and other documentation |
| Доказательство проверки | Evidence that checks whether a requirement is satisfied | The ADR itself | Documented intent is different from measured or analyzed system behavior |
| Элемент бэклога | Actionable delivery work | A durable substitute for architecture rationale | Task state answers what is being delivered, not necessarily why the architecture exists |
| Ограничение | A condition that restricts the solution space | Always an internally chosen architecture decision | Some constraints come from regulation, contracts, existing platforms or organizational boundaries |
Что могло бы изменить этот ответ?
Терминология может развиваться. ISO/IEC/IEEE 29148:2018 остаётся текущим опубликованным стандартом инженерии требований по состоянию на 8 октября 2026 года, но ISO указывает проект международного стандарта, предназначенный для его замены. Если новое издание изменит соответствующую терминологию или руководство по требованиям, ссылки на конкретную версию в этой статье следует обновить.
Шаблоны ADR также могут развиваться, не меняя центрального различия. Минимальный шаблон Майкла Нигарда, MADR, шаблоны для конкретных организаций, инструменты архитектурных знаний или структурированные базы решений — все они могут фиксировать решения. Устойчивый вопрос заключается в том, сохраняет ли запись достаточно контекста и обоснования, чтобы понять архитектурно значимый выбор.
Различие исчезло бы только в том случае, если бы организация сознательно выбрала объединённый артефакт, хранящий данные и требования, и решения в одном документе. Даже тогда семантические роли остаются разными: одно поле указывает требуемый результат или ограничение; другое фиксирует выбранный ответ.
Ограничения
В этой статье NFR используется как практическое сокращение. Некоторые инженерные методы предпочитают такие термины, как требование к атрибуту качества, требование к качеству, качество системы, ограничение, целевой уровень обслуживания или архитектурно значимое требование. Эти термины не являются полностью взаимозаменяемыми, и терминология проекта должна быть явной.
Не каждое требование можно свести к одному числовому порогу. Безопасность, защищённость, поддерживаемость, интероперабельность, удобство использования, объяснимость, переносимость и управление могут требовать комбинаций сценариев, структурных правил, анализов, процедурных контролей и качественных доказательств. «Измеримый» должен означать достаточно проверяемый для решения, а не искусственно числовой.
Не каждое архитектурное решение требует формального ADR. Стоимость документирования должна быть пропорциональна архитектурной значимости, долговечности, неопределённости, сложности компромиссов и стоимости потери обоснования.
Заключение
ADR и NFR принадлежат разным слоям архитектурной работы. NFR определяет цель по качеству, ограничение или условие эксплуатации. ADR фиксирует значимый архитектурный ответ на один или несколько драйверов.
Сохранение этих слоёв раздельными упрощает рассуждения об архитектуре. Требования можно проверять независимо от технологии. Решения можно заменять, не переписывая историю. Альтернативы и компромиссы остаются видимыми. Работу по поставке можно проследить до архитектурного замысла. Доказательства могут показать, действительно ли полученная система удовлетворяет требованию.
Таким образом, самая сильная цепочка — это не «НФТ → ADR → готово». Это потребность → требование → архитектурные драйверы → варианты → решение → реализация → валидация → изменение. Такая цепочка превращает архитектурную документацию из статичной бумажной работы в проверяемую запись о том, почему система имеет именно такую форму.
Часто задаваемые вопросы
ADR против НФТ
Является ли ADR нефункциональным требованием?
Должно ли каждое НФТ иметь ADR?
Может ли «использовать PostgreSQL» быть НФТ?
Доказывает ли ADR, что требование к производительности или безопасности выполнено?
Что должен содержать ADR?
Что делает НФТ архитектурно значимым?
Следует ли удалять старый ADR при изменении архитектуры?
Глоссарий
Ключевые архитектурные термины
- НФТ
- Нефункциональное требование: практическое сокращение для требуемого качества системы, ограничения или условия эксплуатации; точная терминология зависит от метода и стандарта.
- Требование к атрибуту качества
- Требование, описывающее свойство качества, которое система должна демонстрировать в определённых условиях, например производительность, доступность, безопасность, надёжность или модифицируемость.
- Запись архитектурного решения (ADR)
- Долговременная запись архитектурно значимого решения и достаточного контекста, чтобы понять, почему был сделан этот выбор и какие последствия из него вытекают.
- Архитектурно значимое требование (ASR)
- Требование с достаточно далеко идущим архитектурным влиянием, которое существенно влияет на проектирование системы.
- Ограничение
- Условие, ограничивающее пространство решений, включая внешнюю политику, регулирование, платформу, совместимость, договорные или организационные границы.
- Компромисс
- Проектное соотношение, при котором улучшение одной цели, свойства или стоимостного измерения может ухудшить другое.
- Валидация
- Работа по получению доказательств, используемая для определения того, удовлетворяет ли реализованная система заявленному требованию в соответствующих условиях.
- Замещённый ADR
- Историческая запись решения, которая была заменена более новым авторитетным решением, но остаётся доступной для отслеживаемости.
Первоисточники и доказательства реализации
В этой статье текущие стандарты отделены от доказательств реализации проекта. ISO/IEC/IEEE 29148:2018 остаётся действующим по состоянию на 8 октября 2026 года, но помечен для пересмотра; ISO/IEC 25010:2023 и ISO/IEC/IEEE 42010:2022 являются текущими опубликованными редакциями. SenseFlow — это оригинальное доказательство проекта для описанной выше модели отслеживаемости и целостности решений.
ISO/IEC/IEEE 29148:2018 — Инженерия требованийТекущий опубликованный стандарт по инженерии требований. ISO указывает, что редакция 2018 года была рассмотрена и подтверждена в 2024 году и, как ожидается, будет заменена проектом DIS, который сейчас разрабатывается.
ISO/IEC/IEEE DIS 29148 — Инженерия требованийПроект международного стандарта, который сейчас разрабатывается и предназначен для замены ISO/IEC/IEEE 29148:2018.
ISO/IEC 25010:2023 — Модель качества продуктаТекущая модель качества продукта с девятью характеристиками качества, используемая для определения, измерения и оценки качества ИКТ и программных продуктов.
ISO/IEC/IEEE 42010:2022 — Описание архитектурыТекущий стандарт описания архитектуры. Он определяет понятия описания архитектуры и требования соответствия, не предписывая единый формат записи, нотацию, процесс или инструмент.
Michael Nygard — Документирование архитектурных решенийОригинальная влиятельная статья об ADR, описывающая лёгкие записи, сосредоточенные на контексте, решении, статусе и последствиях, с сохранением замещённых решений для исторического понимания.
SEI — Связь бизнес-целей с архитектурно значимыми требованиямиОтчёт SEI, объясняющий, как требования к атрибутам качества и бизнес-цели определяют архитектуру программного обеспечения и почему архитектурно значимые требования нуждаются в явном выявлении.
SEI — Определение нефункциональных качеств системыОбзор SEI, связывающий нефункциональные атрибуты/атрибуты качества с архитектурой, сценариями, компромиссами и объективной оценкой системы.
SEI — Коллекция методов Attribute-Driven DesignМетод проектирования архитектуры, основанный на функциональных требованиях, требованиях к атрибутам качества и ограничениях, с выбором архитектурных тактик и паттернов для удовлетворения сценариев качества.
SEI — Коллекция Views and BeyondРуководство по документированию архитектуры, подчёркивающее важность релевантных представлений и фиксацию необходимых проектных решений как части архитектурной работы.
Related Articles
Ultimate Guide to Acceptance Criteria for LLM Adoption in Enterprise Playbooks
Освойте искусство определения точных критериев приемки для обеспечения успешной интеграции LLM в корпоративной среде. Это всеобъемлющее руководство предоставляет практические фреймворки, примеры и лучшие практики, адаптированные для внедрения на основе плейбуков.
Резервное переключение Dual-SIM на ZBT Z8102AX: что работает, чего не хватает и что требует лучшей прошивки
ZBT Z8102AX — это 5G-роутер OpenWrt с поддержкой двух SIM-карт, но одно лишь аппаратное обеспечение с поддержкой двух SIM-карт — это не то же самое, что интеллектуальное резервирование. Роутер распознает SIM-карту и успешно подключается, но автоматическое переключение, восстановление модема, решения на основе сигнала и четкая логика резервирования все еще требуют более глубокого тестирования.
Освоение рабочего процесса SEO: Основные стратегии оптимизации для органического роста
Структурированный рабочий процесс SEO крайне важен для устойчивого органического роста. Изучите десять основополагающих стратегий, от исследования ключевых слов и технической оптимизации до качества контента и анализа производительности.
Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же
Генеративный ИИ — это больше, чем модель. Узнайте, как модели, поиск информации, инструменты, контекст, среды выполнения и приложения сочетаются друг с другом в производственных системах ИИ.