Привет! Сегодня мы продолжаем разбирать требования, которые вспоминаются нам за день перед релизом.
Если функциональные требования отвечают на вопрос «что система делает?», то эти — на вопрос «насколько хорошо она это делает и сколько это стоит бизнесу». И именно их качество больше всего влияет на архитектуру и стоимость разработки.
В этот раз сосредоточимся на этой тройке: сопровождаемость, надежность и безопасность. Это те требования, которые незаметны пользователю, но определяют, будет ли система жить года или превратится в дорогое и опасное чудо техники.
Не переключайтесь!
Первую частью можно прочитать по ссылке.
Требования к сопровождаемости
Сопровождаемость определяет, сколько времени требуется, чтобы исправить компонент системы, изменить его для повышения производительности или адаптировать к новым условиям эксплуатации.
Как и надёжность, сопровождаемость может выражаться как вероятность восстановления в рамках заданного времени. Например, если сопровождаемость оценивается в 75% за 24 часа, это значит, что у компонента есть 75% шанс быть восстановленным в течение суток.
Сопровождаемость часто измеряется метрикой MTTRS (Mean Time To Restore System) — среднее время восстановления работоспособности системы.
Примеры требований к сопровождаемости
Среднее время восстановления системы (MTTRS) после отказа не должно превышать 10 минут. MTTRS включает всё время корректирующего обслуживания и задержек.
Сервис видеостриминга должен автоматически адаптировать качество видео в зависимости от скорости интернет‑соединения пользователя, чтобы избежать буферизации.
Как формулировать требования к сопровождаемости
Оцените модульность системы. Чем более система разделена на независимые компоненты, тем проще изменять один компонент без влияния на другие.
Учитывайте жизненный цикл продукта. Если продукт будет использоваться долгосрочно, сопровождаемость критически важна, то есть стоит инвестировать в качественную архитектуру. Если создаётся MVP, ориентированный на проверку гипотез, избыточные вложения в сопровождаемость не окупятся.
Требования к надежности
Надёжность определяет, насколько вероятно, что система или её компонент будет работать без отказов в течение заданного периода времени при определённых условиях эксплуатации. Как правило, эта вероятность выражается в процентах.
Например, если надёжность системы на месяц составляет 85%, это означает, что при нормальной нагрузке в течение месяца существует 85% вероятность, что система не столкнётся с критическим отказом.
Примеры требований к надежности
Система должна работать без критических отказов в 95% случаев в течение месяца.
Все финансовые транзакции должны обрабатываться с точностью 100%, при этом система должна гарантировать целостность данных в любой момент времени.
Система должна уметь обрабатывать и восстанавливаться после ошибок без потери данных и без некорректной обработки данных.
Как формулировать и оценивать требования к надёжности
Используйте разные подходы к измерению. Определение понятия «критический отказ», а также выбор периода измерения и условий может быть не очень простым. Возможными метриками могут быть как количество критических дефектов в продакшене за определённый период, так и время между отказами (MTBF — Mean Time Between Failures) или среднее время до отказа (MTTF — Mean Time To Failure).
Оценивайте ценность метрик на тестировании и в продакшене. Поскольку не всегда есть доступ к отраслевым бенчмаркам или данным аналогичных продуктов на этапе планирования, точные требования к надёжности могут уточняться и на предрелизном тестировании, и по результатам наблюдений в продакшене.
Фокусируйтесь на качестве разработки. Даже если конечные метрики надежности будут уточняться позже, важно с самого начала иметь ревью кода, следить за качеством архитектурных решений и, по возможности, использовать автоматизированное тестирование.
Кстати об этом я рассказываю в своей статье Как понять, что вам нужны автотесты
Вышеприведенные меры позволяют значительно снизить риск отказов еще до того, как система попадет в эксплуатацию.
Требования к безопасности
Требования к безопасности описывают каким угрозам должна противостоять система и на каком уровне должна обеспечиваться защита данных, инфраструктуры и доступа пользователей.
Часть вопросов безопасности действительно может быть детализирована в функциональных требованиях (например, конкретные сценарии авторизации), но если безопасность опирается на стандарты, политики или криптографические методы, то такие требования фиксируются именно в нефункциональной части, поскольку они определяют принципы и условия реализации, а не логику поведения системы.
Примеры требований к безопасности
Платёжный шлюз должен соответствовать стандарту PCI DSS.
Клиническое программное обеспечение должно соответствовать требованиям HIPAA и GDPR.
Облачные дата‑центры должны соответствовать стандарту ISO 27001.
Как формулировать требования к безопасности
Определите конкретные угрозы. Уточните при каких условиях возможен несанкционированный доступ, какие сценарии могут привести к утечке данных, какие типы атак система должна предотвращать.
Расширьте нефункциональные требования в функциональные. Например вы можете разработать схему аутентификации и авторизации для всех акторов системы, определить ролевую модель доступа (то есть кто может создавать, просматривать, редактировать и удалять данные) и зафиксировать требования к журналированию и аудиту событий безопасности.
Укажите стандарты и нормативы. Если система должна соответствовать отраслевым стандартам, нефункциональные требования лучшее место для фиксации этих ограничений.
Связи между требованиями
Требования не существуют поодиночке. Между ними постоянно происходит обмен влияниями: усиливая одно, мы нередко ослабляем другое, а иногда — наоборот — улучшаем оба. Поэтому разбираться в связях между атрибутами качества так же важно, как и понимать их по отдельности.
Одним из самых очевидных примеров является взаимосвязь сопровождаемости, надёжности и доступности. Если систему легко поддерживать — менять компоненты, локализовать проблемы, быстро выпускать исправления — то и время восстановления после отказов сокращается. Низкий MTTR напрямую повышает доступность, то есть ту самую метрику, которая обычно фигурирует в SLA и влияет на репутацию продукта. Получается цепочка. Сопровождаемость определяет скорость восстановления, скорость восстановления влияет на надёжность восприятия системы, а вместе они формируют фактическую доступность.
Надёжность тесно соприкасается и с безопасностью — и здесь отношения сложнее. Усиленные меры защиты, дополнительные проверки, шифрование и сложные сценарии аутентификации делают систему более защищённой, но нередко снижают производительность и в отдельных случаях влияют на стабильность. В обратную сторону это тоже работает. Оптимизации, направленные на скорость, иногда сокращают количество проверок и расширяют поверхность атаки. Поэтому, формулируя требования к безопасности, важно смотреть, как они соотносятся с ожиданиями по времени отклика и устойчивости под нагрузкой.
Сопровождаемость, в свою очередь, тоже может неожиданно влиять на производительность. Чем понятнее и модульнее архитектура, тем проще оптимизировать алгоритмы, внедрять кэширование или масштабировать узкие места. Хорошая структурированность кода помогает не только быстрее чинить систему, но и эффективнее её ускорять.
При этом надёжность и производительность нередко входят в прямое противоречие. Если стремиться к максимально устойчивой системе, приходится включать механизмы репликации, транзакции, дублирование данных — всё это неизбежно замедляет работу. Если же гнаться за максимальной скоростью, иногда приходится ослаблять часть проверок, что повышает риск ошибок. Оптимальный баланс зависит от бизнес‑контекста. Где‑то можно пожертвовать долями секунды, чтобы гарантировать корректность данных, а где‑то критичен именно быстрый отклик.
Наконец, безопасность почти всегда влияет на пользовательский опыт и полезность продукта. Жёсткие требования могут делать систему медленнее или сложнее в использовании. Хороший пример — навязчивые подтверждения действий, которые повышают защиту, но создают трение в интерфейсе. Поэтому безопасность всегда должна соотноситься с UX и коммерческими целями.
Заключение
Если функциональные требования задают возможности системы, то нефункциональные задают ее зрелость.
В заключительной части мы подведем итог и рассмотрим нефункциональные требования, которые влияют на пользовательский опыт — юзабилити, совместимость и переносимость.
Если такие вопросы вам приходится разруливать между бизнесом, архитекторами и разработкой, курс «Product Manager IT-проектов» поможет системно прокачать продуктовый подход: от формулировки метрик и гипотез до работы с требованиями, архитектурными решениями, юнит-экономикой и принятием продуктовых решений на основе данных.
Для знакомства с форматом обучения и экспертами приходите на бесплатный демо-урок «Продакт 2026: какие навыки будут нужны в эпоху автоматизации», который пройдет 10 декабря в 19:00.
Разберемся, какие навыки останутся ключевыми в новой реальности, какие задачи можно делегировать ИИ уже сегодня и как развивать себя, чтобы быть востребованным продактом будущего. Записаться на урок.