Пример сценарий использования: Диаграмма сценариев использования в процессе разработки ПО

Диаграмма сценариев использования в процессе разработки ПО

Уже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.

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

Во-первых, что такое сценарий использования? Сценарий использования – это связный рассказ о поведении системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Кто-то или что-то может быть пользователем системы, это может быть какая-то информационная система или устройство. И этот кто-то или что-то называется Действующим лицом (ДЛ). А сам сценарий использования представляет собой последовательность шагов, которые описывают действия ДЛ и реакцию системы на них.

Например, сценарий регистрации на каком-нибудь сайте может выглядеть вот так:

1. Пользователь дает команду на регистрацию.
2. Сайт отображает форму регистрации.
3. Пользователь заполняет поля формы и подтверждает регистрацию.
4. Сайт подтверждает правильность заполнения формы.
5. Сайт отправляет на указанный e-mail письмо с запросом для подтверждения регистрации.
6. Пользователь подтверждает регистрацию.
7. Сайт регистрирует пользователя.

Как можно заметить, действия пользователя и системы чередуются между собой, они будто играют в мяч, делая пасы друг другу. Подробнее про СИ можно прочитать здесь: ru.wikipedia.org/wiki/Сценарий_использования

Но въедливый читатель может справедливо возразить, что в разработку такой сценарий отдавать нельзя. И он будет прав! Мы ведь сейчас посмотрели на систему с высоты, наверно, 5-этажного дома, когда общее поведение уже понятно, но детальных требований ещё нет. Поэтому сценарий использования должен быть, как минимум, дополнен альтернативными потоками выполнения (то что представлено выше, называется основной поток и описывает действия системы, когда все идет как надо). Альтернативные потоки – это потоки, в которых описывается реакция системы на ошибочные действия пользователя или исключительные ситуации, либо же случаи альтернативных действий пользователя, если он захотел, например, зарегистрироваться с помощью аккаунта в социальной сети. Также документ со сценарием использования можно дополнить деталями пользовательского интерфейса, правилами валидации данных, различными бизнес-правилами и сообщениями об ошибках. А вот нефункциональные требования обычно описываются в отдельном документе, так как они обычно применимы ко всей системе целиком, а не к конкретным СИ.

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

Для разработчиков и тестировщиков она, на первый взгляд, несет ещё меньше пользы, чем сами сценарии использования. Но ведь и предназначена она для другого!

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

Я обычно использую диаграмму СИ для решения следующих задач:

• Оценка трудоемкости проекта;
• Планирование графика работ;
• Выявление пропущенных требований;
• «Оглавление» для проектных документов.

Давайте посмотрим, как СИ помогают решать эти задачи.

Оценка трудоемкости проекта

Как показывает опыт и практика, оценка получается тем точнее, чем детальнее выделен список предстоящих работ. Ведь действительно, задачу «написать статью» оценить гораздо сложнее, чем задачу «найти 5 картинок для иллюстраций». Так вот, сценарии использования являются первой итерацией разбивки системы на отдельные элементы. Более того, эти элементы обладают хорошей связностью (в данном случае – функциональная) и могут быть оценены отдельно друг от друга. Если этого недостаточно, то уже каждый СИ можно декомпозировать на основной/альтернативные потоки или даже задачи, которые необходимо выполнить программисту для реализации отдельного сценария.

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

Даже существует специальный способ оценки, основанный на СИ – Use Case Points. В этом случае выделяются действующие лица и сценарии, у них по определенным правилам определяется сложность, задаются некоторые поправочные коэффициенты, учитывающие профессионализм команды и сложность предметной области, и на выходе появляется готовая оценка. То есть, к оценке, в идеале, даже не надо привлекать разработчиков и тестировщиков.

Планирование графика работ

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

Выявление пропущенных требований

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

Также бывает и другая ситуация, когда в описании системы присутствуют требования о том, что в процессе работы пользователи должны создавать какие-то сущности. В подавляющем большинстве случаев, к таким сущностям применимы все CRUD (Create, Read (или также встречается расшифровка Retrieve), Update, Delete) операции, про которые тоже иногда забывают. В чем же здесь польза модели СИ? А как раз в графическом представлении требований. Когда глаз охватывает всю картинку, то гораздо проще заметить недостающие элементы, чем когда требования сформулированы обычным текстом.

«Оглавление» для проектных документов

Очень часто заказчик просит вместе с системой передавать комплект проектной документации. У себя в компании мы пишем проектную документацию в виде сценариев использования. Если же заказчик требует документы по ГОСТу, то все равно сперва пишутся сценарии использования, а затем уже на их основе формируются ГОСТовские документы.

У нас используется, как минимум, два подхода к документированию: когда каждый СИ описывается в отдельном документе, и когда в одном документе описываются сразу несколько СИ, относящихся к одной подсистеме. Часто тот или иной подход определяется, исходя из принятого процесса или привычек заказчика.

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

Заключение

После этих пояснений, надеюсь, стала понятна польза, которую дает использование диаграммы СИ. Несмотря на её простоту и даже избыточность непосредственно для разработчиков, она дает довольно хороший импульс к старту любого проекта. И рассматривать её надо прежде всего в этом ключе. Алистер Коберн в своей книге «Современные методы описания функциональных требований к системам» тоже пишет о том, что не видит смысла в рисовании палочек и овалов, так как они не приближают читателя к пониманию того, как система должна работать. Но и он, как раз, говорит уже про этап детальной проработки требований, который следует после определения набора сценариев.

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

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

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

Что такое Use Case

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое Use Case

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Советы для написания хороших сценариев использования « Заметки консультанта

Как использовать сценарии использования для точной оценки трудоемкости работы

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

