1. Соберите исходные данные
До выбора платформы соберите короткий паспорт проекта. Неизвестное пометьте «нужно уточнить» и назначьте владельца ответа — пустое поле легко превращается в спор об объёме.
- Цель: какое действие человек должен выполнить на сайте; кто подтвердит, что результат ему подходит.
- Аудитория и роли: посетитель, редактор, администратор; какие действия доступны каждой роли и какие запрещены.
- Контент: перечень страниц, файлов и записей; объём переноса; кто готовит тексты, изображения, переводы и доступные версии документов.
- Текущая среда: домен, хостинг, CMS, подключённые сервисы, ограничения доступа. Записывайте владельца доступа, а не пароль.
- Зависимости: кто предоставляет API, тестовые данные и учётные записи, согласует дизайн и принимает результат.
- Границы: что создаём, что переносим, что оставляем как есть, какие подписки и дальнейшее сопровождение обсуждаются отдельно.
2. Опишите сценарии вместо общих пожеланий
Формулировки «удобная CMS» и «быстрый сайт» не объясняют, что именно показывать на проверке. Используйте цепочку: роль → исходное состояние → действие → наблюдаемый результат → способ проверки.
Учебный пример: публикация новости
Требование Ф-01. Редактор создаёт новость с заголовком, текстом и изображением, сохраняет черновик, проверяет предпросмотр и публикует запись. Посетитель видит опубликованную версию; черновик ему недоступен. Редактор не может менять права пользователей.
Проверка: создать тестовую запись под ролью редактора, открыть её как анонимный посетитель до и после публикации, проверить запрет управления правами. Сохранить время действий, адрес записи и результаты. Допустимую задержку публикации согласовать отдельно.
Добавьте отрицательный сценарий: обязательное поле пустое, файл неподходящего типа, сессия закончилась, нет прав. Укажите, какое сообщение увидит человек и сохранятся ли введённые данные. Используйте синтетические тестовые данные.
3. Разделите результат на проверяемые части
Дизайн и содержание
Список макетов и состояний, согласование адаптивных вариантов, готовность текстов, исходники графики и условия использования шрифтов. «Дизайн принят» не означает, что контент перенесён.
CMS и публикация
Роли, черновик, публикация, снятие с публикации, история изменений и восстановление. Если контуры разделены — источник данных, канал обновления, задержка и поведение при сбое.
Интеграции
Для каждой связи: система, направление обмена, формат, владелец, тестовая среда, квитанция успеха, повтор запроса и поведение при недоступности.
Передача и эксплуатация
Исходный код, сборка, развёртывание, резервная копия и пробное восстановление, инструкции, обучение редактора и список внешних зависимостей.
Разработка, лицензия стороннего сервиса, хостинг, гарантийное исправление и новые доработки — разные составляющие. Укажите состав каждой и ответственного, чтобы сравнивать предложения на одинаковый объём.
Если сайт уже существует
Составьте реестр действующих адресов, страниц и документов. Для каждого укажите: сохраняем, переносим на новый адрес или исключаем по согласованному основанию. Запишите объём начального переноса и порядок переноса изменений, появившихся до запуска.
В отдельной таблице разделите «уже есть / покупается / разрабатывается / предоставляет заказчик». Для установленной CMS зафиксируйте редакцию, модули и ограничения обновления; совместимость нового решения проверяют отдельно. Наличие лицензии не означает, что в ней уже есть все нужные функции.
4. Назначьте измеримые критерии
Число без условий измерения не помогает приёмке. Для скорости укажите страницы, устройство, сеть, размер данных и метод замера. Для обновления контента — момент начала отсчёта и место, где проверяется новая версия.
| Пожелание | Что записать для проверки |
|---|---|
| «Быстро загружается» | Страницы, профиль устройства и сети, метрика, порог, число повторов, условия кеширования. |
| «Удобно на телефоне» | Ключевые сценарии, размеры окна, браузеры, ориентация; отсутствие перекрытых кнопок и потери текста. |
| «Доступно всем» | Навигация с клавиатуры, видимый фокус, подписи полей, понятные ошибки, увеличение текста; отдельная проверка специалистом по доступности. |
| «Надёжные формы» | Проверка полей, согласованное обращение с данными, повторы, отказ сети, отсутствие ложного успеха, доступный альтернативный контакт. |
| «Есть резервная копия» | Состав копии, частота и хранение, ответственный, пробное восстановление на отдельном стенде и критерий его успеха. |
Не переносите чужие проценты доступности, сроки гарантии или набор технологий в свой проект автоматически. Сначала проверьте потребность, инфраструктуру и возможность объективно испытать условие.
5. Свяжите ТЗ с проверками
Присвойте требованиям устойчивые номера. В одной таблице связывайте номер требования, сценарий, ожидаемый результат, доказательство и статус. Если требование меняется, обновляйте соответствующий тест и версию документа.
Пример записи: Ф-01 → тест П-01 «редактор публикует новость» → посетитель видит согласованную версию, черновик закрыт → снимки до/после и журнал публикации → статус «пройдено / не пройдено / не проверено».
Статус «не проверено» сохраняйте, если не предоставлен доступ к внешнему сервису. Он не равен успешной проверке.
Заранее согласуйте критичность дефектов, порядок повторной проверки и участников. Технический отчёт помогает принять решение, но не заменяет предусмотренные договором процедуры.
6. Проверьте готовность ТЗ
- Каждую обязательную функцию можно показать на согласованных данных.
- Для текста, доступов и интеграций назначены владельцы и сроки предоставления.
- Есть перечень передаваемых файлов, инструкций и материалов обучения.
- У каждого числового показателя есть метод измерения.
- Изменения объёма и повторная проверка описаны; неопределённости видимы.
Частые ошибки
Список страниц без пользовательских действий; название CMS вместо требований к редактору; интеграция без владельца внешнего API; «безопасный сайт» без состава проверки; обещание передать код без инструкции сборки. Исправьте эти пробелы до сравнения предложений.
Когда нужен специалист
Подключите архитектора для сложного обмена и миграции, инженера по безопасности — для модели угроз и программы испытаний, специалиста по доступности — для проверки с вспомогательными технологиями. Применимые правовые требования и условия закупки определяют отдельно с ответственными специалистами.