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

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

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

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

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

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

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

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

Сценарии использования включают в себя следующие разделы: 

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

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

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

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

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

1. Система выводит информер  с указанием запрещенных символов.

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Модель
вариантов использования (Use—Case
Model).

Эта модель определяет требования к ПО
— то, что система должна делать — в виде
набора вариантов использования. Каждый
вариант использования задает сценарий
взаимодействия системы сдействующими
лицами (actors)или ролями, дающий в
итоге значимый для них результат.
Действующими лицами могут быть не только
люди, но и другие системы, взаимодействующие
с рассматриваемой. Вариант использования
определяет основной ход событий,
развивающийся в нормальной ситуации,
а также может включать несколько
альтернативных сценариев, которые
начинают работать только при специфических
условиях.

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

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

Характеристики
и атрибуты качества программного
обеспечения по ISO 9126

Определения
характеристик и субхарактеристик
качества (ISO 9126-1)

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

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

Правильность
(корректность) —
способность программного средства
обеспечивать правильные или приемлемые
для пользователя результаты и внешние
эффекты.

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

Защищенность —
способность компонентов программного
средства защищать программы и информацию
от любых негативных воздействий.

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

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

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

Сопровождаемость —
приспособленность программного средства
к модификации и изменению конфигурации
и функций.

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

Стандарт
ISO
9126 предлагает использовать для описания
внутреннего и внешнего качества ПО
многоуровневую модель. На верхнем уровне
выделено 6 основных характеристик
качества ПО. Каждая характеристика
описывается при помощи нескольких
входящих в нее атрибутов. Для каждого
атрибута определяется набор метрик,
позволяющих его оценить. Множество
характеристик и атрибутов качества
согласно ISO
9126 показано на рисунке.

   
1. Функциональность
(functionality) —
способность ПО в определенных условиях
решать задачи, нужные пользователям.
Определяет,
что именно делает ПО, какие задачи оно
решает. 

• Функциональная
  пригодность (suitability)
  — способность решать нужный набор задач.

• Точность
  (accuracy)
  — способность выдавать нужные результаты.

• Способность
  к взаимодействию (interoperability)
  — способность взаимодействовать с
  нужным набором других систем.

• Соответствие
  стандартам и правилам (compliance)
  — соответствие ПО имеющимся индустриальным
  стандартам, нормативным и законодательным
  актам, другим регулирующим нормам.

• Защищенность
  (security)
  — способность предотвращать
  неавторизированный, т.е. без указания
  лица, пытающегося его осуществить, и
  неразрешенный доступ к данным и
  программам. 

 
2. Надежность
(reliability) 
— 
способность 
ПО 
поддерживать 
определенную 
работоспособность
в заданных условиях. 

• Зрелость,
  завершенность (maturity)
  — величина, обратная частоте отказов
  ПО. Обычно измеряется средним временем
  работы без сбоев и величиной, обратной
  вероятности возникновения отказа за
  данный период времени.

• Устойчивость
  к отказам (fault
  tolerance)
  — способность поддерживать заданный
  уровень работоспособности при отказах
  и нарушениях правил взаимодействия с
  окружением. 

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

• Соответствие
  стандартам надежности (reliability
  compliance).

   
3. Удобство
использования (usability)
или практичность —
способность ПО быть удобным в обучении
и использовании, а также привлекательным
для пользователей. 

• Понятность
  (understandability)
  — показатель, обратный к усилиям, которые
  затрачиваются пользователями на
  восприятие основных понятий ПО и
  осознание их применимости для решения
  своих задач.

• Удобство
  обучения (learnability)
  — показатель, обратный усилиям,
  затрачиваемым пользователями на
  обучение работе с ПО. 

• Удобство
  работы (operability)
  — показатель, обратный усилиям,
  предпринимаемым пользователями для
  решения своих задач с помощью ПО. 

• Привлекательность
  (attractiveness)
  — способность ПО быть привлекательным
  для пользователей. 

• Соответствие
  стандартам удобства использования
  (usability
  compliance).

   
