Хто це вирішує? І коли?
Нещодавно на дегустації вин я спілкувався із двома юристами, з якими щойно познайомився. Одна з них працювала над справою, що стосувалася програмного забезпечення. І вона запитала мене: «Як Ви розумієте, наскільки детально треба розписати вимоги?» Це було таке глибоке питання, над яким б’ються навіть досвідченні бізнес-аналітики.
На це питання не має однієї правильної відповіді навіть, враховуючи те, що ми могли би визначити, як виміряти «деталізацію» вимог. Як і у випадку багатьох схожих питань, правильна, але незадовільна, відповідь – це «Все залежить…».
Хоча я і не можу дати простої відповіді на це важливе питання, я можу запропонувати деякі способи, як зрозуміти, наскільки деталізувати вимоги в певній ситуації. Ця стаття адаптована із моєї книги «Більше про вимоги до програмного забезпечення» (More About Software Requirements).
Хто керує процесом?
Головне питання, яке треба взяти до уваги при визначенні, скільки інформації мають включати в себе вимоги, звучить так: «Кого ми хочемо призначити для прийняття рішень про деталі вимог і коли саме приймати такі рішення?»
Якщо ви бажаєте делегувати розробникам багато точних рішень щодо можливостей продукту та характеристик, ви можете писати менше документації до вимог. Так само, якщо представники замовника можуть співпрацювати з розробниками, щоб одразу з’ясовувати неточності та приймати необхідні рішення під час розробки. Однак, якщо стейкхолдери потребують спільного розуміння, що мають отримати в результаті, варто створити повнішу специфікацію.
Зазвичай треба балансувати між витратами і ризиком. Вимоги, які недостатньо пояснили стейкхолдерам або передали в усній формі, мають набагато меншу цінність, ніж детально написані вимоги, які все ж таки теж мають певні ризики. Єдиний ризик, який нас турбує – це необхідність додатково та незаплановано перероблювати продукт, щоб він був задовільним. Ненавиджу перероблювати.
Справжній приклад
Ось ілюстрація того, як треба деталізувати вимоги. В моєму будинку є система сигналізації. Коли сигналізацію ввімкнуто, і я заходжу в будинок, панель контролю починає на мене пищати. Щоб виключити сигналізацію, я вводжу свій код на цифровій клавіатурі. Можемо сформулювати вимогу до такої функції досить лаконічно: «Коли система сигналізації увімкнена і спрацьовує датчик, користувач повинен мати змогу ввести цифровий код, щоб вимкнути систему.» Це твердження передає загальний зміст, але у ньому не вистачає інформації для розробника, щоб зрозуміти, що саме проєктувати та створювати. Постають такі питання, на які це твердження не дає відповіді:
- Яка мінімальна та максимальна кількість цифр, дозволена у коді? Чи має код складатися лише з цифр?
- Як система розпізнає, що користувач закінчив введення коду, щоб перевірити код?
- Як довго система чекає, поки користувач введе правильний код, перш ніж подає звуковий сигнал?
- Що робить система, якщо користувач вводить неправильний код до закінчення дії таймеру?
- Скільки спроб введення має користувач? Можливо, це функція часу: чи може користувач робити декілька спроб протягом певного проміжку часу?
- Що робить система, якщо користувач вводить, або не вводить, правильний код протягом зазначеного проміжку часу?
- Як може власник будинку встановити чи змінити код? Чи є початковий код?
Звісно, хтось має відповісти на ці питання. Тож, якщо набір вимог не дає такої чіткої інформації, цей обов’язок лягає на девелопера. Він має виявити всі відповідні запитання та або відслідковувати відповіді, або прийняти рішення самостійно, яке може збігатися або не збігатися із тим, що замовник мав на увазі. Якщо саме ви – бізнес-аналітик, то ви маєте обрати найбільш доречний підхід. Чи ви бажаєте, щоб розробники знаходили відповіді на такі питання вже під час етапу розробки? Якщо вони вгадають неправильно, то їм доведеться перебудовувати систему. Або ви краще отримаєте необхідну інформацію від замовника та зафіксуєте її у специфікації вимог (що також буде корисним для тестувальників)? Це ваш вибір. Клієнти інколи ухиляються від того, щоб витратити трохи часу та уважно обдумати такого роду питання і, нарешті, прийняти рішення. У такому випадку я запитую замовника: «Якщо ви не хочете вирішувати зараз, то хто має це зробити і коли?» Розробники інколи люблять мінімальні специфікації, адже це дає їм більше свободи щодо того, як трактувати вимоги. Проте, пам’ятайте одну з моїх Десяти Космічних Істин про Вимоги до Програмного Забезпечення: «Вимоги можуть бути неясними , але продукт має бути конкретним.» Головне питання – від кого йде ця конкретика. Рисунок 1 демонструє деякі ситуації, коли потрібно детальніше описувати вимоги у документації, та інші випадки, коли буде достатньо меншої точності. У наступних розділах ми детальніше розглянемо ці умови.
До теми – ВІГЕРСОПЕДІЯ – Десять вселенських істин про вимоги до програмного забезпечення.
Рисунок 1. Фактори, які впливають на те, наскільки детальними мають бути вимоги
Коли доцільно менше деталізувати вимоги
Є декілька умов, за яких можна залишити опис вимог на більш абстрактному рівні. Бізнес-аналітик має постійно проводити аналіз ризиків, щоб збалансувати потенційний пропуск важливої інформації та зусилля, які потрібні, щоб записати її.
Достатнє залучення клієнта. Постійна і тісна співпраця із правильними представниками замовника може замінити вичерпну документацію вимог. Розробники повинні просто мати достатньо записаної інформації, щоб оцінити розмір кожної вимоги та мати загальне розуміння ідеї клієнта. Деталі вже надійдуть пізніше через розмови із замовниками та фахівцями у цій сфері. Такий підхід працює, коли розробники мають прямий доступ до людей, які мають час, знання та повноваження приймати рішення від імені групи людей, яку вони представляють. Навіть коли замовник може надати деталі вчасно, стейкхолдерам важко зрозуміти, чого очікувати, якщо цю інформацію не записали. Звичайно, можна також записувати деталі до вимог по мірі того, як їх з’ясовують. Тож вимоги будуть зростати поступово та без особливих зусиль.
Розробники мають значний доменний досвід. Розробники, які мають широкі знання у сфері застосування, інколи можуть самостійно надати більшість необхідних деталей до вимог. Проте остерігайтеся таких розробників, які дуже впевнені в собі та вважають, що знають, що потрібно користувачам, не питавши про це. Навіть розробники із досвідом у певній галузі не завжди знають теперішні потреби користувачів в умовах бізнесу, що змінюється.
Є схожі прецеденти. Коли є схожі кейси із попередніх проєктів, розробники можуть звернутися до продукту чи документації, що вже існують, якщо не вистачає певних деталей. Це може статися, під час оновлення застарілої програми, наприклад. Однак, будьте уважні. Програмне забезпеченні іноді містить значну функціональність, яку просто так не помітно, якщо подивитися на інтерфейс або загальний опис продукту. Не треба змушувати кожного розробника проєктувати поточну систему у зворотному напрямку, щоб зрозуміти все, що вона робить.
Буде застосовано пакетне рішення. Нема потреби писати вичерпні функціональні вимоги, якщо ви плануєте придбати комерційне пакетне рішення для всього функціоналу або для його частини: його постачальник вже зробив це (або ви на це сподіваєтесь). Проте, дуже рідко, коли пакетне рішення повністю задовольняє ваші потреби, тож вам все одно треба деталізувати вимоги до пакетів, інтеграцій та налаштувань. Сценарії використання (use cases) та користувацьке приймальне тестування (user acceptance tests) – дуже ефективні техніки створення вимог для проєктів, де застосовують пакетні рішення. Такий пакет дозволяє вашим користувачам виконати певні завдання (сценарії використання), хоча деталі, як це працює, можуть відрізнятися у різних комерційних пакетах (функціональні вимоги та дизайн інтерфейсу). Той, який ви обрали, має відповідати певним бізнес-правилам. А також має дати вам можливість налаштувати ці правила за потреби. Стейкхолдерам буде легше обрати правильне комерційне рішення, якщо будуть визначені атрибути якості до вимог.
Коли бажано додавати більше деталей.
Також у певних ситуаціях наявність вимог лише на високому рівні може значно збільшити ризик проєкта. У таких випадках розраховуйте, що на створення достатньо деталізованих вимог піде більше часу, ніж зазвичай.
Розробка ведеться через підрядників. Коли всі стейкхолдери знаходяться на одному континенті, а розробники – на іншому, то у вас нема можливості для щоденної взаємодії, щоб конкретизувати деталі, відповісти на питання та з’ясувати неточності. Нема іншого виходу ніж, надати усю потрібну інформацію у формі написаної специфікації або приймальних тестів. Намагайтеся усунути всі невизначеності до того, як надсилати документацію розробникам. Та пам’ятайте про відмінності рідних мов підрядників, які можуть призвести до плутанини.
Члени команди знаходяться в різних локаціях. Навіть невелика відстань між членами проєкту приводить до гальмування комунікації. Давним-давно я писав програми для дослідника, який сидів просто за декілька метрів від мого стола. Одного дня Джон переїхав до іншого офісу метрів за триста. Моя продуктивність моментально впала. Тепер же мені доводилося довше чекати, щоб отримати відповіді на мої питання. Мені треба було домовлятися із Джоном про зустріч, дзвонити йому або спускатися вниз у вестибюль, хоча раніше я просто міг поставити запитання і одразу отримати відповідь. Якщо ви сумніваєтесь, що клієнти будуть завжди під боком, щоб надати потрібну інформацію, вам краще здобути цю інформацію від час фази написання вимог.
Тестування базується на вимогах. Якщо тестувальники будуть писати вичерпні системні та приймальні тести за вимогами, вони мають знати, чого очікувати від системи за певних умов. Це особливо важливо, якщо тестувати будуть люди, які не були залучені у процес розробки. Тести повинні охоплювати не тільки очікувану поведінку, але й відомі виняткові умови, які можуть виникнути. Вимоги мають описувати ці винятки досить добре, щоб тестувальники могли визначити, чи правильно їх обробляє продукт. Якщо визначити потенційні проблеми та як система має на них відповідати, то продукт буде більш надійним.
Потрібна точна оцінка. Люди, які мають розрахувати зусилля і графік за вимогами, потребують достатньо інформації. Одного разу я побачив невинну на вигляд вимогу – лише одну із 700 вимог на великий проєкт – в якій було написано: «Редактор має відповідати на команди редагування, записані голосом.» Це просте твердження мало на увазі необхідність створення цілої системи розпізнання мовлення та інтерфейсу! Неможливо оцінити вартість, не розбиваючи таке обширне твердження на більш детальні, щоб краще зрозуміти його об’єм та складність. Потрібно відстежувати вимоги. Відстеження вимог має на меті створення логічних зв’язків між окремими функціональними вимогами, їхнім походженням та іншими компонентами, які задовольняють кожну вимогу. Якщо для вашого проєкту важливо відслідковувати вимоги, вам слід детально описувати їх. При розробці певних продуктів критичної безпеки таких як медичні прилади або системи авіації обов’язково треба відслідковувати усі вимоги, щоб сам продукт було сертифіковано для використання. Відстеження інформації гарантує, що в системі нема додаткового відгалуженого коду та що жодну вимогу не пропущено. Це дозволяє виконати такі умови:
- Усі вимоги поєднані із елементами дизайну ПЗ.
- До кожного елементу дизайну можна відслідкувати певну вимогу.
- Увесь написаний код поєднаний із елементом дизайну і, таким чином, із вимогою.
- Усі вимоги були застосовані для написання коду.
- Тест-кейси наявні для кожної вимоги.
- Усі тест-кейси відповідають принаймні одній вимозі.
Якщо ви працюєте у сфері, яка суворо регулюється, то ви вже знаєте, чи вам потрібна така інформація щодо взаємозв’язку вимог та інших елементів. В іншому випадку, вибір повністю за вами. Щоб успішно відстежувати вимоги, вам необхідні час, терплячість, власне процес відстеження та інструмент для зберігання даних.
Приклади рівнів деталізації вимог
Згадайте систему сигналізації, яку я зазначив вище. Розгляньмо, як ми можемо описати функціональні вимоги для вимкнення запущеної системи. Наша окрема оригінальна вимога записана на високому рівні розуміння: «Коли система сигналізації увімкнена і спрацьовує датчик, користувач повинен мати змогу ввести цифровий код, щоб вимкнути систему.»
Ми побачили деякі питання, які можуть виникнути у розробника, який отримає цю вимогу. Таблиця нижче показує, як БА має конкретизувати таку дуже обширну вимогу детальнішими функціональними вимогами, якщо він/вона вважає, що в цьому є сенс. (Ці вимоги написано у ієрархічній послідовності. При цьому застосовано таку систему іменування, при якій кожна вимога, що походить від іншої, має унікальну назву, наприклад, Disarm.Timeout. Ці вимоги написані на рівні окремих вимог, які можна протестувати. Власне ж похідна вимога, Disarm, вказана у вигляді назви, а не твердження окремої вимоги).
Як і будь-які вимоги, ці, звичайно, ще теж треба допрацювати, але вони дають набагато більше деталей, ніж оригінальна вимога. Хоча ці функціональні вимоги відповідають на багато поставлених раніше питань щодо поведінки системи сигналізації, у них все ще не вистачає важливої інформації.
Як саме має звучати «звуковий сигнал», описаний у вимозі «Disarm.Sound»? Наскільки голосно? Чи визначити одразу ці деталі до вимог, чи залишити їх на розсуд розробника під час розробки (із вхідними даними та затвердженням від правильного клієнта, я сподіваюсь), залежить від того, хто приймає рішення: замовник, БА чи розробник. Чи вимоги на вашому проєкті потребують такого рівня деталізації? Чи це просто перелік основних функцій, яких має бути достатньо? Це ваше рішення. Ніж вгадувати достатню кількість деталей, БА та розробникам слід працювати разом, щоб визначити, наскільки варто деталізувати вимоги. Це все одно ризик. Ви не бажаєте витрачати більше часу на вимоги, ніж потрібно, але ви теж і не хочете перероблювати частини продукту, щоб він був таким, яким має бути.
Остаточне звернення
Кожного разу коли ви, ваші колеги чи ваші клієнти ухиляються від докладання зусиль, щоб задокументувати вимоги, пам’ятайте, що складніше – не записувати вимоги взагалі. Найважче – це саме визначити вимоги. Запис вимог є здебільшого продуманою транскрипцією. Я переважно записую все, про що не впевнений, що стейкхолдери це знають, або все, що треба зберегти для використання в майбутньому. Не спирайтеся на телепатію або ясновидіння як технічні основи на вашому проєкті. Вони не працюють.
Оригінальна стаття – How Detailed Should Requirements Be?, переклад Валерія Кулішова, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Зображення з оригінальної статті Карла Вігерса.