Техническое задание на обслуживание сайта

Что должно включать в себя техническое задание

В этой статье мы опишем, что должно включать в себя техническое задание на веб-сервис, сложный сайт или интернет магазин, и почему.

Всё началось с того что на большие интернет-проекты нам начали присылать техзадания, написанные на 25-40 листах А4. Раньше мы всегда отдавали ТЗ на прочтение и оценку разработчикам, но когда в неделю приходит 3 или 4 подобных документа, даже на то, чтобы их внимательно прочитать, выписать список вопросов и понять чего в этом документе не хватает, может уйти вся неделя, а то и больше.

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

Мы решили эту задачу сделав чеклист проверки техзадания: документ, в котором описано какие разделы ТЗ должны быть, что они должны включать в себя и почему. Детализацию по разделам и ссылку на скачивание нашего чеклиста смотрите ниже.

Основные разделы техзадания

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

Общая информация о проекте

• Концепция продукта – потребность или проблема, которую продукт решает, общая логика решения, целевая аудитория;
• Цели и задачи проекта – коротко описать, какие есть конкретные цели проекта в цифрах (KPI): достичь траффика 10 000/мес, увеличить продажи на 20% и так далее;
• Словарь терминов, использованных в ТЗ – названия особых систем клиента, технические термины, у которых в контексте данного техзадания может быть свое значение;
• Перечень документов, на основании которых создается проект – ссылки на внешние документы, прототипы, исходники дизайна, для того чтобы не искать по телу документа;
• Карта разделов или страниц проекта – в формате дерева или хотя бы просто иерархического спика для того чтобы было сразу понятен объем разрабатываемого ресурса.

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

Встречается возражение, что «мы не будем описывать для чего и для кого этот проект, это коммерческая тайна, нас интересует только реализация».

Риски утечки конфиденциальной информации решаются путем подписания Договора о неразглашении (NDA). 

Прототип и дизайн

• Прототип или мокапы – для любого современного интернет-проекта разработка прототипа или мокапов является необходимым и очень ускоряет процесс и точность оценки;
• Дизайн – если уже готов на данный момент, то прикрепить ссылку на исходные файлы макетов отдельным архивом;
• Описание динамики страниц – как должен реагировать интерфейс при нажатии на различные элементы управления, эффекты, появление всплывающих окон и подсказок и т.п. Обычно эту часть клиенты описывают легче всего;
• Требования к мобильной или адаптивной версии – на каких устройствах предполагается работа с этим проектом – платформы, браузеры.

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

Функциональная часть проекта

• Информационная архитектура проекта должна быть описана структура сущностей проекта – сущностей базы данных, объекты системы, основные функции ядра, роли пользователей проекта;
• Функциональная спецификация под прототип – помимо динамики страниц, описанной выше, должно быть описано какие алгоритмы или какие функции ядра системы вызываются;
• Описание бэк-офиса – функционал для администратора, контент-менеджера и других – как будет построено администрирование и наполнение проекта;
• Интеграции с внешними и внутренними системами – какие данные передаются, куда, в каком виде, например, если используется API сторонних систем, то как именно;
• Тестирование ресурса – на каких устройствах, платформах, браузерах и при каких условиях будет тестироваться проект;
• Требования по безопасности ресурса – общие или специальные требования к безопасности;
• Требования по нагрузке и серверам – какую нагрузку должен выдерживать проект и на каких серверах размещаться.

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

Организационная часть проекта

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

Это один из самых важных разделов, который позволяет не поссориться на проекте и успешно довести проект до запуска.

Специфика, которая зависит от проектов

Помимо общих разделов проекты в зависимости от целей и масштаба имеют свою специфику.

Разделы технического задания на разработку портала или сервиса

Разделы по серверам обязательно дополняются конкретными параметрами серверов (CPU, RAM, HDD), интерфейсы доступа и сертификаты (SSH, FTP/SFTP, SSL), операционная система на сервере, окружение, системы, расширения, которые должны быть установлены (apache/nginx/iis/…).

Техническая часть дополняется требованиями к документации разработки: как документируется код, как собирается вся документация о проекте. 

Тестированиедополняется написанием тест-кейсов, использованием автоматических тестов, unit-тестов, непрерывной интеграцией и так далее.

