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

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

Попробуйте посмотреть нижеприведённые ссылки может как-нибудь поможет.
http://tepmoc.narod.ru/documets/FAQzakaz/tz.htm
http://tepmoc.narod.ru/documets/FAQzakaz/index.htm

похоже с ГОСТами, цепная реакция может получиться . Но, теперь хоть имеется общее представление. Большое спасибо ответившим.

Есть статья Как писать техническое задание?!, в ней найдете и ссылки на соответствующие ГОСТы.

Как говаривал генерал Лебедь - "Очень не советую"

А Заказчик никогда толком не знает, что хочет. Поэтому ТЗ всегда пишет Исполнитель.

Спасибо, хорошо хоть статья с юмором написана, лично на меня эта тех. док. беспросветную тоску нагоняет .

Поверьте опыту. Какое ТЗ, таков и конечный результат.

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

да, похоже составление ТЗ совместно с заказчиком, задача не только техническая, но и политическая...

Вот еще один практический совет: если разрабатываете ТЗ на АС - потребуется ГОСТ 34.602, если ТЗ на софтину - ГОСТ 19.201, но разработать ТЗ на изделие по ГОСТ Р 15.201 невозможно. ГОСТ Р 15.201 - это самая настоящая идеологическая диверсия, поскольку в нем отсутствует структура и содержание документа Техническое задание. Что и как писать - одному грефу известно.

Разумнее всего пойти "от обратного", взять ГОСТ 2.601-95 - руководство по эксплуатации на изделие и вывернуть его наизнанку - переделать сведения на требования. например:

Назначение изделия - Требования к по назначению
Технические характеристики - Требования к техническим характеристикам
Состав изделия - Требования к составу изделия
и так далее.

Смело можно воспользоваться ГОСТ 2.114, поскольку ТУ и ТЗ - "те же ..., только в профиль"

А вот с этим можно несогласиться, т.к. ТУ - условия, ну мало ли они какие, они могут выполняться, а могут и нет. ТЗ же есть задание о выполнении условий. В конечном счете все зависит от требований заказчика. Хочу просто этим сказать, что ТУ и ТЗ все же вещи разные, хоть и имеют много общего.
Можно так же добавить следующее, что 100% выполнение ТЗ всех ТУ является - качеством продукции.

Должны выполняться. Именно должны.

Тот, кому лениво разрабатывать ТЗ самому, может смело позаимствовать ГОТОВЫЕ ОБЩИЕ разделы ТЗ здесь.

Ссылка изменилась - http://authorit.ru/ а отредактировать предыдущий пост не удается

На двух предприятиях, где я работал раньше многое тоже было наизнанку. Сначала появлялась идея. Затем искался заказчик (например энергосетьпроект). Узнавалось что нужно заказчику, как примерно он видит устройство. Устройство разрабатывалось за счёт денег из других проектов с возможностью нескольких сценариев. Уже после этого составлялся бизнес-план. И только после этого писалось ТЗ. Закзчик думал, что он управляет разработкой ТЗ, но это мы вели его по одному из сценариев . ТЗ писал я, а начальник наставлял. Главное по его мнению, чтобы ТЗ был "черновиком" ТУ. Хозяин-барин.
Потом после согласования ТЗ мы в довольно сжатые сроки выдавали готовое изделие. Заказчик доволен оперативностью.
Минусы: на малом предприятии трудно изыскать средства на неутверждённую разработку.

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

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

Тут вот какая штука. Если работа типовая, тыщу раз выполненная ранее, тогда можно пойти по цепочке ТЗ-ПМ-РЭ. Без проектирования. В этом случае ТЗ может содержать кучу конкретики - типа, каналы связи организовываем по технологии Ethernet с применением маршрутизаторов Cisco и так далее.

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

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

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

Статья (с редакционой правкой) ранее опубликована в украинском журнале "Мир Автоматизации". На сайте - авторский вариант.

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

[quote name='dissector' date='Mar 9 2006, 15:32' post='93687']
[quote]
Если проект разрабатывается, то в документах проекта приводится обоснование выбора, скажем, оборудования, а также подтверждается соответствие выбора оборудования требованиям ТЗ.
[/quote]
Ну вот это кстати не обязательно.

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

Есть тоже интересный материал
Гайка М3 и ТЗ на разработку http://iosifk.narod.ru/nat_m3.pdf

[quote name='dissector' date='Mar 9 2006, 15:32' post='93687']
[quote]Поясняю сказанное словами Требование ТЗ - пропускная способность канала связи д.б. не менее 1200 бит/с. Решение в проекте - канал связи организован с применением технологии Ethernet. Решение обоснованное, поскольку однозначно перекрывает требование ТЗ по скорости обмена данными. Поясняющая картинка здесь, в подразделе Повышение согласованности технической документации.
[/quote]

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

Как это? Необязательно доказывать соответствие технических средств требованиям ТЗ по функционалу, по техническим параметрам и характеристикам?

А существуют ТУ, положим, на буржуйский модем Zyxel 336E+? Нет, скорее всего, его просто как-то сертифицировали - и все. Но сертификатам верить не всегда можно. Покупаются легко.