4. Производительность
(efficiency)
или эффективность —
способность ПО при заданных условиях
обеспечивать необходимую работоспособность
по отношению к выделяемым для этого
ресурсам. Можно определить ее и как
отношение получаемых с помощью ПО
результатов к затрачиваемым на это
ресурсам всех типов. 

• Временная
  эффективность (time
  behaviour)
  — способность ПО выдавать ожидаемые
  результаты, а также обеспечивать
  передачу необходимого объема данных
  за отведенное время.

• Эффективность
  использования ресурсов (resource
  utilisation)
  — способность решать нужные задачи с
  использованием определенных объемов
  ресурсов определенных видов. Имеются
  в виду такие ресурсы, как оперативная
  и долговременная память, сетевые
  соединения, устройства ввода и вывода
  и пр. 

• Соответствие
  стандартам производительности
  (efficiency
  compliance).

   
5. Удобство
сопровождения (maintainability) —
Удобство проведения всех видов
деятельности, связанных с сопровождение
программ. 

• Анализируемость
  (analyzability)
  или удобство проведения анализа —
  удобство проведения анализа ошибок,
  дефектов и недостатков, а также удобство
  анализа необходимости изменений и их
  возможных последствий.

• Удобство
  внесения изменений (changeability)
  — показатель, обратный трудозатратам
  на выполнение необходимых изменений. 

• Стабильность
  (stability)
  — показатель, обратный риску возникновения
  неожиданных эффектов при внесении
  необходимых изменений. 

• Удобство
  проверки (testability)
  — показатель, обратный трудозатратам
  на проведение тестирования и других
  видов проверки того, что внесенные
  изменения привели к нужным результатам. 

• Соответствие
  стандартам удобства сопровождения
  (maintainability
  compliance).

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

• Адаптируемость
  (adaptability)
  — способность ПО приспосабливаться
  различным окружениям без проведения
  для этого действий, помимо заранее
  предусмотренных.

• Удобство
  установки (installability)
  — способность ПО быть установленным
  или развернутым в определенном
  окружении. 

• Способность
  к сосуществованию (coexistence)
  — способность ПО сосуществовать с
  другими программами в общем окружении,
  деля с ними ресурсы. 

• Удобство
  замены (replaceability)
  другого ПО данным — возможность применения
  данного ПО вместо других программных
  систем для решения тех же задач в
  определенном окружении. 

• Соответствие
  стандартам переносимости (portability
  compliance).

   
Помимо перечисленных характеристик и
атрибутов качества, стандарт ISO
9126:2001 определяет наборы метрик для
оценки каждого атрибута. Вот
некоторые примеры таких метрик. 

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

2. Корректность
   реализации функций —
   правильность их реализации по отношению
   к требованиям. Используется
   для измерения функциональной пригодности. 

3. Отношение
   числа обнаруженных дефектов к
   прогнозируемому.
   Используется
   для определения зрелости. 

4. Отношение
   числа проведенных тестов к общему их
   числу.
   Используется
   для определения зрелости. 

5. Отношение
   числа доступных проектных документов
   к указанному в их списке.
   Используется
   для измерения удобства проведения
   анализа. 

6. Наглядность
   и полнота документации.
   Используется для оценки понятности.

17
вопрос+18 вопрос(Вопрос 2 темы Качество
ПО и методы его контроля)

Качество
программного обеспечения определяется
в стандарте ISO 9126 [1] как
вся совокупность его характеристик,
относящихся к возможности удовлетворять
высказанные или подразумеваемые
потребности всех заинтересованных лиц.
Тот же стандарт ISO 9126 [1-4]
дает следующее представление качества.
При рассмотрении качества ПО различаются
понятия внутреннего качества, связанного
с характеристиками ПО самого по себе,
без учета его поведения, внешнего
качества, характеризующего ПО с точки
зрения его поведения, и качество ПО при
использовании в различных контекстах
— то качество, которое ощущается
пользователями при конкретных сценариях
работы ПО. Для всех этих взглядов на
качество введены метрики, позволяющие
оценить его. Кроме того, при создании
качественного ПО существенно качество
технологических процессов его разработки.
Взаимоотношения между этими аспектами
качества по схеме, принятой в ISO
9126

