Кто пишет тз. Стандарты и шаблоны для тз на разработку по

Глоссарий

Термин

Описание

Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных 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-доступ к веб-серверу и доступ к базе данных сайта.

Подготовка к лабораторной работе

Ознакомиться с лекционным материалом по теме «Модели ЖЦ ПО. Этапы ЖЦ в соответствии с ГОСТ 19.102-77. Постановка задачи» учебной дисциплины «Разработка и стандартизация ПС и ИТ».

1.Изучить соответствующие разделы в изданиях .

Теоретическая часть. Разработка технического задания

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

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

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

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

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

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

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата А4 и A3 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннота­цию и содержание), лист регистрации изменений допускается в документ не включать.

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

1.4. Техническое задание должно содержать следующие разделы:

Введение;

Наименование и область применения;

Основание для разработки;

Назначение разработки;

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

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

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

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

Приложения.

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

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

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

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

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

Организация, утвердившая этот документ, и дата его утверждения;

Наименование и (или) условное обозначение темы разработки.

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

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

Требования к функциональным характеристикам;

Требования к надежности;

Условия эксплуатации;

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

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

Требования к маркировке и упаковке;

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

Специальные требования.

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

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

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

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

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

2.5.6.В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

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

2.7.В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

2.8.В приложениях к техническому заданию при необходимости приводят:

Перечень научно-исследовательских и других работ, обосновывающих разработку;

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

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

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

Примеры разработки технического задания приведены в приложениях Б и В.

Контрольные вопросы

1.Дайте понятие модели жизненного цикла ПО.

2.Приведите этапы разработки программного обеспечения.

3. Что включает в себя постановка задачи и предпроектные исследования?

4. Перечислите функциональные и эксплуатационные требования к программному продукту.

5. Перечислите правила разработки технического задания.

6. Назовите основные разделы технического задания.


Приложение А

Варианты заданий

Лабораторные работы № 1-5 выполняются для одного и того же варианта.

1. Разработать программный модуль «Учет успеваемости студентов». Программный модуль предназначен для оперативного учета успеваемости студентов в сессию деканом, заместителями декана и сотрудниками деканата. Сведения об успеваемости студентов должны храниться в течение всего срока их обучения и использоваться при составлении справок о прослушанных курсах и приложений к диплому.

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

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

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

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

6. Разработать приложение Windows «Калькулятор». Приложение предназначено для любых пользователей и должно содержать все арифметические операции (с соблюдением приоритетов) и желательно (но не обязательно) несколько математических функций.

7. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.

8. Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.

9. Разработать программный модуль «Химчистка». При записи на обслуживание заполняется заявка, в которой указываются ФИО владельца, описание изделия, вид услуги, дата приема заказа и стоимость услуги. После выполнения работ распечатывается квитанция.

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

11. Разработать программный модуль «Картотека автомагазина», предназначенный для использования работниками агентства. В базе содержатся сведения об автомобилях (марка, объем двигателя, дата выпуска и др.). При поступлении заявки на покупку производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.

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

13. Разработать программный модуль «Автокасса», содержащий сведения о наличии свободных мест на автобусные маршруты. В базе должны содержаться сведения о номере рейса, маршруте, водителе, типе автобуса, дате и времени отправления, а также стоимости билетов. При поступлении заявки на билеты программа производит поиск подходящего рейса.

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

15. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.

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

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 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пример работы программы.

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

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

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

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

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

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

Зачем нужно техническое задание?

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

Получите 267 видеоуроков по 1С бесплатно:

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

Тех. задание обязательно должно содержать в себе:

  • цель — задача, которую мы решим, реализуя данное ТЗ;
  • описание — краткое изложение предстоящих доработок;
  • способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие , создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
  • оценка работы — очень важный пункт, описание трудозатрат.

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

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

Примеры и образцы ТЗ для 1С

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

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

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

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

Зачем нужно техзадание?

  • Исполнителю грамотное ТЗ на разработку сайта поможет заранее оценить объём работы, её сложность и стоимость. Понять, справится ли он с такой задачей самостоятельно, или стоит взять помощников. А затем сделать именно то, чего от него ждёт заказчик.
  • Заказчику техзадание даёт уверенность в том, что он задокументировал свои пожелания к будущему сайту, чётко обозначил сроки, в которые должен уложится исполнитель, прописал требования к работе сайта. И если результат окажется неудовлетворительным, можно предъявить обоснованную претензию: «Не соответствует ТЗ!»

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

Ваше пожелание «блог с бесплатными материалами, страницей обо мне и контактами» исполнитель видит так:

Вы думаете, этого достаточно для создания сайта?

Вы получаете готовый сайт, и тут вдруг оказывается, что вы имели в виду вот это:

Нюансы описания очень важны

Чувствуете разницу? Формально здесь неправы обе стороны: вы не добавили подробности, исполнитель о них не спросил. Но он уже получил оплату и готов пропасть вместе с ней, а у вас недоделанный сайт, непредвиденные расходы и полное разочарование в специалистах по созданию сайтов.

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

О чём пишут в техзадании?

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

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

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

  • Для чего и для кого создаётся сайт?
  • Чем он будет наполнен?
  • Как это всё будет функционировать?
  • Кто и как будет работать над проектом, кто за что отвечает?
  • Что будет приниматься на выходе?

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

1. Информация о заказчике, то есть о вас

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

2. Информация о проекте

Что это будет: сайт-визитка, интернет-магазин, корпоративный портал, электронная библиотека?

3. Целевая аудитория сайта

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

Вы решились на собственный сайт, но до сих пор не представляете себе в подробностях, кто ваш клиент? Значит, сейчас самое время составить его детальный портрет.

4. Цели и задачи, которые должен решать сайт для заказчика и для аудитории

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

Указывайте прямое назначение вашего сайта.

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

5. Рамки проекта (основной функционал)

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

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

6. Структура (карта) сайта

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

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

Схема взаимосвязей отдельных частей сайта

У нас в на эту тему есть вебинар «Система контента продающего сайта». И вот о структуре сайта, о взаимосвязи страниц и ссылках между ними мы там подробно рассказываем. Рекомендую! Картинка выше - из материалов этого вебинара.

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

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

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

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

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

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

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

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

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

9. Рабочий функционал сайта

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

Какая форма подписки? Как она выглядит? Как работает? Что за календарь? Показывает ли он только сегодняшнее число или весь последний месяц? Можно в нём листать страницы или нельзя? Этих нюансов исполнитель может не угадать, в итоге вы получите совсем не то, чего хотели. Деньги заплачены, проект соответствует ТЗ (вы же написали «календарь» - вот он), а вам придётся довольствоваться тем, что получилось, хотя это вовсе не то, чего хотелось, или переплачивать за изменения.

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

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

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

10. Описание контента

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

11. Технические требования

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

Пример нашёлся на habrahabr.ru/post/140574/

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

Например, ваш сайт должен:

  • одинаково хорошо смотреться на мониторах разной ширины;
  • адекватно отображаться в разных браузерах (каких именно?);
  • открываться с мобильных устройств (или вы будете разрабатывать отдельную мобильную версию сайта?);
  • уметь противостоять вирусам;
  • иметь встроенный seo-функционал и так далее.

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

В остальном придётся полагаться на совесть исполнителя.

Информация, которую я дала в статье, - мой опыт. Мне приходилось заказывать сайты с нуля и дорабатывать существующие. Первая версия сайта аzconsult.ru - один из самых маленьких проектов, с которыми я работала. Для крупных проектов есть нюансы, но не думаю, что они вам понадобятся.

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

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

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