\r
\r
Уважаемые господа разработчики, менеджеры, а также все те, кто имеет отношение к производству софтверных решений и баз данных! \r
\r
-- Мысль о создании данного топика/ветки/темы навеяна мне различными разрозненными топиками по общей тематике и, как я понимаю, достаточно актуальной . Например, самые последние это:\r
Проектирование БД / Нужна помощь по документированию проекта!, Проектирование БД / Этапы проекта: ТЗ, Проектирование БД / Обмен информацией между 2 людьми при совместной работе над проектом БД, Просто треп / кто как пишет документацию к своим нетленкам? и т.д\r
\r
-- Почему выбран раздел Проектирование БД ? Просто на данный момент на SQL.RU нет раздела форума наподобии "Сопровождение (ведение) проекта". Потом так сложилось исторически (в т.ч и в России), что как правило документацией а.к.а описанием системы занимаются аналитики-проектировщики ( это их почти прямая обязанность ), те же менеджеры или руководители проектов ( также отчасти пряма обязанность, а так... ну кому еще можно доверить составление красивого, например, ТЗ на сотню страниц ).\r
\r
-- Почему какая-то одна ветка? Потому что документы, конечно, разные, но тема или предмет (проектное документирование) эта каждый раз одна и та же. Далее: удобно обсуждать один и ту же тему в одном месте.\r
Зачем новый топик? IMHO потому что названия других топиков хотя и близки по духу, но более специфичны\r
\r
-- Что именно могло бы здесь обсуждаться? Согласно названию - проектная документация , а также: КОМУ, для ЧЕГО и ПОЧЕМУ она необходима, КАК ее лучше получать - методы и средства, что такое хорошая и что такое плохая документация. Однако, методы и/или средства могут отличаться в зависимости от выбранного процесса создания ПО, но все равно большинство документов одного типа (например, ТЗ, ТП или словарь) имеют много общего в плане того, ЧТО обязательно должно быть описано даже при разных процессах (например, RUP, MFC), более того - даже при разных подходах (ООАП, структурный, смешенный)\r
\r
Благодарю за внимание!