Методы
контроля качества

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

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

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

Эффективность
верификации и валидации, как и эффективность
разработки ПО в
целом, зависит от полноты и корректности
формулировки требований к программному
продукту.

Основой
любой системы обеспечения качества
являются методы его обеспечения и
контроля. Методы
обеспечения качества [9]представляют
собой техники, гарантирующие достижение
определенных показателей качества при
их применении. Мы будем рассматривать
подобные методы на протяжении всего
курса.

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

• Методы
  и техники, связанные с выяснением
  свойств ПО во время его работы.

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

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

К
этому виду относятся проверка
на моделях (model
checking),
а также прототипирование
(макетирование),
используемое для оценки качества
принимаемых решений.

• Методы
  и техники, нацеленные на выявление
  нарушений формализованных правил
  построения исходного кода ПО, проектных
  моделей и документации.

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

• Методы
  и техники обычного или формализованного
  анализа проектной документации и
  исходного кода для выявления их свойств.

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

1. Составить общее представление о продукте.
Система может состоять из множества компонентов, а вся команда, включая аналитика, должна знать, как они работают. Например, в какой базе данных хранится нужная информация или в какую подсистему нужно отправить запрос для выполнения расчётов. Если команде нужно понять, как обычный человек взаимодействует с ПО, поможет use case.

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

Часто команды, которые давно разрабатывают продукт, говорят: «Нам это приложение уже как родное, мы знаем, как и что должно в нём работать. Давайте как-нибудь без юзкейсов. Сразу будем делать задачки». Однако в большом потоке задач можно упустить разные сценарии использования и забыть, что пользователи не идеальны и могут ошибаться, а системы не всегда выдают тот результат, который устроит пользователя. Например, при поиске авиабилетов пользователю может не подойти ни один из вариантов перелёта. Нужно предусмотреть, чтобы была возможность скорректировать параметры поиска.

3. Иногда помочь тестировщику.
Юзкейс может использовать тестировщик, когда проверяет готовую задачу. В этом случае use case — это классический тест-кейс. Тестировщик идёт по нему, и если что-то в продукте работает не так, как описано, пишет в баг-репорте: ожидаемое действие такое, фактическое — другое. В документе он ссылается на юзкейс.

Как системные аналитики пишут use case

Допустим, аналитик пришёл в команду, которая разрабатывает приложение для такси. Разработка use case пройдёт в несколько этапов:

1. Сбор информации

Перед тем как писать use case, аналитик должен собрать:

● требования того, что хочет получить бизнес;

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

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

Пользовательские требования бизнес-аналитик и системный аналитик формируют вместе. Если аналитиков на проекте нет, то эта задача может лечь на менеджера проекта или UX/UI-дизайнера, который глубоко погрузился в тему и проводил исследования с пользователями. Например, выяснил, что люди хотят доехать из точки А в точку В, но им не нравится заказывать такси по телефону.

2. Общая картина в виде диаграммы

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

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

Элементы текстового use case

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

Примеры написания use case

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

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

Вот подробный пример use case для интернет-магазина — новичку лучше начать с такого шаблона.

Use case, из-за которого пользователь не придёт туда, куда нужно

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

Use case, который приведёт к ошибкам в разработке

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

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

Правила написания use case и несколько советов, как сделать его лучше

● Читать теорию. Новичкам стоит начать с книги Карла Вигерса «Разработка требований к программному обеспечению» — это библия системного аналитика. По шаблонам из этой книги учат в Практикуме и других школах. Принципы Вигерса используют в компаниях в России и по всему миру.

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

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

● Развивать насмотренность. Художники и дизайнеры постоянно смотрят чужие работы, чтобы развиваться. То же самое полезно делать и начинающим системным аналитикам — вбивать в поисковую строку «Use case варианты и примеры» и смотреть как можно больше чужих юзкейсов.
● Писать юзкейсы по другим продуктам. Если аналитик видел аналогичный продукт или функциональность, полезно зайти в этот сервис, пройти путь пользователя и составить по нему юзкейс. Так можно получить важные подсказки по проекту.

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

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

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

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

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

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

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

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

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

