Начиная с 01.01.2014 для совершения закупок все учреждения должны применять положения Закона № 44-ФЗ. Отметим, что в данном законе прямо не предусмотрена обязанность заказчика составлять техническое задание. Однако техническое задание является одним из первых документов, который необходимо составить при любом виде закупки, так как в нем прописаны действия или услуги, которые нужно будет выполнить исполнителю.

При составлении технического задания руководствуются ст. 33 «Правила описания объема закупки» Закона №  44-ФЗ .

В частности, необходимо указать в техническом задании:

  1. Общую информацию о закупке.
  2. Описание объекта закупки.
  3. Требования к объекту закупки.
  4. Условия закупки.
  5. Особенности отдельных видов закупки.
Отметим, что описание объекта закупки должно носить объективный характер.

Общая информация о закупке. Этот раздел, как правило, включает в себя:

1. Общие сведения о заказчике (о наименовании, местонахождении, режиме работы).

2. Общие сведения о закупке (о способе определения поставщика в соответствии с ч. 1 ст. 24 Закона №  44-ФЗ , цели закупки согласно ст. 13 Закона №  44-ФЗ , источнике финансирования, нормативно-правовой базе, на основании которой производится закупка).

3. Дополнительные пояснительные сведения.

Описание объекта закупки. Здесь указываются следующие характеристики объекта закупки:

  1. Функциональные. Необходимо установить основное назначение объекта закупки и условия его использования по назначению. Функциональное назначение объекта характеризуется, например, такими свойствами, как пищевая ценность (энергетическая, биологическая), эстетические свойства (форма, цвет, запах, совершенство производственного исполнения) и др.
  2. Технические. Заказчик может детализировать описание объекта закупки, привести конкретные данные, параметры, исходные и конечные величины, физические величины показателей, описать регламент и порядок действий при поставке товара, выполнении работ, оказании услуг.
  3. Качественные. Указывается совокупность свойств, характеристик, признаков товаров, услуг, работ, обусловливающих их способность удовлетворять потребности и запросы заказчика, соответствовать своему назначению и предъявляемым требованиям.
  4. Эксплуатационные. Здесь можно прописать характеристики надежности и работоспособности объекта закупки, условия, обеспе-чивающие его эффективную эксплуатацию, к которым относятся в том числе прочность, долговечность, технические параметры, объемно-планировочные, санитарно-гигиенические, экономические и эстетические характеристики. В качестве эксплуатационных характеристик товара можно указать стадию его жизненного цикла использования по назначению.
Отметим, что все вышеперечисленные характеристики объекта закупки являются критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона №  44-ФЗ ).

При описании объекта закупки необходимо использовать, если это возможно, стандартные показатели, требования, условные обозначения и терминологию, касающуюся технических и качественных характеристик объекта закупки, установленных в соответствии с техническими регламентами, стандартами и иными требованиями, предусмотренными законодательством РФ о техническом регулировании. К ним относятся ГОСТы, СНиПы и другие нормативно-технические документы.

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

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

Требования к объекту закупки. Здесь необходимо учитывать следующие положения ст. 33 Закона №  44-ФЗ :

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

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

3. Поставляемый товар должен быть новым товаром. Это значит, что он не был в употреблении, в ремонте, не был восстановлен, у него не была осуществлена замена составных частей, не были восстановлены потребительские свойства, в случае, если иное не преду-смотрено описанием объекта закупки (пп. 7 п. 1 ).

Условия закупки. В этом разделе следует указывать:

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

2. Сроки поставки товаров, выполнения работ, оказания услуг. Отметим, что согласно п. 2 ст. 42 Закона №  44-ФЗ обязательно нужно проставить сроки завершения работ. Кроме этого, здесь должны быть указаны промежуточные сроки завершения отдельных этапов работ или приведен график оказания услуг, который поможет распределить объем оказываемых услуг по периодам.

3. Информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт, если заказчик установил требования о соответствии поставляемого товара образцу или макету товара, на поставку которого заключается контракт (пп. 5 п. 1 ст. 33 Закона №  44-ФЗ ).

4. Требования к поставщикам (подрядчикам, исполнителям). Здесь можно прописать требования о наличии лицензии, допуска, разрешения и согласования (п. 1 ч. 1 ст. 31 Закона №  44-ФЗ ). Кроме того, в силу ч. 2 ст. 31 Закона №  44-ФЗ при закупке отдельных видов товаров (работ, услуг) Правительство РФ устанавливает дополнительные требования к участникам закупок, в том числе к наличию финансовых, материальных и трудовых ресурсов для исполнения контракта, опыта работы, связанного с предметом контракта (ч. 2 ст. 31 Закона №  44-ФЗ ).

5. Показатели, которые позволят определить соответствие закупаемых товаров, работ, услуг, установленные заказчиком. При этом указываются максимальные и (или) минимальные значения таких показателей и значения показателей, которые не могут изменяться (п. 2 ст. 33 Закона №  44-ФЗ ).

6. Требование к расходам на эксплуатацию товара (ч. 4 ст. 33 Закона №  44-ФЗ ). Оно устанавливается для необходимости обосновать документально расходы, которые будут понесены заказчиком при эксплуатации закупленного товара. Величина расходов отражается в численной форме индивидуально для каждого товара с учетом нормальных эксплуатационных и нагрузочных условий работы. Данное требование является критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона №  44-ФЗ ).

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

Какие требования может не содержать техническое задание?

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

2. Требования к объекту закупки.Согласно п. 3 ст. 33 Закона №  44-ФЗ не допускается включение следующих требований:

  • о наличии опыта работы к участнику закупки;
  • к деловой репутации участника закупки;
  • к наличию у участника закупки производственных мощностей, технологического оборудования, трудовых, финансовых и других ресурсов, необходимых для производства товара, поставка которого является предметом контракта, для выполнения работы или оказания услуги, являющихся предметом контракта, за исключением случаев, если возможность установления таких требований к участнику закупки предусмотрена данным законом. Это означает, что не допускается указывать требования, которые могут создать преимущественные условия участия для участников закупки (п. 2 ч. 1 ст. 17 Федерального закона от 26.07.2006 №  135-ФЗ «О защите конкуренции» ).
Особенности отдельных видов закупки. Согласно ч. 5 ст. 33 Закона №  44-ФЗ для отдельных видов товаров, работ, услуг Правительством РФ могут быть установлены специальные правила описания закупок, например:

1. Закупка для нужд оборонного заказа. Особенности описания товаров, работ, услуг, входящих в состав государственного оборонного заказа для обеспечения федеральных нужд, могут быть установлены в соответствии с Федеральным законом от 29.12.2012 №  275-ФЗ «О государственном оборонном заказе» (ч. 6 ст. 33 Закона №  44-ФЗ ).

2. Закупка лекарственных средств. При закупке лекарственных средств необходимо отражать следующую информацию (пп. 6 ч. 1 ст. 33 Закона №  44-ФЗ ):

  • международные непатентованные наименования лекарственных средств или (при отсутствии таких наименований) химические, группировочные наименования;
  • при закупке лекарственных средств, входящих в перечень лекарственных средств, закупка которых осуществляется в соответствии с их торговыми наименованиями, а также при осуществлении закупки лекарственных препаратов согласно п. 7 ч. 2 ст. 83 Закона №  44-ФЗ разрешается указывать торговые наименования этих лекарственных средств. Данный перечень и порядок его формирования утверждаются Правительством РФ;
  • предметом одного контракта (одного лота) не могут быть лекарственные средства с различными международными непатентованными наименованиями или (при отсутствии данных наиме-нований) с химическими, группировочными наименованиями при условии, что начальная (максимальная) цена контракта (цена лота) превышает предельное значение, установленное Правительством РФ, а также лекарственные средства с международными непатентованными наименованиями (при отсутствии этих наименований - с химическими, группировочными наименованиями) и торговыми наименованиями.
