Приведи пример пользовательского требования

Пример пользовательского требования (User Requirement)

Пользовательское требование — это формулировка того, что пользователю нужно, написанная на его языке, а не техническом.

Правильное пользовательское требование

UR-001: Быстрый поиск по каталогу товаров

Тип: Функциональное требование
Актор: Покупатель
Приоритет: HIGH
Дата: 2026-03-29

Описание:
Как покупатель, мне нужно быстро найти товары, которые я ищу,
чтобы я мог сэкономить время при покупке и не ушёл к конкурентам.

Причина (Бизнес-ценность):
- 60% покупателей пользуются поиском
- Если поиск медленный (> 1 сек), 40% уходят на конкурентов
- Быстрый поиск → +25% конверсия

Критерии приёма (Acceptance Criteria):
1. ✓ Результаты показываются менее чем за 500 мс
2. ✓ Можно искать по названию товара и описанию
3. ✓ Поиск должен быть нечувствителен к регистру (iPhone = iphone)
4. ✓ Результаты сортируются по релевантности (самые похожие в начале)
5. ✓ Показывается макс 50 результатов на странице
6. ✓ Работает на мобильных устройствах (touch interface)
7. ✓ Если нет результатов, показать сообщение "Не найдено"
8. ✓ История поисков сохраняется для повторного использования

Примеры использования:
- Покупатель вводит "iphone 15" → видит 3 варианта за 300 мс
- Вводит "ноутбук gaming" → видит 120 результатов (50 на странице)
- Вводит "ЗЕЛЁНЫЙ ЧЕХОЛ" → находит товары как с "зелёный", так и с "Green"

Ограничения:
- Поиск работает только для товаров в наличии (статус != archived)
- Не ищет по серийным номерам товаров

Логирование:
- Логировать все поисковые запросы для анализа популярности
- Сохранять время отклика для мониторинга

Отличие правильного требования

НЕПРАВИЛЬНО (техническое требование):

"Реализовать полнотекстовый поиск с использованием Elasticsearch
 на базе инвертированного индекса с поддержкой морфологического анализа"

Это техническое требование, а не пользовательское. Пользователь не знает что такое Elasticsearch и не хочет это знать.

ПРАВИЛЬНО (пользовательское требование):

"Я хочу найти товар по названию, и результаты должны появиться
почти мгновенно, даже если товаров много в системе"

Это пользовательское требование — описано в терминах пользователя.

Пример 2: Система управления проектами

UR-002: Просмотр истории изменений задачи

Тип: Функциональное требование
Актор: Менеджер проекта
Приоритет: MEDIUM

Описание:
Как менеджер проекта, мне нужно видеть полную историю изменений
каждой задачи (кто, когда, что изменил), чтобы я мог отследить
развитие проекта и понять, почему задача была переопределена.

Бизнес-ценность:
- Нужна прозрачность в работе команды
- Возможность найти кто ошибся при неправильном определении
- Соответствие требованиям аудита (ISO, SOX)

Критерии приёма:
1. ✓ История отображает все изменения (статус, приоритет, дата, описание)
2. ✓ Каждое изменение показывает: ДО и ПОСЛЕ значение
3. ✓ Показывается ФИО пользователя, который сделал изменение
4. ✓ Время изменения в формате "2 часа назад" или "29 Mar 2026, 14:30"
5. ✓ История отсортирована от новых к старым
6. ✓ Можно фильтровать по типу изменения (статус, дата, ответственный)
7. ✓ Можно экспортировать историю в PDF/Excel
8. ✓ История хранится минимум 1 год

Примеры:
Задача "Разработать API":
  29 Mar 14:30 - Иван Сидоров изменил статус: "Draft" → "In Progress"
  29 Mar 14:20 - Мария Петрова изменила приоритет: "Medium" → "High"
  28 Mar 10:00 - Сергей Волков создал задачу

Ограничения:
- История не может быть удалена (неизменяемый лог)
- Удаленные задачи — история всё равно доступна в архиве

Пример 3: Мобильное приложение

UR-003: Уведомления о статусе доставки

Тип: Функциональное требование
Актор: Покупатель (пользователь мобильного приложения)
Приоритет: HIGH
Варинты: iOS + Android

Описание:
Как покупатель, я хочу получать уведомления (push-notifications)
о каждом этапе доставки моего заказа, чтобы я знал, когда ожидать
посылку и мог быть готов (дома, или организовать получение).

Бизнес-ценность:
- Уменьшает возврат товаров из-за недоставки
- Снижает количество звонков в поддержку на 30%
- Улучшает NPS оценку (Net Promoter Score)

Критерии приёма:
1. ✓ Отправляется уведомление на этапах:
   - Заказ подтвержден
   - Товар на складе и готов к отправке
   - Товар передан курьеру
   - Товар в пути (каждые 24 часа статус обновления)
   - Товар доставлен
2. ✓ Уведомление содержит: номер заказа, статус, дату/время
3. ✓ Пользователь может отключить уведомления (опционально)
4. ✓ Уведомления отправляются в течение 5 минут после изменения статуса
5. ✓ Работает на слабом интернете (если notification не прошла, повтор через 10 мин)
6. ✓ В уведомлении есть кнопка "Отследить доставку" → открывает трек на карте
7. ✓ Для недоставленных заказов → уведомление + рекомендация связаться с поддержкой

Примеры:
"Ваш заказ #12345 готов к отправке. Курьер заберёт его сегодня."
"Ваш заказ #12345 в пути. Ожидаемое прибытие: завтра, 14:00-18:00"
"Ваш заказ #12345 доставлен! Спасибо за покупку. Оставить отзыв?"

Ограничения:
- Не отправляются уведомления пока пользователь читает приложение
- Макс одно уведомление в минуту (не спамить)
- История уведомлений хранится 30 дней

Структура правильного пользовательского требования

1. ID и название (UR-XXX: Краткое описание)
2. Тип (Функциональное / Нефункциональное)
3. Актор (кто это требует: пользователь, админ, система)
4. Приоритет (MUST / SHOULD / COULD / WONT)
5. Бизнес-ценность (почему это нужно)
6. Критерии приёма (как проверить, что готово)
7. Примеры использования (конкретные сценарии)
8. Ограничения (что НЕ нужно делать)
9. Метрики успеха (как измерить успех)

Как НЕ писать требования

❌ Плохо:

"Нам нужна быстрая система"
"Сделать удобный интерфейс"
"Реализовать микросервисную архитектуру"
"Использовать React и Node.js"

Эти требования нечёткие, технические, не измеримые.

✅ Хорошо:

"Пользователь должен найти товар менее чем за 500 мс"
"Интерфейс использует 3 клика максимум для выполнения основной задачи"
"Система масштабируется до 10,000 пользователей одновременно"
"Использовать инструменты, которые знает текущая команда (Node.js)"

Ключевые характеристики хорошего требования (SMART)

• Specific (Конкретное) — не размыто
• Measurable (Измеримое) — можно проверить
• Achievable (Достижимое) — реально выполнить
• Relevant (Релевантное) — связано с бизнес-целями
• Time-bound (Ограничено временем) — есть дата/сроки

Вывод

Пользовательское требование — это мост между бизнесом (что нужно) и разработкой (как это реализовать). Хорошее требование:

• Пишется на понятном языке
• Имеет ясные критерии приёма
• Содержит примеры использования
• Связано с бизнес-ценностью
• Измеримо и проверяемо