...из последнего (кто как пишет документацию к своим нетленкам?):\r
2 Niemi: \r
Странно, а нас учили наоборот. Сначала документация, потом проект, потом анализ , потом доработка и далее по кругу. Короче спиральная модель. Но можно и другими путями, а документация имхо должна быть. \r
\r
"Модель" (процесс) может быть любой, но то, что документация должна быть - это так сказть modus primum, к-рый почему-то всегда надо объяснять только особо упертым или ленивым людям, новичкам в разработке софта или тем, у кого по жизни 2 десятка таблиц или 1 EXEник, к-рый кроме их авторов никому больше не нужем\r
\r
2 Chicago: \r
...И, к сожалению, я не знаю ни одного средства, охватывающего все аспекты процесса документирования программного продукта. \r
\r
Есть такие средства, например, та же SoDA (software documentation automation), используемая в процессе RUP. Как это наприер работает? Требования к ИС/ПО, варианты использования(ВИ) и т.д то, что определяет концептуальную модель системы хранится в едином репозитории требований (БД средства RequisitePro), там же хранятся все описания этих объектов, связи-трассировки их между собой, связи с Word-документами, в к-рых все это описывается (т.е создаешь/изменяешь в Word как обычно и все синхронизуется с репозиторием). Далее: например, на стадии получения и анализа требований документы могут быть разные ТЭО, ТЭОиП, ТЗ, описания ВИ, модель GUI и т.д, но всегда с помощью SoDы можно сгенерить документ, показывающий связи между нужными объектами. Например, описания ВИ с картинками пользоват.интерфейса из модели GUI и еще какие-то системные требования.\r
Кстати, с процессом (т.е с софтовым фреймворком его реализующим) поставляются различные Word-шаблоны, но ничто не мешает наделать своих. Вобщем про это можно долго рассказывать и еще дольше док читать, если есть желание, то лучше здесь: Проектирование БД / Обсуждение и Вопросы по Rational Rose (и SoDA, Data Modeler, *Link и тд)\r
Про другие рассказывать дорогие продукты для бизнес/системного-анализа(инжиниринга), например, ARIS, где все это сделано вообще на высшем уровне рассказывать даже не хочется по причине их просто офигительной цены и редкости\r
\r
...Так что используем, то что нам кажется разумным. На стадии постановки это, как правило, CASE-рисовалки и обычные текстовые документы. \r
\r
Вообще это уже не стадия постановки задачи исполнителю заказчиком, а стадия разработки , т.е стадия постановки задачи программистам (ОО или БД) аналитиком-проектировщиком\r
\r
...На стадии описания полученного результата это MS Word. Примитивно, но позволяет хорошо оформить текст. И в типографию можно документ передать. \r
\r
Нисколько не примитивно, потому ничего другого лучше на сегодня не придумали. :) Другое дело перетаскивать руками картинки из того же ErWin, например, очень неэффективно, лучше сменить CASE-средство чтобы оно автоматически "выплевывало" то, что нужно в Word, если тем более юзается нелицензионный CASE\r
\r
...Лучше всего у нас разработан процесс документирования исходных текстов. Существует внутренняя инструкция о том как какие объекты в программе следует описывать и задающая шаблоны комментариев. Используются средства, позволяющие потом по этим комментариям получить печатное руководство. \r
\r
IMHO это бесполезное и порочное занятие писать комментарии в программных текстах. Хотя это, конечно, если нет визуальных моделей, например, тех же диаграмм деятельности или взаимодействия, к-рые описывают все взаимодействия между объектами и создаются при полноценном ООАП-подходе, например, как в RUP\r
\r
...Ну и конечно все артефакты хранятся в системе контроля версий. \r
\r
И документация (точно запрос на ее изменение) должна изменяться автоматически согласно изменению артефактов, интересно, как вы это делаете? Мы, например, с помощью Rational ClearQuest (входит в Rational Suite) т.е средства управления запросами на изменения (DCT- defect & change tracking или CRM - change reqest management как часть UCM - unified change management)\r
\r
2 1024: \r
А ваще можно посмотреть на справку от МС Офис. От 97 ещё хоть что-то найти можно было, в 2000 - какой-то тихий ужас, выскакивают какие-то скрепки, свистелки-перделки, ничего не ищет, задаёт идиотские вопросы, кошмар. \r
\r
Ничего подобного - в 2000/XP для разработчика док точно такой же, другое дело что нужен минимум CD Office Pro (кажись) и при установке нужно указывать (это точно) что нуно расширенную документацию устанавливать. Например, я под Access XP, Word, Excel пользуюсь: есть все VBA, JetSQL, вся объектная модель с описанием всех свойств/методов. А тем, кого эта документушка не устраивает - добро пожаловать в MSDN - office development сет (как обычно только по будням или круглосуточно. А свистемлки-перделки и прочие детсадовские скрепки (хотя F1 или как там эта хрень называется, меня слегка прикалывает) отключаются :) \r
\r
2 ТиБиБи: \r
Изобретать свой репозитарий ну совсем не хочется... :~)\r
....\r
Если речь идёт о базе данных, то предпочитаем создавать и сопровождать ее в ERwin - тщательно прописываем логические и физические диаграммы... там, кстати, тоже приветствуются обстоятельные названия полей, включающие в себя принятое в проекте обозначение таблицы.... \r
\r
А зачем изобретать, когда пора переходить к полностью цивилизованным (где есть все удобства от репозитория до создания проектной документации) и интегрированным (не одно-два разрозненных CASE-средства) процессам создания ПО (см. в этом посте выше, для Chicago )\r
\r
На основе многолетней практики у меня сложилось твёрдое убеждение, что для программиста лучше всего подходит исключительно самодокументированный код. У меня объём комментариев, впрочем, составляет лишь около 10% общего объёма в килобайтах. \r
\r
Это вообще древняя и на сегодня уже порочная практика - писать вообще комментарии, необходимая только в случае неиспользования визуального моделирования и CASE-средств или неправильного их использования\r
\r
Основные недостатки этого подхода ("крапание" комментариев):\r
=> Без комментариев можно обойтись заменив его более унифицированным и легко воспринимаемым\r
визуальным моделированием, содержащим все необходимые модели, к-рые наглядно рассказывают\r
о работе системы\r
=> Комментарии пишутся как правило людьми, а люди как известно используют некий диалект,\r
к-рый у каждого свой даже в небольшой команде. Результат - непонимание\r
("чего он имел в виду говоря: юзер включает чек и жмет ОК, к-рый генерит ивент и к-рый поднимает\r
мутекс и лочит таблу, затем килит тред и шатдаунит машинку сисадмина") \r
=> Глобальные программные комментарии относятся к неотслеживаемым объектам \r
как и сами "куски" программных текстов (когда они генерируются в большинстве CASE-средств)\r
в отличии от других объектов, например, классов или таблиц, ассоциаций, методов или хранимых\r
процедур, все изменения свойств к-рых отслеживаются. Единственный способ отследить изменения\r
- использовать комментарии к модели или через ссылку на внешний файл (типа class, sql, frm и т.д),\r
но и такой способ неудобен и избыточен и аналогичен сравнению 2 файлов с помощью\r
команды FC\r
\r
Хорошее документирование означает не только тщательно продуманные имена, конечно же, но без них остальное документирование вообще не имеет смысла, по моему убеждению. \r
\r
Да, понятные и правильные имена важны, но они не помогут, если не будет визуальных моделей в CASE. Правильно? :)\r
Также приятно когда эти имена объектов инвариантны вдоль как жизненного цикла проекта, так и вдоль связей трассировки модельных артефактов проекта (во, сказанул-то!) Т.е, к примеру, у меня в Словаре появился термин "клиент", в ТЗ у меня тоже везде "клиент", в ТП, модели ВИ, классов, в C++ - "Customer", в ТЗ на БД и в модели данных у меня тоже "Customer". Если я хочу найти проектный документ или модель я буду искать всего по 2 словам: "клиент" и "сustomer", а не "client", "cust", "klient" или еще что-то\r
\r
Созавать какую-либо документацию для последующих программистов ПОСЛЕ завершения проекта IMHO осмысленно только для по-настоящему крупных проектов, поскольку, прежде всего, поздновато уже описывать, да и дорогостоящее это занятие... \r
\r
Нет, даже в маленьких проектах тоже надо документировать. И абсолютно согласен, что создавать документацию после завершения ЖЦ проекта неправильно , но нужно , например, чтобы в дальнейшем цивилизованно поддерживать систему. Вообще документация должна рождаться по мере разумной необходимости и согласно нуждам тех, кому она действительно нужна:\r
\r
* Руководству и менеджерам (заказчика и исполнителя)\r
- чтобы понимать суть системы, отслеживать состояние проекта\r
и корректировать план: \r
договор, ТЭО, ТЗ, Словарь; смета, план проекта (календарный, работ и т.д).\r
\r
* Аналитикам и проектировщикам исполнителя\r
- чтобы понимать суть системы, укладываться в проект и создавать Словарь, ТЗ,\r
необходимые модели системы, ТП, модель тест-кейсов (test case): \r
план работ.\r
\r
* Программистам, Web-дизайнерам, писателям прочего контента и документации пользователя \r
- чтобы понимать суть системы, укладываться в проект и писать необходимый\r
код, контент для системы: \r
план работ; ТЗ, ТП, Словарь; ООАП-, Web-модели и модели данных.\r
\r
* Тестерам (заказчика и исполнителя):\r
- чтобы понимать суть системы, укладываться в проект и тестировать систему: \r
план работ; модель тест-кейсов; ТЗ и/или ТП, документация пользователя.

