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

Образцы технических заданий. Как правильно составить техническое задание

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

Техническое задание – что это такое?

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

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

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

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

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

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

Зачем техническое задание исполнителю?

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

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

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

Начало составления документа

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

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

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

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

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

Ответственность и отчетность

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

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

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

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

Любое техническое задание (на поставку, строительство, транспортировку и т. д.) необходимо очень грамотно и качественно оформлять. Это нужно, во-первых, для того, чтобы в дальнейшем не возникало судебных разбирательств, споров и конфликтов из-за недопонимания сторон. А во-вторых, для простого удобства. Грамотно оформить техническое задание способен далеко не каждый заказчик. Зачастую для этого дела нанимаются юристы, хотя в этом и нет особого смысла.

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

Советы по написанию

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

Стоит напомнить и о том, насколько важно сверяться с нормами: будь то ГОСТ, нормативные или правовые акты, локальные акты и т. д.

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

Для чего нужно техническое задание?

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

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

Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.

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

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

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

Как составить техническое задание

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

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

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

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

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

• Введение;
• Основания для разработки;
• Назначение разработки;
• Требования к программе или программному изделию;
• Требования к программной документации;
• Технико-экономические показатели;
• Стадии и этапы разработки;
• Порядок контроля и приемки;
• Приложения.

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

Текст технического задания строится по структуре:

• Общие сведения;
• Назначение и цели создания (развития) системы;
• Характеристика объектов автоматизации;
• Требования к системе;
• Состав и содержание работ по созданию системы;
• Порядок контроля и приемки системы;
• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• Требования к документированию;
• Источники разработки.

Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.

ISO/IEC/IEEE 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Порядок документирования требований

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

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

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

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

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

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

Виджет обратного звонка для сайта

• Повысьте конверсию сайта на 30%.
• Экономьте на тарифах: от 5 рублей в минуту.
• Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
• Используйте гибкие настройки показа.
• Стройте отчеты по звонкам: от показа виджета до ключевого слова.

Технико-коммерческое предложение

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

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

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

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

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

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

Техническое задание

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

Технический проект

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

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

Эксплуатация

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

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

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

Рекомендации по составлению ТЗ

Ведите историю правок

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

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.

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

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

Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.

Стандарты и шаблоны для ТЗ на разработку ПО

Введение

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

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

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

ГОСТ 34

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

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

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

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

ГОСТ 19

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

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

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

IEEE STD 830-1998

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

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

1. Введение

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

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

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

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

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

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

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

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

• 1. Назначение системы
• 2. Содержание системы (границы системы)
• 3. Обзор системы
  • 1. Содержание системы
  • 2. Функции системы
  • 3. Характеристики пользователей
• 4. Термины и определения

2. Ссылки

3. Системные требования

• 1. Функциональные требования
• 2. Требования к юзабилити
• 3. Требования к производительности
• 4. Интерфейс (взаимодействие) системы
• 5. Операции системы
• 6. Состояния системы
• 7. Физические характеристики
• 8. Условия окружения
• 9. Требования к безопасности
• 10. Управление информацией
• 11. Политики и правила
• 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
• 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

• 1. Назначение
• 2. Содержание (границы)
  • 3. Обзор продукта
  • 1. Взаимодействие продукта (с другими продуктами и компонентами)
  • 2. Функции продукта (краткое описание)
  • 3. Характеристики пользователей
  • 4. Ограничения
• 4. Термины и определения

2. Ссылки

3. Детальные требования

• 1. Требования к внешним интерфейсам
• 2. Функции продукта
• 3. Требования к юзабилити
• 4. Требования к производительности
• 5. Требования к логической структуре БД
• 6. Ограничения проектирования
• 7. Системные свойства ПО
• 8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

• 1. Предположения и зависимости
• 2. Аббревиатуры и сокращений

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

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

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

2. Обзор системы

• 1. Обзор вариантов использований.
• 2. Предположения и зависимости.

3. Детальные требований

• 1. Описание вариантов использования.
• 2. Дополнительные требования.
• 3. Другие функциональные требования.
• 4. Нефункциональные требования.

4. Вспомогательная информация.

SWEBOK, BABOK и пр.

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

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Как составить техническое задание

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

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

Напомним, что с 11.01.2018 в правилах описания предмета госзаказа произошли изменения:

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

Делать это не обязательно:

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

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

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

Правила составления ТЗ по 44 ФЗ

Самый простой и быстрый способ сформировать техническое задание — образец по ФЗ 44 разработать на основе официального издания Единой системы документации национальных стандартов.

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

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

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

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

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

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

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

В качестве рекомендации, как составить техническое задание по 44 ФЗ, можно предложить разбить документ на основные разделы:

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

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

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

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

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

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

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

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

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

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры для других госзакупок

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

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

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

Правила оформления техзадания к договору подряда

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

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

Основание для производственных действий

Основанием для производства работ являются:

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

Цель и исходные данные

Для реализации потребностей по договору подряда обе стороны согласуют исходные данные:

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

Требования заказчика

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

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

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

Чтобы подрядчик мог выполнять работы согласно ТЗ, согласуются условия для качественного исполнения этапов договора:

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

Обоснования

Технико-экономическое

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

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

Патентно-лицензионное (при необходимости его оформления)

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

Этапы проведения

Сроки начала и завершения этапов оговариваются при составлении техзадания. Их согласуют перед подписанием договора.

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

Приложения

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

В качестве приложений могут быть:

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте далее: