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

От компании к человеку

Мы уже разобрались с бизнес-требованиями. Мы знаем, что компания хочет увеличить прибыль, снизить расходы или завоевать рынок. Это стратегия.

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

Пользовательские требования – это мостик между высокими бизнес-целями и конкретными функциями системы. Они отвечают на вопросы: “КТО будет пользоваться системой?” и “ЧТО ОНИ ХОТЯТ СДЕЛАТЬ с ее помощью?”.

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

Пользовательские требования – это описание целей и задач, которые пользователи решают с помощью системы, сформулированное с точки зрения самих пользователей.

Представьте, что вы пришли в ресторан. Вы не говорите повару: “Пожарьте кусок мяса на гриле при температуре 200 градусов в течение 3 минут с каждой стороны, посолите 5 граммами соли и поперчите 2 граммами перца”. Это было бы слишком детально.

Вы говорите: “Я хочу сочный стейк с кровью”. Это и есть пользовательское требование. Вы описали свою цель (получить стейк) и критерии качества (сочный, с кровью). А уж как повар это сделает – его дело.

В разработке то же самое. Пользователь говорит: “Я хочу быстро найти нужный товар”. Аналитик записывает это как пользовательское требование. А потом вместе с командой решает, как именно это реализовать – через поиск, фильтры, каталог или все вместе.

Ключевые понятия: Акторы и цели

Чтобы правильно описывать пользовательские требования, нужно разобраться с двумя базовыми понятиями.

Акторы (Actors) – Кто будет пользоваться?

Актор – это роль, которая взаимодействует с системой. Это может быть человек или даже другая система.

Важно различать актора и конкретного человека. Один и тот же человек в разных ситуациях может выступать в разных ролях. Например, начальник отдела продаж может быть и “менеджером по продажам” (когда сам ведет сделки), и “руководителем” (когда утверждает отчеты), и “администратором” (когда настраивает права коллегам).

Примеры акторов:

• Зарегистрированный пользователь – человек, который создал аккаунт.
• Гость – человек, который зашел на сайт впервые.
• Менеджер – сотрудник компании, работающий с заказами.
• Администратор – сотрудник с расширенными правами.
• Курьер – доставщик, который отмечает статусы заказов.
• Платежная система – внешняя система, которая общается с нашей.

Цели (Goals) – Что они хотят получить?

У каждого актора есть цели, которые он хочет достичь с помощью системы. Цель должна быть ценной для пользователя и приносить ему пользу.

Примеры целей:

• “Найти товар по характеристикам”.
• “Оформить заказ за 2 минуты”.
• “Отменить доставку, если не успеваю получить”.
• “Посмотреть историю своих покупок”.
• “Выгрузить отчет для начальника”.

Способы описания пользовательских требований

Есть два основных подхода, которые нужно знать. Оба широко используются в индустрии.

Use Cases (Варианты использования)

Это классический подход из UML (Unified Modeling Language). Use Case описывает взаимодействие актора с системой как последовательность шагов.

Use Case базово состоит из:

• Название: Что делает пользователь (глагол + существительное).
• Актор: Кто это делает.
• Предусловие: Что должно быть истинно перед началом.
• Постусловие: Что изменится в системе после успешного выполнения.
• Основной сценарий: Идеальный путь, шаг за шагом.
• Альтернативные сценарии: Что может пойти не так.

Пример Use Case: Оформление заказа

• Название: Оформить заказ.

• Актор: Зарегистрированный пользователь.

• Предусловие: Пользователь авторизован, товары добавлены в корзину.

• Постусловие: Заказ создан и сохранен в системе, пользователь получил подтверждение.

• Основной сценарий:

  1. Пользователь переходит в корзину.
  2. Система отображает список товаров и итоговую сумму.
  3. Пользователь нажимает кнопку “Оформить заказ”.
  4. Система запрашивает адрес доставки и способ оплаты.
  5. Пользователь вводит данные и нажимает “Подтвердить заказ”.
  6. Система проверяет данные, создает заказ и присваивает ему номер.
  7. Система отправляет подтверждение на email пользователя.
  8. Система перенаправляет пользователя на страницу “Заказ оформлен”.

• Альтернативные сценарии:

  • 4а. Если товара нет в наличии, система уведомляет пользователя и предлагает удалить товар из корзины.
  • 6а. Если данные введены неверно (некорректный адрес), система показывает ошибку и просит исправить.
  • 7а. Если email не указан, подтверждение не отправляется, но заказ создается.

Use Cases хороши для сложных сценариев, где важна последовательность и много альтернативных веток.

User Stories (Пользовательские истории)

Это подход из Agile. User Story – это короткая формулировка требования от лица пользователя. Она записывается на карточку и служит для быстрого обсуждения.

Шаблон User Story:

“Как [роль] , я хочу [действие] , чтобы [ценность] “.

Разберем по частям:

• Как [роль] – кто именно это хочет.
• Я хочу [действие] – что именно он хочет сделать.
• Чтобы [ценность] – зачем ему это нужно, какую проблему решает.

Примеры User Stories:

