Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть Разработка технического задания вызывае вопросы практически у каждого, кто сталкивается в первый раз. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований. Как формулировать требования будет полностью посвящена выявлению и формулировке требований к информационной системе. Именно в ТЗ описываются все основные требования на разработку программного обеспечения, будь то создание либо простенькой программы или. Анализ требований технического задания и разработка спецификаций. Тема разработки технического задания постоянно обсуждается на. Она не имеет собственной  IT службы и решили поступить так Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации. Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную  IT службу. Решили поступить так  разработать Техническое задание, затем согласовать его между IT службой и заинтересованными лицами, и реализовать собственными силами. Госструктура решила затеять IT проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье. Это наиболее сложный случай, ведь приходится работать в самых различных условиях. Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию. Техническое задание разрабатывается для собственных разработчиков клиенту все равно. Техническое задание разрабатывается для передачи подрядчику т. Возможно, последний случай кажется парадоксом, но это правда. Где их взять Должен ли этот человек обладать какими то специальными знаниями Говорю так уверенно от того, что уже 1. Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Tz.jpg' alt='Образец Технического Задания На Разработку Программы' title='Образец Технического Задания На Разработку Программы' />ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ ПРОГРАММЫ. НАИМЕНОВАНИЕ ПРОГРАММЫ. Представлен пример образец технического задания техзадание на создание. Разработка системы должна осуществляться с использованием стандартных. Адаптация программ продолжительность Y месяцев. Что такое техническое задание на разработку программного. Образец Технического Задания На Разработку Программы' title='Образец Технического Задания На Разработку Программы' />Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 1. Но, попробую, как говорится разложить все по полочкам. Те, кто уже знаком с моими статьями знают, что я не пользуюсь копи пастом труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Как правило, те, кто любит умничать на форумах попробуйте все таки поискать, сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам такой небольшой разведкой. В результате приходилось видеть документацию и по таким монстрам, как Газ. Пром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов разбрасывают информацию по интернету. Поэтому сразу говорю конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения профессиональная этика. У всех бывают как успешные документы и проекты, так и совсем бестолковые  исключение, пожалуй, составляют Технические задания, разработанные еще во времена, когда не было персональных компьютеров, но там были совсем другие условия. Именно потому, что цели у проектов бывают разные, как и пользователи этих документов. И, конечно, компетенции непосредственных специалистов не на последнем месте. Конечно, получится в сжатом виде, т. Когда то все эти ГОСТы были актуальны и активно применялись. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Я бы ответил словами Гете Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае Между ними лежит проблема. Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы конкретной и системной не предлагают. Технические условия. ГОСТ 1. 9. 2. 01 7. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. ГОСТ 3. 4. 6. 02 8. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико технические характеристики, показатели качества и технико экономические требования, предписание по выполнению необходимых стадий создания документации конструкторской, технологической, программной и т. Задание как исходный документ на создание чего то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посередине. J. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках Конечно, есть много отличных трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, Как разработать техническое задание будут продолжаться бесконечно. Однако, я увлекся лирикой. Настало время взяться за главное разложить все по полочкам, как и обещал. Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например. Требования в функциональности. Требования к безопасности и правам доступа. Требования к квалификации персонала. Вы можете  прочитаете о них в упомянутом ГОСТе а ниже я их тоже рассмотрю немного подробнее. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности это 9. Технического задания. Все остальное зачастую является камуфляжем, который надет на эти требования. Да, формально все требования будут соблюдены по ГОСТу J, ТЗ разработано, утверждено и подписано, деньги за него получены. А дальше начнется самое интересное что делать то Если это проект на Гос. Заказе, то проблем нет там бюджет такой, что ни в какой карман не влезет, в процессе реализации если она будет все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на Гос. Заказах накалякали ТЗ, слили десяток миллионов, а проект делать не стали. Пакеты Стеримаг Инструкция. Разработка технического задания ТЗ на программный продукт с точки зрения заказчика. Работаем над ошибками Хабрахабр. В недалеком прошлом на этом замечательном ресурсе была опубликована статья Разработка технического задания ТЗ на программный продукт с точки зрения заказчика. Статья сама по себе неплохая содержит, к сожалению, ряд неточностей, о которых следует упомянуть. Сделаем это в один проход по абзацам. По второму абзацу Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть хорошо написанное ТЗ. Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Уточнения Технические задания не пишут составляют, подготавливают, оформляют и пр., а разрабатывают, см. ГОСТ 3. 4. 6. 02 8. Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется по понятиям как сейчас принято то без плюрализ. Ьма мнений тут, конечно, никак не обойтись. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. Палка о трех концах Чрезмерно детализированное техзадание становится техническим проектом, что, в общем то, и неплохо, но кто даст исполнителю столько времени и денег на разработку излишне подробного ТЗ Вменяемый исполнитель всегда стремится сократить объем технического задания, поскольку меньше слов меньше вопросов. И меньше работы. Более того, на стадии технического задания очень трудно предугадать технический облик изделия, программы или автоматизированной системы в целом, поэтому существует типовая отмазка то то и то то должно уточняться на стадии технического проекта Исполнитель не должен забывать, что он несет обязательства не только в части реализации функциональных требований, но и общих требований требований к надежности, безопасности и т. Нет смысла перечислять, поскольку их довольно много и все они подробно изложены в том же ГОСТ 3. При этом заказчик, который точно не определился с параметрами будущей системы или у которого ветер в голове, может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. А вот тут уже все зависит от опыта исполнителя. Толковый исполнитель обязательно пропишет в договоре или ТЗ условие, при котором все дополнительные хотелки заказчика должны будут финансироваться отдельно с соответствующим увеличением срока разработки дополнениями к ТЗ, допсоглашениями и т. При этом очень важно крайне важно По третьему абзацу Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять. Теперь о неточностях нельзя смешивать понятия модулей и подсистем, поскольку подсистема это та же система, только маленькая. Подсистема, как и система, включает в себя все виды обеспечения, все те же общие требования, а модуль есть всего лишь Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память. Таблицы 1 ГОСТ 1. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании. Что касается основных понятий, то существует громадное количество ГОСТов, содержащих в своих названиях строчку. Их и следует применять в работе, чтобы быстрее освоить новую предметную область, но ни в коем случае не ссылаться на всяческие. По четвертому абзацу Немаловажным моментом является вероятность дрейфа требований. Грамотный исполнитель в этих условиях может выбрать т. ГОСТ 3. 4. 6. 02 8. Приложения 1 того же стандарта. По седьмому абзацу Сложность задачи также оказывает влияние на подход к написанию ТЗ. Соответственно и техническое задание будет разрабатываться в начале каждого этапа, опираясь на опыт предыдущего. Смешаны понятия этапов и очередей. Применительно к автоматизированным системам Этап Часть стадии создания АС, выделенная по соображениям единства характера работ и или завершающего результата или специализации исполнителей. ГОСТ 3. 4. 0. 03 9. ГОСТ 3. 4. 0. 03 9. Перед началом разработки ТЗ очень рекомендую определиться с его структурой, фактически, составить страницы с его содержанием, перечнем пунктов и подпунктов до начала работ по ТЗ, а не в процессе или после. При этом и вы и исполнитель договоритесь о том какие вопросы должны быть рассмотрены на данном этапе. Вы будете хорошо понимать, что получите в итоге, а исполнитель будет понимать, что вы от него ждете. Не смотря на кажущуюся простоту, это делается не всегда, даже для крупных и сложных проектов. В итоге ТЗ может получиться совершенно непотребным для дальнейшей работы. Зачем вся эта самодеятельность с составлением страниц с содержанием ТЗ Есть ГОСТ 1. ГОСТ 3. 4. 6. 02 и другие стандарты, в которых структура и содержание технических заданий расписана четко и строго, узаконена государством, не содержит практически ничего лишнего, при этом допускается вводить дополнительные разделы, подразделы, пункты и подпункты на усмотрение заказчика и исполнителя По десятому абзацу. При этом шаблоны этого документа могут существенно различаться для различных компаний и процессов разработки ПО. Будущий разработчик вашей системы может навязывать вам принятые у него шаблоны ТЗ, но в данном случае важно понимать, что, во первых, ТЗ является важнейшим инструментом не только для исполнителя, но и для заказчика, который также имеет полное право определять его структуру. Вот тут совсем непонятно ведь заказывает музыку тот, кто платит, а платит заказчик. Как исполнитель может хоть что то ему навязыватьТут возможно лишь взаимное согласие как продукт при полном непротивлении сторон. Тем не менее, для многих случаев, он является недостаточно детальным и хорошо описывающим специфику разработки современных программных продуктов. Слезы потекли ручьем Плохо или неплохо судить не нам, поскольку все существующие зарубежные стандарты, включая MIL, даже близко к ГОСТ 3. ГОСТ 3. 4. 6. 02 к программным продуктам вообще никакого отношения не имеет, ибо Настоящий стандарт распространяется на автоматизированные системы АС для автоматизации различных видов деятельности управление, проектирование, исследование и т. ГОСТ 1. 9. 2. 01 7. По четырнадцатому большому абзацу Категории роли пользователей, работающих с системой перечислить роли и кратко описать каким должностям из каких подразделений они соответствуют. Все это не предусмотрено как ГОСТ 1. ГОСТ 3. 4. 6. 02, но имеется подраздел Требования к численности и квалификации персонала системы и режиму его работы, который разумно добавить в ТЗ на ПО и детально расписать в нем категории персонала. И даже роли. Если интересны подробности задавайте вопросы в комментариях. По заключению В заключении хотелось бы отметить, что по моему опыту самое лучшее ТЗ это ТЗ написанное самим заказчиком или при самом активном участии заказчика, т. Конечно, для этого необходимо иметь в штате достаточно квалифицированных ИТ специалистов или воспользоваться услугами ИТ консультанта. Полученное ТЗ можно использовать в составе тендерной документации для того, чтобы дать большому количеству потенциальных подрядчиков четкое понимание требуемого результата и получить от них предложения. И, наконец Законодательно ТЗ разрабатывается самим заказчиком только в том случае, если он представляет Министерство обороны или иное силовое ведомство Тендерную документацию разрабатывает именно тот подрядчик, который заведомо должен выиграть конкурс. Простите, но это жизненные реалии. Как то так. В заключении можно рекомендовать старенькую статью Страшная правда о техническом задании, в которой довольно детально расписаны процессы взаимодействия заказчика и исполнителя в ходе разработки технического задания, а также всевозможные тайные подлости этого замечательного документа.