Ну я там назвал это "1. Ввести данные... на основании квитанции". Просто тарифы меня сбивают все время.

В нашем деле ясность и однозначность формулировко имеет первостепенное значение.

То есть "2. Рассчитать сумму оплаты по тарифам" - это не то, для чего "пользователь обращается к системе"?
Ведь оператор хочет узнать - "А какая сумма то к оплате"?

Оператору думаю это без надобности. Оператор желает внести сумму платежа и оформить этот платеж надлежайшим образом. А система в этом ему помогает. Это основная задача оператора - зафиксировать прием платежей.

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

Теперь бац - появляется система

Потом оператору нужно, собственно, произвести оплату, то есть внести сумму оплаты в систему, которую дал ему на руки клиент.

Оператору произвести оплату не нужно, ему нужно принять оплату и должным образом ее зарегистрировать

Потом оператору нужно узнать сдачу, которую ему нужно сдать клиенту.

Да оператор хотел бы выяснить сдачу с переданной клиентом суммы и оплачиваемой им - но это не цель оператора, это защита интереса клиента -(ему дадут правильную сдачу) и оператора (он тоже сдаст правильную сдачу, не обманув клиента или сам не обманувшись)

PS. Сохранение в базе, это не задача оператора, то есть выходит, что это не кейс, а уже функция системы.

Да это функция системы. В нашем случае это постусловие, т.е. состояние в которое перейдет система после исполнения варианта использования.

Очень часто значимость ВИ определяется тем, изменит ли свое состояние система или нет.

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

Вот, переосмыслил диаграмму.

Решил объединить запросные данные к архиву в один кейс. Пока без детализации. Правильное ли решение?

Как в остальном?

Вот, переосмыслил диаграмму.

Не стоит слишком замарачиваться с диаграммой ВИ. Больше усилий потратьте на спецификацию ВИ и связанных с ним артефактов: доп требований, пользовательских интерфейсов, бизнес-объектов

В целом пусть будет такая диаграмма. Кстати к Печать квитанции я бы от Оформить платеж сделал отношение включения, поскольку квитанцию следует печатать всегда. Либо вооще убрал Печатать квитанцию - это шаг Оформления платежа

Кейс 1:
Предусловия:
1) Выполнен Кейс "Настройка АРМ пользователя"
2) Оператор ввел логин и пароль.

Основной сценарий (электроснабжение):
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система сохраняет введенные данные в архив
2. Оператор инициирует расчет суммы, на основании установленного тарифа
3. Система расчитывает и выводит сумму оплаты, на основании установленного тарифа
4. Оператор инициирует оплату
5. Система сохраняет транзакцию в архиве
6. Оператор инициирует печать квитанции с указанием номер АРМ, даты платежа, номера платежа и оплаченной суммы, с учетом услуги по оформлению платежа.

Почитайте рекомендации по написанию ВИ

Кейс 1:

Что за кейс? как именуется, какова его цель?, кто действующее лицо, если другие участники кейса, интересы которых следует соблюсти

Предусловия:
1) Выполнен Кейс "Настройка АРМ пользователя"
2) Оператор ввел логин и пароль.

Действительно так? Может все-таки написать проще? Заданы тарифы, дата - хотя мне как-то все это представляется странноватым
Оператор ввел логин и пароль - больше смахивает на реализацию, может просто авторизирован в системе?

Основной сценарий (электроснабжение):
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система сохраняет введенные данные в архив

Архив понятие реализации. Вообще сохранение данных начато рано, а если у клиента не окажется денег? (забыл кошелек)

2. Оператор инициирует расчет суммы, на основании установленного тарифа
3. Система расчитывает и выводит сумму оплаты, на основании установленного тарифа

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

4. Оператор инициирует оплату
5. Система сохраняет транзакцию в архиве

Как то выглядит странно и похоже на описание того, что сделано, а не на то что должно быть сделано

6. Оператор инициирует печать квитанции с указанием номер АРМ, даты платежа, номера платежа и оплаченной суммы, с учетом услуги по оформлению платежа.

К чему такие подробности - покажите их на форме квитанции. А где кстати реакция системы?

Незачтено Попробуйте еще разок

ВИ: Оформить платеж за электроснабжение
ID: 1
Краткое описание:
Оформление платежа за электроснабжение на основании предоставленного клиентом извещении
Основное действующее лицо: Оператор
Второстепенные действующие лица: Клиент
Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
3. На рабочем месте оператора установлен тариф, процент за услугу, текущая дата (а что Вам кажется странным, где ошибка?)
Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система определяет сумму оплаты, на основании установленного тарифа
3. Система определяет сдачу, как разницу между введенной и рассчитанной суммой
4. Оператор принимает от клиента наличные и совершает оплату
5. Система выдает квитанцию об оплате
6. Система регистрирует транзакцию
Постусловия:
Нет
Альтернативные потоки:
Нет.

А так?

Второстепенные действующие лица: Клиент

Конечно, этого нет явно в описании, но заинтересованным лицом будет в данном ВИ и коммунальная служба - она заинтересована в получении  денег. Но это я так, просто рассуждаю
 

Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
3. На рабочем месте оператора установлен тариф, процент за услугу, текущая дата (а что Вам кажется странным, где ошибка?)

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

Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система определяет сумму оплаты, на основании установленного тарифа
3. Система определяет сдачу, как разницу между введенной и рассчитанной суммой

Тут вы что-то пропустили. Сумма - указанная в извещении, это сумма которую клиент готов оплатить - полностью, или частично. Сдача будет вычисляться как я понимаю, после того когда клиент передаст сумму денег превышающую сумму указанную в извещении. Либо я чего-то не догоняю

4. Оператор принимает от клиента наличные и совершает оплату