Сценарии использования включают в себя следующие разделы: 

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

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

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

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

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

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

1. Система выводит информер  с указанием запрещенных символов.

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Без технической душноты исследуем сценарии «пользователь <—> система». Для продактов, дизайнеров и аналитиков — оставили готовый шаблон

Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.

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

Польза юзкейсов — единое представление о продукте

Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:

Сценарии юзкейсов — как игра в теннис между пользователем и системой

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

Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.

Для наглядности юзкейс можно сравнить с игрой в теннис, где один игрок это пользователь, другой — система. Удар ракеткой это действие, которое совершает пользователь, после чего мяч переходит системе, и далее система ему отвечает. Разница только в том, что в юзкейсе пользователь или система могут подряд совершить несколько действий.

«Основной юзкейс» — сценарий успеха: участники + действия + результат + доп. условия

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

Основные элементы юзкейса:

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

2. Действующие лица или участники. Можно выделить такие варианты:

3. Описание последовательности действий в виде сценария.

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

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

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

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

«Альтернативный юзкейс» — сценарий ошибки

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

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

Чеклист для написания юзкейсов

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

Вначале сделайте единый шаблон и заведите словарь

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

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

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

Советы, которые ускорят написание юзкейсов:

Так нужен ли вам юзкейс?

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

Всем крутых продуктов!

