Считаю, что критерии успешности сбора требований:

• Инвестору/владельцу бюджета/владельцу проекта понятно в первом приближении, "что, как и для кого" предлагается сделать, сколько вложить и за сколько это окупится
• Архитектору понятно, что проектировать, разработчикам - что разрабатывать, менеджеру проекта - как разбить функциональность по итерациям, когда, в каком порядке и что выдавать, тестировщикам - как понять, что изделие работает правильно, тех. писателям - как объяснить, как изделием пользоваться
• Продавцам понятно, как изделие продавать (и у них это получается), инженерам понятно - как это внедрять (и они не краснеют перед представителями заказчика), заказчики готовы сотрудничать, покупают тех. поддержку.

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

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

Чтобы этого не происходило, показывают, обсуждают и согласуют друг с другом артефакты. Как вариант - просят "рассказать своими словами, как понял, что сделать нужно".

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

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

А сильная формализация требований и процесса работы с ними IMHO может такому взаимодействию между людьми только мешать. Чем больше и сложнее документ - тем хуже его читают и понимают.

Саша,

Это все понятно, просто вопрос был про критерии. А твои критерии, к сожалению, не подходят

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

А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.

Вторая цитата:
Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.
Вот Вам и критерий.

А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.

Хороший пример, спасибо. Мне кажется, оценка трудоемкости реализации не может выступать в качестве точности модели, а служит показателем того сколько требуется усилий аналитика определенной квалификации на построение модели с заданной точностью "А".

Вторая цитата: Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Вот Вам и критерий.

Как нам понять, что мы достигли заданного уровня точности?
Моделью для разрабатываемой системы являются классы требований (бизнес-требования, пользовательские, функциональные и т.п.) и их представление (диаграммы), точность характеризуется собираемостью требований того или иного класса и написанием тех или иных диаграмм, их детализацией. Формально, требование о нагрузочном тестировании написано, считается, что мы построили модель необходимого качества, так? Hо реально, требование не отражает действительность.
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?

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

Написано в книжке Дэвида А. Марка и Клемента МакГоуэн "Методология структурного анализа и проектирования SADT", а именно Методология структурного анализа и проектирования SADT. Глава 1. Системы и модели/ 1.2. Модель отвечает на вопросы

Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?

Еще можно добавить критерий "требования должны быть проверяемыми (в процессе приемочных испытаний)". В последнее время несколько раз приходилось сталкиваться с попытками зафиксировать в проекте требования, которые этому критерию не соответствовали.
Для достаточно детальных требований может быть интересна задача оценки их избыточности. В этом случае, как правило, можно выделить требования, которые заведомо удовлетворяются при выполнении других требований. Или переформулировать их все для исключения избыточности.
Правда данная задача  актуальна для достаточно больших систем, требования к которым формулируются несколькими представителями заказчика и собираются разными специалистами.

Хороший пример...

Как нам понять...

По первому.
Вообще говоря, модель - это описание вне зависимости от средств, которыми оно создается. А создается оно не для того "штоб було", а для последующей реализации в виде информационной (например) системы. Поэтому, трудоемкость реализации (а не трудоемкость разработки модели) вполне может быть критерием, определяющим точность.
Про "усилия аналитика" - несколько не в кассу, т.к. он должен затратить столько усилий, сколько нужно для создания модели нужного уровня подробности и точности соответствия той же предметной области. И не менее...

По второму.
Тупо задавайте вопросы: а как происходит то-то и то-то? куда пойдет такая-то информация? какие связи будут задействованы в таком-то случае? и т.д.
Конечно для этого желательно знать минимум две предметных области: конкретную, для которой делается система, и область разработки ПО. Как раз требование о необходимости нагрузочного тестирования в первопричине может иметь источники в опыте работы во второй из этих предметных областей. Вряд ли заказчик настолько хорошо осознает зачем это надо, скорее положится на Вас как на специалистов в своем деле.
Так что не надо ждать от заказчика формулировки всего-всего-всего, нужно и свою голову тоже включать и предлагать ему не набор диаграмм и документации, а РЕШЕНИЕ!

И, наконец, последнее.
Если Вы ждете критериев, типа упомянутого (не содержать того, что можно уточнить), то скажу, что это недостижимо. Как Вы определите, в свою очередь, могут быть сущности еще уточнены или нет?

Так что, нет ничего обязательного в этой деятельности, есть наборы практик, инструментов, которые будучи использованы грамотно и по своему назначению с большей вероятностью приведут к успешному результату. Однако если те же практики и инструменты использовать формально (типа, вот какую крутую методологию мы используем со всеми ее элементами и закорючками), то можно и самому запутаться и задачу не решить, соответственно, результат получится прямопротивоположный.
Я, кстати, видел много случаев, когда человек, с виду не владеющий методологиями, вполне последовательно и качественно решал именно задачу. На вопрос "а ведь Вы использовали такие-то элементы такой-то методологии" он отвечал что-то в духе "а выручалочка-то вот она где", постукивая себя по лбу.

Поэтому не увлекайтесь формализмом - решайте задачу!

To Galogen
Это разве важно? Гораздо важнее уметь правильно и по месту применить :о))

P.S. А еще существуют цитатники великих и просто известных...

не туда наблюдаете :о))

А как Вам идея выставления оценок по требованию другими Аналитиками ревьюирами, Разработчиками, Тестерами, Внедренцами, Заказчиками и т.д.?
Что-то типа голосования за качество требование от 2 до 5. И делать это необязательным, а just for fun.

Из этого голосования можем получить вот что:
1. Кол-во обращений к Требованию
2. Ценность требования (если за требование проголосовали, то это действительно очень важное требование)
3. Среднюю оценку работы Аналитика за период.

Только данный механизм должен быть легок в использовании и скорее всего его имеет смысл использовать только в СУТ.

Вот еще некоторые мысли по оцениванию работы Аналитика:
http://www.requirementsnetwork.com/node/620

По поводу оценки требований другими участниками команды.

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

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

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

Зачастую самые ценные требования - самые неприятные, спорные (трудно изложить и придумать за разработчиков с архитекторами хорошее решение) и трудно реализуемые. А живой и актуальный draft лучше отлично сформулированного, но никому не нужного требования.

IMHO лучше уж учитывать результаты "разбора полётов", после того, как обнаруживается, что какая-то часть программы не делает того, что от неё ожидают. Но и тут дело может быть в требованиях, а может быть в тысяче других причин.