Называть вещи своими именами, конкретизировать
Прописывать названия печатных форм, заголовков форм объектов в точности так, как они выглядят в конфигурации или в пользовательском интерфейсе.
Разработчику может быть известно о других вариантах объекта, о которых пользователь не догадывается или они ему недоступны в силу ограниченных прав. Также пользователи склонны упрощать названия часто используемых объектов, когда общаются между собой, и также пишут в технических заданиях. Но для разработчика это может быть не так очевидно.
Описывать цель доработки
Прежде чем писать о том, что нужно сделать, хорошо, когда есть упоминание, для чего это нужно.
Из контекста цели можно понять, как именно реализовать отдельные детали, если их описание отсутствует или недостаточно подробно описано в ТЗ. Опытный разработчик/архитектор при этом может предложить более эффективный вариант решения, внести коррективы или внести дополнительные предложения, как лучше реализовать. А от каких-то решений, наоборот, отговорит в силу их неэффективности.
Рассказать, что не устраивает в существующем функционале
По аналогии с предыдущим примером (см. “Описывать цель доработки”), при средних и крупных доработках хорошо бы знать, что именно не устраивает в текущей ситуации и почему требуется разработка? Возможно, часть задач можно закрыть функционалом смежных подсистем конфигурации, о которых пользователь не знает, или открыть ему доступ к дополнительным объектам/функциям, которые позволять это сделать.
Иногда бывает и так, что неудобен порядок выполнения каких-то операций, или расположение элементов на форме/в интерфейсе. Из-за этого пользователь может отказываться от использования новой доработки и продолжать делать “по старинке”.
Предоставить пример ожидаемого результата или референсы
Картинка, пример отчета в Excel, скрин из другой программы (“хочу также”), или хотя бы словесное описание того, что должно присутствовать в результате.
Описывать порядок и правила получения данных
Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.
Вопрос даже не в том, что это уменьшает число вопросов программиста к постановщику. Зачастую при недостаточном описании разработчик принимается за реализацию похожих показателей из смежной подсистемы, или по инерции берется за неверный вариант, с которым работал недавно по другой задаче, потому что “на слуху”.
Но все эти правила помогут вам в грамотной поставке простых задач, типа создание/изменения разреза отчетов или "добавления кнопок" в документ.
Для сложных задач советуем вам обратиться к услугам команды разработчика по составлению технического задания. Это сэкономит время и нервы обоих сторон предприятия, ведь работа должна приносить не только доход, но и удовольствие)