Пропущені, неявні або припущені вимоги можуть призвести до прогалин у продукті та неочікуваного перероблення (rework). Саме про це йдеться у новій статті Карла Вігерса, переклад якої, пропонуємо до Вашої уваги
Яким би ретельним не був процес elicitation вимог, неможливо бути впевненим, що ви зібрали їх усі. Немає «зеленого індикатора», який скаже: «Готово!». Стейкхолдери часто очікують певну функціональність і характеристики продукту, не формулюючи їх явно. Нижче наведено підходи, які допомагають закрити прогалини, спричинені пропущеними, неявними та припущеними вимогами.
Пропущені вимоги (Missing Requirements)
Пропущені вимоги складно виявити, бо вони «невидимі». Якщо їх не знайти, команда, ймовірно, не реалізує відповідну функціональність, що призведе до незадоволених стейкхолдерів. Ось кілька технік для їх виявлення:
- Декомпозуйте високорівневі вимоги. Розкрийте їх до достатнього рівня деталізації, щоб однозначно зрозуміти, що саме потрібно реалізувати. Нечіткі вимоги створюють розрив між очікуванням і реалізацією.
- Переконайтеся, що всі user classes надали свій внесок. Кожна вимога користувача має приносити цінність принаймні одній групі користувачів.
- Забезпечте трасування (traceability). Пов’яжіть високорівневі системні вимоги, user requirements, списки подій/реакцій і бізнес-правила з відповідними функціональними вимогами, щоб переконатися, що вся необхідна функціональність визначена.
- Перевіряйте граничні значення (boundary values). Наприклад: якщо є правило «менше ніж 100$» і «більше ніж 100$», то що відбувається при рівно 100$? Такі випадки часто залишаються невизначеними.
- Використовуйте кілька способів представлення вимог. Суцільний текст або набір user stories ускладнює виявлення прогалин. Візуальні моделі можуть показати відсутні зв’язки (наприклад, відсутню стрілку між елементами).
- Аналізуйте складну логіку. Вимоги з булевими операторами (AND, OR, NOT) часто неповні. Якщо для певної комбінації умов немає визначеної поведінки, розробник змушений здогадуватись. Часто пропускаються “else”-сценарії. Використовуйте decision tables або decision trees для покриття всіх варіантів.
- Перевіряйте модель даних (data model). Кожен об’єкт даних має мати відповідну функціональність: створення, читання, оновлення, видалення (CRUD). Переконайтеся, що всі сутності мають визначені відповідні операції.
Припущені та неявні вимоги (Assumed and Implied Requirements)
Я стикався з командою, яка розробляла контент-портал для завантаження, редагування та публікації матеріалів на сайт. Існувало близько 1000 одиниць контенту, організованих ієрархічно. Команда контент-менеджменту припускала, що користувачі зможуть легко навігувати цією ієрархією, щоб швидко знаходити потрібний матеріал для редагування. Проте жодних вимог до навігації в інтерфейсі сформульовано не було.
До теми: ВІГЕРСОПЕДІЯ: Чотири практики для роботи з вимогами
У результаті розробники реалізували інтерфейс без ієрархії — весь контент відображався на одному рівні, по 20 елементів на екран. Щоб знайти потрібний матеріал, користувачу доводилося перегортати до 50 сторінок. Невелика додаткова специфікація та комунікація між командами могла б уникнути значного rework і розчарування користувачів.
Неможливо задокументувати 100% вимог до програмного продукту. Однак саме ті вимоги, які не були явно визначені, створюють ризик, що рішення не відповідатиме очікуванням стейкхолдерів. Найчастіше це пов’язано з припущеними (assumed) і неявними (implied) вимогами.
- Припущені вимоги — це те, що вважається «очевидним» і не проговорюється. Але різні учасники можуть мати різні припущення.
- Неявні вимоги — це вимоги, які логічно випливають з інших, але не сформульовані явно.
Розробники не можуть реалізувати те, про що не знають. Покладатися на «телепатію» чи інтуїцію — ненадійна основа для ІТ-проєкту.
Щоб зменшити ці ризики:
- Виявляйте прогалини в знаннях і ставте питання: «Що ми тут припускаємо?» під час elicitation.
- Перевіряйте валідність припущень і документуйте їх — часто вони застарілі або помилкові.
- Не покладайтеся на існуючі процеси як «єдино можливі» — перевіряйте, чи всі старі функції справді потрібні в новій системі.
Для виявлення неявних вимог:
- Аналізуйте результати elicitation і шукайте «дірки» в логіці.
- Деталізуйте нечіткі високорівневі вимоги.
- Перевіряйте логічні пари (наприклад, save → retrieve, undo → redo).
BA — не просто фіксатор інформації, а дослідник. Він читає «між рядків», виявляючи очікування клієнтів, які ті не озвучили. Важливо ставити відкриті запитання, що розкривають контекст і мотивацію, наприклад:
- «Яка точність потрібна продукту?»
- «Чому ви не погоджуєтеся з цією пропозицією?»
Ще один ефективний підхід — спостереження за користувачем під час роботи з прототипом. Наприклад, користувач може попросити одну функцію, але фактично очікувати іншу поведінку. Виявити це на ранньому етапі значно дешевше, ніж після релізу.
Буде цікаво: Від бізнес-правил до вимог
Ніколи не буде ідеально
Жодна команда не зможе виявити всі вимоги. Але якщо системно звертати увагу на пропущені, припущені та неявні вимоги, можна суттєво зменшити ризики, уникнути проблем у розробці та знизити витрати проєкту в майбутньому.