Возникла такая вот ситуация.

Руководитель проекта в усной форме описал приблизительный функционал устройства и основные требования. Устройство - демонстрационный стенд для ЖК-индикаторов на базе МК ATMEL.
Точного бумажного ТЗ с указанием по пунктам вида "N-количество ЖК-индикаторов, управление подсветкой надо\не надо, интерфейс связи, внешнее питание от DC либо AC 220" и тому подобному - нет.
На базе усного изложения получили устройство вида:

4 разъема для ЖК-индикаторов (по одному на разъем)
Процессор mega16
Для связи внешняя шина USB (COM-порт виртуальный через CP2103 Silabsсовский)
Управление контрастности ЖКИ переменным резистором (по 1му на ЖК)
еще один ЖК с DB25-колодкой на плате (для подключения к LPT ПК, и управления всяким софтом ПКшным)

Собственно все.
Было получено задание сделать схему принципиальную электрическую, и разводку платы.
После выполнения схемы, договорились в устной форме, о предварительной проверке, и в случае "все ок", дальнейшая разводка платы.

Сейчас наступил момент проверки, и, как и следовало ожидать, возникли вопросы - а почему так, а не иначе, почему на подсветке индикаторов стоят MOSFET (для включения\выключения подсветки).

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

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

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

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

Заказчик обязан дать технические требования (конечно в письменной форме), а вот ТЗ уже пишет разработчик (возможно вместе с заказчиком) и согласует, утверждает его с заказчиком. А вот после утверждения ТЗ вопросы из серии - почему MOSFET, надо ставить... решаются строго за дополнительную плату, если в ТЗ не оговорено обратное.
Ну а как поступить Вам уже сказали. Удачи.