2 funikovyuri: \r
круто. Вообще нравятся твои треды \r
\r
Спасибо, стараемся как говорится чтобы уровень SQL.RU был на "уровне" :)\r
\r
К стати, что используете вы RUP или PD??? RUP по-моему не самое лучшее решение если проектируется БД. (Т.е. именно Data Modeller. ) Хотя поддержка UML в розе скорее всего лучше ( одно присутствие в Booch\'a уже много стоит ) \r
\r
Используем и то и то. Я тут вот ответил по поводу RUP, DataModeler (создание модели данных) и PD (финальная доработка модели). Загляни в Проектирование БД / Обсуждение и Вопросы по Rational Rose (и SoDA, Data Modeler, *Link и тд)\r
\r
Насчет бессмысленности коментариев в исходных текстах - я думаю сдесь главное знать меру. Допустим коментировать код на уровне методов - по-моему обязательно. \r
\r
А цель такого комментирования? Вот что говорится, например, в документации к RUP по этому поводу: Root -> [Examples Overview] -> [C++ Programming Guidelines] (URL: file:///<RUP_doc_dir>/manuals/cpp/cpp.htm), раздел Comments: \r
Comments should be used to complement source code, never to paraphrase ( прим: пересказывать ) it:\r
\r
* They should supplement source code by explaining what is not obvious;\r
they should not duplicate the language syntax or semantics.\r
* They should help the reader to grasp the background concepts,\r
the dependencies, and especially complex data encoding or algorithms.\r
( прим: т.е особенности, к-рые используются, но не описаны в моделях )\r
* They should highlight: deviations from coding or design standards;\r
the use of restricted features; and special "tricks."\r
( прим: т.е при использовании нестандартных или недокументированных системных возможностей )\r
\r
For each comment, the programmer should be able to easily answer the question: "What value is added by this comment?" Generally, well-chosen names ( прим: ну имена тоже еще не все ) often eliminate the need for comments. Comments, unless they participate in some formal Program Design Language (PDL), are not checked by the compiler; therefore, in accordance with the single-point-of-maintenance principle, design decisions should be expressed in the source code ( прим: имеются в виду низкоуровневые "трики", т.е к-рые не изображены на визуальных моделях ) rather than in comments, even at the expense of a few more declarations. .......\r
\r
...С другой стороны коментировать сами методы или классы бессмыслено - это общеизвестный факт, но ему мало кто следует. ОО система описывается только сценариямы работы множества объектов. \r
\r
Вот это точно пустая работа\r
\r
P.S. К стати мы сейчас стараемся использовать PD + VS.Net. И вся сопутсвующая проекту документация создается этими программами. Пытаемся сдандартиризовать процесс доступа к ней - через web \r
\r
Я бы тоже может и использовал бы PD (все таки у него и ГУИшник и др. возможности лучше, чем у той же Rоse), если бы у него были все возможности такие как у продуктов Rational Suite по созданию софта - т.е "от и до"

2 funikovyuri:
1. Насчет RUP. Все таки я стараюсь себя сдерживать. Уж больно он далек от реальности. К тому же мне обязательно потребовался бы Data Modeler. А я не сторонник мешать ООП и реляционную модель

А другого выхода просто нет или тогда приложением и БД нужно вообще заниматься как вообще не связанными задачами. Кстати, такой подход на Западе и в России практикуется, особенно в крупных компаниях, т.е там вообще есть объектные аналитики/программисты, а есть реляционные и они работают только над своими задачами, объектников не подпускают к базам, а датабейсеров к приложениям.
IMHO это не очень хорошо, потому что:

1) БД - это целая отдельная подсистема (хотя и идет как компонент), но все равно
ее модель и логика работы определяются "сверху" (т.е требованиями и UC),
т.е нельзя полноценно проектировать или рассматривать независимо объекты
и сущности, все равно чтобы понять всю картину надо все вместе
2) когда разработчик переключается с одного (классы,объекты) на другое (БД) и наоборот
- для мозгов гораздо полезнее, люди мыслят гораздо гибче

