dev98<...> Нужно прорывное решение, иначе буду искать другую работу, есть две недели .... =(

IMHO ТЗ в таком проекте, с непонятными плавающими границами и заказчиком, толком не знающим, что ему нужно, только всем навредит. Я бы попробовал работать по SCRUM.
Книга Addison-Wesley, User Stories Applied For Agile Software Development .

dev98<...>
Как правильно поставить процесс работы разработки в моей ситуации? (как эффективно их автоматизировать)
Какая структура должна быть документации?
Как лучше выстроить процесс управления требованиями?<...>
Сколько-нибудь универсального ответа нет. IMHO никто, кроме Вас, не сможет ответить на эти вопросы. Если сами не можете, а бюджет позволяет - наймите хорошего PMа и хорошего аналитика, а то и нескольких. "Прямо завтра", учитывая риски, к Вам пойдут, если будете готовы дать з/п в 2-3 раза выше рыночной, а в будущем - долю при "распиле" денег, к-рые выплатит заказчик в случае успеха. Если и не можете, и бюджет не позвляет - можно попробовать обложиться книжками и сделать "your best". "Запасной аэродром" иметь желательно, но в панике бежать - неправильно, успеете, если Вы, конечно, материально безответственны :) .

dev98
Как лучше трассировать требования на БП, и наоборот? (управление изменениями) RequisitePro или CaliberRM какие еще мнения?
Какие средства лучше использовать для трассировки требований?
Где можно получить шаблоны документации требований? Используем Word?
Как осуществить переход от БП -> орг.структура -> цель -> задача -> Use Case?
По поводу RUP, какие+, какие-?
Трассировать лучше всего в голове, а затем, чтобы не забыть - в средстве. Средства, в к-ром одновременно можно было бы хорошо работать и с бизнес-процессами, и с требованиями, я не знаю. Трассировать можно в Enterprise Architect 6.5 и, кажется, в PD 12, но бизнес-процессы в них можно только рисовать и описывать, ни о каком имитационном моделировании, индикаторах или генерации должностных инструкций речи не идёт. И вообще, говорят, трассировки следует избегать: user stories, например, стараются писать самодостаточными.
Шаблоны - в книжках. Есть, конечно, стандартные, RUPовские, но пользоваться ими лично мне не очень удобно.
Если БП "как должно быть" рассмотреть с точки зрения функций, ролей (должностей), входных и выходных данных, мест хранения, средств обработки, каналов передачи - из каждой функции получается что-то наподобие варианта использования: "сотрудник получает...", "сотрудник создаёт/изменяет на основании полученного...", "сотрудник сохраняет/передаёт..." Переход скорее похож на БП + орг.структура -> цель + Use Case -> задача.
RUP - замечательный подход, применимый, кстати, как к большим, так и к средним проектам, но имеющий высокий порог вхождения.