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

наша фирма решила разработать БД или АСУ или что-то в этом духе,я просто абсолютный чайник, и поставить сие чудо на новую платформу,делается это из-за того что текущая программа,в которой мы собственно и работает, кого-то не устраивает...и поэтому каждому отделу дали задание написать ТЗ и разъяснить умельцам-программистам что мы хотим и как мы хотим... но это еще и должно выглядеть правильно...подскажите, как вообще его писать и как правильно назвать его (разработка ТЗ на создание БД каким-то отделом какой-то фирмы или разработка ТЗ на создание части АСУ для отдела такого-то фирмы такой-то...), и что там вообще должно быть...ну точно не так "я хочу, чтобы папки и подпапки выделялись разными цветами как в такой-то проге 1990 года, хочу чтобы при просмотре данных о том-то можно было просмотреть прикрепленные документы к нему не зависимо от прав входящего в систему..)

Дааааа..... !

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

А если серьезно, то ТЗ Вы не напишете, т.к. у вас не хватит квалификации. Но Вы можете попробовать создать документ(ы) с условным названием "Информационные потоки в отделе ...".

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

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

Всё, задание выполнено! Все, что Вы могли, Вы сделали.
Т.к. из вашего письма понятно, что Вам это не нужно, этого достаточно.

Лозунг, который когда-то висел над моим рабочим столом и приводил в ярость моих командиров:
ДЕЛАЯ ЧТО НИБУДЬ БЕСПОЛЕЗНОЕ, СЛЕДУЕТ ОГРАНИЧИТЬСЯ САМЫМ НЕОБХОДИМЫМ!

Успехов 

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

В принципе у вас может получиться составить инфологическую модель данных (http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85). В принципе этого достаточно.

Рекомендация. Не используйте ER модель. Вместо этого для каждого объекта составьте таблицу, примерно как показано здесь: http://blog.shumoos.com/archives/145

А если серьезно, то ТЗ Вы не напишете, т.к. у вас не хватит квалификации. Но Вы можете попробовать создать документ(ы) с условным названием "Информационные потоки в отделе ...".

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

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

Всё, задание выполнено! Все, что Вы могли, Вы сделали.
Т.к. из вашего письма понятно, что Вам это не нужно, этого достаточно.

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

текущая программа,в которой мы собственно и работает, кого-то не устраивает...

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

1. Опишите в общем виде какие функции ваш отдел выполняет в текущей системе.
Сильно зависит от деятельности которую выполняет ваш отдел
Например для отдела снабжения:
Работа со справочной информацией.
  Ведение справочника Поставщиков (контрагентов)
  Ведение справочника Номенклатура
...
Работа с "транзакциями" (фиксирование фактов и различных событий деятельности и т.п.)
  Регистрация плана поставок
  Регистрация заявок поставщикам
  Регистрация приходных накладных
...
Отчеты
  Формирование отчета по не выполненным заявкам
  Формирование отчета по остаткам на складах
...
Сервисные функции
  Печать комплекта документов по поставке
  Расчет средних цен по поставщикам
  Расчет показателей подразделения

и т.п.

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

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

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

Рекомендация lnew хорошая, это действительно та работа которую вы можете сделать качественно. Но в итоге получится все равно фигня (надо это довести до вашего руководства), п.ч.:
1. Все что вы опишите совсем не факт, что это будт рамки проекта, т.е. все это необходимо автоматизировать.
2. Программисты все равно придут к вам и скажут, что из вашего документа им ничего не понятно, скажите что лобать в программе
3. Будут разрывы и не состыковки с остальными отделами
4. Возможно вы и сами что-то забудете в своем отделе описать или посчитаете это несущественным
5. А компетенции у ваших программистов хватит, чтобы выбрать нужную платформу разработки и разработать то, что вы напишите?
6. Вы уверены, что нужно будет автоматизировать именно так как сейчас у вас происходит в отделе?

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

Поэтому выходы следующие:
1. Нанять организацию, которая вас будет автоматизировать.
2. Если п.1 невозможен и вы хотите делать все своими силами, то нанять Аналитика.
3. Если п.2 невозможен, то выделить из ваших программистов более менее адекватного и опытного человека(людей), который будет прояснять и согласовывать документы (ТЗ так называемое) от всех отделов компании.
4. Со стороны бизнеса (т.е. вас) должны быть люди:
* Один человек от отдела, которые решает все противоречия в отделе
* Один или несколько человек, которые решают противоречия между отделами
5. Ну и нужен человек (типа менеджер), который будет управлять данным проектом.

раньше не было дележки на менеджеров, аналитиков и т.д. Я работала программистом, сверху давали задание автоматизировать то-то и то-то. Обычно программист выполнял дополнительно роль и аналитика и документалиста. Роль манагера - начальник отдела разработки. И главное что бы был спонсор - заинтересованный человек, который бы всех "пинал". Обычно это человек-заказчик автоматизации. Так что автоматизировать можно все и без аналитиков. Узкая специализация конечно очень хорошо. Но сталкивалась и с таким: замечательная система и без аналитика, и плохая система с десятками аналитиков. Важен человеческий фактор. Не главное как ты зовешься, главное что ты делаешь. Думаю и у вас есть разработчик, который осилит аналитику и направит вас на путь истинный. А купить, нанять...проще всего когда есть деньги. С деньгами и дурак умный.

Лозунг, который когда-то висел над моим рабочим столом и приводил в ярость моих командиров:
ДЕЛАЯ ЧТО НИБУДЬ БЕСПОЛЕЗНОЕ, СЛЕДУЕТ ОГРАНИЧИТЬСЯ САМЫМ НЕОБХОДИМЫМ!

Леонид Борисович, мне нравится Ваш лозунг. Не будете против, если позаимствую для себя? )))

Думаю, я не имею на этот лозунг авторских прав. Я его где-то услышал.
С Богом!

Считается что это говорил Себастьен-Рок-Никола Шамфор.

Считается что это говорил Себастьен-Рок-Никола Шамфор.

Спасибо за информацию - теперь и я так буду говорить )