Я умею писать техническое задание для водопадного метода -  там сразу всё очень подробно пишется.
А когда планируется agile метод разработки, то как будет выглядеть техническое задание -  просто список названий пользовательских историй(я имею ввиду ту часть технического задания, где в водопадном методе  описываются "Системные функции", а именно "Функциональные требования")?

Я умею писать техническое задание для водопадного метода -  там сразу всё очень подробно пишется.
А когда планируется agile метод разработки, то как будет выглядеть техническое задание -  просто список названий пользовательских историй(я имею ввиду ту часть технического задания, где в водопадном методе  описываются "Системные функции", а именно "Функциональные требования")?

А кому будет полезен просто список названий пользовательских историй?
Agile не регламентирует конкретный способ фиксации требований. Можете делать как хотите, придерживаясь основных правил agile.
Но наиболее подходящий и легковесный на мой взгляд - это работа по пользовательским историям, без какого-либо ТЗ.
И соответственно релиз определяется набором историй в нем.
Если заказчику очень нужно, делаете ему документ с этим набором. Не нужно - не делаете.

Я умею писать техническое задание для водопадного метода -  там сразу всё очень подробно пишется.
А когда планируется agile метод разработки, то как будет выглядеть техническое задание -  просто список названий пользовательских историй(я имею ввиду ту часть технического задания, где в водопадном методе  описываются "Системные функции", а именно "Функциональные требования")?

1. ТЗ для agile пишется точно так же ка для не agile.
2. RUP и MSF это agile? Ваше определение.
3. А что такое agile? Я собираю коллекцию определений. Они довольно забавны. Лучшее было: "Хренак, хренак и в продакшен - это agile!".
4. А что водопад существует?!
5. Кроме того, водопад ничем не противоречит agile. Внезапно. Но не все это знают.

Кстати. Термин agile был в моде лед 10 назад. Потом было модно говорить Канбан. Сейчас модно говорит девопс.
С каждой итерацией все становится хуже и хуже.

ТЗ обычно разрабатывается до начала создания продукта и содержит, в основном, бизнес-требования.
А пользовательские истории - это, с одной стороны, пользовательские требования довольно низкого уровня, а с другой - элемент управления требованиями. Включение их в ТЗ не имеет смысла, их место в бэклоге, который можно считать "рабочим документом" команды разработки.

Посмотрите, например, на "Электронный журнал".

Вот ТЗ со структурой, примерно соответствующей ГОСТ 34 (уровень бизнес-требований): http://eljur.ru/elektronnyj-zhurnal-sootvetstvuet-trebovaniyam-ministerstva-obrazovaniya-i-nauki
Вот довольно детальный перечень функций: http://eljur.ru/vse-funkcii-elektronnogo-zhurnala-dlya-shkol

Вполне можно предположить, что разработка велась с использованием практик Agile - итерациями и по бэклогам, включающим пользовательские истории. Но с их помощью только реализуются функции, которые, в свою очередь, реализуют требования, перечисленные в ТЗ. ТЗ живёт долго, на протяжении всей жизни продукта, а пользовательские истории - как бабочки-однодневки: написали, реализовали и выбросили.