А у нас MediaWiki в качестве средства для управления требованиями не прижилась. Специализированные не-web-based средства удобнее. Даже "плоские" пользовательские истории количеством больше десятка хранить уже неудобно, вперемешку со специфическими тегами форматирования, а от вбивания в wiki оценок оставшихся/сделанных единиц по этим историям люди отказались на третий день .

Кто просил полное описание возможностей системы Confluence прошу сюда
http://dkvartal.ru/eldar/35506.
В посте описание основных возможностей Confluence + краткая инструкция для пользователей с иллюстрациями.

Похоже нашел как из Confluence экспортировать дерево/иерархию требований в один документ (ТЗ или SRS):
http://confluence.atlassian.com/display/DOC/Confluence+to+PDF

Насколько я понял, основное преимущество wiki - возможность удалённого участия в разработке требований, которые при этом автоматически документируются. Это замечательно, если заказчики и прочие заинтересованные лица готовы к такому сотрудничеству.

Для каскадной разработки, если есть длинный этап сбора требований, завершаемый выходом ТЗ "на скрижалях", всё просто замечательно.

Но даёт ли этот подход какие-то преимущества на этапах, следующих за сбором и уточнением требований? Что получается на выходе, кроме красиво отформатированного документа в пресловутой blue book? При итерационной разработке интересует, в первую очередь, распределение требований по этапам, отслеживание их статуса в процессе разработки, соответствие тестов требованиям (не обязательно матрица трассировки, но хотя бы лекго управляемые списки связей) и т. п.

Есть ли в wiki механизмы, позволяющие всё это реализовать? Если нет, то, скорее всего, придётся предусматривать экспорт требований в другие системы. Что сильно усложняет работу.

Но даёт ли этот подход какие-то преимущества на этапах, следующих за сбором и уточнением требований?
Что получается на выходе, кроме красиво отформатированного документа в пресловутой blue book?

Так оно как раз и заменят СУТ (систему управления требованиями). Веб - это не самоцель.

распределение требований по этапам,

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

отслеживание их статуса в процессе разработки,

Шаблон страницы, к сожалению с правами выставления этого статуса уже сложнее, но если аналитики не злыдни то все ок, да и историю изменений всегда можно просмотреть

соответствие тестов требованиям (не обязательно матрица трассировки, но хотя бы лекго управляемые списки связей)

Линки или теги можно ставить - вот вам и матрица. Многие Вики позволяют выловить трассируемые объекты

и т. п.

Что еще интересует??

Немного плоховато с моделями, но можно прикрутить какой-нить СВН и это должно решиться.

Подытожим:

Основные Wiki-кандидаты на СУТ:
1. Confluence
2. Twiki
3. MediaWiki
4. DekiWiki

Основные Wiki-подобные кандидаты на СУТ:
1. Jira (приплетем ее сюда)
2. TrackStudio (приплетем ее сюда)
3. NPJ

Хм, может давайте определим ключевые требования к СУТ и тогда кандидаты будут понятны сами собой по wikimatrix.org?

Требования к СУТ:
http://www.nat.naumen.ru/new/Main/OpenResearch/RequirementsManagement

Вот был интерсный доклад на СЕКР от Стаса:
http://lib.custis.ru/index.php/%D0%98%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F_Open_Source-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_%D0%B4%D0%BB%D1%8F_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%BE%D0%B9_%D0%9F%D0%9E

Здесь тоже можно высказывать свои мысли и замечания по этому поводу