2. Под коментариями на уровне метода я имел ввиду как раз то что написано Root -> [Examples Overview] -> [C++ Programming Guidelines]
К стати на данный момент мне кажется очень привлекательным использовать для этого возможности VS.Net ( например /// )

А, ферштейн :) Я вообще не против коментариев только из принципа, тем более есть отличное высказывание (забыл чье, то ли Росса, то ли Йордана):

Одна диаграмма заменяет сотню строк, а сотня строк тысячу диаграмм.

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

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

* тривиальный алгоритм, никаких особенностей , но просто человек 1-й день программирует на C#
- отлично, ведь эти комментарии нужны только ему, пусть будут;

* специальный бэкдор, иксплойт и т.д , т.е то, что лучше скрыть от "посторонних" глаз
- no comments ;о)

3. Вот это точно пустая работа Совсем не понял. А для чего тогда строить модели? Это вообще-то и есть графическое представление системы классов/объектов. Да и не я это придуал - тот же Голуб с Бучем об этом давно говорили.

Сорри, забыл "отрезать" кусок цитаты: "ОО система описывается только сценариямы работы множества объектов." - это конечно верно

По мотивам топика Нужна помощь по документированию проекта! (стр.2)...\r
\r
2 Vik98: \r
Речь идет о документировании существующего проекта. \r
Как лучше описать бизнес-логику, построенную на хранимых процедурах?\r
Можно нарисовать алгоритмы, определяющие послоедователность вызова основных процедур. \r
Для каждой хранимой процедуры можно описать \r
название, краткое назначение, алгоритм работы, кем вызывается, кого вызывает (dependences), каким объектами оперирует. \r
\r
Да, если нужно описать абстрактный алгоритм, то для этого подойдут UML диагаммы (видов) деятельностей (Activity diagrams). Если нужно описать кто кого вызывает, в какой последовательности, проверки условий, итерации и т.д, чтобы показать программную реализацию функции или варианта использования (Use case), то для этого подойдут UML диагаммы последовательности (Sequence diagrams)\r
\r
...Мне кажеться, что в современных средствах разработки Rational, Erwin могут быть средства для хранения таких данных. Средства привлекательны тем, что с ними приятно ( удобно) работать и они формируют все необходимые отчеты. \r
\r
Да, Rational Rose и Sybase PowerDesigner поддерживают как UML, так и моделирование данных (Rose на основе нотации UML, PD на основе IE/CODASYL). Что касается Erwin, то он поддерживает только моделирование данных (IE/IDEF1X), а UML поддерживается ParadigmPlus и AllFusion Component Modeler. Т.е используя эти CASE-средства с поддержкой UML вы можете "рисовать" эти диаграммы, комментировать хранимые процедуры и UDF, а также снабжать диаграммы пояснительными комментариями, поясняющими разные ньюансы\r
\r
Но либо я их не нашла, либо их нет. Скажите, пожалуйтса, не нашла? не праивльно использую? нет? \r
\r
Erwin не поддерживает UML. Что именно вы не нашли в Rose?\r
---\r
Топики по теме: Помогите выбрать CASE (сравнение PD, Erwin, Visio), Обсуждение и Вопросы по Rational Rose (и SoDA, Data Modeler, *Link и тд) (Rose Data Modeler, моделирование данных с помощью UML), Стоит ли убеждать заказчика? (стр.2) (ООАП в разработке приложений)

