Как уже уточнил Galogen, в ICONIX подходе указываются только связи has-a, is-a. От этого я и плясал.
Строго говоря, диаграмма не является чистой domain model из-за присутствия контроллеров, Connection и StorageMethod.
Но без них было бы пустовато, поэтому и решил включить. Так что получилась несколько уточненная модель,
но подходу это не противоречит, т.к. тов. Розенберг призывает с каждым проходом все более уточнять domain model,
пока, наконец, она не превратится в диаграмму классов.

По этой же причине не добавлял атрибутов и методов к классам, для их выявления требуется выполнить п.3 и 4
из моего первого поста, чего я решил не делать, ввиду ограничения объема ответа.

Про описания классов совсем забыл, верно. Спасибо, что напомнили.

Про многопоточность - так и не решил, куда это прикрутить. Можно подумать про кэш соединений, например.
Но, по-моему, это далековато от от задачи "описать последовательность....", поэтому многопоточность не учитывал,
а "неиспользование стандартных СУБД" отразил только наличием StorageMethod.

Виталий Григораш, а стоит ли в данном контексте браться за описание нефункциональных требований?
Или написать применительно к данному ВИ, как практикуется в некоторых подходах?

bas, поправил спецификацию согласно замечаниям. Да, я пользовался электронными платежами, например,  Яндекс.Деньги.
У них в качестве параметров, сверх описанного,  можно указать и-мэйл вместо номера счета, а также наименование платежа.
Комиссия рассчитывается и отображается после ввода суммы – соответствующую строку добавил в спецификацию.

Бабихин Максим, на английском – моё личное решение. Был шаблон только на англ., решил не переводить, продолжил писать.

Итак, поправил спецификацию (немного), написал записку с пояснениями – в вольной форме.
Осталось еще добавить описания классов.

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

Как уже уточнил Galogen, в ICONIX подходе указываются только связи has-a, is-a. От этого я и плясал.
Строго говоря, диаграмма не является чистой domain model из-за присутствия контроллеров, Connection и StorageMethod.
Но без них было бы пустовато, поэтому и решил включить. Так что получилась несколько уточненная модель,
но подходу это не противоречит, т.к. тов. Розенберг призывает с каждым проходом все более уточнять domain model,
пока, наконец, она не превратится в диаграмму классов.

По этой же причине не добавлял атрибутов и методов к классам, для их выявления требуется выполнить п.3 и 4
из моего первого поста, чего я решил не делать, ввиду ограничения объема ответа.

Про описания классов совсем забыл, верно. Спасибо, что напомнили.

Про многопоточность - так и не решил, куда это прикрутить. Можно подумать про кэш соединений, например.
Но, по-моему, это далековато от от задачи "описать последовательность....", поэтому многопоточность не учитывал,
а "неиспользование стандартных СУБД" отразил только наличием StorageMethod.

Виталий Григораш, а стоит ли в данном контексте браться за описание нефункциональных требований?
Или написать применительно к данному ВИ, как практикуется в некоторых подходах?

bas, поправил спецификацию согласно замечаниям. Да, я пользовался электронными платежами, например,  Яндекс.Деньги.
У них в качестве параметров, сверх описанного,  можно указать и-мэйл вместо номера счета, а также наименование платежа.
Комиссия рассчитывается и отображается после ввода суммы – соответствующую строку добавил в спецификацию.

Бабихин Максим, на английском – моё личное решение. Был шаблон только на англ., решил не переводить, продолжил писать.

Итак, поправил спецификацию (немного), написал записку с пояснениями – в вольной форме.
Осталось еще добавить описания классов.

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