Попробуйте открутить назад все Ваши проекты и оцените реальное опоздание по ним.

Может оказаться, что задержки достигают просто гигантских значений.

Автор статьи видел проекты с задержкой сроков в 400% и 700%!

Бытует мнение, что разрабатывать программы без опоздания невозможно в принципе.

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

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

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

Интересно, что сценарии (варианты) использования позволяют довольно точно оценить трудоемкость работ.

Практика показала, что можно достигнуть 20% точности (=%ошибки) при оценке. А ведь опоздание 20% это совсем не 700%, верно?

Как это сделать?

С чего начать

Суть в альтернативах!

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

Как же посчитать трудоёмкость с помощью сценариев?

Представьте, что Вам нужно запрограммировать вот такое небольшое окошко:

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

Вкратце распишем сценарий:

Сценарий использования «Найти документ»

Успешный результат: выбранный документ прописан в свойство какого-то объекта

Основной успешный сценарий

1.Пользователь вводит поисковую фразу.
2.Система выводит список подходящих документов, в названии которых есть искомая фраза. Документы представлены своим названием. Список упорядочен по алфавиту.
3.Пользователь выбирает один из документов.
4.Система прописывает выбранный документ в нужный объект.

Альтернативы

2а.Пользователь хочет найти документы по состоянию на указанную дату

1.Система выводит список подходящих документов, ограниченных по дате создания. Исполнение продолжается согласно п.3.

2б.Пользователь хочет найти документ в архиве

1. 1.Система выводит список подходящих действующих и архивных документов. Исполнение продолжается согласно п.3.

3а.Не найдено ни одного документа

1.Система выводит сообщение: «Не найдено ни одного документа». Исполнение продолжается согласно п.1.

Обратите внимание, что сценарий разделен на две части: «Основной успешный сценарий» и «Альтернативы».

А теперь подумайте, как обычно происходит оценка трудоёмкости? Думаю, Вы согласитесь, что работу обычно оценивают только по успешному сценарию (как самому очевидному, приходящему на ум в первую очередь), а про альтернативы не думают вообще.

В этом и заключается суть проблемы – именно в альтернативах часто зарыта основная трудоёмкость.

Пойдём дальше.

В примере италиком отмечены операции, которые программисту нужно запрограммировать.

В альтернативах можно увидеть две операции, которых нет в основном сценарии. Давайте подумаем, что представляют из себя эти операции? По сути это обычные SQL-запросы к базе, но!

В них фигурируют дополнительные параметры, которых нет в основном запросе. И вполне может получиться так, что отладка запросов с этими параметрами займёт в 10 раз больше времени, чем основной запрос. И именно так и бывает, верно?

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

Как оценить трудоёмкость

Давайте сведём всю информацию по сценарию в одну таблицу и попробуем посчитать сколько времени у нас займёт реализация:

Создание инфраструктуры классов – 1ч

Формирование окна – 2ч

Вывод списка документов по ключевой фразе – 1ч

Вывод списка документов с учётом даты создания – 1ч

Вывод списка документов с учётом архивных – 1 ч

Прописывание выбранного документа в свойства объекта – 1ч

Тестирование 4 * 0,5ч = 2ч
Итого: 9 ч

Как видите, в оценке учтены дополнительные 2ч на реализацию альтернатив и еще 1ч на их тестирование. А если бы оценка проводилась только по успешному сценарию, то этих 3-х часов мы бы не досчитались.

А это почти 50% времени (6ч на основной сценарий и 3ч на альтернативы)!

Итоги

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

P.S.А как быть, если сценариев ещё нет?

Если на момент оценки Вы ещё не расписали сценарии, попробуйте хотя бы вкратце набросать основные альтернативы. Это уже хорошо улучшит оценку.

P.P.S. Где еще зарыта свинья

Бывает так, что шаги сценария недостаточно мелкие. Представьте, например, что в система должна опубликовать какие-либо данные.

Как Вы понимаете, под «публикацией» может быть скрыт целый ворох действий, которые трудно определить сразу.

Такие ситуации очень легко определяются, когда в оценке трудоемкости ставится время > 3ч. Это однозначно указывает на то, что человек, дающий оценку, не знает, что скрыто внутри. И там 100% сидит БОЛЬШАЯ засада! Проверено многократно.

В таком случае обязательно продумывайте и прописывайте, что скрыто внутри, иначе можно очень сильно попасть на сроки.

пример применения пользовательских сценариев от стартапа Trucker Path — Офтоп на vc.ru

Николай Ковалюнас, дизайнер продукта в компании-разработчике приложения для дальнобойщиков Trucker Path, написал для vc.ru колонку о том, как применять пользовательские сценарии в рабочем процессе.

Допустим, вы продуктовый дизайнер и к вам приходит задача: нужно спроектировать импорт перевозчиков в приложение посредством CSV-файла. Задача снабжена более или менее вменяемым описанием и даже есть структура файла с примером. В общем, ничто не мешает приступить к работе. Первое, что приходит в голову, — открыть тетрадь для скетчирования, Sketch, или Photoshop, или, может, редактор кода, и начать накидывать экраны. Но нет. Здесь необходим Use Case. Что это? Давайте разберемся.

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

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

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

Use Case можно, хотя и не обязательно, дополнять визуальной составляющей. Как показывает опыт, простая workflow-диаграмма делает Use Case более простым для восприятия и получения обратной связи.

Из чего состоит Use Case

В зависимости от сложности и детализированности Use Case может содержать следующие элементы:

