×Закрыть

Как и зачем писать Use Cases

Image via Shutterstock.

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

  • Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
  • Текст проще и быстрее отредактировать, чем диаграммы и текст.

Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс :-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Действующие лица Администратор, Система
Цель Изменить статус учетной записи пользователя на «активный».
Предусловие Учетная запись пользователя не активна.

Успешный сценарий:

  1. Администратор выбирает пользователя и активирует «Разблокировать».
  2. Система переключает учетную запись пользователя в статус «активный», и посылает сообщение (тут можно сослаться на текст сообщения из списка сообщений, см. примечание ниже) пользователю на email (если «User Account → email» не пусто).
Результат Учетная запись пользователя была переведена в статус «активный».


Пример 2. Авторизация пользователя:

Действующие лица Пользователь, Система
Цели Пользователь: авторизоваться в системе и начать работать;
Система: идентифицировать пользователя и его права.

Успешный сценарий:

  1. Пользователь запускает систему. Система открывает сессию пользователя, предлагает ввести логин и пароль.
  2. Пользователь вводит логин и пароль.
  3. Система проверяет логин и пароль.
  4. Система создает запись в истории авторизаций (IP адрес пользователя, логин, дата, рабочая станция).
  5. Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).
Результат Пользователь успешно авторизирован и может работать с системой.
Расширения:
Нет доступа к БД.
Система выдает сообщение (ссылка на сообщение).
Результат: пользователь не может войти.
В настройках безопасности для данного IP адреса существует запрет на вход в систему.
Результат: форма логина не предоставляется, система выдает сообщение пользователю (ссылка на сообщение).
Пользователь выбирает: «Напомнить пароль».
Вызывается сценарий «Напомнить пароль».
Пользователь с введенными логином и паролем не найден.
Результат: отказ в авторизации.
Система выдает сообщение (ссылка на сообщение).
Переход на шаг 2.
Количество неудачных попыток авторизоваться достигло максимального, установленного в настройках.
Результат: пользователь не может войти.
Выдается сообщение: (ссылка на сообщение).
Вход с IP адреса Пользователя заблокирован на время, установленное в настройках.

Важные моменты

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

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

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

— Список сообщений, которые система выдает пользователю, стандартные тексты электронных писем и т.п. удобно расположить в едином месте в документе, и ссылаться на нужный пункт из разных юзкейсов, т.к. сообщения в сценариях часто дублируются.

— Перечитайте документ со сценариями, перед тем, как отдавать его разработчикам или заказчикам. Лучше даже несколько раз. Всегда находятся моменты, которые можно описать лаконичнее, или выявляются какие-то несоответствия. Или случайные «копипасты». Уважайте время и головы других людей.

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.


Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

LinkedIn

44 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Елена, а как заставить команду пользоваться use cases?

Не нравится мне слово «заставить». А чем вы сейчас пользуетесь? Эффективно ли? Какие возникают трудности? Пробовали ли использовать юзкейсы?

Ммм. Прецеденты использования. Люблю их. Только табличный формат несколько формальщиной отдает.

Спасибо за статью. Всегда полезно посмотреть, как люди решают похожие задачи на других проектах. У меня есть небольшое замечание, юз-кейсы в виду диаграмм ВСЕГДА лучше воспринимаются. Потому что большая часть людей на планете — визуалы, а картинки с минимумом текста воспринимаются и ложаться легче, чем слова. Читать сложные тексты никто не любит :)

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

«Ви не любите котів? Та ви просто не вмієте їх готувати!» © Альф

Для ентерпрайз рішень юзкейси взагалі незамінна річ. Особливо якщо компанія вже має усталені бізнес процеси. А якщо вони ще й описані внутрішніми процедурами та/або робочими інструкціями, то ви маєте вже половину готової документації.
Лінкування юзкейсів від мети замовника до задачі програміста вирішується різним рівнем абстракції юзкейсів та їх ієрархічною структурою. Той же Коберн, якого вже кілька разів згадували тут, описує такий підхід.