Специфика техзадания на разработку большого сайта и интернет-магазина

Для больших проектов нужно сразу в тех. задании делать SEO-проектирование и описывать требования к первичной внутренней оптимизации и базовым требованиям к коду для поисковых систем.

• правила генерации URL
• правила автогенерации TDH: title, description, h1
• генерация карты сайта (sitemap.xml)
• микро-разметка (семантическая разметка)

Также обязательно описываются системы доставки и оплаты, особенно если используются API для расчета стоимости доставки, «безопасная сделка» и другие современные механизмы.

Если есть требования к платформе разработке или конкретной системе управления сайтом или магазином они также должны быть указаны.

ТЗ на разработку сайта или магазина на новой платформе, когда уже есть существующий

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

• сохранение url или 301-редиректы
• сохранение TDH или автогенерация новых
• редиректы с бэклинков
• перенос контента, особенно если контента много и нужен перенос с помощью парсера или используя старый дамп базы
• Правила наполнения и внесения нового контента на сайт, какие alt,title,description указывать для картинок и так далее

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

Готовый чеклист технического задания

Готовый чеклист технического задания доступен в форматах Google Spreadsheet(онлайн-таблица, заполните форму ниже) и MS Excel (вышлем по запросу).

Бонус №1: признаки неправильного техзадания. В версии чеклиста, доступной для скачивания мы также внесли признаки плохого техзадания.

Бонус №2: послезаполнения чеклиста, мы считаем общий балл качества вашего техзадания от -5 (всё очень плохо) до 5 (прекрасно).

Если этот материал был вам полезным, будем благодарны за комментарии и репост в соцсетях. Если у вас есть что дополнить — напишите нам!

UPD: расшарив этот материал в соцсетях мы начали получать отклики «это вы хотите полететь космос, а не создать ТЗ на сайт» и второй по популярности «заказчик это сделать не может сам».

Да, этот чеклист целесообразен в первую очередь для сложных проектов, разработка которых стоит десятки тысяч долларов. И цена ошибки здесь велика. И мы не ждем, что это будет делать собственник бизнеса.

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

Международные компании когда приглашают в тендер на разработку веб-проектов, присылают RFP (Request For Proposal), который содержит то, что здесь указано и даже больше, например матрицу коэффициентов при выборе подрядчика.

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

Когда компания или предприниматель обращается к нам с идеей, мы разрабатываем техзадание как часть этапа проектирования, который начинается с создания прототипа.

11.10.2016

Источник: https://evergreens.com.ua/ru/articles/checklist-tz.html

Техническое задание на разработку сайта

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

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

Требования к системе управления контентом (CMS)

Система управления контентом (административная часть сайта) должна предоставлять возможность добавления, редактирования и удаления содержимого статических и динамических страниц. Также должна быть предусмотрена возможность добавления информации без отображения на сайте.

Система управления контентом должна иметь стандартный интерфейс, отвечающий следующим требованиям:

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

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

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

Графические элементы навигации должны быть снабжены альтернативной подписью.

Система должна обеспечивать навигацию по всем доступным пользователю ресурсам и отображать соответствующую информацию. Для навигации должна использоваться система контент-меню.

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

Для разделов, содержащих подразделы, должно быть предусмотрено выпадающее подменю.

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

Требования к разделению доступа

Информация, размещаемая на сайте, является общедоступной. Пользователей сайта можно разделить на 3 группы в соответствии с правами доступа:

• Посетители
• Редактор (сотрудник Заказчика)
• Администратор (сотрудник Исполнителя)

Посетители имеют доступ только к общедоступной части сайта.

Доступ к административной части имеют пользователи с правами редактора и администратора.

Редактор может редактировать материалы разделов.

Администратор может выполнять все те же действия, что и Редактор, и кроме того:

• добавлять пользователей с правами Редактора;
• добавлять и удалять разделы сайта.

Доступ к административной части должен осуществляться с использованием уникального логина и пароля. Логин выдается администратором сайта. При создании пользователя в системе, на его электронный адрес отправляется сообщение, в котором указана одноразовая ссылка входа, перейдя по которой система предлагает пользователю сменить пароль (ввести вручную новый пароль).

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

