Стандарт UML.
Диаграмма в случаи использования.

Петров: оперативность и свод статистики
Оператор : справочная информация о клиентах; обработка запросов
Менеджер: просмотр текущих заявок; контроль рабочего времени оператора
Тех поддержка / Администрация: Установка или настройка ПО; настройка или ремонт оборудования ; администрация пользователей; доступ к новым заявкам (система обработки заявок)

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

Разные пользователи системы, представленные на диаграмме - актёры:
1) типовой пользователь - оператор, менеджер, тех. поддержка - это работники компании, с группировкорй по всполняемым обязанностям.;
2) другая система, взаимодействующая с данной системой обработки заявок;
3) выдуманный пользователь (Петров) - отличается от типичного пользователя как правило, согласовываются функции для него, согласовываются лично с ним

После идентификации пользователя, происходит определённие случаев использования этими пользователям системы (use case)

Это незавершённая часть функционирования системы, обладающая разными ценностями для её пользователя (всё то, что красным)

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

Результат ценность означает, что случай использования, должен принять актёру законченный и ценный, с точки зрения деятельности, результат

Задающий вопросы - ответы на вопросы ; Постоянный клиент - Обслуживание ; Новый клиент - Регистрация

Бизнес диаграмма случаев использования. Диаграмма является примером системы управления магазинами разной торговли, клиент не является пользователем ПО, но является бизнес пользователем всей системы в целом. Отдельно или с оператором

Диаграмма случаев использования может служить структурой ТЗ или его части

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

Примеры использования диаграммы случаев: при управлении разработкой ; рабочие встречи по проекту

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

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