Як бізнес-аналітику використовувати ШІ для створення вимог, user stories та use cases

Штучний інтелект поступово стає звичним робочим інструментом для бізнес-аналітиків. Він не замінює BA у спілкуванні з клієнтом, розумінні бізнесу чи прийнятті рішень. Проте ШІ може суттєво пришвидшити рутинну частину роботи: структурувати нотатки після зустрічі, виявити прогалини у вимогах, підготувати чернетки user stories, use cases або матриці пріоритетів.

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

У цій статті розглянемо чотири артефакти бізнес-аналітика, які можна створювати за допомогою ШІ: визначення вимог, пріоритизація вимог, user stories з acceptance criteria та use cases.

‍

1. Визначення та структурування вимог за допомогою ШІ

Вимоги — це опис того, що потрібно бізнесу, користувачу або системі. Вони можуть бути бізнесовими, функціональними та нефункціональними.

Наприклад, клієнт каже: «Нам потрібно, щоб користувачі швидше оформлювали заявки на кредит». Це ще не готова вимога. Бізнес-аналітик має з’ясувати, що саме означає «швидше». Скоротити кількість полів? Додати автозаповнення? Прибрати зайві кроки? Покращити швидкість завантаження сторінки?

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

Наприклад, після дзвінка у вас залишилися такі нотатки:

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

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

Приклад промпту:

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

[Вставити очищені нотатки]

ШІ може видати, наприклад, функціональну вимогу: «Система повинна відображати менеджеру причину відмови у заявці». Але BA має перевірити, хто саме бачить цю причину? Чи має користувач бачити її теж? Звідки система отримує причину? Чи є перелік допустимих статусів?

Тобто ШІ допомагає сформувати першу структуру, а аналітик відповідає за точність, повноту й погодження змісту.

• Вимоги (requirements) — опис того, що має вирішувати продукт або система.
• Бізнес-вимоги — потреби компанії чи клієнта: яку проблему потрібно вирішити й який результат отримати.
• Функціональні вимоги — опис того, що саме повинна робити система.
• Нефункціональні вимоги — вимоги до якості роботи системи: швидкості, безпеки, доступності, надійності тощо.
• Стейкхолдери — люди або групи, яких стосується проєкт: клієнт, користувачі, менеджери, команда.

‍

2. Пріоритизація вимог: як ШІ допомагає обрати головне

Тепер коли ми за допомогою ШІ зібрали чернетку вимог, самостійно, або за допомогою ШІ довели чернетку до чистовика вимог, то тепер треба зробити пріоритезацію вимог.

У реальному проєкті майже ніколи не можна реалізувати все одразу. Бізнес може хотіти новий дизайн, інтеграцію з CRM, систему сповіщень, аналітику, мобільну версію та десятки інших функцій. Завдання BA — допомогти зрозуміти, що потрібно для першого випуску продукту, а що можна перенести на наступні етапи.

Один із найпоширеніших підходів пріоритезації:

• Must have — без цього продукт або ітерація продукту не має сенсу;
• Should have — важливо, але можна тимчасово обійтися без функції;
• Could have — бажане покращення, якщо є час і ресурси;
• Won’t have — не робимо в межах поточного випуску продукту.

Скоріше за все в чистовику у вас буде дуже велика кількість вимог, розбитих на багато різних секцій або сторінок. Пріоритезувати це все самостійно — доволі кропітка задача.

ШІ може допомогти створити стартову матрицю пріоритетів. Наприклад, якщо команда працює над сервісом онлайн-заявок, вона може мати такі вимоги: форма заявки, перевірка номера телефону, збереження чернетки, темна тема інтерфейсу, інтеграції з CRM, email-сповіщення.

Приклад промпту:

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

Вимоги: [вставити список]

Важливо не дозволяти ШІ самостійно «вирішувати», що цінне для бізнесу. Він не знає стратегії компанії, умов контракту, бюджету чи очікувань користувачів. Його відповідь варто використовувати як фундамент для теми розмови з клієнтом, Product Owner або проєктним менеджером.

Наприклад, інтеграція з CRM може здаватися функцією рівня Should have. Але якщо без неї менеджери не отримають жодної заявки, це очевидний Must have. Контекст завжди важливіший за шаблонну рекомендацію.

Терміни з цього розділу

• MVP (Minimum Viable Product) — мінімальна версія продукту з найважливішими функціями, яку вже можна запустити або перевірити на користувачах.
• Backlog — впорядкований список задач, вимог і покращень для продукту.
• CRM — система для роботи з клієнтами: зберігання контактів, заявок, історії комунікації та продажів.

‍

3. User stories та acceptance criteria: від ідеї до зрозумілої задачі

Тепер, маючи пріоритезований список вимог, можна перейти до створення user stories та acceptance criteria.

У Scrum-командах одним із головних артефактів BA є user story. Вона описує потребу користувача простими словами:

Як [тип користувача], я хочу [дію], щоб [отримати цінність].

Наприклад:

Як користувач, я хочу отримати SMS-код для підтвердження номера телефону, щоб завершити подання заявки без помилок.

Одна user story не повинна бути технічним завданням для розробника. Її мета — пояснити, для кого створюється функція, що має відбутися та навіщо це потрібно.

