Что должно быть в серьезном ТЗ?

Что-то как-то все размазано... и не систематизированно...
Ничего не написанно про workflow магазина, ничего про интерфейсы для работников, а это самое главное.
Про интеграцию с бухгалтерией.
Мультиязычность? Какая? Только интерфейс или Каталог товаров тоже должен быть мультиязычным?
Вообщем ещё надо заказчика пытать ещё долго в плане требований... и если вы профи лучше не упоминать
вещи касающиеся технологий (в большинстве случаев JavaScript, Flash, HTML5, Кодировка и DOCTYPE
Кроссбраузерность Микроразметка, микроформаты и микроразметка для заказчика пустой звук)
Так же заказчика будет интересовать насколько эффективен workflow, что бы нанимать работников поменьше.

У вас отсутствует четкая структура ТЗ. Я предложил бы вам 2 варианта переделывания:

1) Быстрый. Добавить в начало ТЗ разделы про цель интернет-магазина (зачем он нужен) и задачи, которые предстоит решить для достижения цели. Дальше описать структуру ИМ, далее описать каждую страницу структуры - какой функционал должен быть, как должен работать интерфейс и т.п. После описания страниц разместить прочие, важные в рамках вашего проекта требования: SEO, мультиязычность, перенос данных (если есть), админка, верстка, и т.п.

2) Менее быстрый. Все тоже самое, что в п.1 +
добавить раздел с описанием используемых в ИМ сущностей, списков, функциональных возможностей, например:
-Тип данных "Новость", атрибуты "Заголовок (строка)", "Содержимое (html)";
-Список "Новости", состоит из новостей (тип данных "Новость"), сортировка по дате по убыванию.

А в описании страниц сослаться на соответствующие сущности, списки, и функциональные возможности, например:
Страница "Новости" должна включать в себя одноименный список. Каждый элемент списка должен являться ссылкой на страницу соответствующей новости.

Это позволит лучше проработать логику проекта, выявить спорные и неоднозначные моменты на этапе проектирования.

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

Если хотите делать всё совсем по взрослому, посмотрите в сторону SRS 830 или его отечественного аналога - ГОСТ 34. (Но, подозреваю, это совсем сурово для ваших целей).

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

По каждому из этих пунктов:

Каталог товаров
Характеристики товаров
Управление магазином
Заказы
Учет товаров на складе
Доставка товара
Регистрация продавцов

можно написать небольшую диссертацию. И это далеко не все моменты, с которыми придется столкнуться при работе с интернет-магазином даже много меньшего масштаба (правда, первый раз вижу этот dx.com, но похоже на скромный аналог aliexpress иже с ними)

Возможно:
- Требования сервера
- Законодательная база (152-ФЗ)

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

В конце написания, форматирую, перемещаю текст по доке для красоты. Когда пишу тз, то пишу просто по порядку без структуры. Потом отдаю на тестирование разработчику и тестировщику. Они комментируют ТЗ задавая вопросы что где не понятно, или предлагают свой вариант описания если я написал недоступно\неправильно. Потом комбинирую правки и отдаю руководству. Руководство добавляет свои 5 копеек и можно показывать клиенту. (постоянный показ клиенту проходит по мере написания ТЗ, что бы не оказалось, что вы писали 2 недели чепуху которая клиенту не нужна).

В "серьезном" тз должно быть следующие вещи:

1) Цели проекта которые будут решены при помощи проекта - тут ни слова о проекте. Тут те участники, из проблемы, и как они будут решены если продукт есть и работает успешно (ни слова о продукте тут!)
2) Задачи проекта - каким образом при помощи проекта будут достигаться цели. Нужно перечислить успешные состояния того, что описывает "успешность достижения цели".
3) Образ решения - сценарии, экраны, структуры данных. Иными словами ответ на вопрос "Как выглядит и работает успешный продукт".

Третий пункт желательно оставить на свое усмотрение и ответсвенность, а подписывать первые два. Именно образ решения вы формируете как специалист. Главное это зафиксировать задачу.

Подробнее тут - www.deppkind.com/product_requirements_document
Пример тут - files.deppkind.com/DemoofRequirementsDocument.pdf