Формулирование User Stories и Use Cases
5.1. Формат User Story (Пользовательская история)
Чтобы ИИ понимал, как компоненты системы взаимодействуют между собой, требования описываются через сценарии.
Шаблон формулировки: «Как [Пользователь], я хочу [Действие], чтобы [Цель]». Примеры: • «Как фрилансер, я хочу нажать кнопку Старт, чтобы начался отсчет времени по текущему проекту». • «Как клиент, я хочу получить ссылку на чек, чтобы проверить итоговую сумму услуги».
5.2. Формат Use Case и позитивные/негативные сценарии (Edge Cases)
Ошибка новичка (НЕПРАВИЛЬНО): Описывать в ТЗ только «счастливый путь» (Happy Path): «Пользователь вводит логин, пароль и входит в систему». Почему так делать нельзя: ИИ не напишет логику валидации и обработки ошибок по своей инициативе. В итоге, если пользователь введет незарегистрированный Email или отправит пустую форму, приложение зависнет, выдаст белую страницу или сбой сервера без объяснения причин.
Как нужно делать правильно:
Для каждого Use Case обязать ИИ обрабатывать не только Happy Path, но и нетипичные ситуации (Edge Cases).
Структура корректного описания Use Case для ТЗ:
Название: Авторизация по Email 1. Основной сценарий (Happy Path): - Пользователь вводит валидный Email и пароль. - Нажимает кнопку «Войти». - Система проверяет данные и перенаправляет в личный кабинет. 2. Краевые случаи и ошибки (Edge Cases): - Пользователь ввел незарегистрированный Email -> Показать сообщение под полом: «Пользователь с таким Email не найден». - Пользователь ввел неверный пароль -> Показать сообщение: «Неверный пароль». - Поле Email пустое -> Кнопка «Войти» неактивна (Disabled).