• Название (Name) — название Use Case: короткое, понятное, отражающее суть.
• Краткое описание (Brief Description) — текст, описывающий данный Use Case.
• Участники (Actors) — список участников взаимодействия. Часто состоит из одного человека.
• Предусловия (Preconditions) — условия, которые должны быть выполнены перед началом реализации данного Use Case.
• Триггер (Trigger) — событие или условие, которое заставляет пользователя приступить к выполнению Use Case.
• Базовый сценарий (Basic Flow) — последовательность действий, которые выполняет участник для успешного достижения цели. Также может называться Normal Flow, Primary Scenario и Happy Path.
• Альтернативные сценарии (Alternative Flows) — описание альтернативных сценариев выполнения Use Case. Важное условие альтернативных сценариев — участник в итоге успешно достигает цели.
• Исключительные сценарии (Exceptional Flows) — все, что может привести участника к невыполнению Use Case.
• Постусловие (Post Conditions) — результат после выполнения Use Case.

К счастью, на практике не всегда нужно использовать все пункты. Всё зависит от того, для чего и кого вы его пишете.

Итак, возвращаемся к нашей задаче. Открываем обычный текстовый редактор. Очень неплох iA Writer, но сгодится любой. Я, например, использую Google Docs — им удобно делиться с коллегами.

Пишем Use Case

На самом деле, пример взят из реального опыта. В Trucker Path у меня была задача на импорт списка перевозчиков посредством CSV. Приступим.

выжимаем практический опыт / Блог компании QIWI / Хабр

У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.

Я буду использовать разговорное «юзкейс» вместо неуклюжей кальки «прецедент использования». Надеюсь, уважаемая публика меня за это простит.

Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.

Мои отношения с юзкейсами начались в 1996 году и складывались поначалу не очень хорошо. Я тогда работал на предприятии связи, и у меня был халявный интернет. По дайлапу, через телефонный модем на 9600 бод я бороздил просторы тогдашнего интернета в поисках методики, которая помогла бы мне описать функциональность комплексной информационной системы предприятия.

Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».

Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.

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

В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.

Что такое юзкейс?

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

А вот определение из глоссария UML (перевод мой).

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

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

Юзкейс — это текст,

описывающий сценарий

взаимодействия с системой,

приводящий к значимому результату.

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

Юзкейс — это текст,

описывающий сценарий (возможно, не один)

взаимодействия (кого или чего?) с системой,

приводящий (возможно, не приводящий)

к значимому (для кого?) результату.

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

• Результат — пишется в заголовке юзкейса
• Что является рассматриваемой системой
• Участники взаимодействия (действующие лица: люди, внешние системы, кто основной участник?)
• Последовательность действий
• На каждом шаге: Кто? Что делает?
• Что будет если что-то пойдет не так?

Для примера приведу юзкейс из реального проекта. В 2012 году QIWI Кошелёк стал мультивалютным, и курсы конвертации сначала устанавливались на базе курсов ЦБ. Но потом их решили устанавливать по рынку, и проект был посвящен этому переходу. Юзкейс довольно простой. Трейдер выставляет курсы в АБС — автоматизированной банковской системе. Директор казначейства или его заместитель должны их на всякий случай подтвердить. Вдруг трейдер ошибется: рука дрогнет, не ту цифру нажмет. Цена ошибки велика. Если что-то не так, директор заявку отклоняет, и трейдер делает работу заново.

Установка курсов для пользователей QIWI Кошелька

Основной сценарий

1. Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки).
2. Директор казначейства получает сообщение по электронной почте о необходимости подтвердить заявку.
3. Директор просматривает заявку и утверждает ее (см. форму утверждения).
4. АБС сохраняет курсы для использования в QIWI Кошельке начиная с момента, указанного в заявке.
5. Заинтересованные лица получают по электронной почте сообщение, в котором указаны новые курсы и дата/время их вступления в силу.

Отклонение заявки

1. На шаге 3 директор отклоняет заявку.
2. Трейдер получает сообщение по электронной почте об отклонении заявки.

Что не нужно в юзкейсе

Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:

• Контекст использования
• Область действия
• Уровень
• Основное действующее лицо
• Участники и интересы
• Предусловие
• Минимальные гарантии
• Триггер
• Расширения
• Список изменений в технологии и данных

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

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

Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.

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

Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.

Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.

Условные конструкции

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

Я не всегда следую этому правилу. Признаюсь, я подправил свой юзкейс перед тем, как выложить его сюда в качестве примера. А в оригинале он выглядел вот так. Отличия начинаются с п.3.

Сценарий установки курсов

1. Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки).
2. Директор казначейства получает сообщение по электронной почте о необходимости подтвердить заявку.
3. Директор просматривает заявку и утверждает либо отклоняет ее (см. форму утверждения).
4. Если заявка отклонена, то трейдер получает сообщение по электронной почте об отклонении заявки.
5. Если заявка утверждена, то:
   
   a. Курсы сохраняются для использования начиная с момента, указанного в заявке.
   
   b. Заинтересованные лица получают по электронной почте сообщение, в котором указаны новые курсы и дата/время их вступления в силу.

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

Бизнес-правила

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

Вот какие бизнес-правила были приложены к юзкейсу из примера.

• Время вступления курсов в силу может быть только 12:00:00, 16:00:00, 20:00:00.
• Трейдеру разрешается отправить заявку на утверждение не позднее, чем за 45 минут до момента вступления курсов в силу.
• Трейдер может удалить заявку, если она еще не направлена на утверждение или отклонена.
• Трейдер может отредактировать не отправленную или отклоненную заявку и повторно отправить ее на утверждение.
• Трейдер может создать и отправить на утверждение одновременно несколько заявок с разными датой и временем вступления в силу.
• Сохранение другой заявки с такой же датой и временем, как у уже существующей, невозможно.
• Директор может утвердить заявку не позднее чем за 40 минут до момента вступления курсов в силу.
• Директор может удалить утвержденную заявку, но не позднее чем 60 минут до момента вступления курсов в силу. Новые курсы, указанные в заявке, в случае ее удаления не вступают в силу.
• При удалении заявки отправляется сообщение заинтересованным лицам об отмене установки новых курсов.
• Необходимо сохранять в журнале информацию о следующих действиях пользователей: отправка заявки на утверждение, утверждение заявки, удаление заявки. Для каждого из них должны сохраняться: дата/время выполнения действия, пользователь, данные заявки: исходные курсы, дата и время вступления в силу.
• Если процессинг QIWI Кошелька не смог загрузить курсы в нужное время по расписанию, то, помимо оповещения специалистов эксплуатации, должно также отправляться сообщение по списку рассылки заинтересованных лиц.

