Как оформить техзадание. Оформление технического задания в сфере закупок. Техзадание составляет исполнитель

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

Что такое техническое задание

Техническое задание - документ, в котором отражены все требования к будущему продукту. В нем описывают все технические требования. Обычно ТЗ составляют в виде текстового документа, редко - в других форматах.

ТЗ используют все разработчики сайтов. Верстальщикам, программистам, дизайнерам оно помогает лучше понять требования клиента и сделать ресурс, соответствующий его ожиданиям. Кроме того, ТЗ используют во всех других сферах, например - в:

разработке приложений;
проектировании дома;
написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

Определитесь, кто будет составлять техническое задание
Разъясните термины
Откажитесь от субъективных терминов

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

Разъяснение терминов - очень важный момент . Все узкоспециализированные термины желательно объяснить в самом начале - клиенты не всегда знают, что такое подвал (футер), CMS, рыба. Чем проще и понятнее будут объяснения, тем понятнее будет ТЗ для обеих сторон.

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

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

Опишите сайт

Расскажите, какой тип сайта нужен, кем он будет использоваться, для чего он вообще создается. Например, напишите, что вам нужен интернет-магазин, лендинг для продажи товара или сайт-визитка с 10 страницами. Укажите ориентировочное количество страниц, если не знаете точного числа.

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

Расскажите о структуре

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

Схемой
Таблицей
Списком

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

Пример простейшей структуры в виде блок-схемы

Опишите, что будет на каждой из страниц

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

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

Пример прототипа главной страницы сайта: все просто, удобно, понятно

Выдвините требования к дизайну

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

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

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:

На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
Какую программную платформу можно использовать - .NET, OpenGL, DirectX
И так далее

Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

Уточните требования к работе сайта

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

Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

- не меньше 95% по Адвего, Текст.ру, Контент.Вотч
Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
Баллам по Главреду - не менее 6,5 или 7 баллов

Конечно, разные сервисы - не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

Цели и задачи - о том, для чего вообще вы создали ТЗ, что хотите сделать с продуктом
Каким должен быть продукт - описание в общих чертах
Технические требования - площадь дома, объем текста, функционал приложения и так далее
Сроки - они важны, чтобы исключить споры.

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования - ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

Линк
Название статьи
Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы - по 10 на каждой.

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

Сроки : до 15.09.2018.

Естественно, это ТЗ можно улучшить - мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

2. Общее описание

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования

4. Приложения
5. Алфавитный указатель

