В ТЗ вообще рисунки лучше не вставлять.

Вы говорили об этом.

Да говорил, но стараюсь не вставлять.

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

А вот,  к примеру что поле в БД FIO называется именно так это

И все-таки рисование проектирование это уже другой этап.

Еще один довод, рисовать это чьи-то трудозатраты ... и все такое , а в основном данных часов нет.

Да говорил, но стараюсь не вставлять.

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

А вот,  к примеру что поле в БД FIO называется именно так это

И все-таки рисование проектирование это уже другой этап.

Еще один довод, рисовать это чьи-то трудозатраты ... и все такое , а в основном данных часов нет.

Что-то я вас не понимаю.
У нас в ТЗ довольно часто входят особенности реализации. Вплоть до макетов интерфейса. И просто так его менять нельзя, только по согласованию с заказчиком и т.д.

Что значит проектирование это другой этап? Другой от чего? От написания ТЗ ? ТЗ бывают разными, для разных людей и с разной степенью детализации.

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

Я лишь хотел сказать что когда вставляем схему то пишем в ТЗ, что предварительная.
 

Вплоть до макетов интерфейса

Именно макет, а не окончательная реализация.
Или схема БД может быть уточнена на этапе тех проектирования.
Это макет решения.

После выработки решения как ая будет схема, рисуем в основном в Visio.

Я лишь хотел сказать что когда вставляем схему то пишем в ТЗ, что предварительная.

Извините, я не могу понять смысл этого высказывания.

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

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

То есть мы все таки пришли к тому, что вы так же рисуете диаграммы и так же вставляете их в ТЗ.

Да вставляем, но очень редко.

Вопрос был "Лучше рисовать диаграммы на бумажке или в CASE?"
Ответ: Что лучше каждый решает сам как ему удобней.

Мы делаем так : сначала на бумаге (a4, a2, a1 , обсуждение (доска и тому подобное), рисуем схему в визио.

Да вставляем, но очень редко.

Вопрос был "Лучше рисовать диаграммы на бумажке или в CASE?"
Ответ: Что лучше каждый решает сам как ему удобней.

Мы делаем так : сначала на бумаге (a4, a2, a1 , обсуждение (доска и тому подобное), рисуем схему в визио.

Ну, мне кажется, что так делают большинство.

У нас в компании всегда рисуются все диаграммы в Enterprise Architect, после их согласовывают с заказчиком - вносят изменения, проверяют тестировщики - вносят изменения. Потом в процессе реализации от программистов или заказчика порой поступают предложения/замечания и опять таки вносим изменения.
В итоге за время жизни проекта первоначальные UC могут быть перерисованы в значительной степени.
И если это не хранить в векторной форме - то это будет вынос мозга и трата кучи времени.

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

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

В качестве средства рисования для простых схем использую встроенные средства MediaWiki (мы ведем постановки в wiki). А для более сложных - сразу в MS Visio, шаблон UML (только не родной, а с http://softwarestencils.com/uml), если речь идет о формальной области, или набор из нескольких шаблонов, адекватных задаче.

По поводу добавления в ТЗ. Все понимают, что диаграммы и картинки могут изменяться. Но они являются очень эффективным средством получения общей картины, в том числе - согласования ее с заказчиком. Так что у нас - предъявляются ему сразу, обсуждаются и согласуются. Особенно vision на новые части или изменения. Другое дело, что при работе с некоторыми заказчиками надо различать формальное ТЗ и реальные обсуждения. Но обсуждения должны быть, и картинки - эффективный инструмент для этого.