Матриця трасування вимог: приклад і як її вести

Вимога змінюється в п’ятницю ввечері. Замовник просить надсилати статус замовлення ще й у SMS — пошти мало. Тімлід ставить нормальне питання: що зламається? І виявляється, що відповісти нікому. Аналітик пам’ятає про лист, тестувальник — про свої кейси, розробник — про сервіс, який смикає шлюз. Цілісну картину не тримає в голові ніхто.

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

На співбесіді про неї питають часто, а відповідають зазвичай половиною: «таблиця, де вимоги зіставлені з тестами». Це правда. Але це найнудніша її половина, і по ній одразу чути, що людина матрицю бачила на слайді, а не вела.

Що вона пов’язує насправді

Визначення з ISO/IEC/IEEE 29148:2018 — міжнародного стандарту з роботи з вимогами — звучить сухо, зате точно: трасування (traceability) — це ідентифікація та документування шляху виведення вгору і шляху розподілу вниз усередині набору вимог. Вимогу, з якої виведено іншу, стандарт називає батьківською, виведену — дочірньою.

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

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

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

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

Матриця — не звітність для галочки. Це єдине місце, де на питання «що зламається» відповідають за хвилину, а не за день.

Приклад: п’ять рядків, з яких можна почати

Інтернет-магазин. Ціль кварталу — розвантажити підтримку: занадто багато звернень «де моє замовлення».

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

Повернімося до п’ятничного прохання про SMS. Дивишся на рядок FR-13: вгору від неї SH-4, вниз — шаблон листа і один тест. Отже, додається брат FR-13, а не правка FR-12; екран не чіпаємо, NFR-3 про п’ять хвилин залишається чинним і поширюється на новий канал. Відповідь тімліду зайняла хвилину.

Зверни увагу на рядок BG-1. У неї порожньо в колонці реалізації — і це нормально: бізнес-ціль не реалізують кодом, її перевіряють метрикою. Порожня клітинка тут означає не дірку, а межу.

Що про трасування говорить BABOK

У BABOK трасування — не прийом, а окреме завдання: 5.1 Trace Requirements у галузі знань «Управління життєвим циклом вимог». Там же названі типи відносин. Їх рівно чотири: derive, depends, satisfy і validate.

• Derive — одна вимога виведена з іншої, між ними різні рівні абстракції. FR-12 виведена з SH-4.
• Depends — вимога залежить від іншої. Два підвиди: necessity, коли реалізовувати її наодинці безглуздо, і effort, коли можна, але разом дешевше.
• Satisfy — зв’язок елемента реалізації з вимогою, яку він закриває. Сервіс статусів закриває FR-12.
• Validate — зв’язок вимоги з тест-кейсом, який підтверджує, що рішення відповідає вимозі.

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

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

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

Інструменти звід не називає взагалі, і це свідомо. Про сховище трасування сказано рівно одне: у складних випадках його автоматизують. Третя редакція вийшла у 2015 році й досі актуальна — чекати від неї списку сучасних систем безглуздо, вона задає правила, а не продукти.

Про сам звід знань і те, навіщо він аналітику, — у статті Що таке BABOK і як ми його використовуємо.

Що вона ловить

Три речі, заради яких її взагалі заводять.

Сиріт. Вимога без жодного зв’язку вниз — ніхто не реалізував і ніхто не перевірив. Тест-кейс без зв’язку вгору — тестуємо те, чого не просили. Стандарт пропонує це навіть міряти: частка батьків без дітей і середня кількість дочірніх вимог на батька, де друге — індикатор складності дизайну. У нашій таблиці сироту видно очима: якби у FR-13 у колонці перевірки було порожньо, лист про зміну статусу поїхав би в реліз непротестованим, і помітили б це клієнти.

Вплив змін. Та сама п’ятниця з SMS. Без матриці питання «що зламається» перетворюється на опитування трьох людей і все одно закінчується словом «нібито».

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

Скільки це коштує і коли не треба

Тепер чесна частина, яку на курсах промовляють рідко. Зв’язки не з’являються самі й не підтримуються самі. Кожен новий рядок — робота, яку хтось робить вручну і потім оновлює при кожній зміні.

Чим складніша мережа зв’язків, тим дорожче тримати її живою — саме тому звід і вимагає визначити рівень формальності заздалегідь, а не по ходу справи. Рішення приймається один раз і усвідомлено: що трасуємо, до якого рівня, чим.

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

З чого почати, якщо матриці немає

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

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

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

Як це робиться сьогодні: трасування з моделлю

Найнудніша частина трасування — не думати, а зіставляти. Шістдесят вимог, двісті тест-кейсів, і треба зрозуміти, що з чим пов’язано. Саме тут мовна модель економить години, а не вдає інтелект.

Три прийоми, які справді працюють.

Первинне зіставлення. Даєш моделі список вимог і список тест-кейсів, просиш пов’язати і повернути дві таблиці: що зіставилося і що ні. Цінність — у другій. Це готовий список кандидатів у сироти, який вручну збирався б пів дня.

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

Чернетка аналізу впливу. «Змінюємо FR-13, ось матриця — що зачеплено?» На виході список кандидатів, який ти перевіряєш очима. Хвилини замість листування з трьома колегами.

Далі — червона лінія, і вона жорсткіша, ніж здається. Модель уміє придумати зв’язок, якого немає. Хибний зв’язок небезпечніший за відсутній: порожня клітинка видна і викликає питання, а неправильна виглядає як виконана робота і не викликає нічого. Тому правило просте: модель пропонує — людина підтверджує. У матрицю потрапляє лише те, де ти відкрив вимогу і перевірку та переконався сам.

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

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

Чому я трасую не лише вимоги

Далі особиста думка, і вона ширша за тему. Цінність трасування не в таблиці, а в звичці ставити два питання: звідки це взялося і як я зрозумію, що це спрацювало. Звичка переноситься куди завгодно.

Курс, який ми робимо, зібраний саме так. Не від красивого змісту вниз, а знизу вгору — від банку реальних питань зі співбесід. Кожен модуль трасується до того, скільки питань на нього припадає. Модуль, під який питань майже немає, у програму не потрапляє, яким би обов’язковим він не виглядав у чужих курсах. Це та сама матриця: вгору — потреба, вниз — матеріал.

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

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

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

Слабка відповідь — «таблиця, де вимоги зіставлені з тестами». Формально вірно, далі розмова не йде.

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