На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.

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

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
(читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из

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

Чем точнее и корректнее будет составлено ТЗ, тем проще будет и поставщику и самому заказчику.

Техническое задание на закупку должно соответствовать требованиям законодательства. И помимо 44-ФЗ при подготовке ТЗ необходимо учитывать нормативные требования Антимонопольной службы и законодательства о техническом регулировании.

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

Разработка технического задания по 44-ФЗ

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

Совет: стоит помнить, что излишние требования и конкретизация могут противоречить требованиям 44-ФЗ, поэтому всегда стоит следовать его нормам.

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

Совокупность всех составленных технических заданий по 44-ФЗ на закупки напрямую влияет на план закупок и формирует план-график на будущий период. В идеале, заказчик составляя список всех необходимых товаров или услуг, которые будет необходимо получить в следующем периоде, планирует определенные моменты:

в какой форме будут проводиться тендеры;

можно ли объединить некоторые лоты в одну закупку или разумнее будет произвести несколько операций;

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

От всех этих нюансов зависит, как именно будет составлен план закупок и план-график соответственно.

Подготовка технического задания

При подготовке техзадания на закупку, заказчик должен максимально открыто и точно указывать все параметры, чтобы подрядчик смог подготовить качественное предложение, оценив объем и сложность. Очень важно указывать требования в соответствии с 44-ФЗ, не превышая полномочий.

Обычно техническое задание закупки содержит следующие пункты:

описание закупки, т.е. наименование товара, работ или услуг;

технические характеристики объекта торга;

количество и комплектацию, если речь идет о товаре;

сроки поставки или выполнения работ;

требования с гарантии и безопасности;

условия оплаты и поставки;

другие требования не противоречащие условиям, обозначенными в законе;

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

Рассматривая эти конкретные показатели заказчик будет принимать решение о допуске поставщиков к участию в аукционе.

Образец технического задания на закупку

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

Пример технического задания по 44 ФЗ и ответа на него вы можете посмотреть на нашем сайте на странице “Подготовки и подачи заявки” . В данном примере подробно описано, как должно выглядеть ТЗ в тендерной документации заказчика и каким образом должен писать ответ подрядчик. Эта информация будет полезна для всех участников торгов.

ООО МКК "РусТендер"

Материал является собственностью сайт. Любое использование статьи без указания источника - сайт запрещено в соответствии со статьей 1259 ГК РФ

Конкретных требований к ТЗ законодательством не определено (как и не определен образец формы технического задания по 44-ФЗ ), а значит, заказчику стоит очень ответственно подойти к его составлению. Ведь от этого зависит, какой товар поставят, какого качества выполнят работу или окажут услугу. Разберем подробно этапы подготовки ТЗ, а в конце статьи вы сможете скачать пример технического задания по 44-ФЗ (образец).

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

Составление ТЗ состоит из трех этапов.

Этап 1-й, подготовительный.

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

Этап 2-й, основной.

Здесь заказчик:

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

Этап 3-й, заключительный.

На этом этапе ТЗ проходит необходимые согласования в заинтересованных службах заказчика. В случае несогласования — дорабатывается. После согласования вместе с остальной тендерной документацией размещается в ЕИС.

Согласно нормам 44-ФЗ образец технического задания по ГОСТУ заказчику разрабатывать не обязательно. Но на всех последующих этапах, начиная от разработки и подписания документации и заканчивая исполнением контракта, заказчик в большей или меньшей степени обращается к ТЗ. Особую значимость оно приобретает на этапе приемки продукции. Поэтому целесообразно иметь подобный документ и понимать основные правила и принципы его разработки.

Как правило, заказчик разрабатывает такое ТЗ, которое участнику дает полную картину о потребности в конкретной закупке.
Чаще всего оно состоит из следующих разделов.

Общая информация. Здесь указываются исходные данные о закупке и условия заключения контракта, а также используемые термины и сокращения.
Описание объекта закупки. Данный раздел регулируется ст. 33 Закона о контрактной системе и должен содержать полное наименование предмета закупки, качественные, технические и количественные характеристики закупаемых товаров. Здесь также могут прописываться требования к таре и упаковке, безопасности товара, стоимости обслуживания и расходам на эксплуатацию, требования к гарантийному сроку и объему предоставления гарантий качества. В соответствии с требованиями законодательства описание должно быть объективным, не содержать указаний на конкретных производителей. При этом должны быть использованы требования и характеристики техрегламентов и национальных стандартов РФ в отношении объектов закупки. Этот раздел может также содержать спецификации, чертежи, планы, фотографии предмета закупки. Заказчику при описании объекта важно соблюсти требования к ТЗ по 44-ФЗ, а именно соответствие описания статье 33 44-ФЗ, сохранить принцип обеспечения конкуренции. Данный принцип заключается в том, что под конкретное ТЗ можно поставить товар нескольких марок. Также нельзя в одной закупке приобретать технологически и функционально не связанные друг с другом товары (за исключением отдельных случаев).
Требования к поставщику. Могут предъявляться требования о наличии лицензий, разрешений, допусков и т.д.
Место исполнения контракта.
Прочие условия (например, гарантийные обязательства).

Глоссарий

Термин	Описание
	Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц
World wide web (WWW, web, веб)	Единое информационное пространство на базе сети Internet, состоящее из совокупности сайтов. Приставка "веб-" может использоваться для обозначения объектов, ориентированных на использование в WWW или использующих типичные для WWW технологии (например, веб-интерфейс - интерфейс на базе веб-страниц)
HTML-страница (веб-страница, страница)	Основной носитель информации в World ide Web. Особым образом сформатированный файл (набор файлов), просматриваемый с помощью www-браузера как единое целое (без перехода по гиперссылкам)
HTML-теги (теги)	Управляющие коды, посредством которых осуществляется форматирование HTML-страницы
	Активный элемент HTML-страницы, задаваемый специальным тегом. Выделенный фрагмент текста или изображения, позволяющий загрузить другую страницу или выполнить определенное действие
WWW-браузер (браузер)	Клиентская программа, поставляемая третьими сторонами и позволяющая просматривать содержимое HTML-страниц
HTML-форма (форма)	Часть HTML-страницы, предназначенная для взаимодействия с посетителем сайта. Представляет собой набор элементов (текстовых полей, селекторов, выпадающих списков), посредством которых пользователь может ввести какую-либо информацию и отправить ее для обработки на сервере
Поле (поле БД, поле формы)	Структурный элемент, содержащий однотипную информацию, например, текст, дату, числовые значения и т.п.
	Особое поле данных, могущее содержать только одно из двух допустимых значений. Позволяет указать на наличие или отсутствие какого-либо события или свойства объекта
Справочник	Вспомогательная структура данных, содержащая список допустимых значений для какого-либо поля основных форм или БД. Справочники подразделяются на фиксированные (неизменяемые и поставляемые Исполнителем вместе с готовым сайтом) и редактируемые (состав которых может изменяться администратором)
Администратор (менеджер, редактор) сайта	Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн-шаблон страниц
Дизайн веб-сайта	Уникальные для конкретного веб-сайта структура, графическое оформление и способы представления информации
Информационные материалы	Информация о деятельности Заказчика. Может включать графические, текстовые, аудио или видео материалы. Предоставляется Заказчиком
Наполнение (контент)	Совокупность информационного наполнения веб-сайта. Включает тексты, изображения, файлы и т.п. предназначенные для пользователей системы
Элемент наполнения (контента)	Отдельная запись в базе данных, внешнее представление которой зависит от управляющего ей программного модуля (например, в модуле «новостная лента» элементом наполнения является отдельная новость)
Система динамического управления наполнением (контентом) сайта
	Совокупность объектов базы данных, представленная в виде файлов, позволяющая восстановить точную копию структуры исходной базы данных в аналогичной системе управления базами данных
Веб-интерфейс	Совокупность экранов и элементов управления системы, позволяющих пользователю, осуществляющему доступ к системе через веб-браузер, осуществлять поддержку и управление системой.
Шаблона раздела	Ссобым образом размеченный ASCII-файл, определяющий как графическое оформление страниц раздела, так и их макет (раскладку) - взаимное расположение блоков с наполнением раздела
WYSIWYG редактор	Редактор языка HTML, имеющий возможности по работе в текстовом режиме и в режиме WYSIWYG (What You See Is What You Get). В режиме WYSIWYG элементы HTML страницы при редактировании представляются в том же виде, что и при просмотре
	Класс пользователей системы, обладающих определенным набором прав доступа

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

Общие положения

Предмет разработки

Предметом разработки является Интернет-сайт компании ООО «…», с системой динамического управления наполнением на базе веб-интерфейса.
Назначение сайта:
- предоставление информации о компании ООО «…»;
- предоставление информации о деятельности компании ООО «…»;
- т.д.;
- пр.

Цель создания сайта: ... .

Назначение документа

В настоящем документе приводится полный набор требований к реализации сайта компании ООО "".
Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:
1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего Технического Задания.
3. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
4. Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
5. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
6. Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.

Требования к графическому дизайну сайта

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

При разработке сайта должны быть использованы преимущественно светлые стили.
Основные разделы сайта должны быть доступны с первой страницы.
На первой странице не должно быть большого объема текстовой информации.

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

Порядок утверждения дизайн-концепции

Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон.
Если представленная Исполнителем дизайн-концепция удовлетворяет Заказчика, он должен утвердить ее в течение пяти рабочих дней с момента представления. При этом он может направить Исполнителю список частных доработок, не затрагивающих общую структуру страниц и их стилевое решение. Указанные доработки производятся параллельно с разработкой программных модулей сайта. Внесение изменений в дизайн-концепцию после ее приемки допускается только по дополнительному соглашению сторон.
Если представленная концепция не удовлетворяет требованиям Заказчика, последний предоставляет мотивированный отказ от принятия концепции с указанием деталей, которые послужили препятствием для принятия концепции и более четкой формулировкой требований.
В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции. Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней.
Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.

Функциональные требования

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

Требования к представлению главной страницы сайта Главная страница сайта должна содержать графическую часть, навигационное меню сайта, а также контентную область для того, чтобы посетитель сайта с первой страницы мог получить вводную информацию о компании, а также ознакомиться с последними новостями компании.
Контентная область первой страницы должна делиться на следующие разделы:
- вступительная статья о компании со ссылкой «подробнее», ведущей на раздел «О компании»;
- новости - содержит 3 последние новости (анонсы) в формате: дата, заголовок, краткое содержание;
- краткая контактная информация - телефон и e-mail компании;
- вверху страницы отображаются облегченная навигационная панель, которая обеспечивает переход к основным пунктам меню сайта (О компании, Новости и т.д.);

- счетчики и ссылка на страницу обмена ссылками.

Рис. 1. Пример размещения элементов главной страницы.

Графическая оболочка внутренних страниц (общая для всех подразделов)
Графическая оболочка внутренних страниц должна делиться на следующие разделы:
- графическая шапка
- навигационное меню сайта (навигационная панель 2 обеспечивает переход к основным пунктам меню сайта);
- поле поиска - предназначено для выполнения полнотекстового поиска по сайту;
- поле выбора языка - русский\английский;
- ссылка «На главную»;
- навигационная панель по подразделам выбранного раздела сайта;
- поле для отображения контента выбранной страницы сайта;
- внизу страницы - краткая контактная информация - телефон и e-mail компании;
- кнопка «Для печати» - обеспечивает вывод контентной области в виде, отверстанном для печати на листах формата А4;
- кнопка «Задать вопрос» - обеспечивает переход к форме «Задать вопрос».

Рис. 2. Пример размещения элементов внутренних страниц сайта.

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

a. История компании
b. Дипломы и сертификаты
c. Наши партнеры
d. Наши клиенты
e. Наши координаты
f. ...

2. Новости
3. т.д.
4. пр.

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

Общие требования к административной части
Для получения доступа к административной части сайта необходимо указать определенный адрес в строке броузера и пройти авторизацию.
Главная страница административной части должна содержать следующие пункты меню:
- Станицы сайта (в соответствии с первым уровнем структуры сайта):

О компании
- Новости
- т.д.;

Рис. 3. Макет формы главной страницы административной части сайта.

Требования к управлению разделами сайта
Для управления разделами сайта должны быть предусмотрены следующие функции:
- создание подраздела 1 уровня;
- создание подраздела 2 (и далее) уровня;
- редактирование контента страницы;
- удаление раздела;
- перемещение раздела вверх в списке;
- перемещение раздела вниз в списке;
- признак показа (show) или не показа (hide) страницы в клиентской части сайта;
- отображение списка подразделов выбранного уровня.

Управление наполнением сайта
Для управления наполнением сайта должны быть предусмотрены следующие блоки:
1. поле элемента контента, может быть одного из следующих типов:
- строка;
- дата;
- ссылка на файл;
- многострочный текст;
2. элемент контента - состоит из набора полей элемента контента;
3. список элементов контента - состоит из набора элементов контента.

Рис. 4. Поля элемента контента.

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

Рис. 5. Редактор многострочного текста в административной части.

Для каждого элемента контента должен определяться требуемый набор полей. Например, для элемента «Новость» определяется следующий набор полей контента:

Рис. 6. Пример представления элемента контента «Новость» в административной части.

Список элементов контента должен позволять:
. перейти к редактированию полей элемента списка;
. удалить элемент списка;
. определить порядок элементов списка вывода в клиентской части;
. указать признак hide\show.

Рис. 7. Пример представления списка элементов контента в административной части и их отображения в клиентской части.

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

Управление настройками сайта
В состав настроек сайта должны входить:
- e-mail для …;
- т.д.;
- пр.

Дополнительные функции административной части
В состав дополнительных функций административной части должны входить:
- …;

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

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

Требования к видам обеспечения

Требования к информационному обеспечению

Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания (изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS. Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Требования к организации гиперссылок
Все ссылки на сайте должны быть относительными (за исключением внешних).

Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
Объем flash-заставки не должен превышать 300 Kb.

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

Требования к программному обеспечению серверной части
Для функционирования сайта необходимо следующее программное обеспечение:
- Операционная система - Windows XP и Windows Server 2003;
- Веб-сервер - Apache версии не ниже 1.3.26;
- СУБД - MySQL версии не ниже 3.23;
Требования к клиентскому программному обеспечению
Сайт должен быть доступен для полнофункционального просмотра с помощью следующих браузеров:
. MS IE 5.0 и выше;
. Opera 6.0 и выше;
. Mozilla Firefox 1.0;
. Mozilla 1.7.
Сайт должен быть работоспособен (информация, расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и JavaScript.

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

Для функционирования сайта необходимо следующее техническое обеспечение со следующими минимальными характеристиками:
- процессор - Intel Pentium III 1 Ghz;
- оперативная память - 512 Mb RAM;
- жесткий диск - 20 Gb HDD.
- т.д.;
- пр.

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

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

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

Сайт должен быть оптимизирован для просмотра при разрешении 1024*768, 1280*1024 без горизонтальной полосы прокрутки и без пустых (белых) полей для основных типов разрешения.
Элементы управления должны быть сгруппированы однотипно - горизонтально либо вертикально - на всех страницах.
На каждой странице должны отображаться логотип компании и контактная информация.
Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

Требования к приемке-сдаче проекта

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

Общие требования к информационному наполнению
В рамках работ по данному проекту Исполнитель обеспечивает наполнение разделов сайта предоставленными Заказчиком материалами в порядке, указанном в п. 6.1.2.
Исполнитель обеспечивает обработку иллюстраций для приведения их в соответствие с техническими требованиями и HTML-верстку подготовленных материалов. Сканирование, набор и правка-вычитка текстов, ретушь, монтаж, перевод и другие работы могут быть выполнены Исполнителем на основании дополнительного соглашения (после просмотра имеющихся у заказчика материалов).
После сдачи системы в эксплуатацию информационное наполнение разделов, осуществляется на основании договора на поддержку сайта.
Объем текста и количество иллюстраций в других типах разделов определяется предусмотренной настоящим ТЗ структурой данных и уточняется на этапе согласования дизайн-концепции.
Порядок предоставления информационного наполнения
Заказчик предоставляет материалы в электронной форме в zip-архиве, содержащем дерево директорий, соответствующих структуре сайта.
В каждой директории размещается набор документов в формате MS Word - по одному документу на каждый информационный модуль, информационные блоки которого опубликованы в соответствующем разделе. Не допускается размещение текста в виде графических изображений или иных нетекстовых элементов.
Изображения могут быть размещены как в тексте внутри файла, так и в виде отдельного изображения. Однако, в последнем случае текст должен содержать ссылку на изображение в виде указания пути и названия файла изображения.
Для каждого информационного модуля структура документа должна соответствовать шаблонам, предоставляемым Исполнителем до начала этапа предоставления материалов.
Материалы для первоначального наполнения разделов должны быть полностью представлены Исполнителю в сроки, установленные планом-графиком работ. Допускается передача материалов частями, в нескольких zip-файлах, соответствующих приведенным требованиям.
Передача материалов в объеме и формате, соответствующем настоящему ТЗ закрепляется подписанием Акта о передаче информационного наполнения.
Любые изменения информационного наполнения силами Исполнителя после подписания данного Акта допускаются только на основании отдельного соглашения за дополнительную плату.
Информационные материалы, не предоставленные Заказчиком в сроки, установленные планом-графиком работ, размещаются Исполнителем по гарантийному письму Исполнителя в течение 2-х недель после сдачи-приемки проекта. На эту часть информационных материалов также накладываются требования к формату предоставления, изложенные выше.

Требования к персоналу

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

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

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

Порядок переноса сайта на технические средства заказчика

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