System Design и нефункциональные требования для системного аналитика

Введение в System Design: почему требования — фундамент проектирования

Добро пожаловать в курс «System Design и нефункциональные требования для системного аналитика». Это первая статья, и мы начнем с главного: почему системный дизайн — это не просто рисование квадратиков и стрелочек, и почему без качественных требований любая архитектура обречена на провал.

Многие аналитики считают, что их работа заканчивается на написании User Stories и описании полей в базе данных. Однако, когда система начинает падать под нагрузкой или данные утекают к злоумышленникам, выясняется, что проблема была заложена в самом начале — на этапе сбора требований.

Что такое System Design?

System Design (Системное проектирование) — это процесс определения архитектуры, компонентов, модулей, интерфейсов и данных для системы с целью удовлетворения заданных требований. Это мост между бизнес-потребностями («хочу интернет-магазин») и технической реализацией (микросервисы, Kubernetes, PostgreSQL).

Для системного аналитика System Design — это умение переводить «хотелки» бизнеса на язык технических ограничений и архитектурных решений. Вы не обязаны писать код, но вы обязаны понимать, как ваши требования влияют на выбор технологий.

Почему требования — это фундамент?

Представьте, что вы строите здание. Если заказчик говорит «нужен дом», вы можете построить деревянную избу. Но если позже выяснится, что в доме будут жить 500 человек, ваша изба рухнет. Фундамент был рассчитан неверно.

В IT происходит то же самое. Согласно habr.com, 80% кандидатов на собеседованиях по System Design проваливаются на одной и той же ошибке — они не фиксируют основные требования к системе. Без четких требований проектирование превращается в хаос, ведущий к неработоспособной архитектуре и перерасходу ресурсов.

Требования определяют не только что делает система, но и как она это делает. Именно здесь проходит граница между функциональными и нефункциональными требованиями.

Функциональные vs Нефункциональные требования

Чтобы спроектировать систему правильно, аналитик должен разделить требования на две категории.

1. Функциональные требования (Functional Requirements — FR)

Описывают поведение системы. Это то, что система должна делать. * Пользователь может зарегистрироваться. * Система должна отправлять уведомление после покупки. * Администратор может заблокировать пользователя.

2. Нефункциональные требования (Non-Functional Requirements — NFR)

Описывают свойства системы (атрибуты качества). Это то, как система должна работать. * Время отклика при регистрации не должно превышать 500 мс. * Система должна выдерживать 10 000 одновременных пользователей. * Данные должны быть зашифрованы по стандарту AES-256.

Именно нефункциональные требования диктуют архитектуру.

> Виной всему — нефункциональные требования, или НФТ, про которые все слышали, но мало кто действительно умеет их описывать. Проблема в том, что НФТ часто упускают. То ли потому что они не так очевидны, как функциональные требования, то ли потому что их сложно измерить. > > habr.com

Пример: Блог vs Социальная сеть

Рассмотрим простой пример. Функциональное требование одно и то же: «Пользователь может опубликовать текстовое сообщение».

Сценарий А: Личный блог * НФТ: 100 просмотров в день, потеря данных за 1 час допустима. * Решение: Обычный монолит (Monolith), одна база данных (например, MySQL), один сервер за 5L\lambdaW\lambda = 1000W = 2W (просто переписать текст в Confluence).

Этап проектирования: Перерисовать схему с монолита на микросервисы стоит 100.

После релиза: Если система упала под нагрузкой, стоимость включает потерю репутации, отток клиентов и экстренную переработку («костыли»). Это может стоить миллионы.

Как отмечается в материалах по архитектуре, умение выбирать базу данных или тип взаимодействия (синхронное/асинхронное) напрямую зависит от собранных требований к нагрузке и доступности (согласно systemanalyst.life).

Роль аналитика в System Design

