Отвечу немного в другом порядке.

Кто "не читают"? Кто эти спецификации должен читать и что делать на их основании?

Читать нужно:
1) тем, кто проектирует артефакт (архитекторы) - на выходе проект и/или прототипы
2) тем, кто формирует, распределяет и оценивает задачи (менеджеры проекта) - на выходе план
3) [часто, но не всегда] тем, кто реализует артефакт, выполняющий требования (программисты, технические писатели, инженеры) - на выходе артефакт
4) тем, кто проверяет выполнение требований (тестировщики) - на выходе последовательности, программы и методики тестирования, затем дефекты артефакта
5) [иногда] тем, кто заказывает и оплачивает разработку артефакта - на выходе решение о дальнейшей судьбе проекта.

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

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

Как это не работает?

Участники (1) - (5) тратят слишком много времени на то, чтобы прочитать и понять требуемое поведение артефакта (в т.ч. нужно множество итераций согласования и коррекции) и/или в результате получается не то, что написано в спецификации.

По моему, от аналитика зависит, работает или не работает.

И да, и нет. Можно предоставить спецификации - но нельзя заставить хорошо работать в соответствии с ними.

С одной стороны, это действительно зависит от того, насколько хорошо (качественно по содержанию, доступно по форме) аналитик спроектировал поведение артефакта.

С другой стороны - насколько это описание соответствует ожиданиям и мнению других участников.

С третьей - есть ещё человеческий фактор: не все могут читать подробные спецификации в силу своего склада ума и темперамента (см., например, Rainwater "Herding Cats" и типологую Майерса-Бриггса), не у всех для этого есть мотивация.
----
Опять же, это всё - по моему мнению и на основании моей практики. Может статься, что Ваша команда действительно не испытывает проблем при чтении объёмных и сложных по форме спецификаций, и что программисты не рассматривают детальное описание поведения системы как вмешательство в творческую часть своей работы.

Виталий написал:
Exeption - это частный случай альтернативного потока событий, который приводит к завершению варианта использования.

Тут моя ошибка. Пример пропуска-фильтрации, искажения и обощения. Слово Exeption, под влиянием момента, вопринималось мною как Extention, поскольку я в тот момент активно обдумывал вопросы с включениями и расширениями

Вот читаю и думаю, что нам всем нужен авторитетный, корректный и полный русский словарь терминов, которыми можно оперировать, понимая друг друга. Он должен быть выложен в интернете, и принят как стандарт (как uml, например). Ну и естественно, он должен инкрементально расширяться и дополняться, быть живым.

Вопрос к участникам  обсуждения: вы на какой (какие?) словарь опираетесь?