Опять же реакция системы не видна. Оператор принял оператор совершил, а система что делает? Выдает квитанцию?

5. Система выдает квитанцию об оплате
6. Система регистрирует транзакцию

Объединить в один шаг

Постусловия:
Нет

как же нет.
зарегистрирован новый платеж, напечатана квитанция, выдана сдача

Альтернативные потоки:
Нет.

ну с этим еще предстоит разобраться

А так?

Уже много лучше

Переосмыслил. Все таки решил выделить запросы оператора к архиву, как отдельный кейс.
Все таки цель в данном конкретном кейсе это просто провести платеж, без всяких дополнительных тарифов и расчетов.
Я так думаю

ВИ: Оформить платеж за электроснабжение
ID: 1
Краткое описание:
Оформление платежа за электроснабжение на основании предоставленного клиентом извещении
Основное действующее лицо: Оператор
Второстепенные действующие лица: Клиент
Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Оператор вводит сумму, переданную клиентом для оплаты
3. Система определяет сдачу
4. Оператор подтверждает оплату
5. Система регистрирует платеж и выдает квитанцию об оплате

Постусловия:
Зарегистрирован новый платеж, напечатана квитанция, выдана сдача
Расширения:
1а. Оператор вводит данные с другого извещения, предоставленного клиентом
1b. Система определяет общую сумму к оплате за все извещения
1с. Возврат на п.2 основного сценария

Что-то мне ваши расширения не нравятся.

Я так понимаю, вы хотите передать то, что можно оформить сразу несколько платежей (в данном случае одного типа). Система подсчитает общую сумму за все сделанные платежи. Когда будет сделана оплата, система рассчитает требуемую сдачу и напечатает нужно количество квитанций?

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

А если несколько платежей разных типов ? То как следуте поступить в этом случае, чтобы система рассчитала общую сумму по всем платежам?

И еще вопрос.
Как лучше поступить с разными видами платежей (за разные услуги)?
Все таки описать в общем кейсе?

Каким образом правильно это сделать?

Ё-маё. Мне за сегодня надо все диаграммы закончить

И еще вопрос.
Как лучше поступить с разными видами платежей (за разные услуги)?
Все таки описать в общем кейсе?

Каким образом правильно это сделать?

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

Можно было бы указать так:
1. Оператор инициирует ВИ "оформить платеж"
2. Система предлагает выбрать тип платежа
3. Оператор указывает один из типов
4. Система предлагает ввести детали платежа
5. Оператор вводит необходимые данные согласно извещению
6. Система вычисляет сумму платежа, добавляя ее к общей сумме, предъявляемой к оплате
7. Система предлагает добавить следующий платеж
8. Если есть еще платежи
    8.1 Оператор повторяет пункты 3-6
9. Иначе
    9.1 Оператор Завершает оформление платежей
    9.2 Система выводит общую сумму платежа и предлагает ввести сумму денег о клиента
    9.3 Оператор подтверждает совершение оплаты
    9.4 Система сохраняет данные платежей, вычисляет сдачу, печатает квитанции

Т.е. вариантов может быть много, правильным будет тот, который наиболее полно описывает цели и удовлетворяет интересы участников

Galogen, спасибо!

Но остался вопрос с п.6. Система вычисляет сумму платежа, добавляя ее к общей сумме, предъявляемой к оплате

Нужен ли этот пункт вобще?

И второе. Навая активити-диаграмму.

Посмотрите пожалуйста... 

Разбавлю ваш диалог, господа.
Мой вариант основного сценария приёма платежа по данной постановке:
1. Оператор выбирает тип платежа и инициирует ввод данных

 (Имхо изящнее и ближе к реалу, чем вариант Эдуарда, при реализации тут будет 3 батона или выпадающий список, в любом случае для пользователя это будет буквально один клик.)

2. Система запрашивает набор параметров платежа в соответствии с выбранным типом.
3. Оператор определяет параметры платежа в соответствии с извещением.
4. Система рассчитывает и отображает оператору:
- Сумму, начисленную согласно текущим тарифам, и разницу с данными, предоставленными клиентом;
- Сумму комиссии за приём платежа;
- Итоговую сумму, которую должен внести клиент.

(Тут Вы, господа, явно упустили аж 2 важнейших момента из постановки: 1) То, что насчитал клиент (или система начислений) в своём извещении может не сойтись с тем, что насчитает наша система (ведь у нас администратор каждый день это настраивает), об этом обязательно нужно оповестить клиента 2) За приём платежа через наш АРМ взимается комиссия, итоговую сумму клиент не знает и может с ней быть не согласен.)

5. Оператор знакомит с итоговыми суммами клиента (клиент не возражает), и инициирует добавление платежа в группу.

(Как я уже писал ранее - важный шаг с точки зрения бизнеса, да ещё и расширения тут могут быть.)

6. Система отображает общую сумму оплаты для группы и предлагает ввести сумму фактической оплаты.
7. Шаги 1-7 повторяются для всех извещений текущего клиента.

(Тут расширения из серии "клиент передумал насчёт вон того платежа").

8. Оператор вводит сумму фактической оплаты.
9. Система рассчитывает и отображает сдачу.
10. Оператор подтверждает приём группы платежей.
11. Система запрашивает подтверждение - оператор подтверждает.

(Опять упущенный и весьма важный шаг, диктуемый суровой реальностью.)

12. Система добавляет информацию о платежах в архив и формирует квитанции.

Работу с группой платежей я бы вынес в отдельный ВИ, ибо в рамках группы вижу расширения, связанные, как минимум, с изменением, отменой и восстановлением отдельных платежей. Единый ВИ с описанием расширений тут может превратиться в месиво.