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

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

Считаете ли вы корректным выделение в отдельные UC таких функций, как "сохранение данных", "удаление данных" и "авторизация"? Если нет, то как бы вы составили диаграмму использования без потери информативности?

Уже 100 раз говорили о том, что ДВИ не имеет смысла без описания сценариев. Все на ДВИ не отобразишь - будет каша.
Как вариант: ДВИ+описание каждого ВИ на несколько строк о его назначении.

Уже 100 раз говорили о том, что ДВИ не имеет смысла без описания сценариев. Все на ДВИ не отобразишь - будет каша.
Как вариант: ДВИ+описание каждого ВИ на несколько строк о его назначении.

А кто говорит о ДВИ без описания сценариев? Я написала, что

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

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

На мой взгляд, диаграмма в корне не верная, т.к. здесь перемешаны и действия, выполняемые системой, и пользовательские цели.

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

Действия с данными (CRUD) лучше не описывать.

В итоге должно получиться что-то подобное (см. рисунок во вложении).

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

Это овальчики в рамке с человечком за ее пределами. Это может быть похоже на что угодно. Например, DFD диаграмма, но это не ДВИ.

Почему:
1. все кто пользуются пользователи. Поэтому от того, что я вижу на вашей картинке Пользователя это не прибавляет мне понимания требований к системе.
2. из диаграамы я могу понять что система МобильнаяСуперПупер должна уметь(позволять) ручной ввод данных, ввод данных через фотографирование, сохранение данных в каком-то МТ, авторизацию в системе, передачу данных в некую БД, включая удаление сохраненных данных из МТ. Но это никак не сообщает мне о том ЗАЧЕМ ВСЕ ЭТО ДЕЛАЕТСЯ И ДЛЯ КОГО
3. Т.е. эта диаграмма может быть концепцией решения, иллюстрацией при разговоре с программистом, но скорее всего не функциональными требованиями к системе от лица его возможных пользователей - опять же непонятно для кого и зачем
4. если убрать слово расход и таинственное МТ, то подобная диаграмма подойдет пожалуй к любому приложению баз данных

1. все кто пользуются пользователи.

А что с этим не так? Если предусмотрена единственная роль в системе.

2. из диаграамы я могу понять что система МобильнаяСуперПупер должна уметь(позволять) ручной ввод данных, ввод данных через фотографирование, сохранение данных в каком-то МТ, авторизацию в системе, передачу данных в некую БД, включая удаление сохраненных данных из МТ.

Я стремилась именно к тому, чтобы проиллюстрировать этой диаграммой предполагаемый функционал будущей системы.

Но это никак не сообщает мне о том ЗАЧЕМ ВСЕ ЭТО ДЕЛАЕТСЯ И ДЛЯ КОГО

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

На мой взгляд, диаграмма в корне не верная, т.к. здесь перемешаны и действия, выполняемые системой, и пользовательские цели.

Вот это и меня смущает.

А ВИ "Ввести данные" включает "Авторизацию".

По замыслу ввод данных и сохранение их в МТ возможно без авторизации. Авторизация нужна лишь для передачи данных в основную базу.

Убрать передачу данных как системную функцию с диаграммы верно только если она происходит автоматически, а не инициируется пользователем. Допустим, инициируется. Что вы можете тогда сказать о ВИ "удаление данных", корректно ли тогда его присутствие?

Улучшенная версия.

Улучшенная версия.

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

Я бы выделил ВИ Сфотографировать объект данных, Распознать объект данных, Передать данные в хранилище

Опишите пожалуйста кратко идею ВИ ввести данные о расходе с клавиатуры
Опишите пожалуйста кратко идею ВИ ввести данные о расходе фотографированием
Опишите пожалуйста кратко идею ВИ передать данные в БД

Распознать объект данных

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

Основная функция приложения на мобильном устройстве - ввод данных о расходах и передача их в основную БД на лицевой счет пользователя. Поэтому фотографирование и ввод с клавиатуры объединены общим UC. Фотографирование лишь способ быстрого ввода данных. А в первой версии диаграммы распознавание было упущено, да.)

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

Что значит будет системный, а Вы какие рассматриваете?

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

Основная функция приложения на мобильном устройстве - ввод данных о расходах и передача их в основную БД на лицевой счет пользователя. Поэтому фотографирование и ввод с клавиатуры объединены общим UC. Фотографирование лишь способ быстрого ввода данных. А в первой версии диаграммы распознавание было упущено, да.)

Я в общем то специально несколько все утрировал.

Какова основная задача или цель использования МУ?
Нечто вроде Занести расход на лицевой счет пользователя - это что за цель? цель пользователя. Зачем это делается - все за кадром. Это и есть системный ВИ, а не бизнес ВИ...

А далее описываем сценарии
1. Выбрать отправку СМС сообщения
2. Указать адрес держателя лицевого счета (утрировано)
3. ввести информацию о расходе
4. отправить сообщение

реакцию системы проигнорировал, но она есть

Или
1. выбрать отправку СМС сообщения
2  Указать адрес держателя лицевого счета (утрировано)
3 выбрать распознанный ранее текст
4 отправить сообщение

ну как-то так...

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

Что значит будет системный, а Вы какие рассматриваете?

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

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

Согласна.

Какова основная задача или цель использования МУ?
Нечто вроде Занести расход на лицевой счет пользователя - это что за цель? цель пользователя. Зачем это делается - все за кадром. Это и есть системный ВИ, а не бизнес ВИ...

А если наше приложения для МУ будет частью некой системы учета личных расходов? Допустим, основной функционал уже работает, а этой доработкой для МУ мы его только расширяем. Оптимизируем операцию ввода данных. Ввод и передача данных – основные UC, для нашей доработки они будут уровня БВИ.

Вот так пожалуй должна выглядеть эта диаграмма. Хотя авторизация тоже вызывает сомнения, нужно ли ее тут показывать как отдельный UC.