Глоссарий
Термин |
Описание |
Информационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных 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.201-78?
Создан 15.02.2010 15:50:53
Примечание от 11.06.2014 г. - Уважаемые дамы и господа! Наверное, в каждом втором-третьем из ваших технических заданий на программы, тем или иным образом оказавшихся в руках автора, содержатся аутентичные тексты из настоящей статьи. Это здорово и чертовски приятно, но следует учитывать тот факт, что прошло почти десятилетие с момента первой статьи, а за это время многое изменилось, особенно в части. Из песни, конечно, слов не выкинешь, но настройтесь на креатив и выдумывайте какие-нибудь более современные ее аранжировки. И не забывайте о том, что это , а не «» документ.
Техническое задание в соответствии с на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения листа. Номера листов (страниц) проставляются в верхней части листа над [из п. 1.1 ГОСТ 19.201-78]
Лист утверждения и титульный лист
Лист и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (и), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]
Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.
Изменения и дополнения
Для внесения или дополнений в техническое задание на последующих или выпускают дополнение к нему. и дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]
Учесть все детали на начальных невозможно, поэтому на практике указанный подход применяется весьма часто. В «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие:
- введение;
- основания для;
- назначение разработки;
- к или;
- требования к;
- технико-экономические показатели;
- порядок и;
- в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]
Любые манипуляции с разделами - строго по с.
Отдельные подразделы технического задания могут подействовать на условного заказчика, как красная тряпка на быка. Заказчика, даже условного, раздражать не следует. В спорных подразделах будут рассмотрены пути поиска компромиссных решений. Ключевые позиции, в которых уступка заказчику равносильна затягиванию петли на шее исполнителя, будут также откомментированы с обоснованием жесткой позиции исполнителя.
Чтобы излишне не отягощать ход повествования, в качестве будем использовать реальную программу с, обеспечивающую возможность выполнения нескольких шаблонных функций. Пусть такой программой станет несложный.
Введение
В разделе «Введение» указывают, краткую характеристику области применения или и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]
Основное правило работы с – детализация, дробление текста на структурные единицы, - разделы, подразделы, пункты и подпункты, см. статью «» документа будет иметь четкую структуру, способствующую легкому требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование программы – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. документ можно будет в ходе технического задания с заказчиком.
Основания для разработки
В разделе «Основания для разработки» должны быть указаны:
- документ (документы), на основании которых ведется разработка;
- , этот документ, и дата его утверждения;
- и (или) условное обозначение темы разработки.
[из п. 2.2 ГОСТ 19.201-78]
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.
Удобно воспользоваться разделом «Общие сведения» , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.
Наименование и условное обозначение темы разработки
Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»
Назначение разработки
В разделе «Назначение разработки» должно быть указано и эксплуатационное назначение или [из п. 2.3 ГОСТ 19.201-78]
Функциональное назначение
Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.
В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т.д. – будут приведены ниже, в соответствующих разделах.
Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?
Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.
Применим формальный подход:
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика. должны являться сотрудники профильных подразделений объектов заказчика.
Два крайних предложения - не в тему. При проведении переговоров с реальным заказчиком подраздел будет откорректирован.
Требования к программе или программному изделию
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
- требования к функциональным характеристикам;
- требования к;
- требования к составу и параметрам;
- требования к и;
- требования к и;
- требования к и;
- специальные требования.
[из п. 2.4 ГОСТ 19.201-78]
Если существуют стандарты, содержащие общие (технические) требования к программе, или, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
- функции создания нового (пустого) файла;
- функции открытия (загрузки) существующего файла;
- функции редактирования открытого (далее - текущего) файла путем ввода, содержимого файла с применением стандартных;
- функции редактирования текущего файла с применением;
- функции файла с исходным;
- функции сохранения файла с именем, отличным от исходного;
- функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы;
- функции вывода оперативных справок в (подсказок);
- функции;
- функции отображения названия программы, версии программы, копирайта и комментариев разработчика.
Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая. Применение клише - шаблонного построения фраз - детально расписано в статье «».
Требования к организации входных данных
программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC... Файлы указанного формата должны размещаться () на локальных или съемных, согласно требованиям операционной системы.
Любой иного, но с расширением rtf, открываться не должен.
Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного, отформатированного, к примеру, в формате ext3, открываться не должны.
Требования к организации выходных данных
Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания.
Требования к временным характеристикам
Требования к временным характеристикам программы не предъявляются.
Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. формулировку выше.
Требования к надежности
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению функционирования (обеспечения, контроль входной и выходной информации, после и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]
– штука тонкая и очень опасная. Но перечень функций и видов их, согласно п. 1.3.2. , обязан составить заказчик и согласовать с исполнителем.
Скорее всего, дождаться от заказчика чего-либо вразумительного не удастся. Стоит разъяснить заказчику, что надежное функционирование программы зависит не столько от исполнителя, сколько от надежности технических средств и, а также предложить заказчику ряд жестких мер для повышения и.
Требования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
- организацией бесперебойного питания технических средств;
- использованием программного обеспечения;
- регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
- регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие.
К списку можно добавить еще несколько десятков. В ходе первичного согласования технического задания заказчик, скорее всего, начнет проявлять склонность к компромиссу.
Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст, считаются выполненными.
Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу:
Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.
Время восстановления после отказа
Вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать стольких-то минут при условии соблюдения технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение технических средств и переустановки программных средств.
Перечень аварийных ситуаций ситуаций также составляет заказчик и согласовывает с исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.
Отказы из-за некорректных действий оператора
Отказы программы возможны вследствие при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных.
Условия эксплуатации
В подразделе «Условия эксплуатации» должны быть указаны (, относительная влажность и т.п. для выбранных типов), при которых должны обеспечиваться заданные характеристики, а также, необходимое количество и персонала [из п. 2.4.3 ГОСТ 19.201-78]
Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания.
Климатические условия эксплуатации
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести в полном объеме за счет исполнителя.
Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!
Примечание от 10.02.2011 г. - По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее - провели разработку программы и методики испытаний на воздействие внешних факторов , по и подготовили, открыв для себя еще одно. Не зря говорят, что история развивается по восходящей спирали...
Требования к видам обслуживания
Программа не требует проведения каких-либо видов.
Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования».
Если заказчик в ходе согласования технического задания сошлется на отсутствие или желание проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на за отдельные деньги отдельным договором. Откажется – следует считать программу.
Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и пользователь программы – оператор.
Системный администратор должен иметь высшее профильное образование и компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
- задача поддержания технических средств;
- задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
- задача установки (инсталляции) программы.
Пользователь программы (оператор) должен обладать практическими навыками работы с операционной системы.
Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
При отсутствии самой ключевой фразы в утвержденном техническом задании заказчик вправе затребовать от исполнителя разработку руководства по эксплуатации графического пользовательского интерфейса операционной системы, мотивируя тем, что оператор «не справляется» с программой.
Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к и конторскому оборудованию.
Требования к составу и параметрам технических средств
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]
Следует подбирать не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере.
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
- процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
- материнскую плату с FSB, ГГц - 5, не менее;
- оперативную память объемом, Тб - 10, не менее;
- и так далее…
Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и решения, и, используемым программой.
При необходимости должна обеспечиваться и [из п. 2.4.5 ГОСТ 19.201-78]
Требования к информационным структурам и методам решения
Иформационная структура файла должна включать в себя текст, содержащий, предусмотренную спецификацией формата rtf.
Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.
Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на C++. В качестве интегрированной программы должна быть использована среда Borland C++ Buider.
Требования к программным средствам, используемым программой
Используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Допускается применение пакета обновления такого-то.
Требования к защите информации и программ
Требования к и программ не предъявляются.
Подобных требований следует избегать, если нет особого желания разработать что-то вроде концепции обеспечения информационной безопасности согласно Обеспечить некоторый уровень и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет.
Требования к маркировке и упаковке
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]
Программа поставляется в виде программного изделия - на дистрибутивном (внешнем) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного.
Требование к маркировке
Программное изделие должно иметь маркировку с обозначением компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.
Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).
Требования к упаковке
Упаковка программного изделия должна осуществляться в упаковочную тару ().
Именно предприятия-изготовителя (поставщика). Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель (поставщик) тары.
Условия упаковывания
Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.
Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия (по) в ненадлежащем виде (наличие царапин, трещин и прочих) исполнитель сможет предъявить претензии в части нарушения заказчиком условий упаковывания и не принять программное изделие.
Порядок упаковки
Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.
Программное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей (силикагеля).
Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.
должна быть уложены в потребительскую тару вместе с программным изделием.
На верхний слой прокладочного материала укладывается - упаковочный лист и ведомость упаковки.
Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.
Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.
В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.
Габариты грузового места должны быть не более 1250 820 1180 мм.
Масса НЕТТО - не более 200 кг.
Масса БРУТТО - не более 220 кг.
Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб, но требования есть и остаются требованиями.
Требования к транспортированию и хранению
В подразделе «Требования к транспортированию и хранению» должны быть указаны для условия, места, условия хранения, условия складирования, в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]
В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Выглядит несколько необычно в контексте программного изделия.
Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения.
Условия транспортирования и хранения
Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.
При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания и. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:
- температура окружающего воздуха, °С - от плюс 5 до плюс 50;
- , кПа - такое-то;
- относительная влажность воздуха при 25 °С - такая-то.
Специальные требования
Программа должна обеспечивать взаимодействие с пользователем () посредством, разработанного согласно рекомендациям компании-производителя операционной системы.
Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.
Требования к программной документации
В разделе «Требования к программной документации» должен быть указан предварительный состав и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]
Предварительный состав программной документации
В состав программной документации должны входить:
Программа и методика испытаний потребуется, чтобы показать заказчику, что разработанная исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний заказчик и исполнитель подпишут. И, тем самым, работа будет закрыта, условия договора выполнены.
Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]
Но тем, кто впервые занялся разработкой программной документации, лучше придерживаться принципа «мухи отдельно, котлеты отдельно».
Технико-экономические показатели
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]
Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.
Положим, заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.
Экономические преимущества разработки
Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:
число рабочих мест | разработка | экономические преимущества |
|
Виды испытаний
должны проводиться на объекте заказчика в сроки…
Приемосдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) исполнителем и согласованной заказчиком «Программы и методики испытаний».
Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в.
Общие требования к приемке работы
На основании протокола испытаний исполнитель совместно с заказчиком акт приемки-сдачи программы в эксплуатацию.
Приложения
В приложениях к техническому заданию, при необходимости, приводят:
- перечень и других работ, обосновывающих разработку;
- схемы, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
- другие источники разработки.
[из п. 2.8 ГОСТ 19.201-78]
Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Например:
- ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению;
- и так далее..
Выводы
Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.
Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма, и т.д. Указанные сведения должны быть отражены в Договоре.
Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
Как составить техническое задание на разработку сайта, чтобы не переделывать сайт заново? На самом деле у заказчика и исполнителя всегда существует вероятность неправильно понять друг друга.
К примеру, у клиента в голове появилось определенное представление, каким бы он хотел видеть сайт, и пытается объяснить это разработчикам. Но разработчики неверно трактовали «на пальцах» пожелания. Плачевный итог – клиент получил совсем не то, что представлял себе. Силы, время исполнителей и клиента были потрачены зря.
В этой статье вы узнаете, как правильно составить техническое задание на создание сайта, чтобы все остались довольны проделанной работой.
Что такое техническое задание
Техническое задание (ТЗ) – документ, содержащий требования заказчика к сайту. Заказчик и исполнитель должны правильно понимать друг друга, поэтому лучше подробно расписать все требования. Четко составленное ТЗ увеличивает шансы того, что заказчик будет доволен получившимся результатом, а исполнитель не будет переделывать ресурс 2-3 раза.
В хорошо составленном техническом задании четко указаны структура, функционал и все элементы. Если заказчик захочет изменить какую-то поставленную задачу, то вы можете смело отказать ему, ссылаясь на то, что в техническом задании такой пункт не прописан.
Техзадание может составить и заказчик, но все же у веб-студии опыта гораздо больше. При этом заказчик должен принимать участие в процессе составления ТЗ. Лучше всего, если будет заполнен опросный лист со следующими моментами:
- Рассказать подробнее о компании, предлагаемых товарах или услугах, целевой аудитории;
- Уточнить о проблемах, с которыми целевая аудитория (ЦА) будет приходить к клиенту и их решения;
- Узнать, что именно клиент хочет получить от сайта;
- Попросить привести примеры удачных сайтов конкурентов.
Важно также учитывать на этапе подготовки ТЗ, так как это поможет сделать продукт для целевой аудитории в первую очередь, а не «для себя».
Чёткость формулировок в ТЗ
Забудьте о прилагательных красивый, инновационный, современный, надежный, длительный. Ведь у каждого человека свои представления значения этих слов. Для кого-то красивым будет сайт с обилием анимаций и ярких цветов, другой же сочтёт за красоту минимализм.
Главный критерий качества ТЗ - чёткие формулировки, отсутствие двусмысленных трактовок.
Конкретика в техническом задании - главное условие качества, например:
- Каждая страница должна провериться на GTmetrix или GoogleSpeed с показателем скорости не менее 80/100 по Google Page Speed.
- Ресурс должен выдерживать до 20 тыс. посетителей одновременно.
- На главной должны выводиться новости и ниже отображаться форма с кнопкой «Подписаться» с возможностью отправить e-mail адрес.
- Список партнеров в виде карусели логотипов, отзывы клиентов в слайдере с горизонтальной прокруткой по 1-му отзыву на слайд.
Обязательно согласуйте с клиентом инструменты, которые будут использоваться, движки и требования к хостингу. Пропишите в своём ТЗ, что ваш ресурс должен работать во всех браузерах, быть адаптивным для всех видов устройств, должен быть устойчив к нагрузкам и защищен от хакерских DDoS атак.
Структура сайта – фундамент. Решите, какие страницы необходимо создать и продумайте навигацию на них. По нашему опыту клиент проще воспринимает блок-схему, нарисованную в XMind. Но если вы считаете, что работа в XMind займет слишком много времени, то просто перечислите секции в word файле. Кстати, не лишним будет предварительно собрать , которое поможет в определении структуры и разделов на основании реальных запросов потенциальных клиентов в вашем сегменте.
Пример структуры ТЗ по договору
Данные формулировки подходят для преамбулы приложения по техническому заданию к договору услуг. Важно прописать структуру, блоки и элементы, чтобы обозначить рамки работ и понять итоговую стоимость. Ниже пример составления структуры для ТЗ.
Страница «Главная»
- Секция «Меню» с разделами и выпадающим списком подразделов:
- Логотип и слоган;
- «Главная»;
- «Проекты»;
- «Каталог продукции» с выпадающим списком разделов «Трубы SML», «Фитинги SML», «Соединительные хомуты»;
- «Производство»;
- «О компании»;
- «Проектировщикам»
- «База знаний / FAQ»;
- «Контакты»;
- Ссылка на скачивание катала продукции в.pdf;
- Контактный телефон компании;
- Кнопка «Заказать звонок».
- Секция «Слайдер» с фотографией по ширине экрана и кнопкой обратной связи с запросом на просчёт проекта / запроса на полный прайс-лист продукции.
- Секция «Преимущества» с указанием ключевых выгод для клиентов;
- Секция «Производство» с кратким описанием и информацией про систему контроля качества, со ссылкой на раздел «Производство» и кнопкой с записью на поездку на завод;
- Секция «Продукция» с текстовым описанием преимуществ, ссылками на сертификаты, ссылкой на «Каталог продукции»;
- Секция «Наши проекты» (с переходом в раздел «Все проекты»);
- Секция «Компания в цифрах» с цифрами достижений и ссылкой на раздел «О компании»;
- Секция «Видео-инструкции» с текстовым описанием и ссылкой в раздел «Все видео»;
- Секция «Подвал»:
- Контакты, телефон, адрес, электронная почта;
- Кнопка обратной связи;
- Ссылка на YouTube канал и на социальные сети компании.
Если вы также заказываете уникальный дизайн, то структуру страниц можно строить по предварительному прототипу. Ниже пример прототипа сайта, который можно прикрепить к техническому заданию на разработку. Определите вид главной страницы. Решите, где будет заголовок, пропишите основные элементы, на чём сделать акцент и так далее.
Функционал сайта
Функционал - отдельная история. Если вы хотите получить гибкий и функциональный сайт, который можно легко поддерживать в будущем, то обязательно пропишите в техническом задании технические аспекты проекта. В противном случае вы рискуете получить просто набор строчек когда, который может поддерживаться только программистом в штате. Что относится к функционалу:
- CMS система Вордпресс, Битрикс и тп.
- Формы заявок с возможностью оставить заявку
- Модальные окна
- Слайдеры
- Модули галереи
- Модули SEO оптимизации и страниц
- Модули кеширования и сжатия
- Онлайн-карта с гео-метками
- с расчетом цены
К технической части относятся требования хостингу и его настройкам. Советуем выбирать проверенный и быстрого хостинг-провайдера с приемлемыми тарифами на обслуживание. Мы используем в проектах вот этот хостинг. Стоимость всего 2500 в год, домен в зоне.ru можно купить за 179 руб. Вот пример функционального описания для технического задания.
Подключение и настройка CMS системы 1С Битрикс | Исполнитель настраивает CMS систему управления сайтом 1С Битрикс. Лицензия «1С-Битрикс: Управление сайтом» оплачивается Заказчиком самостоятельно. |
Наполнение контентом | Наполнение текстом и фотографиями указанных выше страниц. Текст и фотографии предоставляет Заказчик. Исполнитель в праве использовать также контент с сайта заказчика. Расположение блоков на страницах выводится в рамках структуры страниц шаблона. |
Настройка ролей доступа | Добавление роли «Администратор» с возможностью администрирования CMS, роли редактора (для отдела закупок) с возможностью добавления информации. |
Адаптация для мобильных устройств и планшетов | Широкоэкранная верстка и адаптация под более мелкие разрешения экрана, сайт должен корректно отображаться на экранах шириной от 1920 до 320 пикселей, появление горизонтальной прокрутки недопустимо. |
Подключение дополнительных модулей CMS | Исполнитель также вправе добавлять модули CMS и функциональные элементы на своё усмотрение, если они улучшают работоспособность сайта по согласованию с Заказчиком, платные модули оплачиваются Заказчиком. |
Подключение домена и хостинга Заказчика | Исполнитель подключает домен и хостинг Заказчика для веб-сайта. Производится парковка домена с указанием адресов ns1, ns2. Включается версия PHP не ниже 7.0. |
Настройка базы данных MySQL | Исполнитель создает базу данных MySQL на хостинге заказчика для размещения данных веб-сайта. Доступы к базе данных передаются Исполнителем Заказчику по электронной почте. |
Видеофон на главной странице | Вывод подложки с видеорядом Заказчика в первом блоке главной страницы сайта. Должна присутствовать затемняющая подложка для повышения читабельности текста. |
Вывод модальных окон и отправка данных | Каждая из кнопок должна вызывать соответствующее модальное окно с формой обратной связи. Данные с формы в корректном виде должны отправляться на почту Заказчика. |
Вывод форм обратной связи | Форма обратной связи должна выводиться на каждой странице. В форме обратной связи должны присутствовать: форма поля ввода номера телефона и кнопка «отправить заявку». Данные с формы должны передаваться на электронный адрес администратора, а также дублироваться на адрес [email protected]. |
Подключение Яндекс карты c ГЕО-метками | На страницах выводится Яндекс.Карта с ГЕО меткой расположения / адреса Заказчика. Заказчик устанавливает метку на собственном аккаунте Яндекс. |
Подключение статистики Яндекс.Метрика | Сервис сбора данных о посещаемости и поведении пользователей. Заказчик предоставляет Яндекс почту, на которую Исполнитель подключает сервис. |
Настройка целей в Яндекс.Метрика | Исполнитель настраивает цели в Яндекс.Метрика. Цели сообщают в статистике о том, с какой конкретно формы была отправлена заявка. |
Вывод H1 и МЕТА-описаний страниц согласно ключевому запросу веб-страницы | Каждая страница веб-сайта должна иметь заголовок и МЕТА-описание в соответствии с содержимым страницы. |
Кроссбраузерная оптимизация сайта | Сайт должен корректно открываться в последних актуальных версиях существующих браузеров. |
Настройка файлов sitemap.xml | Исполнитель выводит карту сайта в отдельный раздел sitemap.xml с указанием существующих страниц для индексации. |
Добавление «хлебных крошек» | Исполнитель выводит в каждый раздел навигационную цепочку («хлебные крошки», англ. Breadcrumbs) с адресом страницы формата: Главная → Раздел → Подраздел → Текущая страница. |
Настройка файла robots.txt | Исполнитель настраивает текстовый файл, который содержит параметры индексирования сайта для роботов поисковых систем. |
Настройка файла.htaccess | Исполнитель настраивает специальный файл, позволяющий редактировать конфигурации и настройки веб-сервера. |
Настройка ЧПУ адресов страниц в формате domen.ru/arenda-sklada | Адрес каждой страницы должен содержать корректное описание для поисковых систем и посетителей на латинице. |
Настройка 404 и 303 страниц | Настройка корректной выдачи ошибки 404, настройка 303 переадресации на страницы, которые изменили свой адрес. |
Оптимизация программного кода HTML/CSS/PHP и скриптов | Исполнитель выполняет оптимизацию программного кода страниц сайта для повышения скорости загрузки страниц и веб-сайта в целом. При необходимости Исполнитель переносит загрузку.js скриптов в «подвал» сайта, настраивает кеширование страниц и сжатие CSS / HTML. |
Оптимизация размера изображений и графического контента | Исполнитель сжимает изображения и видео, размещаемые на страницах веб-сайта для повышения скорости загрузки страниц ресурса. |
Тестирование и поддержка в течение 1-го месяца после запуска | После приемки и запуска веб-сайта Исполнитель оказывает услуги по технической поддержке, устраняет технические ошибки и корректирует работу сайта при необходимости. |
Отдельно.
Помните, что сайт - это техническое и программное обрамление контента. Если контент (фото и видео) не очень, то и сайт будет таким же.
Отдельно стоит уделить внимание качеству фото и видео. Мы всегда рекомендуем заказать фото и видео съёмку клиентам, если нет презентабельного фото и видео контента для сайта.
Что относится к оформлению: оформление кнопок и элементов взаимодействия - ссылки, кликабельные стрелки слайдера, формы заявок и так далее. Продумайте цветовую гамму и пропишите гарнитуры шрифтов. У вас есть брендбук? Отлично, вы можете взять из него основные цвета и стили шрифтов для заголовков и основного текста и прописать всё это в техническом задании. Помните, что хорошее оформление зависит от качества исходного контента. Если у вас будут неказистые фото, то красивые кнопочки не помогут.
Кстати, многие клиенты путают понятие оформления и дизайна. Дизайн - это структура страниц от слова design (проектировать). Дизайн страниц должен содержать ключевые блоки и элементы, которые они содержат. Дизайн - это логика построения страниц.
Структура технического задания
Итак, что должно содержать в себе хорошее техническое задание, которое обезопасит вас от недопонимания с исполнителем. Вот перечень:
- Общая концепция.
- Структура сайта и страниц.
- Требования к хостингу.
- Прототипы страниц.
- Требования к вёрстке и работоспособности.
- Функциональная часть.
- Требования к дизайну и контенту.
Вы можете сами продолжить этот список, ведь каждый проект индивидуальный. Сайт компании всегда зависит от особенностей самого бизнеса и должен передавать его суть через контент и функциональные элементы. Узнайте также, который способен повысить прибыль компании и узнаваемость бренда?
Если вам нужен новый сайт, то вы можете создание сайта или технического задания в нашей веб-студии.
Павел Молянов
Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.
В этом гайде я расскажу, что и зачем нужно писать в техзадании. Заодно покажу, как писать не надо, чтобы создание ТЗ не обернулось потраченным впустую временем.
Статья будет полезна:
- Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
- Менеджерам проектов.
- Руководителям диджитал-студий.
- Предпринимателям, которые планируют заказать разработку сайта.
Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.
Что такое техзадание и зачем оно нужно
Техническое задание - это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.
Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента:
- Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
- Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
- Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
- Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
- Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.
Польза для исполнителя:
- Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
- Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
- Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
- Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.
- Облегчить и ускорить процесс разработки . В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Когда все требования уже перед глазами - остается только задизайнить и написать код.
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Техзадание составляет исполнитель
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Пишите однозначно и точно
Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое - с невнятными формулировками, которые ничего сами по себе не значат:
- Сайт должен понравиться заказчику. А если у него будет плохое настроение?
- Сайт должен быть удобным. Что это значит? Удобным для чего?
- Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
- Качественный экспертный контент. Ну, вы поняли.
Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:
- Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
- Большие нагрузки → 50 тысяч посетителей одновременно.
- На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
- Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.
С формулировками разобрались, давайте пробежимся по структуре.
Укажите общую информацию
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.
Поясните сложные термины
Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».
Опишите инструменты и требования к хостингу
Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»
Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.
Перечислите требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Укажите структуру сайта
До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.
Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.
Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.
Объясните, что будет на каждой странице
Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.
Прототип - более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Распишите сценарии использования сайта
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
- Действие пользователя.
- Ответное действие сайта.
- Результат.
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.
Подробнее о сценариях использования читайте в «Википедии ».
Определите, кто отвечает за контент
Одни разработчики делают сайт сразу с контентом. Другие ставят рыбу. Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Опишите дизайн (если сможете)
Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Вместо вывода: структура техзадания
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
- Информация о компании и целевой аудитории, цели и задачи сайта.
- Глоссарий терминов, которые могут быть непонятны клиенту.
- Технические требования к верстке и работе сайта.
- Описание используемых технологий и список требований к хостингу.
- Подробная структура сайта.
- Прототипы страниц или описания элементов, которые должны на них быть.
- Сценарии использования нестандартного интерфейса (опционально).
- Список контента, который делает разработчик.
- Требования к дизайну (опционально).
- Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
- Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.
Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.
Комментарии разработчиков
Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
В первую очередь ТЗ нужно клиенту - чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так - он может сослаться на ТЗ и попросить переделать.
ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Мы указываем:
- Информацию о компании и цель сайта.
- Требования к дизайну, цветовую гамму.
- Используемые технологии и CMS.
- Кто занимается контентом - мы или клиент.
- Структуру сайта вплоть до каждой страницы.
- Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.
Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.