Если присмотреться, то почти каждое из правил может дать начало еще одному альтернативному сценарию, а то и целому юзкейсу. Например: «Директор не успел утвердить заявку». Но если бы я расписал все альтернативы, как положено по Коберну, юзкейс стал бы хуже. В нем было бы труднее разобраться и выделить суть.

Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.

Когда систем несколько

Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.

Этот подход можно назвать «одноклеточным». Мы сосредотачиваемся на том, что происходит в клеточной мембране, и игнорируем до поры до времени всё остальное.

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

У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.

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

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

Сказуемое без подлежащего

Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.

Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров».

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

Неуспешные сценарии

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

Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.

Если в проекте описаны только основные сценарии юзкейсов, то велик риск, что забыли что-то важное.

Модель предметной области

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

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

Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:

Поддерживаемые валюты

Имеется список поддерживаемых валют. Этот список делится на две части:

1. Валюты кошельков — в которых клиенты могут открывать кошельки.
2. Остальные («валюты платежей») — в них клиенты не могут открывать кошельки, но в этих валютах могут указываться суммы платежей.

Список поддерживаемых валют может со временем расширяться, валюты платежей становиться валютами кошельков.

Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».

(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).

Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.

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

Перечень юзкейсов

Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.

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

1. Задать прогноз оборотов
2. Создать заявки на конвертацию
3. Отправить заявки в банк
4. Выполнить заявки на конвертацию
5. Учесть выполненные заявки

Тот же самый перечень, но в виде диаграммы юзкейсов.

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

Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.

Заключение

Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN.

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

Примеры диаграмм вариантов использования UML

Здесь мы приводим несколько примеров UML
диаграммы вариантов использования.

Примеры бизнес-сценариев использования диаграмм

Бизнес-модель регистрации и досмотра в аэропорту

Цель :
Пример бизнес-схемы использования для регистрации в аэропорту и проверки безопасности.

Сводка :
Примеры использования для бизнеса: индивидуальная регистрация, групповая регистрация (для групп туристов),
Проверка безопасности и т. Д.- представление бизнес-функций или процессов
проходящие в аэропорту и обслуживающие потребности пассажиров.

Бизнес-модель ресторана

Цель :
Два альтернативных примера бизнес-схемы использования для ресторана —
внешний и внутренний вид ресторана.

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

Примеры использования системы диаграммы

Автомат по продаже билетов

Цель :
Покажите, что автомат по продаже билетов позволяет пассажирам покупать билеты.

Сводка :
Конечная цель пассажира пригородных поездов по отношению к нашему автомату по продаже билетов — купить билет.
У нас есть единственный вариант использования Билета на покупку, поскольку этот торговый автомат не предоставляет никаких других услуг.Автомат по продаже билетов
это предмет
примерной диаграммы вариантов использования. Пригородный и банк
наши актеры,
оба участвуют в Билете покупки
вариант использования.

Примеры схем использования UML для банкоматов

Цель :
Опишите варианты использования банкомата (ATM) или банкомата (ABM).
предоставляет клиентам банка.

Сводка :
Клиент использует банкомат для проверки остатка на своих банковских счетах, внесения средств,
снимать наличные и / или переводить средства (варианты использования).Специалист по обслуживанию банкоматов обеспечивает обслуживание и ремонт банкомата.

POS-терминал

Цель :
Пример сценариев использования POS-терминала или кассы в супермаркете.

Сводка :
Вариант использования Checkout включает в себя клиентов, клерков и сотрудников службы кредитных платежей и включает
сканирование товаров, расчет суммы и налогов, а также варианты использования оплаты.Это пример большого и сложного варианта использования, разделенного на несколько более мелких вариантов использования.

Электронный каталог общего доступа онлайн (OPAC)

Цель :
Перечислите варианты использования верхнего уровня для общедоступного онлайн-каталога электронной библиотеки.

Сводка :
Посетители библиотеки могут искать в каталоге библиотеки в Интернете различные ресурсы —
книги, периодические издания, аудио- и визуальные материалы или другие предметы, находящиеся под контролем библиотеки.Посетители могут резервировать или продлевать товар, оставлять отзывы и управлять своей учетной записью.

Диаграммы вариантов использования в интернет-магазинах

Цель :
Предоставьте варианты использования верхнего уровня для веб-клиентов, совершающих покупки в Интернете.

Сводка :
Актер веб-клиента
использует некоторые веб-сайты для покупок в Интернете.
Варианты использования верхнего уровня
Просмотреть товары , Сделать покупку и Клиентский регистр .

Система обработки кредитных карт

Цель :
Определите основные варианты использования системы обработки кредитных карт
( платежный шлюз кредитной картой ).

Сводка :
Продавец отправляет запрос транзакции кредитной карты на платежный шлюз кредитной карты.
от имени клиента. Банк, выпустивший кредитную карту клиента, является субъектом, который может утвердить
или отклонить транзакцию.Если транзакция будет одобрена, средства будут переведены на банковский счет продавца.

Администрирование сайта

