Use Cases при настройке CRM

Внутренние Use Cases уже частично описаны в блоках описания бизнес-процесса касательно воронки продажи, обслуживания клиента аптеки:

Lucid map

To-do:

Прям раскладываем эти красные блоки, нумеруем, берём в проверку, самими, сотрудниками.

Для чего нужны в первую очередь описания сценариев:

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

Разница между Use case vs User stories:

Ещё примеры:

Список ошибок по составлению:

по видео: https://youtu.be/Rur5DEoqDdM?t=750

В описании нет "вещь", с которой роль исполняет действия, использует - нет "объекта-системы" в описании
В описании нет "основной роли" - основного действующего лица.
Слишком много деталей интерфейса пользователя (тут не согласен = нет описания, нет договора). От неё ремарка: "в качестве общего описания, это ошибка, такое делается уже в реализации с тех.отделом". Что я и предполагал. Получается не пишем слишком подробно интерфейс ещё, чтобы и ограничения по реализации не ставить так же.
Описание низкого уровня. Нужно чуть группировать. Пример: описание когда пользователь вносит несколько типов данных: не разбивать на части, каждой строкой, а сгруппировать - "вносит _____-ието данные: 1, 2, 3"
Не прорабатывают расширения. "Расширения" — то, что может пойти не так.
Не указывают альтернативные сценарии. "Альтернативные сценарии" — то, что приведёт к успеху другим путём.
Считают что Альтернативы = Расширения.
Забывают про предусловия и тригеры.
Относятся к системе как к "черному ящику". (Малик: другими словами обсуждают её архитектуру, внутренность устройства, а не то, что хотят получить от объекта в первую очередь функционально, ещё не обращая внимания на архитектуру. Пункт 3 тоже в ту сторону.)
Не реализуют нумерацию шагов.

wikipedia:

Уровень детализации

Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

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

Шаблон сценария

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

Имя сценария. Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше, чем Регистрирующийся Пользователь), и должно объяснять смысл сценария использования. Неплохо использовать имя сценария, цель актора, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя. Пример: UC-1. Регистрация в личном кабинете.
Цель. Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком акторе, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
Акторы (действующие лица). Актор — это кто-то или что-то вне системы, влияющий(-ее) на систему или находящийся(-ееся) под её влиянием. Актор может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими акторами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия.
Заинтересованные лица (Стейкхолдеры). Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования.
Предварительные условия. Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте также, что предварительные условия это не «активаторы» (см. ниже), так как верные предварительные условия НЕ инициируют выполнение сценария.
Активаторы. Активатор — это событие, инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), а ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.

Есть несколько вариантов, как описать ситуацию, когда активация происходит, но предварительные условия не выполнены.

Один путь состоит в том, чтобы обработать «ошибку» в пределах сценария (как исключение). В принципе такой подход нелогичен, потому что «предварительные условия» — теперь не истинные предварительные условия вообще (потому что поведение сценария определено, даже когда предварительные условия не выполнены).
Другой путь — поместить все предварительные условия в активатор (так, чтобы сценарий не выполнялся, если предварительные условия не выполнены), и создать отдельный сценарий, описывающий проблему.

Порядок Событий. Как минимум, каждый сценарий использования должен описать типичный ход событий, часто представленный как ряд пронумерованных шагов.
Альтернативные пути и дополнения. Сценарии использования могут содержать вторичные пути или альтернативные сценарии, которые являются вариантами основного. Каждое проверенное правило может привести к альтернативному пути, и, когда правил много, количество альтернативных путей возрастает, приводя к очень сложным документам. Иногда лучше использовать условную логику или диаграммы, чтобы описать сценарии со многими правилами и условиями.
Бизнес-правила. Бизнес-правила — способ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

Ограничения сценариев использования

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