nmk

Лабораторна робота №5 (2 години)

Тема: Збір вимог та створення технічної специфікації (User Stories & Use Cases)

Практика моделювання вимог до програмного забезпечення. Написання користувацьких історій (User Stories) з критеріями приймання (Acceptance Criteria) та розробка детального сценарію використання (Use Case).

Мета: Навчитися перетворювати розмиті бізнес-побажання замовника на чіткі, структуровані вимоги, зрозумілі як розробникам, так і клієнтам, використовуючи сучасні стандарти бізнес-аналізу в IT.

Технологічний стек: Google Docs / Microsoft Word / Notion (для документування вимог).

Завдання

Ви продовжуєте роботу над своїм навчальним проєктом (з Лабораторної №1 та №3) в ролі Business Analyst (BA) / Product Owner. Вам необхідно деталізувати вимоги до ключового функціоналу вашого застосунку, щоб передати їх програмістам у роботу.

Перелік завдань:

  1. Написати 3 User Stories за класичним шаблоном.
  2. До кожної User Story додати Acceptance Criteria (Критерії приймання) у форматі BDD (Given-When-Then).
  3. Розписати 1 детальний Use Case (Сценарій використання) за табличним шаблоном.

Хід виконання роботи

Крок 1. Написання User Stories

User Story (Користувацька історія) — це коротке формулювання вимоги з точки зору кінцевого користувача.

Шаблон: Як <Роль>, я хочу <Дія/Бажання>, щоб <Користь/Ціль>.

Оберіть 3 різні функції вашого проєкту і напишіть для них User Stories. Наприклад, для інтернет-магазину:

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

Запишіть ваші 3 історії у звіт.

Крок 2. Написання Acceptance Criteria (Критерії приймання)

User Story сама по собі занадто коротка. Програміст не знає, як саме її реалізовувати. Тому до кожної з трьох історій з Кроку 1 потрібно додати Acceptance Criteria.

Ми будемо використовувати BDD (Behavior-Driven Development) формат, відомий як синтаксис Gherkin:

Приклад для історії №1 (з Кроку 1):

Критерій 1 (Успішне додавання) Given: Користувач знаходиться на сторінці товару і не увійшов в акаунт. When: Він натискає кнопку “Купити”. Then: Лічильник кошика в шапці сайту збільшується на 1, а товар зберігається в LocalStorage браузера.

Критерій 2 (Товару немає на складі) Given: Користувач знаходиться на сторінці товару, залишок якого = 0. When: Він дивиться на кнопку “Купити”. Then: Кнопка неактивна (сіра) і має текст “Немає в наявності”.

Напишіть мінімум по 1-2 таких критерії для кожної з ваших трьох User Stories.

Крок 3. Написання Use Case (Сценарій використання)

Use Case — це більш строгий і детальний документ (класичний інструмент з UML-підходів), який описує покрокову взаємодію між Системою та Актором (користувачем).

Оберіть найскладніший процес у вашому додатку (наприклад, “Оформлення замовлення” або “Реєстрація водія таксі”) і розпишіть його у вигляді наступної таблиці:

Поле Опис
Назва Use Case: “Оформлення замовлення з оплатою карткою”
Актор (Actor): Авторизований Клієнт
Передумова (Pre-condition): Клієнт має хоча б 1 товар у кошику і знаходиться на екрані “Кошик”.
Основний сценарій (Happy Path): 1. Клієнт натискає “Оформити”.
2. Система запитує адресу доставки.
3. Клієнт вводить адресу.
4. Система показує форму оплати.
5. Клієнт вводить дані картки.
6. Система списує гроші і показує екран “Успіх”.
Альтернативний сценарій (Alternative): (Крок 6) Якщо на картці недостатньо коштів:
6.1 Система показує помилку банку і просить іншу картку.
Постумова (Post-condition): Замовлення створено в базі статус “Оплачено”. Користувачу відправлено Email.

Відтворіть цей шаблон у звіті і заповніть його для вашого процесу.

Контрольні запитання

  1. Хто з команди зазвичай відповідає за збір, написання та узгодження вимог (User Stories) із замовником?
  2. Поясніть формулу INVEST для написання ідеальних User Stories. Що означають ці літери?
  3. Чому програмісту недостатньо отримати від аналітика просто одну фразу-User Story без Acceptance Criteria?
  4. У чому головна візуальна та структурна різниця між підходами User Story (Agile) та Use Case (Waterfall/UML)?
  5. Що таке Scope Creep (Розповзання меж проєкту) і як якісно написана специфікація вимог допомагає з цим боротися?

Вимоги до звіту

  1. У репозиторії на GitHub додати файл lab_05.md.
  2. В цей файл перенести результати виконання Кроків 1, 2 і 3 (Три User Stories, Критерії приймання Gherkin до кожної з них, та заповнену таблицю Use Case).
  3. У файлі lab_05.md дати письмові відповіді на всі 5 контрольних запитань.
  4. Завантажити зміни на GitHub та надіслати посилання викладачу.