Нефункціональні вимоги або NFR (non-functional requirements) – це набір специфікацій, які описують робочі можливості та обмеження системи та намагаються покращити її функціональність. Це в основному вимоги, які визначають, наскільки добре працюватиме продукт якщо врахувати, наприклад, швидкість, безпеку, надійність, цілісність даних тощо. Структура стандартів ISO/IEC 25000 визначає нефункціональні вимоги як вимоги до якості системи та якості програмного забезпечення.
Нефункціональні вимоги: приклади, типи, підходи
Нефункціональні вимоги: приклади, типи, підходи
Як функціональні, так і нефункціональні вимоги описують конкретні характеристики, якими повинен володіти продукт, щоб відповідати потребам зацікавлених сторін і самого бізнесу. Але, як видно з назви, вони зосереджені на різних речах:
- функціональні вимоги визначають, що повинен робити програмний продукт: його характеристики та функції;
- нефункціональні вимоги задають атрибути якості системи.
Основні типи нефункціональних вимог
Найпоширенішими з них є продуктивність, масштабованість, портативність, сумісність, надійність, доступність, придатність до ремонту, безпека, локалізація, зручність використання тощо.
| Нефункціональна вимога |
Визначення |
Приклад |
| Продуктивність | Визначає, наскільки швидко програмна система або її окрема частина реагує на певні дії користувачів за певного навантаження. У більшості випадків цей показник пояснює, скільки часу користувач має чекати, перш ніж відбудеться цільова операція (відображається сторінка, обробляється транзакція тощо) якщо врахувати загальну кількість користувачів на даний момент. | Цільова сторінка, яка підтримує 5000 користувачів на годину, має забезпечувати час відповіді не більше 6 секунд у браузері Chrome настільного комп’ютера з урахуванням відтворення тексту та зображень і через з’єднання LTE. |
| Масштабованість | Оцінює найвищі навантаження, за яких система все ще відповідатиме вимогам продуктивності. | Система повинна бути достатньо масштабованою, щоб підтримувати 1 000 000 відвідувань одночасно та зберігати оптимальну продуктивність. |
| Портативність | Визначає, як система або її елемент можуть бути запущені в тому чи іншому середовищі. Зазвичай містить специфікації обладнання, програмного забезпечення чи іншої платформи використання. Простими словами, він визначає, наскільки добре функції, що виконуються на одній платформі, виконуються на іншій. | Програма, яка працює в Windows 10, повинна працювати в Windows 11 без будь-яких змін у своїй поведінці та продуктивності. |
| Сумісність | Як додатковий аспект портативності, визначає, як система може співіснувати з іншою системою в одному середовищі. Наприклад, програмне забезпечення, встановлене в операційній системі, має бути сумісним із брандмауером або антивірусним захистом. | Програма iOS повинна підтримувати пристрої iPhone, що працюють на версіях ОС: 3.6, 3.3, 3.4, 4.3, 2.3 |
| Надійність | Визначає, наскільки ймовірно, що система або її елемент працюватимуть без збоїв протягом заданого періоду часу за заздалегідь визначених умов. Традиційно цю ймовірність виражають у відсотках. | Система повинна працювати без збоїв у 95 відсотках випадків використання протягом місяця. |
| Ремонтопридатність | Визначає час, необхідний для виправлення бага або його компонента, зміни для підвищення продуктивності чи інших якостей або адаптації до мінливого середовища. Придатність до ремонту часто вимірюється за допомогою такого показника, як MTTRS – середній час відновлення системи. | Середній час відновлення системи (MTTRS) після збою не повинен перевищувати 10 хвилин. MTTRS включає весь час коригувального обслуговування та час затримки. |
| Доступність | Описує, наскільки система доступна для користувача в певний момент часу. Виражається як очікуваний відсоток успішних запитів, або як відсоток часу, протягом якого система доступна для роботи протягом певного періоду. | Веб-панель має бути доступною для користувачів із США 99,98% часу щомісяця в робочі години за східним стандартним часом. |
| Безпека | Гарантує, що всі дані всередині системи або її частини будуть захищені від атак шкідливих програм або несанкціонованого доступу. | Шлюз обробки платежів має бути сумісним з PCI DSS. |
| Локалізація | Визначає, наскільки добре система або її елемент відповідає контексту місцевого майбутнього ринку. Контекст включає місцеві мови, закони, валюти, культури, правопис та ін. | Формат дати має бути таким: місяць.число.рік. |
| Зручність використання (Usability) | Наскільки легко клієнту користуватися системою? Зручність використання пропонують оцінювати за п’ятьма параметрами:
|
Рівень помилок користувачів, які надсилають платіжні дані на сторінці оформлення замовлення, не повинен перевищувати 10 відсотків. |
Загальні рекомендації щодо документування нефункціональних вимог
Вимоги мають бути такими, щоб їх можна було виміряти та перевірити. Щоб зрозуміти, чи відповідає система обмеженням якості, необхідно попередньо визначити кількісні вимоги. Потрібно вказати одиниці вимірювання, методи, які будуть використовувати, а також рівні успіху та невдачі.
Вимоги краще встановлювати до компонентів системи, а не до цілих продуктів. Якщо користувачі ніколи не взаємодіють з деякою частиною продукту (наприклад, панеллю адміністратора), встановлення обмежень продуктивності для цих компонентів може бути марною, оскільки команда витрачатиме багато зусиль без видимої вигоди.
Зв'язок NFR із бізнес-цілями. Хвилинна різниця в доступності системи може не мати суттєвого впливу на продажі, але іноді може означати додаткові тижні розробки. Бізнес-цілі варто розділяти на системні вимоги.
Обмеження по залученню третіх сторін. Якщо використовується сторонній API, який повертає дані повільніше, ніж потрібно, команда мало що зможе з цим зробити.
Врахування архітектурних обмежень. Застарілі системи можуть накладати обмеження на якість. Хоча рефакторинг застарілого коду можливий, іноді поточну архітектуру потрібно повністю переробити, щоб відповідати деяким вимогам.
Використання існуючих стандартів та посібників. Перед початком роботи з вимогами варто ознайомитись з інструкціями програм для iOS або Android тощо.
Переваги нефункціональних вимог:
- гарантія дотримання правових норм;
- визначення атрибуту якості програмного забезпечення;
- забезпечення надійності, доступності, продуктивності і масштабованості програмного забезпечення;
- побудова політики безпеки системи;
- забезпечення хорошої взаємодії з користувачем, легкість роботи з програмним забезпеченням і мінімізація фактору витрат;
- покращення загальної якості системи;
- підвищення задоволення користувачів;
- краще узгодження з бізнес-цілями;
- зменшення кількості доопрацювань;
- покращення масштабованості і адаптивності системи;
- краще технічне обслуговування системи.
Недоліки нефункціональних вимог:
- може впливати на різні підсистеми програмного забезпечення високого рівня;
- збільшення вартості, оскільки вони вимагають особливої уваги на етапі архітектури програмного забезпечення/проєктування високого рівня;
- труднощі з визначенням усіх вимог;
- труднощі з прогнозуванням майбутніх вимог;
- проблеми вимірювання та тестування;
- великі часові затрати, які можуть уповільнити процес розробки;
- ризик зміни вимог: нефункціональні вимоги можуть змінюватися з часом, що може призвести до плутанини;
- конфліктні вимоги: нефункціональні вимоги можуть конфліктувати одна з одною, і може бути важко збалансувати їх та визначити пріоритети для виконання;
- непередбачені вимоги: нефункціональні вимоги можуть бути не повністю визначені на етапі збору вимог, а деякі вимоги можуть бути виявлені лише після розгортання системи.
