Алістер Мавін та команда Rolls-Royce PLC розробили та представили концепцію підходу EARS на конференції з Інженерії Вимог (RE 09) в 2009 році.
У світі розробки програмного забезпечення (далі – ПЗ), завдання синтаксису вимог може бути складним та відлякуючим. Маючи так багато різних елементів, які потрібно враховувати, дуже легко загубитись в деталях, втративши при цьому бачення загальної картини. І тоді у пригоді стає EARS – Легкий Підхід до Синтаксису Вимог.
EARS – це простий та ефективний спосіб організувати та сформулювати вимоги до програмного забезпечення, який допомагає зробити цей процес доступнішим та простішим.
Що таке вимога?
Вимогою називають твердження, яке описує факт, що підпадає під одну з декількох категорій:
- Які дії чи функції повинна виконувати система
- Будь-які внутрішні чи зовнішні обмеження ресурсів чи дизайну, які можуть впливати на систему
- Рівень продуктивності чи якості, який очікується від системи.
Перший вид вимог відомий як функціональні вимоги, а другий та третій види підпадають під категорію нефункціональних вимог (НФВ).
Наведімо декілька прикладів функціональних та нефункціональних вимог:
Функціональні вимоги:
- Вебсайт повинен надавати можливість користувачам створювати облікові записи та безпечно входити в ці облікові записи.
- Мобільний застосунок повинен надавати можливість користувачам купувати продукти та послуги, використовуючи для оплати кредитні картки.
Нефункціональні вимоги:
- Вебсайт повинен витримувати великий обсяг трафіку, не ламаючись та не сповільнюючись.
- Мобільний застосунок повинен бути сумісним з операційними системами iOS та Android.
Існують деякі проблеми, яких не уникнути навіть якщо приділити достатньо уваги вимогам в процесі дизайну системи. Я наведу приклади цих проблем, щоб розширити наше бачення вимог:
- Багато авторів вимог не проходили формальних навчань ефективного написання вимог.
- Вимоги часто пишуть розмовною мовою, без будь-яких обмежень, що призводить до двозначності, нечіткості та субʼєктивності.
- Вимоги можуть бути незрозумілими, занадто деталізованими чи незвʼязними, і це ускладнює розуміння того, що потрібно зробити.
- Деякі вимоги можуть не містити подій-тригерів чи важливого контексту.
- Логіка у вимогах може бути незавершеною.
- Низькоякісні вимоги часто копіюють та дублюють, що призводить до зростання кількості дефективних вимог.
Підхід EARS виділяє пʼять шаблонів вимог
- Повсюдні (зустрічаються завжди): Визначають основні властивості системи.
- Керовані подіями: описують поведінку системи, яка відбувається тільки за умови настання події-тригера.
- Небажана поведінка: описують небажані випадки, такі як помилка, збій, несправність, порушення та інші види небажаної поведінки системи.
- Керовані станом: описують поведінку системи, яка відбувається тільки під час певного стану системи.
- Додаткові функції: функції, які викликаються лише в системах, які підтримують ці додаткові функції.
Шаблони EARS
| Назва шаблону | Шаблон |
| Повсюдні | Система повинна <відповідь системи> |
| Керовані подіями | КОЛИ відбувається <подія-тригер>, ТОДІ система <назва системи> повинна <відповідь системи> |
| Небажана поведінка | ЯКЩО відбувається <небажана умова чи подія>, ТОДІ система <назва системи> повинна <відповідь системи> |
| Керовані станом | У ТОЙ ЧАС, ЯК система перебуває у стані <стан системи>, система <назва системи> повинна <відповідь системи> |
| Додаткові | КОЛИ <функція включена>, система <назва системи> повинна <відповідь системи> |
| Складні | (комбінація вищенаведених шаблонів) |
Приклади:
Повсюдна вимога: Програмне забезпечення буде написане на мові програмування Python.
Керована подіями вимога: Коли кошти буде отримано, тоді ПЗ повинне надіслати сповіщення.
Небажана поведінка: Якщо пароль було введено невірно, тоді ПЗ повинне відобразити повідомлення про помилку.
Керована станом вимога: Коли система перебуває в режимі “Не турбувати”, тоді ПЗ повинне заглушувати вхідні дзвінки.
Додаткова вимога: Коли підключено кабель DP, тоді ПЗ повинне надати користувачу можливість переглядати максимальну підтримувану частоту оновлень.
Складна вимога: Коли кнопку заднього ходу натиснено один раз, якщо ПЗ виявило, що задню передачу не встановлено, тоді ПЗ повинне відобразити сповіщення.
Крім того, я б хотів згадати про ситуації, що відбуваються, коли ми натрапляємо на неоднозначну вимогу, та як виправити таку вимогу за допомогою шаблону EARS. Погляньмо на приклад.
Оригінальна вимога:
- Система повинна розірвати мережеве зʼєднання.
Вимога, написана з використанням EARS:
- Коли було натиснуто кнопку відʼєднання, тоді ПЗ повинне розірвати мережеве зʼєднання.
Висновок:
Підхід EARS – це потужний інструмент для документування вимог ПЗ. Використовуючи цей стандартизований шаблон, команди розробників ПЗ забезпечують чітку та послідовну документацію вимог, полегшуючи відстеження прогресу та забезпечення виконання всіх вимог. Незалежно від того, чи розробляєте ви невеличкий застосунок, а чи велику корпоративну систему, підхід EARS допоможе вам легко та ефективно задокументувати ваші вимоги до ПЗ.
Оригінальна стаття – EARS: The Easy Approach to Requirements Syntax, переклад – Іванна Івченко, ревью – Іван Вільчавський. Зображення згенероване за допомогою DALL-E у ChatGPT.