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

Думаю, формально ее можно рассматривать как диаграмму состояний фокуса ввода.

Действительно, аналитик и проектировщик могут использовать любые средства для "донесения" своей мысли. Текст, иллюстрации. Но простите, при чем здесь диаграмма состояний UML?

Есть очень простой способ: запустите валидацию в инструменте моделирования. Уверяю Вас, самого большого монитора не хватит, чтобы показать все ошибки!

Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!

Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!

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

Действительно, аналитик и проектировщик могут использовать любые средства для "донесения" своей мысли. Текст, иллюстрации. Но простите, при чем здесь диаграмма состояний UML?

Вы, несомненно, правы. Предложенный мной подход не претендует на соответствие стандарту. Он просто удобен для решения поставленной автором темы задачи: "...для описания сценария функционирования разрабатываемой формы".
Более "стандартных" (но в то же время доступных для восприятия человеком ) ) примеров пока никто здесь не предложил.

Юра Булуй вполне резонно указал, что такое описание на практике никому не нужно.
 
Для определения требований к интерфейсу с пользователем-человеком вполне достаточно диаграммы деятельности. Из описания к этой диаграмме (поля документирования каждого модельного элемента) должно быть ясно, какие средства управления (поля, кнопки и т.д.) нужны для реализации.
Иногда проектировщик делает диаграмму классов (граничных, по терминологии моделирования анализа). Окна, области, поля и т.д.
Для любого разработчика этого достаточно!

Средства управления, как правило, между собой не взаимодействуют.

Ну, а если форма в процессе заполнения взаимодействует с сущностями или контроллером (подсказки, запуск операций), так это не моделирование формы, а моделирование реализации прецедента (use case realization). См. RUP, там все очень подробно описано.