Що таке нефункціональні вимоги: швидкість, безпека, доступність, масштабованість і надійність?

1. Що таке нефункціональні вимоги (NFR) простими словами і чим вони відрізняються від функціональних?

Нефункціональні вимоги (Non-Functional Requirements, NFR) визначають критерії якості, за якими оцінюється працездатність та ефективність усієї системи. Якщо спростити, вони описують не те, що саме робить програма, а те, наскільки якісно, швидко, безпечно та стабільно вона виконує свої завдання за різних умов.

Головні відмінності між ними:

Обсяг і фокус: Функціональні вимоги описують конкретні дії, поведінку, бізнес-правила та функції (наприклад, «користувач може додати товар до кошика» або «авторизуватися через Google»). Нефункціональні вимоги фокусуються на стандартах якості, обмеженнях та системних характеристиках (наприклад, «кошик завантажується за 1 секунду» або «паролі користувачів шифруються за стандартом AES»).

Реалізація та тестування: Функціональні вимоги втілюються на основних етапах розробки та перевіряються через виконання конкретних дій. Нефункціональні вимоги закладаються в архітектуру системи й тестуються за допомогою спеціальних інструментів навантажувального, стресового або безпекового тестування.

Наслідки ігнорування: Якщо сфокусуватися лише на функціях, сайт буде формально працювати, але виявиться повільним, вразливим для зламу чи нестабільним при напливі відвідувачів. Якщо ж ігнорувати функції, ви отримаєте ідеально безпечний і швидкий сайт, який не вирішує жодного бізнес-завдання.

2. Що включає вимога до швидкості та продуктивності сайту?

Продуктивність визначає, наскільки швидко програмна система реагує на дії користувача під певним навантаженням. Вимога до швидкості — це не просто абстрактне побажання, вона безпосередньо впливає на конверсії та дохід бізнесу. 53% користувачів залишають мобільний сайт, якщо він завантажується довше 3 секунд.

Повноцінна вимога до продуктивності включає:

Конкретні обмеження часу відгуку (Response Time) для ключових сценаріїв використання.

Параметри навантаження, за яких цей час має зберігатися (наприклад, «при 5000 користувачів на годину»).

Технічні умови тестування: тип пристрою, браузер та тип мережевого з’єднання (наприклад, «через LTE-з’єднання на мобільних пристроях у браузері Chrome»).

Економічне обґрунтування: згідно з дослідженнями Deloitte, покращення швидкості мобільного сайту лише на 0,1 секунди підвищує конверсію в ритейлі на 8,4%, а інженери Amazon зафіксували, що кожні 100 мс затримки сервера знижують виручку компанії на 1%.

3. Які показники можна використовувати для оцінки швидкості?

Для вимірювання швидкодії застосовуються технічні метрики та стандарти:

TTFB (Time to First Byte): час від моменту запиту користувача до отримання першого байта інформації від сервера. Показник демонструє якість хостингу й швидкість обробки коду сервером (рекомендовано < 800 мс, найкращі сервери відповідають за 200–400 мс).

Core Web Vitals від Google — офіційні фактори ранжування, що оцінюють реальний досвід взаємодії:

LCP (Largest Contentful Paint): час відтворення найбільшого видимого елемента на сторінці (зображення чи тексту); користувач відчуває, що сайт завантажився (має бути менше 2,5 секунди).

INP (Interaction to Next Paint): час затримки реакції інтерфейсу на будь-який клік чи взаємодію користувача (має бути менше 200 мс).

CLS (Cumulative Layout Shift): рівень стабільності верстки; вимірює, чи не зміщуються кнопки й тексти під час завантаження сторінки (оптимальний показник менше 0,1).

PageSpeed Score: оцінка оптимізації сторінки в межах сервісу Google PageSpeed Insights (наприклад, вимога «перебувати в зеленій зоні» або мати оцінку «не менше 90/100»).

4. Що означає вимога до безпеки сайту і які ризики потрібно враховувати при проєктуванні?

Вимога до безпеки (Security) гарантує захист системи й даних користувачів від несанкційного доступу, витоків, зловмисних атак та збереження конфіденційності, цілісності й доступності інформації.

Ще на етапі проєктування архітектори закладають рішення для таких ризиків:

Компрометація персональних та платіжних даних: вимагає використання стійких алгоритмів шифрування (наприклад, 256-бітного шифрування AES або RSA), обов'язкового використання протоколів SSL/HTTPS та дотримання жорстких індустріальних стандартів (GDPR для персональних даних, PCI DSS для платіжних шлюзів).

