Пишите, что обнаружила система
❌ Пользователь забыл пароль и не может авторизоваться — неудачная формулировка.
Мы не знаем, действительно ли пользователь забыл пароль. Возможно:
* Он ошибся в одной букве или символе.
* Забыл переключить раскладку клавиатуры.
* Пароль был введён автоматически, но некорректно.
* 🐈 По клавиатуре прошлась кошка и случайно нажались лишние символы.
Система не способна читать мысли пользователя.
Хорошие формулировки:
1️⃣ Использованы недопустимые символы в логине или пароле
2️⃣ Введённый логин отсутствует в системе
3️⃣ Пароль не соответствует сохранённому в системе
4️⃣ Превышено допустимое количество попыток ввода пароля
5️⃣ Ошибка сервера
Эти формулировки точные и отражают факты, которые может выявить система, без предположений о действиях пользователя.
Такие формулировки позволяют ясно понять причину ошибки и корректно спроектировать сценарий её обработки.
#usecase #documentation
❌ Пользователь забыл пароль и не может авторизоваться — неудачная формулировка.
Мы не знаем, действительно ли пользователь забыл пароль. Возможно:
* Он ошибся в одной букве или символе.
* Забыл переключить раскладку клавиатуры.
* Пароль был введён автоматически, но некорректно.
* 🐈 По клавиатуре прошлась кошка и случайно нажались лишние символы.
Система не способна читать мысли пользователя.
Хорошие формулировки:
1️⃣ Использованы недопустимые символы в логине или пароле
2️⃣ Введённый логин отсутствует в системе
3️⃣ Пароль не соответствует сохранённому в системе
4️⃣ Превышено допустимое количество попыток ввода пароля
5️⃣ Ошибка сервера
Эти формулировки точные и отражают факты, которые может выявить система, без предположений о действиях пользователя.
Такие формулировки позволяют ясно понять причину ошибки и корректно спроектировать сценарий её обработки.
#usecase #documentation
👍8🔥7⚡2👏1💯1
Идеальная техника для поиска альтернативных кейсов и анализа, что может пойти не так — это Use Case
Use Case описывается по определенному шаблону. Основные пункты — Основной сценарий и Расширения.
Основной сценарий для записи к врачу:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Система резервирует слот, врача и кабинет.
6️⃣ Система отправляет уведомление о записи.
Как находить альтернативные сценарии?
Проходим по каждому шагу и задаём себе вопрос: «Что может пойти не так?»
Найденные альтернативы — это расширения основного сценария.
Примеры расширений (альтернативные сценарии):
1️⃣ Пользователь выбирает врача — Что может быть по-другому?
1.а. Врач отсутствует в списке.
Например, пользователь неправильно ввел ФИО врача
2️⃣ Система отображает доступные слоты
2.а. У выбранного врача нет свободных слотов
3️⃣ Пользователь выбирает дату и время
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4️⃣ Ввод причины обращения
4.а. Введенное кол-во символов превышает максимально допустимое.
5️⃣ Система резервирует слот
5.а. Врач или кабинет уже заняты в это время.
5.b. Техническая ошибка при резервировании.
6️⃣ Система отправляет уведомление
6.а. Почта пользователя указана неверно.
6.b. Почтовый сервер недоступен.
✏️ Мы проделали ШАГ 1 на пути к проработке сценариев! Мы определили возможные альтернативные кейсы.
Потренируйтесь дальше сами. Попробуйте найти и другие альтернативные сценарии.
✏️ Затем ШАГ 2 — выберите те сценарии, которые действительно будете обрабатывать. А еще подумайте, а как можно спроектировать систему так, чтобы избежать части альтернативных сценариев? 😉
✏️ ШАГ 3 — напишите, как система должна вести себя в случае выполнения этих расширений.
#usecase #documentation
Use Case описывается по определенному шаблону. Основные пункты — Основной сценарий и Расширения.
Основной сценарий для записи к врачу:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Система резервирует слот, врача и кабинет.
6️⃣ Система отправляет уведомление о записи.
Как находить альтернативные сценарии?
Проходим по каждому шагу и задаём себе вопрос: «Что может пойти не так?»
Найденные альтернативы — это расширения основного сценария.
Примеры расширений (альтернативные сценарии):
1️⃣ Пользователь выбирает врача — Что может быть по-другому?
1.а. Врач отсутствует в списке.
Например, пользователь неправильно ввел ФИО врача
2️⃣ Система отображает доступные слоты
2.а. У выбранного врача нет свободных слотов
3️⃣ Пользователь выбирает дату и время
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4️⃣ Ввод причины обращения
4.а. Введенное кол-во символов превышает максимально допустимое.
5️⃣ Система резервирует слот
5.а. Врач или кабинет уже заняты в это время.
5.b. Техническая ошибка при резервировании.
6️⃣ Система отправляет уведомление
6.а. Почта пользователя указана неверно.
6.b. Почтовый сервер недоступен.
✏️ Мы проделали ШАГ 1 на пути к проработке сценариев! Мы определили возможные альтернативные кейсы.
Потренируйтесь дальше сами. Попробуйте найти и другие альтернативные сценарии.
✏️ Затем ШАГ 2 — выберите те сценарии, которые действительно будете обрабатывать. А еще подумайте, а как можно спроектировать систему так, чтобы избежать части альтернативных сценариев? 😉
✏️ ШАГ 3 — напишите, как система должна вести себя в случае выполнения этих расширений.
#usecase #documentation
👍8🔥5✍3🤝2💯1
Как вам такой формат? Делать еще разбор Use Case?
Anonymous Poll
94%
🔥 Очень полезно! Хочу больше таких постов.
2%
👍 Интересно, но чего-то не хватает (го в комментарии)
0%
😐 Не заходит.
0%
❓ Что такое Use Case?
4%
😎 Я это всё и так знаю, мне такие разборы не нужны.
👍3💯2
Альтернативные сценарии — не только ошибки!
Судя по опросу, тема юз кейсов актуальна, поэтому продолжим👇
Когда мы думаем об альтернативных сценариях, первое, что приходит в голову — это ошибки, то, что может пойти не так. Но это лишь одна часть. Альтернативные сценарии — это любые пути, по которым может развиваться сюжет. Это ситуации, когда события разворачиваются иначе, чем в основном сценарии, но не обязательно связаны с ошибками.
Примеры:
1️⃣ Запись к врачу.
Основной сценарий: пользователь выбрал дату, время, указал причину обращения и успешно записался.
Альтернативный сценарий:
✏️ Пользователь выбрал ближайший доступный слот автоматически.
✏️Система предложила врача аналогичного профиля, так как выбранный был занят.
2️⃣ Онлайн-заказ еды.
Основной сценарий: клиент выбрал блюда, оплатил, заказ доставлен.
Альтернативный сценарий:
✏️ Клиент выбрал самовывоз.
✏️ Клиент оплатил заказ при получении.
3️⃣ Регистрация на курс.
Основной сценарий: пользователь заполнил анкету, оплатил, получил доступ к курсу.
Альтернативный сценарий:
✏️ Пользователь воспользовался промокодом.
✏️ Регистрация завершена без оплаты — активирован тестовый доступ.
4️⃣ Текстовое сообщение в телефоне.
Основной сценарий: пользователь набрал текст, система предложила автозамену, пользователь подтвердил замену.
Альтернативный сценарий:
✏️ Пользователь решил оставить свой текст без изменений.
✏️ Пользователь отклонил автозамену, но воспользовался предложением другого слова.
Ключевая идея:
Альтернативные сценарии — это варианты взаимодействия пользователя с системой. Они охватывают и ошибки, и другие способы достижения результата.
#usecase
Судя по опросу, тема юз кейсов актуальна, поэтому продолжим👇
Когда мы думаем об альтернативных сценариях, первое, что приходит в голову — это ошибки, то, что может пойти не так. Но это лишь одна часть. Альтернативные сценарии — это любые пути, по которым может развиваться сюжет. Это ситуации, когда события разворачиваются иначе, чем в основном сценарии, но не обязательно связаны с ошибками.
Примеры:
1️⃣ Запись к врачу.
Основной сценарий: пользователь выбрал дату, время, указал причину обращения и успешно записался.
Альтернативный сценарий:
✏️ Пользователь выбрал ближайший доступный слот автоматически.
✏️Система предложила врача аналогичного профиля, так как выбранный был занят.
2️⃣ Онлайн-заказ еды.
Основной сценарий: клиент выбрал блюда, оплатил, заказ доставлен.
Альтернативный сценарий:
✏️ Клиент выбрал самовывоз.
✏️ Клиент оплатил заказ при получении.
3️⃣ Регистрация на курс.
Основной сценарий: пользователь заполнил анкету, оплатил, получил доступ к курсу.
Альтернативный сценарий:
✏️ Пользователь воспользовался промокодом.
✏️ Регистрация завершена без оплаты — активирован тестовый доступ.
4️⃣ Текстовое сообщение в телефоне.
Основной сценарий: пользователь набрал текст, система предложила автозамену, пользователь подтвердил замену.
Альтернативный сценарий:
✏️ Пользователь решил оставить свой текст без изменений.
✏️ Пользователь отклонил автозамену, но воспользовался предложением другого слова.
Ключевая идея:
Альтернативные сценарии — это варианты взаимодействия пользователя с системой. Они охватывают и ошибки, и другие способы достижения результата.
#usecase
👍5🔥5❤3💯1
Про свёртывание ошибок в Use Case
Что мы в основном знаем о технике Use Case? Это последовательность шагов между пользователем и системой. Но без дополнительных знаний и лайфхаков эта техника не раскрывает у писателей весь потенциал.
Одна из полезных техник — свертывание ошибок.
Use case «Обновить программное обеспечение»
Основной сценарий:
1️⃣ Пользователь запускает процесс обновления.
2️⃣ Система проверяет наличие доступных обновлений.
3️⃣ Система устанавливает обновления.
4️⃣ Система проверяет корректность установки.
Обратим внимание на шаг 4. Причин может быть много, почему установка завершилась с ошибкой. В данном юз кейсе пусть нас интересует только одно: обновление закончилось удачей или неудачей?
Пишем расширение:
4а. Установка завершилась с ошибкой.
На этом шаге причины ошибки не важны. Главное, что итог — некорректное обновление.
Но все возможные проверки разработчикам все-равно нужно проработать! Все эти проверки вынесем в отдельный Use Case «Проверить корректность установки». В этом случае каждая ошибка важна.
Основной сценарий:
1️⃣ Система запускает проверку установки.
2️⃣ Система анализирует компоненты.
...
Расширения:
2а. Отсутствуют ключевые компоненты.
2b. Конфликт версий.
2c. Проблемы совместимости с оборудованием.
2d. Ошибки в конфигурации.
...
Здесь ошибки не сворачиваются. Для каждой из них нужно указать конкретное поведение системы: при каких-то кейсах попробовать перезапустить обновление компонента (3 попытки), откатиться на другую версию и пр.
Так когда сворачивать ошибки?
📌 Когда результат Use Case с низкоуровневыми условиями расширений приводит к одному результату в верхнеуровневом Use Case
Техника свёртывания упрощает работу с юз кейсами, но её нужно использовать осознанно, чтобы не потерять важные детали. 😉
#usecase
Что мы в основном знаем о технике Use Case? Это последовательность шагов между пользователем и системой. Но без дополнительных знаний и лайфхаков эта техника не раскрывает у писателей весь потенциал.
Одна из полезных техник — свертывание ошибок.
Use case «Обновить программное обеспечение»
Основной сценарий:
1️⃣ Пользователь запускает процесс обновления.
2️⃣ Система проверяет наличие доступных обновлений.
3️⃣ Система устанавливает обновления.
4️⃣ Система проверяет корректность установки.
Обратим внимание на шаг 4. Причин может быть много, почему установка завершилась с ошибкой. В данном юз кейсе пусть нас интересует только одно: обновление закончилось удачей или неудачей?
Пишем расширение:
4а. Установка завершилась с ошибкой.
На этом шаге причины ошибки не важны. Главное, что итог — некорректное обновление.
Но все возможные проверки разработчикам все-равно нужно проработать! Все эти проверки вынесем в отдельный Use Case «Проверить корректность установки». В этом случае каждая ошибка важна.
Основной сценарий:
1️⃣ Система запускает проверку установки.
2️⃣ Система анализирует компоненты.
...
Расширения:
2а. Отсутствуют ключевые компоненты.
2b. Конфликт версий.
2c. Проблемы совместимости с оборудованием.
2d. Ошибки в конфигурации.
...
Здесь ошибки не сворачиваются. Для каждой из них нужно указать конкретное поведение системы: при каких-то кейсах попробовать перезапустить обновление компонента (3 попытки), откатиться на другую версию и пр.
Так когда сворачивать ошибки?
📌 Когда результат Use Case с низкоуровневыми условиями расширений приводит к одному результату в верхнеуровневом Use Case
Техника свёртывания упрощает работу с юз кейсами, но её нужно использовать осознанно, чтобы не потерять важные детали. 😉
#usecase
❤6👍3✍2🔥2💯1
👍4🔥2💯2
Писать детали пользовательского интерфейса в Use Case? Смотрим минусы ⬇
Когда вы добавляете в Use Case такие детали, как названия кнопок или элементы интерфейса, это создает множество проблем.
Например:
* Пользователь выбирает значение из выпадающего списка.
* Пользователь нажимает кнопку «Сохранить».
Что произойдет, если вы с командой решили изменить интерфейс? Список заменили на радиобаттоны, кнопку переименовали в «Добавить». Теперь вам придется обновлять не только макеты в фигме, но и документацию.
📌 Чем это плохо?
1️⃣ Неудобная поддержка
Изменения интерфейса — обычное рутинное дело. А поддерживать актуальность и макетов, и документации сложно, особенно на крупных проектах.
А если у вас на одну экранную форму 5 юз кейсов, то во всех пяти нужно поправить название элемента — неудобно, легко забыть, легко ошибиться.
2️⃣ Сложности с поиском чего-то в документации
Допустим, тестировщик хочет узнать, как работает кнопка «Сохранить». Он ищет это слово в документации через Ctrl+F, но не находит, потому что кнопку переименовали в «Добавить».
3️⃣ Снижение универсальности
Use Case должен описывать, как процесс движется вперед, а не зависеть от элементов интерфейса.
4️⃣ Запутанность источников правды
Представьте, вы отдали разработчикам задачу реализовать Use Case с кнопкой «Сохранить», а на макетах указана «Добавить». В итоге разработчик реализует «Сохранить», но тестировщик заводит баг, так как проверяет по макетам. Кто прав? Какой источник считать главным?
📌 Как по-другому?
Вместо Нажимает кнопку «Сохранить» пишите: Пользователь инициирует сохранение.
Вместо Выбирает значение из выпадающего списка пишите: Пользователь выбирает значение...
💡 За дизайн отвечают макеты, пусть все элементы с точными названиями и типами останутся там.
💡 Use Case должен отображать как движется процесс вперед, что делает пользователь, как система на это реагирует, но без привязки к элементам интерфейса.
💡 Описание всех элементов конечно же нужно делать, но не с помощью техники Use Case. Это уже другая история.
#usecase #documentation
Когда вы добавляете в Use Case такие детали, как названия кнопок или элементы интерфейса, это создает множество проблем.
Например:
* Пользователь выбирает значение из выпадающего списка.
* Пользователь нажимает кнопку «Сохранить».
Что произойдет, если вы с командой решили изменить интерфейс? Список заменили на радиобаттоны, кнопку переименовали в «Добавить». Теперь вам придется обновлять не только макеты в фигме, но и документацию.
📌 Чем это плохо?
1️⃣ Неудобная поддержка
Изменения интерфейса — обычное рутинное дело. А поддерживать актуальность и макетов, и документации сложно, особенно на крупных проектах.
А если у вас на одну экранную форму 5 юз кейсов, то во всех пяти нужно поправить название элемента — неудобно, легко забыть, легко ошибиться.
2️⃣ Сложности с поиском чего-то в документации
Допустим, тестировщик хочет узнать, как работает кнопка «Сохранить». Он ищет это слово в документации через Ctrl+F, но не находит, потому что кнопку переименовали в «Добавить».
3️⃣ Снижение универсальности
Use Case должен описывать, как процесс движется вперед, а не зависеть от элементов интерфейса.
4️⃣ Запутанность источников правды
Представьте, вы отдали разработчикам задачу реализовать Use Case с кнопкой «Сохранить», а на макетах указана «Добавить». В итоге разработчик реализует «Сохранить», но тестировщик заводит баг, так как проверяет по макетам. Кто прав? Какой источник считать главным?
📌 Как по-другому?
Вместо Нажимает кнопку «Сохранить» пишите: Пользователь инициирует сохранение.
Вместо Выбирает значение из выпадающего списка пишите: Пользователь выбирает значение...
💡 За дизайн отвечают макеты, пусть все элементы с точными названиями и типами останутся там.
💡 Use Case должен отображать как движется процесс вперед, что делает пользователь, как система на это реагирует, но без привязки к элементам интерфейса.
💡 Описание всех элементов конечно же нужно делать, но не с помощью техники Use Case. Это уже другая история.
#usecase #documentation
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6💯4
По User Story не написать документацию
User Story и Use Case сравнивают по самым разным критериям. Мне нравится сравнение по одному неочевидному пункту. Возможно, эта мысль станет для кого-то новой.
📌 По юз кейсам можно вести документацию, а по юзер стори — нет.
Почему?
👉 User Story в формате «Я, как пользователь, хочу..., чтобы...» отражает намерение, но не даёт подробностей. Она не объясняет, как именно реализован программный продукт. Даже с критериями приемки сложно понять, как работает система в целом.
👉 Use Case, напротив, позволяет вести документацию. Сначала он пишется как часть ТЗ, а после реализации становится документацией.
User Story помогает понять что нужно, а Use Case объясняет как это работает.
#usecase #documentation
User Story и Use Case сравнивают по самым разным критериям. Мне нравится сравнение по одному неочевидному пункту. Возможно, эта мысль станет для кого-то новой.
📌 По юз кейсам можно вести документацию, а по юзер стори — нет.
Почему?
👉 User Story в формате «Я, как пользователь, хочу..., чтобы...» отражает намерение, но не даёт подробностей. Она не объясняет, как именно реализован программный продукт. Даже с критериями приемки сложно понять, как работает система в целом.
👉 Use Case, напротив, позволяет вести документацию. Сначала он пишется как часть ТЗ, а после реализации становится документацией.
User Story помогает понять что нужно, а Use Case объясняет как это работает.
#usecase #documentation
👍12✍3🔥3💯1
Use Case — это не про «писать», это про «мыслить»
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
С Use Case у меня любовь с первого взгляда.
Впервые я узнала об этой технике в ВУЗе. Именно эти знания помогли мне устроиться на первую работу. В качестве тестового задания нужно было проработать все юз кейсы по процессу восстановления пароля VK. Проверяющий оценил мое внимание к деталям, ведь я описала десятки альтернативных сценариев. 😅
С тех пор Use Cases стали частью многих моих проектов. Где-то у описания задачи юз кейс — это был обязательный пункт шаблона, а где-то мы полноценно вели документацию по продукту в формате юз кейс.
Из абсурдного и забавного:
Как то меня заставили писать юз кейсы для распила бюджета, где важно было не качество, а количество написанных страниц. 🤦♀️
Для меня техника Use Case — не способ писать, а способ мыслить. Прорабатывая сценарий по шаблону, у аналитика все требования раскладываются по полочкам.
📌 Оформление — вторично. Требования можно оформить хоть в виде списка в вордовском документе или в конфлюенсе, на бумаге, на стикере, да хоть мелом на асфальте. 😅
📌 Первично — продумать, а что будем делать. И техника Use Case учит именно думать, а не только писать.
Попробуйте использовать Use Case на своих проектах — техника действительно работает!
#usecase #documentation #sa_dev
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
С Use Case у меня любовь с первого взгляда.
Впервые я узнала об этой технике в ВУЗе. Именно эти знания помогли мне устроиться на первую работу. В качестве тестового задания нужно было проработать все юз кейсы по процессу восстановления пароля VK. Проверяющий оценил мое внимание к деталям, ведь я описала десятки альтернативных сценариев. 😅
С тех пор Use Cases стали частью многих моих проектов. Где-то у описания задачи юз кейс — это был обязательный пункт шаблона, а где-то мы полноценно вели документацию по продукту в формате юз кейс.
Из абсурдного и забавного:
Как то меня заставили писать юз кейсы для распила бюджета, где важно было не качество, а количество написанных страниц. 🤦♀️
Для меня техника Use Case — не способ писать, а способ мыслить. Прорабатывая сценарий по шаблону, у аналитика все требования раскладываются по полочкам.
📌 Оформление — вторично. Требования можно оформить хоть в виде списка в вордовском документе или в конфлюенсе, на бумаге, на стикере, да хоть мелом на асфальте. 😅
📌 Первично — продумать, а что будем делать. И техника Use Case учит именно думать, а не только писать.
Попробуйте использовать Use Case на своих проектах — техника действительно работает!
#usecase #documentation #sa_dev
👍6❤🔥5💯4
Альтернативные сценарии в процессе авторизации
Ранее вы прорабатывали альтернативные сценарии для процесса авторизации 👆
Спасибо всем, кто поучаствовал.
Давайте дополним этот список:
✏️ Истекший срок действия пароля — пользователь пытается войти, но его пароль больше не актуален и требует обновления.
✏️ Учетная запись заблокирована — например, из-за подозрительной активности или нарушений правил.
✏️ Попытка входа с неизвестного устройства — система запрашивает дополнительное подтверждение (например, код из SMS).
✏️ Превышение времени сессии на странице авторизации — пользователь слишком долго заполнял данные, и сессия авторизации истекла.
✏️ Попытка входа в аккаунт без подтвержденной почты — система просит завершить регистрацию или подтвердить email.
✏️ Вход с VPN или из другой страны — система может запросить дополнительное подтверждение личности.
✏️ Неверный или отсутствующий токен безопасности — например, при попытке входа через сохраненную ссылку на форму авторизации.
Если у вас есть еще идеи, пишите в комментарии 👇
#usecase
Ранее вы прорабатывали альтернативные сценарии для процесса авторизации 👆
Спасибо всем, кто поучаствовал.
Давайте дополним этот список:
✏️ Истекший срок действия пароля — пользователь пытается войти, но его пароль больше не актуален и требует обновления.
✏️ Учетная запись заблокирована — например, из-за подозрительной активности или нарушений правил.
✏️ Попытка входа с неизвестного устройства — система запрашивает дополнительное подтверждение (например, код из SMS).
✏️ Превышение времени сессии на странице авторизации — пользователь слишком долго заполнял данные, и сессия авторизации истекла.
✏️ Попытка входа в аккаунт без подтвержденной почты — система просит завершить регистрацию или подтвердить email.
✏️ Вход с VPN или из другой страны — система может запросить дополнительное подтверждение личности.
✏️ Неверный или отсутствующий токен безопасности — например, при попытке входа через сохраненную ссылку на форму авторизации.
Если у вас есть еще идеи, пишите в комментарии 👇
#usecase
👍7🔥4❤2✍1
Как писала ранее, Use Case оформляются по шаблону. И следовать ему нужно не для красивого оформления, а для качественной проработки логики работы системы.
Что вообще такое Use Case?
📌 Use Case — это описание того, как пользователь, другая система или любой другой объект взаимодействует с системой для достижения определённой цели.
Вернемся к прошлому примеру про запись на прием к врачу и заполним остальные пункты шаблона.
Название Use Case (Цель): Записаться на прием к врачу.
Действующие лица: Пользователь (пациент).
Минимальные гарантии:
* Пользователь увидит форму записи на прием к врачу.
Гарантии успеха:
* Пользователь успешно записан на прием к врачу.
* Система отправляет подтверждение на электронную почту или телефон.
Триггер: Пользователь решает записаться на прием к врачу.
Предусловие: Пользователь авторизован в системе.
Основной сценарий:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Пользователь указывает свой email
6️⃣ Система резервирует слот, врача и кабинет.
7️⃣ Система отправляет письмо с уведомлением о записи на указанный email.
Расширения:
1.а. Врач отсутствует в списке (например, пользователь неправильно ввел ФИО врача).
2.а. У выбранного врача нет свободных слотов.
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4.а. Введенное количество символов превышает максимально допустимое.
5.а. Введен email не по формату *@*.*
6.а. Врач или кабинет уже заняты в это время.
6.b. Техническая ошибка при резервировании.
7.а. Почта пользователя указана неверно.
7.b. Почтовый сервер недоступен.
#usecase #documentation
Что вообще такое Use Case?
📌 Use Case — это описание того, как пользователь, другая система или любой другой объект взаимодействует с системой для достижения определённой цели.
Вернемся к прошлому примеру про запись на прием к врачу и заполним остальные пункты шаблона.
Название Use Case (Цель): Записаться на прием к врачу.
Действующие лица: Пользователь (пациент).
Минимальные гарантии:
* Пользователь увидит форму записи на прием к врачу.
Гарантии успеха:
* Пользователь успешно записан на прием к врачу.
* Система отправляет подтверждение на электронную почту или телефон.
Триггер: Пользователь решает записаться на прием к врачу.
Предусловие: Пользователь авторизован в системе.
Основной сценарий:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Пользователь указывает свой email
6️⃣ Система резервирует слот, врача и кабинет.
7️⃣ Система отправляет письмо с уведомлением о записи на указанный email.
Расширения:
1.а. Врач отсутствует в списке (например, пользователь неправильно ввел ФИО врача).
2.а. У выбранного врача нет свободных слотов.
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4.а. Введенное количество символов превышает максимально допустимое.
5.а. Введен email не по формату *@*.*
6.а. Врач или кабинет уже заняты в это время.
6.b. Техническая ошибка при резервировании.
7.а. Почта пользователя указана неверно.
7.b. Почтовый сервер недоступен.
#usecase #documentation
👍7✍3🔥2🤔1
Название Use Case — не просто название
Это цель действующего лица, которую оно хочет достичь с помощью системы.
✅ UC «Записаться к врачу» — цель Пациента.
✅ UC «Заполнить карточку», «Отредактировать карточку», «Просмотреть карточку» — цели врача.
✅ UC «Просмотреть расписание врача», «Изменить запись» — цели администратора клиники.
..........
Думаете, мы все разобрали по теме Use Case?
Спойлер: конечно же, нет
Как обсуждали в предыдущих постах (ищите их по хэштегу #usecase), UC — это не просто формальный документ. Это инструмент мышления и анализа.
UC — интереснее, чем кажется. А вы знали, что:
❗ Участник в UC — это не просто пользователь.
❗ Минимальные и максимальные гарантии действительно важно продумывать.
❗ Без идентификаторов UC теряют потенциал для трассировки требований.
❗ Как правильно ссылаться на UC и зачем это нужно?
❗ Как UC интегрируются с другими документами/артефактами системного анализа?
❗ Как грамотно оформлять расширения, избегать дублирования шагов и не превращать UC в 100-страничный документ?
и пр.
Ответить на все эти вопросы в рамках коротких постов сложно. Нужны практика и полное погружение.
👉 Рекомендуем: изучите статьи в интернете, прочитайте книги и попробуйте применять эту технику на своих проектах.
#usecase
https://analystcore.com/#program
Это цель действующего лица, которую оно хочет достичь с помощью системы.
✅ UC «Записаться к врачу» — цель Пациента.
✅ UC «Заполнить карточку», «Отредактировать карточку», «Просмотреть карточку» — цели врача.
✅ UC «Просмотреть расписание врача», «Изменить запись» — цели администратора клиники.
..........
Думаете, мы все разобрали по теме Use Case?
Как обсуждали в предыдущих постах (ищите их по хэштегу #usecase), UC — это не просто формальный документ. Это инструмент мышления и анализа.
UC — интереснее, чем кажется. А вы знали, что:
❗ Участник в UC — это не просто пользователь.
❗ Минимальные и максимальные гарантии действительно важно продумывать.
❗ Без идентификаторов UC теряют потенциал для трассировки требований.
❗ Как правильно ссылаться на UC и зачем это нужно?
❗ Как UC интегрируются с другими документами/артефактами системного анализа?
❗ Как грамотно оформлять расширения, избегать дублирования шагов и не превращать UC в 100-страничный документ?
и пр.
Ответить на все эти вопросы в рамках коротких постов сложно. Нужны практика и полное погружение.
👉 Рекомендуем: изучите статьи в интернете, прочитайте книги и попробуйте применять эту технику на своих проектах.
А если хотите быстрее освоить Use Case, приглашаем вас на курс AnalystCore!Мы рассказываем, как UC вписываются в требования, учим прорабатывать сценарии и раскрываем весь потенциал этой техники для работы системного аналитика. 👊Если есть вопросы по программе, пишите нам в ЛС 👉 @analystcoreteam
#usecase
https://analystcore.com/#program
👍5🔥4🆒2
Приглашаем вас поучаствовать в создании контента этого канала!💡
Насколько вам понятен текущий уровень материалов на канале?
Пройдите опрос ниже 👇
Мы стремимся делать наши публикации максимально полезными и интересными для вас. Выберите вариант, который лучше всего отражает ваши ощущения.
Напоминаем! У нас есть второй канал — AnalystCore -> Старт карьеры.
Там мы:
✅ Объясняем теорию простыми словами,
✅ Даем практические упражнения,
✅ Мотивируем учиться и развиваться в профессии.
Присоединяйтесь! 🚀
Насколько вам понятен текущий уровень материалов на канале?
Пройдите опрос ниже 👇
Мы стремимся делать наши публикации максимально полезными и интересными для вас. Выберите вариант, который лучше всего отражает ваши ощущения.
Напоминаем! У нас есть второй канал — AnalystCore -> Старт карьеры.
Там мы:
✅ Объясняем теорию простыми словами,
✅ Даем практические упражнения,
✅ Мотивируем учиться и развиваться в профессии.
Присоединяйтесь! 🚀
🔥5👍2
Насколько вам понятен текущий уровень материалов на канале? Ваш голос поможет нам адаптировать контент под ваши ожидания!
Anonymous Poll
76%
💡 Всё отлично, материалы понятны и полезны.
14%
🤔 Иногда сложно, хочется больше примеров и пояснений.
0%
😅 Часто сложно, лучше больше фокусироваться на базовых вещах и теории.
10%
🚀 Слишком просто, можно углубить уровень проработки.
👍6🔥2
Кэширование данных на фронтенде
Ранее мы делились шаблоном для постановки задачи на фронтенд. Но это еще не всё, что хочет получить разработчик! ✨
На фронтенде часто используют кэширование, чтобы:
* на странице быстрее загружались данные,
* не нагружать лишний раз сервер.
Какую роль играет системный аналитик в проработке кэширования?
📌 Мы помогаем ответить на важные вопросы:
* Какие данные нужно кэшировать?
* Сколько времени данные остаются актуальными?
* Что делать, если кэш устарел?
Примеры данных, которые можно закэшировать:
* Значения справочников (страны, валюты, категории услуг).
* Информация о пользователе (если она редко меняется).
* Результаты фильтров, например, товары по заданным критериям.
* Настройки интерфейса (тема, язык).
Пример ТЗ:
Вызвать метод GET <uri> с параметрами <указываем параметры и откуда их брать>.
- Если в ответе пришел http-код = 200, то закэшировать ответ на 5 минут.
- Иначе отобразить ошибку в алерте с текстом из <указываем параметры>.
#frontend
Ранее мы делились шаблоном для постановки задачи на фронтенд. Но это еще не всё, что хочет получить разработчик! ✨
На фронтенде часто используют кэширование, чтобы:
* на странице быстрее загружались данные,
* не нагружать лишний раз сервер.
Какую роль играет системный аналитик в проработке кэширования?
📌 Мы помогаем ответить на важные вопросы:
* Какие данные нужно кэшировать?
* Сколько времени данные остаются актуальными?
* Что делать, если кэш устарел?
Примеры данных, которые можно закэшировать:
* Значения справочников (страны, валюты, категории услуг).
* Информация о пользователе (если она редко меняется).
* Результаты фильтров, например, товары по заданным критериям.
* Настройки интерфейса (тема, язык).
Пример ТЗ:
Вызвать метод GET <uri> с параметрами <указываем параметры и откуда их брать>.
- Если в ответе пришел http-код = 200, то закэшировать ответ на 5 минут.
- Иначе отобразить ошибку в алерте с текстом из <указываем параметры>.
#frontend
👍8✍4
👉 Поделитесь, сталкивались ли вы с задачами кэширования? Что было самым сложным? 💬
Anonymous Poll
14%
1️⃣ Да, определял(а), что кэшировать
11%
2️⃣ Да, сложно было выбрать время жизни кэша
11%
3️⃣ Да, возникали проблемы с устаревшими данными
68%
4️⃣ Нет, с задачами кэширования не сталкивался(ась)
👍5