• Длина пароля должна быть не менее 8 символов.
• Пароль должен состоять из цифр и латинских букв в разных регистрах; желательно включать в пароль другие символы, имеющиеся на клавиатуре (например, символы / ? ! < > [ ] { } и т.д.)
• Пароль не должен являться словарным словом или набором символов, находящихся рядом на клавиатуре. В идеале пароль должен состоять из бессмысленного набора символов.
• Все пароли необходимо менять с определенной периодичностью, оптимальный срок — от трех месяцев до года.

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

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

Требования к хранению данных

Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключениями могут быть файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.).

Такие файлы сохраняются в файловой системе или в облачном хранилище, а в БД размещаются ссылки на них.

Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.

Требования к прикрепленным файлам:

• Максимальный размер файла: 25 МБ.
• Разрешённые типы файлов: txt, jpg, jpeg, png, doc, docx, pdf, ods, xlsx, xls, zip, rar.
• Опция “отображение” у файла позволяет скрыть/отобразить его в списке внизу страницы.
• Максимальное количество прикрепленных файлов у одной страницы – 25.

Требования к языкам программирования

• Для реализации статических страниц и шаблонов должны использоваться языки HTML 5 и CSS 3.
• Исходный код разрабатывается руководствуясь стандартами W3C.
• Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и HTML.
• Для реализации динамических страниц должен использоваться язык PHP.

Все ссылки на сайте должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Изображения, загружаемые через интерфейс управления дополняются замещающим текстом. Допускаются следующие форматы gif, jpg, png.

Требования к программному обеспечению серверной части

Для функционирования сайта необходимо следующее программное обеспечение:

• Операционная система: Ubuntu 16.04;
• Веб-сервер: Nginx версии не ниже 1.13;
• СУБД: MySQL 5.5.3;
• PHP: 5.5.9 или выше.

Требования к клиентскому программному обеспечению

Сайт должен быть доступен для полнофункционального просмотра с помощью популярных браузеров последней версии

Требования к хостингу

Сайт располагается на облачном хостинге, со следующей конфигурацией

• память: от 1 ГБ;
• процессор: от 1 ядра;
• дисковое пространство: от 100 МБ.

Требования к лингвистическому обеспечению

Сайт должен выполняться на русском языке.

Требования к эргономике и технической эстетике

Верстка Сайта должна быть адаптивной под разные разрешения экранов. Сайт должен отображаться без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешений. Изменение расположения элементов сайта при адаптивной версии сайта происходят с учетом следующих параметров ширины экрана:

Источник: https://drupal.ru/tz

Техническое задание на разработку сайта, структура сайта

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

Техническое задание необходимо для разработчика. На него следует ссылаться в процессе составлении договора на оказание услуг между заказчиком и исполнителем. Ответственность в случае невыполнения или некорректного выполнения обязательств и нарушения сроков для обеих сторон должна быть согласована заранее.

Главное – ТЗ помогает ускорить разработку проекта.

Чем подробнее заказчик опишет функционал каждого из модулей, тем оперативнее он получит результат, и это соответствует интересам обеих сторон договора.

На техническое задание к программной продукции (к которой относится и сайты), тоже существует ГОСТ за номером 19.201-78. Он так и называется «Техническое задание. Требования к содержанию и оформлению».

Несмотря на давность, многие его положения до сих пор актуальны.

Назначение ТЗ

Юридическое. Техническое задание — это необходимое приложение к любому договору об оказании услуг.

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

И договор, и техзадание — это описание того, с чем и заказчик, и исполнитель согласились и над чем они сообща работают.

Техническое. Исполнитель — это профессионал, который умеет делать что-то, чего вы не умеете. Или по каким-то причинам не хотите. Формулируя задание, Вы должны быть уверена, что вам дадут именно то, что Вам хочется, а затем получаете от исполнителя гарантию, что он сделает именно это.

Основные пункты технического задания

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

C чего начать писать ТЗ?

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

Если Вы пишете ТЗ для фирмы самостоятельно, лучше прикинуть все на листе бумаги.

Описание

Здесь можно написать несколько предложений о предприятии и его деятельности, нечто вроде вступления.

Далее указываем:

Целевую аудиторию:

То есть надо описать это сайт для юридических или физических лиц, какого возраста, пол, регион.

— партнеры (фирмы)

— продавцы (магазины, интернет-магазины)