Цель :
Пример диаграмм вариантов использования UML для управления или администрирования веб-сайта.

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

Управление больницей

Цель: Опишите основные услуги (функции), предоставляемые приемной больницы.

Сводка :
В этом примере диаграммы вариантов использования UML показаны исполнители и варианты использования для приемной больницы.
Приемная в больнице Подсистема или модуль поддерживает некоторые из множества рабочих обязанностей
администратора больницы. Регистратор составляет график приема и поступления пациента в больницу,
собирает информацию от пациента по телефону и / или по прибытии пациента в больницу.

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

Пример схемы использования UML для создания отчетов о радиологической диагностике

Назначение:
Пример схемы использования UML для создания отчетов о радиологической диагностике
для простого изображения и числового отчета (SINR) IHE Radiology Integration Profile.

Сводка :
На начальном этапе диагностического отчета читающий врач
записывает диагноз путем создания черновика объекта структурированного отчета DICOM (SR).Субъект Report Creator передает этот объект DICOM SR диспетчеру отчетов.
Субъект доступа к репозиторию внешних отчетов — это шлюз для получения
отчеты других подразделений предприятия, такие как Лаборатория и Патология,
из отдела визуализации.

Защита программного обеспечения и лицензирование

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

Сводка :
Sentinel License Development Kit (Sentinel LDK) — это система управления цифровыми правами на программное обеспечение (DRM)
решение SafeNet Inc., обеспечивающее надежную защиту от копирования, защиту интеллектуальной собственности (IP),
и безопасное и гибкое лицензирование.
Приложение Sentinel EMS обрабатывает три основных рабочих процесса — планирование лицензий,
обработка и изготовление заказов, а также активация пробного ПО.

.

Use Case and Use Case Testing Complete Tutorial

Для начала давайте разберемся с «Что такое вариант использования?» , а позже мы обсудим «Что такое тестирование вариантов использования?» .

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

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

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

Вариант использования

Вариант использования играет важную роль на отдельных этапах жизненного цикла разработки программного обеспечения. Вариант использования зависит от «действий пользователя» и «реакции системы» на действия пользователя.

Это документация «Действий», выполняемых Актером / Пользователем, и соответствующего «Поведения» Системы по отношению к «Действиям» Пользователя. Варианты использования могут привести или не привести к достижению «Участником / пользователем» цели по взаимодействию с системой.

В случае использования мы опишем «Как система будет реагировать на данный сценарий?» .Он «ориентирован на пользователя», а не «на систему».

Он «ориентирован на пользователя»: Мы укажем «какие действия выполняет пользователь?» И «Что участники видят в системе?».

Он не «ориентирован на систему»: Мы не будем указывать «Какие входные данные предоставляются системе?» И «Какие выходные данные производятся системой?».

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

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

После реализации кейса документ тестируется, и соответственно проверяется поведение Системы. В случае, если заглавная буква «А» означает «Актер», буква «S» означает «Система».

Кто использует документы «Варианты использования»?

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

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

Использование документов:

• Разработчики используют документы для реализации кода и его проектирования.
• Тестировщики используют их для создания тестовых примеров.
• Заинтересованные стороны бизнеса используют этот документ для понимания требований к программному обеспечению.

Типы вариантов использования

Есть 2 типа.

Это:

# 1) Примеры использования «Солнечный день»

Это основные случаи, которые наиболее вероятны, когда все идет хорошо. Этим случаям уделяется более высокий приоритет, чем другим случаям. После того, как мы завершили кейсы, мы передаем их на рассмотрение команде проекта и гарантируем, что мы рассмотрели все необходимые кейсы.

# 2) Дождливый день Варианты использования

Их можно определить как список крайних случаев.Приоритет таких случаев будет после «Sunny Use Cases». Мы можем обратиться за помощью к заинтересованным сторонам и менеджерам по продукции, чтобы определить приоритеты.

Элементы в сценариях использования

Ниже представлены различные элементы:

1) Краткое описание : Краткое описание, объясняющее случай.

2) Участник : Пользователи, которые участвуют в действиях вариантов использования.

3) Предварительное условие : Условия, которые должны быть выполнены до начала рассмотрения дела.

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

5) Альтернативный поток : Помимо обычного рабочего процесса, в системе также может быть «Альтернативный рабочий процесс». Это менее распространенное взаимодействие пользователя с системой.

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

7) Опубликовать Условия : Условия, которые необходимо проверить после завершения рассмотрения дела.

Представление

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

Пример сценария использования:

Здесь я объясню случай «входа» в «Систему управления школой».

На что следует обратить внимание

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

Как написать сценарий использования?

Пункты, изложенные ниже, помогут вам написать следующее:

=> Когда мы пытаемся написать дело, первый вопрос, который должен возникнуть, — это «Какое основное использование для клиента?» Этот вопрос будет заставить вас писать свои кейсы с точки зрения пользователя.

=> У нас должен быть шаблон для них.

=> Он должен быть производительным, простым и прочным. Сильный пример использования может произвести впечатление на аудиторию, даже если у нее есть незначительные ошибки.

=> Надо пронумеровать.

=> Мы должны написать шаг процесса в его порядке.

=> Дайте Сценариям собственное имя, имя должно быть выполнено в соответствии с целью.

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

=> Определите участников системы. Вы можете найти в системе множество актеров.

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

Сначала давайте рассмотрим первых участников. У нас может быть более одного актера с одинаковым поведением.

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

=> Мы должны определить применимое предварительное условие.

Диаграмма вариантов использования

Диаграмма вариантов использования — это графическое представление действий пользователя (ей) в системе. Это действительно отличный инструмент в этом контексте: если диаграмма содержит много участников, то ее очень легко понять.Если это высокоуровневая диаграмма, на ней не будет много деталей. Он показывает сложные идеи в довольно простой форме.

