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

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

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

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

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

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

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению	ГОСТ 34.602.89 Техническое задание на создание автоматизированной системы
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надежности	4.1.4. Требования к надежности
	4. 1.5. Требования к безопасности
	4. 1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4. 1.10. Требования по сохранности информации при авариях
	4. 1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4. 1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4. 1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4. 1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приемки	6. Порядок контроля и приемки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

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

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

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

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

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

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

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

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

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

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

Создание информационной системы «Единое окно» должно обеспечить:

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

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

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

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

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

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;
• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

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

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

Требованиям к видам обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При разработке любого проекта. Как оформляется этот документ? Об этом будет рассказано в статье.

Техническое задание - что это такое?

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

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

Зачем техническое задание заказчику?

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

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

Зачем техническое задание исполнителю?

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

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

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

Начало составления документа

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

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

Требования и сроки

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

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

Ответственность и отчетность

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

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

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

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

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

Просто стоит запомнить несколько простых правил:

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

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

Стоит напомнить и о том, насколько важно сверяться с нормами: будь то ГОСТ, нормативные или правовые акты, локальные акты и т. д.

Одной из главных составляющих сайта является качественный контент. Этого мнения придерживаются и отечественные SEO-специалисты, и их зарубежные коллеги, нередко отписывая формулировки вида “Content is a God”. С этим не поспоришь - качество контента напрямую влияет и на ряд других как технических, так и поведенческих показателей сайта. Если вы не можете самостоятельно написать интересный и качественный SEO-оптимизированный текст, то необходимо прибегать к услугам копирайтера.

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

Подготавливаем материалы для копирайтера

В первую очередь необходимо выбрать общую тематику текста, а после этого - конкретную тему для статьи. Объясняем на примере: если вы ведете кулинарный блог, то в первую очередь нужно определиться с общей тематикой, которая вам необходима - возможно, в первую очередь стоит описывать первые блюда, возможно - десерты и т.д. Выбрали? Тогда следующий шаг - выбор темы для статьи, к примеру “Любимые десерты заключенных Алькатраса” или “ТОП-10 десертов в Бельгии”.

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

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

Как не следует составлять ТЗ

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

Заказ: подробно описать процесс разведения рыбок в аквариуме, около 4-6 тысяч символов без пробелов.

Тема: аквариумные рыбки-меченосцы.

Нужно написать читабельную и интересную статью по теме, указанной выше. На написание статьи дается 1 сутки, но если будет готова на 3-4 - тоже хорошо. Уникальность должна быть 100%, в середине и в конце текста должны быть ключи из названия статьи.

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

Как писать техническое задание на программу по ГОСТ 19.201-78?

Создан 15.02.2010 15:50:53

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

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

Лист утверждения и титульный лист

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

Информационную часть (и), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]

Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.

Изменения и дополнения

Для внесения или дополнений в техническое задание на последующих или выпускают дополнение к нему. и дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]

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

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

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

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

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

Любые манипуляции с разделами - строго по с.

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

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

Введение

В разделе «Введение» указывают, краткую характеристику области применения или и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]

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

Наименование программы

Наименование программы – «Текстовый редактор для работы с файлами формата rtf».

Краткая характеристика области применения

Программа предназначена к применению в профильных подразделениях на объектах заказчика.

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

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

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

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

[из п. 2.2 ГОСТ 19.201-78]

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

Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.

Удобно воспользоваться разделом «Общие сведения» , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.

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

Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»

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

В разделе «Назначение разработки» должно быть указано и эксплуатационное назначение или [из п. 2.3 ГОСТ 19.201-78]

Функциональное назначение

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

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

Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?

Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.

Применим формальный подход:

Эксплуатационное назначение

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

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

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

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

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

[из п. 2.4 ГОСТ 19.201-78]

Если существуют стандарты, содержащие общие (технические) требования к программе, или, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.

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

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

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

Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая. Применение клише - шаблонного построения фраз - детально расписано в статье «».

Требования к организации входных данных

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

Любой иного, но с расширением rtf, открываться не должен.

Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного, отформатированного, к примеру, в формате ext3, открываться не должны.

Требования к организации выходных данных

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

Требования к временным характеристикам

Требования к временным характеристикам программы не предъявляются.

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

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

В подразделе «Требования к надежности» должны быть указаны требования к обеспечению функционирования (обеспечения, контроль входной и выходной информации, после и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]

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

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

Требования к обеспечению надежного (устойчивого) функционирования программы

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

• организацией бесперебойного питания технических средств;
• использованием программного обеспечения;
• регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
• регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие.

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

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

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

Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.

Время восстановления после отказа

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

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

Отказы из-за некорректных действий оператора

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

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

В подразделе «Условия эксплуатации» должны быть указаны (, относительная влажность и т.п. для выбранных типов), при которых должны обеспечиваться заданные характеристики, а также, необходимое количество и персонала [из п. 2.4.3 ГОСТ 19.201-78]

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

Климатические условия эксплуатации

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

Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести в полном объеме за счет исполнителя.

Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!

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

Требования к видам обслуживания

Программа не требует проведения каких-либо видов.

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

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

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

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

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

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

Пользователь программы (оператор) должен обладать практическими навыками работы с операционной системы.

Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).

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

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

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

В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]

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

В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:

• процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
• материнскую плату с FSB, ГГц - 5, не менее;
• оперативную память объемом, Тб - 10, не менее;
• и так далее…

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

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

При необходимости должна обеспечиваться и [из п. 2.4.5 ГОСТ 19.201-78]

Требования к информационным структурам и методам решения

Иформационная структура файла должна включать в себя текст, содержащий, предусмотренную спецификацией формата rtf.

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

Требования к исходным кодам и языкам программирования

Исходные коды программы должны быть реализованы на C++. В качестве интегрированной программы должна быть использована среда Borland C++ Buider.

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

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

Требования к защите информации и программ

Требования к и программ не предъявляются.

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

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

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]

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

Требование к маркировке

Программное изделие должно иметь маркировку с обозначением компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.

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

Требования к упаковке

Упаковка программного изделия должна осуществляться в упаковочную тару ().

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

Условия упаковывания

Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.

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

Порядок упаковки

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

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

Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.

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

На верхний слой прокладочного материала укладывается - упаковочный лист и ведомость упаковки.

Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.

Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.

В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.

Габариты грузового места должны быть не более 1250 820 1180 мм.

Масса НЕТТО - не более 200 кг.

Масса БРУТТО - не более 220 кг.

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

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

В подразделе «Требования к транспортированию и хранению» должны быть указаны для условия, места, условия хранения, условия складирования, в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]

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

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

Условия транспортирования и хранения

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

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

• температура окружающего воздуха, °С - от плюс 5 до плюс 50;
• , кПа - такое-то;
• относительная влажность воздуха при 25 °С - такая-то.

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

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

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

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

В разделе «Требования к программной документации» должен быть указан предварительный состав и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]

Предварительный состав программной документации

В состав программной документации должны входить:

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

Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]

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

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

В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]

Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.

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

Экономические преимущества разработки

Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:

На стадии «Технический (и рабочий) проект» должны быть выполнены перечисленные ниже этапы работ:

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

На стадии «Внедрение» должен быть выполнен этап разработки «Подготовка и передача программы».

На этапе разработки техзадания должны быть выполнены перечисленные ниже работы:

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

На этапе разработки программы должна быть выполнена работа по (кодированию) и.

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

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

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

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

В разделе «Порядок контроля и приемки» должны быть указаны виды и общие требования к приемке работы [из п. 2.7 ГОСТ 19.201-78]

число рабочих мест		разработка	экономические преимущества

Виды испытаний

должны проводиться на объекте заказчика в сроки…

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

Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в.

Общие требования к приемке работы

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

Приложения

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

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

[из п. 2.8 ГОСТ 19.201-78]

Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Например:

• ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению;
• и так далее..

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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