Как составлять техническое задание. Наименования Разработчика и Заказчика работ и их реквизи-ты

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

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

Создан 05.02.2005 11:41:19

Твой мир пуст...

Кто печаль твою разделит?

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

Вернемся к вопросу. При «раскладке» получается:

  • первый вопрос - «а зачем оно надо»;
  • второй вопрос - какова должна быть структура разделов «Техническое задание»;
  • третий вопрос - какие существуют способы подготовки текстов содержимого разделов технического задания?

Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.

Цели и задачи статьи

Цель статьи - облегчить жизнь совсем уж начинающим техписам.

Задачи статьи:

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

История

Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:

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

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

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.

История, леденящая душу

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

Приволокли опричники холопа государева, умепьца местного (), кинули царю-батюшке в ноги. Бился лбом умелец о пол каменный - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме!

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

Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная.). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...

Выводы

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

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

Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.

Примечание от 10.05.2014 г. - Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. и.

Современное состояние

И было придумано то, что сделали танк...

из серии «Армейские приколы»

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

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

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

Большому Боссу, непосредственно взаимодействующему с заказчиком, техническое задание дает возможность избежать участи мастера-умельца (об этом ранее упоминалось неоднократно).

Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:

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

Крайнее утверждение - палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.

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

Считаем, что первый вопрос (в первом же приближении) закрыт.

ГОСТы на технические задания

Куст есть совокупность веток, произрастающих из одной точки.

Военная мудрость

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

Примечания:

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

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

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

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

Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо - открываем ГОСТ 34.602-89. На - ГОСТ 19.201-78.

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

Практические приемы

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

Самый первый прием - создание документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде -файла, затем просто открывается вордом и в формате dot.

Электронные версии ГОСТов, хранящиеся на, в целом соответствуют официальным версиям. Сомнительные моменты всегда можно проверить путем сравнения, если не лень, конечно.

Примечание от 25.12.2011 г. - На Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате...

Детализация

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

Вспомним родительское - «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».

Произвольно выбранная цитата из ГОСТ 34.602-89:

Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]

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

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

4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня

(текст требования)

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

(текст требования)

4.3.2.1.3 Требования к кодированию данных

(текст требования)

4.3.2.1.4 Требования к декодированию данных

(текст требования)

4.3.2.1.5 Требования к языкам ввода-вывода данных

(текст требования)

4.3.2.1.6 Требования к языкам манипулирования данными

(текст требования)

4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)

(текст требования)

4.3.2.1.8 Требования к способам организации диалога

(текст требования)

Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?

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

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

Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.

Шаблонное построение фраз

Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) - половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе ». Итак:

4.3.2.1 Требования к применению в системе языков программирования высокого уровня

В системе должны быть (именно должны - это же!) применены перечисленные ниже языки программирования высокого уровня:

  • язык C++;
  • язык Pascal;
  • и т.д.

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

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

(детализируем - создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)

(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)

Численность персонала должна удовлетворять требованиям :

  • быть достаточной для реализации автоматизированных () системы во всех режимах работы системы;

4.1.2.2 Требования к квалификации персонала

Квалификация персонала должна обеспечивать эффективное функционирование технических и системы во всех режимах работы системы»

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

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

Режим работы персонала - трехсменный круглосуточный.

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

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

Формализация при подготовке текста технического задания

Возможно Двести Вариантов

Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»

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

4.1.2.1 Требования к численности персонала

Численность персонала должна удовлетворять требованиям:

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

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

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

Примечание от 17.04.2018 г. - В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен

Штампы и унификация при подготовке текста технического задания

Вы, бабы, красивы,

А я - без прикрас

Но, все же, мужчины

Уходят от вас...

Ю. Рыбчинский, «Две сестры»

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

Положим, разрабатывается универсальный преобразователь энергии в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:

Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).

И, в тексте - Изделие, Изделие, Изделие...

Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).

И, в тексте - Система, Система, Система... Программа, Программа, Программа...

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

Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.

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

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

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

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

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

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

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

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

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

