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

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

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

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

Заказчик может несколько изменить условия по сравнению с техническим регламентом, ГОСТом или СанПиНом, но только в сторону улучшения характеристик.

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

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

Положения п. 2 ч. 1 ст. 33 Закона № 44-ФЗ не обязывают заказчика абсолютно во всех случаях закупок руководствоваться ГОСТами, стандартами или техническими регламентами. Заказчик использует и обосновывает необходимость использования других показателей, требований, условных обозначений и терминологии только в случае, если законодательством установлены технические регламенты, национальные стандарты и иные требования.

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

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

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

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

1. При составлении документации, описание объекта закупки должно носить объективный характер. То есть четкое и ясное описание того, что именно нужно заказчику, не допускающее двусмысленностей и разночтений. Кроме того, для уточнения отдельных моментов поставщик может подать запрос на разъяснение.
2. Заказчик в описании предмета закупки описывает его функциональные, технические и иные характеристики, которые требуются от поставленного товара (произведенных работ).
3. Техническое задание должно быть нейтральным, не ставить ограничений на количество потенциальных участников путем прописывания чрезмерных требований к поставляемой продукции. Нельзя «подгонять» описание только под один конкретный товар одного производителя. Это является ограничением конкуренции. Единственным исключением тут является ситуация, когда нет другого способа исчерпывающего описания свойств объекта закупки (п.1 ч. 1 ст. 33).
4. Заказчику рекомендуется указывать в техническом задании, что поставляемый товар должен быть новым (который не был в употреблении, в ремонте, в том числе который не был восстановлен, у которого не была осуществлена замена составных частей, не были восстановлены потребительские свойства), иначе заказчик может получить товар, бывший в употреблении.

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

2 голоса

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

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

План действий по работе с заказчиком

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

• Первое общение.

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

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

• Подготовка и первый бриф.

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

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

• Составление и подписание технического задания.

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

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

Однажды мне очень повезло. Прежде чем прийти на встречу клиент изучил вопрос, и сам составил не только грамотное ТЗ, но и художественное задание. То есть литературное и подробное описание как оно все должно выглядеть. Моему удивлению не было предела, на что он ответил: «Я считаю, что заказчик сам в первую очередь должен знать, чего хочет, а не мучать специалистов». К сожалению, это редкость, поэтому нам приходится задавать вопросы, прописывать и утверждать.

• Разработка и прием.

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

Чего не должно быть в ТЗ, а что там быть обязано

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

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

Пусть в вашем ТЗ будет фраза: «Все, что не оговорено выполняется на усмотрение исполнителя». И не обязательно делать эту строчку маленьким шрифтом. Пусть думает заранее, а не начинает мечтать, когда проект уже готов. Конечно же, небольшие изменения вы можете и должны внести. Хорошая репутация – залог будущих клиентов, но иногда заказчик может так достать своими пожеланиями, что жить не захочется.

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

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

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

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

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

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

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

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

Выглядит оно так:

1. Глоссарий
2. Общие положения
3. Предмет разработки
4. Назначение документа
5. Требования к графическому дизайну сайта
6. Требования к дизайну сайта
7. Порядок утверждения дизайн-концепции
8. Функциональные требования
9. Требования к представлению сайта
10. Требования к системе управления сайтом
11. Требования к разделению доступа
12. Требования к видам обеспечения
13. Требования к информационному обеспечению
14. Требования к программному обеспечению
15. Требования к техническому обеспечению
16. Требования к лингвистическому обеспечению
17. Требования к эргономике и технической эстетике
18. Требования к приемке-сдаче проекта
19. Требования к наполнению информацией
20. Требования к персоналу
21. Порядок предоставления дистрибутива
22. Порядок переноса сайта на технические средства заказчика

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

Глоссарий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будьте внимательны. Это важный пункт, в котором лучше написать больше. Например, у вас должен быть раздел «Похожие новости». Что вы будете делать: прописывать алгоритм, который будет вычислять какие статьи наиболее близки по теме, дадите список последних пяти статей, добавленных на сайт, или у автора текста будет возможность вставить ссылки в этот блок самостоятельно?

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

1. Структура сайта: описываем какие категории (рубрики) будут на сайте.
2. Главная страница: лучше всего со схематической картинкой и описанием основных элементов.
3. Внутренние страницы: тоже что и в предыдущем пункте. Схема и описание внутренних страничек.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Тут речь идет о хостинге или серверах. Так как мой блог ориентирован на создателей, которые работают на Таймвебе (https://timeweb.ru ) – все очень просто. Если вы не из «наших», то нужно смотреть на технические характеристики. Например, кто-то очень умный делает крутой сайт, а потом пытается подключить его к хостингу, а технические характеристики настолько завышены, что ни один хостинг в России не справляется. Пункт нужный, но не для новичков в сфере разработки.
2. Здесь мы описываем будет ли портал иметь мобильную версию, адаптирован под портативные устройства или сможет открываться только через Google Chrome, а любые искривления в других браузерах нас вообще не волнуют.

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

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

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

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

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

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

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

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

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

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

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

Что вы отдадите заказчику, когда работа будет выполнена: логин, пароль, туда-сюда.

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/ .

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru .

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

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

СКАЧИВАЕМ ШАБЛОН ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

• описывать объект закупки так, как это предусмотрено КТРУ;
• включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

• общая информация;
• информация о закупаемом объекте;
• требования к поставщикам;
• условия ;
• приложения (допускается по усмотрению заказчика).

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

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

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

• или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
• централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
• привлечение экспертов, порядок их работы.

4. Перечислить сведения о госзакупке:

• способ определения поставщика (ч. 1 ст. 24);
• обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

10. Указать источник финансирования.

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

12. Определить условия госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

21. Определиться, нужны ли монтаж и наладка.

22. Установить порядок поставки и приемки.

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

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

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .

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

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

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

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

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

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

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

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

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

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

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

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

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

Опишите сайт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сроки : до 15.09.2018.

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