ТЗ и спецификации

Так для общего развития:

ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

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

http://www.istu.edu/science/competition/metod.rtf

К сожалению, не все так просто. Под спецификациями понимались западные Specification, но при этом надо было опираться на ГОСТы 34 и 19 групп.
В частности пришлось описывать форматы бесконтактных карточек.
В итоге на оборудование делали ЧТЗ, а на остальное пришлось брать обозначение документов из 19 ГОСТа, а писать по образцам западных документов. Заказчик работу принял. Но сказать, что я осталась довольна выполненной работой не могу.

Это коллеги должны Вам объяснить

В терминологии ГОСТ это ведомость покупных изделий. Некоторые отличия есть.

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

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

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

По хорошему, описание алгоритма, всяких предиктов и пр. - это все проектная документация. Но, повторяю, можно сделать минимальный набор документов - ТЗ, ПМ и РО для программы.

Доброго времени суток!
Не подскажите ли - какой должен быть уровень детализации при написании ТЗ? К примеру, есть некая автоматизир. система, скажем, раздачи кормов. Так в ТЗ нужно отображать только то, что "система должна выполнять раздачу..." или расписывать по шагам - с пред- и пост-условиями, и альтернативами? И если не в ТЗ, то где должно быть такое детальное описание алгоритма работы (а оно, очевидно, должно быть, ибо потом Заказчику ничего не докажешь)?

С интерфейсами сложнее. Если имеется в виду GUI - рекомендации есть здесь - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/modcore/html/deconrequirementsforgrizzlyapplicationfrontend.asp

Раздел дерева Win 32 & COM developer->User Interface
Можно и попроще - предложить Заказчику структуры меню, прорисовать окошки с предварительным набором элементов интерфейса. Заказчика, скорее всего, будет интересовать состав.

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

Спасибо!!! Я так и думала, но смущало, что один из разделов "Спецификации на оборудование"- спецификации на интерфейсы (желание заказчика). Как их писать? Я уж молчу о том, что писать нужно все на украинском, т.е. все Ваши рекомендации и ГОСТы я еще и перевожу.

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

Cпецификация - это технические требования. В данном случае, фактически - ЧТЗ. В ГОСТ 34.201-89 есть "Технические задания на разработку специализированных (новых) технических средств", то есть проектом все предусмотрено.

Иными словами, надо разрабатывать частные технические задания на отдельные подсистемы все по тому же ГОСТ 34.602-89, только в подразделах ЧТЗ, чтобы не дублировать разделы общего ТЗ, давать ссылки на разделы общего ТЗ. Как-то так (в ЧТЗ):

1.2.3. Требования к условиям эксплуатации
Требования к условиям эксплуатации приведены в п. ТАКОМ-ТО технического задания на Систему.