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

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

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

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

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

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

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

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

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

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

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

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

С чего начать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание инфраструктуры классов – 1ч
Формирование окна – 2ч
Вывод списка документов по ключевой фразе – 1ч
Вывод списка документов с учётом даты создания – 1ч
Вывод списка документов с учётом архивных – 1 ч
Прописывание выбранного документа в свойства объекта – 1ч
Тестирование 4 * 0,5ч = 2ч
Итого: 9 ч

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

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

Итоги

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

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

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

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

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

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

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

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

Пояснения к примеру Вводные элементы

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

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

Заинтересованные лица и их потребности

Этот
список играет важную роль. С его помощью
можно понять, что должна делать система.
Приведем цитату: «Система реализует
соглашение между заинтересованными
лицами. Пове­дение системы описывается
с помощью прецедентов… Прецедент, как
со­глашение о поведении, включает все
возможные аспекты поведения, свя­занные
с удовлетворением запросов заинтересованных
лиц».

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

Предусловия и постусловия

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

Результаты
или постусловия
(postconditions)
– описывают, какие условия обяза­тельно
должны выполняться в случае успешного
завершения сценария. Эти ре­зультаты
должны удовлетворять интересам всех
заинтересованных лиц.

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

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

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

В разделе основного сценария описываются
три вида действий:

1. Взаимодействие
   между исполнителями.²

2. Верификация (обычно со стороны системы).

3. Изменение
   состояния системы (например, запись
   или модификация неко­торых сущностей).

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

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

Расширения (или альтернативные потоки)

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

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

Соседние файлы в папке Лаб.работы

• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Федеральное
государственное бюджетное образовательное
учреждение

высшего
профессионального образования

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

имени
академика Д.Н. Прянишникова»

направление
230700 «Прикладная информатика»

Лабораторное
занятие № 4

Тема:
Модель
прецедентов: описание прецедентов

Учебные
вопросы:

1. Задачи
   и описание.

2. Типы
   и форматы прецедентов.

3. Задачи
   и рамки прецедента.
   

В
контексте UP
модель
прецедентов
(Use—Case
Model)
относится к дисцип­лине «Требования«.

Требования
– это
весь набор прецедентов, т.е. модель
функционирования системы и ее окружения.

Введем
некоторые неформальные определения.

У
потребителей
и конечных
пользователей
есть свои задачи (которые в контексте
UP
называют потребностями),
решение которых должна обеспечить
компьютер­ная система.

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

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

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

Сценарий
(scenario)
– это
специальная последовательность действий
или взаимодействий между исполнителями
и системой. Его иногда также называют
экземпляром
прецедента
(use
case
instance).
Это один конкретный сценарий ис­пользования
системы либо один проход прецедента,
например, сценарий успеш­ной покупки
товаров за наличный расчет, либо сценарий
неудачного завершения покупки из-за
прерванной транзакции по обработке
данных кредитной карточки.

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

Описания
прецедентов – это
текстовые документы, а не диаграммы.
Моде­лирование прецедентов
– это
процесс написания текста, а не рисования.
Однако для иллюстрации имен прецедентов
и исполнителей, а также их взаимоотноше­ний
в UML
определены обозначения для диаграммы
прецедентов.

Прецеденты типа
«черный ящик» и системные обязанности

Прецеденты
типа «черный ящик»
(black—box
use
cases)
– это
самый типич­ный и рекомендуемый тип
прецедентов. Они не описывают внутреннюю
работу системы, ее компоненты или дизайн.
Наоборот, системе вменяются некоторые
обязанности
(responsibilities).
Этот метафорический термин широко
применяет­ся в объектно-ориентированном
проектировании: программные элементы
имеют обязанности и взаимодействуют с
другими элементами со своими обязанностями.

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

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

• Сжатый
  – аннотация
  в виде одного абзаца. Обычно она описывает
  только главный успешный сценарий.
  Пример такого описания приведен выше
  для прецедента Обработка
  продажи (Process
  Sale).

Сжатый
формат описания прецедента
Обработка продажи (process
sale).

Покупатель
подходит к кассе с вы­бранными товарами.
Кассир с помощью POS-системы регистрирует
ка­ждый товар. Система отображает
информацию о каждом наименовании товара
и вычисляет общую сумму. Покупатель
вводит требуемую ин­формацию; система
ее верифицирует и регистрирует. Система
выпол­няет инвентаризацию. Покупатель
получает товарный чек и покидает магазин
с покупками.

