ЮВС точки зрения писателя, ... (назовем "белый ящик") ... (назовем "черный ящик")
Честно говоря, я немного сомневаюсь в разумности такого подхода. Почему: потому что мало-мальски больших программных продуктов, целиком понятных по интерфейсу [не обязательно графическому - то же можно сказать и о, например, интерфейсе API] (белых ящиков в Вашей терминологии) не существует. Их можно назвать недостижимым идеалом. Всегда есть тонкости, есть неочевидные моменты, а если бы даже их не было - исследовать приложение и быть уверенным, что ничего не пропустил, гораздо дольше, чем спросить разработчика - нет ли чего-то еще.

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

ЮВво втором - нет, программист ОБЯЗАН предоставить писателю так называемые "рабочие материалы" по своей работе.
"Рабочие материалы" - это некая абстрактная сущность, которая может принимать очень разные формы, вовсе не обязательно "документации от программиста" - зависит от конкретной ситуации и конкретной команды. Скажем, в одном из моих проектов такие вот рабочие материалы выглядели как функциональные диаграммы в Oracle Designer с комментариями.

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