Изучив примеры ТЗ в открытом доступе, можно сделать следующие выводы:

• И Заказчик, и Разработчик считают, что ТЗ должно быть максимально подробным и однозначно понимаемым, но никто не хочет тратить много времени и ресурсов на его разработку.
• С однозначным пониманием возникают проблемы - слишком многое подразумевается, имеется в виду и кажется очевидным Заказчику. Разработчик же, в целях минимизации затрат, не стремится делать то, что не прописано в ТЗ.
• Часто возникают противоречия между тем «как хочется Заказчику» и «что действительно можно реализовать в рамках бюджета».
• Для успешного сотрудничества нужна готовность к компромиссам, вовлеченность с обеих сторон и готовность к тому, что не прописанные в ТЗ требования могут возникнуть с обеих сторон.

Для решения таких проблем есть несколько подходов.

• Ограничиться брифом. Бриф - документ, краткая письменная форма согласительного порядка между планирующими сотрудничать сторонами, в которой прописываются основные параметры будущего программного проекта.
  Это заявка, первоначальное видение того, что должно быть. Обычно готовится Заказчиком, для сравнения предложений и выбора подрядчика. В такой ситуации итоговый бюджет разработки может вырасти в несколько раз, т.к. однозначно оценить сразу, сколько это будет стоить, по брифу очень сложно.
• Составление ТЗ после разработки и запуска MVP. Минимально жизнеспособный продукт (minimum viable product, MVP) продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Основная задача — получение обратной связи для формирования гипотез дальнейшего развития продукта. Сбор информации от MVP зачастую дешевле, чем разработка продукта с большим количеством функций.
  Это позволяет снизить затраты и риски, если продукт не заработает, например, из-за неверных предположений или анализа рынка.
• Разработка полноценного ТЗ (обычно это документ на 70-150 стр.) на первом этапе работы и доработка в ходе выполнения проекта.
  Требует дополнительных ресурсов, но позволяет полностью понять временные и денежные затраты на проект.

Логично поэтому оценивать предстоящую работу именно по ТЗ.

Что должно быть включено в ТЗ на разработку Интернет-магазина по мнению разработчиков:

1. Общие сведения о проекте
   • Цели и задачи проекта
     Описание бизнеса и что хочет получить Заказчик от сайта.
   • Аудитория проекта
     Кто наши покупатели и конкуренты.
   • Общая структура сайта
     Ключевые разделы, возможности для посетителей, посадочные страницы.
   • Сроки и календарный план исполнения проекта
     Четко прописанные этапы, чтобы в любой момент можно было понять, где мы находимся.
   • Контент
     Чем торгуем. Какого рода контент будет представлен на сайте. Где он будет размещаться. Что готовится Заказчиком, а что Разработчиком.
2. Распределение работ между Разработчиком и Заказчиком
   • Заказчик предоставляет информацию.
   • Разработчик выполняет работы.
3. Дизайн
   • Заполненный заказчиком брифлист.
     Что должно быть на каждой странице (баннеры, каталог, рекомендации, отзывы, виджеты и проч.). Желательно с примерами того, что нравится заказчику на других сайтах (возможно, анимация каталога или 3Д просмотр).
   • Подробная структура.
     Вплоть до мелочей – страницы, разделы, подразделы, личный кабинет покупателя, корзина.
   • Функциональные прототипы страниц.
     Расположение всех блоков Например, на главной странице сайта расположение блоков может быть обозначено так:
     
     на всех страницах.
   • Фирменный стиль Заказчика.
     Брендирование, логотипы, цвета.
   • Требования к адаптивности.
     На каких устройствах предполагается отображение сайта.
   • Сценарии взаимодействия.
     Пути следования покупателя по сайту с различных точек входа на сайт.
4. Особенности функционала:
   • Мультиязычность
     На каких языках будет работать сайт.
   • Мультивалютность.
     В каких валютах будут отображаться цены товаров, как будут задаваться курсы валют.
   • Типы цен.
     Кому и в каких ситуациях доступны разные типы (оптовая, розничная, премиальная и др.) цен.
   • Управление заказами, доставками, оплатами.
   • Рассылки и уведомления.
     Каким образом и о каких событиях информируется покупатель/администратор/владелец сайта.
   • Интеграции
     С учетно-бухгалтерскими программами (например, с 1С), с соцсетями, с уже существующими проектами Заказчика.
   • Импорт/экспорт.
   • Система бонусов.
     Скидки, наценки, подарки, карты постоянного клиента и проч.
   • Личный кабинет покупателя.
     Способы авторизации, редактирование профиля, отслеживание заказов, возвраты, внутренний счет и т.д.
   • Разграничение прав.
     Что входит в права администратора/контент-менеджера/зарегистрированных и не зарегистрированных покупателей/разных типов покупателей.
5. SEO требования
   Могут быть в отдельном документе. Желательно привлечение SEO-специалиста для разработки.
6. Программные модули
   • Система администрирования сайта (движок сайта, CMS).
   • Описание того, чего нет в CMS и подлежит разработке.
   • Где получить недостающие модули (разработка, маркетплейс, подписка).
7. Требования
   • К хостингу.
   • К администратору сайта.
   • К контент-менеджеру (например, будет ли он заниматься SEO, общением с пользователями, техподдержкой или это будут отдельные специалисты).
8. Финальная часть
   • План тестирования проекта.
   • Ответственность сторон.
   • Прочая информация.

В рамках текущего курса мы рассказываем подробно о пункте 4 и частично о пп. 3 и 6. Пункт 5 подробно рассматривается в курсе Продвижение сайта и маркетинг.