По мотивам топика Проект "образцово-документированная база данных"...\r
\r
2 vdimas: \r
Понимаешь, Cat2, тот же самый Репликант всячески критикует эти ЕСПД, и называет следование этим методикам "кустарным" или там "на коленках...", хотя я так и не понимаю, с чего бы это? С того, что стадия анализа (предметной области) там означает не то, что сейчас подразумевается под этим словом? \r
\r
Привет. Мне просто в лом искать мою же цитату по этому поводу, но ты перепутал: "кустарными методиками" или "на коленках..." я называл "процессы" разработки, когда не используется методология/процесс , а часть ГОСТов 19-й серии (ЕСПД - Единая система проектной документации), т.е стандарты на метод документирования и форматы документов я называл устаревшим по вполне объективным причинам. ГОСТ 34-й серии (АС/АСУ) я также называл излишне перегруженным (если ему следовать "от и до"), т.к многое что там есть просто не нужно для офисных бизнес-систем. Что же касается ТЗ для БД, и устаревшим на сегодня по терминологии \r
\r
Мне наоборот, стандарты из области 9000 кажутся порой нелогичными, и, как бы это выразиться, на дураков и детей глупеньких расчитанных (или на недостаточный уровень общего их образования, что-ли, ну уж черезчур местами много "жвачки" из ничего, оформляли один проект по 9000 - упарились тратить время на бесполезные мелкие подробности) \r
\r
Во-первых, какой именно стандарт 9000? Во-вторых, те же ИСО 900х:2000 наборот очень общие, т.е перечислены основные свойства, к-рым должна удовлетворять система. Я не думаю, что большинство европейских или американских предприятий, сертифицированных по ИСО, имеют своими работниками "дураков и детей глупеньких". Что же касается излишней формализованности процессных систем получаемых под ИСО с т.з, например, документооборота, то это уже затертое клише, к-рое впаривается теми, кто тупо делает реинжиниринг под ИСО, например, для сертификации, т.е формально по бумажке или на бумажках (без модели БП в CASE-средстве), а еще хуже не понимая для чего это нужно. Можно ведь по-разному тот же документооборот организовать: можно сделать бумажный, а можно электронный с бизнес-правилами, когда корректность большинства параметров БП отслеживает ИС, а человек верифицирует самые общие. А вообще любой стандарт, например, тот же SEI-CMM сложен к внедрению, т.к это не просто методология, а уже тяжелый процесс , к-рый должен быть обязательно автоматизирован. Так что дело мастера боится :о)