• Свободный
  – неформальный
  стиль описания. Описание прецедента
  занима­ет несколько абзацев и
  охватывает различные сценарии. Примером
  такого описания является рассмотренный
  выше прецедент Возврат товара.

Свободный
формат пре­цедента
Возврат товара (Handle
Returns),
включающего некоторые альтернативные
сценарии.

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

Покупатель
подходит к кассе с товарами, подлежащими
возврату. Кассир использует POS-систему
для регистрации каждого возвращаемого
товара…

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

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

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

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

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

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

Для
развернутого описания прецедентов
существуют различные шаблоны
форматирования. Однако чаще всего
используется шаблон, приведенный на
Web-узле www.usecases
.org.
Рассмотрим
пример развернутого описания прецедента
Оформление
продажи
для POS-системы
«ТТ».

Основной
исполнитель.
Кассир.

Заинтересованные
лица и их требования:

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

• Продавец.
  Хочет получить свои комиссионные от
  продажи
  

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

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

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

Предусловия.
Кассир
идентифицирован и аутентифицирован.

Результаты
(Постусловия). Данные
о продаже сохранены. Налоги корректно
вычислены, Бухгал­терские и складские
данные обновлены. Комиссионные начислены.
Чек сгенерирован. Авторизация платежа
выполнена.

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

1. Покупатель
   подходит к кассовому аппарату POS-системы
   с выбранными товарами.

2. Кассир
   открывает новую продажу.

3. Кассир
   вводит идентификатор товара.

4. Система
   записывает наименование товара и выдает
   его описание, цену и общую «стоимость.
   Цена вычисляется на основе набора
   правил.

Кассир
повторяет действия, описанные в п.п.
3-4, для каждого наименования товара.

1. Система
   вычисляет общую стоимость покупки с
   налогом.

2. Кассир
   сообщает покупателю общую стоимость
   и предлагает оплатить покупку.

3. Покупатель
   оплачивает покупку, система обрабатывает
   платеж.

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

5. Система
   выдает товарный чек.

6. Покупатель
   покидает магазин с чеком и товарами
   (если он что-то купил).

Расширения
(или альтернативные потоки)

*а. При каждом
выходе системы из строя.

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

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

2.
Система восстанавливает предыдущее
состояние.

2а.
Система определяет аномалию, повлекшую
сбой.

1. Система уведомляет
   об ошибке кассира, регистрирует ошибку
   и переходит в началь­ное состояние.

2. Кассир
   начинает новую продажу.

За. Неправильный
идентификатор.

1.
Система уведомляет об ошибке и отменяет
ввод данного наименования товара.

3б. В рамках одной
категории существует несколько различных
наименований товара, и идентифи­цировать
конкретное наименование не нужно
(например, 5 пакетов леденцов).

1. Кассир может ввести идентификатор
категории товара и количество единиц.

3в. Покупатель
просит кассира отменить покупку одного
из товаров.

1.
Кассир вводит идентификатор товара для
удаления из продажи.

2.
Система отображает обновленную
промежуточную стоимость.

3г.
Покупатель просит кассира отменить
продажу.

1.
Кассир отменяет продажу.

3д.
Кассир приостанавливает продажу.

1.
Система записывает сведения о продаже
таким образом, чтобы они были доступны
с любого терминала POS-системы.

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

1. Кассир
   вводит команду об изменении цены.

2. Система
   вычисляет новую цену.

5а. Система выявляет
сбой при коммуникации с внешней службой
вычисления налога.

1.
Система перезапускает службу с данного
узла POS-системы и продолжает работу.

1а.
Система определяет, что служба не
перезапускается.

1. Система
   сигнализирует об ошибке.

2. Кассир
   может вручную вычислить и ввести сумму
   налога либо отменить продажу.

5б. Покупатель сообщает о положенной
ему скидке (например, для сотрудников
данного предпри­ятия или постоянных
покупателей).

1. Кассир
   отправляет запрос на скидку.

2. Кассир
   вводит идентификационные данные
   покупателя.

3. Система
   представляет сумму скидки, вычисленную
   на основе дисконтных правил.

5в. Покупатель сообщает об открытом
в данном магазине кредите на фиксированную
сумму и просит оформить продажу с его
помощью.

1. Кассир
   отправляет запрос на оформление платежа
   с использованием открытого кредита,

2. Кассир
   вводит идентификационную информацию
   о покупателе.

