По моему должна быть такая проверка:
1. Эксперт по качеству/тестированию, кот. проверяет полноту ТЗ и соответствие ТЗ принятым нормам, да и хотя бы что бы было понятно, что аналитик имел ввиду.
2. Архитектор/ст. разработчик, кот. проверяет на реализуемость
3. Специалист ИТ, кот. проверяет не функциональные требования
4. Заказчик, кот. проверяет на свои хотелки.
5. Ну и по желанию спец по ГУИ

2 All: Я так понял, что экспертное вычитывание рулит.

Однако, как вы учитываете возможный субъективизм вычитывающего?
Мы, что греха таить, регулярно на эти грабли наступаем... В новой для себя предметной области, где мы далеко еще не эксперты, привлечение внешних консультантов для вычитки ТЗ зачастую приводит к тому, что помимо указания на наши явные ляпы (за что, конечно, спасибо!) эксперты привносят некоторые новые требования, которые впоследствии оказываются, к сожалению, ничем иным, как личными, субъективными пожеланиями данного конкретного эксперта. Вносятся эти требования, разумеется, из сугубо благих намерений ("чтобы делать систему не вчерашнего дня, а современную, передовую"), вот только внедрить этот фукционал потом крайне трудно, если не невозможно. Эксперт с грустью констатирует, что "пользователи пока не готовы" к его передовым идеям. А мы сидим и думаем, "ну и зачем это надо было???". Потом - очередная новая предметная область, очередной новый эксперт, и все снова...
Кто-нибудь имеет успешный опыт избегания таких проблем?

Михаил, ну а Вы на что?? Или Вы слепо принимает, что скажет эксперт/заказчик/архитектор? А у вас не было ситуации, что Архитектор/ст разработчик говорит, что это не возможно сделать, а заказчик хочет?? Что Вы делаете в этой ситуации?? Либо бьете архитектора, что он лентяй, либо говорите заказчику, что будет это стоить в два раза больше.

З.Ы. От полного субъективизма Вы не уйдете. Это как в программирование, одно и то же можно реализовать 10ью способами, чем квалифицированнее программист или его контролирующий программист, тем он это сделает оптимальнее, но не идеально.

Boatman, семь бед - один ответ )

Мне понравилась мысль boatman'a о трассировании требований к целям как о методе проверки необходимости требований. Правда, встает вопрос о качестве и адекватности описания целей...

Мне приходилось от весьма опытных и успешных менеджеров слышать что-то вроде: "главное, определиться с техничнскими требованиями, что нам сделать надо, а цели можно откуда-нибудь скопипастить, их все равно никто не читает"...

Всем привет!
Коллеги, хочу с Вами посоветоваться.
А что если для проверки качества требований, описанных в техническом задании применить следующую модель:

1. Для каждого требования задать некоторые атрибуты качества, например, полнота,
   непротиворечивость понятность, возможность реализации и тд.

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

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

4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
    или других механизмов обработать результаты полученных данных и для каждого требования
    определить некий показатель качества. Например, требование UC234Регистрация
    пользователя имеет показатель качества "70%" и выводы почему + комментарии.

5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
    изменения.

Я конечно понимаю, что Вам может данная идея показаться бредовой , но я хочу посоветоваться
имеет ли такая идея право на жизнь или не стоит об этом даже думать!

Пожалуйста, Ваша критика и замечания.

Насколько я знаю, предлагаемые на рынке системы управления требованиями (например тот же RaQuest) имеет встрроенные системы расчета количественного показателя для требования, что входит в общую систему оценки. И в частности:

1. Для каждого требования задать некоторые атрибуты качества, например, полнота,
   непротиворечивость понятность, возможность реализации и тд.

Такая возможность есть  и она широко применяется на практике

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

Именно так и делается

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

По поводу 1 это так, второе предложение тоже возможно, но оно будет заменять текущее значение на значение выставляемое проверяющим, и конечно будет отражать мнение этого проверяющего

4. После того, как все атрибуты описаны, с помощью допустим алгоритмов нечеткой логики
    или других механизмов обработать результаты полученных данных и для каждого требования
    определить некий показатель качества. Например, требование UC234Регистрация
    пользователя имеет показатель качества "70%" и выводы почему + комментарии.

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

5. Аналитик может за меньшее время оценить результаты и сделать выводы и если нужно внести
    изменения.

Думаю это возможно через обратную связь

1. На практике с требованием работает Аналитик (1 чел) + Заказчик (1-2 чел.) + Ревьюер (1 чел, и то не всегда). Как вы хотите получить качественную оценку от 2-3 человек?
2. Кто все это будет поддерживать и обновлять?