Ната Нефедьева

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

  Диаграммы вариантов использования UML являются основной формой требований к системе/программному обеспечению для новых разрабатываемых программ. Цель диаграммы прецедентов — визуализировать, что система должна делать (что); на данном этапе не рассматривает, как (как) это сделать.

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

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

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

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

  • Укажите контекст системы
  • Зафиксируйте требования системы
  • Проверить архитектуру системы
  • Управляйте внедрением и создавайте тестовые примеры
  • Совместная разработка аналитиками, экспертами в предметной области и целевыми конечными пользователями

  Стандартная форма диаграммы прецедентов определена в унифицированном языке моделирования, как показано в примере диаграммы прецедентов ниже.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  Актеры

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

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

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

  Люди против нечеловеческих актеров

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

  Первичные и второстепенные актеры

  A primary actor is an actor that uses the system to achieve a goal. Use cases document the interactions between the system and actors to achieve the goals of the primary actor. Secondary actors are the actors that the system needs to assist in order to achieve the goals of the primary actor.

  • Actors may be primary or secondary. Primary actors initiate interactions with the system.
  • Secondary actors are typically called upon by the system for help and a secondary actor never initiates the use case.

  Note that: The symbol for an actor does not differentiate between a primary actor and a secondary actor; the difference must be inferred from the use case descriptions (also called use case narratives).

  For Example:

  A bank loan officer wants to review a customer’s loan application, and part of the process involves a real-time credit rating check.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  • Используйте имя дела. Рассмотреть заявку на кредит
  • Главный актер. Кредитный специалист
  • Второстепенный актер. Система кредитного рейтинга

  Как определить актеров?

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

  • Кто будет использовать систему после ее разработки?
  • От кого или от каких других систем система должна будет получать данные?
  • Для кого или для каких других систем система будет предоставлять данные?
  • С какими другими системами будет связана система?
  • Кто будет поддерживать и администрировать систему?

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

  • Оператор несет ответственность за техническое обслуживание и управление системой банкоматов.
  • Банкоматы также должны взаимодействовать с внутренними серверами для получения информации об учетных записях пользователей.

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

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

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

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

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

  • Почему актеры используют систему?
  • Создает ли участник, изменяет, удаляет, получает доступ и хранит данные в системе? Если да, то как актор выполняет эти операции?
  • Уведомляет ли актор систему об определенных внешних событиях?
  • Уведомляет ли система актора об определенных внутренних событиях?

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

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

  Системная граница

  Границы системы описывают систему, группируя варианты использования в прямоугольные границы, а границы системы в Visual Paradigm обеспечивают поведение ограничения вариантов использования.

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

  Обратите внимание, что: 

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

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

  Отношение

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

  Вариант использования можно разбить на несколько вариантов использования, которые связаны отношениями <<включить>>, <<расширить>> или <<обобщить>> (описано далее в этом посте).

  Связь канала связи

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  <<Включить>> Связь

  Отношение включения означает, что вариант использования будет включать в себя другие варианты использования. Цель Include Relationship состоит в том, чтобы использовать Include Relationship, чтобы уменьшить повторение повторного описания одного и того же варианта использования. Если во многих прецедентах используется одна и та же функция части, то функция может быть выделена, а другие прецеденты могут быть включены в прецедент.

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  <<Расширить>> отношения

  Если вариант использования B расширяет другой вариант использования A, то реализация A может условно включать реализацию B для выполнения своей задачи. То есть в некоторых случаях А может выполнить свою задачу без В. Однако в зависимости от описанных условий А может потребовать В. В этом случае В зависит от В. Однако в зависимости от описанных условий А может потребовать В В этом случае В зависит от А и не может существовать отдельно. По этой причине B нельзя распространить более чем на один вариант использования. Описание варианта использования A будет включать этапы выполнения, требуемые от B; эта точка называется точкой расширения.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  Отношение обобщения

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

  Например, в системе бронирования есть два типа методов бронирования: «забронировать билет по телефону» и «забронировать билет через Интернет», а также базовый вариант использования «забронировать билет», поэтому вы можете использовать обобщение для формирования случая, и добавьте <<essential>> к родительскому варианту использования (бронирование), чтобы указать обобщенную связь.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

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

  Вариант использования — поток событий

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

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

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

  Например, кейс «Снятие денег» в банкомате можно представить потоком событий следующим образом:

  Обычный сценарий – вывод средств – основной ход событий:

  1. Пользователь вставляет кредитную карту
  2. Введите PIN-код
  3. Введите сумму вывода
  4. Снимает наличные
  5. Выйдите из системы и получите кредитную карту

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

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

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

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

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

  Снятие – альтернативные процессы событий.

  1. Альтернативный сценарий I: Пользователь может отказаться на любом шаге основного процесса и перейти к шагу 5 основного процесса.
  2. Альтернативный процесс II: на шаге 1 основного процесса пользователь вставляет недействительную кредитную карту, система отображает ошибку и закрывает кредитную карту, и вариант использования заканчивается.
  3. Альтернативный процесс III: на шаге 2 основного процесса пользователь вводит неверный пароль, система отображает ошибку и предлагает пользователю повторно ввести пароль и вернуться к шагу 2 основного процесса; после трех неправильных вводов пароля кредитная карта конфискуется системой, и вариант использования заканчивается.
  4. …

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

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

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

  Модель вариантов использования состоит из диаграммы вариантов использования и подробного описания каждого варианта использования, спецификации варианта использования, которая предоставляется в виде шаблона в RUP.

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

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

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

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

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

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

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

  Например:

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

  Используйте инструменты кейса

  Онлайн-версия

  Бесплатная версия бесплатного инструмента для рисования Visual Paradigm Online (VP Online) поддерживает UML, ERD и организационные диаграммы. Вы можете быстро нарисовать диаграммы вариантов использования с помощью интуитивно понятного редактора чертежей UML. В этом бесплатном инструменте UML нет рекламы, нет ограниченного периода доступа и нет ограничений, таких как количество диаграмм, количество фигур и т. д. Рисуйте UML свободно. Рисуйте UML свободно. вам принадлежат диаграммы, которые вы создаете для личных и некоммерческих целей.

  Настольная версия

  Версия Visual Paradigm Community Edition , доступная с 2004 года, предоставляет бесплатное программное обеспечение UML только для некоммерческих целей, поддерживая пользователей, которые делают первые шаги в моделировании UML, а также тех, кому требуется бесплатное кроссплатформенное программное обеспечение для моделирования UML для личное использование, например применение UML в студенческих проектах.

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

  • Что такое диаграмма вариантов использования?
  • Типы актеров в модели вариантов использования
  • Определите требования пользователя с помощью диаграмм вариантов использования
  • Что такое спецификация варианта использования?
  • История пользователя и вариант использования для гибкой разработки программного обеспечения
  • Используйте подход, основанный на прецедентах, для гибкой разработки

  UML-ресурсы

  • Что такое УМЛ?
  • Почему UML-моделирование?
  • Обзор 14 типов диаграмм UML