3. Система
   снижает стоимость покупки (вплоть до
   0) и уменьшает оставшуюся сумму кредита.

6. Покупатель сообщает, что хочет
оплатить покупку наличными, но у него
недостаточно денег.

1
а. Покупатель использует альтернативный
способ платежа.

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

7а.
Оплата наличными.

1. Кассир
   вводит предложенную покупателем сумму.

2. Система
   вычисляет положенную сдачу и открывает
   кассу с наличностью.

3. Кассир
   складывает поученные деньги и выдает
   сдачу покупателю.

4. Система
   регистрирует платеж наличными.

7б.
Оплата по кредитной карточке.

1.
Покупатель вводит информацию о своей
кредитной карточке.

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

2а.
Система определяет сбой при взаимодействии
с внешней системой.

1. Система
   сигнализирует об ошибке кассиру.

2. Кассир
   просит покупателя изменить тип платежа.

3.
Система получает информацию о подтверждении
платежа и сообщает об этом кассиру.

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

1. Система
   сообщает об отказе кассиру.

2. Кассир
   просит покупателя изменить тип платежа.

4.
Система регистрирует платеж по кредитной
карточке, включая информацию о
подтверждении платежа.

5.
Система предоставляет механизм ввода
подписи для платежа по кредитной
карточке.

6.
Кассир просит покупателя подписать чек
на оплату по кредитной карточке,
Покупатель вводит подпись.

7в. Оплата чеком.

7г. Оплата по
дебитной карточке.

7д.
Покупатель предоставляет купоны.

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

1а.
Купон действует не для всех выбранных
товаров,

1.
Система сигнализирует об ошибке кассиру.

9а. Генерация чека.

1.Система
выводит формы и чеки для каждого товара.

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

1.
Кассир вводит запрос на подарочный чек,
и система выдает его.

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

• Сенсорный
  экран с интерфейсом пользователя для
  большого плоского монитора. Текст
  должен быть виден с расстояния один
  метр.

• Отклик
  службы авторизации в 90% случаев приходит
  в течение ЗО секунд.

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

• Возможность
  локализации (представления на различных
  языках) отображаемого текста.

• Возможность
  добавления новых бизнес-правил на шагах
  3 и 7 в процессе функционирования системы.

Список
технологий и типов данных

За.
Идентификатор товара считывается со
штрих-кода (при наличии последнего)
лазерным скане­ром или вводится с
клавиатуры.

3б.
Идентификатор товара может определяться
по схемам кодирования UPC,
EAN,
JAN
или SKU.

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

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

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

История

В 1987 г. Ивар Якобсон представляет первую статью о вариантах использования на OOPSLA Конференция 87 года.^[1] Он описывает, как этот метод использовался в Эриксон фиксировать и определять требования к системе, используя текстовые, структурные и визуальное моделирование методы объектно-ориентированного анализа и проектирования.^[2] Первоначально он использовал термины сценарии использования и случай использования — последний прямой перевод его шведского термина användningsfall — но обнаружил, что ни один из этих терминов не звучит естественно по-английски, и в конце концов остановился на вариант использования.^[3]

В 1992 году он соавтор книги. Объектно-ориентированная разработка программного обеспечения — подход, основанный на сценариях использования,^[4] которые заложили основу OOSE метод системной инженерии и помог популяризировать варианты использования для сбора функциональные требования, особенно в разработка программного обеспечения. В 1994 году он издает книгу о вариантах использования и объектно-ориентированных методах, применяемых к бизнес-модели и процесс реорганизации бизнеса.^[5]

В то же время, Грейди Буч и Джеймс Рамбо работать над объединением своих объектно-ориентированный анализ и дизайн методы, Метод Буча и Метод объектного моделирования (OMT) соответственно. В 1995 году к ним присоединился Ивар Якобсон, и вместе они создали Единый язык моделирования (UML), который включает моделирование вариантов использования. UML стандартизирован Группа управления объектами (OMG) в 1997 г.^[6] Джейкобсон, Буч и Рамбо также работают над усовершенствованием Цель процесс разработки программного обеспечения. Результирующий Единый процесс опубликовано в 1999 году и продвигает подход, основанный на вариантах использования.^[7]

