Use кейсы что это
Как и зачем писать Use Cases
Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.
Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.
Что такое Use Case
На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.
Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.
Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».
В жизни встречаются такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.
Текст vs диаграмма/схема
Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовал диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:
Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.
Кому и в каких случаях нужны сценарии
А также другим участникам процесса.
В каких случаях они нужны:
Как их описывать
Давайте рассмотрим пару примеров, они говорят сами за себя.
Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):
Пример 2. Авторизация пользователя:
Важные моменты
Правильных и полезных вам сценариев! Спасибо за внимание.
При написании статьи я использовал материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».
Юзеркейсы: что это такое и как их писать, чтобы вам поверили
Практика показывает, что продать текстом финансовые услуги гораздо сложнее, чем швабры. Но правильно составленный юзеркейс может и то, и другое. Наш автор Саша Ежова (признанный мастер юзеркейсов) составила подробный гайд для внутренней редакции агентства, как писать достоверные пользовательские истории. Здесь публикуем его в сокращенном виде и с примерами.
Это история от первого лица, герой которой рассказывает о своем опыте покупки и использования каких угодно продуктов или услуг – начиная от кредитных карт, заканчивая онлайн-кинотеатрами и квартирой от конкретного застройщика. Что делать, если у вас нет такого опыта? Это не проблема и нет, обманывать никого не придется. Для убедительного и честного текста нужно будет только собрать «жирную» фактуру.
Опишите собственный опыт, если вы уже пользовались или пользуетесь тем самым товаром. Если же сервис или продукт вам не знакомы, обязательно попросите прислать его на тест или предоставить промо-доступ на несколько дней. С некоторыми темами, например кредитов и недвижимости, дела обстоят сложнее, но и о них я позже расскажу.
Пообщайтесь с коллегами, знакомыми, друзьями, друзьями друзей и коллег, незнакомцами в профильных группах на Facebook или Telegram. Обычно я начинаю с коллег и далее иду по цепочке. Как-то мне достался сложный юзеркейс про рефинансирование кредитов. У меня такого опыта нет, но он был у другой сотрудницы агентства. Даже если у человека нет времени на мини-интервью, можно отправить вопросы в мессенджере и в ответ получить голосовые сообщения.
Важно: опыт людей не обязательно будет на 100 % совпадать с темой материала. Это значит, что фактуру придется еще доработать с учетом информации из брифа.
В профильных группах в соцсетях не обязательно объяснять, что пишешь статью — зависит от масштабности вопроса. Если нужно уточнить какие-то мелкие детали, я просто спрашиваю в лоб в комментариях или чате, мол, ребята, а какой у вас опыт в использовании этого продукта?
Нырните во всевозможные форумы и читайте отзывы пользователей. Это особенно помогает при изучении каких-то сложных продуктов. Однажды я писала для застройщика, и герой должен был описать плюсы и минусы одного из ЖК. Вот, например, один из плюсов, на который меня вдохновил отзыв с форума:
В тех же отзывах ищите негатив и очень аккуратно добавляйте его в текст, иначе юзеркейс не получится достоверным. Минусы добавляют реалистичности, но с ними нужно быть осторожными: меньше эмоционального текста, больше коротких фактических предложений. Когда у «минуса» нет никакой эмоциональной окраски, он воспринимается легче и меньше бросается в глаза.
Позвоните в компанию под видом клиента. У того же ЖК на сайте указана возможность онлайн-бронирования квартир: описано, как это сделать, ниже – форма, но непонятно, что именно это дает покупателю (то есть нашему читателю). Такие детали обязательно стоит уточнять и объяснять в тексте.
Вот как это подали мы в статье от лица Паши, руководителя отдела разработки в одной крупной IT-компании:
Не забывайте подписывать картинки и скриншоты — да, вообще все, даже самые, казалось бы, очевидные. Это дополнительный и важный способ коммуникации с читателем.
Объясняйте, почему герой принимает то или иное решение. Здесь я говорю о сторонних вещах, которые тоже нужно пояснить. Помните, я искала плюсы ЖК? Так вот, нашелся еще один на очередном форуме по недвижимости.
Вот так было бы плохо:
А вот так уже хорошо:
Пишите практически так же, как говорили бы вслух (в рамках разумного) или писали в социальных сетях. Да, даже в самых серьезных юзеркейсах допустимы такие слова и словосочетания, как «ноут», «капец», «я в шоке», «я психую», «смотрю киношку» и так далее.
Теперь представьте себя среднестатистическим мужчиной и прочитайте текст вслух. Я отметила красным те словосочетания, которые выбиваются из тональности юзеркейса.
Здесь я упростила слова и добавила боли в мире читателя – про тот же мусорный бак и удаленку.
Старайтесь сохранять примерно одинаковую стилистику всего текста. Перевоплотитесь в героя и представьте, как он говорит в жизни. Вы ведь, когда смотрите сериал, не ожидаете, что доктор Хаус в следующей серии вдруг станет вежливым и больше не будет остроумно шутить? Вот-вот.
Подумайте над акцентом в начале. Можно сделать автора центральным героем, а можно пойти от проблемы читателя и только потом представить героя. Если вы ставите автора в центре повествования в какой-то серьезной теме, сначала нужно подкрепить его авторитет. Например, вот так мы начали один из юзеркейсов для сервиса Финолог:
Если во главе угла будет стоять проблема читателя, тот же абзац получится другим. Это будут общие рекомендации с опорой на документы и факты без лишних эмоций — просто рамка для основного материала.
Прочитайте текст через полчаса после написания. Можно даже вполголоса, чтобы понять, какие предложения звучат нескладно. Иногда перестановка или замена двух-трех слов все меняет в лучшую сторону.
Придумывайте заголовок после того, как написали текст. Не пытайтесь глядя на пустой белый экран сразу придумать привлекательный заголовок — получится «без жизни» и, скорее всего, без важной конкретики. Сначала напишите разные УТП, потом приплюсуйте к ним эмоциональные акценты и интригу. Вообще лучше максимально уходить от метафорических заголовков, которые без контекста не понятны. Заголовок типа «Занимательная история» при беглом просмотре читателю ничего не говорит — он в интернете за день видит примерно 5–10 занимательных историй. Почему именно эта должна его заинтересовать?
Вот неплохие варианты заголовков:
Здесь многое зависит от специфики текста, но если есть возможность и желание сделать юзеркейс более качественным, то вот, что можно сделать:
Фотографируйте детали в мире читателя, но не перебарщивайте. Подумайте, какие возможности сервиса клиенту интересно увидеть. Можно фоткать телефон или ноутбук со стороны, если в распоряжении есть другой смартфон или камера. Например, вот одна из фоток для приложения по фитнесу. Специально публикую в связке с текстом:
Или вот условия, в которых 90 % людей занимаются спортом дома. При этом у меня есть свободная большая комната, где можно сделать более приличные фото:
Будьте героем сами. Здесь поможет муж, жена, штатив, коллега или собственная вытянутая рука.
Нам важно, чтобы читатель себя узнал. Не забывайте, что это юзеркейс, а не продуктовая статья. Фотки не должны быть правильные, вылизанные, но и в трешак скатываться не стоит. Я просто прогоняю их через фильтры VSCO, убираю лишние детали в Snapseed.
Кстати, вот что значит скатываться в трешак:
Мы закрыли лицо картинкой — нам лишь важно показать, как делать не надо. В таком случае вы зря тратите прежде всего свое время. Что здесь не так:
фото сделаны при плохом освещении, все в шумах;
А вот хорошие примеры нескольких самостоятельных фото для этого же юзеркейса, но уже от лица девушки (меня).
Документирование в разработке ПО
INTRO
Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.
Одним из болезненных вопросов в разработке ПО всегда был и остаётся процесс документирования этой самой разработки. Вам доводилось приходить на проект, который делают уже пару лет, но, при этом, вы никак не можете с ним разобраться, потому что из документов есть одно техническое задание, да и то написано в самом начале и не отражает и половины функционала системы? Мне доводилось. И это, честно говоря, очень печальное и байтораздирающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально построить процесс так, чтобы неопознанного и неописанного функционала не было, все члены команды вовремя получали актуальную информацию и вообще был мир во всём
Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.
1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.
Для себя я выработала набор базовых правил, которые позволяют эффективно документировать, планировать и контролировать разработку в комфортных для всех участников условиях.
1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.
Я предлагаю на суд уважаемого сообщества схему документирования, которая кажется мне удобной, логичной и правильной. И – да, это работает.
Итак, какие типы документов используются в схеме.
1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).
На рисунке ниже — схема связи между этими документами. 
Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.
В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».
Use Case
Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.
Test Case
Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.
Bug Report
Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.
Руководство пользователя/Руководство администратора
Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.
Use кейсы что это
Use Case (вариант использования, ВИ, Прецедент, юскейс) — это сценарная техника описания взаимодействия. С помощью Use Case может быть описано и пользовательское требование, и требование к взаимодействию систем, и описание взаимодействия людей и компаний в реальной жизни.
В общем случае, с помощью Use Case может описываться взаимодействие двух или большего количества участников, имеющее конкретную цель:
В разработке ПО эту технику часто применяют для проектирования и описания взаимодействия пользователя и системы, поэтому название Use Case часто воспринимает как синоним требования человека-пользователя к решению определенной задачи в системе. В статье мы будем рассматривать использование Use Case для описания взаимодействия пользователя с системой.
Исторически требования к функционированию системы описывались в виде отдельных функций. Ивар Якобсон в середине 1990-х годов предложил Use Case как альтернативу и дополнение описания функциональности системы. Описание требований к системе не в виде отдельных функций, а в виде описания контекста и последовательности действий пользователя помогает сформировать набор функциональных требований, который будет обеспечивать полноту и неизбыточность требований.
Мы можем сформулировать набор функциональных требований:
FRQ1 Система должна предоставить пользователю возможность ввести код бронирования
FRQ2 Система должна сохранить сведения о регистрации пассажира на рейс
FRQ3 Система должна предоставить пользователю возможность распечатать посадочный талон
Пока это разрозненные требования, мы не можем проверить их набор на полноту и соответствие целям пользователей, так как мы не видим:
1) контекста выполнения этих функций,
2) роли пользователя, которому должна быть доступна функция,
3) целей этого пользователя при использовании системы.
Use Case задаёт формат, в котором все эти важные факторы описываются и учитываются. И перечисленные выше функциональные требования можно объединить в один Use Case, описывающий цель пользователя.
Пример базовой части Use Case.
Регистрация пассажира на рейс
Описание решения задачи пользователя в системе в виде Use Case должно определять:
Основной поток действий Use Case описывает успешную последовательность событий, необходимую для достижения конкретной цели основного действующего лица.
Предусловие — условия, которые должны выполняться, чтобы сценарий вообще мог начаться. Мы не будем проверять это условие в процессе работы сценария, так как мы предварительно договорились, что оно истинно.
Результат — или «гарантия успеха» — след, который оставляет сценарий. Наличие результата говорит нам, что и Пассажир достиг своей цели.
Этот Use Case пишется для проектирования решения, его потребителем будет команда разработки.
Назначение Use Case для разных участников проекта
Конечно, для разработки функциональных требований к системе мы пишем целый набор Use Case, учитывающих цели пользователей нескольких ролей. Этот набор позволяет обеспечить полноту требований пользователей к системе. Набор Use Case является набором требований более высокого уровня абстракции, чем набор отдельных функциональных требований, и в то же время полностью покрывает пользовательские требования к функциональности. Поэтому он более удобен в работе.
Рассмотрим преимущество работы с набором Use Case для людей, выполняющих разные роли в проекте.
Use Case для руководителя проекта
Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.
В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе Use Case гораздо прозрачнее для заказчика. Во-первых, каждый Use Case несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного Use Case в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.
То, что набор Use Case состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого Use Case, сильно упростит выставление приоритетов между ними.
Use Case для тестировщика
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев — test case, — так как они описывают в каком контексте должно производиться каждое действие пользователя. Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.
Use Case для аналитика и менеджера продукта
Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:
В процессе проектирования взаимодействия с системой в виде Use Case и согласования их с заказчиком, аналитик и руководитель проекта узнают много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику Use Case и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других Use Case формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде Use Case, формируются требования к производительности системы.
Так как Use Case полностью покрывают набор таких функциональных требований, и в то же время согласуются с бизнес-целями заказчика, они позволяют проследить связь от бизнес-целей заказчика до отдельной функции и связанных нефункциональных требований, т.е. обеспечить трассировку.
Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.
Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными Use Case: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде Use Case.
То же касается бухгалтерских программ, систем поддержки принятия решения, профессиональных систем для проектирования и дизайна. Use Case важны для них, но не покроют и пятой части требований к функциональности.
Если эта техника вас заинтересовала, ознакомьтесь с материалами от классиков Use Case: