Мы подготовили ТЗ на портал электронных торгов.
Нужно по этому ТЗ нарисовать общую сводную схему основных функций, на которой желательно отобразить следующие моменты:
1) основные действующие лица
2) функции системы сгруппированные по "уровням":
    - интерфейс, предоставляемый системой
    - бизнес-функции
    - "обеспечивающие" функции
Желательно, чтобы эта схема соответствовала принципам UML.

Я подготовил такую схему, но чувствую что она не вполне корректна.
Хромает терминология.

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

Я бы большую часть этой диаграммы преобразовал в диаграмму вариантов использования (с человечками-экторами) и не побоялся представить функции в виде овалов-целей.
Раздел "Веб-интерфейс" - это про сайт или про API? Если про сайт, то его лучше бы представить в виде иерархической структуры страниц сайта. Или не иерархической.

Непонятно, кто управляет торгами: рассматривает заявки на проведение торгов, запускает торги, останавливает.

Непонятно, что это вообще за торги. Все торги одного типа? Их никому не надо администрировать? Они ведутся все одновременно?

UML-ские стрелочки - зло, в реальной жизни в большинстве случаев их нужно избегать. Они всё только запутывают. Что означают разные концы стрелочек в разделе"Основные бизнес-функции", никому не ведомо.

Очень большое внимание уделено процедурам регистрации. Имеется в виду регистрация в каких-то гос. органах?

Коль уж измеряем слонов попугаями, по-моему как-то таг:
1) Use-case diagram
2) Интерфейс - User interface diagram
Все, что связано с функциями, должно иметь приставку типа "система должна..." - тут подойдет Requirements Diagram.
Ну и не забываем про трассировки между интерфейсом, требованиями и вариантами использования. И не стоит все элементы держать в одном пакете - старайтесь каждую диаграмму с элементами поместить в отдельный пакет и отобразить взаимосвязь между пакетами на Package Diagram.
Предлагаю ознакомиться с книгой "UML2 и унифицированный процесс" Джима Арлоу и Айлы Нейштадт.

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

Конечно это никак не связано с UML.
Если бы в нотации UML существовала подобная диаграмма, то все другие просто перестали бы быть полезными.

Кстати, вы действительно рассчитываете, что те, кто запрашивает одну сводную схему знают что такое "композиция", которая показана на диаграмме?
Будьте проще. Нет в нотации UML инструмента "все и сразу", зато он есть за ее пределами  )

Конечно это никак не связано с UML.
Если бы в нотации UML существовала подобная диаграмма, то все другие просто перестали бы быть полезными.

Вы не поверите, в UML есть такое и всегда было - как минимум это диаграмма пакетов, иначе таже диаграмма классов с гнездовыми связями или связями владения или компонентная диаграмма http://www.uml-diagrams.org/package-diagrams-overview.html http://www.uml-diagrams.org/component-diagrams.html

Да много чего есть еще замечательного в UML
Но есть и composite structure http://www.uml-diagrams.org/composite-structure-diagrams.html

огромное спасибо за ваши замечания,
далее отвечаю на возникшие вопросы

Я бы большую часть этой диаграммы преобразовал в диаграмму вариантов использования (с человечками-экторами) и не побоялся представить функции в виде овалов-целей.

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

Раздел "Веб-интерфейс" - это про сайт или про API? Если про сайт, то его лучше бы представить в виде иерархической структуры страниц сайта. Или не иерархической.

Веб-интерфейс - это про сайт. То есть в этом разделе представлены основные функциональные разделы сайта, точнее их первые страницы.
Структуру страниц представить на этой схеме будет нереально. Так как во-первых страниц очень много, сайт большой. Во-вторых, это противоречит духу этой схемы, ведь на схеме нужно отобразить только "главное".

Продолжая первый пункт ответа, возникает вопрос: можно ли элементы раздела "Интерфейс" представить на этой схеме при помощи ВИ?
Чем являются "Личный кабинет", "Административный интерфейс"?
Можно ли их считать функциями? целями?

Непонятно, кто управляет торгами: рассматривает заявки на проведение торгов, запускает торги, останавливает.
Непонятно, что это вообще за торги. Все торги одного типа? Их никому не надо администрировать? Они ведутся все одновременно?

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

UML-ские стрелочки - зло, в реальной жизни в большинстве случаев их нужно избегать. Они всё только запутывают. Что означают разные концы стрелочек в разделе"Основные бизнес-функции", никому не ведомо.

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

Очень большое внимание уделено процедурам регистрации. Имеется в виду регистрация в каких-то гос. органах?

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

Предлагаю ознакомиться с книгой "UML2 и унифицированный процесс" Джима Арлоу и Айлы Нейштадт.

Скачал, буду изучать.
При беглом просмотре обратил внимание на главу "5.7.3. Избегайте функциональной декомпозиции",
что косвенно подтверждает что для моей схемы использовать Use Case diagram не совсем верно.