С тех пор многие авторы внесли свой вклад в развитие этой техники, в частности: Ларри Константин развивается в 1995 г. в контексте ориентированный на использование дизайн, так называемые «основные варианты использования», которые нацелены на описание намерений пользователя, а не на последовательность действий или сценариев, которые могут ограничивать или искажать дизайн пользовательского интерфейса;^[8] Алистер Кокберн публикует в 2000 г. целевые примеры использования, основанные на текстовых описаниях и табличных спецификациях;^[9] Курт Биттнер и Ян Спенс в 2002 году разработали передовые методы анализа функциональных требований с помощью вариантов использования;^[10] Дин Леффингуэлл и Дон Видриг предлагают применять варианты использования для управления изменениями и взаимодействия с заинтересованными сторонами;^[11] В 2004 году Гуннар Овергаард предложил распространить принципы шаблонов проектирования на сценарии использования.^[12]

В 2011 году Джейкобсон вместе с Яном Спенсом и Куртом Биттнером издает электронную книгу Пример использования 2.0 адаптировать методику к гибкому контексту, обогатить ее дополнительными «фрагментами» вариантов использования и продвигать ее использование на протяжении всего жизненного цикла разработки.^[13] представив обновленный подход на ежегодном IIBA конференция.^[14][15]

Основной принцип

Варианты использования — это метод сбора, моделирования и определения требований к системе.^[10] Вариант использования соответствует набору поведения, которое система может выполнять во взаимодействии со своими действующими лицами, и которое дает наблюдаемый результат, который способствует достижению ее целей. Актеры представляют роль, которую играют пользователи-люди или другие системы во взаимодействии.

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

Согласно Свод знаний программной инженерии (SWEBOK),^[16] варианты использования относятся к основанным на сценариях требование техники, а также модельный анализ техники. Но варианты использования также поддерживают сбор требований на основе повествования, сбор дополнительных требований, системную документацию и приемочное тестирование.^[1]

Вариации

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

• Сценарии использования системы определяют требования к разрабатываемой системе.^[2] В своем подробном описании они идентифицируют не только взаимодействия с акторами, но и сущности, участвующие в обработке. Они являются отправной точкой для дальнейшего анализа моделей и проектной деятельности.
• Сценарии бизнес-использования сосредоточены на бизнес-организации, а не на программной системе. Они используются для определения бизнес-моделей и требований бизнес-процессов в контексте инициатив по реинжинирингу бизнес-процессов.^[5]
• Существенные варианты использования, также называемые абстрактными вариантами использования, описывают потенциальные намерения участников и то, как система их решает, без определения какой-либо последовательности или описания сценария.^[8] Эта практика была разработана с целью поддержки дизайна, ориентированного на пользователя, и предотвращения предвзятого отношения к пользовательскому интерфейсу на ранней стадии спецификации системы.^[7]
• Вариант использования 2.0 адаптирует методику к контексту методов гибкой разработки.^[1] Этот метод обогащает практику сбора требований поддержкой повествований пользовательских историй. Он также предоставляет «срезы» вариантов использования для облегчения инкрементального выявления требований и обеспечения инкрементной реализации.

Объем

Объем варианта использования может определяться предметом и целями:

• Субъект определяет систему, подсистему или компонент, который будет обеспечивать взаимодействие.^[17]
• Цели могут быть структурированы иерархически с учетом уровня организации, заинтересованного в цели (например, компания, отдел, пользователь), и декомпозиции цели пользователя на подцели.^[9] Декомпозиция цели выполняется с точки зрения пользователей и независимо от системы, что отличается от традиционной функциональной декомпозиции.^[10]  

использование

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

• Объектно-ориентированная разработка программного обеспечения (OOSE), как движущий элемент;^[4]
• Единый язык моделирования (UML) как инструмент поведенческого моделирования;^[17]
• Единый процесс разработки программного обеспечения (UP) и его предшественник, IBM Рациональный унифицированный процесс (RUP);^[7]

• предварительная документация спецификация требований к программному обеспечению (SRS), как альтернативная структура для функциональных требований;^[18]
• получение дизайна из требований с использованием объект-контроль-граница подход;^[7]
• и гибкое развитие.^[1][19]

Шаблоны

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

Кокберн стиль

Шаблон, определенный Алистер Кокберн в его книге Написание эффективных сценариев использования был одним из наиболее широко используемых стилей написания сценариев использования.^{[нужна цитата ]}

Объемы проектирования

Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «Объем проектирования», который может быть черным ящиком (внутренние детали скрыты) или белым ящиком (показаны внутренние детали). Доступны пять символов:^[20]

