Що ви опануєте
Ви навчитеся перетворювати потребу користувача на перевірювану вимогу, описувати основний і альтернативний сценарії та узгоджувати неоднозначні правила. Приклад — бронювання консультації з обмеженою кількістю місць. Результат опрацювання: невелика специфікація, з якої інша людина зможе створити перевірки й пояснити очікувану поведінку системи.
Потреби та види вимог
Потреба описує бажаний результат людини. Функціональна вимога визначає поведінку системи: показати доступні консультації, створити запис, повідомити про відмову. Вимога до якості задає характеристику виконання: доступність, час відповіді, безпеку або зручність. Обмеження звужує допустиме рішення: певний формат даних, вимога використати наявний сервер чи підтримати конкретні пристрої.
Фраза «сайт має бути швидким» залишає відкритими питання вимірювання. Потрібно визначити дію, умови навантаження, спосіб виміру й поріг. Наприклад: «для набору до 1000 консультацій відповідь на пошук у тестовому середовищі має вкладатися у погоджений поріг у 95% запитів». Сам поріг погоджують із зацікавленими сторонами; довільне число може бути технічно досяжним і не відповідати реальній потребі.
Джерела та уточнення
Вимоги отримують через інтерв’ю, спостереження, аналіз документів і прикладів поточної роботи. Питайте про фактичні випадки: що відбулося останнього разу, які дані були відомі, як користувач зрозумів результат. Це допомагає знайти приховані правила. Наприклад, час консультації може вказуватися в локальному часовому поясі, а зберігатися як момент UTC; межу між ними потрібно явно пояснити.
Кожне твердження пов’язують із джерелом і статусом погодження. Якщо студент і викладачка по-різному розуміють можливість скасування, запишіть обидва очікування й питання для рішення. Непогоджене припущення не має мовчки перетворитися на правило. Специфікація залишається живим документом: зміни правил повинні бути помітні й мати причину.
User story та сценарій
User story — короткий опис бажаної можливості з погляду користувача: «Як студент, я хочу скасувати запис, щоб звільнити місце після зміни планів». Вона задає напрям розмови. Для реалізації додають сценарії, правила та критерії прийняття. Актор — роль зовнішнього учасника взаємодії. Актором може бути також інша система, яка надсилає повідомлення.
Основний сценарій бронювання починається з відкриття доступного часу. Студент підтверджує вибір, система перевіряє місткість, зберігає запис і показує ідентифікатор. Альтернативний сценарій описує, що робити, якщо місце зайняли перед підтвердженням. Передумова визначає стан до початку, постумова — гарантований стан після завершення. Помилка мережі має власну відповідь і спосіб повторення.
Критерії прийняття
Критерій прийняття — умова, за якою результат можна визнати відповідним вимозі. Формат Given–When–Then описує вихідний стан, дію й очікувану зміну. Для консультації місткістю два місця: дано один запис; коли інший студент підтверджує бронювання; тоді з’являється другий запис. Для вже заповненої консультації кількість записів не змінюється, а користувач отримує зрозумілу причину.
Окремо перевіряють границі. Нульова місткість, повторний запис тієї самої людини, скасована консультація й момент завершення прийому заявок повинні мати визначену поведінку. Приклади допомагають виявити суперечність ще до коду. Якщо критерій містить слова «зручно» або «коректно», потрібно пояснити, який спостережуваний результат вони означають.
Виконуване правило
def accept_booking(capacity: int, bookings: int, active: bool) -> bool:
# Від’ємні значення сигналізують про помилкові дані.
if capacity < 0 or bookings < 0:
raise ValueError("Лічильники мають бути невід’ємними")
return active and bookings < capacity
assert accept_booking(2, 1, True)
assert not accept_booking(2, 2, True)
assert not accept_booking(2, 0, False)
Параметр active описує можливість приймати записи. Оператор < зберігає інваріант місткості: заповнену консультацію не можна збільшити. ValueError відокремлює некоректні вхідні дані від нормальної відмови. Функція поки не зберігає запис; вимога атомарності перевірки та додавання потребує окремої реалізації в сховищі.
Трасованість та зміни
Вимозі надають стабільний ідентифікатор R-BOOK-01. У таблиці зазначають джерело, сценарій, перевірки та залежності. Якщо місткість зміниться, команда знаходить функцію, тести й текст повідомлень через ці зв’язки. Ідентифікатор не замінює змісту: вимога повинна залишатися зрозумілою без усної розповіді автора.
Пріоритет визначають з огляду на цінність, ризик і залежності. Базове бронювання потрібне до нагадувань, а правила ідентифікації можуть впливати на обидва сценарії. Погоджуйте порядок явно. Додавання функції без аналізу залежностей може збільшити обсяг роботи значно більше, ніж очікують за її короткою назвою.
Типові помилки та професійні практики
Поширені помилки: кілька незалежних правил в одному реченні, приховані одиниці вимірювання, критерій без вихідних даних і повідомлення, яке не пояснює наступну дію. У вимозі «адміністратор керує розкладом і студентами» потрібно розділити різні дозволи та сценарії. Так легше аналізувати доступ і перевіряти кожну операцію.
Практична перевірка
Опишіть скасування запису: хто має право, до якого моменту, що відбувається з місцем і повідомленням. Складіть таблицю з трьома прикладами. Перевірте, чи всі потрібні дані названо, чи можна спостерігати постумову, чи відмова не змінює сховище. Після цього попросіть іншу людину пояснити правило за вашим текстом.
Приклад уточнення неоднозначної вимоги
Фраза «скасування доступне завчасно» не задає перевірного правила. Уточніть точний момент: наприклад, до початку консультації за часом сервера. Далі визначте, що відбувається на межі: якщо час запиту дорівнює часу початку, скасування відхиляється. Часова зона відображення може відрізнятися, тому правило порівнює моменти часу, а інтерфейс показує локальне значення з поясненням.
Наступне питання — повноваження. Студент скасовує власний запис, викладач може закрити всю консультацію. Це дві операції з різним масштабом і повідомленнями. Якщо їх описати одним словом «скасувати», можна помилково дозволити студенту змінювати чужі записи. Для кожного сценарію зазначайте роль, передумови, об’єкт і постумову.
Складіть таблицю перевірки: власний запис до початку — успіх; чужий запис — відмова; власний запис після початку — відмова; повторне скасування вже скасованого — визначений стабільний результат. У кожній відмові явно перевірте, що інші записи та місткість не змінюються. Це перетворює словесне правило на набір спостережуваних прикладів.
Після погодження присвойте вимозі ідентифікатор і пов’яжіть його з тестами. При зміні часового порогу знайдіть усі залежні сценарії, тексти інтерфейсу й документацію. Трасованість зменшує ризик, що нове правило буде реалізоване лише в одному місці. У власному завданні оберіть неоднозначний часовий вислів та перетворіть його на точні умови.
Схема процесу
З’ясовуємо потребу та правила.
Самоперевірка
Як обґрунтувати відповідь своїми словами?
Підсумок
Перевірювані вимоги поєднують потребу, сценарії та конкретні критерії. Граничні приклади виявляють неоднозначності. Трасованість допомагає оцінювати вплив змін на реалізацію й перевірки.