Якщо є проект, який якісно задокументований юзкейсами, то переробляти його просто тому що вони не подобаються — безглуздо.
Але якщо починати новий — то треба обирати той підхід, який буде більш ефективним в конкретному випадку (замовник/проект/розробник і тд). І юзкейси тут ніяк не є незамінними.

А у нас как то не прижились, аналитик наш писал их, а девелоперы часто забивали и делали как понимали, ибо было очень много юз кейсов которые по сути описывали одну и ту же вещь.

Может это и проблема, должна ли быть абстракция в них, а если да то насколько сильная?

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

А все хорошо получается без юзкейсов? Может у вас проект такой просто, где они не очень подходят... В моем последнем проекте за пол года было написано аж 2 юзкейса, и то потому, что разработчики попросили формализовано описать нетривиальную логику. Но требования ко всем задачам были задокументированны, просто очень high level.

Мы сейчас вообще пришли к тому что девелоперы создают себе на все тикеты сами, нам ничего, а вот КуА не очень счастлив.

Так?

Ага, ибо чаще наблюдается следующее: -Мы тут чего-то наваяли, потести по быстрому, а да доки нет, только код. -А хотели то что? -Ну типа того, что получилось, там разберешься.
А вообще QA должен быть чуть не главный привыпуске некоей фичи в продакшен. А как ему понять вы сделали то, что нужно заказчику или нет?
Вообще я всегда был счастлив, если есть QA? Который может проверить то, что я сделал и знает что именно должно быть. Но, положа руку на сердце скажу, что такие QA единичны, таких исчезающе мало.

Не, мы пишем описание к тикету, но как известно девелоперы не всегда ясно излагают свои мысли, и описание бывает порой слишком низоуровневое. Лично мне не очень нравится такая практика, но наш менеджер считает что БА не надо. Потому маемо шо маемо

Довольно часто сталкиваюсь с таким(неясным излаганием мысли). Надо как то устроить опрос на DOU — используете ли вы в разработке подход TDD?

Было уже. Большая часть не использует.
Вот только TDD к обсуждаемой теме отношение имеет постольку-поскольку.

Тдд здесь не причем, хоть мы его и используем

Не буду с Вами спорить о роли Use Cases в создании верхнеуровневых тестов для TDD, а вот пообщаться с человеком использующим в работе TDD очень бы хотелось. Книги это хорошо, но практика обычно совсем другое

А что практика.
Понял, что нужно написать и знаешь, что проверить, пишешь тест, не знаешь пишешь код, по мере написания кода или добавляешь тесты или расширяешь имеющиеся. Лично я без юнит-тестов почти ничего не пишу, ибо без теста хрен поймешь работает-ли так, как ожидаешь или нет. Тоже и с фиксом багов. Код есть уже, пишешь юнит-тест и правишь код, чтобы этот отработал и остальные не попадали, возможно изменяешь другие тесты, если необходимо. Что тут еще обсуждать.
Только к тестированию TDD отношения не имеет, это часть процесса написания кода.

Пишу стори, ничем не хуже. То, что описано в статье сильно напоминает тест-кейсы. Сильно.
Для определенных задач можно использовать BPMN — описывать бизнес требования или более глубокий уровень процесса. Но со всеми интеграционными и техническими моментами так не намоделишь... А еще пока напилишь моки... Неее, вот так, таблички рисовать для сценариев времени не хватит. Лучше сторями покрывать текстовую часть.

От проекта зависит. Конечно, аналитик не обязан в каждом проекте использовать весь известный инструментарий:) но базовые вещи знать обязан, я считаю :)

Хотелось бы видеть, может быть даже в виде отдельной статьи, сравнение use cases и user stories.
Последние используются ничуть не реже, и многие их путают. Особенно в текстовом виде :) .

