SDD — це ренесанс чи кінець бізнес-аналізу? Або як специфікація може стати виконуваним кодом

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Я — Олександр Москалюк, директор з залучення та членства IIBA Ukraine. Я кілька тижнів тому почав активно використовувати Claude Code, і цей досвід примусив мене повірити в силу ШІ-агентів та SDD-підходу.

Коли аналітики чують Specification-Driven Development або SDD, то перше реакція: «А що, буває інакше?». Адже вся робота бізнес-аналітика — це підготовка вимог, на основі яких має відбуватись розробка продукту. Тобто фактично Specification-Driven Development.

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

На щастя для багатьох аналітиків, розробників та інших учасників ІТ-команд вайб «вайб-кодінгу» швидко проходить. Але після того, як вайб розвіюється, стає зрозуміло, що зміни в роботі ІТ команд таки відбулись. SDLC залишився і стає ще більш потрібним, а ШІ-агенти стають повноправними членами команди. Саме за допомогою ШІ-агентів з’явилась можливість автоматичної трансформації вимог в код без втручання розробників. Тобто аналітик пише вимоги, а ШІ-агент конвертує його в програмний код, деплоїть на дев, тестує та релізить на прод. Такий процес і називають Specification-Driven Development.

Зараз вже стає буденністю, коли команда з трьох людей — бізнес-аналітик, ШІ-інженер і продакт — за шість тижнів мігрує 3 500 тест-файлів. Раніше, за оцінками тієї ж команди, це зайняло б півтора року. Airbnb зробила це не в уявному майбутньому, а вже зараз. Google звітує, що 80% змін у коді при певних міграціях вже генерується ШІ.

Ще кілька тижнів тому я скептично ставився до цієї ідеї, поки не спробував попрацювати з Claude Code. Те що у мене получилось за кілька днів повністю змінило моє відношення до SDD, і дана стаття є результатом тих змін.

Звідки взявся SDD і чому саме зараз

Specification-Driven Development — не нова концепція. Першу академічну згадку відносять до 2004 року, де SDD описується як синтез Test-Driven Development та Design-by-Contract. Двадцять років ця ідея існувала десь на периферії методологічних дискусій, поки в 2025-му не відбулося щось важливе: ШІ-агенти навчилися читати специфікації й перетворювати їх безпосередньо в робочий код.

Amazon випустив Kiro. GitHub — Spec Kit. З’явилися Tessl та інші інструменти. Раптом стара ідея про «специфікацію як єдине джерело істини» набула цілком практичного сенсу. Не тому що методологи наполягли, а тому що інструменти дозріли.

Проблема вайб-кодингу, яку не прийнято визнавати вголос

Andrej Karpathy, один із засновників OpenAI, у лютому 2025 року описав «vibe coding» — підхід, при якому розробник просто спілкується з ШІ природною мовою, не занурюючись у деталі реалізації. Звучить чудово. На практиці виявилося, що якщо попросити ШІ «впровадити дозволи користувача» без детальної специфікації, агент може згенерувати технічно коректний, але бізнесово неправильний код RBAC — без гранульованих дозволів, без тимчасового доступу.

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

Тріада SDD: яка роль BA

SDD можна розкласти на три складові:

1. Бізнес-вимоги та вимоги користувачів — часто оформляються у вигляді BRD
2. Системні вимоги — часто оформляються у вигляді SRS
3. Тести — часто оформляються як тести :)

Нічого не нагадує? Якщо додати транзитні вимоги, то отримаємо класичну класифікацію вимог з BABOK від IIBA. Але саме цікаве заховане в деталях, тому давайте розглянемо кожну складову окремо.

BRD (Business Requirements Document) — це соціальний контракт з бізнесом. Тут немає назв таблиць і технічних деталей, але є залізна логіка: як рухаються гроші, документи, процеси. Сценарії у форматі BDD (Given-When-Then), матриця ролей, UML Activity Diagrams або BPMN. Саме цей рівень — традиційна зона відповідальності BA.
Саме в BRD фіксуються вимоги бізнесу та більшість користувацьких вимог в форматі, який простіше погодити з бізнес-замовниками. Також важливо не забути включити в BRD не-технічні транзитні вимоги, пов’язані з навчанням користувачів, зміною процесів та нормативних документів.

