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

Очень простая диаграмма вариантов использования системы Wiki . Зарегистрированный пользователь Wiki редактирует статью.

В программной и системной инженерии словосочетание вариант использования является многозначным и имеет два значения :

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

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

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

История

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

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

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

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

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

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

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

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

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

Вариации

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

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

Объем

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

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

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

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

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

Шаблоны

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

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

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

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

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

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

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

Уровни целей

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

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

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

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

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

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

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

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

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

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

Повседневный

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

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

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

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

• Заголовок: «Цель, которую пытается достичь вариант использования»
• Основной сценарий успеха: нумерованный список шагов
  • Шаг: «простая формулировка взаимодействия между актором и системой».
• Расширения: отдельно нумерованные списки, по одному на каждое расширение.
  • Расширение: «состояние, которое приводит к взаимодействиям, отличным от… основного сценария успеха». Расширение основного шага 3 имеет номер 3a и т. д.

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

Алистер Кокберн заявил:

Думайте о пользовательской истории как о сценарии использования с точностью до 2 бит. Бит 1 точности называет цель варианта использования, а бит 2 добавляет основной сценарий. Бит 3 добавляет условия отказа, бит 4 добавляет действия при сбое. Бит 5 добавляет описание данных ввода/вывода. Я бы поставил Катализ на 6-й бит точности, так как они включают в себя еще и модель получателя сообщения. В семействе CrystalMethodology проекты, основанные по-разному, используют варианты с разными уровнями точности. Методологически легкий проект использует пользовательские истории, методологически более тяжелый проект использует варианты использования с точностью до 4 бит, а Catalysis использует точность до 6 бит.

Мартин Фаулер заявил:

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

Актеры

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

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

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

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

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

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

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

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

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

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

Варианты использования — это не только тексты, но и диаграммы, если это необходимо. В Unified Modeling Language отношения между вариантами использования и субъектами представлены в диаграммах вариантов использования, первоначально основанных на Ивара Джейкобсона нотации Objectory . SysML использует ту же нотацию на уровне системного блока.

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

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

Примеры

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

Вариант использования : редактирование статьи.

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

Область применения : Wiki. система

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

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

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

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

...

Постусловия

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

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

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

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

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

Триггеры :

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

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

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

Расширения :

2–3.

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

Заблуждения

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

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

Agile и Scrum нейтральны в отношении методов требований. Как Scrum Primer государства,

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

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

Варианты использования в основном представляют собой диаграммы.

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

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

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

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

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

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

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

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

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

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

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

Инструменты

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

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

• ДелоЗавершено
• Корпоративный архитектор
• МагияНичья
• RequisitePro от Rational Software — один из первых и хорошо известных инструментов управления сценариями использования и требованиями в 1990-х годах.
• Разработчик идей программного обеспечения
• Программное обеспечение Wiki — хорошие инструменты для команд, которые могут совместно создавать сценарии использования и управлять ими.

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

См. также

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

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

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

Внешние ссылки

• Столбец вариантов использования и шаблон базового варианта использования от Алистера Кокберна
• Варианты использования на GSA Usability.gov
• Применение вариантов использования для анализа заинтересованных сторон «Проект Икар» на Academia.edu
• Найдите «вариант использования» на сайте IBM Developer.