Как я себе это представляю:

Задача:
Создать программу для торговли фьючерсными контрактами, опционами и форекс контрактами. Программа включает клиентское приложение и серверное, осуществляющее связь клиентов с clearing firm.

После беседы с заказчиком появляются следующие термины

Conract - ключевая сущность, в которой агрегируются все торгуемые контракты Инструментов. Нужно  для обеспечения ссылочной целостности к этой одной сущности из других сущностей, не показанных на схеме
Spot - содержит данные по наиболее простым торгуемым контрактам, таким как:  Акций, Облигаций, Индексов, Металов и т.д.
Future - содержит данные по Фьючерсным контрактам
Option - содержит данные по Опционным контрактам. Каждый опцион содержит так называемый underlining контракт, им может быть либо Фьючерс, либо Spot
Asset - базовый актив. Торгуемый контракт Spot или Future имеет под собой один базовый актив, т.е. что реально покупается или продается.
Exchange - Биржа. Один контракт может торговаться только на одной Бирже.

А так же он рассказывает. - "Хочу иметь программу, как trading floor 2, чтобы пользователи подключались и видели информацию по ценам, списки доступных инструментов, размещали ордера различных видов, "оne triggers other", "one cancels other", отложенные ордера. Как администратор хочу иметь доступ к их сделкам, возможность повышать-понижать их maintanance margin, чтобы в конце дня у меня был отчет с балансом, а так же если из-за ситуации на рынке у пользователя баланс начинает стремительно уменьшатся, то я оперативно получаю письмо или смс об этом и связываюсь с ним для решения проблемы, и, если ситуация совсем плоха, то контракты начинают продваться автоматически."

Как бы выглядила диаграмма и звучало резюме аналитика в этом случае?

Это достаточно большая задача, на прошлой работе я как раз занимался этим и строил похожую систему. Резюме аналитика в двух словах быть не может. Если Вы только начали заниматься данной темой, то вам будет очень не просто. Сформулируйте пока цели проекта и основные возможности системы в виде каждого отдельного пункта, предложите на базе какой архитектуры будете это делать и оформите в виде документа - Vision. Потом начертите какие по вашему мнению есть бизнес объекты, потом можно накалякать СДВИ (только правильно,если не знаете как, то лучше просто детализируйте каждую фичу) и каждый ВИ распешите в виде сценария. Вот пока ближайшее ваши действия. Я могу накалакать основные БО, какие должны быть в системе, и помочь вам в описании требований, но это уже получиться прямое решение вашей проблемы, которе за бесплатно не делается. Если хотите бесплатных советов, то спрашивайте конкретно, и я вам отвечу.

Цели проекта:
Создать программу для онлайн торговли фьючерсами и опционами на биржах.

Возможности системы:

-   Получать данные с внешних источников (clearing firm, новостные сайты, другие провайдеры)
-   Отсылать ордера в clearing firm.
-   Редактировать ордера.
-   Менять и запоминать layout клиентской программы.
-   Менять и запоминать цвета форм, шрифты клиентской программы.
-   Экспортировать формы и таблицы клиентской программы.
-   Предоставлять графики.
-   Распечатывать ордера.
-   Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
-   Возможность у клиента иметь несколько accounts.
-   Управление accounts для админа.
-   Отчеты по account – для админа и клиента.
-   Размещение ордера админом для клиента.
-   Клиентская программа ведет лог событий.
-   События сопровождаются звуками.
-   Авто обновление компонентов клиентского приложения.
-   Управление margins клиентов админом.



Реализация программ планируется на C#  DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting.


Можно выделить два актера
 - Админ
 - Клиент

Как видно многие функции у них совпадают, но админ имеет больше возможностей. Как мне кажется админ не наследуется от клиента, а они оба происходят от одного предка – пользователя.

Часть фичей сразу просятся в ВИ для актеров:

Пользователь:
-   Разместить ордер
-   Редактировать ордер
-   Создавать отчет
-   Экспортировать данные
-   Распечатать ордер

Админ:
-   Размесить заказ для клиентов
-   Управление пользовательским эккаунтом
-   Управление margins клиентов


но не все, например
-   Получать данные с внешних источников.
-   Отсылать ордера в clearing firm
-   Менять и запоминать layout клиентской программы.
-   Менять и запоминать цвета форм, шрифты клиентской программы
-   Предоставлять графики.
-   Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
-   Возможность у клиента иметь несколько accounts
-   Клиентская программа ведет лог событий.
-   События сопровождаются звуками.
-   Авто обновление компонентов клиентского приложения

