Управление изменениями в проекте с помощью service desk

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

Без ТЗ: почему клиент не хочет его

в голосовалке не хватает пункта «я тот, кто специализируется только на написании ТЗ» )
по структуре самого техзадания — помимо пользовательских сценариев вместе с прототипами (экранами) должно быть описание работы программного модуля — как рубрицируются данные, как они обновляются (если предусмотрено автоматическое обновление из интегрированных систем), в каких случаях и кому улетают почтовые уведомления и т.п. Расписать состав элементов БД для каждого модуля тоже бывает полезно — экономит кучу времени и в процессе не грузит заказчика дополнительными вопросами типа «а должна ли в каталоге стоять дата последнего обновления цены»