— сервисные центры

— потенциальные покупатели

— потребители продукции (кто уже купил)

Назначение сайта:

— улучшение имиджа компании

— увеличение продаж

Тип:

— корпоративный

— сайт – визитка

— интернет-магазин

Цели и задачи сайта

В этом разделе ТЗ мы описываем круг задач, которые решает сайт, всей целевой аудитории.

Потенциальные потребители

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

Также необходимо:

Предоставить информацию о самой продукции, сервисе

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

Составление качественного технического задания на разработку сайта – это вопрос опыта.

На что важно обратить внимание:

Структура сайта — чем проще, тем лучше

Удобнее всего начать с пунктов меню. В них отображаются основные страницы.

Конечный вариант может выглядеть приблизительно так (количество пунктов зависит только от пожеланий заказчика):

Горизонтальное меню:

1. О компании. Лицензии ( чем больше, тем лучше ). Реквизиты компании приветствуются

1.2 История компании

1.3. Отзывы

1.3. Руководство. сотрудники

1.4. Партнеры

2. Новости — не размещайте этот пункт, если не планируете публиковать часто новости на сайте. Если будут висеть старые даты, то это очень испортит имидж компании.

3. Акции

4. Контакты.

Вертикальное меню — каталог продукции или услуги

Так же на сайте рекомендуем реализовать:

Форма подписки
Карту сайта
Поиск
ролик
Социальные каналы

На основе  разработанной структуры сайта создаем дизайн и рисуем блок схему.

Сейчас особенно популярна одностраничная структура, очень удобная для ознакомления (лендинг).

Если планируется масштабная рекламная кампания, лучше подумать о хорошем хостинге.

В момент старта продаж на сайте одновременно окажутся тысячи пользователей. Возможны и DDoS-атаки, предотвращение которых нужно спланировать заранее.

Самое главное и простое правило: на сайте должно быть легко и просто найти нужную информацию

Отправьте нам заявку на разработку ТЗ.

info@2estudio.ru

+79038443000

Опыт ведения коммерческих проектов с 2004 года.

Источник: http://ProdvizhenieSite.ru/news/tekhnicheskoezadanie/

Тз на создание сайта: как сформулировать задачу исполнителю?

Вопрос «Нужно ли вообще составлять техническое задание (ТЗ)?» может возникать только у тех, кто никогда в жизни не заказывал разработку сайта, поскольку необходимость в нём возникает после первого же общения заказчика с исполнителем.

ТЗ — это документ, который описывает будущий проект детально и полностью. Чем детальней он будет, тем точнее будет реализована задумка и тем меньше конфликтов и спорных ситуаций в ходе выполнения проекта будет возникать, ведь абсолютно любую вещь можно сделать по-разному.

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

При этом заказчику необходимо убедиться, что все его «хотелки» зафиксированы в тех задании.

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

Из чего состоит ТЗ?

Предположим, в рамках проекта требуется составить техническое задание на разработку сайта студии копирайтинга «Перо». Какие пункты оно должно содержать?

Общие сведения (описание)

Здесь указываются:

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

Этапы и сроки реализации проекта. Очень важный момент, как правило, календарный план по всем этапам работ составляют в самом конце. Эта часть даёт понимание, что и когда будет делаться. Например (с указанием дат):

• Подготовительный этап;
• Проработка концепции сайта;
• Проектирование;
• Создание дизайн-макета;
• Разработка дизайна страниц;
• Вёрстка;
• Программирование;
• Наполнение контентом;
• SEO-оптимизация;
• Тестирование;
• Запуск.

Каких-то этапов, например, SEO-продвижения может и не быть. Зависит от целей и задач заказчика и компетенций исполнителя.

Назначение и цели

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

Назначение сайта. Каких целей созданием сайта необходимо достичь? Для чего он нужен, какие задачи решает?

• Реклама и привлечение новых клиентов;
• Поддержка заказчиков и партнёров;
• Демонстрация выполненных работ;
• Ознакомление со списком услуг;
• Создание и поддержание имиджа компании.

Возможно, некоторые пункты стоит расписать более подробно. Например, если перед сайтом стоит задача в том числе и информировать посетителей, то лучше пояснить, о чём именно.

Целевая аудитория. Кто будет пользоваться сайтом, для кого он создаётся?

