С RP работаю в данный момент.
RP умеет ссылаться на конкретное место в другой спецификации, но не умеет вставлять часть содержимого. А так же не может поддерживать корректность ссылки.
Именно не удовлетворённость RP и подталкивает на поиск альтернатив.

Может ли кто подсказать в каком из RMT есть все перечисленные ниже возможности? Именно все!

Все-все навряд ли где-либо есть.
Все, кроме ссылок на конкретное место в Т. и вставки содержимого из другого Т. -- есть в DOORS, как уже заметил bas.
Но полезна ли возможность ссылаться на часть Т. в принципе? Если Т. можно поделить на части, то это уже по сути несколько Т. Которые можно зарегистрировать по отдельности и ссылаться на любое из них как на целое.

Кстати, коллеги, а ведь это хороший пример на тему, которая недавно обсуждалась -- следует или нет изобретать велосипеды в ИТ.  Достоинства примера: а) не отвлеченный, а имеющий непосредственное отношение к будням аналитика, б) правильный ответ для многих совсем не очевиден.

Но полезна ли возможность ссылаться на часть Т. в принципе?

ИМХО это полезно для создания обобщённых документов требований. Например, если требуется иметь документ отражающий все ДВИ без описания. При отсутствии данной возможности, приходится постоянно отслеживать изменения и дублировать информацию.

ИМХО это полезно для создания обобщённых документов требований. Например, если требуется иметь документ отражающий все ДВИ без описания.

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

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

А если мне из всех ДВИ нужны только их графические изображения без описания?

...можно экспортировать в Word..

А как поддерживать актуальность? Постоянно делать экспорт? Накладно.

А если мне из всех ДВИ нужны только их графические изображения без описания?

Как предположение (на практике не пробовал): создать для требований атрибут "изображение", в котором хранить диаграммы, и выводить в обобщенный документ только этот атрибут требований-ВИ.

А как поддерживать актуальность? Постоянно делать экспорт? Накладно.

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

Скажем, из DOORS можно экспортировать в Word требования нужного типа (например, "ВИ"), включая только нужные атрибуты требований (заголовок там является отдельным атрибутом). В итоге получится желаемый обобщенный документ.

Здесь еще можно использовать такой инструмент, как Rational Publishing Engnee Document Studio (RPE), который позволяет готовить шаблоны документов и выгружать при их помощи требования из DOORS в готовый документ. Например, мне удалось создать такой шаблон для выгрузки ТЗ по ГОСТ 34, который можно использовать для большинства проектов, ведущихся в DOORS в нашей компании.
Жаль только, что по RPE я не нашла пока русского форума, ибо в процессе работы столкнулась с некоторыми трудностями. Пришлось самой во всем разбираться, ну и форум ibm помог, конечно. Может быть стоит создать такой раздел, где агрегировать опыт коллег, как думаете?

Здесь еще можно использовать такой инструмент,

Катенька, поздравляю! Есть что посоветовать известному тебе коллективу?

Может быть стоит создать такой раздел, где агрегировать опыт коллег, как думаете?

Такой раздел уже есть - База Знаний: http://lib.uml2.ru

Ее можно наполнять не стесняясь.

Мы в свое время (лет 7) вели документацию в sgml и делали всякие штуки, чтобы вытаскивать нужное в сводные таблицы - словари, списки форм и подобное. Но постепенно пришли к тому, что стоит менять подход. Дело в том, что описание требований в этом виде очень напоминает процедурное программирование времен фортрана и Си. Каждое требование - это такая подпрограмма, вызывающая другие. В мире программирования победил объектно-ориентированный подход, с его принципами инкапсуляции, наследования, стандартных интерфейсов и многого другого. А аналитики - по прежнему во многом находятся на уровне требований, связанных в произвольную сеть. И это тяжело.  Прежде всего - тяжело эту сеть загрузить в голову, тяжело в ней ориентироваться. Фактически в полном объеме ей владеет только автор. Что не подходит для больших проектов - фактически все участники должны верить компетентности аналитика и правильности его представлений. А ошибки обнаруживаются поздно. В борьбе с этим мы начали строить модели, с приличной инкапсуляцией, минимизацией зависимостей между разными частями. Тогда мы имеем хорошее иерархическое описание, а в рамках обособленного фрагмента - материал вполне обозрим, чтобы обойтись без специальных средств поддержки.

Тогда мы имеем хорошее иерархическое описание, а в рамках обособленного фрагмента - материал вполне обозрим, чтобы обойтись без специальных средств поддержки.

