Кейс

Кейс (Case) в контексте CPA — описание последовательности определенных действий, при выполнении которых, автор кейса получил профит. Часто кейсом является связка источник-креатив-ПП-оффер.

В программном обеспечении и системной инженерии фраза "прецедент" представляет собой полисемию с двумя значениями:

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

• Потенциальный сценарий, в котором система получает внешний запрос (например, ввод данных пользователем) и отвечает на него.

В этой статье рассматривается последний смысл.

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

История

В 1987 году Ивар Якобсон представил первую статью о случаях использования на конференции OOPSLA'87. Он описал, как этот метод использовался в Ericsson для определения и определения требований к системе с использованием текстовых, структурных и визуальных методов моделирования для управления объектно-ориентированным анализом и проектированием. Первоначально он использовал термины сценарии использования и прецедент – последний является прямым переводом его шведского термина användningsfall – но обнаружил, что ни один из этих терминов не звучит естественно на английском языке, и в конечном итоге он остановился на прецеденте.

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

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

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

В 2011 году Джейкобсон опубликовал вместе с Яном Спенсом и Куртом Биттнером электронную книгу "Вариант использования 2.0", чтобы адаптировать метод к гибкому контексту, обогатив его дополнительными "фрагментами" вариантов использования и продвигая его использование на протяжении всего жизненного цикла разработки после представления обновленного подхода на ежегодной конференции IIBA.

Общий принцип

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

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

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

Вариации

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

• Варианты использования системы определяют требования к разрабатываемой системе. В их подробном описании указываются не только взаимодействия с субъектами, но и сущности, участвующие в обработке. Они являются отправной точкой для дальнейшего анализа моделей и проектной деятельности.
• Бизнес-примеры использования сосредоточены на бизнес - организации, а не на программной системе. Они используются для определения бизнес-моделей и требований к бизнес-процессам в контексте инициатив по реинжинирингу бизнес-процессов.
• Основные варианты использования, также называемые абстрактными вариантами использования, описывают потенциальные намерения участников и то, как система решает эти проблемы, без определения какой-либо последовательности или описания сценария. Эта практика была разработана с целью поддержки ориентированного на пользователя проектирования и предотвращения предвзятого отношения к пользовательскому интерфейсу на ранней стадии спецификаций системы.
• Вариант использования 2.0 адаптирует методику в контексте методов гибкой разработки. Этот метод обогащает практику сбора требований поддержкой повествований пользовательских историй. Он также предоставляет "фрагменты" вариантов использования для облегчения постепенного выявления требований и обеспечения постепенной реализации.

Масштаб

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

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

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

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

1. Объектно-ориентированная программная инженерия (OOSE), как движущий элемент;
2. Унифицированный язык моделирования (UML), как инструмент моделирования поведения;
3. Единый процесс разработки программного обеспечения (UP) и его предшественник, IBM Rational Unified Process (RUP);
4. предварительная документация спецификации требований к программному обеспечению (SRS) в качестве альтернативной структуры для функциональных требований;
5. вывод проекта из требований с использованием подхода "объект-контроль-граница";
6. и гибкая разработка.

Шаблоны

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

Стиль Кокберна

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

Области проектирования

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

Масштаб	Икона
Организация (черный ящик)	Заполненный Дом
Организация (белый ящик)	Незаполненный Дом	Scope-icons-unfilled-house
Система (черный ящик)	Заполненная Коробка	Scope-icons-filled-box
Система (белый ящик)	Незаполненная Коробка	Scope-icons-unfilled-box
Компонент	Шуруп или болт	Scope-icons-screw-bolt

Другие авторы иногда называют варианты использования на уровне организации "Бизнес-варианты использования"[21].

Уровни целей

Иерархия уровней целей