SRS (Software Requirements Specification) — це технічний контракт з командою розробки, сформований на основі бізнес-вимог та вимог користувачів з BRD. Це набір функціональних та нефункціональних вимог, оформлених у вигляді ERD, State-Machine, Data Dictionary, TDD-сценаріїв. Якщо BRD каже «що», SRS каже «як реалізувати в конкретній системі, не зламавши ядро». Саме SRS буде основою для розробки коду ШІ-агентом. В SRS можна, і навіть потрібно, включати технічні транзитні вимоги, такі як оновлення користувацької документації, CI/CD процедури, підготовку та обробку даних як до, так і після релізу.

Тести — автоматизована валідація технічного контракту або автоматизовані тести, які виконує ШІ-агент щоб перевірити правильність виконання вимог в BRD та SRS. Якщо тест проходить, але не відповідає SDD — це дефект, навіть якщо код «працює».

Тести можуть бути як приймальними та функціональними, так і регресними та інтерфейсними. Якщо аналітик та його ШІ-агент підготував разом з BRD та SRS тестові набори даних, то ШІ тест-агент може автоматично протестувати весь розроблений функціонал та повернути його на доопрацювання ШІ дев-агенту.

Зі свого досвіду можу додати, що спостерігати як тест-агент знаходить баги, а дев-агент їх виправляє дуже цікаво. Іноді я навіть запитую себе, коли дев-агент почне сваритись з тест-агентом, що код це не баг, а фіча.

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

Три варіанти SDD: вибирайте свій

В документації описують три варіанти реалізації SDD.

Spec-First (спочатку документація, потім код). BA разом з ШІ-інструментом (Gem-бот, Kiro, Copilot) опитує стейкхолдерів, формує BRD, SRS, прототипи та дизайни. ШІ-агент-розробник отримує не розмиті user story, а структурований документ для генерації коду. Особливістю такого підходу є те, що в процесі роботи між специфікацією та кодом можуть формуватись розбіжності через оновлення коду під-час тестування без оновлення документації. Зі свого досвіду можна сказати, що це, нажаль, стається в більшості проектів.

Spec-Anchored (Living Documentation або жива документація). Специфікація та код існують паралельно і постійно синхронізуються. Будь-яка зміна в коді також відображається і в SRS (BRD не повинна мінятись, оскільки технічна реалізація не повинна суперечити бізнес-вимогам). Це ідеальна ситуація, коли ми маємо актуальні вимоги, які повністю відповідають працюючому продукту.

Spec-as-Source (вимоги як джерело коду) — "світле«майбутнє з ШІ. Людина редагує специфікацію, а ШІ-агент автоматично генерує код, XML-views, правила безпеки. Специфікація і є вихідний код. Такий підхід нівелює потребу в синхронізації документації та коду — без змін документації зміни в коді не відбуваються. Виглядає як мрія будь-якого аналітика.

Що змінюється для BA?

З тексту вище можна зробити важливий висновок: для SDD якість вимог стає критично важливою, оскільки втрачається можливість коригування помилок в вимогах за рахунок зв’язків аналітик-розробник-тестувальник. Тобто в процесі роботи аналітик може щось додатково пояснити розробнику, тестувальник щось знайде і вони швидко поправлять це з розробником. У випадку SDD це не получиться: які вимоги ШІ-агент отримає на вході, такі результати ви побачите на екрані (і добре, якщо тільки на екрані).

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

ШІ в цьому процесі може допомогти з технічними задачами: зробити транскрипт зустрічі з замовником, підготувати нотатки, BRD та SRS, намалює діаграми, прототипи чи дизайни, підготує тести та документацію для користувачів. Що ШІ не може зробити — це підтвердити, що все це саме те, що потрібно замовнику. Саме тут і потрібен аналітик: вичитати та перечитати все, що нагенерував ШІ, відповісти на дуже багато уточнюючих запитань, попросити перегенерувати все по кілька разів, поки не отримаєш потрібний результат. І все це з максимальною увагою, оскільки пропущена дрібниця може вирости в великий і нікому не потрібний шматок функціоналу. А потім показати все це бізнес-замовникам і повторити попередній процес з їх правками.