В ГОСТ 34.003-90 поставлена впереди, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций... И представьте себе, как дико звучала бы декларация: «Цель партии и правительства - повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой»... (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно - для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.

Итак, пример.

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

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

И из предыдущего подраздела:

  • должны быть ...;
  • должна удовлетворять требованиям ..

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

Перечни и нумерация разделов

Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.

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

Случай первый.

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

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

Случай второй.

«4.3.2.1 В рамках задачи (или для решения задачи ) ведения базы данных программные средства системыдолжны обеспечивать возможность выполнения перечисленных нижефункций :

  1. автоматизированной функции добавления записей в таблицы базы данных;
  2. автоматизированной функции удаления записей из таблиц базы данных;
  3. автоматизированной функции сортировки записей в таблицах базы данных...;»

Отличия, казалось бы, невелики. Но!

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

Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».

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

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

По списки следует «нумеровать» не цифрами, а буквами:

а) функция такая-то;

Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой организации - разработчика ТЗ и, при необходимости, подвергнуто [из п. 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.

Чуть-чуть о. Если в ТЗ имеется подраздел «Метрологическое обеспечение...», то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений согласно ГОСТ 8.417. И только.

Связка «общие сведения, назначение и состав» в техническом задании

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

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

Любой человек начнет рефлекторно просматривать разделы ГОСТа на техническое задание, пытаясь найти хоть какую-то зацепку. Человек с опытом сразу вспомнит о.

2.1 Назначение системы

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

Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:

  1. задачи сбора данных с каких-то, допустим, датчиков;
  2. задачи обработки, хранения, отображения и пр. в центре сбора.

Вот и все. Немного фантазии, и раздел готов:

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

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

Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?

2.1.1 Уровень сбора данных

2.1.1.1 Общие сведения

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

2.1.2.2 Назначение

Уровень сбора данных предназначен (еще один штамп):

  1. для передачи данных каких-то датчиков уровню консолидации по запросу (инициативе) крайнего (последнего);
  2. для протоколирования передачи данных в журнале событий (а если по ГОСТу, то в);
  3. еще для чего-то.

2.1.2.3 Состав

В состав уровня сбора данных должны входить:

  1. датчики такие-то;
  2. датчики еще какие-то.

В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.

2.2.2.3.1 Датчики такие-то

2.2.2.3.1.1 Общие сведения (о таких-то датчиках)

2.2.2.3.1.2 Назначение (таких-то датчиков)

2.2.2.3.1.3 Состав (таких-то датчиков)

Главное - вовремя остановиться.

Предостережение

При разработке и наибольший интерес представляют перечисленные ниже:

  • прежде всего - . Для таким является;
  • , например и;
  • , например;
  • и, например;
  • ряд других.

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

Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание и внести в него или возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.

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

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

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

Короче, писать надо примерно так, русским по белому:

«В качестве каналов связи могут быть применены (использованы):

  1. каналы связи -;
  2. каналы операторов сотовой связи;
  3. каналы операторов спутниковой связи;
  4. коммутируемые телефонные линии общего пользования;
  5. объекта заказчика;
  6. и так далее»

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

Заключение

Итак, вспомним еще разок ключевые моменты:

  1. подготовка технического задания импортом электронной версии требуемого ГОСТа;
  2. детализация - дробление больших по объему разделов технического задания на короткие простые подразделы;
  3. шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
  4. формализация содержимого тех разделов, где невозможно (или) давать конкретику;
  5. применение штампов;
  6. применение перечней (маркированных или нумерованных списков);
  7. применение связки «общие сведения, назначение и состав»;
  8. минимальное применение «тематических» ГОСТов.

В заключении можно дать ряд дополнительных советов:

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

Заказать ООО «Техническая документация» можно по эл. почте admin @ tdocs . su (без пробелов), тел. 8-910-468-09-28 или в форме.

Copyright © ООО «Техническая документация» 2018. Заимствуйте наши материалы с блеском! При воспроизведении материалов портала обязательна установка активной гиперссылки на источник - страницу с этой публикацией на сайт.

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

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

Проблема

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

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

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

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

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

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

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

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

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

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.

Понятие ТЗ

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

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

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

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

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

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

Место ТЗ в структуре проектирования

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

Стадии проектирования регламентированы стандартами. Это следующая последовательность:

  • Техническое задание (по ГОСТ 2.103-68 к стадиям разработки не относится),
  • Эскизный проект,
  • Стадии рабочего проекта.

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

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

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

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

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

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

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

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

Необходимость ТЗ

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

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

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

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

Академик А. Н. Крылов рассказывал. На одной фабрике установили новую машину, но никак не могли её запустить. Тогда обратились за помощью к профессору университета. Приехав на фабрику, он долго ходил вокруг машины, внимательно что-то высматривая и к чему-то прислушиваясь. Затем, взяв молоток, ударил по её корпусу. И машина заработала. За свою помощь профессор запросил у правления фабрики 100 рублей (дело было в начале 20 века). Но правление фабрики посчитало, что за один удар молотком это слишком большая плата. На что профессор ответил, что сам удар стоит один рубль, а вот то, куда ударить - 99 рублей. Замечено, что если стоимость исправления проектной ошибки, допущенной на этапе технического проектирования принять за 1, то стоимость её исправления возрастает приблизительно в 10, 100 и 1000 раз, если ошибка была допущена соответственно на этапах эскизного проектирования, технического предложения и ТЗ!

Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет:

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

Регламентированное ТЗ

Несмотря на свою важность, содержание ТЗ мало регламентировано нормативными документами (ГОСТ , ОСТ).

В части выполнения научно-исследовательских работ ТЗ регламентируется следующими документами:

Разделы ТЗ по ГОСТ 34.602-89 (пример)

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

Стоит отметить, что приведённые в условии данные - это номинальные параметры, но было бы более правильно приводить нормированные значения этих параметров, задаваемые своими предельно-допустимыми значениями (например, масса изделия 9,8…10,1 кг). То есть то, что считают условиями, на практике являются ограничениями в виде двусторонних неравенств. Ширина диапазона является следствием величины допуска на этот параметр.

При формировании системы требований обязателен анализ следующих источников:

  • Доступность ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные. Все ресурсы взаимосвязаны, например, за счет увеличения финансирования проекта можно добиться сокращения периода разработки. Следствием степени доступности является введение ограничений на методы и точность решения проектной задачи, что, в свою очередь, влияет на вид выбираемой модели . Так, при ограниченности времени ведут оценочные расчеты упрощенными методами или используют готовое программное обеспечение, стандартные методики, типовое оборудование, стандартные и покупные детали и узлы и т. д. В то же время модель, метод и точность решения должны обеспечивать исполнение требований ТЗ, даже если они и высоки.
  • Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств). В соответствии с законами Российской Федерации любое производство требует получения региональной лицензии на эксплуатацию. Помимо этого многие производства лицензируются надзорными органами и подлежат с их стороны контролю. Наиболее часто контролирующими являются региональные органы Ростехнадзора , Росстандарта, Минрегион России (бывш. Госстрой), Роспотребнадзора , Росприроднадзора , ГПС , МВД России , Роструда .
  • Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды. Основные указания на нее приводятся в технических требованиях в условиях потребления будущей продукции. Эти условия могут быть охарактеризованы достаточно обобщенно и нуждаться в конкретизации.

