Огляд та ключові тези вебінару Non-Functional Requirements: посібник для архітекторів-початківців

Запис вебінару наприкінці статті

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

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

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

• Класифікація та категоризація: нефункціональні вимоги можна поділити на кілька категорій, таких як продуктивність, масштабованість, портативність, сумісність, доступність, та інші. Кожна із цих категорій вимагає специфічних технічних і архітектурних рішень для їхнього втілення в життя.
• Вимірюваність та перевірка: важливо, щоб нефункціональні вимоги були вимірними. Це означає, що для кожної вимоги потрібно визначити методи перевірки та критерії успіху. Наприклад, якщо вимога стосується швидкодії, слід вказати, яким чином вона буде заміряна (наприклад, через тестування продуктивності) та які показники будуть вважатися прийнятними.
• Зв’язок із бізнес-цілями: нефункціональні вимоги мають бути тісно пов’язані з бізнес-цілями проєкту. Вони повинні відображати потреби та очікування клієнтів, а також сприяти досягненню стратегічних цілей компанії. Наприклад, забезпечення високої доступності системи може бути критично важливим для забезпечення неперервності бізнес-процесів.
• Архітектурні обмеження та стандарти: нефункціональні вимоги часто залежать від існуючої архітектури та технологічних стандартів. Важливо враховувати обмеження, які можуть накладати застарілі системи, та планувати їхнє оновлення або заміну в контексті вимог до нового проєкту.

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

Приклади та типологія нефункціональних вимог

Нефункціональні вимоги (NFR) охоплюють широкий спектр аспектів, які впливають на загальну якість та ефективність систем.

Ось декілька ключових типів та прикладів:

• Продуктивність: вимірюється швидкістю реакції системи на користувацькі запити. Наприклад, вебсторінка, що підтримує 5000 користувачів на годину, повинна забезпечувати час відповіді не більше 6 секунд.
• Масштабованість: оцінює здатність системи витримувати збільшення навантаження без втрати продуктивності. Система має бути здатною підтримувати до 1 000 000 відвідувачів одночасно, зберігаючи оптимальну продуктивність.
• Портативність: визначає можливість системи працювати в різних середовищах. Програма, що працює в Windows 10, має без змін функціонувати й в Windows 11.
• Сумісність: забезпечує співіснування системи з іншими системами в одному середовищі. Програмне забезпечення має бути сумісним з основними операційними системами та антивірусним захистом.
• Надійність: визначає ймовірність безперебійної роботи системи. Система має функціонувати без збоїв у 95 % випадків протягом місяця.
• Ремонтопридатність: визначає час, необхідний для виправлення несправностей. Середній час відновлення системи (MTTRS) після збою не повинен перевищувати 10 хвилин.
• Доступність: описує час, протягом якого система доступна для користувачів. Вебпанель повинна бути доступною 99,98 % часу щомісяця.
• Безпека: забезпечує захист даних від несанкціонованого доступу та атак. Шлюз обробки платежів повинен відповідати стандартам PCI DSS.
• Локалізація: Враховує місцеві особливості, такі як мова, законодавство, валюта. Формат дати має бути адаптований до місцевих стандартів.
• Зручність використання: оцінюється за легкістю взаємодії користувача із системою. Рівень помилок при введенні платіжних даних не повинен перевищувати 10 %.

Отже, вимоги мають бути такими, щоб їх можна було виміряти та перевірити. Для забезпечення відповідності системи обмеженням якості, необхідно попередньо визначити кількісні вимоги, вказати одиниці вимірювання, методи, які будуть використовуватися, а також рівні успіху та невдачі.

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

Зв’язок нефункціональних вимог (NFR) із бізнес-цілями є критично важливим. Хвилинна різниця в доступності системи може не мати суттєвого впливу на продажі, але іноді може означати додаткові тижні розробки. Бізнес-цілі варто розділяти на системні вимоги.

Обмеження із залучення третіх сторін також важливі. Якщо використовується сторонній API, який повертає дані повільніше, ніж потрібно, команда мало що зможе із цим зробити.

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

Перед початком роботи з вимогами варто ознайомитись з існуючими стандартами та посібниками, наприклад, архітектурними стилями, патернами, тактиками.

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

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

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

А також не забувайте слідкувати за нашими новинами, в EPAM безліч цікавого і корисного. Робити це зручно на наших сторінках у Facebook, Twitter, Telegram або Youtube, а ще радимо заглядати у розклад наших подій на сайті у відповідному розділі — Календар подій.

І, як завжди, дякуємо, що ви з нами!