Розуміння функціональних і нефункціональних вимог в Agile: Всеосяжний посібник

текст перекладу

Фото: Blake Wisz на Unsplash

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

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

Що таке функціональні вимоги?

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

Приклади функціональних вимог:

• Вхід/Аутентифікація: Користувачі повинні мати змогу входити, використовуючи свою електронну пошту та пароль.
• Пошук: Користувачі повинні мати змогу шукати продукти за назвою, категорією або ціною.
• Оформлення замовлення: Користувачі повинні мати змогу оформити замовлення, додавши товари в кошик і завершивши платіжний процес.

Управління функціональними вимогами в Agile:

В Agile історії користувачів використовуються для фіксації функціональних вимог. Типова історія користувача має такий формат:

Як [тип користувача], я хочу [щось зробити], щоб я міг [досягти мети].

Приклад:
Як покупець, я хочу мати змогу додати товари до кошика, щоб я міг придбати їх пізніше.

Ці історії користувачів пріоритетизуються в Product Backlog, і під час кожного спринту команда розробників працює над їх реалізацією. У межах ітераційного підходу Agile ці історії розвиваються завдяки постійному зворотному зв'язку, що дозволяє продукту краще відповідати потребам користувачів.

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

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

Приклад для кошика покупок в електронній комерції:

• Кошик має показувати правильну кількість товарів.
• Кошик має розраховувати загальну вартість вибраних товарів, включаючи податки та доставку.
• Користувач має мати змогу видаляти товари з кошика.

Що таке нефункціональні вимоги?

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

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

• Продуктивність: Система має завантажуватися протягом 2 секунд для 95% користувачів.
• Масштабованість: Застосунок має витримувати до 10 000 одночасних користувачів без погіршення якості.
• Безпека: Усі паролі користувачів повинні бути зашифровані за допомогою шифрування AES-256.
• Доступність: Система повинна мати 99,9% часу безвідмовної роботи, що дозволяє не більше 8 годин простою на рік.

Управління нефункціональними вимогами в Agile:

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

1.

текст перекладу
Вбудовування нефункціональних вимог (NFR) в Definition of Done (DoD)

В Agile, Definition of Done (DoD) визначає критерії, які повинні бути виконані, щоб будь-яка функція могла вважатися завершеною. Наприклад, функція електронної комерції, як кошик для покупок, може не бути "готовою", поки не досягне конкретних вимог до продуктивності або безпеки.

Приклад:

• Продуктивність: Сторінка кошика повинна завантажуватися протягом 3 секунд, навіть якщо 1 000 користувачів переглядають її одночасно.
• Безпека: Усі платіжні дані повинні бути зашифровані за допомогою HTTPS.

2. Технічні історії для NFR

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

Приклад технічної історії:

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

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

3. Вимірювання та тестування NFR

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

Наприклад, ви можете виконувати:

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

Фото: Campaign Creators на Unsplash

Як Agile працює з функціональними та нефункціональними вимогами

В Agile ключовим є постійне співробітництво, частий зворотний зв'язок та гнучкість. Управління функціональними та нефункціональними вимогами — це не одноразова діяльність, а постійний процес, що розвивається разом з проектом. Ось як команди Agile можуть збалансувати обидва види вимог:

1. Очищення беклогу та пріоритизація

І функціональні, і нефункціональні вимоги містяться в Product Backlog, але їх часто пріоритизують по-різному. Функціональні вимоги зазвичай пріоритизуються на основі користувацької цінності, в той час як нефункціональні вимоги можуть пріоритизуватися залежно від технічних потреб або ризиків.

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

2. Часті ітерації

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

3. Крос-функціональні команди

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

4. Прототипування та постійний зворотний зв'язок

Agile заохочує швидке прототипування та часті випуски. Після кожної ітерації команди можуть отримувати зворотний зв'язок від користувачів та зацікавлених сторін. Якщо виникають проблеми з функціональною функцією (наприклад, функція "додавання в кошик" не є інтуїтивно зрозумілою), команда може внести зміни в наступних спринтах.
текст перекладу
Так само, якщо виникають проблеми з продуктивністю (наприклад, система працює повільно при великому навантаженні), команда може негайно вирішити це питання.

Приклад з реального світу: Застосунок для електронної комерції

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

Функціональні вимоги:

1. Функціональність пошуку: Як користувач, я хочу шукати товари за назвою чи категорією, щоб легко знайти те, що мені потрібно.
2. Аутентифікація користувачів: Як покупець, я хочу увійти, використовуючи свою електронну пошту та пароль, щоб безпечно отримати доступ до мого акаунту та історії замовлень.
3. Процес оформлення замовлення: Як користувач, я хочу безперешкодно оформити замовлення, додаючи товари в кошик, вибираючи способи доставки та оплачуючи мої покупки.

Нефункціональні вимоги:

1. Продуктивність: Вебсайт повинен завантажуватися за 3 секунди за нормальних умов трафіку. Під час високого навантаження, наприклад, під час розпродажу, він має підтримувати продуктивність при великому навантаженні (наприклад, 5 000 користувачів).
2. Безпека: Усі платіжні дані повинні бути зашифровані за стандартами SSL та PCI DSS.
3. Масштабованість: Система повинна мати можливість обробляти 10 000 одночасних користувачів під час пікових періодів покупок без зупинок.
4. Зручність користування: Процес оформлення замовлення не повинен займати більше ніж 3 хвилини, забезпечуючи плавну та швидку транзакцію для користувачів.

Управління як функціональними, так і нефункціональними вимогами в Agile:

1. Історії користувачів: Функціональні вимоги, такі як «функціональність пошуку» та «процес оформлення замовлення», фіксуються як історії користувачів.
2. Очищення беклогу: Власник продукту працює з командою, щоб пріоритизувати історії користувачів та технічні завдання (наприклад, забезпечення шифрування платіжних даних).
3. Планування спринтів: В одному спринті команда може зосередитися на реалізації функції «додати в кошик», а в іншому — на вирішенні проблем масштабованості або аудити безпеки.
4. Безперервне тестування: Команда розробників постійно тестує як функціональність (наприклад, функція пошуку), так і продуктивність (наприклад, забезпечення того, що сайт може обробляти 5 000 одночасних користувачів).

Часто задавані запитання на інтерв'ю під час етапу проектування системи:

1. Як би ви розробили платформу для електронної комерції з реальним відстеженням товарних запасів, забезпечуючи високу доступність та стійкість до збоїв?
2. Як би ви забезпечили низьку затримку доступу до даних у глобально розподіленій системі, дотримуючись суворих вимог до конфіденційності даних (наприклад, GDPR)?
3. Як би ви розробили систему для обробки реальних повідомлень з мільйонами одночасних користувачів, забезпечуючи стабільність та високу якість користувацького досвіду?
4. Спроектуйте багатокористувацький SaaS-застосунок, де кожен клієнт може визначати власні робочі процеси та дозволи. Як би ви забезпечили гнучкість, безпеку та хорошу продуктивність на великих масштабах?
5. Як би ви розробили глобальну систему доставки контенту для платформи відео-стримінгу, забезпечуючи низьку затримку, високу доступність і відповідність законам про авторські права?

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

Висновок: Балансування обох для успіху

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

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

Перекладено з: Understanding Functional vs. Non-Functional Requirements in Agile: A Comprehensive Guide