Функціональні вимоги: як писати, приклад і шаблон

Аналітик пише: «Система має швидко й зручно показувати клієнтові статус замовлення та не допускати помилок». Розробник читає «швидко» як «за секунду», тестувальник — як «без спінера», замовник — як «клієнт не дзвонить у підтримку». Усі троє згодні з фразою і розуміють під нею різне. Суперечка почнеться на прийманні, коли переробляти вже дорого.

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

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

Формула однієї вимоги

Коли [подія або умова], система має [дію] [об’єкт], [результат або обмеження].

Приклад: «Коли клієнт відкриває сторінку замовлення, система має показати поточний статус доставки та час його останнього оновлення».

У формулі чотири частини, і в кожної своя робота. Умова говорить, коли вимога діє, — без неї незрозуміло, що перевіряти. «Система має» фіксує, хто діє: не користувач, не співробітник, а система. Дія та об’єкт — це і є поведінка, яку побачать ззовні. Результат відповідає на питання, як зрозуміти, що все спрацювало.

Схожий шаблон — EARS, Easy Approach to Requirements Syntax — придумали Алістер Мавін та його колеги в Rolls-Royce, коли розбирали вимоги до системи керування реактивним двигуном. Вперше його опублікували в 2009 році. Ідея та сама: жорсткий порядок частин і кілька ключових слів замість вільного тексту.

Умова буває не в усіх вимог. «Система має зберігати історію змін статусу замовлення» діє завжди, і починати її з «коли» не потрібно. Але якщо умова є, а в тексті її немає, — це перше, про що запитає тестувальник.

Одна фраза — від поганої до хорошої

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

Вихідна фраза: «Система має швидко й зручно показувати клієнтові статус замовлення та не допускати помилок».

Правка 1 — дві вимоги в одній фразі. Тут приховано щонайменше дві вимоги: показувати статус і не допускати помилок. Їх не можна перевірити одним тестом і не можна окремо відкласти чи скасувати. Розділяємо:

• «Система має швидко й зручно показувати клієнтові статус замовлення».
• «Система має не допускати помилок під час показу статусу».

Правка 2 — оцінка замість поведінки. «Швидко» й «зручно» не перевіряються: у кожного читача своя міра. Швидкість — це окрема, нефункціональна вимога, і писати її потрібно в цифрах. «Зручно» зазвичай приховує конкретну поведінку — запитуємо замовника, яку. З’ясовується: клієнтові важливо розуміти, наскільки статус свіжий.

• «Коли клієнт відкриває сторінку замовлення, система має показати поточний статус доставки та час його останнього оновлення».

Правка 3 — заперечення. «Не допускати помилок» говорить, чого не повинно бути, але не говорить, що система робить замість цього. Розробник не знає, що будувати, а тестувальник — що перевіряти. Запитуємо: яка помилка мається на увазі? Виявляється, служба доставки іноді не відповідає, і сторінка показує порожнє місце. Переписуємо в поведінку:

• «Коли служба доставки не відповідає, система має показати останній отриманий статус і позначку, що він може бути застарілим».

Правка 4 — влаштування замість поведінки. На обговоренні розробник пропонує уточнити першу фразу: «Система має запитувати статус у служби доставки кожні п’ять хвилин і зберігати його в базу». Це не вимога, а спосіб її виконати. Через місяць служба доставки почне сама надсилати повідомлення, опитування стане непотрібним — і вимогу доведеться переписувати, хоча клієнтові нічого не змінилося. Залишаємо те, що видно ззовні, а спосіб лишаємо технічному рішенню.

Підсумок: з однієї розпливчастої фрази вийшли дві перевіряні функціональні вимоги та одна нефункціональна, про швидкість, яка пишеться окремо:

1. «Коли клієнт відкриває сторінку замовлення, система має показати поточний статус доставки та час його останнього оновлення».
2. «Коли служба доставки не відповідає, система має показати останній отриманий статус і позначку, що він може бути застарілим».

Ці чотири помилки не вигадані для прикладу. Стандарт вимог ISO/IEC/IEEE 29148 прямо перелічує, чого слід уникати у формулюванні: найвищих ступенів порівняння, суб’єктивних оцінок, розпливчастих займенників, порівнянь, лазівок на кшталт «за можливості» та заперечень. Правила списком є всюди, але на одній фразі видно, як кожне з них змінює сенс.

Шаблон набору вимог

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

Виділіть таблицю повністю та вставте в Confluence, Excel або Google Таблиці: стовпці збережуться.

Що робить кожен стовпець:

• ID — короткий номер. На нього посилаються в задачах, тест-кейсах і суперечках: «ФТ-02 не виконано» зрозуміліше, ніж переказ фрази.
• Формулювання — одна фраза за формулою вище.
• Джерело — бізнес-вимога, заради якої потрібна функція. Якщо джерело не знаходиться, це привід запитати, навіщо вимога взагалі в списку. На цьому стовпці тримається трасування — як його побудувати, розібрано в статті матриця трасування вимог: приклад і шаблон.
• Критерій перевірки — що зробить тестувальник і що побачить. Якщо критерій не вдається написати, формулювання потрібно правити ще раз.
• Пріоритет — тут MoSCoW: Must, Should, Could, Won’t. Підійде будь-яка шкала, яку команда розуміє однаково.

Чого в шаблоні немає навмисно: розділів документа, титульного аркуша, глосарія. Це будова документа, а не вимоги. Який документ потрібен під задачу, розібрано в статті BRD, FRD і SRS: який документ коли потрібен.

Де закінчується функціональна вимога

Якщо вимога записана історією або сценарієм, формула та сама, змінюється лише обгортка: як вибрати між ними, розібрано в статті User Story і Use Case: чим відрізняються і що писати.

Те, що залишилося після правки 2 — «швидко», — не функціональна вимога. Воно говорить не що робить система, а наскільки добре. Такі вимоги пишуть окремо і теж вимірно: час відповіді в секундах, частка доступності у відсотках.

Як це звучить на співбесіді

У нашому банку питань з реальних співбесід функціональні вимоги — що це і чим вони відрізняються від бізнес-вимог — зустрічаються в 15 питаннях, і 7 з них позначені як junior. Тему питають уже на початковому рівні.

Слабка відповідь — визначення та список властивостей: «функціональні вимоги описують, що робить система, вони мають бути повними, однозначними й перевіряними». Правильно, але так відповідає будь-хто, хто прочитав підручник.

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