Техническое задание на технологию. Техническое задание: законодательные требования и сложившаяся практика

От автора : Как написать техническое задание на разработку сайта ? Тема достаточно обширная, и в рамках одной статьи ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, то, что нужно учесть, на что следует обратить внимание при составлении ТЗ, я постараюсь достаточно подробно изложить в данной статье.

Итак, ТЗ

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

Давайте проанализируем такой пример:

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

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

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

Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит ТЗ?

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

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

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

Поехали по пунктам.

Описание сайта

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

для кого – целевую аудиторию сайта :

• потенциальные покупатели
• продавцы продукции (магазины, интернет-магазины)
• сервисные центры
• партнеры (фирмы)
• потребители продукции (тот, кто уже купил)

Для чего нужен сайт :

• Для повышения имиджа компании
• Для увеличения продаж
• Для удобства клиентов

Тип сайта :

• Корпоративный
• Сайт – визитка
• Интернет магазин

Языковые версии :

• Английский
• Русский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам сайта.

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

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

Потенциальные покупатели продукции .

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

Необходимо решить задачи :

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

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

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

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

Теперь перечисляем модули сайта.

Функционал сайта

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

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

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

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

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

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

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

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

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

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

О компании

• история компании
• контакты
• отзывы

Новости

• события
• акции
• новое на сайте

Продукция

• каталог продукции
• релизы
• отзывы о продукции

Сервис

• служба сервиса
• гарантийное обслуживание
• послегарантийное обслуживание

Потребителю

• покупка и доставка
• пользование
• о сервисе

Магазинам и интернет магазинам

• фотографии продукции
• Часто задаваемые вопросы

Сервисным центрам

• Как стать сервисным центром
• Часто задаваемые вопросы

Партнерам

• приглашение к сотрудничеству
• часто задаваемые вопросы

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

Эта часть меняется в зависимости от того, как вы хотите видеть вашу страницу. Может вверху не нужно столько баннеров, возможно вверху нужно указать контакты (адрес, телефон, факс), может в виде иконок «карта сайта», «главная», «контакты». Может, новости Вам слева не нужны, а «акции и релизы» показывать слева.

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть сайта остается неизменной на каждой странице сайта. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал сайта отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

Теперь подробно описываем каждый блок. Например «Новостная лента».

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

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

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению	ГОСТ 34.602.89 Техническое задание на создание автоматизированной системы
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надежности	4.1.4. Требования к надежности
	4. 1.5. Требования к безопасности
	4. 1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4. 1.10. Требования по сохранности информации при авариях
	4. 1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4. 1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4. 1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4. 1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приемки	6. Порядок контроля и приемки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

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

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

• Общие сведения о системе (программе);
• Назначение, цели и задачи системы (программы);
• Требования к системе (функциональные требования, пользовательские требования, требования к системе в целом и тд);
• Требования к видам обеспечения;
• Требования к документированию;
• Стадии и этапы разработки;
• Порядок контроля и приемки системы (программы).

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

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

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

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

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

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

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

Создание информационной системы «Единое окно» должно обеспечить:

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

Создание Системы позволит сократить эксплуатационные затраты в результате повышения эффективности работы ведомства.»

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

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

В данном бизнес-процессе выделяются следующие участники:

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;
• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

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

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

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

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

Требования к документированию

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

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание.

Минимальный пакет документов обычно включает:

• Техническое задание;
• Ведомость эскизного (технического) проекта;
• Пояснительная записка к Техническому проекту;
• Описание организации информационной базы;
• Руководство пользователя;
• Руководство администратора;
• Программа и методика испытаний;
• Протокол приемочных испытаний;
• Акт выполненных работ

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

Стадии и этапы разработки

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

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

Порядок контроля и приемки системы

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

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

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

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

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

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

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

bikeriderlondon / Shutterstock.com

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

В настоящем документе приводится полный набор требований по реализации сайта.

Заказчик и Исполнитель соглашаются

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

