Пример.
Система ведет учет прихода/расхода деталей на складе.


--- СИСТЕМНЫЕ ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ ---
ВИ1. Ввод информации о поступлении деталей.
...

ВИ2. Ввод информации о расходе деталей.
...

ВИ3. Просмотр остатков на складе.
1. ....
2. ....
3. Пользователь выбирает "просмотр остатков на складе"
4. Система показывает ...

что обычно пишут на месте п.4 ВИ3? Указывают ссылку на раздел, описывающий форму пользовательского интерфейса, где указывается, что будет таблица, с колонками "наименование товара" и "остаток". И в разделе описывающем форму, конкретизируют, что источником данных будет то-то и то-то?

Или в тексте ВИ, как-то пишется, что будут показаны данные, получаемые как результат некого алгоритма по исходным данным введенным при ВИ1 и ВИ2?

или еще каким-то третьим способом?

Андрей.
1. Мне не нравятся Ваши наименования ВИ. Они не отражают цели, которую преследует пользователь, а скорее показываю некотрую функцию системы, которую она должна обеспечить. Но любая ИС по определению должна обеспечить ввод, изменение и удаление и т.п. просмотр..

2.Ви - это описания требоваий, т.е. того, что следует делать системе в ответ на воздействия внешней сущности, учитывая это, я бы написал Система показывает остатки на складе на текущую дату.
То, о чем вы справшиваете далее, это размещается в дополнительных требованиях (никто не мешает при описании шага ВИ сделать ссылку на прототип GUI

Кроме того существует понятие Иллюстрированные сценарии ВИ

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

Спасибо за ответ.

Я вижу цели написания ВИ
1) в том, чтобы разговорить заказчика. (На этапе описания концепции все бывает хорошо, да-да расходный документ, имеет атрибут дата все именно так, но после того как начинает писаться сценарий, выходит, что дату мы ввести не можем, потому, что на практике дата идет задним числом и тп)
2) в том, чтобы связать тесты и требования заказчика. (если ВИ являются входными данными для тестера, то так оно и получается)
3) в том, чтобы [в теории] не тратить время в ситуации "блин, зачем я написал 2 месяца назад if ( invoiceTotal < 3.5 ) { ... }".

4) не цель,а ограничение: -- текст одного ВИ не должен сильно меняться, если меняется способ его реализации.

для (2) - на алгоритм лучше сослаться через интерфейс.
для (4) - лучше этого не делать.

Чем именно плохи мои название ВИ? Не отражает бизнес-смысл операции? "ВИ1. учесть поступление деталей", "ВИ2. учесть расход деталей" ?

Делаете ли вы ссылки на алгоритмы? через интерфейс или как-то еще?

1. ... Но любая ИС по определению должна обеспечить ввод, изменение и удаление и т.п. просмотр..

Что-то новое в определении ИС :о)) ИС вроде должна решать какие-то предметные задачи, нее?
Вот именно из-за подобных определений люди и пишут подобные названия ВИ. Это неправильно.

Чем именно плохи мои название ВИ? Не отражает бизнес-смысл операции? "ВИ1. учесть поступление деталей", "ВИ2. учесть расход деталей" ?

Тем, что они формулируют задачу системы с точки зрения программиста. Что делает Ваша система - позволяет вводить данные? А если они станут откуда-нибудь загружаться - будете что-то менять?
Рекомендую назвать эти действия системы как-нибудь так: регистрация/оформление приход материалов (деталей) на склад и отпуск материалов (деталей) в производство (например, или куда там они у Вас отпускаются). Спросите у Ваших предметников (кладовщиков тех же), как они на своем языке называют эти действия, и так же назовите свои прецеденты. Тем самым Вы убъете сотню (или даже две) зайцев - уберете несколько совершенно ненужных проблем,  и начнете выстраивать какую-никакую коммуникацию с заказчиком.

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

Кроме того существует понятие Иллюстрированные сценарии ВИ

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

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

а мне понравилось :о)) "ИС ВИ НФТ в ВИ ИМХО ВИ" что тут трудного - очень хорошее предложение :о))

Водолей,

А Вы удосужились прочитать по приведенной Эдом ссылке, прежде чем наезжать?

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

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

что обычно пишут на месте п.4 ВИ3?

Напишите в кейсе:
4. Система отображает параметры объекта. (смотрите Требование1)

Требование1:
Система должна отображать следующие параметры объекта
 - Название
 - Стоимость
 -....

Водолей,

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

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

Стало быть:
4. Система открывает форму (см ПИ1.) и отображает параметры объекта. (см. Требование1)

Требования к пользовательскому интерфейсу

ПИ1. Форма1
Элемент.       тип                  источник данных
Таблица 1     таблица            см Требование1.

так примерно поступают?

ВИ3. Просмотр остатков на складе.
1. ....
2. ....
3. Пользователь выбирает "просмотр остатков на складе"
4. Система показывает ...

что обычно пишут на месте п.4 ВИ3? Указывают ссылку на раздел, описывающий форму пользовательского интерфейса, где указывается, что будет таблица, с колонками "наименование товара" и "остаток". И в разделе описывающем форму, конкретизируют, что источником данных будет то-то и то-то?

Или в тексте ВИ, как-то пишется, что будут показаны данные, получаемые как результат некого алгоритма по исходным данным введенным при ВИ1 и ВИ2?

или еще каким-то третьим способом?

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

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

Водолей,

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

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

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

давайте всё-таки вернемся к исходной теме.

Приведу цитату

Иллюстрированные сценарии прецедентов, ИСП [10.4], наряду с прототипами позволяют достичь лучшего понимания между Заказчиком и Разработчиком. Но если прототипы адресованы скорее Заказчику, нежели Разработчику, то с ИСП ситуация обстоит наоборот: они содержат дополнительные сведения, помогающие Разработчику лучше понять специфику проблемной области и, тем самым, лучше отразить ее в интерфейсе пользователя.

Т.е. однозначно определяется для кого предназначено иллюстрирование сценариев. И на каком этапе.
Далее вопрос сокрытия или отображения информации - вопрос инструментов которыми мы пользуемся. Если ВИ разрабатываюся на основе некого инструмента - то там можно сделать кнопку - скрывать или открывать примечания. Даже word это умеет. Расцветка видов иллюстрирования дает ясное указание на то, что несет эта информация. Мне кажется это довольно удобно