Прочитали Савина? Помните, что «баги — это несоответствие ТЗ»? А теперь окунитесь в реальность — полноценного технического задания (ТЗ) не существует. Это миф. Не получится прийти на работу, поставить аватарку в JIRA и сказать: «Тестировать буду только по ТЗ, пока отдыхаю». ТЗ не будет.

Если компания:

маленькая — ТЗ нет вообще, все в головах разработчиков;

большая — ТЗ есть и много, но актуально процентов на 15.

Хорошо, когда есть небольшая инфостильная документация, которую заботливо написал внятный трезвый аналитик. Но мы рассматриваем ситуацию, когда ее нет. Что делать? Писать!

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

Что делать? Общаться с носителями знаний и записывать результат. Да, самому. Нет, не надорветесь.

Хочешь ТЗ и волшебные замки? Построй их сам

Есть несколько вариантов записи требований:

— диаграмма состояний и переходов;

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

— любовные записки;

— …

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

• вариант — основной позитивный тест;

• каждая альтернатива — негативный тест;

• каждый параметр — дополнительный позитивный тест.

Тестировщики выбирают варианты! Давайте посмотрим, как это делать.

1. Найдите пользователя и цель, опишите сценарий

Для кого сделан функционал? Системы не делают ради систем.

Мы хотим, чтобы пользователь:

— сделал заказ;

— заплатил налоги;

— посмотрел на котика;

— прочитал блог-пост;

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

Чтобы написать вариант, надо подумать о будущем пользователе. Зачем он к нам придет? Что будет делать и как?

Пример с магазином. Основной сценарий.

Цель пользователя магазина — увидеть ЕГО и купить

СИ01. Найти товар и сделать покупку

1. Юзер открывает список товаров и фильтрует по категории.

2. Система отображает товары выбранной категории.

3. Юзер видит интересный товар и переходит на его карточку.

4. Система отображает карточку товара, оценку покупателей и отзывы.

5. Юзер изучает товар и кладет его в корзину.

6. Система добавляет товар в корзину.

7. Юзер переходит в корзину и оформляет заказ.

8. Система сохраняет заказ, отправляет уведомление по email.

СИ01 → Сценарий использования № 1

2. Продумайте альтернативы

Альтернативные сценарии — это отклонения от основной ветки. Даже типовой установщик Windows “Нажми Далее-Далее-Далее-Профит!” позволяет свернуть с основного сценария. Пользователь на каждом шаге может передумать и нажать “Назад”, или вообще отменить установку.

Нас такие альтернативы мало интересуют, иначе их было бы слишком много. Пользователь

— передумал покупать юбку;

— платье тоже передумал покупать;

— отменил все на этапе фильтрации товаров;

— отменил все, находясь в корзине;

— открыл в соседней вкладке bash.org;

— пошел налить чай;

— наклонился погладить кота;

— обожрался вкусняшек;

Не забываем о системе и внешних условиях:

— Внутренний сбой программы на любом этапе.

— Компьютер сдох. Сценарий завершился.

— Кот уронил сладкий кофе на клавиатуру.

— Уборщица шваброй выдернула сервер из розетки.

— На сервер упал метеорит.

— …

Да, это все возможно, но описывать бессмысленно. Получаем километровый текст, который никто не читает. Нужно вычленить те альтернативы, которые не “П передумал и закрыл браузер”. Сбой системы имеет смысл только тогда, когда система умеет находить выход из такой ситуации без потери данных и это действительно важно описать и проверить.

Итого, думаем, какие могут быть отклонения от основного сценария и записываем их по следующим правилам:

1. Альтернатива ссылается на основной сценарий. То есть пункт «2а» означает, что это отклонение от пункта «2» основного сценария. Сам пункт 2 копипастить не надо.

2. В альтернативах всегда надо писать, чем они заканчиваются. Это «Завершение сценария» или «Переход к шагу 7». Помните школу и программы на Basic? IF … GOTO 2 (возвращаемся к шагу 2 и все повторяем)