Несанкціонований доступ до функцій: вимагає впровадження гнучкого контролю доступу на основі ролей (RBAC), інтеграції корпоративного входу (SSO через SAML/OAuth2) та автоматизованого керування обліковими записами (SCIM).

Ризики використання штучного інтелекту (AI): швидка інтеграція сторонніх AI-плагінів створює нові вектори для витоку чутливих даних компанії на зовнішні сервери. На етапі проєктування необхідно передбачити сувору аутентифікацію, логування та контроль усіх запитів до сторонніх моделей.

Зовнішні атаки (DDoS): потребують попереднього налаштування CDN та систем фільтрації шкідливого трафіку на мережевому рівні.

5. Що таке доступність сайту і чим технічна доступність сервісу відрізняється від accessibility для людей з обмеженнями?

Доступність (Availability) описує частку часу, протягом якого вебсайт повністю працездатний і відкритий для використання клієнтами. Зазвичай вона фіксується у відсотках від загального часу роботи на місяць чи рік (наприклад, «доступність 99,98% щомісяця»). Ці показники безпосередньо формують вимоги до угод про рівень послуг (SLA). Наприклад, цільовий показник доступності 99,9% дозволяє максимум 8 годин 46 хвилин технічного простою на рік, а рівень 99,999% («п'ять дев'яток») обмежує сумарний простій до 5 хвилин 15 секунд на рік.

Головна відмінність:

Технічна доступність (Availability): це інфраструктурний показник безперебійної роботи серверів і мережі. Вона перевіряється сервісами моніторингу (наприклад, Host-Tracker), які надсилають автоматичні запити з різних куточків світу для оцінки часу відповіді сервера.

Інклюзивна доступність (Accessibility / Web Accessibility): це зручність користування сайтом для людей з інвалідністю або когнітивними порушеннями. Вона включає наявність звукового супроводу для незрячих, підтримку читання екрана (screen readers), можливість керувати інтерфейсом без мишки, контрастність шрифтів та підтримку автоматичних перекладів.

6. Що таке масштабованість і як сайт повинен поводитися при зростанні навантаження?

Масштабованість (Scalability) — це здатність вебсистеми ефективно справлятися зі зростанням навантаження (збільшенням обсягів даних, кількості зареєстрованих користувачів, контенту або паралельних запитів) без критичного зниження швидкості роботи та капітальної переробки архітектури.

При зростанні навантаження (наприклад, під час великих розпродажів, вірусних рекламних кампаній чи сезонних піків) якісно спроєктований сайт повинен:

Утримувати швидкість роботи в межах встановлених лімітів (наприклад, обробляти до 10 000 одночасних сесій або до 1 000 000 відвідувачів на добу без уповільнення відповіді сервера).

Задіяти додаткові ресурси (горизонтальне або вертикальне автомасшабування в хмарі), рівномірно розподіляючи трафік, щоб уникнути утворення «вузьких місць» (bottlenecks).

Ефективно кешувати дані, щоб знизити навантаження на базу даних та бекенд.

7. Що таке надійність, uptime і відмовостійкість сайту?

Надійність (Reliability): математична ймовірність того, що система працюватиме безвідмовно та коректно виконуватиме свої функції протягом визначеного проміжку часу (наприклад, «робота без помилок у 95% випадків протягом місяця»).

Uptime (час безперебійної роботи): відсоткове вираження часу, коли сайт перебуває в активному робочому стані й готовий приймати користувачів.

Відмовостійкість (Fault Tolerance, FT) та Висока доступність (High Availability, HA): це два різні підходи до забезпечення надійності системи:

Відмовостійкість (FT): орієнтована на повну відсутність пауз у роботі. Якщо один сервер чи жорсткий диск виходить з ладу, система миттєво й непомітно для користувача перемикається на резервний компонент. Вона вимагає глибокого апаратного дублювання (дзеркалювання дисків, резервних контролерів), складних консистентних баз даних та коштує значно дорожче.

Висока доступність (HA): орієнтована на максимальне скорочення часу простою та швидке відновлення. Вона допускає короткочасне переривання сесії клієнта (на кілька секунд або хвилин), під час якого автоматика виявляє збій, перенаправляє трафік на робочий сервер (failover) та відновлює працездатність.

