На старте проекта требования часто выглядят как более или менее полный список того, что система должна уметь. Есть сценарии, роли, бизнес-цели, ограничения, иногда даже список интеграций и отдельный блок нефункциональных требований. Формально этого достаточно, чтобы начать обсуждение. Практически — почти никогда.
Причина простая: не все требования одинаково влияют на форму системы. Одни помогают уточнить поведение на уровне пользовательского сценария. Другие же меняют границы подсистем, способы взаимодействия, модель хранения данных, стратегию отказоустойчивости, observability и даже организацию команд. Именно такие требования и становятся архитектурными драйверами.
Проблема в том, что на раннем этапе они часто маскируются под “ещё одну важную деталь”. Если аналитика не помогает увидеть их вовремя, архитектура начинает строиться вокруг вторичных сценариев, а потом вынуждена догонять реальность через переделки.
В прошлой статье мы отделяли симптом от причины и задавали измеримые метрики с порогами. Теперь следующий шаг: смотрим, какие из этих измеримых требований становятся архитектурными драйверами. Продолжим сквозной кейс проектирования лунной базы и посмотрим, как требования начинают управлять архитектурой ещё до того, как команда выбрала конкретный стек, модель взаимодействия и форму разбиения системы.
В статье
- Почему не все требования одинаково важны для архитектуры
- Три уровня требований: бизнес, функциональные, нефункциональные
- Как распознать архитектурно значимое требование
- Лунная база: какие требования действительно меняют систему
- Сквозной пример: от сценария к форме системы
- Как требования начинают конфликтовать
- Что аналитик может сделать раньше схемы и технологий
- Короткий checklist для отбора архитектурных драйверов
- Что дальше
Почему не все требования одинаково важны для архитектуры
Если упростить, требования можно разделить на два больших класса.
Первые описывают что именно должна делать система. Например:
- вести учёт критичных запасов;
- показывать состояние модулей базы;
- принимать команды на перемещение роботизированных платформ;
- уведомлять экипаж о критичных событиях;
- давать наземному центру доступ к сводной картине состояния базы.
Это всё важно. Но само по себе ещё не определяет архитектуру.
Вторые отвечают на вопрос, в каких условиях система должна это делать:
- при ограниченной и нестабильной связи;
- при частичной автономности модулей;
- с жёстким приоритетом безопасности;
- с ограничением по энергопотреблению;
- с возможностью работы при деградации части контура;
- с высокой ценой ошибки и трудной стоимостью восстановления.
Вот здесь и начинает формироваться архитектура. Не из самого use case, а из того, в какой реальности система обязана этот use case выполнять.
Три уровня требований: бизнес, функциональные, нефункциональные
Полезно держать очень простую рабочую модель.
Бизнес-требования
Отвечают на вопрос, зачем система вообще нужна и какой результат она должна дать.
В кейсе лунной базы это может быть:
- обеспечить устойчивое автономное функционирование экипажа;
- снизить риск потери критичных ресурсов;
- сократить нагрузку на ручное управление и работу наземного контура координации;
- повысить предсказуемость логистики и эксплуатации.
Функциональные требования
Описывают, что система должна уметь делать:
- учитывать ресурсы;
- маршрутизировать команды;
- собирать и отдавать телеметрию;
- планировать поставки и распределение ресурсов;
- включать деградационные режимы.
Нефункциональные требования
Описывают, как именно система должна себя вести, в каких условиях и с какими ограничениями:
- допустимая задержка;
- доступность;
- время восстановления;
- автономность;
- объём допустимой потери данных;
- требования к безопасности и подтверждению команд;
- эксплуатационная наблюдаемость.
На практике именно третий слой чаще всего и становится архитектурно решающим. Но «чаще всего» — не «всегда»: функциональное требование тоже бывает драйвером, если оно меняет модель системы. «Команда должна исполняться локально без Земли» или «поставка должна перепланироваться автоматически» — это функциональные требования, и они напрямую диктуют форму. Точнее говоря, драйвер обычно рождается на пересечении функционального сценария, NFR и ограничения среды, а не в одном из слоёв изолированно.
Как распознать архитектурно значимое требование
Хороший рабочий вопрос звучит так:
Если это требование убрать или смягчить, изменится ли форма системы?
Если ответ “да”, это уже кандидат в архитектурный драйвер.
Признаки архитектурно значимого требования:
- влияет на границы контекстов и подсистем;
- меняет способ взаимодействия между частями системы;
- влияет на стратегию хранения, синхронизации и консистентности;
- влияет на deployment и топологию (как и где разворачиваются части системы и как они связаны);
- влияет на способы отказа и восстановления;
- влияет на объём и форму observability;
- влияет на организацию команд и ownership (кто за какую часть системы отвечает).
Примеры:
- “данные о критичных запасах должны быть доступны локально даже при потере связи” — да, это архитектурный драйвер;
- “оператор должен видеть зелёный индикатор вместо серого” — важная деталь UX, но вряд ли архитектурный драйвер;
- “аварийные команды не могут исполняться без локального подтверждения” — да, это уже меняет контуры принятия решений, безопасность и логику маршрутизации;
- “отчёт по использованию ресурсов нужен раз в сутки” — скорее всего нет, если за этим не стоит тяжёлая аналитическая нагрузка или отдельный processing pipeline.
Лунная база: какие требования действительно меняют систему
В кейсе лунной базы очень быстро становится видно, какие требования влияют на архитектуру сильнее остальных.
1. Автономность при потере связи
Это не “ещё одно ограничение среды”, а один из главных архитектурных драйверов.
Он влияет на:
- локальные решения;
- кэширование и буферизацию;
- допустимые режимы eventual consistency (согласованность «не сразу, но в итоге»);
- распределение ответственности между Землёй и базой;
- операции и взаимодействия, которые нельзя выполнять синхронно.
2. Приоритет безопасности над удобством
Если критичная команда должна требовать локального подтверждения, это меняет не только UX. Это меняет:
- поток управления;
- модель доверия;
- журналирование и аудит;
- возможные сценарии автоматизации.
3. Ограниченность энергоресурсов
Энергия на базе — не просто операционная метрика, а реальное ограничение архитектуры. Оно влияет на:
- частоту телеметрии;
- приоритеты вычислительных задач;
- работу деградационных режимов;
- offloading (перенос) задач между локальным и внешним контуром.
4. Разделение критичных и некритичных данных
Если система не различает:
- критичную телеметрию;
- полезную, но некритичную диагностику;
- данные для локальных решений;
- данные для долгого анализа;
то дальше начинают ломаться и pipeline, и наблюдаемость, и логика синхронизации.
5. Поэтапное расширение базы
Лунная база почти наверняка не строится “целиком сразу”. Это означает:
- модульность;
- совместимость между очередями развития;
- миграцию доменной модели;
- постепенное усложнение архитектуры без полного переписывания.
Это тоже архитектурный драйвер, потому что он меняет цену решений на старте.
flowchart TD
A["Требования"] --> B["Бизнес-цели"]
A --> C["Функциональные сценарии"]
A --> D["Ограничения среды и эксплуатации"]
D --> E["Архитектурные драйверы"]
C --> E
B --> E
E --> F["Границы подсистем"]
E --> G["Модель взаимодействий"]
E --> H["Согласованность данных"]
E --> I["Надёжность и деградация"]
E --> J["Deployment и topology"]
Сквозной пример: от сценария к форме системы
Соберём цепочку на сквозном сценарии серии: связь с Землёй пропала на 40 минут, а энергобюджет просел. Здесь хорошо видно, как сценарий превращается в форму:
- Сценарий → канал недоступен, энергии меньше, решения нужны сейчас.
- Требование → критичные для жизнеобеспечения операции исполняются локально, без ожидания Земли.
- Метрика + порог → 100% операций из перечня критичных для жизнеобеспечения исполняются локально; подтверждение ≤ 1 с при недоступном канале.
- Архитектурный драйвер → нельзя ставить критичное решение в зависимость от внешнего контура.
- Следствие для системы → локальный контур принятия решений, классификация команд, журнал аудита, деградационный режим при просадке энергии.
Ту же логику удобно держать в виде таблицы — она и есть рабочий мостик от требования к архитектуре:
| Требование | Почему это драйвер | Что меняет в архитектуре |
|---|---|---|
| Критичные операции исполняются локально при потере связи | Нельзя ждать внешний контур: канал недоступен до 40 минут | Локальный контур принятия решений, классификация команд, журнал аудита, деградационный режим |
| Критичная телеметрия доступна контуру принятия решений за ≤ 2 с | Иначе решение в дефиците энергии опирается на устаревшие данные | Приоритизация потоков, отдельная очередь/канал для критичных сигналов |
| При просадке энергобюджета сохраняется жизнеобеспечение | Энергия — жёсткое ограничение, обслужить все нагрузки нельзя | Приоритизация нагрузок, отключаемые некритичные сервисы, деградация по уровням |
Таблица полезна тем, что не даёт остановиться на «это важное требование»: третий столбец заставляет назвать конкретное изменение формы системы. Если столбец пустой — требование, возможно, и не драйвер.
Как требования начинают конфликтовать
На этом этапе становится особенно важно не только собрать требования, но и увидеть, где они противоречат друг другу.
В сложной системе почти никогда не бывает так, что все требования одновременно усиливают одно решение.
В лунной базе типичные конфликты могут выглядеть так:
- автономность против централизованного контроля;
- безопасность против скорости операции;
- консистентность против доступности;
- подробная телеметрия против энергобюджета и пропускной способности канала;
- удобство эксплуатации против сложности изоляции контуров.
Если команда не фиксирует такие конфликты рано, дальше почти неизбежно происходит одно из двух:
- архитектура строится так, будто конфликта нет;
- конфликт всплывает позже в виде “неожиданного” технического долга.
Хорошая аналитика не обязана сама решать эти конфликты. Но она обязана сделать их видимыми.
Что аналитик может сделать раньше схемы и технологий
До выбора технологий и до появления детальной схемы аналитик уже может сделать очень много полезного.
1. Отделить обязательное от желательного
Не всё, что звучит важно, одинаково критично для формы системы. Полезно рано разделить:
- must-have;
- should-have;
- can-be-deferred;
- nice-to-have.
2. Зафиксировать сценарии, где требования особенно остры
Например:
- потеря связи на заданное время (40 минут или 6 часов);
- нехватка расходников в одном модуле;
- конфликт между локальным и внешним контуром управления;
- перегрузка телеметрии при аварийном режиме.
Это делает требования не абстрактными, а конкретными и проверяемыми.
3. Уточнить измеримые критерии
Если требование нельзя хотя бы приблизительно измерить, оно почти не участвует в архитектурном выборе.
4. Явно показать зависимости между требованиями
Часто отдельные требования кажутся независимыми, пока их не положить рядом. А потом выясняется, что:
- одно делает другое очень дорогим;
- одно смягчает другое;
- одно можно выполнить только ценой роста сложности в другом контуре.
5. Принести в разговор реальность эксплуатации
Аналитик не обязан быть field engineer, но он может вовремя вернуть в разговор:
- кто и как реально будет обслуживать систему;
- где она будет ломаться;
- кто должен будет разбираться в инциденте в 3 часа ночи;
- что будет стоить дорого не в разработке, а в жизни системы.
Короткий checklist для отбора архитектурных драйверов
Перед тем как превращать требования в архитектурную схему, полезно проверить:
- Какие требования реально меняют форму системы?
- Какие из них связаны с ограничениями среды, а не просто с поведением UI?
- Где требования начинают конфликтовать друг с другом?
- Какие требования влияют на консистентность, взаимодействия и границы контекстов?
- Какие требования изменят развёртывание (deployment), наблюдаемость (observability) или эксплуатационные режимы?
- Где сейчас не хватает измеримости?
- Какие требования команда пока считает “деталями”, хотя они уже архитектурно значимы?
Если этот отбор не сделан, архитектура часто начинает обслуживать то, что лучше видно, а не то, что действительно определяет систему.
Что дальше
Когда архитектурные драйверы видны, появляется следующий вопрос: как разрезать предметную область так, чтобы модель выдерживала эти ограничения. Следующая статья серии — DDD для аналитика без культа терминов — про то, как строить доменную модель, которая не ломается о реальные границы и конфликты системы.
Комментарии