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

О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики ERP SAP группы компаний Лига Цифровой Экономики, Екатерина Синица.

ТЗ предназначено для окончательного формулирования требований к продукту проекта, в нашем случае – к информационной системе (ИС). Большинство проблем, связанных с разработкой и согласованием ТЗ, вызвано неполным охватом всех видов требований при их анализе. Напомним, они делятся на функциональные (требования к тому, ЧТО должна делать ИС) и нефункциональные (требования к тому, КАК должна функционировать ИС).

При анализе функциональных требований аналитик сталкивается со всем многообразием проблем нечеткого и неполного формулирования требований заказчиком. Чтобы обеспечить их полноту и непротиворечивость, полезно выстраивать иерархию (дерево) требований, на вершине которой будет цель проекта, на следующем уровне – бизнес-требования (понимание, зачем данная ИС нужна и какие бизнес-потребности удовлетворяет), еще ниже, раскрывая каждое бизнес-требование, будут располагаться пользовательские требования (бизнес-сценарии, user stories или use cases), а в самом низу – детальные функциональные требования с описанием действий ИС в каждом конкретном сценарии.

Разработка электронного устройства. Техническое задание.

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

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

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

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

Как написать быстро техническое задание?

1) Структурный анализ – моделирование структуры, понимание компонентов ИС и взаимосвязи между этими компонентами;

2) Анализ процессов – моделирование рабочего взаимодействия всех участников процесса, в котором предполагается задействовать ИС;

3) Функциональный анализ – моделирование всех возможных сценариев работы ИС и ее взаимодействия с акторами (пользователями) и смежными системами;

4) Информационный анализ – моделирование структуры данных (выделение объектов и их атрибутов, определение взаимосвязей между объектами) и потоков прохождения этих данных по процессам;

5) Анализ интерфейсов – моделирование (а в идеале прототипирование) пользовательских интерфейсов, проектирование рабочих мест пользователей.

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

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

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

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

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

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

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

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

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

Источник: vc.ru

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

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

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

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

Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?»

Как правильно разработать техническое задание для автоматизированной системы. Часть 1

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

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

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

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

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

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

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

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

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

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

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

В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

Как ни странно, проблемы у всех одинаковые! У всех бывают как успешные документы (и проекты), так и совсем бестолковые (исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия). Почему так получается?

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

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

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

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

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

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

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

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

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

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

Именно этот факт лежит в корне проблемы, которая лежит посерединеJ. А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится!

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

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

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

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

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

Что необходимо знать о требованиях?

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

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

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

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

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

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

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

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

Когда разберешься.

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

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

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

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

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

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

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

Что мы имеем на практике?

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

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

Так что мы имеем на практике-то?

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

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

Еще небольшой, но важный момент.

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

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

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

Не перегрелся ли я?

Разве такое возможно, вообще без Технического задания ?

Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий».

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

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

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

А что же с Техническим проектом?

Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик?

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

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

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

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

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

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

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

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

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

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

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

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

Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

И так, ГОСТ рекомендует следующие разделы:

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

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

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

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

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

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

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

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

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

Рекомендации по ГОСТ	Что с этим делать на практике
Требования к системе в целом.

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по ГОСТ	Что с этим делать на практике
Виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

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

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

Источник: www.lobanov-logist.ru

ОПИСАНИЕ ОБЪЕКТА ЗАКУПКИ. РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

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

Разработка ТЗ — очень ответственная работа, для которой целесообразно привлекать сотрудников иных подразделений (подведомственных организаций), сторонних специалистов (консультантов, экспертов). Закупка ненадлежащей продукции, допущение нарушений, связанных с ограничением конкуренции и количества участников закупки, — вот только некоторые негативные последствия некачественной разработки ТЗ. Закон о контрактной системе не детализирует процесс разработки ТЗ, ограничиваясь такими общими фразами, как «описание объекта закупки должно носить объективный характер», «в описание объекта закупки не должны включаться требования, которые влекут за собой ограничение количества участников закупки», «использование при составлении описания объекта закупки стандартных показателей, требований, условных обозначений и терминологии». Однако следует учитывать, что особенности описания отдельных видов объектов закупок могут устанавливаться федеральными законами (Федеральный закон от 29.12. 2012 № 275-ФЗ «О государственном оборонном заказе») и Правительством РФ (постановление Правительства РФ от 28.11.2013 № 1086).

Работник контрактной службы при разработке ТЗ может руководствоваться следующими рекомендациями:

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

В структуру ТЗ целесообразно включить:

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

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

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

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

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

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

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

