Як писати вимоги до продуктивності так, щоб їх дійсно імплементували (і протестували)

Вступ

Що таке продуктивність системи — простими словами

Чому вимоги до продуктивності важливі

Міні-словничок (UA + EN)

Профіль навантаження: що це і навіщо він потрібен

Приклад профілю навантаження для e-commerce

Як формулювати вимоги до продуктивності: проста логіка

Шаблон для Confluence/Jira

Заповнений приклад шаблону

Як писати вимоги для систем обробки даних

Чекліст: чи добре сформульована вимога?

Бонус: якщо продукт працює з “залізом” (embedded / hardware)

Вступ

Коли продукт стає популярнішим, зростає кількість користувачів, замовлень, запитів до API, а також обсяг даних. У цей момент “раптово” з’являються типові проблеми: сторінки завантажуються довше, пошук гальмує, оформлення замовлення зависає, а інтеграції з партнерами починають повертати помилки.

Дуже часто причина проста: вимоги до продуктивності або відсутні, або написані занадто загально (“має працювати швидко”). У результаті команді складно зрозуміти, що саме вважати успіхом, а тестувальникам - як це перевірити.

Ця стаття показує, як формувати зрозумілі, вимірювані та тестовані вимоги до продуктивності мовою, доступною для бізнес-аналітиків та продакт-оунерів.

Що таке продуктивність системи — простими словами

Продуктивність - це не лише “швидкість”. Це набір характеристик, які описують, наскільки передбачувано та стабільно працює система, коли користувачів і даних багато.

Ключові складові продуктивності:

• Швидкість відповіді (Latency / Response time) - як швидко система реагує на дію.

• Пропускна здатність (Throughput) - скільки запитів/операцій система здатна обробити.

• Стабільність (Error rate) - скільки помилок виникає під навантаженням.

• Масштабованість (Scalability) - як система справляється зі зростанням навантаження.

• Споживання ресурсів (Resource utilization) - скільки “коштує” робота системи (CPU/RAM тощо).

Чому вимоги до продуктивності важливі

Якісно прописані вимоги до продуктивності допомагають:

• узгодити очікування бізнесу та команди розробки;

• підготуватися до пікових навантажень (акції, сезонність, PR-кампанії);

• уникнути “пожеж” на продакшені;

• включити продуктивність у критерії прийняття (Acceptance Criteria), а не згадувати в кінці.

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

Міні-словничок (UA + EN)

• Час відповіді (Response time / Latency) - скільки часу проходить від дії користувача до результату.

• Перцентиль (Percentile: P95/P99) - “у 95 випадках зі 100 буде швидше за X”. Це точніше, ніж середнє.

• Пропускна здатність (Throughput) - скільки запитів/операцій обробляється за секунду/хвилину.

• Паралельність (Concurrency) - скільки операцій/користувачів одночасно “в роботі”.

• Рівень помилок (Error rate) - частка запитів із помилками або тайм-аутами.

• Доступність (Availability) - який процент часу в роботі система доступна.

• Деградація (Graceful degradation) - контрольоване спрощення функцій під піком, щоб система не “падала”.

• Угода про рівень сервісу (SLA / Service Level Agreement) - юридично/формально гарантований рівень сервісу (наприклад, 99.9% доступності).

• Ціль рівня сервісу (SLO / Service Level Objective) - внутрішня ціль (наприклад, P95 latency ≤ 500мс), часто “строгіша” за SLA.

• Індикатор рівня сервісу (SLI / Service Level Indicator) - конкретна метрика, яку міряємо (latency P95, error rate, availability).

Профіль навантаження: що це і навіщо він потрібен

Навіть правильна вимога типу “P95 ≤ 800 мс” буде неповною, якщо не описати умови, за яких вона має виконуватися.

Профіль навантаження (Load profile) - опис того, як система використовується в реальному житті:

• які дії виконуються найчастіше (пошук, перегляд, checkout);

• у яких пропорціях;

• як змінюється активність у часі (ріст → пік → спад);

• які типові дані (наприклад, розмір корзини або “важкі” запити).

Приклад профілю навантаження для e-commerce

У пікову годину користувачі можуть робити різні дії з різною частотою:

• 35% - перегляд каталогу

• 25% - пошук

• 20% - перегляд товару

• 10% - додавання в корзину

• 10% - оформлення замовлення

Також важливо описати, як поводиться навантаження протягом часу:

• Розігрів: поступове зростання, наприклад 15 хвилин

• Пік: стабільно високий трафік, наприклад 60 хвилин

• Спад: повернення до норми, наприклад 15 хвилин