3. Закупка машин и оборудования. В силу ч. 4 ст. 33 Закона №  44-ФЗ при закупке машин и оборудования в техническом задании, которое включается в документацию о закупке, необходимо установить следующие требования, если они предусмотрены технической документацией на товар: к гарантийному сроку, к объ-ему предоставления гарантий качества товара, к гарантийному обслуживанию, к расходам на обслуживание товара в течение гарантийного срока, к осуществлению монтажа и наладки товара. При закупке новых машин и оборудования в техническом задании нужно установить требования к предоставлению гарантии производителя и (или) поставщика и сроку ее действия. Следует учитывать, что такая гарантия предоставляется вместе с товаром.

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

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

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

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

  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
  • Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную IT-службу. Решили поступить так: разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
  • Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
  • IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:

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

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

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

  • А почему нельзя разрабатывать Техническое задание всегда одинаково?;
  • Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
  • Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
  • Как понять, хорошо составлено Техническое задание или нет?
  • За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

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

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема ». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации — далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

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

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

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

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

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности - это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет - там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания .

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

  1. Требование должно быть понятным ;
  2. Требование должно быть конкретным ;
  3. Требование должно быть тестируемым ;

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

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

  • на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
  • Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
  • А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

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

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

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

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

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

А нужно ли вообще техническое задание? А Технический проект?

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

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

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

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 - пожалуй, перебор. Ведь Техническое задание - это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

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

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

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

Раздел 1. общие сведения.

Рекомендации по ГОСТ
полное наименование системы и ее условное обозначение; Тут все понятно: пишем, как будет называться система, ее краткое наименование
шифр темы или шифр (номер) договора; Это не актуально, но можно и указать, если требуется
наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты; указывают, кто (какие организации) будут работать над проектом. Можно указать и их роли.Можно вообще удалить этот раздел (достаточно формальный).
перечень документов, на основании которых создается система, кем и когда утверждены эти документы; Полезная информация. Тут стоит указать ту нормативно-справочную документацию, которую Вам предоставили для ознакомления с определенной частью требований
плановые сроки начала и окончания работы по созданию системы; Пожелания по срокам. Иногда в ТЗ об этом пишут, но чаще такие вещи описываются в договорах на работы
сведения об источниках и порядке финансирования работ; Аналогично, как и в предыдущем пункте про сроки. Более актуально для государственных заказов (для бюджетников)
порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы. Не вижу необходимости в этом пункте, т.к. требования к документированию вынесены отдельно, а кроме этого есть целый отдельный раздел «Порядок контроля и приемки» системы.

Раздел 2. назначение и цели создания (развития) системы.

Рекомендации по ГОСТ Что с этим делать на практике
Назначение системы С одной стороны с назначением все просто. Но желательно формулировать конкретно. Если написать что-то вроде «качественно автоматизировать складской учет в компании Х», то потом можно долго обсуждать результат при его завершении, даже независимо от хорошей формулировки требований. Т.к. Заказчик всегда может говорить, что под качеством он имел ввиду нечто иное. В общем, нервов можно попортить друг другу много, а зачем? Лучше сразу написать примерно так: «Система предназначена для ведения складского учета в компании Х в соответствии с требованиями, зафиксированными в данном Техническом задании».
Цели создания системы Цели - это безусловно важный раздел. Если уж его включать, то надо уметь эти цели формулировать. Если у Вас трудности с формулировкой целей, то лучше вообще исключить данный раздел. Пример неудачной цели: «Обеспечить быстрое оформление документов менеджером». Что такое быстрое? Это можно потом доказывать бесконечно. Если это важно, то лучше переформулировать данную цель так: «Менеджер по продажам должен иметь возможность оформить документ «Реализация товаров» из 100 строк за 10 минут». Подобная цель может появиться, если, например, в настоящее время менеджер тратит на это около часа, что слишком много для этой компании и для них это важно. В такой формулировке цель уже пересекается с требованиями, что вполне естественно, т.к. при разворачивании дерева целей (т.е. дробя их на более мелкие связанные цели), мы и так будем приближаться к требованиям. Поэтому, увлекаться не стоит.

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

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