Составление списка требований ТЗ

Основная статья: Методы проектирования

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

Сначала приведем рассказ о том, как Эдисон ставил перед собой техническую задачу.

Прежде, чем приступить к разработке электрического освещения в быту, Эдисон провел исследования, при каких условиях оно выдержит конкуренцию в цене, яркости и удобстве с газовым освещением (рожком). Он до тонкостей изучил газовую промышленность, разработал план центральной электростанции и схему линий электропередач к домам и фабрикам. Затем подсчитал стоимость меди и других материалов, которые потребуются для изготовления ламп и добычи электроэнергии с помощью динамо-машины, движимой паром. Анализ данных определил не только размеры лампы, но и её конкурентоспособную цену, равнявшуюся 40 центам. И лишь когда Эдисон убедился, что сможет решить проблему электрического освещения, он принялся работать над лампой накаливания с угольной нитью, помещенной в стеклянный шар, из которого откачан воздух. В поисках материала нити он опробовал около 6 000 разновидностей растительного волокна.

Анализ задания заказчика

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

Следует выявлять и стараться избегать решения следующих задач:

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

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

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

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

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

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

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

Конкретизация целей проектирования

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

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

Наряду с потребностью в каком-то действии может существовать и потребность в несовершении действия или совершении действия с отрицательным эффектом.

Обработка собранной информации

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

Абстрагирование предназначено дать такую формулировку требованиям, чтобы избежать предопределения путей решения задачи (не создавать психологических барьеров). Для получения «сильных» решений рекомендуют проводить усиление системы требований и обострение противоречий путем формулирования ИКР.

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

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

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

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

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

Проблемами оценки качества посредством количественных показателей занимается наука «Квалиметрия».

5. Усечение списка требований.
Большой объем информации хотя и способен дать максимально полное представление о решаемой задаче, но труднее удерживается в голове, усложняет решение задачи. Для сокращения сведений до разумного объема (под способности каждого конкретного разработчика, соответствие его финансовым, организационно-техническим, временным ресурсам) можно воспользоваться их ранжированием или разделением на группы обязательных к учету, желательных и несущественных. К обязательным относятся те, неудовлетворение которых существенным образом влияет на выбор вариантов решений. Это - функциональные параметры, условия взаимосвязи систем и их частей и другие. Желательные требования позволяют различить варианты по степени качества.

Стоит принимать во внимание слова Ли Якокки : «… беда в том, что ты учился в Гарварде, где тебе вбили в голову, что нельзя предпринимать никаких действий, пока не соберёшь все факты. У тебя 95 % информации, а для того, чтобы собрать недостающие 5 %, тебе понадобится ещё шесть месяцев. За это время все факты устареют, потому что рынок развивается гораздо быстрее. Самое главное в жизни - всё делать вовремя. … главная задача состоит в том, чтобы собрать все важные факты и точки зрения, которые вам доступны. Но в какой-то момент надо начинать действовать решительно. Во-первых, потому, что даже самое правильное решение оказывается неверным, если оно принято слишком поздно. Во-вторых, потому, что в большинстве случаев не существует такой вещи, как полная уверенность. Вам никогда не удастся собрать все 100 % информации. К сожалению, жизнь не будет ждать, пока вы оцените все возможные просчеты и потери. Иногда надо просто двинуться вперед наудачу и исправлять ошибки по ходу движения». - — Тематики электросвязь, основные понятия EN expression of requirements … Справочник технического переводчика

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

техническое задание - 3.29 техническое задание (statement of work): Документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора.

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

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

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

Содержание примера технического задания на разработку сайта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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