ШІ добре справляється з перетворенням короткого опису потреби на чернетку user story. Також він може запропонувати acceptance criteria — умови, за якими команда та бізнес перевіряють, що задача виконана правильно.

Приклад промпту:

Створи user story для функції підтвердження номера телефону через SMS. Додай acceptance criteria у форматі Given / When / Then, негативні сценарії та список уточнювальних питань до бізнесу. Контекст: користувач подає онлайн-заявку, код діє 5 хвилин, кількість повторних відправлень коду потрібно уточнити.

ШІ може запропонувати такий критерій:

Given — користувач увів коректний номер телефону;
When — він натискає «Надіслати код»;
Then — система надсилає SMS-код на вказаний номер.

Але хороший BA не зупиняється на базовому сценарії. Потрібно перевірити corner cases. Що буде, якщо код неправильний? Що робити, якщо SMS не прийшло? Скільки спроб доступно? Чи потрібно блокувати користувача після багатьох невдалих спроб? Чи має користувач можливість змінити номер?

ШІ може нагадати про такі питання, але саме аналітик повинен погодити відповіді зі стейкхолдерами та зафіксувати їх у вимогах.

Терміни з цього розділу

• User story — короткий опис потреби користувача у форматі: «Як [користувач], я хочу [дію], щоб [отримати цінність]».
• Acceptance criteria — чіткі умови, за якими можна перевірити, що задача виконана правильно.
• Given / When / Then — формат опису перевірки: за певних умов, коли відбувається дія, система має показати очікуваний результат.
• Негативний сценарій — сценарій, де користувач вводить некоректні дані або відбувається помилка.
• Corner case — нестандартний, рідкісний або граничний сценарій, який усе одно потрібно передбачити.
• Scrum — гнучкий підхід до організації роботи, у якому команда виконує задачі короткими ітераціями.
• Реліз — версія продукту або набір змін, які команда передає користувачам.

‍

4. Use cases: коли user story недостатньо

User stories добре працюють для коротких ітеративних задач. Але іноді команді потрібен детальніший опис взаємодії користувача із системою. У таких випадках BA створює use case — сценарій використання.

Use case зазвичай містить:

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

Наприклад, use case «Подання заявки на кредит» може описувати не тільки натискання кнопки «Відправити», а й весь шлях: авторизацію, заповнення анкети, підтвердження телефону, перевірку даних, отримання рішення та повідомлення користувача.

ШІ може допомогти швидко створити логічну структуру такого документа, особливо якщо BA має лише високорівневий опис процесу.

Приклад промпту:

Створи чернетку use case для сценарію «Користувач подає онлайн-заявку». Додай: актора, передумови, тригер, основний сценарій, альтернативні сценарії, помилки та результат. Не вигадуй інтеграції або бізнес-правила; познач невідомі деталі як [потребує уточнення].

Контекст: [вставити опис]

Позначка «потребує уточнення» дуже важлива. Вона робить документ чесним: замість вигаданих правил BA отримує список прогалин, які треба обговорити з бізнесом або технічною командою.

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

Терміни з цього розділу

• Use case — детальний сценарій взаємодії користувача або іншого учасника із системою.
• Передумови — умови, які мають бути виконані до початку сценарію.
• Тригер — подія, яка запускає сценарій: наприклад, користувач натискає кнопку «Подати заявку».
• Основний сценарій — стандартний шлях, коли все відбувається без помилок.
• Альтернативний сценарій — інший можливий шлях виконання дії.
• QA (Quality Assurance) — спеціаліст, який перевіряє якість продукту та шукає баги.
• Прототип — спрощена візуальна модель майбутнього інтерфейсу або функції.

‍

Як перевіряти артефакти, створені ШІ

Будь-який документ, підготовлений за допомогою ШІ, потребує перевірки. Перед тим, як додавати вимоги в Jira, Confluence або інший робочий простір, BA варто поставити собі кілька запитань.

Чи відповідає документ тому, що справді сказав клієнт? Чи не додав ШІ припущення, які ніхто не погоджував? Чи зрозуміло, хто користувач і яку проблему вирішує функція? Чи можна перевірити acceptance criteria? Чи враховані помилки, обмеження та альтернативні сценарії?

Корисна практика — окремо попросити ШІ провести «рев’ю» тексту:

Перевір цю user story та acceptance criteria. Знайди неоднозначні формулювання, відсутні правила, неперевірні критерії та можливі edge cases. Не переписуй вимоги повністю — надай список конкретних зауважень.

Такий підхід перетворює ШІ з генератора тексту на інструмент, який допомагає у критичному аналізі.

Терміни з цього розділу

• Рев’ю (review) — перевірка документа, задачі або рішення перед погодженням чи передачею в роботу.
• Критичний аналіз — перевірка інформації на логічність, повноту, точність і можливі помилки.
• Jira — інструмент для ведення задач, backlog, спринтів і відстеження прогресу команди.
• Confluence — інструмент для зберігання документації, вимог, рішень і командних знань.

‍

Висновок

ШІ може значно прискорити роботу бізнес-аналітика з вимогами, пріоритизацією, user stories та use cases. Він допомагає структурувати нотатки, створювати чернетки, знаходити прогалини та готуватися до обговорень із командою.

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

‍