• “Как покупатель, я хочу видеть историю своих заказов, чтобы отслеживать все покупки в одном месте”.
• “Как менеджер, я хочу получать уведомление о новом заказе, чтобы сразу начать его обрабатывать”.
• “Как администратор, я хочу блокировать подозрительных пользователей, чтобы защитить систему от мошенников”.
• “Как курьер, я хочу отмечать заказ как доставленный, чтобы система уведомила клиента и закрыла задачу”.
• “Как гость, я хочу сравнивать товары, чтобы выбрать лучший, не регистрируясь”.

Последняя часть “чтобы” очень важна. Она помогает не потерять фокус на ценности. Если вы не можете объяснить, зачем пользователю эта функция, возможно, она не нужна.

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

Интервью с пользователями

Самый прямой способ. Садитесь с реальным пользователем (или заказчиком, который представляет пользователей) и спрашиваете: “Расскажи, как ты сейчас работаешь? Что тебе нравится? Что бесит? Что бы ты хотел улучшить?”.

Наблюдение (Ethnographic research)

Приходите и смотрите, как люди работают сейчас. Часто люди делают не так, как говорят. В разговоре человек может сказать “все нормально”, а вы увидите, что он открывает 10 окон и переписывает данные вручную – вот вам и требование.

Анализ существующей системы

Если система уже есть, посмотрите логи, тикеты поддержки, запросы пользователей. Там часто всплывают “хотелки”.

Мозговой штурм с командой

Иногда команда сама генерирует хорошие идеи, потому что видит продукт изнутри.

Пример: От бизнес-требований к пользовательским

Вернемся к нашему примеру из прошлой главы.

Бизнес-требование

“Снизить операционные расходы колл-центра на 30% за счет автоматизации ответов на типовые вопросы клиентов”.

Анализ

Мы знаем цель компании. Теперь нам нужно понять, КТО и КАК будет взаимодействовать с системой, чтобы эту цель достичь.

Вопросы, которые задает аналитик:

• Кто звонит в колл-центр? (Клиенты)
• Какие вопросы они задают чаще всего? (Статус заказа, как вернуть товар, где пункт выдачи)
• Кто сейчас отвечает на эти вопросы? (Операторы)
• Как они это делают? (Открывают систему, смотрят статус, говорят клиенту)
• Что хотят клиенты на самом деле? (Быстро получить информацию, не ждать на линии)
• Что хотят операторы? (Не отвечать на одни и те же вопросы по 100 раз)

Пользовательские требования (результат)

• “Как клиент, я хочу быстро узнать статус своего заказа, чтобы не ждать на линии и не тратить время”.
• “Как клиент, я хочу получить ответ на вопрос о возврате в любое время суток, чтобы не привязываться к графику работы колл-центра”.
• “Как оператор, я хочу, чтобы меня не отвлекали на типовые вопросы, чтобы я мог сосредоточиться на сложных случаях, требующих моего опыта”.
• “Как оператор, я хочу видеть статистику по типовым вопросам, чтобы понимать, какие темы чаще всего беспокоят клиентов”.

Следующий шаг - превратить эти пользовательские требования в конкретные функциональные (чат-бот, страница статуса заказа, база знаний и т.д.).

Типичные ошибки

Ошибка 1: Путать пользовательские требования с функциональными

“На странице заказа должна быть кнопка “Отменить”. Это уже функциональное требование. Пользовательское требование звучало бы так: “Как покупатель, я хочу иметь возможность отменить заказ, если передумал”.

Ошибка 2: Забывать про ценность (часть “чтобы”)

“Как пользователь, я хочу вводить дату рождения” - плохо. Зачем? А если добавить “чтобы получать скидку в день рождения” – сразу понятна ценность.

Ошибка 3: Слишком общие формулировки

“Система должна быть удобной” – это не пользовательское требование. А вот “Как пользователь, я хочу оформлять заказ в три клика, чтобы не тратить время” уже ближе к делу.

Ошибка 4: Игнорировать разные роли

Думать, что все пользователи одинаковые. Менеджеру нужно одно, клиенту – другое, администратору – третье. Каждую роль нужно описать отдельно.

Ошибка 5: Не проверять с реальными пользователями

Написали User Story, отдали разработчикам, через месяц показали пользователю. А он говорит: “Да мне это не нужно, мне нужно было другое”. Проверять нужно до разработки, показывая прототипы или просто обсуждая тексты.

Резюме для системного аналитика

1. Пользовательские требования отвечают на вопросы “КТО?” и “ЧТО ХОЧЕТ?”. Это про людей и их цели.

2. Всегда указывайте роль и ценность. Шаблон “Как [роль] я хочу [действие] чтобы [ценность]”.

3. Не смешивайте уровни. Пользовательское требование – это не про дизайн и не про техническую реализацию. Это про потребность пользователя.

4. Учитывайте всех акторов. Не только явных пользователей, но и тех, кто остается за кадром (администраторы, поддержка, смежные системы).

5. Проверяйте с реальными людьми. Самые лучшие требования рождаются не в кабинете, а в разговоре с теми, кто будет реально работать в системе.