Пример с магазином. Альтернативы.

1а. Юзер фильтрует список по несуществующей категории. Система выдает ошибку. Завершение сценария.

2а. Товаров не найдено. Вывод сообщения об ошибке. Завершение сценария.

2б. Товаров слишком много. Система выводит первые 100 и предлагает сузить поиск.

5а. Юзер возвращается к покупкам. Переход к шагу 1.

3. Выделите параметры

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

Например, открыть файл в блокноте можно как?

— даблклик по файлу;

— «File — Open» в блокноте;

— горячими клавишами.

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

Параметры выглядят так:

название: значение 1, значение 2, значение 3

Без привязки к конкретному пункту сценария.

Запомните:

Альтернатива — это когда  ВМЕСТО исходного события происходит другое.

А параметры — это когда В ОДНОМ И ТОМ ЖЕ событии есть несколько вариаций, как его совершить.

Таким образом, параметр в одно значение бесполезен:

Способ оформления заказа: кнопка «Оформить заказ».

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

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

Время хранения файла в системе: 2 часа с момента обработки файла.

Пример с магазином. Параметры

Категории товаров: платья, джинсы, свитера.

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

4. Соберите все вместе

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

Читать удобнее именно в формате:

— основной вариант;

— альтернативы со ссылками на него;

— возможные параметры и особенности реализации.

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

Я к такому написанию уже привыкла, поэтому соберу вариант вместе с ним.

СИ01. Найти товар и сделать покупку


Легенда

П — пользователь

С — система

Сценарий использования

1. П открывает список товаров и фильтрует по категории.

2. С отображает товары выбранной категории.

3. П видит интересный товар и переходит на его карточку.

4. С отображает карточку товара, оценку покупателей и отзывы.

5. П изучает товар и кладет его в корзину.

6. С добавляет товар в корзину.

7. П переходит в корзину и оформляет заказ.

8. С сохраняет заказ, отправляет уведомление по email.

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

1а. П фильтрует список по несуществующей категории. Система выдает ошибку. Завершение сценария.

2а. Товаров не найдено. Вывод сообщения об ошибке. Завершение сценария.

2б. Товаров слишком много. Система выводит первые 100 и предлагает сузить поиск.

5а. П возвращается к покупкам. Переход к шагу 1.

Параметры

Категории товаров: платья, джинсы, свитера.

Время хранения товара в резерве: 2 часа с момента добавления в корзину.

Коберн предлагает до самого варианта расписать:

— основное действующее лицо;

— область действия;

— уровень;

— участники и интересы;

— предусловие;

— минимальные гарантии успеха;

— максимальные гарантии успеха

— …

Вы уже уснули? Вот и я засыпаю. Это как шаблон тест-плана по RUP — вроде все правильно, но сто-о-о-о-олько текста. Который никто не читает.

Текст, кому ты нужен?

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

Я устала от текста слева на 5 строке. А справа прочитала за минуту. Делайте выводы


См также:
Сила примера — после варианта, альтернатив, параметров… Не забудьте про пример!

Типовые ошибки

Напоследок хочу рассказать несколько типовых ошибок, которые допускают тестировщики, впервые описывая варианты:

1. Вариант начинает система

Инициирует сценарий всегда человек, убирайте сразу фразы вида

С предоставила П возможность выбора…

Пишите о действиях, не о статическом состоянии.

2. Система — ванга-терминатор

В домашних заданиях студентов часто вижу что-то типа:
1. Пользователь выбирает файл

2. Система отображает окно выбора файла

Итак, я пользователь, я открываю папку с файлами, рассматриваю их и думаю «ага, надо залить вот этот», мысленно выбрала. И ВДРУГ открывается сайт системы и начинает что-то делать!!!!

Терминатор отдыхает Я лично побоялась бы такого сайта ))) Но, может, система не такая страшная и пользователь все таки что-то делает?

3. Внутренний сбой везде и всюду

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

4. Действие по устранению вместо самой альтернативы

6. Тут было что-то умное

Не бойтесь действовать!

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

Как написать вариант:

1. Найти пользователя и цель.

2. Записать основной сценарий.

