Когда отображается тема (или граница системы), недостающий вариант использования визуально находится в прямоугольнике границы системы. Обратите внимание, что это не обязательно означает, что классификатор тем имеет включенные варианты использования, только то, что вариант использования применим к этому классификатору.
Мастерская бизнес-анализа
Каждый разработчик информационных систем рано или поздно сталкивается с вариантами использования. В результате, однако, часто случается, что эта полезная техника не используется по назначению и не приносит ожидаемых выгод. Так в чем же проблема и как эффективно писать сценарии использования?
Алистер Коуберн 1 сказал все это пять лет назад в своей статье «Use cases, десять лет спустя» 2. Я попытаюсь добавить сюда некоторые практические аспекты из собственного опыта. Я предполагаю, что читатель знаком с VI (если нет, рекомендую книгу «Написание эффективных примеров использования» Алистера Коуберна 3).
С помощью VGI можно описать взаимодействие системы с окружающим миром и таким образом лучше понять систему. То есть, WI можно рассматривать как своего рода описание требований к системе (система должна быть такой, чтобы поведение, наблюдаемое извне, соответствовало описанию в WI). В предыдущем предложении ключевыми словами являются «один из». Существует бесчисленное множество способов написания различных системных требований, и theVI — лишь один из них, подходящий только для конкретного типа требований в конкретной среде. При успешном использовании ВИ описывают систему в компактной и понятной форме. Когда ВИ используются в недостаточной степени, они отнимают время автора и читателя и не способствуют ясности изложения.
Пример: Описываем задачу поиска
Мой любимый пример — задача поиска (для наглядности пусть это будет поиск по сайту). Давайте попробуем написать VIs для поиска:
VI 1 (простой): Поиск
Пользователь вводит слово для поиска. Система находит документы, содержащие это слово, и отображает их пользователю в виде списка.
Это понятно? По сути, мы описали поведение любой поисковой системы. Будет ли нашего ВИ достаточно для внедрения Google? К сожалению, нет. Означает ли это, что наш API неверен? Это не так. Мы написали хорошую статью. Это коротко и ясно. Вот как это работает. Вы просто не можете описать все аспекты работы поисковой системы в VI. Некоторые люди начинают «улучшать» ВИ, добавляя к нему всевозможные детали:
VI 2 (подробный): Поиск.
1. пользователь вызывает страницу поиска.
2. система представляет страницу поиска с по крайней мере одним полем для поискового слова и кнопкой «Поиск».
Пользователь отображает поисковое слово. 4.
Система находит документы, содержащие это слово, и отображает их пользователю в виде списка. Список отсортирован по релевантности. Список выводится в виде страниц с 50 результатами. Каждый результат отображается с названием документа, цитатой из документа, содержащей выделенный поисковый термин, и индексом релевантности.
Пользователь выбирает документ. 6.
Система открывает выбранный документ.
Альтернативы
4a. Поисковый запрос не найден.
1. система выводит сообщение об ошибке: «Не найдено ни одного документа, соответствующего запросу».
Улучшение? Нет! Пока недостаточно данных для приложения. Есть еще текст. Вам придется читать его все более внимательно, чтобы получить нужную информацию. В то же время ту же информацию можно было бы передать лучше. Например, вот так:
Рис. 1 Результаты поиска Google.ru
Более подробное описание различных требований потребовало бы других форм, которые не имеют никакого отношения к VI.
Для описания синтаксиса языка вопросов можно использовать формальную нотацию, например, Backus-Naur 4.
Требования к производительности (например, время отклика или количество запросов в минуту) могут быть заданы с помощью простой таблицы чисел.
Чтобы грамотно описать, что и как должно существовать, необходимо включить модель данных.
Для иллюстрации элементов пользовательского интерфейса, включая переходы состояний, вы можете создать прототипы с помощью HTML (или нажать кнопку dummy) или просто нарисовать несколько картинок в Visio.
Тексты различных сообщений следует выгрузить в электронную таблицу, поскольку их, скорее всего, придется переводить (и даже если их не переводить, они все равно не будут красиво сформулированы разработчиком).
Что касается VI, я бы вернулся к первой — простой — версии. Или отбросьте этот ВИ из-за его незначительного характера. Это важный принцип: вместо того, чтобы писать тривиальные ВИ, лучше не писать их вообще. Каждое написанное вами предложение должно иметь смысл, а не просто заполнять определенный шаблон.
Когда нужны варианты использования
Почему вы должны использовать VIs, когда есть так много других удобных способов написания требований? В некоторых случаях они просто более удобны. В этом разделе вы найдете несколько примеров этого.
Незнакомая предметная область
Если ваши проекты снова и снова вращаются вокруг одной и той же темы и отличаются только набором параметров, VIs, вероятно, не пригодятся. Однако если вы столкнулись с незнакомой предметной областью, начните с классического исследования и попытайтесь выяснить, о чем идет речь. Это исследовательский проект, в котором вы постепенно открываете новых участников, их цели и то, как они используют систему. Это то, что формат IB хорошо подходит для съемки. Ваш документ ВИ будет эволюционировать, развиваться, улучшаться и, что самое главное, постоянно влиять на другие документы — такие как модель данных и прототип пользовательского интерфейса, — которые создаются параллельно с ВИ.
Сложные взаимодействия
Если вы имеете дело с большим и сложным бизнес-процессом, то, скорее всего, создание пользовательского интерфейса упростит ситуацию (или, по крайней мере, позволит вам подойти к сложному процессу так, чтобы разные люди могли говорить о нем в одних и тех же терминах).
С высоты птичьего полёта
Цели пользователей часто располагаются в иерархии. Вот пример из статьи, упомянутой ранее2:
«Например, я могу сказать, что моя главная цель — получить хороший контракт. Более близкая цель (временной горизонт сужается) — пригласить клиента на совместный обед. Еще более близкая цель (временной горизонт еще более узкий) — получить наличные деньги, чтобы заплатить за еду. Эта цель подводит меня к необходимости снять деньги с карты в ближайшем банкомате. В то же время, моя самая срочная и самая короткая по времени цель — вставить карту в банкомат и начать транзакцию».
Когда функциональные требования описываются на уровне, позволяющем разработчикам реализовать систему, цели более высокого уровня легко теряются. Так, в примере, ваш документ будет продолжать говорить о том, что пользователь вставляет карту в автомат и пытается снять деньги. Чтобы не пропустить лес за деревьями, часто полезно написать синтетический ВИ в большем масштабе. Он может проходить через несколько модулей и даже включать несколько пользователей — главное, чтобы он показывал, как все описанные требования собираются вместе, чтобы в конечном итоге дать пользователю желаемый результат.
Предположим, что мы имеем дело с системой закупок. Наш пользователь, покупатель, является сотрудником отдела закупок. У него есть начальник, который должен утвердить приказы своих подчиненных, прежде чем они будут выполнены.
VI: Заказ товаров.
1. покупатель выбирает нужный ему товар (см. «каталог») и заказывает его (см. «процесс заказа»).
2. система помещает заказ в очередь и уведомляет менеджера по закупкам. 3. менеджер по закупкам получает уведомление.
Менеджер по закупкам получает уведомление из системы, проверяет заказ и утверждает его. 4.
4. система получает заказ и отправляет подтверждение покупателю.
Это позволит вам не забыть, например, почему разработчики работают над компонентом рабочего процесса и какие функции в нем необходимы для основного компонента рабочего процесса. Эти четыре строки текста очень лаконичны — они проходят через всю систему и могут стать причиной многомесячной работы многих разработчиков. Такой ВИ имеет больше шансов быть прочитанным и понятым пользователем и/или клиентом, чем длинный, подробный ВИ на 3 страницах.
2.2 Блокирование персональных данных — временное прекращение обработки персональных данных (за исключением случаев, когда обработка необходима для уточнения персональных данных).
Что такое юзкейс?
Существует несколько определений, которые на первый взгляд сильно отличаются друг от друга. Наиболее невнятную формулировку можно найти у Кобурна, который определяет вариант использования как «соглашение о поведении соответствующей системы». Действительно, Кобурн написал целую книгу, чтобы раскрыть и уточнить свое определение.
А вот определение из глоссария UML (мой перевод).
Экземпляр — это описание набора последовательностей действий системы, включая вариации этих последовательностей, которые приводят к наблюдаемому результату, имеющему определенную ценность для того, кто вовлечен в процесс.
Какое определение следует иметь в виду при написании дела? Оно должно подсказать мне, что нужно сделать, что нужно вспомнить, чтобы написать:
Кейс — это документ, описывающий сценарий взаимодействия с системой, который приводит к важному результату.
Он короткий, и это хорошо. Однако существуют некоторые неявные спецификации. Я также помню об этом, когда разрабатываю сценарий использования. Вот полная версия:
Вариант использования — это документ, описывающий сценарий (возможно, не один) взаимодействия (кого или чего?) с системой, который приводит (возможно, не приводит) к важному результату (для кого?).
Такое определение говорит о том, что оно должно быть понятно из описания варианта использования:
- Результат — находится в названии дела.
- О какой системе идет речь?
- Участники взаимодействия (акторы: люди, внешние системы, кто является главным действующим лицом?).
- Последовательность действий
- На каждом этапе: кто? Кто?
- Что произойдет, если что-то пойдет не так?
Что происходит, когда что-то идет не так?
Основной сценарий
- Трейдер создает заявку на установку ставки. Заявка содержит все начальные курсы покупки и продажи для списка перечисленных валют, а также даты и время их вступления в силу (см. форму заявки).
- Финансовый директор получает электронное письмо с подтверждением заявки.
- Директор рассматривает заявление и утверждает его (см. форму утверждения).
- АБС сохраняет тарифы для использования в QIWI-кошельке с даты, указанной в запросе.
- Заинтересованные лица получают электронное письмо с информацией о новых курсах и дате/времени их начала.
- На этапе 3 директор отклоняет запрос.
- Трейдер получает электронное письмо об отклонении запроса.
Что не нужно в юзкейсе
Кобурн не скрывает, что предпочитаемый им формат usecase — Fully Dressed, который включает разделы с основным и альтернативными сценариями:
- Usecase
- Область применения
- Уровень
- Главные герои
- Участники и интересы
- Требование
- Минимальные гарантии
- Триггер
- Расширения
- Перечислите изменения в технологиях и данных
При разработке сценария использования не делайте поспешных ограничений на проектирование. Посмотрите на приведенный выше пример использования. В нем не хватает деталей экранов и элементов управления интерфейсом. Выбирает ли пользователь опцию из выпадающего списка, выбирает опцию или нажимает кнопку? Сейчас это не важно, решения на этом уровне следует оставить на потом. Не делайте работу дизайнера, он сделает ее лучше вас.
Можно сформулировать это так: давайте, вы написали, что менеджер получает уведомление по электронной почте. Почему не SMS или другой способ? Потому что мы с пользователями уже договорились об уведомлении по электронной почте. Если бы я написал в резюме, они бы спросили: как получилось, что мы не договорились об электронной почте? Что-то изменилось? Описав пользовательский интерфейс немного более подробно, чем предполагает методология, я позаботился о том, чтобы читатель не споткнулся при чтении сценария использования.
В целом, основным критерием выбора информации для включения в пример использования должна быть понятность. Это может происходить в ущерб правилам, деталям и иногда даже точности. Самое главное, дело должно быть понятно сразу. Если его трудно понять спонтанно, то это плохой вариант использования.
Чего еще не хватает в этом примере? В нем ничего не говорится о том, как комиссии переводятся из АБС в процессинговую систему QIWI-кошелька. Потому что это предмет другого взаимодействия и другого исследования. Если плата не доходит до системы обработки из-за ошибки, это не является заботой торговца. Для него результат достигнут: тарифы выделены и утверждены.
Не пытайтесь втиснуть все в рамки одного варианта использования. Разделите его в соответствии с целями пользователей.
Условные конструкции
Одно из ключевых требований Кобурна — отсутствие ветвления в сценарии. Если существует альтернативный сценарий, он должен быть описан отдельно. Любая сложная блок-схема с ветвями и циклами может быть представлена в виде серии линейных сегментов.
Я не всегда следую этому правилу. Должен признаться, что я изменил свой пользовательский случай, прежде чем опубликовать его здесь в качестве примера. В оригинале это выглядело следующим образом. Различия начинаются со страницы 3.
Сценарий конфигурации курса
- Трейдер создает заявку на установку ставки. Заявка содержит все начальные курсы покупки и продажи для списка перечисленных валют, а также даты и время их вступления в силу (см. форму заявки).
- Финансовый директор получает электронное письмо с подтверждением заявки.
- Директор рассматривает заявку и утверждает или отклоняет ее (см. форму утверждения).
- Если заявка будет отклонена, трейдер получит электронное письмо, подтверждающее отклонение заявки.
- Если заявка утверждена: a. Ставки будут храниться для использования с даты, указанной в заявке. b. Перспектива получит электронное письмо с новыми тарифами и датой/временем начала действия тарифов.
Хотя поддержка бизнес-моделирования заявлена как цель UML, спецификация UML не содержит определения для случаев использования бизнеса.
Как написать use case?
Шаги сценария использования описаны как можно более четко. Что касается отдельных шагов, то они могут выглядеть следующим образом
- Определите, кто будет пользоваться веб-сайтом.
- Определите, кто будет пользоваться веб-сайтом.
- Укажите, что этот пользователь хочет сделать на сайте. Все, что пользователь делает на сайте, становится вариантом использования.
- Укажите нормальную последовательность событий для каждого случая использования.
- Опишите основной путь пользователя: что именно он делает и какова ожидаемая реакция системы.
- Затем рассмотрите и добавьте альтернативные пути событий для «расширения» сценария использования.
- Повторите шаги 2-6 для всех остальных пользователей.
Пример use case
Этот пример использования описывает сценарий входа пользователя в школьную систему.
| Название варианта использования | Вход в систему |
| Описание сценария использования | Пользователь входит в систему для доступа к функциям. |
| Актер | Родители, студенты, преподаватели, администраторы |
| Пререквизиты | Система должна быть подключена к сети |
| Метаданные | После успешного входа в систему пользователь получает уведомление по электронной почте |
| Основные сценарии | Номер | Шаги |
| Актеры/Пользователь | 1 | Введите имя пользователя Введите пароль |
| 2 | Проверьте имя пользователя и пароль | |
| 3 | Разрешить вход | |
| Расширения | 1a | Неправильное имя пользователя Система выводит сообщение об ошибке |
| 2b | Неправильный пароль Система выводит сообщение об ошибке | |
| 3c | Введите неправильный пароль 4 раза Приложение закрыто |
Юзкейс-диаграммы
Диаграмма используется для визуализации сценария использования. На диаграмме система представлена прямоугольником, вариант использования — овалом, а действующее лицо — маленькой графической фигуркой.
Пример диаграммы для случая входа пользователя в школьную систему:
9.3 Обработка персональных данных необходима для отправления правосудия, исполнения судебного акта, акта другого органа или должностного лица, которое должно осуществляться в соответствии с законодательством Российской Федерации об исполнительном производстве.
How to write a use case for a project
Представленный в письменном виде, вариант использования может быть полезной частью проектной документации. Варианты использования являются общим артефактом требований и могут облегчить коммуникацию между техническими и бизнес-заинтересованными сторонами.
В зависимости от аудитории и обсуждаемой системы, пример использования может быть настолько подробным или простым, насколько это необходимо. Документ о варианте использования должен определять и идентифицировать некоторые ключевые элементы — это:
- Система: Система — это продукт, услуга или программное обеспечение, о котором идет речь.
- Агенты: Агент — это пользователь или что-то другое, демонстрирующее определенное поведение при взаимодействии с системой. Агентом может быть другая система, часть оборудования или целая организация. Существует четыре типа агентов: обсуждаемая система, внутренний агент, первичный агент и вторичный агент. Чаще всего упоминаются две последние системы. Первичный агент инициирует взаимодействие с системой, а вторичный агент может предоставлять системе услуги.
- Сценарий: В книге «Применение UML и паттернов» Ларман утверждает, что «сценарий — это конкретная последовательность действий и взаимодействий между участниками и обсуждаемой системой; его также называют сценарием использования».
- Вариант использования: Вариант использования описывает сценарии успеха и неудачи, которые могут произойти при взаимодействии субъекта(ов) с системой. В этом разделе вы определяете основной сценарий успеха, т.е. наиболее желательный результат взаимодействия между субъектом и системой. Вы также указываете альтернативные пути, которые объясняют, что произойдет в случае сбоя или ошибки.
Let’s take a look at a simple use case example:
- Пример использования приложения для доставки еды: люди могут использовать приложение для размещения заказов на еду непосредственно в ресторанах. Когда пользователь делает заказ, ему предлагается оплатить его через приложение или заплатить при доставке еды. Как только это подтверждается, ресторан получает запрос через свою систему. Затем продукты готовятся, упаковываются и доставляются человеку. В этом случае приложение должно иметь возможность принимать заказы, обрабатывать платежи и осуществлять электронную связь с рестораном.
- Система: Приложение для доставки еды
- Протагонист: Клиент, заказывающий еду.
- Сценарий: Пользователь просматривает варианты ресторанов. Выбрав нужный ресторан, он оформляет заказ через приложение. Пользователь платит онлайн или подтверждает оплату лично. Заказ отправляется из приложения во внутреннюю систему ресторана. Сотрудник ресторана принимает онлайн-заказ и обрабатывает его.
Этот вариант использования иллюстрирует, как клиент и сотрудник ресторана (операторы) взаимодействуют с приложением для доставки еды (системой) и какой результат ожидается от каждого взаимодействия.
What is a use case model?
Модель сценария использования — это визуальное представление взаимодействия между субъектом и системой. Как также отмечает PMI, модели вариантов использования представляют процессы, что облегчает формулировку предположений и триггеров.
Модель варианта использования обычно выражается с помощью UML (универсального языка моделирования). В этих представлениях есть три основных компонента: система, действующие лица и сценарий использования.
Система представлена прямоугольником или ограничительной рамкой. Действующие лица представлены в виде фигурок вне ограничительной рамки, а сценарии использования — в виде текста в овале внутри рамки. Сплошные и пунктирные линии показывают соотношение между действующими лицами и вариантами использования в системе.
Use case model example:
What is the difference between a use case model and a use case diagram?
Диаграмма сценария использования — это просто разновидность модели сценария использования. Диаграмма модели варианта использования использует текст и фигуры для представления отношений между пользователем и системой.
В первую очередь, диаграммы моделей вариантов использования используются для:
- Визуализация потока и поведения системы.
- Иллюстрировать функциональность системы.
- Проиллюстрируйте ключевые взаимодействия системы и пользователя.
В зависимости от системы, диаграмма модели варианта использования может отличаться по сложности и представлять основные взаимодействия или быть расширенной для представления множества исключений.
Самым известным инструментом в предметной области является глоссарий. Если вы начнете объяснять все подряд, читатель заскучает уже после первых трех абзацев и закроет глоссарий, потому что не дошел до самого главного.
Relationships Between Use Cases
Примеры использования могут быть организованы с использованием следующих взаимосвязей:
Generalization Between Use Cases
Обобщение между вариантами использования аналогично обобщению между классами — дочерний вариант использования наследует свойства и поведение родительского варианта использования и может переопределять поведение родительского варианта использования.
Обобщение представлено в виде непрерывной, направленной линии с большим полым треугольным наконечником стрелки, подобно обобщению между классификаторами, которое ведет от наиболее конкретного случая использования к общему случаю использования.
Вариант использования Web User Authentication — это абстрактный вариант использования, который специализируется на вариантах использования Login, Remember Me и Single Sign-On.
Association Between Use Cases
Варианты использования могут участвовать только в бинарных ассоциациях.
Два варианта использования, в которых указан один и тот же объект, не могут быть связаны друг с другом, поскольку каждый из них описывает полное использование системы самостоятельно.
Расширение сценария использования
Заметили ли вы орфографическую ошибку? Выделите текст с помощью мыши и нажмите Ctrl + Enter.
Кирилл Фахрутдинов.
Данный документ описывает UML 2.5 и основан на спецификации OMG™ Unified Modeling Language™ (OMG UML®) 2.5 UML 2.5 RTF — Beta 2.
Все диаграммы UML были созданы в Microsoft Visio 2007-2016 с использованием стандарта UML 2.2. Свои замечания и предложения вы можете направлять веб-мастеру по адресу webmaster@uml-diagrams.org.
Проблема с этим требованием заключается в том, что оно не учитывает, какие варианты использования расширяются, а какие включаются. Расширение сценария использования не обязательно должно быть полезным. Включенный вариант использования — это общая часть, которая выделяется в отдельный вариант использования. Также представляется непрактичным требовать получения наблюдаемого результата.
Текст vs диаграмма/схема
Какое описание лучше: текст или диаграмма? Решение зависит от вас и вашей команды. В первые годы я использовал либо диаграммы, либо диаграммы + текстовые описания. Сейчас я предпочитаю описывать сценарии с помощью текста и объясню почему:
- Такой формат более понятен для клиентов (и они также предпочитают читать и соглашаться с использованием).
- Текст обрабатывается легче и быстрее, чем диаграммы и текст.
Если дополнительная польза от использования диаграмм в вашем проекте очевидна, конечно, вы должны их использовать.
Кому и в каких случаях нужны сценарии
- Программисты. Очень удобно, когда разветвленный запрос описывается с помощью основного и альтернативного потока событий. Все ясно: кто и когда звонит и что из этого получается. В моем последнем проекте менеджер придерживался подхода: минимум описаний, максимум общения. Но сами разработчики требовали подробных описаний для нескольких сложных сценариев, и сценарии использования сработали идеально.
- Клиентам. Описывая на человеческом языке, клиент может вовремя подтвердить, что это именно то, что он ожидает, или исправить это.
- Тестеру. Почти готовый тестовый пример.
- Всей команде проекта. Если необходимо согласовать сценарий и на каждой встрече заслушиваются два или три альтернативных варианта сценария, полезно точно описать последовательность событий.
А также другим участникам процесса.
В каких случаях они нужны:
- Если вам нужна хорошая, исчерпывающая спецификация требований, тематические исследования станут отличным подспорьем. Для разработки и сопровождения таких систем очень хорошо подходит спецификация требований, включающая модель данных, описание интерфейса, интеграцию с другими системами и пользовательские примеры.
- Для поддержки системы. Чтобы отследить ошибку, необходимо выяснить, на каком этапе что-то пошло не так.
- Если вам нужно описать часть функциональности, пользовательского интерфейса и т.д. в сценарии. Затем вы можете взять за основу шаблон сценария использования и использовать его для описания сценария. Например, основой требований для вашего мобильного приложения является описание пользовательского интерфейса. Однако реализация определенных функций имеет множество тонкостей, которые необходимо более подробно описать в «плане действий и реагирования» или даже в комбинации плана и сценария.
Как их описывать
Давайте рассмотрим несколько примеров, которые говорят сами за себя.
Пример 1. Разблокировка учетной записи пользователя (простой короткий пример, без альтернативного потока событий):
Пример 2. Авторизация пользователя:
Проблема с этим требованием заключается в том, что оно не учитывает, какие варианты использования расширяются, а какие включаются. Расширение сценария использования не обязательно должно быть полезным. Включенный вариант использования — это общая часть, которая выделяется в отдельный вариант использования. Также представляется непрактичным требовать получения наблюдаемого результата.
What are a use case and a use case scenario?
Вариант использования — это набор шагов, необходимых для достижения конкретной задачи или цели. У сценария использования может быть несколько путей достижения цели; каждый из этих путей считается сценарием сценария использования. Проще говоря, сценарий использования — это цель с несколькими процессами, а сценарий использования представляет собой линейный и прямой путь через один из процессов.
Пример использования отвечает на следующие вопросы:
- Каков сценарный контекст задачи?
- Каковы условия процесса?
- С какими исключениями может столкнуться задача?
- Как должно быть выполнено задание?
- Какие ошибки могут возникнуть в процессе?
Сколько у нас есть способов выполнить задание? (Основные маршруты и альтернативные маршруты)
Пример 1: Допустим, это запись в мобильном приложении; история пользователя будет выглядеть следующим образом: Пользователю A нужно нажать ENTER, чтобы получить доступ к приложению. (Затем мы разработали сценарий использования: Сначала нам нужно открыть приложение, проверить подключение устройства, а затем представить пользователю варианты выполнения задачи. Мы видим, что у нас есть несколько вариантов: Мы можем войти в систему с помощью учетной записи Facebook, учетной записи Twitter или по электронной почте. Сценарий использования — это вход в систему; каждый из вариантов входа в систему — это сценарий использования. Все ситуации приводят к одному и тому же результату, но как пользователь мы будем сталкиваться с разными интерфейсами в зависимости от нашего выбора входа.
User story and a use case. What is the difference?
История пользователя дает нам больше информации о мотивации и потребностях пользователя; она также дает нам всеобъемлющую цель, связанную с примером использования. Она дает нам подробную информацию о том, как достичь цели, и обо всех сценариях, с которыми пользователь может столкнуться при выполнении задачи. Вариант использования является более подробным и в большей степени сосредоточен на функциональности. Чтобы узнать больше о пользовательских историях, прочитайте нашу статью «Раскадровки и как они помогают определить продукт».
Пользовательский поток — это более детальное и графическое представление сценария использования или сценария использования. Блок-схемы представляют навигацию в виде карты; они используют фигуры и графику для представления содержимого экрана и навигационные маркеры для представления взаимодействия между экранами. Сложные случаи не следует документировать с помощью блок-схем. Если сценарии использования включают несколько экранов/элементов и навигационных спецификаций, диаграмма может стать слишком длинной и очень сложной для понимания.
Потоки пользователей могут быть:
- Рабочие процессы: фигуры и навигационные стрелки представляют шаги.
- Кабельные потоки: более подробные потоки. Вместо графических фигур они содержат формы кабелей и навигационные стрелки с низкой или средней точностью. Кабельные потоки не фокусируются на конкретных задачах, а скорее на общей навигации.
- Пользовательские потоки: включают в себя электронные схемы с низкой или средней точностью, с той разницей, что потоки являются специфическими для функциональности с точки зрения пользователя или навигации задачи, в отличие от электронных схем, которые документируют более одной общей перспективы.
Что же делать, если поток слишком велик, чтобы его можно было представить на одной диаграмме? Мы можем рассмотреть использование потоков проводов и потоков пользователей в документах. Эти документы содержат эскизы с низкой и средней точностью. Вместо стрелок навигация осуществляется с помощью уникальных идентификаторов экрана и индикаторов на схемах. Каждое действие (кнопки, меню и т.д.) ссылается на другие ярлыки экрана. Этот тип документации служит своей цели для каждого пользовательского сценария, случая использования, функции и т.д.
Our experience.
Варианты использования, истории пользователей и блок-схемы являются важной частью проектирования и разработки мобильных приложений. Мы выяснили, что пользовательские истории обычно создаются владельцем продукта для передачи потребностей пользователей и бизнеса. Технические руководители и дизайнеры UI/UX разрабатывают пользовательские потоки на основе пользовательских историй и требований. Затем дизайнеры UI/UX реализуют сценарии использования и переводят их в графические блок-схемы. Вся документация необходима для текущей и будущих версий продукта.
По нашему опыту, сценарии использования и блок-схемы — это документация, которая проходит через различные стороны, участвующие в процессе:
- Владелец продукта получает сценарии использования для подтверждения пользовательских историй.
- Технические менеджеры и разработчики используют сценарии использования и блок-схемы в качестве документации для проверки функциональности реализации.
- UI-UX дизайнеры разрабатывают электронные схемы и макеты на основе сценариев использования.
- Команда SQA использует сценарии использования для проверки ожидаемой функциональности в сравнении с реализацией.
Создание примеров использования отнимает много времени, но, по нашему опыту, они, безусловно, необходимы и полезны в качестве справочной документации и руководства для разработчиков, дизайнеров и тестировщиков. Существует несколько способов документирования сценария использования; нет правильного ответа на вопрос, какой из них выбрать; все зависит от того, какой метод лучше всего подходит для вашего процесса и продукта. Выберите наилучшее погружение в зависимости от масштаба документируемого варианта использования. Если функция или условие еще не полностью определены, лучше всего сначала поработать над сценарием использования, а после утверждения сценария использования перевести его в блок-схему или документ.
Каковы цели документирования сценариев и потоков сценариев использования?
Анализ требований и документация
Помогает выявить незакрытые сценарии, дефекты или подсценарии.
Проверяет истории пользователей.
Помогает понять развитие функций.
В качестве последнего соображения рассмотрите бизнес-требования, требования к продукту и требования команды (разработка, SQA и т.д.). Убедитесь, что ваша документация включает все элементы, необходимые для поддержки команды, и что документация может быть расширена постепенно.