Можете привести реальный пример? Чтобы мы поучились на вашем опыте.

Катенька, поздравляю! Есть что посоветовать известному тебе коллективу?

Спасибо Готова поделиться своими знаниями, если вас заинтересовала эта тема. Мне понравились результаты, которых удалось добиться Конечно, подогнать все проекты под один шаблон нельзя, но доработать шаблон можно всегда, не затрачивая больших усилий. Это лучше, чем вести требования в каком-либо инструменте и отдельно создавать готовые документы.

ekaterinalog, с реальным примером - тяжело. Потому что это реально большие системы (10 и более человеко-лет разработки), и там ТЗ объемные. Плюс основное на верхнем уровне - это запоминающийся образ, картинка, через который идет описание конкретных кейсов на понятном для бизнеса языке. Когда мы делали управление товарным запасом для магазинов, то нам рассказали, что может быть много разных вариантов деления товарного запаса по назначению, в зависимости от ситуации, при этом разными ситуациями заведуют разные отделы и именно они определяют правила. Мы это свели к двум основным видам: запас, доступный группе магазинов и запас, поделенный по конкретным магазинам, решили что дальше будем описывать приоритеты обхода для бизнес-кейсов через специальные правила. И нарисовали для бизнеса все многообразие их существующих кейсов в этой нотации. Дальше был интерактив, они задавали вопросы - мы рассказывали и результатом было общее понимание - что может система, каковы варианты настройки. Как результат - формализм системы отразился в бизнес-терминах. И после того, как модель верхнего уровня возникла, детали - конкретные алгоритмы настройки процесса управления, или функционал рабочих мест - можно было согласовывать для конкретных групп пользователей, и они по объему - были вполне обозримыми. Примерно тоже самое было с Розничным магазином (это тоже сложный проект) - была декомпозиция на основные блоки - склад, торговый зал, касса и сквозные процессы - выкладка товара, примерка, выписка со склада - были прорисованы, именно они делают систему цельной. А дальше - можно было сосредоточиться на каждом отдельном блоке и работать с ним, формируя его модель.

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

Не знаю, насколько получилось донести мысль. Если пересечемся в реале (например, на круглом столе uml2), могу попробовать рассказать более ясно.

Сейчас использую в своей работе Polarion Requirements Management (RM).
Из большинства распостраненных тулов идея лежащая в его основе мне нравится больше всего. Возможно реализация некоторых моментов и не идеал, но идеала и среди других тулов я тоже не видел.
Почему этот тул мне подошел? У меня следующий кейс:
 - я пишу ТЗ по ГОСТУ, либо по стандартам чем-то напоминающим ГОСТ;
 - документ с требованиями в бумажном (или в Word файле) виде согласовывается с заказчиком;
 - заказчик в большинстве своем не технарь, не программист, поэтому я не несу ему документ с диаграммами классов, схемами баз данных и прочего что он не поймет, а если и поймет, то ему это совершенно не интересно;
 - разработчики хотят видеть четкий список требований, где можно четко понимать над каким требованием он работает в данный момент, а не объемный документ с кучей воды, которая ему в данный момент не интересна.

Основная идея этого тула в том, что я пишу требования как обычный вордовский док-файл, а в этом документе уже отмечаю отдельные сущности - business case, system requirements, non-functional requirements и т.д. в зависимости от потребностей. При этом легко могу слинковать нужные мне элементы. Разработчик может уже смотреть список только нужных ему элементов. Проблем с распечаткой всего этого дела нет, так как это все уже представлено в виде документа.

Вспоминая свое общение с Doors понимаю сколько там было лишнего геморроя -  убей пол дня чтобы настроить проект как тебе надо, потом каждый раз когда надо получить печатный документ Word, то после экспорта начинались танцы с бубнами по форматированию стилей, удалению лишнего и прочее-прочее и это еще на пол дня.
Может для Doors проблему с выходным документом и решит Rational Publishing Engine Document Studio, но проблема трассировки к процессу разработки все равно останется.

Упомянутый уже в этой теме обзор Polarion ALM не совсем уместен здесь, так как там рассматривается именно цельное ALM решение, а не конкретный тул для управления требованиями, коим является Polarion Requirements Management.

 Коллеги, если кто-то игрался уже с песочницей RM на сайте Polarion или устанавливал себе локально, то было бы интересно послушать Ваше мнение.

UPD: Кому лень играться в песочнице на сайте могут посмотреть вебинар, ближайший по этой штуке 27 октября http://www.polarion.com/company/events/webinar.php?eventid=130