Техническое задание согласно госту. Техническое задание определение термина

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

Рекомендуем прочитать:

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

Для чего ТЗ заказчику?

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

Рекомендуем прочитать:

Для чего ТЗ исполнителю?

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

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

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

• Общие положения технического задания

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

Рекомендуем прочитать:

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

• Цели проекта

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

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

• Функциональные требования

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

Рекомендуем прочитать:

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

• Сроки

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

• Отчетность

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

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

• Ответственность

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

Рекомендуем прочитать:

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

1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

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

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

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

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

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

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

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

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

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

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

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

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.

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

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

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

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

Пишите однозначно и точно

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

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

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

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

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

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

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

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

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

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

Укажите структуру сайта

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

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

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

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.

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

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.

Вместо вывода: структура техзадания

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

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

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

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

Комментарии разработчиков

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

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

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

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

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

ГОСТ 19.201-78

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

Unified system for program documentation. Technical specification for development. Requirements for contents and form of pressentation

МКС 35.080

Дата введения 1980-01-01

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. N 3351 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).


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

Стандарт полностью соответствует СТ СЭВ 1627-79*.
________________
* Доступ к международным и зарубежным документам, упомянутым здесь, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru . - Примечание изготовителя базы данных.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68 , как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 .

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

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

1.4. Техническое задание должно содержать следующие разделы:

введение;

основания для разработки;

назначение разработки;

требования к программе или программному изделию;

требования к программной документации;

технико-экономические показатели;

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

порядок контроля и приемки;

в техническое задание допускается включать приложения.

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

(Измененная редакция, Изм. N 1).

2.1. В разделе "Введение" указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

2.2. В разделе "Основание для разработки" должны быть указаны:

документ (документы), на основании которых ведется разработка;

организация, утвердившая этот документ, и дата его утверждения;

наименование и (или) условное обозначение темы разработки.

2.1, 2.2 (Измененная редакция, Изм. N 1).

2.3. В разделе "Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел "Требования к программе или программному изделию" должен содержать следующие подразделы:

требования к функциональным характеристикам;

требования к надежности;

условия эксплуатации;

требования к составу и параметрам технических средств;

требования к информационной и программной совместимости;

требования к маркировке и упаковке;

требования к транспортированию и хранению;

специальные требования.

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

(Введен дополнительно, Изм. N 1).

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

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

2.7. В разделе "Порядок контроля и приемки" должны быть указаны виды испытаний и общие требования к приемке работы.

2.8. В приложениях к техническому заданию, при необходимости, приводят:

перечень научно-исследовательских и других работ, обосновывающих разработку;

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

другие источники разработки.



Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Единая система программной документации:
Сборник национальных стандартов. -
М.: Стандартинформ, 2010

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

Техническое задание (далее - ТЗ) - это результат анализа процессов организации и концептуальных предложений по автоматизации этих процессов. До начала создания ТЗ необходимо провести информационное обследование процессов, оформляемое в виде отчета об обследовании, и разработать концепцию автоматизации, которая содержит саму идею автоматизации и раскрывает цели автоматизации, а также дает основные предложения по архитектуре и составу системы. При этом отчет об информационных процессах и концепция должны быть составлены в двух парадигмах: «как есть» и «как должно быть». Очень полезным дополнением к этим отчетам будет графическое отображение процессов (так называемое моделирование процессов) в любой выбранной методологии. Самыми распространенными методологиями на сегодня в российской практике являются нотации ARIS * с одноименным инструментарием и UML **. Разработка СЭД - это всегда проектная деятельность, у которой есть начало и конец. Разработка заканчивается передачей системы в промышленную эксплуатацию и началом процесса сопровождения СЭД.

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

1. Каскадная модель.

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

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

2. Итерационная модель.

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

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

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

Тем не менее, независимо от выбранной модели разработки, в каждой из них есть стадия формирования требований к создаваемой СЭД. Эта стадия и правила создания самого ТЗ описаны в российском законодательстве, а именно в ГОСТах 34-й серии. Основные документы - ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание авто­матизированной системы и РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

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

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

Согласно ГОСТ 34.602-89, основными разделами ТЗ являются:

1. Общие сведения.

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

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

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

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

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

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

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

9. Источники разработки.

Все эти разделы могут быть разбиты на подразделы и могут включать приложения, которые приводятся в конце документа и оформляются как приложения к ТЗ. Такой же состав имеет и ЧТЗ, которое может создаваться при итерационном подходе в больших проектах для уточнения требований. ТЗ на СЭД должно оформляться на листах формата А4 по ГОСТ 2.301-68* без рамки, основной надписи и дополнительных граф к ней.

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

Титульный лист ТЗ содержит следующие реквизиты:

Гриф «Утверждаю»;

Полное наименование СЭД;

Наименование документа (в нашем случае - «Техническое задание» и «Частное техническое задание»);

Код документа;

Количество листов;

Место составления документа.

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

Код ТЗ на СЭД - это обозначение конструкторского документа, которое присваивается заказчиком или разработчиком документа согласно ГОСТ 2.201-80**. Код состоит из следующих частей: первые 4 символа - код организации-разработчика, следующие 6 символов - код классификационной характери­стики, следующие 3 цифры - порядковый регистрационный номер. Например, номер ТЗ может выглядеть так:

ЦНТП. 425180.048.

Особенности написания некоторых разделов ТЗ

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

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

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

Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании.

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

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

В данном разделе должны быть описаны следующие требования:

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

2. Требования к функциям (задачам), выполняемым систе­мой, должны содержать описание функционала подсистем (модулей) СЭД.

3. Требования к взаимодействию подсистем (модулей) СЭД должны описывать механизмы взаимодействия подсистем (модулей).

4. Требования к взаимосвязи со смежными системами организации должны описывать, какие системы являются смежными и как они могут быть связаны с СЭД.

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

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

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

7. Требования к администрированию системы с описанием ролей и обязанностей администраторов системы.

Раздел «Состав и содержание работ по созданию системы» целесообразно делать в виде таблицы с указанием наименования этапов работ по созданию СЭД, примерных сроков начала и окончания этапов, а также результатов окончания этих этапов.

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

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

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

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

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

При этом в тексте ТЗ должны быть проставлены ссылки на все источники разработки. Указание того или иного источника должно быть обоснованным и подтверждаться в тексте ТЗ.

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

* ARIS (англ. Architecture of Integrated Information Systems) – принадлежащие компании Software AG методология и тиражируемый программный продукт
для моделирования бизнес-процессов организаций.
** UML (англ. Unifi ed Modeling Language) – язык графического описания для объектного моделирования в области разработки программного обеспечения; был создан для определения, визуализации, проектирования и документирования в основном программных систем.