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

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

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

У этой системы так же будет интерфейсный компонент для просмотра и редактирования информации, поэтому второй мой вопрос, при разработки ТЗ для таких систем описываются ли подсистемы организации (БД) и интерфейса отдельно или вместе?

Понятно, что они тесно связаны, но мне казалось, что сначала лучше продумать четкую структуру БД, а затем уже накладывать сверху интерфейсы. Поправьте, если я не прав.

Большое спасибо за ответы, действительно ценная для меня информация к размышлению. Я сразу должен был задать несколько определений. Специфика мой среды такова, что (к счастью или сожалению) границы "разработчика" и "организатора" достаточно размыты. Разработчиком в данном случае будет скорее всего один специалист, который будет осуществлять кодирование интерфейса. Я являюсь специалистом в предметной области для организации данных которой и создается система, но не являюсь специалистом в проектировании. К сожалению ситуация такова, что просто изложить требования мне кажется недостаточным, надо продумать возможную атрибутику, связи объектов между собой, функции интерфейса...или по другому говоря, все это и должно быть в требованиях...

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

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

IT-Shamanподробнее в спецификации RUP описано
То как вы это изложили похоже на то, как я себе это понимал, более того некоторое время назад начал набрасывать список ролей и видение системы с точки зрения простого посетителя, того кто вводит информацию и т.д. Где можно найти эту спецификацию?

474Почитайте про требования, варианты использования. Коберна - это классика.
Не подскажете ли где можно найти эти текст(ы)?