LMC (три продукта jama software к примеру), но в проде их не пользовал.

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

ну Doors использовал, Rational ClearQuest использовал, Rational RM (часть jazz.net) тоже юзал и даже интеграцию с ней делал

RM нужен в производстве - электроники, авионика, авиа и мото в целом.  Там довольно обьемные наборы требований и детальные

и важно отслеживать исполнение

в бизнес-кейсах требования менее формальны

Сдача ИТ продуктов с ним упрощается в разы, только теперь сбор и утверждение становится болью заказчика. Они же привыкли - вот вам абзац, вперед, наше управление считает что автоматизация 30 складов это 20 страниц текста с полей.

ну это склад... а представьте набор требований на самолет ? :)

Про управление требованиями - это вам надо в чат к аналитикам)

Конструкторский софт за оверпрайс. Для ИТ

А вот и нет, аналитик это сбор. Управление - не их задача.

Ну только если управлени процессами, тогда их. Но не требованиями к софту.

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

Тогда однозначно LCM продукт. Ну или три: сбор, отслеживание, тестирование

Типа один раз собрал требования и всё?) А проанализировать? А согласовать? А внести изменения?
Я конечно допускаю, что в каких-то проектах ПМ на себя может часть задач взять, но всё-таки требования обычно считаются вотчиной аналитиков...

То что вы написали вот это я и называю собрать. Потом зафиксировать, передать в проектирование, разработку куда угодно, и тут начинается управление ими. Даже BA в лучшем случае приходит и говторит что это новое требование плюс к процессу но управлять старыми, отменять, и направлять имплементацию нового, замораживать связанные до принятия решения Архитектором, или вобще отметать новое, вообще ни разу ни Аналитик. Принимать имплементацию тем более.

Может офтоп, но скажу, Знаете вот меня прямо умиляют РП консалтов РФ, у них раб-консультнант все делает, еще и тестирует, нужно же проект протолкнуть заказчику, ведь не барское это дело что бы РП работал 😂

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

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

В ходе анализа и согласований аналитик вполне может прийти к выводу что новое требование не пойдёт дальше в работу.

Из BABOK про управление требованиями

Так управление требованиями - не совсем его задача, это скорее про Product.
Project интересует бюджет, сроки, ресурсы и т.п.
А уж как там Product c Project договорятся (если для одного важно, а у другого бюджета нет) - это их личное дело.