Начали разрабатывать новый модуль, по учету денежных средств.
Хотелось бы услышать критики и замечаний, возможно полезных советов, так как опыта не много.
Сделал описание по Коберну, ну и Use Case диаграмму.

сообственно беглое описание:
Модуль по учету расходов по грузу.
Компания перевозчик грузов.
Клиент приносит, либо перечисляет по безналу денежные средства на счет компании перевозчика. Менеджер на основании платежного поручения или полученных денежных средств формирует платеж «Зачисление», который рассматривается Бухгалтером на основании полученных наличных денежных средств или платежа по безналичному расчету, принимает решение о подтверждении «Зачисления». Система производит пополнение счета на указанную сумму.
Далее менеджер формирует платеж «Оплата» на оплату услуг по заявке. На момент формирования платежа, состояние счета может быть = 0, если есть не подтвержденные «Зачисления», либо должно быть больше нуля. Бухгалтер рассматривает платеж «Оплата», на основании состояния счета клиента и его правильности заполнения, подтверждает, если все корректно. Система списывает указанную сумму с виртуального счета клиента и производит зачисление на виртуальный счет компании.

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

Реализация по Коберну:

Вариант использования 1
Зачисление средств на счет клиента и оплата оказанных услуг.

Контекст использования: Оплата за оказанные услуги.
Область действия: Система Логистик
Уровень: обобщенный
Основное действующее лицо: Менеджер
Участники и интересы:
Клиент – оплатить услуги.
Менеджер – принять деньги за услуги, сформировать платеж за оказанные услуги по заявке.
Бухгалтер – подтвердить принятие средств на счет клиента и оплату услуг
Предусловие: Оказаны услуги по заявке
Минимальные гарантии: Денежные средства зачислены на счет клиента
Гарантия успеха: Денежные средства зачислены на счет клиента, подтверждена оплата за оказанные услуги
Триггер: Клиент приносит\перечисляет денежные средства.
Основной сценарий:
1.   Клиент приносит либо переводит на банковский счет деньги
2.   Менеджер принимает деньги от клиента (нал или платеж по безналу).
3.   Менеджер формирует платеж «Зачисление» на счет клиента.
4.   Бухгалтер проверяет и подтверждает платеж «Зачисление».
5.   Менеджер формирует платеж «Оплата» за оказанные услуги по заявке.   
6.   Бухгалтер проверяет и подтверждает платеж «Оплата» за оказанные услуги по заявке.

Расширения:
   3a. Сумма зачисления на счет равна нулю:
      3a1. Менеджер редактирует платеж «Зачисление»
      3a2. Переход на шаг 4
   3b. Указан несуществующий клиент:
      3b1. Система сообщает, что клиент в системе не существует.
      3b2. Выход из сценария
   4a.Платеж «Зачисление» некорректен или курс зачисления неудовлетворительный :
       4a1. Менеджер редактирует платеж «Зачисление»
      4a2. Переход на шаг 4
   5a. Неоплаченных услуг нет:
      5a1. Система сообщает об отсутствии неоплаченных услуг.
      5a2. Выход из сценария.
   5b. Средств на счету недостаточно:
      5b1. Система проверяет неподтвержденные зачисления на счет клиента.
5b1a. Есть неподтвержденные зачисления + средства на счету, перекрывают сумму платежа:
   Формируется платеж.
5b2a. Есть неподтвержденные зачисления + средства на счету, не перекрывают сумму платежа:
Формируется платеж на сумму имеющихся на счету средств и неподтвержденных зачислений.
         5b3a. Неподтвержденных зачислений нет:
            Формируется платеж на сумму имеющихся на счету средств
         5b4a. Неподтвержденных зачислений нет, средств на счету нет:
Система информирует об отсутствии средств на счету и производит выход из сценария   
   5с. Указан несуществующий клиент:
      5с1. Система сообщает, что клиент в системе не существует.
      5с2. Выход из сценария
   5d. Менеджер указал сумму большую суммы стоимости услуг или равную нулю:
      5d1. Система сообщает, что клиент в системе не существует.
      5d2. Выход из сценария
   6a. Бухгалтер обнаружил несоответствия в платеже «Оплата»:
      6a1. Бухгалтер сообщает менеджеру об ошибке.
      6a2. Менеджер редактирует платеж «Оплата».
      6a3. Переход на шаг 6
   6b. Недостаточно средств на счету клиента:
      6b1. Система сообщает о недостаче средств.
      6b2. Выход из сценария

Ну и вот диаграмма use case



ЗЫ: Просьба ногами сильно не пинать 

ЗЫ: Просьба ногами сильно не пинать

А руками бить можно? :-)