Це допомагає сформувати вимоги не “в вакуумі”, а в реалістичному сценарії.

Як формулювати вимоги до продуктивності: проста логіка

Хороша вимога зазвичай відповідає на 4 питання:

1) Що вимірюємо? (сценарій)

2) Яку метрику? (швидкість, пропускна здатність, помилки…)

3) За яких умов? (пік, тривалість, типові дані)

4) Як вимірюється? (логи клієнта, сервера, СУБД/E2E)

Приклад “погано / добре”:

Погано: “Система має працювати швидко.”

Добре: “Для ‘Оформлення замовлення’ час відповіді P95 ≤ 800 мс і P99 ≤ 1500 мс під час пікового навантаження протягом 60 хвилин; рівень помилок ≤ 0.3%.”

Саме тому важливо вимірювати Р95 / Р99, а не серднє.

Шаблон для Confluence/Jira

Сценарій (Scenario): [Опис функції / сценарію]

Чому це важливо (Business importance): [Бізнес-цінність, вплив на користувача або процес]

Опис дії користувача (User journey): [Коротко: що робить користувач та який результат очікує]

Очікуване навантаження (Load profile):

- Пікове навантаження (Peak):

- Частка серед усіх дій (%):

- Типові дані (Data characteristics):

Вимоги до швидкості (Response time):

- P95 ≤ …

- P99 ≤ …

Стабільність (Error rate): - ≤ … %

Пропускна здатність (Throughput): - … запитів/сек або … операцій/хв

Умови вимірювання (Conditions):

- Тривалість піку:

- Тип даних:

- Середовище (Environment):

Деградація (Graceful degradation): [Що дозволено спрощувати, а що має залишатися стабільним]

Метрика / моніторинг (Measurement): [логи, E2E, зовнішні моніторингові системи]

Заповнений приклад шаблону

Сценарій (Scenario): Оформлення замовлення (Checkout)

Чому це важливо (Business importance): Критичний етап продажу. Затримки впливають на конверсію та довіру користувачів.

Опис дії користувача (User journey): Користувач натискає “Оформити” → отримує підтвердження замовлення.

Очікуване навантаження (Load profile):

- Пікове навантаження: 3000 запитів/сек

- Частка серед усіх дій: близько 10%

- Типові дані: корзина 3–5 товарів (P95 - до 20 товарів)

Вимоги до швидкості (Response time):

- P95 ≤ 800 мс

- P99 ≤ 1500 мс

Стабільність (Error rate): ≤ 0.3% під час пікової години

Пропускна здатність (Throughput): Система має обробляти не менше 3000 запитів/сек

Умови вимірювання (Conditions):

- Пік триває 60 хвилин;

- Середовище, подібне до продакшену;

- Реалістичні набори даних (обфусковані продакшен-дані).

Деградація (Graceful degradation): Дозволено спрощувати рекомендації під піком, але оформлення замовлення має залишатися стабільним.

Метрика / моніторинг (Measurement): Е2Е‑моніторинг, серверні логи

Як писати вимоги для систем обробки даних

Для продуктів, де є завантаження та обробка даних, часто важливі не “мілісекунди”, а час до готового результату. Це можна описувати максимально бізнесово.

Три прості категорії вимог:

1) Час до результату: “Нові дані мають бути доступні у звітах/результатах не пізніше ніж через 30 хвилин після завантаження.”

2) Скільки система витримує під піком: “Під час піку система має приймати до 200 завантажень за хвилину без збоїв.”

3) Стабільність: “Під час пікової активності допускається не більше ніж 0.2% помилок.”

Додатково, якщо є “бізнесовий дедлайн”: “Нічна обробка має завершуватися до 07:00, навіть при збільшенні обсягу даних у 2 рази.”

Бонус: якщо продукт працює з “залізом” (embedded / hardware)

У системах, що взаємодіють із пристроями, важливо не просто “швидко”, а “вчасно завжди”. Тут часто зустрічаються вимоги на кшталт:

• “Задача має виконуватися кожні 10 мс; максимальний час виконання — не більше 7 мс.”

• “Обробка сигналу має бути стабільною без пропусків TTL.”

Чекліст: чи добре сформульована вимога?

• Є конкретні метрики (швидкість / пропускна здатність / помилки / час до результату)

• Є перцентилі P95/P99 (а не тільки середнє)

• Є чіткий сценарій

• Є умови (пік, тривалість, типові дані)

• Вказано, як вимірюється результат

• Описано, що допускається під піком (деградація)

Висновок

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

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

Розклад тренінгів від Art of Business Analysis 

Новини та статті з бізнес-аналізу: 

• Telegram 

• Linkedin