Специфікація вимог і приймальні приклади

Мета та вихідні знання

Створити перевірювану специфікацію невеликого сервісу й зв’язати вимоги з прикладами перевірок. Потрібно знати поняття актора, передумови, постумови й критерію прийняття. Для роботи достатньо текстового редактора та Python 3.11 або новішого. Вимоги зберігайте в Markdown, приклади — у таблиці з чіткими значеннями.

Створіть папку requirements-lab, файли requirements.md, examples.csv і demo.py. Не записуйте реальні персональні дані. У навчальному наборі використовуйте вигадані ідентифікатори. Результат має бути зрозумілим людині, яка не брала участі у ваших початкових обговореннях.

Теоретичний мінімум

Функціональна вимога описує спостережувану поведінку. Критерій прийняття визначає стан до дії та очікуваний результат. Бізнес-правило задає обмеження предметної області, наприклад максимальну кількість місць. Трасованість пов’язує правило, сценарій і перевірку. Невизначені питання фіксують окремо; припущення позначають як такі, що потребують підтвердження.

Демонстрація стосується реєстрації на семінар. Місткість задається додатним цілим числом; кількість зареєстрованих не може бути від’ємною. Вимога R-01: відкритий семінар із вільним місцем приймає нову реєстрацію. R-02: закритий або заповнений семінар відхиляє її. Для некоректних лічильників передбачена помилка даних. Ці три результати мають різний зміст.

Демонстраційна специфікація

R-01: система дозволяє реєстрацію, якщо семінар відкритий
      та registered < capacity.
Передумова: capacity > 0, registered >= 0.
Постумова рішення: результат "accepted" або "rejected".
E-01: capacity=2, registered=1, opened=true → accepted.
E-02: capacity=2, registered=2, opened=true → rejected.
E-03: capacity=2, registered=0, opened=false → rejected.

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

Повний код демонстрації

def decision(capacity: int, registered: int, opened: bool) -> str:
    if capacity <= 0 or registered < 0 or registered > capacity:
        raise ValueError("Некоректні лічильники")
    # Логічне правило прямо відповідає вимозі R-01.
    return "accepted" if opened and registered < capacity else "rejected"

examples = [
    ("E-01", 2, 1, True, "accepted"),
    ("E-02", 2, 2, True, "rejected"),
    ("E-03", 2, 0, False, "rejected"),
]
for identifier, capacity, registered, opened, expected in examples:
    actual = decision(capacity, registered, opened)
    assert actual == expected, (identifier, actual, expected)
    print(identifier, actual)

Розпакування кортежу пов’язує поля прикладу з параметрами. Рядок assert показує ідентифікатор при розбіжності. Очікуваний результат задається із вимоги вручну. Не обчислюйте його тією самою формулою, що використовується в реалізації: спільна помилка зробить таку перевірку неінформативною. Очікуваний вивід містить три рядки: accepted, rejected, rejected із відповідними ID.

Покрокове виконання

Складіть перелік акторів і по одній потребі кожного. Опишіть основний сценарій реєстрації й альтернативу заповненого семінару. Виділіть правила, які впливають на результат. Дайте їм стабільні ID. Для кожного створіть звичайний і граничний приклади, а для входів — приклад порушення передумови.

Виконайте демонстрацію, потім навмисно змініть < на <=. Запишіть, який приклад виявив помилку й чому. Поверніть правильну умову. Такий експеримент перевіряє здатність набору тестів захищати границю. Передайте специфікацію іншій людині або перечитайте її без звернення до коду й перевірте, чи результат кожного прикладу зрозумілий.

Самостійне завдання

Оберіть систему видачі обладнання, реєстрації на подію або бібліотечного замовлення. Сформулюйте щонайменше п’ять функціональних вимог, дві вимоги до якості й два обмеження. Для одного важливого правила створіть таблицю з шістьма приймальними прикладами та самостійний перевіряльник. Не копіюйте правило місткості без адаптації до предметної області.

Задайте одну реальну зміну: обмеження строку, новий статус або особливу роль. Покажіть, які вимоги й приклади зміняться. Додайте список невизначених питань із джерелом відповіді. Якість роботи визначається узгодженістю й перевірюваністю; кількість тексту сама по собі не усуває неоднозначності.

Типові помилки й налагодження

Слова «швидко», «зручно», «правильно» потребують операційного визначення. Вимога з кількома незалежними діями ускладнює трасованість. Приклад без початкового стану не дозволяє відтворити результат. Якщо код і специфікація суперечать одне одному, спочатку з’ясуйте погоджене правило; автоматична зміна очікування під код приховує дефект.

Результат роботи

Подайте специфікацію, таблицю трасованості «потреба → вимога → приклад», код перевірки та короткий аналіз зміни. Поясніть, чим відрізняються нормальна відмова й некоректний вхід. Який приклад виявляє порушення на границі? Яке питання залишилося непогодженим? Як інша людина відтворить вашу перевірку?

Як перевірити власну специфікацію

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

Окремо пройдіть правила доступу. Дві ролі можуть бачити один об’єкт, але мати різні дозволені дії. У таблиці позначте операцію, роль, умову та результат. Для відмови перевіряйте незмінність інших даних. Це особливо важливо, коли помилка виявляється після частини підготовчих дій.

Перевірте узгодженість чисел і термінів між розділами. Якщо місткість семінару визначається як число підтверджених записів, не рахуйте чернетки як зайняті місця в іншому сценарії. Створіть словник станів і використовуйте однакові назви. Відмінність pending та confirmed повинна мати явний вплив на правила.

У результаті додайте таблицю трасування: ідентифікатор вимоги, сценарій, очікуваний результат, спосіб перевірки. Попросіть іншого читача відтворити один сценарій лише за вашим текстом. Запишіть питання, які виникли, та уточнення після перевірки. Цей короткий експеримент виявляє приховані припущення, які автор часто сприймає як очевидні. Власні уточнення повинні бути погодженими предметними рішеннями.

Схема процесу

Самоперевірка

Підсумок

Специфікація стає корисною, коли її правила можна відтворити на конкретних прикладах. Трасованість дозволяє пояснити зміни. Некоректні дані, нормальна відмова та успіх потребують окремих контрактів.

Джерела

• Python tutorial
• unittest