1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание (ТЗ), который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего ТЗ.
3. После утверждения ТЗ все предыдущие договоренности теряют силу и действуют только пункты данного ТЗ.
4. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем ТЗ.
5. Исполнитель выполняет только работы, указанные в данном ТЗ.
6. Все что выходит за рамки пунктов данного ТЗ, Заказчиком оплачивается дополнительно, на основании утвержденных сторонами дополнений к данному ТЗ.
7. Исполнитель приступает к выполнению работ по ТЗ, после: письменного утверждения ТЗ, получения всей необходимой информации указанной в ТЗ, получения необходимых материалов заказчика и выполнения пунктов оплаты.
8. Заказчик берет на себя обязательства, по завершению принять работу в течении 3-5 рабочих дней, оплатить работы по данному ТЗ в указанные в нем сроки, в случае если работы выполнены в полном объеме и в соответствии с ТЗ.
9. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем ТЗ.
10. Все работы по созданию сайта ведется на собственном хостинге Исполнителя. После завершения всех работ, переносится на реальный сервер для тестирования.
11. По окончанию работ, Исполнитель предоставляет консультации по администрированию в течение 5 рабочих дней, но не более получаса в день. Дополнительное время оплачивается отдельно, согласно действующих тарифов Исполнителя.
12. Все неоднозначности, выявленные в настоящем ТЗ после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и оцениваются соответствующим образом.
13. Положения данного документа являются обязательными для разработчиков после его утверждения в установленном порядке.
14. ТЗ является средством верификации выполненных работ.

Статья по теме: Как подключить Яндекс.Спеллер к WordPress

Совместимость с браузерами

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

• Internet Explorer (версия 8 и выше);
• Mozilla Firefox (версия 3 и выше);
• Google Chrome (версия 4 и выше);
• Opera (версия 10 и выше).

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

Текст должен быть читаем. Согласно статистике, минимальное экранное разрешение мониторов пользователей составляет 1024×768 пикселей. При таком разрешении все тексты на сайте должны выглядеть понятно и хорошо видны без использования горизонтальной полосы прокрутки. При разрешении, меньшем, чем 1024×768 появится горизонтальная полоса прокрутки.

Сайт также должен иметь ограничения и на максимальный размер, чтобы хорошо выглядеть на мониторах с высоким разрешением. Поэтому максимальная ширина сайта будет 1280×1024.

Требования к изменению содержимого сайта

Для удаленного администрирования (добавления, редактирования и удаления текстовой и графической информации) может использоваться бесплатная система управления контентом сайта (CMS), например WordPress. Но можно использовать и UMI.CMS (она более удобна пользователю для редактирования сайта, но сложнее для разработчика). Поэтому, если Заказчик пожелает использовать UMI.CMS, стоимость внедрения оговаривается отдельно, после утверждения дизайна. Ориентировочно она будет дороже на 50% от стоимости программирования.

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

Резюме

От того насколько подробно вы опишите задачи, стоящие перед разработчиком сайта, настолько проще будет сдавать проект. Вплоть до того что написать как открывается картинка во всплывающем окне, в какой она будет рамочке и будет ли она открываться с каим-то дополнительным эффектом. Так как очень часто заказчики, еще при создании сайта норовят вносить правки в текст, картинки и тому подобное, что собственно относится к совершенно другому этапу, который называется «Наполнение сайта» или «Обновление сайта».

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

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

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

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях (благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

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

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много - выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

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

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса? » или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

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

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

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

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело (и грамотно) составленное ТЗ определяет успех всей работы. Именно ТЗ согласовывается с Заказчиком, который обычно стремится внести как можно больше противоречивых и завышенных требований. Задача же Исполнителя – наоборот, облегчить себе жизнь. Но после того, как подписи с обеих сторон поставлены, переигрывать что-либо поздно.

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

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:

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

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

Раздел: Наименование и область применения

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

В разделе Основание для разработки должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

Например, Применительно к специфике учебного процесса основанием может служить задание на курсовое проектирование, приказ по институту от __.__. за N ___., договор __.__. за N ___., и т.п.

Раздел: Назначение разработки

В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное – четко определить, для чего нужна эта программа.

Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.

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

В этом разделе должны содержаться следующие подразделы:

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

Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.

Раздел:Требования к функциональным характеристикам.

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

Например : Программа должна позволять … вычислять … строить… создавать …

Исходные данные: текстовый файл с заданной …

Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.

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

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

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

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

С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.

Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".

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

Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.

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

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

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

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

Здесь описываются стандартные этапы. Главное – грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.

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

Эскизный проект. На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатывается общее описание алгоритма, сам алгоритм, структура программы. Разрабатываются план мероприятий по разработке и внедрению программы.

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

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

Oтекст программы;

Oописание программы;

Oпрограмма и методика испытаний;

Oописание применения;

Oруководство пользователя.

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

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

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

Oтехнико-экономические показатели;

Oструктура программы;

Oформат представления входных данных программы;

Oобщая схема алгоритма (2 листа);
oосновные вычислительные алгоритмы;
oпример работы программы.

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

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

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

Другие источники разработки.