Если бы существовал актер Сервер или Клиентская программа, то они ложились бы их ВИ. Как оформляются такие вещи в документации?

ps диаграмму визио выложу завтра, если сумею зарегистрироваться.

Цели проекта:
Создать программу для онлайн торговли фьючерсами и опционами на биржах.

Нужна цель Разработки или Системы:

2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.

Возможности системы:
-   Получать данные с внешних источников (clearing firm, новостные сайты, другие провайдеры)
Что за данные?[/i]
-   Отсылать ордера в clearing firm.
Я бы называл clearing firm - брокером. Разница огромна. Вам же не нужно осуществлять clearing как таковой?[/i]
-   Редактировать ордера.
Я бы сказал в первую очередь выствить ордера и только потом редактировать[/i]
-   Менять и запоминать layout клиентской программы.
-   Менять и запоминать цвета форм, шрифты клиентской программы.
-   Экспортировать формы и таблицы клиентской программы.
В один пункт, да и то я бы это опустил[/i]
-   Предоставлять графики.
В пукнт с данными[/i]
-   Распечатывать ордера.
Только ордера?? Это не та важно[/i]
-   Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
-   Возможность у клиента иметь несколько accounts.
-   Управление accounts для админа.
-   Отчеты по account – для админа и клиента.
Входит в управление[/i]
-   Размещение ордера админом для клиента.
В п. размещение ордера[/i]
-   Клиентская программа ведет лог событий.
Не так важно[/i]
-   События сопровождаются звуками.
Не важно[/i]
-   Авто обновление компонентов клиентского приложения.
-   Управление margins клиентов админом.
А это огромный пукнт, Вы сами не знаете еще на что подписались[/i]

Реализация программ планируется на C#  DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting.

Можно БД и ОС указать

Можно выделить два актера
 - Админ
 - Клиент

А Брокера или Поставщика данных куда дели??

Пользователь:
-   Разместить ордер
-   Редактировать ордер
-   Создавать отчет
-   Экспортировать данные
-   Распечатать ордер

Это не ВИ - это функции. ВИ должен нести цель для актера. Какая цель у ВИ "Распечатать ордер"?

Админ:
-   Размесить заказ для клиентов
-   Управление пользовательским эккаунтом
-   Управление margins клиентов

Вот это больше похоже на ВИ. Но если Вы пишите все в глаголах, то так и пишите, н-р, "Управлять ...."

но не все, например

Многие ваши ф-ии, войдут в ВИ как составная часть

Как оформляются такие вещи в документации?

Какие??

Цели проекта:Создать систему дающую пользователям доступ к онлайн торговле фьючерсами и опционами на биржах посредством одного брокера. Брокер должен поддерживать протокол patsystem API. Система рассчитана на 10 тысяч работающих пользователей. Состоит из двух частей: клиентское приложение и сервер. Клиентское приложение связывается с сервером через интернет по TCP протоколу. Сервер является промежуточным звеном между клиентом и брокером.



Возможности системы:

-   Получать данные с внешних источников :
   o   Списки товаров и их цены
   o   Историю изменений цен определенных товаров.
   o   Новости

-   Выставлять ордера брокеру и редактировать их.
   o   Клиент делает это самостоятельно
   o   Админ делает это для клинта.
   o   Выставлять отложенные ордера, OCO, OTO.

-   Управлять эккаунтом
   o   Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
   o   Возможность у клиента иметь несколько accounts.
   o   Управление accounts для админа.
   o   Отчеты по account – для админа и клиента.
Еще добавлю
   o   Пополнять и снимать деньги со счета.


-   Авто обновление компонентов клиентского приложения.

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

Хм, в теории этот пункт звучит так: админ неуверен в способности пользователя вести торговлю и завышает его margin. То есть попытки пользователя поместить ордер будут отвергнуты если его текущий баланс ниже какого-то уровня.
Наверное нужно сделать пункт и подпункт.
-   Управление эккаунтами  клиентов админом
   o   Управление margins клиентов.

Архитектура
Реализация программ планируется на C#  DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting. База данных MSSQL Server 2000. OC - Windows.


Можно выделить следующих актеров:
-   Админ
-   Клиент
-   Брокер
-   Поставщик данных