3. Продумать альтернативы.

4. Выделить параметры

5. Навести красоту.

6. Проверить в Главреде на стоп-слова.

7. Выкинуть лишнее.

NB: For the purpose of this question, alternate scenarios are scenarios that aside from the main scenario also lead to the completion of the user goal; exceptional scenario are scenarios that do not lead to the completion of the user goal.

I’ve been having a conversation with my professor regarding one of his statements in class. He claims that «extend» should be used to model use cases that derives from exceptional scenarios. As an example:

(UC1: Publish blog post)
  ^
   
    -- <<extend>> -- (UC2: Error, empty blog post)

At this point given the definition of use case:

A use case is a set of scenarios (sequences of steps) that aim at accomplishing a end-goal for an user (actor).

I’m a little confused. If the error is a use case, what end-goal is it aiming at accomplishing? Does a user access the system to see the error message as an end-goal?

I’ve also went ahead and read about «extend» on the internet and I can’t seem to find an example where the extension use case is an actual use case according to that definition. For example here we are given:

(UC1: Deposit funds)
  ^
   
    -- <<extend>> -- (UC2: Calculate bonus)

Again, what user end-goal is «Calculate bonus» trying to achieve? It almost seems as by definition, something that is only triggered by another case in certain situations cannot be considered a «use case» because it’s not an end-goal.

Where am I wrong?

NB: For the purpose of this question, alternate scenarios are scenarios that aside from the main scenario also lead to the completion of the user goal; exceptional scenario are scenarios that do not lead to the completion of the user goal.

I’ve been having a conversation with my professor regarding one of his statements in class. He claims that «extend» should be used to model use cases that derives from exceptional scenarios. As an example:

(UC1: Publish blog post)
  ^
   
    -- <<extend>> -- (UC2: Error, empty blog post)

At this point given the definition of use case:

A use case is a set of scenarios (sequences of steps) that aim at accomplishing a end-goal for an user (actor).

I’m a little confused. If the error is a use case, what end-goal is it aiming at accomplishing? Does a user access the system to see the error message as an end-goal?

I’ve also went ahead and read about «extend» on the internet and I can’t seem to find an example where the extension use case is an actual use case according to that definition. For example here we are given:

(UC1: Deposit funds)
  ^
   
    -- <<extend>> -- (UC2: Calculate bonus)

Again, what user end-goal is «Calculate bonus» trying to achieve? It almost seems as by definition, something that is only triggered by another case in certain situations cannot be considered a «use case» because it’s not an end-goal.

Where am I wrong?

• Что такое юзкейс
• Из чего состоит
• Как написать
• Пример
• Диаграммы
• Польза для команды

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

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

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

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

• покупка товара в магазине (Покупатель – Продавец);
• отправка письма по электронной почте (Отправитель – Почтовый клиент);
• запрос страницы браузером (браузер – веб-сервер).

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

• Актор (actor) — тот, кто использует систему. Если взять за пример онлайн-магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи.
• Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто-то, получающий выгоду от функционирования системы. В случае с онлайн-магазином это может быть партнер — платежная платформа.
• Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн-магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн-платформе.
• Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования.
• Триггеры — события, запускающие юзкейс.
• Успешный сценарий — юзкейс, при котором все идет по плану, без ошибок и неожиданностей.
• Альтернативные пути — вариации основного успешного сценария на случай, если что-то пойдет не так на уровне системы.

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

1. Определите, кто будет использовать сайт.
2. Выберите одного из этих пользователей.
3. Определите, что этот пользователь хочет делать на сайте. Все, что пользователь делает на сайте, становится юзкейсом.
4. Для каждого use case определите нормальный ход событий.
5. Опишите основной путь пользователя: что именно делает пользователь и каков ожидаемый ответ системы.
6. Далее рассмотрите альтернативные варианты развития событий и добавьте их, чтобы «расширить» use case.
7. Повторите шаги 2-6 для всех остальных пользователей.

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Юзкейс-диаграммы

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

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

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

1. Заказчики

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

1. Разработчики

В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим.

1. Тестировщики

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки,  которые сложно найти, например, при юнит-тестировании.