2 vdimas:
... Разрабатывали систему, ориентируясь на ЕСПД. Потом от нас потребовали сертификацию по 9000 (миллион пунктов). Ну сделали...

Сорри, я не понял: ваш заказчик/руководство потребовал от вас, чтобы процесс (или бизнес-процесс) разработки системы и оргструктура не только соответствовали ИСО 900х, но еще и был сертифицирован? Можно еще несколько вопросов, т.к я лично был знаком только с одной софтверной конторой, сертифицированной по еще сторому 1994-му ИСО:

какова же все-таки была аргументация заказчика (хоть какая-нибудь)?

откуда "миллион пунктов", а если не миллион, то откуда взялась хотя бы
тысяча пунктов?

как делался инжиниринг БП (методы, средства) хотя бы в общих чертах и кем
(вами - разработчиками ПО или сторонними людьми)?

автоматизированны ли были у вас БП разработки, чем и когда ("до" и "после")?

2 Владимир Крылов:
Там везде ГОСТы и как делать, а самого примера ТЗ на разработку БД нету, ну кто нибудь бедь сам делал такие ТЗ, должны ведь где то быть!

В рунете хороших примеров ТЗ ни на БД, ни на ИС/ПО я не видел. Вот несколько ссылок на англоязычные ТЗ на ИС/ПО, где в частности описываются домены, бизнесправила и т.п, т.е легче всего вытащить то, что относится к БД:

Marine Corps Distance Learning Program Learning Management System (LMS) (57 стр.)
  (The Marine Corps Distance Learning Network (MarineNet) provides Marines with global
  access to standardized electronic training and education resources.)
  - словарь, входные данные, отчеты, домены, пользователи.