Брокреа наследуем от Поставщика данных, а Админа и Клиента наследуем от Пользователя и выделяем ВИ для всех актеров:

Пользователь:
-   Управлять эккаунтом
-   Управлять ордерами


Админ:
-   Управлять эккаунтами клиентов.

Поставщик данных
-   Поставить данные

Брокер
- ?


Получается такая очень мальенькая диаграмма:
Это нонсенс или для верхнего уровня нормально?

Цели проектато указаны, а вот какие цели создания самой системы? ;-).

Цели проектато указаны, а вот какие цели создания самой системы? ;-).

Ммм... Зачем создавать систему?
 - Заказчик хочет отделиться от своего брокера и стать самостоятельным ведя свой бизнес.

Так, уже лучше. Т.е.:
Предоставить новый сервис/возможность для 10.000 Клиентов одновреммной торговли на Биржах (каких? всех? какими инструментами?).
Контролировать процесс торговли Клиентами.
Далее ....

З.Ы. Все таки предлагаю отказаться от термина clearing firms, если Вы не вкладываете что-то еще в это понятие кроме Брокера.
З.З.Ы. Выложите диаграмму в формате Розы, я подправлю.

Так, уже лучше. Т.е.:
Предоставить новый сервис/возможность для 10.000 Клиентов одновреммной торговли на Биржах (каких? всех? какими инструментами?).

Futures and options. Но предусмотреть возможность расширения для форекса.

З.Ы. Все таки предлагаю отказаться от термина clearing firms, если Вы не вкладываете что-то еще в это понятие кроме Брокера.

В моем понимании Брокер - это посредник между трейдером и биржей. Но если быть точным то эта цепочка на физическом уровне выглядит так:
клиент - брокер - cleargin firm - exchange

Система призвана реализовать звено "Брокер" и, боюсь, при общении с экспертами может возникнуть путаница.

Через кого Вы будете торговать, имя?? Т.е. протокол patsystem API к кому будет идти от вас.
Мне кажется Вы путаете понятия. Вообще процесс идет так:
Брокер->Биржа (или даже скорее ECN, а потом уже биржа)   - выставление ордера
Брокер->Клиринг - сообщить все ордера, какие были выполнены на Бирже за промежуток времени (день, час ...)
Клиринг->Биржа  - сверить полученный список отправленных и реально исполненых на Бирже
Клиринг->Брокер - сообщить какие Ордера реально исполнены, а какие нет. Это происходит раз в день

Причем этот процесс делают только прайм Брокеры. А подброкеры просто все отправляют прайм прокеру:
Брокер -> Прайм Брокер -> Биржа (или даже скорее ECN, а потом уже биржа)

Вы что реально хотите клиерить ордера или просто отправлять их на Биржу??

Через кого Вы будете торговать, имя?? Т.е. протокол patsystem API к кому будет идти от вас.

Заказчик не определился. Сошлись на том, что PATSAPI подходит для него, так как существуют десятки брокеров поддерживающих этот протокол и при желании можно свободно переместиться от одного к другому.

Причем этот процесс делают только прайм Брокеры. А подброкеры просто все отправляют прайм прокеру:
Брокер -> Прайм Брокер -> Биржа (или даже скорее ECN, а потом уже биржа)

Вы что реально хотите клиерить ордера или просто отправлять их на Биржу??

В интервью заказчик употреблял clearing firm как партнера через которого ордера будут уходить на биржу. Себя он называл брокером. Этот вопрос я проясню, но, безусловно, задача стоит просто отправлять ордера на биржу, ни о каком клиринге речи не идет.

Заказчик не определился. Сошлись на том, что PATSAPI подходит для него, так как существуют десятки брокеров поддерживающих этот протокол и при желании можно свободно переместиться от одного к другому.

Ну Вы и сами ответили себе на вопрос. Заказчик не всегда знает о чем говрит ...

Вот что получилось:

Целый ВИ под "Войти в систему"? Но ведь на практике пользователь совершит всего несколько поростых действий, навроде "распечатать отчет". Хотя некая законченнченность и невключенность в другие ВИ у "войти в систему" есть...
Так, в голове проясняется. Куда двигаться дальше, по науке?

У ВИ "Войти в систему" - одна большая цель - получить доступ к контексту Системы, не сделав этого он не может ничего делать дальше.

Теперь расписывайте каждый ВИ в виде сценария.