Согласен с Юрием, это уже больше относится к планированию. Зачем загружать структуру требований не нужной информацией. Если для вас это так важно, то введите новый атрибут у ВИ - требует релизации.
Это не так принципиально, но все же ...

сорри за неточность:
Название: UC12 ДОЛЖЕН быть реализован(или НЕ реализован в данном проекте).
Покрываемая бизнес-потребность: BR007
Источник требования: должностная инструкция менеджеру А отдела Х.
и т.д.
Насколько я знаю, традиционные шаблоны такие атрибуты в ЮзКейс не включают.

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

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

это всё к той же теме антипрецедента
тяжело работать с требованиями в ключе "делаем только И ТОЛЬКО то, что записано в документе".
Легче в таком стиле:
- точно делаем то, что записано,
- точно НЕ делаем, что явно указано НЕ делать,
- о чём явно не договорились в документе - разбираем по ходу возникновения проблем.

А вот покрытие бизнес-потребности обчно вводится не через атрибут, а через связи трассировки.
Но вам удобнее так .. никто за это не осуждает :-).

да нет, я тоже делаю это трассировкой с соответствующим стереотипом, но это же в диаграмме.
согласен, в текстовом описании нужно было  добавить явно, что не атрибут, а трассировочная ссылка.
Но опять же, от какого источника? от ЮзКейса или от отдельно выделенного требования по данному ЮзКейсу?

Ещё пример-аргумент в защиту такого разделения (Требования и ЮзКейса):
- система давно написана, досталась в наследство на сопровождение,
- разрабатывалась не то чтобы просто партизанами, а целым партизанским движением,
- соответственно, отсутствует как документация так и какая-либо структуризация в продукте,
- Кровавым пОтом аналитики реинжирят функциональность в виде ЮзКейсов.

Приходит очередная хотелка.
По-сути - это дополнительный альтернативный сценарий для одного из отреинжиреных ВИ.
Как такую хотелку оформлять?
Я завожу отдельный объект "требование",
- даю название,
- вставляю в текст описания соответствующий бред из письма Кастомера, как есть.
- "тычу пальцем" в соответствующее место ДОРАБОТАННОЙ модели ВИ:
если это текстовый документ - кликабельную ссылочку,
если есть диаграммы - то рисую трассировочную ссылочку на ВИ, а ещё лучше - на соответствующий новый сценарий.
Теперь, если добавится ещё и соответствующая активити-диаграмма, то нарисуем и трассировку от нашего требования
к соответствующей ветке на диаграмме.
Но не так всё просто, если пытаться задействовать средства автоматизации:
с ними особо не договоришься про атрибуты, тут они либо есть - либо их нет.
Остаётся, правда, возможность пользовательских полей, но с ними тоже не особо развернёшься.
Кстати, именно здесь мне пришлось использовать связку StarTeam+Caliber+MSProject.

1. Странно, создаю в ЭА требование и класс, который его реализует, создаю связь.
Открываю свойства класса,  в закладке Links вижу связь с требованием.
Открываю свойства требования - закладки Links нет вААще.

Меня это тоже удивляло, моя гипотеза: ЕА заморозил виз.интерфейс для требований, чтоб не пересечься по разработке с RaQuest'ом, который делает японская дочка австралийской фирмы спаркс. другой причины для извращений не вижу.

3. Странно, а какое назначение закладки "Сценарии" у многих элементов, не имеющих ничего общего с ВИ?
Например - свим-лайны, артефакты, актёры, бизнес-ентити.

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

Меня это тоже удивляло, моя гипотеза: ЕА заморозил виз.интерфейс для требований, чтоб не пересечься по разработке с RaQuest'ом, который делает японская дочка австралийской фирмы спаркс. другой причины для извращений не вижу.

С чего это такой реверанс в сторону дочернего предприятия? Может просто таково политика? Или денег не хватило?
А не связано ли это вообще с проблемой команды или менеджеров ЕА? Нет же у них нормального объяснения тому, что ДП не конвертируется в ДС.
Если это их игра особая - то очень странная, а как кодогенерация у них выстроена примитивно. Мне кажется оне зазнались, либо такая политика как у 1С - выпускают полуублюдочную версию, чтобы дочки тоже могли зарабатывать.
Меня прикололо что раквест академический стоит 75 тугриков, а ЕА всего 65.

Предложение купить Галогену ЕА - поддерживаю, выступлю спонсором, но скорее всего в феврале.
С остальными ответами уважаемого аксакала согласна, добавить пока нечего.

Как поешь акын

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