8. Як backup, monitoring, logs, redundancy та disaster recovery пов'язані з нефункціональними вимогами?

Всі ці компоненти є інженерними методами та інструментами, за допомогою яких архітектори втілюють у життя нефункціональні вимоги до надійності, безпеки та доступності сайту:

Redundancy (резервування): фізична наявність дублюючих серверів, дисків чи джерел живлення. Резервування — це метод, а відмовостійкість чи висока доступність — результат його правильного налаштування.

Backup (резервне копіювання): захищає бізнес від втрати інформації у разі збоїв чи хакерських атак. Згідно з правилами NFR, копії повинні зберігатися в ізольованому від основного сервера місці. Також необхідно регулярно проводити автоматичну перевірку цілісності цих архівів.

Logs (журнали аудиту) та Monitoring: інструменти контролю. Логи збирають дані про кожну дію користувачів та системні помилки, що необхідно для відповідності стандартам безпеки. Системи моніторингу (наприклад, AppDynamics або SolarWinds) в режимі реального часу відстежують стан серверів, попереджаючи адміністраторів про наближення лімітів заліза до критичної межі.

Disaster Recovery (аварійне відновлення): детальні інструкції та автоматичні сценарії відновлення інфраструктури з нуля після катастрофічних аварій. Прописують конкретні ліміти часу відновлення — наприклад, середній час відновлення системи після аварії (MTTRS) не повинен перевищувати 10 хвилин.

9. Як нефункціональні вимоги впливають на вибір CMS, технологій, баз даних та хостингу?

Нефункціональні вимоги є головним орієнтуванням для розробників при формуванні архітектурного стеку проєкту:

Вибір CMS:

Якщо головна вимога — це суворий контроль прав користувачів, складна безпека та гнучка робота з багатьма мовами, обирають Drupal, оскільки він має надійну вбудовану систему ролей (RBAC).

Якщо в пріоритеті швидкість завантаження контенту по всьому світу та гнучкість фронтенду, розглядають Headless/Composable CMS (Contentful, Storyblok, Strapi). Вони передають дані через швидкі API, що спрощує кешування на рівні CDN, але вимагають сильної інженерної команди для налаштування.

WordPress VIP підходить для медійних сайтів з високими вимогами до швидкості редагування, але неконтрольоване встановлення плагінів може зруйнувати стандарти безпеки та продуктивності.

Хостинг та Бази даних: Простий shared-хостинг не підійде для сайтів з вимогами високої доступності. Для забезпечення низького TTFB та стабільної обробки важких баз даних потрібні VPS або хмарні середовища (AWS, Azure, Google Cloud), які дозволяють налаштувати автоматичне масштабування, резервування та географічний розподіл даних.

CDN (Content Delivery Network) та Кешування: Для задоволення вимог до продуктивності (швидкості) та захисту від навантажень впроваджують географічно розподілені мережі серверів CDN (Cloudflare, KeyCDN), які роздають копії файлів із найближчих до користувачів дата-центрів. Також налаштовується багаторівневе кешування: браузерне (через заголовки Cache-Control та ETag), серверне на рівні CMS та зворотне проксі (Reverse Proxy на базі NGINX або Varnish), що обробляє тисячі запитів на хвилину без навантаження на базу даних та код сайту.

10. Як правильно сформулювати нефункціональні вимоги так, щоб їх можна було реально перевірити?

Найпоширеніша помилка при складанні ТЗ — використання розмитих, суб'єктивних описів на кшталт «сайт має бути швидким, безпечним та витримувати багато людей». Такі вимоги неможливо об'єктивно оцінити та протестувати.

Щоб нефункціональна вимога була якісною, вона повинна відповідати наступним правилам:

Вимірюваність та кількісний характер: кожна вимога повинна мати чітку метрику, числові межі, одиниці виміру та порогові значення успіху/невдачі.

Поділ за компонентами системи: встановлювати вимоги слід до конкретних елементів, а не до всього сайту загалом. Наприклад, вимагати, щоб сторінка адміністратора завантажувалася за 1 секунду — це марна трата ресурсів розробників, оскільки адміністратори не впливають на продажі й користуються кабінетом рідко; натомість швидкість посадкових сторінок та кошика є критично важливою.

Наявність методу верифікації: у ТЗ має бути чітко вказано, як саме перевірятиметься цей показник (інструмент, умови тестування).

Приклади правильних та помилкових формулювань у ТЗ: