тз для сайтаподскажите... для описания web-ресурса... используеся обчный гост 34 или какие-то особенные есть?

При условии необходимости создания документации требований имеено по ГОСт 34.602 -- вполне можно написать ТЗ на web-ресурс и по этому шаблону. Я сейчас как раз занимаюсь тем, что вместе с аналитиками одного проекта пишем документацию требований и проектируем часть внутрикорпортативного портала. Мы сначала написали Vision, где перечислили основные бизнес-требования (которые включали краткое описание проблематики со ссылкой на уже описанные ранее бизнес-процессы в виде положений и инструкций, бизнес-цели ассоциированные с созданием тематического портала и критерии их достижения, основные потребности заинтересованных лиц, фичи в соотнесении с потребностями и т.п.). Сейчас мы описываем пользовательские требования в виде вариантов использования, где показываем основные юзкейсы. Следует отметить, что не для всех порталов/сайтов, особенно чисто информационных, есть возможность расписать все "красиво" на юзкейсах. Часть (иногда и все) пользовательских требований имеет смысл формулировать "в стиле agile", если это допустимо. Повторюсь, что пользовательские требования это взгляд на ПО со стороны пользователя. При этом логично группировать в финальном документе спецификации каждого юзкейса по Экторам.
Далее будем писать функциональные требования (какие свойства должны быть у ПО для поддержки пользовательских и бизнес-требований). Тут будем группировать требования по выделенным "подсистемам" -- web-форум, поисковая машина, новости, управление контентом и т.п. ... Потом аналитики желают проектировать это все на UML :-) ... покажем и UML ;-).
Есть одно но -- зказчик все это описание желает иметь в форме одного документа под названием "Технический проект", не взирая на то что это по ГОСТ есть стадия а не документ :-).

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

Petro123
авторВ соответствии с п. 1.3.4 ГОСТ 34.201-89 «В зависимости от применяемых методов проектирования и специфики создаваемых АС допускается:
1) разрабатывать групповые документы;
2) выпускать документы отдельными самостоятельными частями, соответствующими разделам основного документа;
3) расширять номенклатуру документов, установленную настоящим стандартом.
Допускается также сокращать или изменять номенклатуру документов, установленную настоящим стандартом.»
IMHO просто если у Вас RUP, то ТП никак, если какое-нибудь ХР то можно без всяких документов.

Допускается все что угодно, особенно если это "что угодно" прописано в контракте. Хуже, когда заказчик думает что он знает ГОСТ. Еще хуже, если он думет что знает ГОСТ и RUP. Совершенно без разницы по какой методологии вы работаете, но если вам нужно по контракту выдать документацию по ГОСТ 34, то никуда не деться и придется ее выдать. Вопрос только в мэппинге между артефактами или их кусками с документами ГОСТ в случае того же RUP.