Можно работать в стиле "OpenUP".

Есть бизнес-требования, которые описывают, что нужно заказчику. Их собирает Ваш шеф, т.к. имеет доступ к "телу" заказчика на уровне руководства. IMHO именно их он должен писать в ТЗ. Без попыток заходить в системные требования, архитектуру, реализацию, т.к. он в это некомпетентен.

Есть системные требования, которые описывают, что будет делать система, и частично - как она будет это делать. Если речь идёт о небольшом проекте и индивидуальном программировании - наверное, можно их не писать, но держать в голове их нужно.

На основании бизнес-требований Ваш шеф может создавать "стратегию развития продукта", "roadmap", т.е. план низкой точности и детализации, в котором описано когда ему что хотелось бы получить. На основании "roadmap" Вы можете сделать план реализации системных требований. Это поможет шефу понять, когда и с какой вероятностью он получит функциональность, описанную в "roadmap", и сколько ему это будет стоить.

Есть рамки релиза. В них, конечно, обычно набирают системные требования, делают итерацию не очень длинной, чтобы они не успели устареть, и стараются не менять их по ходу итерации. Но в Вашем случае, наверное, можно использовать бизнес-требования.

Есть конец релиза и планирование следующего. Все изменения и дополнения требований обсуждаются в этот момент, на соответствующих совещаниях.

Есть архитектура. Она должна быть достаточно гибкой, чтобы реализовать большую часть требований без её изменения, но достаточно простой и ориентированной на решение конкретной задачи, чтобы минимизировать трудозатраты.

Можно организовать всё и в другом стиле.

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

Исключение - когда во время релиза становится понятно, что требование неактуально. Но даже в этом случае полезно дать его доделать, если это не очень дорого, потому что иначе понижается авторитет аналитиков и руководителей в глазах разработчиков, и происходит демотивация последних.