Ваша задача — не просто транслировать слова бизнеса разработчикам. Вы должны задавать «неудобные» вопросы: * Сколько пользователей придет в «черную пятницу»? * Насколько критично, если история заказов будет недоступна 5 минут? * Как быстро должны появляться данные в отчетах: мгновенно или на следующее утро?

Ответы на эти вопросы формируют атрибуты качества системы, которые мы будем детально разбирать в следующих статьях курса.

Итоги

* System Design — это процесс принятия технических решений на основе требований. Нет требований — нет дизайна. Функциональные требования говорят, что строить, а нефункциональные (НФТ) — как* это должно работать (быстро, надежно, безопасно). * Одинаковые функции могут требовать абсолютно разных архитектурных решений в зависимости от нагрузки и других НФТ. * Использование простых формул, таких как Закон Литтла (), помогает аналитику заранее оценить необходимые ресурсы. * Исправление архитектурной ошибки после релиза стоит в сотни раз дороже, чем на этапе анализа.

Классификация нефункциональных требований по ISO 25010: производительность, безопасность, надежность

В предыдущей статье мы выяснили, что нефункциональные требования (NFR) — это фундамент, который определяет, как работает система. Но когда аналитик садится писать требования, перед ним встает проблема «чистого листа». Как не забыть про безопасность? Что именно писать про скорость работы? Как описать надежность, чтобы разработчики не смеялись, а бизнес не плакал?

Чтобы не изобретать велосипед, индустрия использует международные стандарты. Главный из них для системного аналитика — ISO/IEC 25010. Это не просто скучный документ, а готовый чек-лист (cheat sheet), который спасет вас от фатальных пропусков при проектировании.

Что такое ISO/IEC 25010?

ISO/IEC 25010 — это стандарт, описывающий модель качества программного обеспечения. Он пришел на смену устаревшему ISO 9126. Стандарт делит качество продукта на 8 основных характеристик.

Для System Design наиболее критичными являются три из них, которые мы разберем детально:

Производительность (Performance Efficiency)

Надежность (Reliability)

Защищенность/Безопасность (Security)

Остальные (Совместимость, Удобство использования, Сопровождаемость, Переносимость, Функциональная пригодность) также важны, но именно первая тройка определяет архитектуру серверной части (Backend).

Согласно gostinfo.ru, этот стандарт применим к любым продуктам ИКТ и позволяет четко определить параметры качества, подлежащие измерению.

---

1. Производительность (Performance Efficiency)

Многие аналитики пишут: «Система должна работать быстро». Это плохое требование. «Быстро» для человека — это 100 мс, а для высокочастотного трейдинга — это вечность.

В ISO 25010 производительность делится на подхарактеристики:

А. Временное поведение (Time Behaviour)

Это то, что мы привыкли называть Latency (задержка) и Response Time (время отклика). Это время, которое проходит от отправки запроса до получения ответа.

Как формулировать: Не используйте среднее время (Average), так как оно скрывает проблемы. Используйте перцентили. Плохо:* «Среднее время ответа поиска — 200 мс». Хорошо:* «95-й перцентиль (p95) времени ответа поиска не должен превышать 200 мс».

Б. Пропускная способность (Capacity)

Это количество операций, которое система может выполнить за единицу времени. В System Design это обычно измеряется в RPS (Requests Per Second) или TPS (Transactions Per Second).

Рассмотрим простую зависимость пропускной способности от времени обработки:

где — количество транзакций в секунду, — количество параллельных потоков (или пользователей), — время выполнения одной транзакции в секундах.

Пример: Если один поток обрабатывает запрос за 0,5 секунды (), то один поток дает 2 TPS. Чтобы получить 1000 TPS, нам нужно 500 параллельных потоков.

В. Использование ресурсов (Resource Utilization)

Требование описывает, сколько памяти, процессорного времени или дискового пространства может потреблять система. Это важно для облачной инфраструктуры, где вы платите за каждый гигабайт.

---

2. Надежность (Reliability)