Коль уж измеряем слонов попугаями, по-моему как-то таг:
1) Use-case diagram
2) Интерфейс - User interface diagram
Все, что связано с функциями, должно иметь приставку типа "система должна..." - тут подойдет Requirements Diagram.
Ну и не забываем про трассировки между интерфейсом, требованиями и вариантами использования. И не стоит все элементы держать в одном пакете - старайтесь каждую диаграмму с элементами поместить в отдельный пакет и отобразить взаимосвязь между пакетами на Package Diagram.

Вы все правильно поняли, но хотелось это все изобразить на одной сводной схеме.
Это возможно?

И еще... Я схему делаю в PowerDesigner-е, в нем нету Requirements Diagram

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

Интересная идея с вложенными блоками, попробую.
Блок более высокого уровня по смыслу представляет собой что? Группировку блоков нижележащего уровня? Или их абстракцию?

Конечно это никак не связано с UML.
Если бы в нотации UML существовала подобная диаграмма, то все другие просто перестали бы быть полезными.

Это я понимаю.

Но если говорить о UML то...
В принципе наверное можно использовать трассировку для связи элементов из разных моделей.
Только не понятно на какой диаграмме такую трассировку можно отобразить

Кстати, вы действительно рассчитываете, что те, кто запрашивает одну сводную схему знают что такое "композиция", которая показана на диаграмме?
Будьте проще. Нет в нотации UML инструмента "все и сразу", зато он есть за ее пределами  )

Скорее, это я рисовал для себя.
Заказчик, думаю, не обратит внимания на разницу между типами связей. Или поймет после краткого объяснения.

Интересная идея с вложенными блоками, попробую.
Блок более высокого уровня по смыслу представляет собой что? Группировку блоков нижележащего уровня? Или их абстракцию?

Для меня это круги Эйлера, множества.

Без описания того, кто и как будет использовать эту схему, обсуждать её правильность или неправильность можно долго.

Представьте вопрос «Я нарисовал схему дома, что в ней не так»? Приходит водопроводчик, видит одно, электронщик — другое, архитектор — третье, дизайнер по интерьеру — четвёртое.

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

Вы все правильно поняли, но хотелось это все изобразить на одной сводной схеме.
Это возможно?

Возможно, в UML практически все возможно, но как правильно тут заметил Денис, сначала сформулируйте - зачем?
Практически - я использую SPARX EA 10, там для этого можно воспользоваться любой диаграммой:
1. Нарезать пакетов с диаграммами, которые я описал выше.
2. Создать отдельную мега-диаграмму, на которую вытащить все диаграммы в форме фреймов с трассировками между элементами диаграмм, чтобы было понятно - что из чего следует и как что от чего зависит - распечатать в цвете на промышленном плоттере формата A-0 или больше, гораздо больше)))
3. Устроить мега-презентацию руководству компании в огромной аудитории на гигантском распечатанном заранее плакате(тах).
Таким образом, вы получите все и сразу на одной диаграмме. Ваша миссия будет выполнена с высокой степенью вероятности, если докладчик будет смекалистым и не облажается (типа "генеральский эффект" или что-то подобное).

И еще... Я схему делаю в PowerDesigner-е, в нем нету Requirements Diagram

Как-то работал на DWH с сим инструментом, но потом перешел полностью на SPARX. Как в Designer-е отобразить требования, подсказать не могу, спросите спецов по данному продукту. Но, подозреваю, там должен быть элемент Requirement.

Будьте проще. Нет в нотации UML инструмента "все и сразу", зато он есть за ее пределами  )

Отличная диаграмма!

Один из вариантов использования:

При работе с господрядчиками часто встречается ситуация, когда надо еще до обследования написать документ требований/архитектуры и изменять его потом нельзя. В результате вставляется диаграмма одновременно "обо всем" и "ни о чем". Под эту диаграмму можно подтянуть массу проектов и сказать что они ей соответствуют. Главное не сопровождать пояснениями!!!

* сделать надпись ESB, но не расписывать как и какие будут реализованы интервейсы
* нарисовать облако, написать интернет, но ни в коем случае не расписывать используемые протоколы
* нарисовать молнию, но не писать, то ли это Зевс поражающий титанов, то ли прогноз погоды

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

Без описания того, кто и как будет использовать эту схему, обсуждать её правильность или неправильность можно долго.

Представьте вопрос «Я нарисовал схему дома, что в ней не так»? Приходит водопроводчик, видит одно, электронщик — другое, архитектор — третье, дизайнер по интерьеру — четвёртое.

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

Схема нужна для приблизительной оценки объема работ по реализации проекта.
Эту оценку будут делать:
1) директор фирмы-исполнителя, менеджера проекта, которые НЕ имеют большого опыта в разработке подобных проектов
2) два внешних консультанта, участвующие в разработке других интернет-проектов

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

...
Практически - я использую SPARX EA 10...
...
2. Создать отдельную мега-диаграмму, на которую вытащить все диаграммы в форме фреймов с трассировками между элементами диаграмм...

У меня установлена 8-я версия. В принципе могу попробовать нарисовать в нем.
Какой тип диаграммы надо выбрать при создании такой мега-диаграммы? Там ведь надо сначала обязательно выбрать тип диаграммы.

Как-то работал на DWH с сим инструментом, но потом перешел полностью на SPARX

А что не понравилось в PowerDesigner-e?