GESTCO-DSS Software Requirements Specification (44 стр.)
  (The objective of the GESTCO project will be to contribute to CO2 emission
  abatement from power generation and heavy industry.)
  - словарь, входные и выходные данные, матформулы.


Software Requirements Specification for the MDO Application: Aircraft Sizing (27 стр.)
  (..the application computes performance, aerodynamic and weight characteristics
  based on design parameters such as wing area, cruise altitude, mach speed, and various
  weight factors.)
  - словарь, матформулы, входные и выходные данные, обработка ошибок, правила именования и т.д.


WMITS Software Requirements Specifications (19 стр.)
  (The main purpose of WMITS is to help automate the entire process that the Department
  of Environmental Quality (DEQ) Waste Management Division (WMD) staff members perform
  throughout an inspection.)
  - словарь, пользователи, входные и выходные данные, домены, ERD.


Student 1 Interface Software Requirements Specification (13 стр.)
  (The Interface connects to existing databases being developed by another design
  team that contains information about assignments, and displays this information to the user,
  which in this case would be a student.)
  - словарь, входные данные, таблицы, домены, транзакции.

Если еще проще и если вдруг вы не знакомы с этой книгой, то рекомендую- Вендров А.М., "Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие" - М., 2002. 192 с., ISBN 5-279-02440-6 (допущено Минобразования РФ в качестве учебного пособия для студентов..., обучающихся по специальностям 351400 "Прикладная информатика в экономике", 351500 "Математическое обеспечение и администрирование информационных систем"). В главе "1.2. ВЫПОЛНЕНИЕ УЧЕБНОГО ПРОЕКТА" есть разделы "1.2.3. Спецификация структу данных", "1.2.4. Построение начального варианта концептуальной модели данных" для простого примера

.. но не кто не дает, сам этот пример в принцепе на две странице должен быть! ну если у тебя есть этот пример по мылу можешь скинуть 000_corp@mail.ru

К сожалению, у меня все примеры по объему >> 2 страниц и они являются ТЗ на систему в целом, а не только на БД, т.е мне придется за вас вытаскивать то, что относится к БД и т.п, т.к ТЗ целиком - это тоже ведь интеллектуальная собственность

Ну где это видел то? я вот видел когда работу на job.ru искал, там в качестве Теста было, вот это вот реально ТЗ было, дай ссылку где на 32 стр. видел

Объем ТЗ зависит от следующих вещей:

1. назначение ТЗ, т.е если ТЗ будет использоватьтся как конечная спецификация,
  по к-рой система будет разрабатываться, то это подробный => объемный документ;
  если же на основе ТЗ система будет приниматься заказчиком, т.е оно является лишь
  спецификацией, описывающей пользовательские функции и нефункциональные требования,
  то это меньший объем;
2. сложности системы , выраженной в таких метриках как, например, кол-во функций, сущностей и т.п или   если грамотнее, то в функциональных точках.
3. ...чего-то еще...

В топике Как не сделать "вонючий" проект? (стр.4) упоминался пример программы и объем спецификаций требований к ней. Что касается ТЗ на 2-х страницах, то это либо очень простая по функциональности программа, либо разработчик, отвечающий за ТЗ, просто ленится все описывать или заинтересован в том, чтобы требования не были записаны подробно. Например, даже список из 30 названий функций/вариантов использования (UC) - это 1 страница A4 (Arial 10pt, 2 ln), а если к этим названиям прибавить достаточно краткое описание из 5-10 строк, то соответственно 5-10 страниц, не говоря уже про скрины ГИП и нефункциональные требования (пользовательская среда, архитектурные ограничения, производительность, надежность и т.п). Тоже самое верно и по отношению к ТЗ на БД, т.к там нужно описать домены, бизнес-правила, изобразить модель данных и т.д, т.е в 2 страницы можно уложиться только для ну очень простой БД. Удачи! :о)