Объем	Значок
Организация (черный ящик)	Заполненный дом
Организация (белый ящик)	Незаполненный дом
Система (черный ящик)	Заполненная коробка
Система (белый ящик)	Незаполненная коробка
Компонент	Винт или болт

Другие авторы иногда называют варианты использования на уровне организации «бизнес-вариантами использования».^[21]

Уровни целей

Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «Уровень цели»;^[22] предпочтительный уровень — «Пользователь-цель» (или в просторечии «уровень моря»^[23]:101).

Иногда при написании текста имя варианта использования, за которым следует альтернативный текстовый символ (!, +, — и т. Д.), Является более кратким и удобным способом обозначения уровней, например оформить заказ!, авторизоваться-.

Полностью одет

Кокберн описывает более подробную структуру варианта использования, но позволяет упростить ее, когда требуется меньше деталей. В его полностью одетом шаблоне варианта использования перечислены следующие поля:^[24]

• Заголовок: «Целевая фраза с активным глаголом, обозначающая цель основного действующего лица»^[25]
• Основной актер
• Цель в контексте
• Объем
• Уровень
• Заинтересованные стороны и интересы
• Предварительное условие
• Минимальные гарантии
• Гарантии успеха
• Спусковой крючок
• Основной сценарий успеха
• Расширения
• Список вариантов технологий и данных

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

Подход Кокберна повлиял на других авторов; например, Александер и Беус-Дукич обобщают шаблон Кокберна «Полностью одетый вариант использования» с программного обеспечения на системы всех видов, со следующими полями, отличными от Кокберна:^[26]

• Варианты сценариев «(возможно, ответвление от основного сценария или возвращение к нему)»
• Исключения, «т.е. исключительные события и их сценарии обработки исключений»

Повседневная

Кокберн признает, что проекты не всегда могут нуждаться в подробных «полностью подготовленных» сценариях использования. Он описывает случайный вариант использования с полями:^[24]

• Название (цель)
• Основной актер
• Объем
• Уровень
• (История): тело варианта использования — это просто параграф или два текста, неформально описывающие происходящее.

Стиль Фаулера

Мартин Фаулер утверждает: «Не существует стандартного способа написания содержимого варианта использования, и разные форматы хорошо работают в разных случаях».^[23]:100 Он описывает «общий стиль использования» следующим образом:^[23]:101

• Заголовок: «цель, которую пытается достичь вариант использования»^[23]:101
• Основной сценарий успеха: пронумерованный список шагов^[23]:101
  • Шаг: «простое изложение взаимодействия между действующим лицом и системой»^[23]:101
• Расширения: отдельно нумерованные списки, по одному на каждое расширение.^[23]:101
  • Расширение: «условие, которое приводит к взаимодействиям, отличным от .. основного сценария успеха». Добавочный номер основного шага 3 имеет номер 3a и т. Д.^[23]:101

Стиль Фаулера также можно рассматривать как упрощенный вариант шаблона Кокберна.

Актеры

Вариант использования определяет взаимодействие между внешними участниками и рассматриваемой системой для достижения цели. Актеры должны уметь принимать решения, но не обязательно должны быть людьми: «Действующим лицом может быть человек, компания или организация, компьютерная программа или компьютерная система — оборудование, программное обеспечение или и то, и другое».^[27] Актеры всегда заинтересованные стороны, но не все заинтересованные стороны являются участниками, поскольку они «никогда не взаимодействуют напрямую с системой, даже если они имеют право заботиться о том, как система ведет себя».^[27] Например, «владельцы системы, совет директоров компании и регулирующие органы, такие как Налоговая служба и Департамент страхования» могут быть заинтересованными сторонами, но вряд ли будут действующими лицами.^[27]

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

Актеры часто работают от имени кого-то другого. Кокберн пишет: «В наши дни я пишу« торговый представитель для клиента »или« клерк для отдела маркетинга », чтобы зафиксировать, что пользователь системы действует для кого-то другого». Это говорит проекту, что «пользовательский интерфейс и допуски безопасности» должны быть разработаны для торгового представителя и клерка, но что роль клиента и отдела маркетинга несут ответственность за результаты.^[28]