№ рисунка: UC 01

Как показано на рис. № : UC 01 , он представляет собой диаграмму, где прямоугольник представляет «систему», овал представляет собой «вариант использования», стрелка представляет собой «взаимосвязь» а Мужчина представляет «Пользователя / Актера». Он показывает систему / приложение, затем показывает организацию / людей, которые взаимодействуют с ним, и показывает основной поток «Что делает система?»

Рис. №: UC 02

Рис. №: UC 03 — Диаграмма вариантов использования для входа в систему

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

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

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

Действия пользователя

Это действия, которые выполняет пользователь в системе.

Например: Поиск на сайте, добавление элемента в избранное, попытка связаться и т. Д.

Примечание:

• Система — это «все, что вы разрабатываете». Это может быть веб-сайт, приложение или любой другой программный компонент. Обычно он представлен в виде прямоугольника. Он содержит варианты использования.Пользователи размещаются за пределами «прямоугольника».
• Варианты использования обычно представлены овальными формами, определяющими действия внутри них.
• Участники / Пользователи — это люди, которые используют систему. Но иногда это могут быть другие системы, человек или любая другая организация.

Что такое тестирование вариантов использования?

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

Он проверяет, работает ли путь, используемый пользователем, должным образом или нет. Это гарантирует, что пользователь сможет успешно выполнить задачу.

Некоторые факты

• Для определения качества программного обеспечения проводится не тестирование.
• Даже если это тип сквозного тестирования, оно не гарантирует полного охвата пользовательского приложения.
• На основании результата теста, известного из тестирования сценария использования, мы не можем принять решение о развертывании производственной среды.
• Выявит дефекты в интеграционном тестировании.

Пример использования Пример тестирования:

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

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

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

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

Шаг 1: Первым шагом является проверка документов вариантов использования.

Нам необходимо проверить и убедиться, что функциональные требования полны и правильны.

Шаг 2: Нам нужно убедиться, что варианты использования атомарны.

Например: Рассмотрим «Систему управления школой, имеющую множество функций, таких как« Вход »,« Показать сведения об учащемся »,« Показывать оценки »,« Показывать посещаемость »,« Связаться с персоналом »,« Подавать плату »и т. Д. В этом случае мы пытаемся подготовить варианты использования для функции «Вход».

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

Шаг 3: Нам нужно проверить нормальный рабочий процесс в системе.

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

Шаг 4: Убедитесь, что альтернативный рабочий процесс в системе завершен.

Шаг 5: Мы должны убедиться, что каждый шаг в сценарии использования поддается тестированию.

Каждый шаг, описанный в разделе «Тестирование сценария использования», можно проверить.

Например, некоторые транзакции по кредитным картам в системе не могут быть проверены из соображений безопасности.

Шаг 6: После того, как мы восстановим эти кейсы, мы можем написать контрольные примеры.

Мы должны написать тестовые примеры для каждого нормального и альтернативного потока.

Например, , Рассмотрим случай «Показать оценки учащихся» в системе управления школой.

Пример использования Имя: Показать оценки учащихся

Актеры: Студенты, учителя, родители

Предварительное условие:

1) Система должна быть подключена к сети.

2) Актеры должны иметь «Студенческий билет».

Пример использования для «Показать оценки учащихся»:

Соответствующий тестовый пример для «Показать оценки учащихся»:

Обратите внимание, что приведенная здесь таблица тестовых примеров содержит только основную информацию. «Как создать шаблон тестового случая» подробно объясняется ниже.

В таблице отображается «Тестовый набор», соответствующий случаю «Показать оценку учащегося», как показано выше.

Лучший способ написать тестовые примеры — сначала написать тестовые примеры для «Основного сценария», а затем написать их для «Альтернативных шагов».« шагов» в тестовых примерах взяты из документов прецедентов. Самый первый шаг Step в кейсе «Show Student Mark», «Введите имя ученика» станет первым Step в «Test Case».

Пользователь / актер должен иметь возможность войти в него. Это становится ожидаемым результатом .

Мы можем обратиться за помощью к методам проектирования тестов, таким как «анализ граничных значений», «разделение эквивалентности», пока мы готовим тестовые примеры. Техника разработки тестов поможет сократить количество тестовых примеров и тем самым сократить время, необходимое для тестирования.

Как создать шаблон тестового случая?

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

Есть несколько инструментов, доступных на рынке, чтобы помочь в этом контексте. « TestLodge» — один из них, но это не бесплатный инструмент. Нам нужно это купить.

Нам нужен шаблон для документирования тестового случая. Давайте рассмотрим распространенный сценарий «Вход в систему FLIPKART», с которым мы все знакомы.Таблицу Google можно использовать для создания таблицы тестовых примеров и поделиться ею с членами команды. Пока я использую документ Excel.

Вот пример

=> ЗАГРУЗИТЕ этот шаблон таблицы тестовых примеров здесь

Прежде всего, назовите лист тестовых примеров соответствующим именем. Мы пишем тестовые примеры для конкретного модуля в проекте. Итак, нам нужно добавить столбцы «Project Name» и «Project Module » в таблицу тестовых примеров.В документе должно быть указано имя создателя тестовых случаев.

Поэтому добавьте «Создано» и «Дата создания» . Документ должен быть рассмотрен кем-то (руководителем группы, менеджером проекта и т. Д.), Поэтому добавьте «Проверено» и «Дата проверки» .

Следующий столбец — «Тестовый сценарий» , здесь мы предоставили Пример тестового сценария «Подтвердить вход в Facebook» . Добавьте столбцы «Идентификатор тестового сценария» и «Описание тестового сценария» .