ГОСТ расшифровывает перечень таких требований:

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

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

  • Требования к квалификации . Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
  • Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
  • Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
  • Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.

Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.Требования к функциям (задачам), выполняемым системойВот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье, которая войдет в 5-й выпуск рассылки. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.Требования к видам обеспечения

ГОСТ выделяет такие виды:

  • Математическое
  • Информационное
  • Лингвистическое
  • Программное
  • Техническое
  • Метрологическое
  • Организационное
  • Методическое
  • и другие…

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

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

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

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

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

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

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

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

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

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

Раздел 8. Требования к документированию

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

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

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

Раздел 9. Источники разработки

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

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

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

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

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

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

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

Вид требования

Неправильная формулировка

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

  • Этап планирования;
  • Составление итоговой документации предстоящей закупки, извещения, проектные договора;
  • Этап непосредственного исполнения условий контракта.

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

На основании сведений, которые содержаться в данном документе, становится возможным:

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

Как составить форму


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

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

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

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

На выполнение строительно-монтажных работ

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

  • Сам объект аукциона. Какие именно работы должны быть произведены в соответствии с будущим контрактом;
  • Адрес местоположения. Точное местонахождение объектов, на которых требуется осуществить строительно-монтажные работы;
  • Условия проведения работ. В данном пункте, как правило, перечисляется характер почв, инженерно-геологические характеристики, например, уровень глубины грунтовых вод и иные характеристики, значимые при проведении будущего строительства;
  • Указывается характер строительно-монтажных работ — будет ли это новое строительство либо работы будут проводиться на уже возведенном объекте;
  • Способ осуществления, например, подряд;
  • В следующем пункте содержится информация о наличии проектно-сметной документации и о том, кем она была составлена;
  • Технико-экономические характеристики объекта строительства;
  • В следующем пункте расписываются функции, которые возлагает на себя заказчик строительно-монтажных работ, включая бухгалтерский учет, контроль за ходом строительства на всех этапах, организации работы и предоставление разрешения на проведение строительно-монтажных работ;
  • Требования к исполнителю с перечнем работ, которые подлежат выполнению стороной-подрядчиком;
  • Стадии строительства и сроки выполнения определенного объема согласно распределению на этапы;
  • Организационные требования, например, необходимость соответствия выполняемой работы требованиям ГОСТа, и действующим СНиПам;
  • В конечном пункте указываются сроки, в которые строительно-монтажные работы должны быть произведены в полном объеме.

На выполнение электромонтажных работ

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

  • Место выполнения работ;
  • Сроки выполнения;
  • Дается краткое описание требуемых работ;
  • Требования к исполнителю.

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

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

На выполнение работ по 44-фз

Согласно требованиям Федерального закона № 44-ФЗ, заказчику надлежит руководствоваться едиными требованиями, касающимися описания объекта закупок, при подготовке документов вне зависимости от способов фактического исполнения контракта. При оформлении ТЗ заказчик должен руководствоваться следующими директивами:

  1. При описании объектов аукциона следует ориентироваться на критерии объективности;
  2. Функционал, технико-эксплуатационные характеристики объекта закупок должны присутствовать в описании в случае необходимости;
  3. ТЗ должно носить нейтральный характер, не содержа излишнее количество чрезмерных требований с целью ограничения количества потенциальных участников.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или 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

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

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

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

  • Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
  • Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
  • (читать вместе с комментариями)
  • Примеры ТЗ и другой документации по разработке АС для МЭР
  • ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
  • Шаблоны документов для бизнес-аналитиков из