Коберн А — Современные методы описания функциональных требований к системам.

Материал для знакомства с темой. Некоторые вещи требуют вдумчивого перепрочтения. С наработкой практики в основном становится все понятно.

****
Пример 2 — Я так не делаю ))
1. Либо в предусловие, либо разбивать на два пункта.
3,4,5. — один пункт.
Хотя это вопрос стилистики.

Коберн — супер, я в статье на эту книгу тоже ссылаюсь :)

Кстати, вопрос автору. Сам практикую написание сценариев использования. Сейчас пишу их относительно формализованным языком, но есть планы писать их сразу не Геркине, чтобы по этим сценариям можно было делать автотесты. Был ли у Вас такой опыт?

Не было такого опыта

Елена, а можно пару слов о том где вы храните юз кейсы и как вы их трейсите к остальным требованиям/тест кейсам?

Если честно, обычно зависит от организации процесса в компании/проекте. Где-то самописная тулза (система) была, где-то — word документы по каждому модулю системы, между ними — ссылки.
О, ещё redmine использовали. Там тоже привязка к проекту, задачам, ссылки, все такое.

Дякую за статтю!

Хотів би трохи від себе додати.
Use Case діаграма (та сама з чоловічками та овалами) найкраще використовується для опису системи взагалі на високому рівні. Тобто вона чудово ілюструє загальний функціонал і ЩО система може робити, які актори використовують яку частину функціоналу та як юзкейси між собою пов’язані. Також вона гарно описує межі (кордони) проекту.
В той час як конкретний юзкейс (овал з use case діаграми) краще описувати текстом або діаграмою активності. Тут вже описується ЯК САМЕ система та зовнішній актор досягають потрібної мети.
Важливим є грамотне написання передумов та результату юзкейсів. Вони мають «склеювати» юзкейси в суцільну картину системи. Як пазли, що мають ідеально прилягати один до одного, щоб картинка була красива.
Ще звернув би увагу на важливість коректного опису альтернативних потоків (в статті — Расширения). Тут часта помилка — ухід потоку в нікуди. В ідеалі альтернативний потік має або запускати інший юзкейс, або повертати до основного (успішного) сценарію або завершувати поточний юзкейс. По суті юзкейс має бути написаний як чіткий алгоритм для комп’ютера.
І я би всі технічні моменти виносив би з юзкейсів в додатки. Так, у випадку якихось змін у дизайні чи технічних вимогах сам юзкейс не потребував би правок, оскільки принцип взаємодії системи з актором не змінюється.

Дякую

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

— Тестировщику. Почти готовый тест-кейс :-)

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

Ага, ибо чаще наблюдается следующее: -Мы тут чего-то наваяли, потести по быстрому, а да доки нет, только код. -А хотели то что? -Ну типа того, что получилось, там разберешься.

true story bro :) И догадывайся потом expected condition, чтоб понять — это баг или фича)))

Ух ты, редкость тут, грамотная статья. Приятно читать. Вот бы все ВА (по роли) так делали, а не в стиле «сделай то, не знаю что, сходи туда, не знаю куда».
Повезло людям с тобой работать.
Отправил в закладки.

Спасибо за добрые слова :)

В расширения ещё частенько добавляю небольшие ветви-предусловия и дальнейший ход событий — получается информативно. Естественно простыню условий совать не стоит и в таком случае нужно бить по юзкейсам мельче.
По поводу диаграм — нужно помнить, что одна диаграмма может показывать то, что можно описать на листе А4

Да, большие диаграммы часто запутывают.

ух, ты, интересный шаблон-сет правил, спасибо.

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

использовать однозначные формулировки

А чем Геркин не подходит? Дано, Когда, Тогда

не говорю, шо не подходит.
просто либо у вас есть шаблон(и тогда разница со схемами — только во внешности, а не в структуре). либо как повезет.

Спасибо!
Да, есть такое:)

Подписаться на комментарии