Для каждого сценария тестирования мы напишем «Test Cases ». Итак, добавьте столбцы «ID тестового набора» и «Описание тестового набора ». Для каждого сценария тестирования будет «Пост-условие» и «Предварительное условие» . Добавьте столбцы «Постусловие» и «Предварительное условие».

Другой важный столбец — «Test Data» . Он будет содержать данные, которые мы используем для тестирования. Сценарий тестирования должен предполагать ожидаемый результат и фактический результат.Добавьте столбец «Ожидаемый результат» и «Фактический результат». «Статус» показывает результат выполнения тестового сценария. Может быть пройдено / не пройдено.

Тестировщики выполнят тестовые примеры. Нам нужно включить его как «Дата исполнения» и «Дата исполнения» . Мы добавим «Команды», если они есть.

Заключение

Надеюсь, у вас есть четкое представление о вариантах использования и тестировании вариантов использования.

Написание этих кейсов — это итеративный процесс.Вам просто понадобится немного практики и хорошее знание системы, чтобы написать эти кейсы.

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

Есть ли у вас предыдущий опыт использования и тестирования? Не стесняйтесь поделиться с нами в разделе комментариев ниже.

.Диаграмма вариантов использования UML для

: Учебное пособие с ПРИМЕРОМ

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing 9L000
    • 9000 J2000
    • Тестирование базы данных

    9000

    • Назад
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • Центр качества (ALM)
    • Центр качества (ALM)
    • Управление тестированием
    • TestLink

