Урок 2 из 8 · 20 мин · обновлено

Сбор требований: кого спрашивать и что записывать

Откуда берутся требования, как проводить интервью с заказчиком и пользователями, чем бизнес-требования отличаются от функциональных и нефункциональных и как сделать требование проверяемым.

Откуда берутся требования

Требования не придумывают в одиночку. Их собирают из разных источников:

  • заказчик — владелец кофейни, руководитель отдела: цели и ограничения;
  • пользователи — гости, бариста, менеджер: как они работают сейчас и что мешает;
  • документы — регламенты, договоры, законы. Например, правила программы лояльности;
  • текущие системы — как устроено сейчас, какие данные уже есть;
  • данные — сколько гостей, сколько заказов, какие бывают ошибки.

Интервью

Главный инструмент — интервью. Правила, похожие на интервью в UX:

  • спрашивайте о цели и проблеме, а не только о решении. Заказчик просит «кнопку экспорта в Excel» — спросите, что он потом делает с файлом. Может, ему нужен готовый отчёт;
  • просите примеры: «Расскажите, как это происходит сейчас», «Покажите последний случай»;
  • уточняйте исключения: «А если гость отменил заказ?», «А если связь пропала?»;
  • не предлагайте решение раньше времени — сначала поймите задачу.

После встречи запишите итоги — что решили, какие вопросы открыты — и отправьте участникам на подтверждение. Устные договорённости забываются, а письменные можно проверить.

Как проводить такие встречи и оформлять требования во внедрении 1С, подробно разобрано в уроке «Как выявить, записать и согласовать требования» — принципы те же.

Виды требований

Вид На какой вопрос отвечает Пример для «Зерна»
Бизнес-требования зачем Увеличить долю повторных заказов с 30% до 40% за полгода
Пользовательские что нужно пользователю Гость хочет видеть, сколько у него баллов и на что их хватит
Функциональные что делает система Система начисляет 5% от суммы заказа баллами после успешной оплаты
Нефункциональные какой должна быть система Баланс загружается не дольше 2 секунд; данные о гостях хранятся в России

Нефункциональные требования часто забывают: скорость, надёжность, безопасность, нагрузка, доступность, законы. А потом система работает, но медленно падает в час пик.

Хорошее требование

Хорошее требование:

  • однозначное — его нельзя понять двумя способами;
  • проверяемое — тестировщик может проверить, выполнено ли оно;
  • выполнимое — технически и по срокам;
  • нужное — за ним стоит реальная потребность;
  • атомарное — одно требование описывает одну вещь.

Сравните: «Система должна работать быстро» и «Баланс баллов загружается не дольше 2 секунд при 1000 одновременных пользователей». Первое — пожелание, второе — требование.

Попробуйте сами. Перепишите расплывчатые требования так, чтобы они стали проверяемыми: 1) «Баллы должны начисляться быстро»; 2) «Приложение должно быть безопасным»; 3) «Гостю должно быть удобно списывать баллы».

Пример
  1. «Баллы начисляются на баланс гостя не позднее 5 минут после успешной оплаты заказа».
  2. «Вход в приложение — по номеру телефона и одноразовому коду из СМС. После 5 неверных кодов вход блокируется на 15 минут».
  3. «На экране оплаты гость видит доступные баллы и может одним нажатием списать их, но не больше 50% суммы заказа. Итоговая сумма пересчитывается сразу».

Третье требование стоит ещё обсудить с UX-дизайнером: «удобно» — это про интерфейс, а аналитик фиксирует правила.

Мини-тест: проверьте себя

Закрепите урок: несколько вопросов, разбор ответов — в конце.

  1. Какое требование нефункциональное?

  2. Заказчик просит: «Сделайте кнопку экспорта в Excel». Что аналитику важно выяснить?

  3. Какое требование сформулировано лучше?