Вообще написано красиво, а вот диаграмму я не понял, вернее понял, но мне думается что-то с ней не так.

Однако по порядку.
1. Что за ВИ мы описываем? Видно: обобщеный, по стилю описания прозрачный, тип бизнес процесс? Или все-таки системный? Мне думается смешение точек зрения в одном прецеденте.

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

3. Не очень понятно условие 3а, как оно согласуется с шагом 2 основного сценария и триггером - деньги уже либо перечислены, либо принесены

4. Условие 3б неожиданно сообщает нам, что клиент должен быть зарегистрирован в системе. С другой стороны это понятно, а как иначе можно перечислить деньги (есть клиент - значит есть виртуальный счет)

5. если следовать логике Коберна диаграмма ВИ фактически есть модель Действующие лица и цели, цели, которые они пытаются достичь, используя систему!
Как Вы сами указываете, Клиент не Основное действующее лицо, но он инициирует процесс. Непосредственно с системой работают Менеджер и Бухгалтер, следовательно для нас важны цели именно этих действующих лиц:
Менеджер: Сформировать платеж "Зачисление", Сформировать платеж "Оплата"
Бухгалтер: Подтвердить платеж "Зачисление", Подтвердить платеж "Оплата". Причем что примечательно, действия бухгалтера не имеют самостоятельного значения - они должны быть произведены в ответ на создание документов Менеджером. Я бы вероятно выделил два ВИ Принять деньги клиента - Оформить оплату, где участвуют помимо системы менеджер и бухгалтер - как видно из постановки задачи - жить они не могут друг без друга.

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

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

Не очень понятна идея с виртуальным счетом. Я понимаю на нем деньги появляются, если есть неопровержимое доказательство - либо наличные, либо квитанция о переводе нужной суммы на счет компании-огранизации. Не понятно зачем нужно столько сложное действие менеджера и бухгалтера, может менеджера исключить?

Далее как я понимаю оплата услуги совершается постфактум, т.е. когда услуга оказана? А если так, кто мешает оплатить услугу на основании документа "Оказанная услуга" .

Совет: если никакой такой системы не существует и описан процесс как есть, так и опишите процесс как есть, а потом как Вы его видете с точки зрения уже существующей системы, как должно быть, покажите улучшение бизнес-процесса или улучшения системы.

Если Вы просто модернизируете существующую систему - разрабатываете модуль , который будет содержать фактически два документа Зачисление и Оплата и возможно виртуальный счет - может не стоит копия ломать и тратить время на моделирования ясной ситуации. Напишите варианты и дело с концом - получите функциональные требования, добавть бизнес-правила - и все модуль готов...


Итого. Вариант использования в целом - 4 "хорошо", Диаграмма вариантов использования - "посредственно". Но это только мое мнение:-)

1. В названии юзкейса присутстует "и", что уже подозрительно.
2. Слот "Участники и интересы" .. думаю, что "заплатить" не следует считать интересом Клиента. Интерес клиента -- как раз что-то получить, и очень здорово если это будет на халяву :-), а получить оплату -- аккурат интерес организации или клерков которые ее предстваляют.
3. Заявлен уровень юзкейса как "обощенный", но тем не менее видим "3a1. Менеджер редактирует платеж «Зачисление»", это не вполне корректно для такого уровня.
4. "Основной сценарий: 1.   Клиент приносит либо переводит на банковский счет деньги" -- нужно выбрать какой-то один способ в качестве основного (который чаще например встречается) и для него описывать ситуацию. Если различие в формах оплаты не сказывается на ходе сценария, то имеет смысл вынести "перевод денег на счет" -- суть безналичный способ оплаты в слот "Вариации технологий и данных".
5. Про "Черный ящик" Эд уже сказал ...
6. Что хотим сказать пунктом 3а (3a. Сумма зачисления на счет равна нулю:) и последующими шагами?
7. Диаграмма юзкейсов больше похожа на функциональную декомпозицию. Думаю ее нужно переделать.

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

Ну в принципе уже все сказали, добавлю и свои 5 коп.:
1. Надо определиться что мы описываем?! СВИ или БВИ. Я так понимаю что СВИ, т.е. ВИ Системы. Как уже сказал Эдуард, нужно выделить актеров только тех, кто использует Систему непосредстенно.
2. По Коберну, первый этап - это выделить актерев и их цели. Думаю, следующим постом Денис, ты, это и сделаешь. Тем более, что Эдуард уже львиную долю за тебя сделал.
3. Не надо на ДВИ указывать Систему - это не правильно, т.к. все ВИ реализуются этой самой Системой и тогда придется ко всем приделывать атера-Систему.