Нефункціональні вимоги (non-functional requirements, NFR), відомі також як атрибути якості (quality attributes), – це характеристики системи, які не повʼязані безпосередньо з певною функцією чи фічею. Ці вимоги описують, як має поводитися і функціонувати система, щоб задовольняти потреби користувачів і стейкхолдерів. Приклади нефункціональних вимог – продуктивність (performance), масштабованість (scalability), безпека (security) та зручність використання (usability).
Функціональні вимоги описують, що система повинна робити, тоді як нефункціональні вимоги описують, як саме вона повинна це робити. Ці вимоги є ключовими для підтвердження, що система відповідає своєму призначенню та забезпечує позитивний досвід користування. Вони також відіграють важливу роль у визначенні загального успіху проєкту.
Функціональні вимоги – це певні фічі та функції, які система повинна виконувати. Ці вимоги описують вхідні й вихідні дані та взаємодію з користувачем. Наприклад, функціональною вимогою для сайту електронної комерції може бути опція додавання товарів у кошик.
З іншої сторони, нефункціональні вимоги описують загальну продуктивність і поведінку системи. Ці вимоги не визначають конкретні функції, а описують атрибути якості системи. Наприклад, нефункціональною вимогою для сайту електронної комерції є завантаження сайту менше ніж за 2 секунди при підключенні до 3G мережі.
Гнучкі методології розробки пріоритезують гнучкість і швидкі ітерації над детальним плануванням і документацією. Цей підхід може ускладнити виконання нефункціональних вимог, які часто важче оцінити і виміряти, ніж функціональні вимоги.
У гнучкому підході до розробки нефункціональні вимоги інтегруються в загальний беклог продукту разом із функціональними вимогами. Це дозволяє регулярно переоцінювати та пріоритезувати нефункціональні вимоги відповідно до прогресу проєкту. У гнучкій розробці також приділяється особлива увага тестуванню і відгукам користувачів як ключовим компонентам оцінки і валідації нефункціональних вимог.
Враховуючи нефункціональні вимоги протягом усього процесу гнучкої розробки, команди можуть гарантувати, що кінцевий продукт не тільки відповідатиме функціональним потребам користувачів, але й добре працюватиме і забезпечуватиме позитивний користувацький досвід.
Роль бізнес-аналітиків щодо нефункціональних вимог
Одна з ключових ролей бізнес-аналітиків стосовно нефункціональних вимог – збір і документація цих вимог. Цей процес може включати проведення інтервʼю зі стейкхолдерами, аналіз існуючих систем і перегляд документації. Бізнес-аналітики використовують різноманітні техніки, наприклад, виявлення вимог, для збору нефункціональних вимог, які можуть включати продуктивність, масштабованість, безпеку, юзабіліті і зручність підтримки (maintainability).
Для бізнес-аналітиків важливо документувати нефункціональні вимоги чітко і лаконічно та переконатися, що їх можна протестувати. Це допоможе команді розробки зрозуміти вимоги і побудувати систему відповідно до них.
Інша важлива роль бізнес-аналітиків стосовно нефункціональних вимог – це передача вимог команді розробки. Це може включати створення документації, такої як функціональні й технічні специфікації, що детально описують нефункціональні вимоги. Бізнес-аналітики також мають тісно співпрацювати з командою розробки, щоб переконатися, що вони розуміють вимоги та можуть ефективно їх реалізувати.
Бізнес-аналітики також мають створити план тестування нефункціональних вимог у співпраці з командою розробників. Він включає визначення релевантних метрик для тестування, а також забезпечення команди необхідними інструментами та ресурсами для проведення тестування.
Бізнес-аналітики також відповідальні за те, щоб нефункціональні вимоги відповідали бізнес-цілям. Це включає тісну співпрацю зі стейкхолдерами для розуміння їхніх потреб та узгодження нефункціональних вимог із загальними цілями проєкту. Бізнес-аналітики повинні вміти оцінювати компроміси, які можуть знадобитися при розгляді нефункціональних вимог, наприклад, продуктивність чи вартість, і залучати стейкхолдерів до процесу прийняття рішень.
Нарешті, бізнес-аналітики відіграють ключову роль у керуванні нефункціональними вимогами впродовж процесу гнучкої розробки. Цей процес може включати співпрацю з командою розробки для інтеграції нефункціональних вимог до беклога і процесу планування спринта, регулярний перегляд і оновлення вимог. Бізнес-аналітики також повинні спільно з командою розробки використовувати метрики і тестування для вимірювання та валідації нефункціональних вимог, а також співпрацювати зі стейкхолдерами, включаючи користувачів, щоб зрозуміти їх і визначити пріоритети.
Загалом, бізнес-аналітики відіграють важливу роль у зборі, документуванні, комунікуванні та узгодженні нефункціональних вимог з цілями проєкту. Вони також є свого роду “мостом” між стейкхолдерами та командою розробки та забезпечують дотримання нефункціональних вимог протягом гнучкого процесу розробки.
Проблеми управління нефункціональними вимогами в гнучкій розробці
Один з найбільших викликів у керуванні нефункціональними вимогами в agile розробці – це пріоритезація цих вимог у поєднанні з функціональними вимогами. Згідно з методологією agile розробки, команди мають бути гнучкими та швидко реагувати на зміну вимог і пріоритетів.
Це може ускладнити спрямування достатньої уваги та ресурсів на нефункціональні вимоги, особливо коли існує конфлікт пріоритетів між функціональними та нефункціональними вимогами. Наприклад, нова фіча може бути пріоритезованою вище проблеми з продуктивністю, що призводить до неоптимального користувацького досвіду.
Іншим викликом в управлінні нефункціональними вимогами в гнучкій розробці є підтримка балансу між гнучкістю та стабільністю. Agile методології пріоритезують гнучкість і швидкі ітерації, що ускладнює задоволення нефункціональних вимог.
Хоча цей підхід дозволяє командам оперативно реагувати на зміну вимог і пріоритетів, це також означає, що система може бути не цілком оптимізована у плані продуктивності, масштабованості та інших нефункціональних вимог.
Багато програмних систем підлягають галузевому регулюванню та стандартам, яких необхідно дотримуватися, щоб їх можна було використовувати чи продавати. Ці норми і стандарти часто включають специфічні нефункціональні вимоги, такі як шифрування даних або доступність для користувачів з обмеженими можливостями.
До теми – ВІГЕРСОПЕДІЯ – Оці “всі інші” вимоги: атрибути якості та неминучі компроміси.
Забезпечення відповідності цих нормам і стандартам може спричинити значні складнощі для agile команд, адже це може потребувати додаткових ресурсів і часу для виконання вимог, а також бізнес-аналітику потрібно постійно стежити за оновленнями нормативних актів.
Керування нефункціональними вимогами у гнучкій розробці може ускладнюватися для розподілених та віддалених команд. Коли члени команди працюють у різних локаціях і часових поясах, складніше координувати ефективну співпрацю.
Через ці причини ускладнюється ідентифікація та пріоритезація нефункціональних вимог, а також вимірювання і тестування продуктивності системи та користувацького досвіду.
Управління нефункціональними вимогами в agile розробці – це складний процес, який потребує поєднання технічних навичок і soft skills. Бізнес-аналітики відіграють ключову роль у менеджменті цих вимог і в забезпеченні того, щоб кінцевий продукт відповідав потребам користувачів і стейкхолдерів, а також підтримував загальні бізнес-цілі.
Кращі практики управління нефункціональними вимогами в гнучкій розробці
В agile розробці нефункціональні вимоги не менш важливі за функціональні вимоги. Однак під час планування спринту та пропрацювання беклога можна легко пропустити нефункціональні вимоги. Щоб переконатися, що про нефункціональні вимоги не забули, важливо інтегрувати їх у беклог та процес планування спринту.
Один зі способів це зробити – включити нефункціональні вимоги до історій користувачів (user stories) в якості acceptance критеріїв. Наприклад, якщо історія описує нову фічу, яку потрібно додати до системи, acceptance критерії повинні включати нефункціональні вимоги, такі як продуктивність, безпека та юзабіліті. Це допоможе команді краще зрозуміти контекст історії користувача та забезпечити відповідність продукту вимогам.
У процесі реалізації проєкту важливо регулярно переглядати та оновлювати нефункціональні вимоги. Вимоги можуть змінюватися з розвитком проєкту, тому важливо переконатися, що вони залишаються актуальними і відповідають цілям проєкту. Також стейкхолдери, наприклад, користувачі краще розуміють свої потреби, коли починають взаємодіяти з системою і можуть надати новий фідбек, який вплине на нефункціональні вимоги.
Щоб забезпечити виконання нефункціональних вимог, потрібно регулярно проводити ревʼю та та перевірки зі стейкхолдерами. Це допоможе виявити будь-які невідповідності або проблеми на ранній стадії, коли їх легше виправити.
Не менш важливо використовувати метрики і тестування для вимірювання та валідації нефункціональних вимог. Наприклад, метрики продуктивності, такі як час відгуку (response time) і пропускна здатність (throughput), можна використовувати для вимірювання продуктивності системи, а тестування безпеки – для перевірки захищеності системи.
Слід глибоко розуміти метрики, які стосуються кожної нефункціональної вимоги, і знати, як їх збирати й аналізувати. Крім того, важливо протестувати нефункціональні вимоги системи, щоб переконатися, що вони відповідають необхідним рівням продуктивності, безпеки та зручності використання.
Співпраця зі стейкхолдерами – ключова активність для розуміння і пріоритезації нефункціональних вимог. У гнучкій розробці користувачі вважаються невід’ємною частиною команди, а їхній внесок та зворотній зв’язок цінуються.
Важливо залучати користувачів до процесу визначення і пріоритезації нефункціональних вимог, щоб система відповідала потребам її цільових користувачів, а нефункціональні вимоги узгоджувалися з цілями проєкту.
Також у комунікації зі стейкхолдерами необхідно забезпечувати повну прозорість у питаннях можливих компромісів щодо нефункціональних вимог, таких як продуктивність проти вартості, і залучати їх до процесу прийняття рішень.
Підсумовуючи, в agile розробці важливо інтегрувати нефункціональні вимоги до беклога і процесу планування спринта, регулярно переглядати і оновлювати їх, використовувати метрики і тестування для їх виміру і валідації та співпрацювати зі стейкхолдерами, включаючи користувачів, для їх розуміння і пріоритезації. Використовуючи ці кращі практики, команди уникнуть пропуску нефункціональних вимог та створять кінцевий продукт, який відповідатиме потребам цільових користувачів.
Висновки
Отже, управління нефункціональними вимогами в гнучкій розробці має вирішальне значення для того, щоб кінцевий продукт відповідав потребам його цільових користувачів. Ключові моменти, розглянуті в цій статті, включають важливість інтеграції нефункціональних вимог в процес планування беклога і спринтів, регулярний перегляд і оновлення їх протягом проєкту, використання метрик і тестування для їх вимірювання і валідації, а також співпрацю зі стейкхолдерами, включаючи користувачів, для їх розуміння і визначення пріоритетів. Коли команди дотримуються цих практик, нефункціональні вимоги не будуть проігноровані, а кінцевий продукт відповідатиме всім вимогам.
Оскільки гнучка розробка продовжує розвиватися, ймовірно, з’являться нові інструменти та методології, які допоможуть командам ефективніше управляти нефункціональними вимогами. Один із прикладів – використання технік штучного інтелекту і машинного навчання (Machine Learning) для управління і аналізу вимог. Крім того, проводяться дослідження щодо використання agile методологій у регульованих середовищах, де стандартизація та документування є обов’язковими. Зі зростанням популярності хмарних обчислень конфіденційність даних, безпека та відповідність вимогам у хмарному середовищі відіграватимуть важливу роль в управлінні нефункціональними вимогами в гнучкій розробці.
Є багато книжок, статей та вебсайтів для бізнес-аналітиків, які шукають додаткової інформації про керування нефункціональними вимогами в гнучкій розробці. Ось кілька рекомендованих ресурсів:
- “Agile Estimating and Planning”, автор Mike Cohn
- “Мапа історій користувача. Відкрий правдиву історію, створи саме той продукт”, автор Джеф Петтон
- “ Навчись робити вдвічі більше за менший час”, автор Джефф Сазерленд
- “Functional and Non-Functional Requirements”, автори Elaine W. Leigh і Richard C. Lee
Також існують професійні організації та онлайн-спільноти, такі як Institute of Business Analysis (IIBA) та Agile Alliance, які надають рекомендації, тренінги та ресурси з agile розробки та управління вимогами.
Загалом, дотримуючись кращих практик і залишаючись в курсі новітніх інструментів і методологій, бізнес-аналітики можуть ефективно керувати нефункціональними вимогами в гнучкій розробці і гарантувати, що кінцевий продукт відповідатиме потребам його цільових користувачів.
Оригінальна стаття – Managing Non-Functional Requirements in Agile Projects від Erivan Ramos, переклад – Марія Слободян, ревью – Юлія Березенко, фото від Parabol з сайту Unsplash.