Разработка требований к программному обеспечению: пошагово

Почему именно требования определяют бюджет проекта

Представьте владельца магазина одежды в Ташкенте. Он говорит подрядчику: «Нужен бот, чтобы клиенты заказывали». Подрядчик делает каталог и корзину. Выясняется, что владелец ожидал оплату через Click и Payme, выбор филиала для самовывоза, уведомление менеджеру в рабочий чат и интерфейс на русском и узбекском. Каждая из этих деталей была в голове заказчика, но не на бумаге.

Это и есть главный риск: стороны не спорят, они просто понимают одно слово по-разному. Чем позже обнаруживается расхождение, тем дороже его исправить: поменять формулировку в документе дёшево, поменять готовую логику оплаты и базу данных — нет.

Четыре уровня требований

Требования удобно раскладывать по уровням. Так вы не смешиваете цель бизнеса с конкретной кнопкой в интерфейсе.

• Бизнес-требования: зачем нужна система. Например, принимать заказы вне рабочего времени и разгрузить менеджеров в Instagram и Telegram.
• Пользовательские требования: что человек хочет сделать. Клиент хочет выбрать товар, оплатить и узнать статус доставки.
• Функциональные требования: что система делает. Показывает каталог, формирует заказ, отправляет ссылку на оплату, уведомляет оператора.
• Нефункциональные требования: в каких условиях работает. Скорость ответа, число одновременных диалогов, защита данных, поведение при сбое.
• Интеграционные требования: с чем обменивается данными. Платёжный сервис, CRM, таблица остатков, служба доставки.

Как собирать требования: пошаговая инструкция

Главная ловушка этапа в том, что люди описывают решение, а не проблему. Фраза «сделайте выгрузку в Excel» на деле может означать «бухгалтер хочет сверять оплаты по вечерам». Для такой задачи лучше подойдёт автоматический отчёт в Telegram. Ваша задача — дойти до причины.

• Шаг 1. Сформулируйте цель одной фразой и признак успеха: что изменится в бизнесе, если система заработает.
• Шаг 2. Составьте список всех, кто будет с ней взаимодействовать: клиент, менеджер, курьер, бухгалтер, владелец.
• Шаг 3. Поговорите с каждой ролью и спросите, как она работает сейчас и где теряет время. Опишите процесс «как есть».
• Шаг 4. Посмотрите на реальную работу: переписки с клиентами, таблицы заказов, журналы звонков.
• Шаг 5. Нарисуйте процесс «как должно быть» и покажите участникам. Для бота хватит схемы диалога на бумаге или в прототипе.
• Шаг 6. Зафиксируйте всё письменно и попросите подтверждение у владельца процесса.

Сценарии и критерии приёмки на примере бота

Сценарий описывает один путь конкретного человека. Например: «Клиент из Самарканда открывает бота, выбирает язык, добавляет товар в корзину, указывает адрес, оплачивает через Payme и получает сообщение с номером заказа. Менеджер видит заказ в рабочем чате с пометкой „оплачено“».

К каждому сценарию добавьте критерии приёмки: проверяемые условия, по которым принимается результат. «Бот должен работать быстро» проверить невозможно. «Бот отвечает на нажатие кнопки за согласованное время, а при сбое оплаты клиент получает понятное сообщение и кнопку повторить» проверить можно. Конкретное значение времени вы определяете с разработчиком исходя из задачи и фиксируете в документе.

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

Нефункциональные требования, о которых забывают

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

Отдельно опишите языки и тексты: русский, узбекский на латинице, возможно кириллица. И устройства: часть клиентов в регионах пользуется недорогими смартфонами и нестабильным интернетом, поэтому лёгкие сообщения и кнопки работают лучше тяжёлых картинок.

Приоритеты: как выделить первую версию

Не всё нужно делать сразу. Разделите требования на три группы и сравните их по ценности для бизнеса и сложности.

• Обязательные: без них система не приносит пользы. Каталог, заказ, приём оплаты, уведомление менеджеру.
• Важные: заметно улучшают работу, но можно запустить без них. Промокоды, история заказов, повторный заказ.
• Желательные: приятные дополнения. Программа лояльности, рассылки по сегментам, интеграция с маркетплейсами.

Типичные ошибки при описании требований

Разберём то, что чаще всего приводит к спорам между заказчиком и исполнителем.

• Расплывчатые формулировки: «удобно», «быстро», «современно» без критерия проверки.
• Только функции без цели: непонятно, зачем они нужны, и невозможно отказаться от лишнего.
• Один источник мнений: говорил только владелец, а менеджеры и курьеры узнали о боте в день запуска.
• Нет описания ошибок: что видит клиент при сбое оплаты или отсутствии товара.
• Нет ответственного за согласование: два отдела просят противоположное, и решение откладывается до запуска.
• Требования пишутся один раз и забываются, хотя бизнес меняется.

Чек-лист перед стартом разработки и управление изменениями

Прежде чем подписывать договор и этапы работ, пройдите по списку. Если на пункт нет ответа, вернитесь к обсуждению.

Изменения неизбежны: появится новый способ оплаты, изменится схема доставки. Это нормально, если есть процедура. Каждое изменение записывается, оценивается по влиянию на сроки и стоимость и согласуется до реализации. Тогда бюджет остаётся предсказуемым, а не складывается из устных «давайте ещё добавим».

• Цель проекта и признак успеха записаны.
• Перечислены все роли пользователей.
• Для главных задач есть сценарии, включая ошибки.
• У каждого важного требования есть критерий проверки.
• Определены внешние сервисы: платежи, CRM, доставка.
• Описаны нагрузка, безопасность и резервное копирование.
• Требования разделены по приоритетам, первая версия определена, назначен человек, который согласует правки.

С чего начать и где помогут

Начните с одной страницы: цель, роли, три-пять ключевых сценариев и список интеграций. Этого достаточно для предметного разговора с разработчиком, а подробности добавятся по ходу.

Если вы планируете Telegram-бот для заказов, записи или поддержки клиентов, команда markdev поможет превратить идею в понятное описание задачи, предложит структуру диалога и честно обозначит, что войдёт в первую версию. Напишите нам, и мы обсудим вашу задачу.