ТРЕБОВАНИЯ К САЙТУОпишите роль пользователя, действие и ожидаемый результат. «Покупатель выбирает несколько товаров и отправляет запрос с контактами; менеджер получает список позиций в CRM» понятнее, чем «сделать удобный каталог». Каждое требование должно допускать проверку.
Приложите перечень того, что не входит в первую версию, и процедуру изменения требований. Любое новое пожелание сначала оценивается по влиянию на срок, стоимость и уже согласованные сценарии. Так документ помогает принимать решения, а не становится архивом споров.
Для старого сайта добавьте требования к переносу страниц и материалов.
Разделите требования по тому, что предстоит проверить
Разведите по разделам поведение посетителя, содержание страниц, возможности сотрудника и условия работы системы. Так проще найти требование при проверке. Посетитель отправляет запрос, редактор меняет описание услуги, система сохраняет обращение, сотрудник получает его для обработки: это связанные, но разные действия.
Начните с небольшого словаря. Определите, что в вашем проекте называют заявкой, заказом, программой, филиалом и вариантом товара. Одинаковые слова могут означать разные сущности у заказчика и разработчика. Если «заказ» пока лишь запрос на уточнение наличия, это нужно прямо объяснить. Иначе интерфейс, уведомления и внутренние статусы могут быть спроектированы для другой стадии взаимодействия.
Каждому важному требованию удобно присвоить короткое обозначение. По этому обозначению можно связать описание, прототип и замечание при проверке. Например, замечание ссылается на правило сохранения выбранной услуги и показывает шаги воспроизведения. Так обсуждение остаётся предметным, даже когда в проекте появляется несколько форм, одинаковых полей и похожих экранов.
Не дублируйте макет в задании: согласованный оттенок кнопки уже задан оформлением. А поведение при недоступном внешнем сервисе опишите словами. В документе должны оставаться требования, влияющие на результат и проверку.
Опишите данные и состояния, которые не видны на макете
Для редактируемого объекта перечислите поля и их обязательность. Например, проект содержит название, задачу, изображения и связанную услугу. Укажите, можно ли публиковать его без фотографий и как тогда выглядит страница.
Приложите характерные исключения: длинное техническое название, несколько документов, пустое описание, одинаковые заголовки. Короткие демонстрационные тексты не покажут, пригодны ли карточка и меню для ваших материалов.
Состояния относятся и к действиям пользователя. Форма бывает незаполненной, ошибочной, отправляющейся, принятой или временно недоступной. Для каждого случая определите, что человек видит и может сделать дальше. Особенно важно различать приём обращения сайтом и дальнейшую передачу в другую систему. Подтверждение одного события не должно создавать неподтверждённое обещание о другом.
Если данные приходят извне, опишите источник каждого существенного поля и допустимые действия редактора. Укажите, может ли сотрудник исправить название вручную, сохранится ли правка после обновления и как обнаружить пропущенный обмен. Фраза «двусторонняя интеграция» не объясняет, что происходит при конфликте двух версий одного значения.
Фрагмент задания: запрос на консультацию
Представим консультационный центр с несколькими направлениями и филиалами. Это вымышленный пример, который показывает подробность требований. Посетитель выбирает направление, знакомится с условиями и оставляет запрос на согласование времени. Свободные часы на сайте не отображаются, поэтому отправка формы не считается подтверждённой записью. Это ограничение отражается в тексте перед отправкой и после неё.
В задании указывают поля: имя, контакт, выбранное направление и необязательный комментарий. Направление подставляется со страницы, но посетитель может его изменить. Филиал выбирается только из тех, где доступно направление. Если подходящего филиала нет, сайт предлагает общий запрос и объясняет, что сотрудник уточнит возможность консультации. Скрывать проблему за пустым выпадающим списком нельзя.
Обычная проверка проходит так: открыть направление, выбрать филиал, заполнить контакт и отправить форму. В сохранённом обращении должны остаться выбранные значения и страница отправки. Затем проверяют ошибку в обязательном поле: сообщение находится рядом с ним, понятным языком объясняет исправление и не стирает остальные сведения. Повторное нажатие во время ожидания не должно порождать неуправляемые дубликаты.
Отдельно опишите сбой передачи, получателя обращения и резервный способ доставки. Сайт сохраняет принятое обращение и сообщает ответственному о проблеме согласованным способом; пользователю показывают только подтверждённый статус. Если сохранение вообще не удалось, успешного сообщения нет. Конкретная реализация выбирается командой, но проверяемое поведение задано заранее. Для приёмки используют подготовленные тестовые данные, а не реальные обращения будущих клиентов.
Свяжите требования к качеству с условиями измерения
«Быстро», «удобно» и «адаптивно» описывают желание, но не дают одинаковой проверки. Если важна работа на телефоне, перечислите обязательные сценарии и характерные размеры экрана. Нужно прочитать условия, открыть документы, заполнить форму, увидеть ошибку и закончить действие без горизонтальной прокрутки. Такой набор конкретнее требования просто показать уменьшенную главную страницу.
Для проверки скорости согласуйте страницы, заполнение, первый или повторный визит и способ измерения. Затем задайте допустимые значения. Иначе стороны будут сравнивать разные условия.
Управление содержанием тоже проверяют на действиях. Вместо «удобная админка» напишите, что редактор создаёт услугу, меняет порядок фотографий и снимает устаревший документ с публикации. Определите, какие настройки ему доступны, а какие остаются у технического специалиста. Это помогает не перегрузить рабочее место сотрудника и одновременно не сделать повседневное обновление зависимым от разработки.
Для восстановления нужен согласованный результат, а не только наличие слова «бэкап». Опишите, какие данные сохраняются, кто отвечает за копии и как проверяется восстановление на подготовленной среде. Не обещайте отсутствие любой потери без понятных условий. Проверка должна соответствовать устройству сайта: опубликованным материалам, обращениям и внешним зависимостям, которые невозможно восстановить простым копированием файлов.
Оставьте документ управляемым во время проекта
Храните согласованную версию и список существенных изменений с причиной и затронутыми частями. Правка фразы и добавление сценария требуют разного согласования. Одной переписки для контроля версии недостаточно.
У замечания при приёмке должны быть ссылка на требование, условия проверки и наблюдаемый результат. «Каталог работает неправильно» трудно исправить. «После выбора размера список пуст, хотя в подготовленных данных есть подходящая позиция» позволяет воспроизвести проблему. Если ожидаемого поведения нет в документе, сначала согласуют решение, затем определяют, является ли это уточнением или расширением задачи.
Отмечайте зависимости от внешних участников: кто предоставит описание обмена, подтвердит товарные признаки или даст доступ к тестовой системе. Если зависимость не готова, заранее выбирают допустимую замену для промежуточной проверки. Она может подтвердить работу части сценария, но не должна выдаваться за проверенную интеграцию с реальной системой. Это различие следует сохранить в результатах приёмки.
Материал обновлён в октябре 2026 года.