• Веб-мастера, блогеры;
• Владельцы интернет-магазинов;
• Владельцы информационных порталов;
• Рекламные студии;
• Представители присутствующих в онлайн-пространстве фирм и компаний.

Требования

Большой и крайне важный раздел, в котором учитывается как можно больше моментов проектирования и разработки, потому как за неоговоренный в ТЗ функционал заказчику придётся доплачивать.

Тип. К какой категории принадлежит веб-ресурс?

• Посадочная страница;
• Сайт-визитка;
• Корпоративный сайт;
• Информационный портал;
• Интернет-магазин.

Требования к оформлению. Они могут быть следующего вида:

• Сайт должен быть минималистичным и при этом отражать род деятельности компании.
• Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
• В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
• Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).

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

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

Второй вариант стоит дороже и требует большей квалификации от подрядчика.

Языковые требования. Носители какого языка смогут посещать ресурс? Какие языковые версии сайта должны быть?

• Русский;
• Английский;
• Эсперанто.

Требования к совместимости.

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

Здесь можно перечислить браузеры, с которыми однозначно должен быть совместим ресурс. Обычно на всех современных браузерах сайты отображаются одинаково, бывают только проблемы со старыми версиями Internet explorer.

Требования к CMS. Возможности администрирования сайта определяют, какие именно блоки можно редактировать и настраивать через панель управления, не вмешиваясь в код и не редактируя напрямую базу данных, а используя удобный визуальный интерфейс. Например, можно сформулировать так:

• Возможность изменения контента на страницах сайта;
• Возможность управления страницами (добавление, переименование, удаление и т. д.);
• Возможность редактирования структуры сайта и пунктов меню;
• Функции автоматической обработки графики (создание превью, трансформация под заданный размер и т. п.);
• Возможность прописывать уникальные Мета-теги;
• …

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

Часто заказчик уже имеет опыт работы с одним из популярных CMS, тогда целесообразно искать порядчиков под конкретный движок. Также при выборе CMS лучше не соглашаться на самописные решения, т.к.

в дальнейшем это поставит в зависимость от исполнителя.

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

Структура и навигация. Какие разделы, подразделы и отдельные страницы будет содержать проект?

• Копирайтинг
• Рерайтинг
• SEO-коперайтинг
• Корректура
• Транскрибация
• Контент-менеджмент
• Контент-маркетинг

Сделайте и краткое описание каждой страницы, дайте определения.

Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?

Желательно контент или хотя бы его наброски приготовить еще до начала работ с подрядчиком. Это будет способствовать более эффективной коммуникации.

Дополнительные требования. Всё, что не вошло в другие пункты раздела.

Описание разделов сайта

В этом пункте — детали. Обычно расписывается содержание всех уникальных страниц: какие элементы там будут, как пользователь будет взаимодействовать с ними.

страница. Формулировка задачи может быть в следующем виде.

Основная часть главной страницы должна быть выполнена в виде Landing Page. На ней сверху вниз должны располагаться следующие элементы:

• Шапка — логотип, название фирмы;
• Меню навигации;
• Информация об акциях и скидках;
• Кнопка заказа;
• Рекламный текст;
• Блок с пятью лучшими работами и ссылкой на раздел портфолио;
• Отзывы клиентов;
• Штат студии;
• Блок партнёров компании;
• Информация о тарифах;
• Дублирующий блок скидок и кнопка заказа;
• Карта ссылок;
• Кнопки социальных сетей.

Схема главной страницы. Если есть понимание будущей структуры сайта, то будет нелишним вставить макет, отражающий структуру хотя бы главной страницы. Это может быть нарисованный от руки и отсканированный набросок, созданный в Photoshop макет — что угодно. Также можно использовать программы для прототипирования, который может освоить даже начинающий пользователь.

Внутренние страницы. Аналогичным образом можно отразить и другие страницы сайта. Если в целом они будут похожи друг на друга (например, изменяется только контент главной части страниц), то можно обобщить.

Сюда же можно поместить схемы (или схему) страниц.

Кстати, эти прототипы сделаны с помощью программы Balsamiq Mockups, который довольно прост в освоении.

Описание функциональной части

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

Источник: https://www.seostop.ru/blog/sozdanie-saita/tz.html