Без заголовка

Классически тут рекомендуют больше времени и усилий тратить на стадию определения needs (нужно обычно делать какой-то reverse engineering для using system), чтобы по возможности убрать связанные с ошибками на этой стадии риски. Сколько это "больше"? Никто, конечно, не скажет - это высокоспецифично для каждого проекта. Плюс чем меньше определённость в needs, тем больше контракт должен быть agile-like, а не классическим водопадным. Если тебя посылают "туда не знаю куда принести то не знаю что", то и контракт должен быть не на это, а на "побродить, прикладывая разумные усилия и отчитываясь о промежуточных результатах". Так будет честно для обеих сторон контракта.