Вы умеете писать документацию по продукту?
Anonymous Poll
9%
📄 Конечно! Я в этом спец
44%
💪 Умею, но хотелось бы прокачаться
23%
🤔 Пробую, но пока сложно
24%
✍️ Нет, но хочу научиться!
❤4🔥4💯2
Описывайте логику в формате Если — То — Иначе 🧩
Почему?
Описывая логику работы системы в таком формате, вы минимизируете двусмысленность. Это помогает всем — разработчикам, тестировщикам, дизайнерам, аналитикам — быстро понять, как должна работать система в разных ситуациях.
Пример 1: Отображение данных
- Если пользователь авторизован, то отображать приветственное сообщение с именем.
- Иначе отображать кнопку «Войти».
❌ Если бы вы просто написали «Для авторизованных пользователей нужно отображать приветственное сообщение с именем», то у разработчиков остался бы вопрос, так а что делать, если он НЕ авторизован?
Пример 2: Работа с API
Алгоритм обновления данных:
- Если запрос вернул http-код=200, то обновить таблицу данными из ответа.
- Иначе вывести сообщение об ошибке с текстом из error.message.
- Если вернулся пустой массив, то отобразить текст «Данных пока нет».
- Иначе вывести список данных с пагинацией.
Пример 3: Валидация формы
- Если поле «Email» пустое, то отобразить сообщение «Поле обязательно для заполнения».
- Иначе проверить, соответствует ли введённое значение формату email.
Пример 4: Алгоритм авторизации
- Если пользователь авторизован, то открыть страницу профиля.
- Иначе перенаправить на страницу логина.
- Если роль пользователя «Администратор», то отображать панель управления.
- Иначе выводить страницу «Нет прав».
Почему это работает?
📌 Такой подход универсален. Его понимают и фронтендеры, и бэкендеры, и QA-инженеры, и системные аналитики.
📌 Логика становится очевидной даже через несколько месяцев после написания.
📌 Это упрощает тестирование — тестировщики видят все ветки сценариев.
Используйте формат Если — То — Иначе и забудьте про разночтения в ТЗ. 😉
#frontend #documentation
Почему?
Описывая логику работы системы в таком формате, вы минимизируете двусмысленность. Это помогает всем — разработчикам, тестировщикам, дизайнерам, аналитикам — быстро понять, как должна работать система в разных ситуациях.
Пример 1: Отображение данных
- Если пользователь авторизован, то отображать приветственное сообщение с именем.
- Иначе отображать кнопку «Войти».
❌ Если бы вы просто написали «Для авторизованных пользователей нужно отображать приветственное сообщение с именем», то у разработчиков остался бы вопрос, так а что делать, если он НЕ авторизован?
Пример 2: Работа с API
Алгоритм обновления данных:
- Если запрос вернул http-код=200, то обновить таблицу данными из ответа.
- Иначе вывести сообщение об ошибке с текстом из error.message.
- Если вернулся пустой массив, то отобразить текст «Данных пока нет».
- Иначе вывести список данных с пагинацией.
Пример 3: Валидация формы
- Если поле «Email» пустое, то отобразить сообщение «Поле обязательно для заполнения».
- Иначе проверить, соответствует ли введённое значение формату email.
Пример 4: Алгоритм авторизации
- Если пользователь авторизован, то открыть страницу профиля.
- Иначе перенаправить на страницу логина.
- Если роль пользователя «Администратор», то отображать панель управления.
- Иначе выводить страницу «Нет прав».
Почему это работает?
📌 Такой подход универсален. Его понимают и фронтендеры, и бэкендеры, и QA-инженеры, и системные аналитики.
📌 Логика становится очевидной даже через несколько месяцев после написания.
📌 Это упрощает тестирование — тестировщики видят все ветки сценариев.
Используйте формат Если — То — Иначе и забудьте про разночтения в ТЗ. 😉
#frontend #documentation
🔥8❤5👍4💯1
Судя по предыдущему опросу, тема документации актуальна ✍️
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Я тот самый человек, который любит писать документацию.
Мой секрет — я пишу ТЗ сразу в формате доки. Так убиваем двух зайцев — сначала создаём ТЗ, а после релиза оно превращается в документацию.
Я отношусь к процессу не как к «писательству», а как к задаче по проектированию. Документация структурирована, и когда мы ее пишем, мы идем по шаблону, чтобы ничего не забыть. Это идеальный подход при проектировании.
Я видела разные примеры — и хорошие, и плохие. Со временем я выработала собственный подход, которым хочу поделиться.
💡 Хочу собрать весь накопленный опыт в мини-курс по документации.
🚀 И у вас есть уникальный шанс повлиять на программу!
Напишите, что именно вы хотели бы узнать о документации, ТЗ и др.? Анонимно
https://forms.gle/6wTXhRTmryFjFpS17
Давайте вместе сделаем полезный курс 🔥
#sa_dev #documentation
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Я тот самый человек, который любит писать документацию.
Мой секрет — я пишу ТЗ сразу в формате доки. Так убиваем двух зайцев — сначала создаём ТЗ, а после релиза оно превращается в документацию.
Я отношусь к процессу не как к «писательству», а как к задаче по проектированию. Документация структурирована, и когда мы ее пишем, мы идем по шаблону, чтобы ничего не забыть. Это идеальный подход при проектировании.
Я видела разные примеры — и хорошие, и плохие. Со временем я выработала собственный подход, которым хочу поделиться.
💡 Хочу собрать весь накопленный опыт в мини-курс по документации.
🚀 И у вас есть уникальный шанс повлиять на программу!
Напишите, что именно вы хотели бы узнать о документации, ТЗ и др.? Анонимно
https://forms.gle/6wTXhRTmryFjFpS17
Давайте вместе сделаем полезный курс 🔥
#sa_dev #documentation
🔥6❤🔥2👍2💯1
Плохая задача на фронт? Разбираем на примере 🚨
Представьте, что вы описываете задачу на создание главного экрана в приложении для трекинга физической активности. См. макет.
❌ BAD:
* В верхнем левом углу отображается имя пользователя
* Ниже календарная неделя с выделением текущей даты синим. Отображается день недели и число
* Кол-во км пройденных за день
* Кнопка «Details» открывает экран с прогрессом
* Кол-во шагов
и т.д.
Что тут не так?
1️⃣ Задача бесполезна — просто продублировано описание макета.
2️⃣ Указано расположение элементов — это видно на макете, не пишите это в доке.
3️⃣ Нет ясности для разработчика. Что такое Имя пользователя? Откуда брать календарь? Как узнать кол-во км и кол-во шагов?
4️⃣ Нет альтернативных сценариев. А если пользователь был не в сети и км = 0, что показывать? А если сердцебиение слишком высокое?
Как исправить, расскажем в другом посте.
#frontend #documentation
Представьте, что вы описываете задачу на создание главного экрана в приложении для трекинга физической активности. См. макет.
❌ BAD:
* В верхнем левом углу отображается имя пользователя
* Ниже календарная неделя с выделением текущей даты синим. Отображается день недели и число
* Кол-во км пройденных за день
* Кнопка «Details» открывает экран с прогрессом
* Кол-во шагов
и т.д.
Что тут не так?
1️⃣ Задача бесполезна — просто продублировано описание макета.
2️⃣ Указано расположение элементов — это видно на макете, не пишите это в доке.
3️⃣ Нет ясности для разработчика. Что такое Имя пользователя? Откуда брать календарь? Как узнать кол-во км и кол-во шагов?
4️⃣ Нет альтернативных сценариев. А если пользователь был не в сети и км = 0, что показывать? А если сердцебиение слишком высокое?
Как исправить, расскажем в другом посте.
#frontend #documentation
🔥8👍5✍3💯1
Исправляем задачу на фронт 😎
Перечислить элементы недостаточно.
Как минимум, нужно указать метод, откуда брать данные — из GET /activity/summary.
Но и этого мало.😱
Не всегда можно с ходу понять, какой параметр к чему относится. Фронтендерам часто приходится додумывать, что куда подставить, как что вычислить и с этими вопросами они приходят к нам, системным аналитикам.
Например, в ответе есть параметры distance и dToday.
* distance — это общее расстояние за месяц.
* dToday — как мы предполагаем, это расстояние за день.
Но как разработчику догадаться, что на экране нужно использовать именно dToday, а не distance?
Под параметром dToday может пониматься:
❗ Пройденное расстояние за текущий день
❗ Расстояние, которое осталось пройти сегодня до какой-то цели
❗ Расстояние, которое обновляется реальным временем (например, через трекер)
Без объяснений разработчик может выбрать неверный параметр.
Не будем же скупиться на слова, давайте писать полные постановки 🙌
#frontend #documentation
Перечислить элементы недостаточно.
Как минимум, нужно указать метод, откуда брать данные — из GET /activity/summary.
Но и этого мало.😱
Не всегда можно с ходу понять, какой параметр к чему относится. Фронтендерам часто приходится додумывать, что куда подставить, как что вычислить и с этими вопросами они приходят к нам, системным аналитикам.
Например, в ответе есть параметры distance и dToday.
* distance — это общее расстояние за месяц.
* dToday — как мы предполагаем, это расстояние за день.
Но как разработчику догадаться, что на экране нужно использовать именно dToday, а не distance?
Под параметром dToday может пониматься:
❗ Пройденное расстояние за текущий день
❗ Расстояние, которое осталось пройти сегодня до какой-то цели
❗ Расстояние, которое обновляется реальным временем (например, через трекер)
Без объяснений разработчик может выбрать неверный параметр.
Не будем же скупиться на слова, давайте писать полные постановки 🙌
#frontend #documentation
🔥7👍4✍2❤1💯1
Альтернативные сценарии
Часто многие продумывают только основной сценарий, а про альтернативные забывают, т.к. «это неважно, потом разберемся».
Не мыслите так ❌
Альтернативные кейсы очень важны и задача системного аналитика найти их, подсветить заказчику и вместе решить, как их обрабатывать.
Вернёмся к приложению для трекинга активности. Что здесь может пойти не так? 🤔
1️⃣ Пользователь не сделал ни шага
Телефон был выключен? Нет синхронизации? Отображаем: «Нет данных», 0 или что-то другое?
2️⃣ Пользователь неавторизован
Приложение открыто месяцами, пользователь неактивен. Нужно разлогинивать? Показать сообщение: «Вы не авторизованы. Войдите в аккаунт»?
3️⃣ Высокое сердцебиение
Подсветить показатель красным? Вывести уведомление? Включить сигнал?
4️⃣ Нет интернета
Показать старые данные и предложить подключиться к сети?
5️⃣ Заполнить цель активности
Если цель не установлена, отображать: «Установите цель для лучших результатов!»?
#frontend #requirements #documentation
Часто многие продумывают только основной сценарий, а про альтернативные забывают, т.к. «это неважно, потом разберемся».
Не мыслите так ❌
Альтернативные кейсы очень важны и задача системного аналитика найти их, подсветить заказчику и вместе решить, как их обрабатывать.
Вернёмся к приложению для трекинга активности. Что здесь может пойти не так? 🤔
1️⃣ Пользователь не сделал ни шага
Телефон был выключен? Нет синхронизации? Отображаем: «Нет данных», 0 или что-то другое?
2️⃣ Пользователь неавторизован
Приложение открыто месяцами, пользователь неактивен. Нужно разлогинивать? Показать сообщение: «Вы не авторизованы. Войдите в аккаунт»?
3️⃣ Высокое сердцебиение
Подсветить показатель красным? Вывести уведомление? Включить сигнал?
4️⃣ Нет интернета
Показать старые данные и предложить подключиться к сети?
5️⃣ Заполнить цель активности
Если цель не установлена, отображать: «Установите цель для лучших результатов!»?
#frontend #requirements #documentation
🔥6💯4👍2👏2
Альтернативные сценарии — самое интересное!
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Я тот человек, который обожает прорабатывать альтернативные сценарии, но признаюсь, иногда слишком увлекаюсь этим процессом! 😅
Когда начинаешь искать все возможные кейсы, сложно вовремя остановиться. Но со временем я выработала для себя простой план, который помогает не закопаться в деталях.
Делюсь им с вами:
1️⃣ Определяю роли пользователей и их цели
Чего ждут пользователи от системы? Какие функции?
2️⃣ Выделяю приоритетные цели и начинаю их описывать в формате Use Case
* цель — это название юз кейса, а описание цели (юз кейса) состоит из последовательности шагов и других пунктов шаблона.
3️⃣ Затем в виде списка пишу все альтернативные сценарии для выбранных юз кейсов.
Пишу только названия. Детально пока ничего не прорабатываю.
4️⃣ ✍️ Определяю приоритетные альтернативные сценарии с заказчиком и только после этого начинаю их описывать.
Этот метод вдохновлён подходом Алистера Коберна — автора книги «Writing Effective Use Cases». Его структура помогает не утонуть в работе, не забывая о важных деталях.
Попробуйте, это правда упрощает процесс и экономит время! 🙌
#usecase #documentation
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Я тот человек, который обожает прорабатывать альтернативные сценарии, но признаюсь, иногда слишком увлекаюсь этим процессом! 😅
Когда начинаешь искать все возможные кейсы, сложно вовремя остановиться. Но со временем я выработала для себя простой план, который помогает не закопаться в деталях.
Делюсь им с вами:
1️⃣ Определяю роли пользователей и их цели
Чего ждут пользователи от системы? Какие функции?
2️⃣ Выделяю приоритетные цели и начинаю их описывать в формате Use Case
* цель — это название юз кейса, а описание цели (юз кейса) состоит из последовательности шагов и других пунктов шаблона.
3️⃣ Затем в виде списка пишу все альтернативные сценарии для выбранных юз кейсов.
Пишу только названия. Детально пока ничего не прорабатываю.
4️⃣ ✍️ Определяю приоритетные альтернативные сценарии с заказчиком и только после этого начинаю их описывать.
Этот метод вдохновлён подходом Алистера Коберна — автора книги «Writing Effective Use Cases». Его структура помогает не утонуть в работе, не забывая о важных деталях.
Попробуйте, это правда упрощает процесс и экономит время! 🙌
#usecase #documentation
🔥7👍4👏4💯1
Привет! 👋 Представьте: вы проектируете экран авторизации. Какие альтернативные сценарии стоит продумать? Выберите те, которые кажутся важными, и добавьте свои варианты!
Anonymous Poll
91%
1️⃣ Пользователь ввёл неверный логин или пароль.
76%
2️⃣ Неправильный формат email (например, пропущен @).
48%
3️⃣ Плохое интернет-соединение или его отсутствие.
31%
4️⃣ Смена языка интерфейса. Пользователь хочет переключить язык до авторизации.
76%
5️⃣ Превышено количество попыток входа.
52%
6️⃣ Ввод капчи. Если поведение похоже на автоматический вход (бот).
74%
7️⃣ Запрос на сброс пароля. Пользователь передумал и хочет восстановить доступ.
2%
Ваши варианты 👇
💯5
Кстати, а как вам формулировка альтернативного сценария "Пользователь забыл пароль и не может авторизоваться"?
Anonymous Poll
38%
✅ Все ок
62%
😂 Теперь сомневаюсь, что ок
👍4
Пишите, что обнаружила система
❌ Пользователь забыл пароль и не может авторизоваться — неудачная формулировка.
Мы не знаем, действительно ли пользователь забыл пароль. Возможно:
* Он ошибся в одной букве или символе.
* Забыл переключить раскладку клавиатуры.
* Пароль был введён автоматически, но некорректно.
* 🐈 По клавиатуре прошлась кошка и случайно нажались лишние символы.
Система не способна читать мысли пользователя.
Хорошие формулировки:
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