Заинтересованная сторона может играть как активную, так и неактивную роль: например, Потребитель является одновременно «покупателем массового рынка» (не взаимодействующим с системой) и пользователем (действующим лицом, активно взаимодействующим с приобретенным продуктом).^[29] В свою очередь, Пользователь является как «обычным оператором» (субъектом, использующим систему по прямому назначению), так и «функциональным бенефициаром» (заинтересованной стороной, получающей выгоду от использования системы).^[29] Например, когда пользователь «Джо» снимает наличные со своего счета, он управляет банкоматом и получает результат от своего имени.

Кокберн советует искать участников среди заинтересованных сторон системы, основных и вспомогательных (вторичных) участников варианта использования, самой разрабатываемой системы (SuD) и, наконец, среди «внутренних участников», а именно компонентов системы. в стадии проектирования.^[27]

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

Точно так же, как вариант использования описывает серию событий и взаимодействий между пользователем (или другим типом действующего лица) и системой, для получения результата (цели), бизнес-вариант использования описывает более общее взаимодействие. между бизнес-системой и пользователями / участниками этой системы для получения ценных бизнес-результатов. Основное отличие состоит в том, что система, рассматриваемая в модели бизнес-варианта использования, может содержать людей в дополнение к технологическим системам. Этих «людей в системе» называют работниками бизнеса. В примере с рестораном необходимо принять решение, относиться ли к каждому человеку как к действующему лицу (т.е. вне системы) или как к бизнес-работнику (внутри системы). Если официант считается актером, как показано в примере ниже, тогда система ресторана не включает официанта, и модель раскрывает взаимодействие между официантом и рестораном. В качестве альтернативы можно было бы рассматривать официанта как часть ресторанной системы (бизнес-работника), а клиента рассматривать как вне системы (актера).^[30]

Визуальное моделирование

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

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

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

Примеры

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

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

Основной актер: Член (Зарегистрированный пользователь)

Объем: а Вики система

Уровень: ! (Пользовательская цель или уровень моря)

Краткий: (эквивалентно история пользователя или эпос)

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

Заинтересованные стороны

…

Постусловия

Минимальные гарантии:

Гарантии успеха:

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

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

Статья с включенным редактированием предоставляется участнику.

Триггеры:

Участник вызывает запрос на редактирование (для всей статьи или только одного раздела) статьи.

Основной поток:

1. Система предоставляет новую область / поле редактора, заполненное всем релевантным содержанием статьи с информативным сводным обзором редактирования, которое может редактировать участник. Если участник просто хочет отредактировать раздел статьи, отображается только исходное содержание раздела, а заголовок раздела автоматически заполняется в сводке редактирования.
2. Участник изменяет содержание статьи до тех пор, пока не будет удовлетворен.
3. Участник заполняет сводку редактирования, сообщает системе, хотят ли они посмотреть эту статью, и отправляет правку.
4. Система сохраняет статью, регистрирует событие редактирования и завершает необходимую постобработку.
5. Система представляет участнику обновленный вид статьи.

Расширения:

2–3.

а. Предварительный просмотр:

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

б. Показать изменения:

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

c. Отменить редактирование:

1. Участник выбирает Отмена.
2. Система отменяет все изменения, внесенные участником, и переходит к шагу 5.

4а. Тайм-аут:

…

Преимущества

С момента зарождения гибкого движения история пользователя техника из Экстремальное программирование был настолько популярен, что многие думают, что это единственное и лучшее решение для гибких требований всех проектов. Алистер Кокберн перечисляет пять причин, по которым он до сих пор пишет сценарии использования в гибкое развитие.^[31]

1. В списке названий целей указаны самый короткий краткое изложение того, что предлагает система (даже чем пользовательские истории ). Он также предоставляет структуру планирования проекта, которую можно использовать для определения начальных приоритетов, оценок, распределения команд и сроков.
2. Основной успешный сценарий каждого варианта использования дает всем участникам согласие относительно того, что система в основном будет делать, а что нет. Он предоставляет контекст для каждого конкретного требования к позиции (например, подробные пользовательские истории), контекст, который очень трудно найти где-либо еще.
3. Условия расширения для каждого варианта использования обеспечивают основу для исследования всех мелочей, которые так или иначе занимают 80% времени и бюджета разработки. Он обеспечивает механизм прогнозирования, поэтому заинтересованные стороны могут выявить проблемы, ответы на которые могут потребовать много времени. Эти проблемы могут и должны быть решены раньше срока, чтобы ответы были готовы, когда команда разработчиков приступит к работе над ними.
4. Фрагменты сценария расширения варианта использования дают ответы на многие подробные, часто сложные и игнорируемые бизнес-вопросы: «Что мы должны делать в этом случае?» Это структура мышления / документации, которая соответствует выражению if … then … else, которое помогает программистам обдумывать проблемы. За исключением того, что это делается во время расследования, а не во время программирования.
5. Полный набор сценариев использования показывает, что исследователи продумали потребности каждого пользователя, каждую цель, которую они преследуют в отношении системы, и каждый задействованный бизнес-вариант.

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

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