Трохи новин з ІТ-полів:

McKinsey описує «one-pizza pods» — команди з 3-5 людей, де інженери оркеструють ШІ-агентів замість того, щоб писати кожен рядок коду вручну. Один з кейсів, про який говорять відкрито: два фахівці — BA і ШІ-інженер — можуть замінити те, що раніше потребувало значно більшої команди. BA відповідає за функціональні вимоги і специфікації. ШІ-інженер валідує, виконує, тестує і вдосконалює.

Thoughtworks у своєму огляді SDD зазначає принципову вимогу до специфікацій: вони мають використовувати «domain-oriented ubiquitous language» для опису бізнес-намірів, а не технічних деталей реалізації.

Обидві цитати повністю підтверджують зміну ролі бізнес-аналізу при використанні SDD, а разом з тим і збільшення навантаження на аналітиків. З іншого боку SDD дає можливість змінити процес взаємодії з бізнес-замовниками. За умови використанням добре налаштованих інструментів вже на зустрічі з замовником можна згенерувати діаграми, прототипи, BRD та спробувати погодити їх. Для довгих проектів або для продукту це повністю реально, оскільки там вимоги відносно стандартні і під них можна налаштувати всі потрібні інструменти. Для розробки нових продуктів це буде складніше, але при відповідній спеціалізації можливо.

З чого почати, якщо ви вирішили спробувати SDD?

Якщо ви BA і хочете бути релевантними в SDD-світі, ось конкретний список:

Освоїти Given-When-Then на рівні рефлексу. Специфікації мають мати чітку структуру зі спільним стилем визначення сценаріїв через Given/When/Then — це напряму впливає на якість згенерованого коду і допомагає скорочувати витрати токенів. Це вже не «один з форматів user story», це lingua franca SDD.

Навчитися читати ERD, state-machine та інші діаграми Не будувати з нуля — читати і валідувати те, що запропонував ШІ або архітектор. Розуміти, чи відображає схема даних реальну бізнес-логіку.

Зрозуміти Negative Scope і Constraints. Найчастіша причина провалу SDD — неповна специфікація. Нечіткі промпти призводять до нечіткого коду, що акумулює технічний борг. BA, який навчився формулювати «що система НЕ робить» так само чітко, як «що робить» — безцінний.

Попрактикувати роботу з ШІ-інструментами як «аналітиком-інтерв’юером». GitHub Spec Kit, Kiro, Claude — всі вони реалізують поетапний робочий процес: Specify → Plan → Tasks → Code. Тепер аналітикам потрібно уважно слухати не тільки замовника, але і відповідати на питання ШІ та перевіряти чи правильно він зрозумів відповідь. В SDD ви не заповнюєте шаблон, ви керуєте якістю результатів роботи ШІ і додаєте те, що ШІ не може отримати сам: контекст, підтекст, пріоритети.

SDD — це ренесанс

Назва цієї статті обіцяла дати відповідь: ренесанс чи кінець? Моя відповідь — ренесанс. Але не безумовний і не автоматичний.

Ренесанс для тих BA, хто зрозуміє просту річ: цінність ніколи не була в тому, щоб заповнювати шаблони. Цінність формується в здатності перетворювати неструктурований бізнес-хаос на структуровану, несуперечливу, повну специфікацію. Раніше ця специфікація потрапляла в стіл розробника і тлумачилася довільно. Тепер вона потрапляє в ШІ-агент і виконується буквально.

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

ШІ може писати, малювати та програмувати, але розуміти замовника та думати — ні. Думати за нього — ваша робота, і вона нікуди не зникає. SDD звільняє BA від рутини (малювання прототипів вручну ) і повертає до першочергової цінності — мислення та розуміння замовника. Це і є справжній ренесанс професії.

P.S. Перефразовуючи класика, «жити аналітикам треба інтерєсно, читати статті та дресірувать любімого ШІ-агента».