Від потреби до технічного завдання. User Stories та Use Cases
Тема 3: Бізнес-аналіз та вимоги до ІТ-продуктів · Заняття 4
1. Шлях від бізнес-потреби до формалізованої вимоги: принципи та типові помилки
1.1. Рівні вимог
Вимоги існують на кількох рівнях, що утворюють ланцюг від «навіщо» до «що конкретно»:
| Рівень | Відповідає на питання |
|---|---|
| Бізнес-потреба | Навіщо (яку проблему/ціль вирішуємо). |
| Стейкхолдер-вимога | Що потрібно користувачам. |
| Функціональна вимога | Що має робити рішення. |
| Нефункціональна вимога | Якими властивостями (безпека, швидкодія). |
1.2. Принципи формалізації
- простежувати кожну вимогу до потреби (навіщо вона);
- формулювати однозначно й перевірювано (з приймальним критерієм);
- відокремлювати «що» (вимога) від «як» (реалізація);
- пріоритезувати (MoSCoW).
1.3. Типові помилки при формалізації
Типові помилки:
- вимога-рішення («зробити кнопку») замість потреби («швидко формувати звіт»);
- неоднозначні формулювання («система має бути зручною»);
- вимога без приймального критерію (неможливо перевірити);
- втрата зв’язку вимоги з потребою.
Проміжний висновок: якісна вимога простежувана до потреби, однозначна, перевірювана й відокремлює «що» від «як».
2. User Story: формат, критерії прийняття, управління Backlog
2.1. Формат User Story
User Story (історія користувача) — коротке формулювання вимоги з погляду користувача за шаблоном: «Як <роль>, я хочу <дію>, щоб <ціль/цінність>». Це фокусує на потребі й цінності, а не на технічній реалізації.
Приклад. «Як відповідальний за облік, я хочу автоматично звіряти дані з фактом, щоб скоротити час інвентаризації».
2.2. Критерії якості (INVEST)
Хороша User Story відповідає критеріям INVEST: незалежна, обговорювана, цінна, оцінювана, мала, тестована.
2.3. Критерії прийняття (acceptance criteria)
Кожна історія супроводжується приймальними критеріями — умовами, за яких вона вважається виконаною. Поширений формат — «Given/When/Then» (за наявності умови, коли дія — тоді результат).
Приклад. Given є розбіжність обліку й факту, When користувач формує акт, Then система автоматично включає всі розбіжності.
2.4. Управління беклогом
Product Backlog — упорядкований за пріоритетом перелік історій. Верх беклогу — найпріоритетніші й найдетальніше опрацьовані історії; низ — крупніші й менш деталізовані. Беклог регулярно уточнюють (grooming).
2.5. Епіки, історії, задачі
Вимоги організують ієрархічно: епік (велика функціональна область) → історії (окремі потреби користувача) → задачі (технічні кроки реалізації). Епік розбивають на історії, що вміщуються в ітерацію. Це дозволяє планувати від великого до дрібного, не втрачаючи цілісності.
Приклад. Епік «Електронний облік майна» → історії «авто-звіряння», «формування акта», «розмежування доступу» → задачі розробки під кожну.
Типові помилки:
- User Story як технічне завдання без ролі й цінності;
- історія без приймальних критеріїв;
- надто велика історія (не вміщується в ітерацію).
Проміжний висновок: User Story фокусує на потребі й цінності; її якість забезпечують INVEST і приймальні критерії.
3. Use Cases: структура, основний та альтернативні сценарії
3.1. Призначення
Use Case (варіант використання) детально описує, як актор досягає мети за допомогою системи, крок за кроком. Якщо User Story — коротка «що і навіщо», то Use Case — розгорнутий сценарій «як саме».
3.2. Структура Use Case
| Елемент | Зміст |
|---|---|
| Назва / мета | Що робить актор. |
| Актор | Роль, що ініціює. |
| Передумови | Що має бути виконано до старту. |
| Основний сценарій | Кроки успішного шляху. |
| Альтернативні сценарії | Відхилення, помилки, винятки. |
| Постумови | Стан після завершення. |
3.3. Основний та альтернативні сценарії
Основний сценарій — послідовність кроків за «щасливого шляху». Альтернативні — що відбувається за відхилень (помилка введення, недоступність системи, розбіжність даних). Повнота альтернативних сценаріїв визначає надійність майбутнього рішення.
Приклад. Use Case «Провести інвентаризацію»: основний — звірка без розбіжностей; альтернативний 1 — виявлено розбіжність (скласти акт); альтернативний 2 — система недоступна (ручний режим).
Типові помилки:
- лише основний сценарій без альтернативних;
- змішування Use Case з технічною реалізацією;
- надмірна деталізація тривіальних кроків.
Проміжний висновок: Use Case розгортає сценарій досягнення мети; його цінність — у повноті альтернативних сценаріїв.
4. Структура технічного завдання (ТЗ) на розробку/впровадження ІКС у ЗСУ
4.1. Призначення ТЗ
Технічне завдання — основний документ, що формалізує всі вимоги до ІКС і є основою для розробки, закупівлі та приймання. ТЗ має бути повним і однозначним: усе, що не зафіксовано, може бути реалізовано не так.
4.2. Орієнтовна структура ТЗ
- Загальні відомості: призначення, підстава, замовник.
- Мета й призначення системи.
- Функціональні вимоги (що система робить).
- Нефункціональні вимоги: захист інформації, продуктивність, доступність, сумісність.
- Вимоги до даних та інтеграції.
- Вимоги до документації й навчання.
- Приймальні критерії та порядок випробувань.
- Етапи й строки; вимоги до прав на код/супроводу.
4.3. Особливості для ЗСУ
У ТЗ на ІКС ЗСУ обов’язково закладають вимоги захисту інформації (класифікація, розмежування доступу), сумісності з наявними системами, права на код/документацію та умови супроводу. Пропуск цих вимог призводить до непогодження або залежності від підрядника.
Типові помилки:
- ТЗ лише з функціональними вимогами без ЗІ й нефункціональних;
- нечіткі приймальні критерії;
- відсутність вимог прав на код і супроводу.
Проміжний висновок: ТЗ формалізує всі вимоги; його повнота (особливо ЗІ, приймальні критерії, права на код) визначає результат.
5. Traceability вимог: забезпечення простежуваності від бізнес-потреби до рішення
5.1. Поняття
Трасовуваність (traceability) — можливість простежити кожну вимогу від бізнес-потреби через стейкхолдер-вимогу, функціональну вимогу, елемент ТЗ до реалізації та тесту приймання. Це гарантує, що жодна потреба не загубилася і жодна «зайва» вимога не з’явилася без підстави.
5.2. Матриця трасовуваності
Матриця трасовуваності (RTM) пов’язує рівні вимог: потреба → вимога → елемент ТЗ → приймальний тест. Вона дозволяє оцінити повноту (усі потреби покриті) і обґрунтованість (кожна вимога має джерело).
Типові помилки:
- вимоги без зв’язку з потребою (звідки взялися?);
- потреби, не покриті жодною вимогою;
- відсутність зв’язку вимоги з приймальним тестом.
Проміжний висновок: трасовуваність гарантує повноту й обґрунтованість вимог — жодна потреба не загублена, жодна вимога не «зайва».
6. Impact assessment зміни вимог: вплив на строки, бюджет, ресурси та реліз
6.1. Поняття
Impact assessment (оцінка впливу) — аналіз наслідків зміни вимоги перед її ухваленням. Зміна однієї вимоги може потягнути за собою зміни в інших вимогах, ТЗ, строках, бюджеті й релізі.
6.2. Що оцінювати
- пов’язані вимоги (через матрицю трасовуваності);
- вплив на строки й критичний шлях;
- вплив на бюджет і ресурси;
- вплив на реліз і нормативні віхи;
- нові ризики.
6.3. Зв’язок зі зміною обсягу
Impact assessment — частина процесу change request (Тема 2): жодну зміну вимоги не ухвалюють без оцінки впливу. Матриця трасовуваності робить оцінку швидкою — видно, що «зачепить» зміна.
Приклад. Зміна вимоги «додати роль аудитора» впливає на модель доступу (ЗІ), функції, ТЗ і тести — оцінка показує +2 тижні й потребу повторного погодження ЗІ.
Типові помилки:
- ухвалення зміни вимоги без оцінки впливу;
- ігнорування пов’язаних вимог;
- недооцінка впливу на нормативні погодження.
Проміжний висновок: жодну зміну вимоги не ухвалюють без impact assessment; трасовуваність робить оцінку швидкою й повною.
7. Практична вправа: написання User Stories, Use Cases та матриця трасовуваності
Мета вправи: на основі TO-BE-процесу (Заняття 3) слухачі формулюють User Stories з приймальними критеріями, розписують один Use Case і будують фрагмент матриці трасовуваності.
Вихідні дані: результати AS-IS/TO-BE аналізу; шаблони (Додатки 1–4).
Форма роботи: у парах, з презентацією 2–3 робіт.
Порядок виконання
- Сформулювати 4–5 User Stories за шаблоном із приймальними критеріями — 15 хв.
- Розписати один Use Case (основний + 1–2 альтернативні сценарії) — 15 хв.
- Побудувати фрагмент матриці трасовуваності (потреба → вимога → ТЗ → тест) — 5 хв.
- Презентація 2–3 робіт із розбором — 5 хв.
Еталонне проходження (зразок для викладача)
User Story. «Як відповідальний за облік, я хочу автоматично звіряти дані, щоб скоротити інвентаризацію». Критерій: Given розбіжність, When формую акт, Then система включає всі розбіжності.
Use Case. «Провести інвентаризацію»: основний — звірка без розбіжностей; альтернативні — розбіжність (акт), система недоступна (ручний режим).
Трасовуваність. Потреба «швидка інвентаризація» → вимога «авто-звіряння» → пункт ТЗ 3.2 → тест «час ≤ 1 дня».
Методичні вказівки викладачу
Викладач перевіряє: (1) User Story має роль, дію, цінність і приймальний критерій; (2) Use Case має альтернативні сценарії; (3) кожна вимога простежується до потреби. Для розбору обирає одну повну й одну неповну роботу.
Контрольні питання
- Назвіть рівні вимог і поясніть перехід від потреби до вимоги.
- Який формат User Story? Що таке критерії прийняття (Given/When/Then)?
- Опишіть структуру Use Case. Навіщо потрібні альтернативні сценарії?
- Яка структура ТЗ на ІКС у ЗСУ і які вимоги обов’язкові?
- Що таке трасовуваність вимог і навіщо матриця RTM?
- Що таке impact assessment і як він пов’язаний зі зміною обсягу?
Завдання на самостійну підготовку
Тема: Метод збалансованих показників у бізнес-аналізі.
- Опрацювати Balanced Scorecard (BSC) як інструмент комплексної оцінки діяльності підрозділу ЦТ.
- Розробити систему показників для підрозділу за чотирма перспективами (фінансова, клієнтська, процесна, навчальна).
- Скласти User Stories та ТЗ-фрагмент для реального рішення свого підрозділу.
Додаток 1. Шаблон User Story
| Поле | Зміст |
|---|---|
| Як <роль> | |
| Я хочу <дію> | |
| Щоб <ціль/цінність> | |
| Критерії прийняття (Given/When/Then) | |
| Пріоритет (MoSCoW) |
Додаток 2. Шаблон Use Case
| Елемент | Зміст |
|---|---|
| Назва / мета | |
| Актор | |
| Передумови | |
| Основний сценарій (кроки) | |
| Альтернативні сценарії | |
| Постумови |
Додаток 3. Структура технічного завдання (ТЗ)
| № | Розділ |
|---|---|
| 1 | Загальні відомості (призначення, підстава, замовник) |
| 2 | Мета й призначення системи |
| 3 | Функціональні вимоги |
| 4 | Нефункціональні вимоги (ЗІ, продуктивність, доступність, сумісність) |
| 5 | Вимоги до даних та інтеграції |
| 6 | Вимоги до документації й навчання |
| 7 | Приймальні критерії та порядок випробувань |
| 8 | Етапи, строки, права на код і супровід |
Додаток 4. Матриця трасовуваності (RTM)
| Бізнес-потреба | Вимога | Пункт ТЗ | Приймальний тест |
|---|---|---|---|
Додаток 5. Критерії оцінювання роботи
| Критерій | Бали | Орієнтир |
|---|---|---|
| User Stories: роль, дія, цінність, критерії | 0–3 | Формат і INVEST дотримані. |
| Use Case: основний + альтернативні сценарії | 0–3 | Повнота сценаріїв. |
| Трасовуваність (потреба → тест) | 0–2 | Кожна вимога простежується. |
| Однозначність і перевірюваність вимог | 0–2 | Є приймальні критерії. |
| Разом | 0–10 | 9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно». |
Додаток 6. Глосарій ключових термінів
- User Story — вимога у форматі «Як роль, хочу дію, щоб ціль».
- INVEST — критерії якості історії: незалежна, обговорювана, цінна, оцінювана, мала, тестована.
- Критерії прийняття — умови виконаності (Given/When/Then).
- Backlog — упорядкований за пріоритетом перелік вимог.
- Use Case — розгорнутий сценарій досягнення мети актором.
- Альтернативний сценарій — шлях за відхилення від основного.
- ТЗ — технічне завдання — формалізовані вимоги до ІКС.
- Traceability — простежуваність вимоги від потреби до рішення.
- RTM — матриця трасовуваності вимог.
- Impact assessment — оцінка впливу зміни вимоги.
Додаток 7. Приклад розписаного Use Case (для розбору)
| Елемент | Зміст |
|---|---|
| Назва / мета | Провести інвентаризацію майна. |
| Актор | Відповідальний за облік. |
| Передумови | Настав строк; є доступ до системи. |
| Основний сценарій | 1) Сформувати опис майна; 2) Запустити авто-звіряння; 3) Переглянути результат; 4) Підтвердити дані. |
| Альтернативний 1 | Виявлено розбіжність → система формує акт → передати командиру. |
| Альтернативний 2 | Система недоступна → ручна звірка → внести дані пізніше. |
| Постумови | Облік актуалізовано; акт (за потреби) сформовано. |
Повнота альтернативних сценаріїв (розбіжність, недоступність) визначає надійність майбутнього рішення.