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

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

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

Анастасия, если я правильно понял, схема у Вас следующая:
1. Создается набор вариантов использования и описываются их сценарии
2. Из сценариев получается набор функциональных требований
3. Создаются GUI на основе функциональных требований.

Трассировка у вас в таком случае UC-->RQ-->GUI ?
1. В документе, как уже говорил Выше Александр и немного я , создаете раздел в котором описываете набор вариантов использования и их сценарии. Лучше каждому ВИ присвоить уникальный номер, например UC1, UC2...
2. В следующем разделе приводите список функциональных требований, которые вы получили из сценариев ВИ. Каждому требованию тоже лучше присовить идентификатор, например REQ1, REQ2...
Далее делаете матрице трассировки требований на ВИ, или если описываете требования в таблице, то прямо в таблице для каждого требования пишете ВИ к которому оно относится
3. В следующем разделе рисуете GUI и точно также трассирует на требования.

Анастасия, а какого уровня абстракции у вас варианты использования: Business, Summary или System?
Если системные ВИ то может не стоит тогда функциональные требования писать, а достаточно лишь сценариев?