При идентификации товарных знаков в ТЗ заказчик использует государственные реестры (реестр товарных знаков и знаков обслуживания, реестр полезных моделей, реестр промышленных образцов). Трудность использования официального сайта (http://wwwl. fips.ru/) заключается в том, что поиск записи в реестре осуществляется только по номеру свидетельства. Вместе с тем возможно использование иных бесплатных ресурсов, позволяющих проводить поиск по наименованию (например, http://wvv.findtm.ru/).

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

• • наименование объекта закупки (в соответствии с классификаторами видов продукции, экономической деятельности) [1] ;
• • обоснование объекта закупки (см. подробнее в главе 5), ожидаемые показатели использования объекта закупки;
• • характеристики (количественные, качественные) объекта закупки, которые позволяют однозначно идентифицировать объект. Требование к объективности (п. 1 ч. 1 ст. 33 Закона о контрактной системе) означает необходимость использования (по возможности) открытых, доступных источников информации, что представляет сложность при описании инновационного, высокотехнологичного продукта;
• • характеристики (функциональные) объекта закупки, которые описывают свойства объекта в процессе его функционирования, условия его нормального функционирования, назначение и соответствие потребностям заказчика;
• • характеристики (технические) объекта закупки, которые описывают исходные и конечные параметры объекта, конкретные данные, порядок и график действий. Заказчику рекомендовано включать в описание спецификации, планы, чертежи, эскизы, фотографии, результаты работы, тестирования, требования (и. 3 ч. 1 ст. 33 Закона о контрактной системе);
• • характеристики (эксплуатационные) объекта закупки, которые описывают эффективность применения, работоспособность, экономичность, эргономичность объекта закупки в будущем. Для этих целей заказчик квалифицирует эксплуатационные расходы, стадии жизненного цикла товара;
• • характеристики объекта закупки, которые описывают порядок, сроки и периодичность поставки товара, выполнения работ, оказания услуг. В отсутствие регламентированных требований к установлению данных характеристик объекта закупки единственным ориентиром для заказчика является принцип разумности с учетом правил делового оборота и функционирования рынка;
• • характеристики энергетической эффективности объекта закупки. Заказчик обязан [2] установить требования к энергетической эффективности (постановление Правительства РФ от 31.12.2009 № 1221), которые направлены на повышения эксплуатационной экономии и достижение показателей энергосбережения;
• • гарантийный срок и объем предоставляемых гарантий к качеству (при необходимости), который заказчик устанавливает для обеспечения возможности обращения к исполнителю контракта с требованием о восстановлении исходных свойств объекта закупки, восстановления функционального состояния. Закон о контрактной системе устанавливает случаи обязательного установления гарантийного срока (ч. 4 ст. 33). Сроки и объем гарантий могут быть установлены иными законами и нормативными правовыми актами. Заказчик также может указать требование о предоставлении гарантийного обслуживания в период гарантийного срока;
• • характеристики внешнего вида объекта закупки (этикетка, маркировка, упаковка), которые заказчик устанавливает в целях обеспечения идентификации, сохранности, безопасности закупаемых товаров. При закупке отдельных товаров требования к упаковке и (или) маркировке являются обязательными;
• • характеристики соответствия образцу (макету), изображению товара. Данное требование позволяет заказчику оценить степень соответствия предлагаемого участником закупки товара путем сопоставления, осмотра, апробации и испытаний. Кроме того, это дает возможность участнику закупки предметно ознакомиться с выставляемым образцом (макетом) при том, что заказчик установит порядок осмотра, наблюдения, посещения для участников (п. 5 ч. 1 ст. 33 Закона о контрактной системе). Следует учитывать, что испытания могут проводить только аккредитованные Федеральной службой по аккредитации органы по сертификации и (или) испытательные лаборатории (центры) при установлении заказчиком в ТЗ программы испытаний;
• • характеристики объекта закупки, определяющие объем закупаемой продукции, который может быть выражен в натуральной величине (физические показатели) или в денежных единицах (при неопределенном объеме закупки, невозможности определить общий объем закупки).

Важно запомнить

Приказом Федерального агентства но техническому регулированию и метрологии от 30.09.2014 № 1261 -сг «О внесении изменений в приказ Федерального агентства по техническому регулированию и метрологии от 31 января 2014 г. № 14-ст “О принятии и введении в действие Общероссийского классификатора видов экономической деятельности (ОКВЭД2) ОК 029-2014 (КДЕС Ред.2) и Общероссийского классификатора продукции по видам экономической деятельности (ОКПД2) ОК 034-2014 (КПЕС 2008)”» введение новых ОКВЭД и ОКПД отложено до 2016 г. Данные классификаторы, в частности, используются в целях планирования при осуществлении закупок как в рамках контрактной системы, так и в рамках закупок отдельных видов юридических лиц, а также в различных перечнях, используемых в закупочной деятельности заказчиков, например в Перечне товаров, работ, услуг, в случае осуществления закупок которых заказчик обязан проводить аукцион в электронной форме (электронный аукцион), утвержденном распоряжением Правительства РФ от 31.10.2013 № 2019-р.

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

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

Источник: studme.org