Вимоги користувача (варіанти використання, історії користувачів)

📌 Про що ця тема

Тут перевіряють, як розробник фіксує те, чого хоче замовник чи кінцевий користувач від майбутньої системи. Ключові поняття — вимоги користувача, варіанти використання (use cases) та історії користувачів (user stories). Це фундамент: якщо вимоги зібрані погано, програму зроблять «не ту».

📖 Головне

• Вимоги — це опис того, що система має робити (функціональні) і яким обмеженням відповідати (нефункціональні: швидкодія, безпека, зручність). На цьому етапі ще не кажуть, ЯК це реалізувати технічно, а лише ЩО потрібно.

• Вимоги користувача (user requirements) описують систему з точки зору людини, якій вона потрібна, звичайною мовою, зрозумілою замовнику.

• Актор (дійова особа) — будь-хто чи будь-що, що взаємодіє із системою ззовні: користувач, адміністратор, інша програма.

• Варіант використання (use case) — опис послідовності дій, які актор виконує із системою для досягнення конкретної мети. Наприклад, «Оформити замовлення».

• Use case має: назву, актора, основний сценарій (кроки) та альтернативні сценарії (що робити при помилці чи відхиленні).

• Діаграма варіантів використання (UML Use Case Diagram) зображує акторів (чоловічки) та варіанти використання (овали), сполучені лініями; система — прямокутник-межа.

• Історія користувача (user story) — короткий опис потреби за шаблоном: «Як РОЛЬ, я хочу ДІЮ, щоб ВИГОДА/МЕТА». Застосовується у гнучких (Agile) методологіях.

• Критерії приймання (acceptance criteria) — умови, за якими перевіряють, що історія виконана.

• Відмінність: use case детально розписує сценарій крок за кроком; user story — коротка, акцент на цінності для користувача, деталі уточнюють під час роботи.

🔢 Як це працює на прикладі

Завдання: онлайн-бібліотека, дія «пошук книги».

User story: «Як читач, я хочу шукати книгу за назвою, щоб швидко знайти потрібне видання».

Критерій приймання: якщо введено частину назви — показуються всі збіги; якщо збігів немає — повідомлення «Нічого не знайдено».

Той самий випадок як use case:

• Назва: Пошук книги.

• Актор: Читач.

• Основний сценарій: 1) читач відкриває пошук; 2) вводить назву; 3) система шукає в базі; 4) показує список.

• Альтернативний: якщо книг немає — система повідомляє про відсутність результатів.

На діаграмі: чоловічок «Читач» сполучений лінією з овалом «Пошук книги» всередині прямокутника «Система бібліотеки».

⚠️ Типові помилки

• Плутають функціональні й нефункціональні вимоги: «показувати список книг» — функціональна, «відповідати за 2 секунди» — нефункціональна.

• Вважають актором лише людину; актором може бути інша система чи сервіс.

• У user story пишуть технічне рішення замість потреби («хочу базу MySQL») — має бути роль + мета + вигода.

• Плутають use case і user story: use case — детальні кроки, user story — коротка фраза.

• Забувають про альтернативні сценарії (помилки, порожні результати).

🎯 Що завчити напамʼять

• Шаблон історії: «Як РОЛЬ, я хочу ДІЮ, щоб ВИГОДА».

• Склад use case: назва, актор, основний і альтернативний сценарії.

• На UML-діаграмі: актор — чоловічок, варіант використання — овал, межа системи — прямокутник.

• Функціональні = що робить; нефункціональні = якість/обмеження.

🧠 Перевір себе

1. Чим use case відрізняється від user story?

2. До яких вимог належить «пароль має містити ≥8 символів»?

3. Що означає актор у діаграмі варіантів використання?

4. Запиши історію користувача для входу в систему.

Відповіді: 1 — use case детально описує сценарій кроками, user story — коротка фраза про потребу й вигоду; 2 — нефункціональна (вимога безпеки); 3 — зовнішня сутність (людина чи система), що взаємодіє із системою; 4 — «Як користувач, я хочу увійти за логіном і паролем, щоб отримати доступ до свого акаунта».