Сценарии использования представляют собой мощный ориентированный на пользователя инструмент для процесса разработки требований к программному обеспечению.^[32] Моделирование вариантов использования обычно начинается с определения ролей ключевых заинтересованных сторон (актеры) взаимодействия с системой, и их целей или задач, которые система должна выполнять (внешняя перспектива). Эти пользовательские цели затем становятся идеальными кандидатами для названий или заголовков вариантов использования, которые представляют желаемые функциональные возможности или услуги, предоставляемые системой. Этот ориентированный на пользователя подход гарантирует, что разрабатывается то, что имеет реальную ценность для бизнеса и действительно нужно пользователю, а не те тривиальные функции, которые предполагаются с точки зрения разработчика или системы (изнутри).

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

Лучшее общение

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

Требования к качеству при структурированной разведке

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

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

Упрощение тестирования и пользовательской документации

С контентом, основанным на структуре потока действий или событий, модель хорошо написанных сценариев использования также служит отличной основой и ценными руководящими принципами для разработки тестовых примеров и руководств пользователя системы или продукта, что является достойным вложением. аванс. Существует очевидная связь между потоками варианта использования и его тестовыми примерами. Получение функциональных тестовых случаев из варианта использования через его сценарии (запуск экземпляров варианта использования) несложно.^[33]

Ограничения

Ограничения вариантов использования включают:

• Сценарии использования плохо подходят для регистрации требований системы, не связанных с взаимодействием (таких как алгоритм или математические требования) или нефункциональные требования (например, платформа, производительность, время или аспекты безопасности). Их лучше декларативно указать в другом месте.
• Поскольку полностью стандартных определений вариантов использования не существует, каждый проект должен формировать свою собственную интерпретацию.
• Некоторые отношения вариантов использования, например расширяет, неоднозначны в интерпретации и могут быть трудными для понимания заинтересованными сторонами, как указывает Кокберн (Проблема № 6)^{[34][нужна цитата ]}
• Разработчикам сценариев использования часто бывает сложно определить уровень пользовательский интерфейс (UI) зависимость для включения в вариант использования. Хотя теория вариантов использования предполагает, что пользовательский интерфейс не может быть отражен в вариантах использования, может быть неудобно абстрагироваться от этого аспекта дизайна, поскольку это затрудняет визуализацию вариантов использования. В программной инженерии эта трудность решается применением прослеживаемость требований, например, с матрица прослеживаемости. Другой подход к связыванию элементов пользовательского интерфейса с вариантами использования — это прикрепление дизайна пользовательского интерфейса к каждому этапу варианта использования. Это называется раскадровкой варианта использования.
• Сценарии использования можно переоценить. Бертран Мейер обсуждает такие вопросы, как слишком прямое управление проектированием системы, исходя из вариантов использования, и использование вариантов использования, исключая другие потенциально ценные методы анализа требований.^[35]
• Сценарии использования являются отправной точкой для разработки тестов,^[36] но поскольку для каждого теста нужны собственные критерии успеха, может потребоваться изменить варианты использования, чтобы обеспечить отдельные постусловия для каждого пути.^[37]
• Хотя варианты использования включают цели и контексты, независимо от того, конфликтуют ли эти цели и мотивы, стоящие за целями (проблемы заинтересованных сторон и их оценки, включая отсутствие взаимодействия), или отрицательно / положительно влияют на другие цели системы, они являются предметом целенаправленных методов моделирования требований (таких как BMM, Я*, КАОС и ArchiMate БРОНЯ).

Заблуждения

Эта секция нуждается в расширении. Вы можете помочь добавляя к этому. (Июль 2015 г.)

Распространенные заблуждения о вариантах использования:

Истории пользователей подвижны; варианты использования — нет.

Agile и Scrum нейтральны по требованиям техники. Как Scrum Primer^[38] состояния,

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

Методы использования прецедентов эволюционировали, чтобы учесть подходы Agile за счет использования фрагментов прецедентов для постепенного обогащения прецедентов.^[13]

