на Ваши вопросы ответить-то просто, но я бы порекомендовал помимо этого поглубже узнать предметную область
я предложил бы сделать три шага:
1. ввод условий отбора, перечислить поля/данные, используемые для отбора и т.п. можно приложить картинку интерфейса
2. запрос отчета, грубо говоря действие, выполняемое по кнопке, без описания самого запроса и источников информации, к которым он обращается (т.е. нижнего технического уровня)
3. форма получаемого отчета, колонки, если есть, то формулы, расчеты и т.п. ссылок на БД я бы не рекомендовал бы делать, но описать "своими словами" какая информация будет помещена в соответствующие ячейки отчета.

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

Пример демонстрировал, как сущность предметной области (накладная) неявно участвует в ВИ1 и ВИ3.
Нерешенная мной задача в том, что как указать в ВИ3 факт некого алгоритма по данным, которые задействованы в ВИ1.

P.S.
В прочем, я с удовольствием наблюдаю за вашей дискуссией.

И соответственно как ( и стоит ли) указываьтт в алгоритме то, что данные участвуют в ВИ1. ( Для тестера было бы удобно, но делают ли это на практике)

Пример демонстрировал, как сущность в предметной области (накладная) неявно участвует в ВИ1 и ВИ3.
Нерешенная мной задача в том, что как указать в ВИ3 факт некого алгоритма по данным, которые задействованы в ВИ1.

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

ВИ могут ссылаться друг на друга, но не на часть друг друга.

Если один вариант имеет функциональность, которая может использоваться как есть в других ВИ используем либо include либо extend, в зависимости от ситуации

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

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

Пример демонстрировал, как сущность предметной области (накладная) неявно участвует в ВИ1 и ВИ3.
Нерешенная мной задача в том, что как указать в ВИ3 факт некого алгоритма по данным, которые задействованы в ВИ1.

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

Я бы понял ответ, вроде
ВИ должен содержать ЧТО, я отображаю, а не КАК это вычислять. Все точка, закрыли тему. И никакого разговора про ссылки на алгоритмы, GUI, исходные данные, про связи по данным с другими ВИ.

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

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

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

IMHO прецеденты вполне могут описывать систему ДО того, как были созданы другие артефакты проектирования. Соответственно ссылок давать просто не на что. Но бывают и обратные случаи. В приведенном Вами напишите, что по кнопке "выполнить" запускается тот самый особо секретный алгоритм, результат отработки которого отображается на следующей форме...

И потом, если заказчик хочет - дайте ему это. Тем более, что в данном случае речь идет о документе.

Вопрос в том, как поступают с ссылками на артефакты проектирования из ВИ.

Для этого используется трассировка проектных артефактов к ВИ. Их можно демонстрировать на диаграмме или указывать в контексте артефактов ссылки на ВИ ими реализуемые

При этом никто не запрещает писать ВИ как есть, а потом ВИ как надо

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

Считается ли связью ВИ2 - ФТ1 - ВИ1, если
ВИ1:
i. Пользователь вводит номер накладной

ВИ2:
j. Система отображает "некая сущность" (см ФТ1)

ФТ1:
Система должна вычислять общую сумму по накладным

Стоит ли вообще стремиться указывать такие связи?

Эд, вы имеете ввиду разделение БВИ/СВИ ?
БВИ я делал только в курсовике в институте, у меня не было позывов создавать ссылки на алгоритмы.

накладная - объект предметной области, а не артефакт проектирования.

IMHO такое использование более чем уместно. я бы сказал, что необходимо не просто стремиться, а только их и использовать, чтобы заказчик Вас понял.

Формулировка Вами связи, через "некую сущность" не вполне понятна. Нельзя просто написать "общую сумму по накладным"? только стоило бы конкретизировать про какие конктретно накладные в этом случае идет речь.

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

Для этого используется трассировка проектных артефактов к ВИ. Их можно демонстрировать на диаграмме или указывать в контексте артефактов ссылки на ВИ ими реализуемые

Спасибо, Эд. Понятно, по крайней мере такое понятие существует.

накладная - объект предметной области, а не артефакт проектирования.

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

Формулировка Вами связи, через "некую сущность" не вполне понятна. Нельзя просто написать "общую сумму по накладным"? только стоило бы конкретизировать про какие конктретно накладные в этом случае идет речь.

это понятно.

дайте алгоритмам (включая готовые секретные алгоритмы заказчика) какие-нибудь внятные наименования, можно мнемонические. и используйте при описании прецедентов: "по нажанию кнопки выполняется секретный алгоритм с кодом NSX/RDU-9732948", "результаты работы алгоритма вычисления суммы накладных отображаются в таблице такой-то"

пользовательский интерфейс может быть в значительной мере определен на стадии описания ВИ (да и каркас системы с точки зрения пользователя тоже) и впоследствии будет дополнен при проектировании "внутренних сущностей системы".