Надежность — это вероятность того, что система будет работать без сбоев в течение определенного времени. Если производительность — это «как быстро мы едем», то надежность — «доедем ли мы вообще».

Подхарактеристики по ISO 25010:

А. Доступность (Availability)

Самая известная метрика. Она показывает процент времени, когда система доступна для пользователей. Часто измеряется в «девятках».

Формула расчета доступности:

где — доступность (Availability), (Mean Time Between Failures) — среднее время между сбоями (время нормальной работы), (Mean Time To Repair) — среднее время восстановления после сбоя.

Пример расчета: Представьте, что ваш сервис падает раз в 100 часов () и вы чините его 1 час ().

Доступность 99% означает, что сервис может не работать 3.65 дня в году. Для банка это катастрофа. Чтобы повысить , нужно либо увеличивать время между сбоями (), либо, что чаще проще, уменьшать время восстановления () через автоматизацию.

Б. Устойчивость к сбоям (Fault Tolerance)

Способность системы продолжать работу даже при отказе некоторых компонентов. Пример:* Если упал сервис рекомендаций, интернет-магазин должен продолжать продавать товары, просто не показывая блок «Вам может понравиться».

В. Восстанавливаемость (Recoverability)

Как быстро система может восстановить данные и состояние после сбоя. Здесь важны две метрики бизнеса: * RPO (Recovery Point Objective): Сколько данных мы готовы потерять (например, данные за последние 5 минут). * RTO (Recovery Time Objective): Сколько времени мы можем лежать (например, не более 1 часа).

---

3. Защищенность (Security)

В современном System Design безопасность — это не опция, а требование №1. Утечка данных может уничтожить бизнес быстрее, чем падение сервера.

Согласно qalight.ua, стандарт выделяет следующие аспекты безопасности:

А. Конфиденциальность (Confidentiality)

Данные доступны только тем, кто имеет на это право. Реализация:* Шифрование (TLS, AES), маскирование данных в логах.

Б. Целостность (Integrity)

Защита от несанкционированного изменения. Пример:* Баланс пользователя не может измениться без транзакции. Использование контрольных сумм и транзакционности БД (ACID).

В. Неотказуемость (Non-repudiation)

Гарантия того, что автор действия не сможет отрицать факт его совершения. Пример:* Логирование действий администратора или электронная подпись. Пользователь не может сказать «я не переводил эти деньги», если есть цифровая подпись.

Г. Аутентичность (Authenticity)

Доказательство того, что субъект является тем, за кого себя выдает. Реализация:* Пароли, двухфакторная аутентификация (2FA), биометрия.

---

Как аналитику использовать это на практике?

Не пытайтесь описать все атрибуты ISO 25010 для каждой системы. Это приведет к «параличу анализа». Используйте стандарт как карту рисков.

Алгоритм работы с NFR:

Интервью: Спросите бизнес не «какая нужна надежность?», а «сколько денег мы потеряем, если сайт ляжет на час?».

Выбор: Выберите 3-5 критичных атрибутов из ISO 25010.

Метрики: Превратите абстрактные слова в цифры (RPS, Latency, %, часы).

Фиксация: Запишите это в ТЗ или Confluence.

> Путаница между функциональными и нефункциональными требованиями — частая причина провала IT-проектов. По статистике, до 68% проектов терпят крах именно из-за некорректно сформулированных требований. > > sky.pro

Итоги

* ISO/IEC 25010 — это главный стандарт для классификации требований, который помогает не упустить важные аспекты качества. * Производительность описывается через время отклика (Latency) и пропускную способность (Throughput/RPS). Для расчетов используйте формулу . * Надежность измеряется через доступность (Availability) и зависит от частоты сбоев () и скорости восстановления (). * Безопасность включает не только защиту от хакеров, но и целостность данных, а также неотказуемость действий (Non-repudiation). * Хорошее нефункциональное требование всегда измеримо. Избегайте слов «быстро» и «надежно», используйте «200 мс» и «99.9%».