Варианты использования — это в основном диаграммы.

Крейг Ларман подчеркивает, что «варианты использования — это не диаграммы, это текст».^[39]

В вариантах использования слишком много контента, связанного с пользовательским интерфейсом.

Как говорят некоторые,

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

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

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

Написание сценариев использования для больших систем утомительно и пустая трата времени.

Как говорят некоторые,

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

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

Фактически, форматы вариантов использования, сформулированные эти популярные стили шаблонов, например RUP и Cockburn (также принятые метод ОУМ ) и т. д., зарекомендовали себя на практике как ценные и полезные инструменты для сбора, анализа и документирования сложных требований больших систем. Качество хорошей документации по прецедентам (модель) не следует судить в основном или только по его размеру. Также возможно, что качественная и всеобъемлющая модель варианта использования большой системы может, наконец, превратиться в сотни страниц, главным образом из-за присущей ей сложности проблема в руки, а не из-за плохих навыков письма его авторов.

Инструменты

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

Некоторые из хорошо известных инструментов сценариев использования включают:

• CaseComplete
• Архитектор предприятия
• MagicDraw
• Рациональное программное обеспечение RequisitePro — один из первых широко известных инструментов управления сценариями и требованиями в 1990-х годах.
• Разработчик программных идей
• Программное обеспечение вики — хорошие инструменты для команд для совместной разработки и управления сценариями использования.

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

Смотрите также

• Дело о злоупотреблении
• Бизнес-кейс
• Сущность-контроль-граница
• Разделение событий
• Особенность
• Список инструментов UML
• Случай неправильного использования
• Требование
• Выявление требований
• Сценарий
• Раскадровка
• Прецедент
• Точки использования

Рекомендации

дальнейшее чтение

• Александр, Ян и Беус-Дукич, Лерка. Обнаружение требований: как указать продукты и услуги. Wiley, 2009.
• Александр, Ян, и Дева, Нил. Сценарии, истории, сценарии использования. Wiley 2004.
• Армор, Фрэнк и Грэнвилл Миллер. Расширенное моделирование вариантов использования: программные системы. Аддисон-Уэсли, 2000.
• Курт Биттнер, Ян Спенс, Моделирование вариантов использования, Addison-Wesley Professional, 20 августа 2002 г.
• Кокберн, Алистер. Написание эффективных сценариев использования. Аддисон-Уэсли, 2001.
• Ларри Константин, Люси Локвуд, Программное обеспечение для использования: практическое руководство по основным моделям и методам проектирования, ориентированного на использование, Аддисон-Уэсли, 1999.
• Денни, Ричард. Успешное использование сценариев использования: разумная работа для обеспечения качества. Аддисон-Уэсли, 2005.
• Фаулер, Мартин. UML Distilled (третье издание). Аддисон-Уэсли, 2004.
• Якобсон Ивар, Кристерсон М., Йонссон П., Овергаард Г., Объектно-ориентированная разработка программного обеспечения — подход, основанный на сценариях использования, Аддисон-Уэсли, 1992.
• Якобсон Ивар, Спенс И., Биттнер К. Сценарий использования 2.0: Руководство по достижению успеха с вариантами использования, IJI SA, 2011.
• Дин Леффингуэлл, Дон Видриг, Управление требованиями к программному обеспечению: подход к использованию, Аддисон-Уэсли Профессионал. 7 декабря 2012 г.
• Кулак, Дэрил и Имонн Гини. Примеры использования: требования в контексте. Аддисон-Уэсли, 2012.
• Мейер, Бертран. Построение объектно-ориентированного программного обеспечения. (2-е издание). Прентис Холл, 2000.
• Шнайдер, Джери и Винтерс, Джейсон П. Применение вариантов использования 2-е издание: Практическое руководство. Аддисон-Уэсли, 2001.
• Вазлавик, Рауль С. Объектно-ориентированный анализ и дизайн информационных систем: моделирование с помощью UML, OCL и IFML. Морган Кауфманн, 2014.

внешняя ссылка

• Колонка вариантов использования Алистера Кокберна
• Примеры использования (Usability.gov)
• Базовый шаблон сценария использования Алистер Кокберн
• Применение сценариев использования для анализа заинтересованных сторон «Проект Икар: сценарии заинтересованных сторон для программы межзвездных исследований», JBIS, 64, 224-233
• «Академический обзор роли вариантов использования в UML»
• Поиск варианта использования в IBM developerWorks