Кокберн предлагает аннотировать каждый вариант использования символом, чтобы показать "Уровень цели"; предпочтительный уровень-"Цель пользователя" (или, в просторечии, "уровень моря

Уровень Цели	Икона	Символ
Очень Высокое Резюме	Облако	++
Краткие сведения	Летающий воздушный змей	+
Цель Пользователя	Волны в море	!
Подфункция	Рыба	-
Слишком Низко	Раковина моллюска морского дна	--

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

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

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

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

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

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

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

Повседневная обувь

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

1. Название (цель)
2. Основной Субъект
3. Масштаб
4. Уровень
5. (История): основная часть прецедента-это просто один или два абзаца текста, неофициально описывающих то, что происходит.

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

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

1. Название: "Цель, которую пытается достичь прецедент"

• Основной сценарий успеха: пронумерованный список шагов
  • Шаг: "простое изложение взаимодействия между субъектом и системой"
• Расширения: отдельно пронумерованные списки, по одному на расширение
  • Расширение: "условие, которое приводит к взаимодействиям, отличным от ... основного сценария успеха". Расширение от основного шага 3 пронумеровано 3a и т. Д.

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

Актеры

Основная статья: Актер (UML)

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

Область применения: Вики-система

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

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

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

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

...

Постусловия

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

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

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

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

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

Раздражители:

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

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

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

Расширения:

2–3.

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

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

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

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

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

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

4a. Время ожидания:

...

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

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

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

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

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

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

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

Лучшая коммуникация

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

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

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

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

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

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

Ограничения

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

• Варианты использования не очень хорошо подходят для учета требований системы, не связанных с взаимодействием (таких как требования к алгоритмам или математическим требованиям), или нефункциональных требований (таких как платформа, производительность, сроки или критические аспекты безопасности). Они лучше указаны декларативно в другом месте.
• Поскольку полностью стандартных определений вариантов использования не существует, каждый проект должен сформировать свою собственную интерпретацию.
• Некоторые отношения вариантов использования, такие как расширения, неоднозначны в интерпретации и могут быть трудны для понимания заинтересованными сторонами, как указывает Кокберн (проблема № 6)
• Разработчикам вариантов использования часто бывает трудно определить уровень зависимости пользовательского интерфейса (UI) для включения в вариант использования. Хотя теория вариантов использования предполагает, что пользовательский интерфейс не должен отражаться в вариантах использования, может быть неудобно абстрагироваться от этого аспекта дизайна, поскольку это затрудняет визуализацию вариантов использования. В программной инженерии эта трудность решается путем применения прослеживаемости требований, например, с помощью матрицы прослеживаемости. Другой подход к связыванию элементов пользовательского интерфейса с вариантами использования заключается в том, чтобы прикреплять дизайн пользовательского интерфейса к каждому шагу в случае использования. Это называется раскадровкой вариантов использования.
• Примеры использования могут быть чрезмерно подчеркнуты. Бертран Мейер обсуждает такие вопросы, как проектирование систем вождения, слишком буквально, исходя из вариантов использования, и использует варианты использования, исключая другие потенциально ценные методы анализа требований.
• Варианты использования являются отправной точкой для разработки тестов, но, поскольку для каждого теста требуются свои собственные критерии успеха, варианты использования, возможно, потребуется изменить, чтобы обеспечить отдельные постусловия для каждого пути.
• Хотя примеры использования включают цели и контексты, независимо от того, конфликтуют ли эти цели и мотивы, стоящие за целями (проблемы заинтересованных сторон и их оценки, включая невзаимодействие), или отрицательно/положительно влияют на другие цели системы, методы моделирования требований, ориентированные на цели (такие как BMM, I*, KAOS и ArchiMate ARMOR).

Заблуждения

Распространенными недоразумениями в отношении вариантов использования являются:

Пользовательские истории гибки, а варианты использования-нет.

Agile и Scrum нейтральны в отношении методов требований. Как говорится в учебнике по Scrum[38] ,

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

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

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

Крейг Ларман подчеркивает, что "варианты использования-это не диаграммы, это текст".

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

Как некоторые выразились,

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

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

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

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

Как некоторые выразились,

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

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

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

Инструменты

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

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

1. Завершение дела
2. Архитектор предприятия
3. Магический рисунок
4. RequisitePro от Rational Software - один из ранних, хорошо известных инструментов управления вариантами использования и требованиями в 1990-х годах.
5. Разработчик программных идей
6. Программное обеспечение Wiki - хорошие инструменты для команд для совместного создания вариантов использования и управления ими.

Большинство инструментов UML поддерживают как написание текста, так и визуальное моделирование вариантов использования.

См.также

Клоака

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