Добрый день.
Хотел поинтересоваться, у форумчан, как они описывают требования к реализации, просто в процессе работы над созданием сайта, заказчик высказывает кучу пожеланий:Тут хочу чтобы окно всплывало, тут чтобы появлялась фотка большего размера ну итд.
Отсюда и вопрос, стоит ли это все прописывать в ТЗ, а если не стоит, то в каком документе это лучше указывать?

P.S Прошу прощения если данный вопрос уже встречался на форуме

Перечисленное вами это есть не столько требования к реализации, сколько к внешнему оформлению или графическому дизайну. Всех ньюансов в ТЗ вы все равно не учтете, и к тому же по ходу разработки у заказчика могут появляться новые идеи. И это нормально. Просто работайте итеративно, и создавайте прототипы. Все хотелки заказчика фиксируете письменно и формируйте набор реализуемых фич на каждую итерацию. Только при этом довольно сложно работать по fixed price, лучше брать деньги за каждый релиз. Как вариант -- можно сделать оговоренную в ТЗ функциональность за fixed price, а все остальное обрабатывать как запросы на изменение, беря дополнительно деньги за модификацию.

Юрий, спасибо за ответ. Очень помогли.
У меня, тут созрел еще один вопрос: как лучше и в каком документе описывать, поведение элементов Сайта при переходах с одной страницы на другую?
Грубо говоря есть некоторый корневые элементы, допустим список пользователей в левом углу, жмем на одного из пользователей, открывается страница профиля пользователя, в ленте пользователей загружаются друзья пользователей. Вот примерно так.
Можно ли это отнести к функциональным требованиям и описывать в общем разделе функции, или это все же стоит где-то в другом месте описывать?

Это уже больше Тех Проект или Дизайн, где может быть описано данное поведение.

It depends ... Вопрос в том, для чего будет служить такое описание. Если это приложение к контракту (типа будет сделано так и только так, а все остальное -- запросы на изменение за отдельные деньги, либо просто включаем нашу оценку изменений в риск-бюджет), то это описывается в приложении к контракту. Обычно его именуют ТЗ, даже если ничего общего с ГОСТ он не имеет. Никто не мешает вам в этом документе создать соответствующий раздел и там это и описывать.
Другой вопрос, что эта карта переходов нужна вам самому, как разработчику, чтобы ориентироваться в многообразии переходов и т.н. "функциональном дизайне" сайта -- то это можно описать в сценарной форме (в т.ч. используя технику юзкейсов). Плюс дополнить ее графической нотацией, например те же диаграммы UML. Но для этого вам нужно будет а) выделить сущности, состояние которых будет изменяться б) сформировать диаграммы состояний этих сущностей. При этом формат документа в который вы это будете размещать не существеннен. Его может и не быть в принципе -- т.к. все знания могут просто существовать в виде модели в инструментальном средстве (тот же Sparx или StarUML)