• SAP

  • • Назад
    • ABAP
    • APO
    • Начинающий
    • Basis
    • BODS
    • BI
    • BPC
    • CO
    • Назад
    • CRM
    • Crystal Reports
    • QM4000
    • QM4
    • Заработная плата
    • Назад
    • PI / PO
    • PP
    • SD
    • SAPUI5
    • Безопасность
    • Менеджер решений
    • Successfactors
    • Учебники SAP
  • Apache
    • AngularJS
    • ASP.Net
    • C
    • C #
    • C ++
    • CodeIgniter
    • СУБД
    • JavaScript
    • Назад
    • Java
    • JSP
    • Kotlin
    • Linux
    • Linux
    • Kotlin
    • Linux

    js

    • Perl
    • Назад
    • PHP
    • PL / SQL
    • PostgreSQL
    • Python
    • ReactJS
    • Ruby & Rails
    • Scala
    • SQL

    000

    • SQL

    000

    0003 SQL

    000

    0003 SQL

    000

    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

  • Обязательно учите!

    • • Назад
      • Бухгалтерский учет
      • Алгоритмы
      • Android
      • Блокчейн
      • Business Analyst
      • Создание веб-сайта
      • CCNA
      • Облачные вычисления
      • 00030003 COBOL 9000 Compiler
        9000 Встроенные системы
        • 00030002 9000 Compiler 9000
        • Ethical Hacking
        • Учебники по Excel
        • Программирование на Go
        • IoT
        • ITIL
        • Jenkins
        • MIS
        • Сеть
        • Операционная система
        • Назад
        • Управление проектами Обзоры
        • Salesforce
        • SEO
        • Разработка программного обеспечения
        • VB A

    • Big Data

      • • Назад
        • AWS
        • BigData
        • Cassandra
        • Cognos
        • Хранилище данных

        0003

        • HBOps

        0003

        • HBOps

        0003

        • MicroStrategy
        • MongoDB

    .

    Как написать сценарий использования

    Как человек с опытом работы в бизнесе, обнаруживаете ли вы, что многие должности бизнес-аналитика предполагают взаимодействие с ИТ-командой или ИТ-системами? Вам интересно, как вы будете выполнять эти обязанности, если у вас мало (или совсем нет) технических знаний?

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

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

    >> Щелкните здесь, чтобы загрузить шаблон варианта использования << .

    Для тех, кто любит читать, а не смотреть, вот полный текст видео:

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

    Зачем писать пример использования

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

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

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

    Что такое вариант использования?

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

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

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

    Шаблон сценария использования: что включено

    Что входит в вариант использования? Я собираюсь пройти по общим разделам, которые есть в очень традиционном шаблоне сценария использования. Вы можете делать заметки, если хотите, но вы также можете скачать наш шаблон. Это один из тринадцати шаблонов, которые мы включаем в наш набор инструментов Business Analyst Template Toolkit, и вы можете получить его на сайте Bridging-the-Gap / UCTemplate. Вам очень легко скачать. Также должна быть ссылка под этим видео.

    Вы хотите начать с имени , и, как и в случае с бизнес-процессом, вы хотите, чтобы это имя было глаголом-существительным.Итак, «Купите курс», «Подпишитесь на бесплатное обучение», а не просто «Пример использования бесплатного обучения». Вы хотите знать: какое действие, предпринимаемое пользователем, будет описано в сценарии использования?

    Далее идет краткое описание , и одна из вещей, которые мне очень нравится включать в свое краткое описание, — это предложение, которое действительно проясняет объем. «Этот вариант использования начинается, когда…» и «Этот вариант использования заканчивается, когда…», потому что когда вы начинаете писать все эти шаги, вы обнаруживаете все эти варианты.Затем, внезапно, ваш вариант использования появляется повсюду, и вы говорите: «Лора, это не последовательность шагов. Это паутина «. Обычно это происходит из-за того, что вы сбиваетесь с пути, или слишком подробно изучаете альтернативные варианты, или просто выходите за рамки тех шагов, которые необходимо выполнить для конкретной цели этого варианта использования. «Когда начинается», «Когда заканчивается». Большой совет.

    Актеры : кто такие пользователи, роли или типы субъектов, которые могут использовать систему? Это не должность; это актер.Эту роль в системе могут выполнять несколько человек. Это то, что система может определить о вас. Вы покупатель? Вы администратор? Вы репортер? Что-то подобное.

    Предварительные условия : что должно быть выполнено перед запуском варианта использования? Это опять же очень системный уровень. Что система может знать, что это правда, до того, как начнется сценарий использования?

    Затем вы попадаете в базовый поток , и мне нравится думать об основном потоке, как о пинг-понге. Пользователь делает одно, система — другое.Пользователь делает одно, система — другое. «Пинг-понг, пинг-понг». Это не всегда так однозначно. Иногда это похоже на «Пинг, пинг, понг, понг, понг. Настольный теннис.» Это не обязательно должно быть просто одно и то же, но представление об этом как о пинг-понге действительно помогает убедиться, что вы получаете взаимодействие между пользователем и системой.

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

    С другой стороны, более техничный человек часто говорит: «Пользователь делает одно действие в режиме« Бум, бум, бум, бум »». Это похоже на «Понг, понг, понг, понг, понг». Это все технические детали того, что делает система, что намного глубже, чем то, что на самом деле заботит бизнес, потому что вы просто теряете их с «текстом», говоря: «О, система выполняет такого рода процедуры и обновляет это data, и отправляет их в этот API, и обновляет веб-форму », и все эти технические детали.Это не то, что входит в сценарий использования. Это не техническая спецификация. Это не системная спецификация. Вам нужны требования. Что представляет собой наблюдаемая часть системы, что пользователь может видеть, что делает система, и ощущать ее действия? Не то, как система все это делает. Я понимаю, что там происходит много волшебных и пикантных вещей; он не подходит для вашего варианта использования. Настольный теннис. Иногда «Пинг, пинг, понг», но не все одно или все другое. В противном случае у вас действительно есть другой тип документа, а не вариант использования.

    Затем альтернативные потоки и исключительные потоки . Это варианты пути. Иногда… Давайте посмотрим на пример. Для «Смотреть видео» у вас может быть «Пауза». Вы можете приостановить видео. Вы можете завершить видео (пожалуйста, не делайте этого!). Вы можете делать разные вещи. Вы можете поставить лайк видео. У вас может быть — Иногда это может не вписываться в рамки этого варианта использования, но все разные вещи, которые вы можете делать. Поток исключения может быть следующим: что произойдет, если ваше Интернет-соединение прервется и поток закончится? Как это представить пользователю? Вещи, которые идут не так, как надо, и мешают людям достичь конечной цели или конца варианта использования.

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

    Сценарии использования не требуют технических знаний

    Одна вещь, которую я хочу затронуть — и я уже упоминал об этом, когда описывал вариант использования, но мы все еще получаем много вопросов по этому поводу, — это: разве этот вариант использования не требует технических знаний? «Что мне делать, если я не разбираюсь в технологиях? Как мне общаться с разработчиками и как выполнять требования? Похоже, я должен знать все эти технологии и должен знать бизнес-анализ ».

    На самом деле, вы должны думать о сценарии использования как об инструменте, который позволяет вам сообщать о том, что технология должна делать, фактически не зная, как она построена, потому что вы не делаете все эти «Понг, понг, понг, понг» .«Вы не видите всех различных частей технологии, которые происходят за кулисами. Вы говорите: «Каковы мои наблюдаемые функции как пользователя? Что, на мой взгляд, делает для меня система? » Как бизнес-аналитик, мы должны уметь четко понимать это. Это часть той ясности, которую мы вносим в таблицу.

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

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

    В качестве примера предположим, что мы говорим о «Курсе покупки». У нас есть шаг для пользователя, выбирающего курс, шаг для системы, представляющей форму заказа. Затем пользователь заполняет форму заказа; пользователь отправляет форму заказа, корзина проверяет данные кредитной карты. Я, вероятно, здесь кое-что упускаю, но у вас будет постоянный обмен мнениями между пользователем и системой. Если вы смотрели мое видео о бизнес-процессе, то знаете, что регистрация участника курса происходит автоматически.Как это на самом деле происходит? Какой результат позволяет это осуществить? За кулисами есть — я не знаю технического термина, — но есть пинг данных, который отправляет данные этой кредитной карты. Это было бы действительно важно, информация о пользователях из одной системы в другую, поэтому мы можем автоматизировать эту настройку и как можно быстрее получать данные о регистрации на курс.

    Вот такие вещи, где можно увидеть разрыв. Типа: «Ну, погоди. Мы видим, как это происходит здесь.У нас вот что происходит. На самом деле мы не знаем, какие шаги нужно пройти от пункта А до пункта Б. Мне это не ясно ». У нас были люди, которые задают этот вопрос в новинку для нашего бизнеса. «Как это на самом деле происходит?» Они используют свой вариант использования, чтобы продумать все и найти пробел. Это намного проще, если вы на самом деле пишете вариант использования и переходите к шагам, где последним шагом будет получение пользователем своего регистрационного письма на курс. Вы говорите: «Погодите.Это не из корзины покупок. Откуда он берется и как туда попадает? » Это тот вид пошагового мышления, который вы хотите применять в своих сценариях использования и который вы хотите использовать. Это действительно помогает вам понять технологию без необходимости создавать технологию.

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

    Загрузите шаблон сценария использования сегодня

    Это мой рассказ на сегодня. Спасибо за просмотр. Опять же, загрузите этот шаблон варианта использования здесь .

    Как всегда, мы строим нашу профессию по одному бизнес-аналитику. Успех начинается с тебя.

    Спасибо, что вы здесь. Спасибо за просмотр. Меня зовут Лаура Бранденбург из компании Bridging the Gap, и мы поможем вам начать карьеру бизнес-аналитика. Удачного моделирования!

    .

    No related posts.