Another word for use case

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

---

Что такое Use Case

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

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

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

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

---

В каких ситуациях может помочь Use Case

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

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

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

---

В чем польза юзеркейса

Качественно составленный Use Case может решать разные задачи. Например:

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

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

---

Из каких элементов состоит Use Case

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

1. Actor — человек, который пользуется созданной системой. В качестве примера можно привести какой-нибудь интернет-магазин, где в качестве actor выступают продавцы, покупатели, поставщики и все те, кто взаимодействует с этим интернет-магазином.
2. Primary actor — это человек, у которого получается достигнуть поставленных целей с помощью созданного программного продукта. Если вернуться к тому же интернет-магазину, то primary actor в нем может быть производитель вещей, у которого получается реализовывать эти вещи с помощью функционала онлайн-площадки.
3. Stakeholder — человек, который заинтересован в том, чтобы созданы ПП выполнял те или иные действия. В интернет-магазине это может быть какой-нибудь партнер, получающий доход от приведенных покупателей, или подключенная к магазину платежная платформа, через которую совершаются онлайн-платежи.

Также к элементам юзеркейса относятся:

• понятный заголовок, содержащий конечный результат Use Case;
• описание последовательности действий;
• результат, к которому должен привести юзеркейс;
• предусловия — это то, что должно произойти до или после запуска кейса;
• триггеры, влияющие на запуск кейса.

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

---

Какими должен качественный быть Use Case

Высокое качество юзеркейса определяют следующие критерии:

1. Правильная детализация. При составлении Use Case нет смысла описывать каждый шаг пользователей и состояние элементов ПП в этот момент. Главная задача юзеркейса — всего лишь дать общую картину.
2. Простота изложения. Чтобы содержимое юзеркейса было понятным даже новым членам команды, его необходимо писать максимально простым языком. Не стоит использовать для Use Case сложные термины и вставки кода.
3. Единый стиль. Старайтесь использовать для всех юзеркейсов один и тот же шаблон. Это поможет сэкономить время на изучении ПП.

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

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

---

Какую пользу несет Use Case для определенных специалистов в команде

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

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

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

---

Как  составить Use Case

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

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

1. В первую очередь определяем, какие пользователи будут работать с программным продуктом. Помочь в этом может обычный анализ рынка и ЦА.
2. Выявляем определенную группу пользователей, которые будут работать с ПП.
3. Рисуем портрет группы пользователей и приблизительно определяем, что они будут делать разрабатываемой программе. Каждое действие в рамках ПП — потенциальный Use Case.
4. Определяем последовательность действий для каждого юзеркейса.
5. Приблизительно описываем основной путь пользователя.
6. Прогнозируем ответ системы на действия пользователя.
7. Разрабатываем альтернативные пути для расширения юзеркейса.
8. Повторяем перечисленные шаги для каждой группы пользователей.

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

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

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

---

Пример 1: регистрация на сайте

Результат кейса: пользователь создает аккаунт с личным кабинетом.

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

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

---

Пример 2: регистрация в интернет-магазине по сложной схеме

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

Шаги юзеркейса выглядят следующим образом:

1. Пользователь нажимает на кнопку регистрации.
2. Система открывает форму регистрации, запрашивает контактные данные и платежные реквизиты.
3. Пользователь заполняет поля, отправляет на проверку.
4. Система проверяет инфу на корректность, вносит пользователя в базу, отправляет письмо со ссылкой активации.
5. Пользователь открывает письмо, переходит по ссылке.
6. Система активирует аккаунт.

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

---

Пример 3: кейс по взаимодействию с сайтом вуза на примере диаграммы

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

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

---

Эксперты отвечают
 

Вывод

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

In software and systems engineering, the phrase use case is a polyseme with two senses:

1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
2. A potential scenario in which a system receives an external request (such as user input) and responds to it.

This article discusses the latter sense.

A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human or another external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.

History[edit]

In 1987, Ivar Jacobson presented the first article on use cases at the OOPSLA’87 conference.^[1] He described how this technique was used at Ericsson to capture and specify requirements of a system using textual, structural, and visual modeling techniques to drive object-oriented analysis and design.^[2] Originally he had used the terms usage scenarios and usage case – the latter a direct translation of his Swedish term användningsfall – but found that neither of these terms sounded natural in English, and eventually he settled on use case.^[3]

In 1992 he co-authored the book Object-Oriented Software Engineering — A Use Case Driven Approach,^[4] which laid the foundation of the OOSE system engineering method and helped to popularize use cases for capturing functional requirements, especially in software development. In 1994 he published a book about use cases and object-oriented techniques applied to business models and business process reengineering.^[5]

At the same time, Grady Booch and James Rumbaugh worked at unifying their object-oriented analysis and design methods, the Booch method and Object Modeling Technique (OMT) respectively. In 1995 Ivar Jacobson joined them and together they created the Unified Modelling Language (UML), which includes use case modeling. UML was standardized by the Object Management Group (OMG) in 1997.^[6] Jacobson, Booch and Rumbaugh also worked on a refinement of the Objectory software development process. The resulting Unified Process was published in 1999 and promoted a use case driven approach.^[7]

Since then, many authors have contributed to the development of the technique, notably: Larry Constantine developed in 1995, in the context of usage-centered design, so called «essential use-cases» that aim to describe user intents rather than sequences of actions or scenarios which might constrain or bias the design of user interface;^[8] Alistair Cockburn published in 2000 a goal-oriented use case practice based on text narratives and tabular specifications;^[9] Kurt Bittner and Ian Spence developed in 2002 advanced practices for analyzing functional requirements with use cases;^[10] Dean Leffingwell and Don Widrig proposed to apply use cases to change management and stakeholder communication activities;^[11] Gunnar Overgaard proposed in 2004 to extend the principles of design patterns to use cases.^[12]

In 2011, Jacobson published with Ian Spence and Kurt Bittner the ebook Use Case 2.0 to adapt the technique to an agile context, enriching it with incremental use case «slices», and promoting its use across the full development lifecycle^[13] after having presented the renewed approach at the annual IIBA conference.^[14][15]

General principle[edit]

Use cases are a technique for capturing, modeling, and specifying the requirements of a system.^[10] A use case corresponds to a set of behaviors that the system may perform in interaction with its actors, and which produces an observable result that contributes to its goals. Actors represent the role that human users or other systems have in the interaction.

In the requirement analysis, at their identification, a use case is named according to the specific user goal that it represents for its primary actor. The case is further detailed with a textual description or with additional graphical models that explain the general sequence of activities and events, as well as variants such as special conditions, exceptions, or error situations.

According to the Software Engineering Body of Knowledge (SWEBOK),^[16] use cases belong to the scenario-based requirement elicitation techniques, as well as the model-based analysis, techniques. But the use cases also support narrative-based requirement gathering, incremental requirement acquisition, system documentation, and acceptance testing.^[1]

Variations[edit]

There are different kinds of use cases and variations in the technique:

• System use cases specify the requirements of a system to be developed.^[2] They identify in their detailed description not only the interactions with the actors but also the entities that are involved in the processing. They are the starting point for further analysis models and design activities.
• Business use cases focus on a business organization instead of a software system. They are used to specify business models and business process requirements in the context of business process reengineering initiatives.^[5]
• Essential use cases, also called abstract use cases, describe the potential intents of the actors and how the system addresses these, without defining any sequence or describing a scenario.^[8] This practice was developed with the aim of supporting the user-centric design and avoiding to induce bias about the user interface in the early stage of the system specifications.^[7]
• Use Case 2.0 to adapt the technique for the context of agile development methods.^[1] This technique enriches the requirement-gathering practice with support for user-story narratives. It also provides use case «slices» to facilitate incremental elicitation of requirements and enable incremental implementation.

Scope[edit]

The scope of a use case can be defined by a subject and by goals:

• The subject identifies the system, sub-system, or component that will provide the interactions.^[17]
• The goals can be structured hierarchically, taking into account the organizational level interested in the goal (e.g. company, department, user), and the decomposition of the user’s goal into sub-goals.^[9] The decomposition of the goal is performed from the point of view of the users, and independently of the system, which differs from traditional functional decomposition.^[10]  

Usage[edit]

Use cases are known to be applied in the following contexts:

• Object Oriented Software Engineering (OOSE), as driving element;^[4]
• Unified Modeling Language (UML), as a behavioral modelling instrument;^[17]
• Unified Software Development Process (UP) and its fore-runner, the IBM Rational Unified Process (RUP);^[7]
• up-front documentation of software requirements specification (SRS), as an alternative structure for the functional requirements;^[18]
• deriving the design from the requirements using the entity-control-boundary approach;^[7]
• and agile development.^[1][19]

Templates[edit]

There are many ways to write a use case in the text, from use case brief, casual, outline, to fully dressed etc., and with varied templates. Writing use cases in templates devised by various vendors or experts is a common industry practice to get high-quality functional system requirements.

Cockburn style[edit]

The template defined by Alistair Cockburn in his book Writing Effective Use Cases has been one of the most widely used writing styles of use cases.^{[citation needed]}

Design scopes[edit]

Cockburn suggests annotating each use case with a symbol to show the «Design Scope», which may be black-box (internal detail is hidden) or white box (internal detail is shown). Five symbols are available:^[20]

Scope	Icon
Organization (black-box)	Filled House
Organization (white-box)	Unfilled House
System (black-box)	Filled Box
System (white-box)	Unfilled Box
Component	Screw or Bolt

Other authors sometimes call use cases at the Organization level «Business use cases».^[21]

Goal levels[edit]

Cockburn suggests annotating each use case with a symbol to show the «Goal Level»;^[22] the preferred level is «User-goal» (or colloquially «sea level»^[23]: 101).

Goal Level	Icon	Symbol
Very High Summary	Cloud	++
Summary	Flying Kite	+
User Goal	Waves at Sea	!
Subfunction	Fish	—
Too Low	Seabed Clam-Shell	—

Sometimes in text writing, a use case name followed by an alternative text symbol (! +, -, etc.) is a more concise and convenient way to denote levels, e.g. place an order!, login-.

Fully dressed[edit]

Cockburn describes a more detailed structure for a use case but permits it to be simplified when less detail is needed. His fully dressed use case template lists the following fields:^[24]

• Title: «an active-verb goal phrase that names the goal of the primary actor»^[25]
• Primary Actor
• Goal in Context
• Scope
• Level
• Stakeholders and Interests
• Precondition
• Minimal Guarantees
• Success Guarantees
• Trigger
• Main Success Scenario
• Extensions
• Technology & Data Variations List

In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.

Cockburn’s approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn’s «Fully dressed use case» template from software to systems of all kinds, with the following fields differing from Cockburn:^[26]

• Variation scenarios «(maybe branching off from and maybe returning to the main scenario)»
• Exceptions «i.e. exception events and their exception-handling scenarios»

Casual[edit]

Cockburn recognizes that projects may not always need detailed «fully dressed» use cases. He describes a Casual use case with the fields:^[24]

• Title (goal)
• Primary Actor
• Scope
• Level
• (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.

Fowler style[edit]

Martin Fowler states «There is no standard way to write the content of a use case, and different formats work well in different cases.»^[23]: 100 He describes «a common style to use» as follows:^[23]: 101

• Title: «goal the use case is trying to satisfy»^[23]: 101
• Main Success Scenario: numbered list of steps^[23]: 101
  • Step: «a simple statement of the interaction between the actor and a system»^[23]: 101
• Extensions: separately numbered lists, one per Extension^[23]: 101
  • Extension: «a condition that results in different interactions from .. the main success scenario». An extension from main step 3 is numbered 3a, etc.^[23]: 101

The Fowler style can also be viewed as a simplified variant of the Cockburn template. This variant is called a user story.

Alistair Cockburn stated:^[27]

Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, and Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds a data description of the in/out data. I would put Catalysis at the 6th bit of precision, as they include a model also of the recipient of the message. In the CrystalMethodology family, differently founded projects use cases at different levels of precision. A methodologically light project uses User Stories, a methodologically heavier project uses Use Cases to 4 bits of precision, and Catalysis uses 6 bits of precision.

Martin Fowler stated:^[27]

It is all about how people use cases. I’ve seen many people use cases in a very formalized manner. Kent does his UserStories in a much more approachable manner. I do use cases the way Kent does User Stories. I call them to use cases to better communicate with other developers and to influence them to use a more lightweight approach.

Actors[edit]

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: «An actor might be a person, a company or organization, a computer program, or a computer system—hardware, software, or both.»^[28] Actors are always stakeholders, but not all stakeholders are actors, since they may «never interact directly with the system, even though they have the right to care how the system behaves.»^[28] For example, «the owners of the system, the company’s board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance» could all be stakeholders but are unlikely to be actors.^[28]

Similarly, a person using a system may be represented as a different actor because of playing different roles. For example, user «Joe» could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. Cockburn writes that «These days I write ‘sales rep for the customer’ or ‘clerk for the marketing department’ to capture that the user of the system is acting for someone else.» This tells the project that the «user interface and security clearances» should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.^[29]

A stakeholder may play both an active and an inactive role: for example, a Consumer is both a «mass-market purchaser» (not interacting with the system) and a User (an actor, actively interacting with the purchased product).^[30] In turn, a User is both a «normal operator» (an actor using the system for its intended purpose) and a «functional beneficiary» (a stakeholder who benefits from the use of the system).^[30] For example, when user «Joe» withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Cockburn advises looking for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design (SuD) itself, and finally among the «internal actors», namely the components of the system under design.^[28]

Business use case[edit]

In the same way that a use case describes a series of events and interactions between a user (or other types of Actor) and a system, in order to produce a result of value (goal), a business use case describes the more general interaction between a business system and the users/actors of that system to produce business results of value. The primary difference is that the system considered in a business use case model may contain people in addition to technological systems. These «people in the system» are called business workers. In the example of a restaurant, a decision must be made whether to treat each person as an actor (thus outside the system) or a business worker (inside the system). If a waiter is considered an actor, as shown in the example below, then the restaurant system does not include the waiter, and the model exposes the interaction between the waiter and the restaurant. An alternative would be to consider the waiter as a part of the restaurant system (a business worker) while considering the client to be outside the system (an actor).^[31]

Visual modeling[edit]

Use cases are not only texts but also diagrams if needed. In the Unified Modeling Language, the relationships between use cases and actors are represented in use case diagrams originally based upon Ivar Jacobson’s Objectory notation. SysML uses the same notation at a system block level.

In addition, other behavioral UML diagrams such as activity diagrams, sequence diagrams, communication diagrams, and state machine diagrams can also be used to visualize use cases accordingly. Specifically, a System Sequence Diagram (SSD) is a sequence diagram often used to show the interactions between the external actors and the system under design (SuD), usually for visualizing a particular scenario of a use case.

Use case analysis usually starts by drawing use case diagrams. For agile development, a requirement model of many UML diagrams depicting use cases plus some textual descriptions, notes, or use case briefs would be very lightweight and just enough for small or easy project use. As good complements to use case texts, the visual diagram representations of use cases are also effective facilitating tools for the better understanding, communication, and design of complex system behavioral requirements.

Examples[edit]

Below is a sample use case written with a slightly modified version of the Cockburn-style template. Note that there are no buttons, controls, forms, or any other UI elements and operations in the basic use case description, where only user goals, subgoals, or intentions are expressed in every step of the basic flow or extensions. This practice makes the requirement specification clearer and maximizes the flexibility of the design and implementation.

Use Case: Edit an article

Primary Actor: Member (Registered User)

Scope: a Wiki system

Level: ! (User goal or sea level)

Brief: (equivalent to a user story or an epic)

The member edits any part (the entire article or just a section) of an article they are reading. Preview and changes comparison are allowed during the editing.

Stakeholders

…

Postconditions

Minimal Guarantees:

Success Guarantees:

• The article is saved and an updated view is shown.
• An edit record for the article is created by the system, so watchers of the article can be informed of the update later.

Preconditions:

The article with editing enabled is presented to the member.

Triggers:

The member invokes an edit request (for the full article or just one section) on the article.

Basic flow:

1. The system provides a new editor area/box filled with all the article’s relevant content with an informative edit summary for the member to edit. If the member just wants to edit a section of the report, only the original content of the section is shown, with the section title automatically filled out in the edit summary.
2. The member modifies the article’s content until the member is satisfied.
3. The member fills out the edit summary, tells the system if they want to watch this article, and submits the edit.
4. The system saves the article, logs the edit event, and finishes any necessary post-processing.
5. The system presents the updated view of the article to the member.

Extensions:

2–3.

a. Show preview:

1. The member selects Show preview which submits the modified content.
2. The system reruns step 1 with the addition of the rendered updated content for preview, and informs the member that his/her edits have not been saved yet, then continues.

b. Show changes:

1. The member selects Show changes which submits the modified content.
2. The system reruns step 1 with the addition of showing the results of comparing the differences between the current edits by the member and the most recent saved version of the article, then continues.

c. Cancel the edit:

1. The member selects Cancel.
2. The system discards any change the member has made, then goes to step 5.

4a. Timeout:

…

Advantages[edit]

Since the inception of the agile movement, the user story technique from Extreme Programming has been so popular that many think it is the only and best solution for the agile requirements of all projects. Alistair Cockburn lists five reasons why he still writes use cases in agile development.^[32]

1. The list of goal names provides the shortest summary of what the system will offer (even then user stories). It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation, and timing.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do and what it will not do. It provides the context for each specific line item requirement (e.g. fine-grained user stories), a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look-ahead mechanism, so the stakeholders can spot issues likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule so that the answers can be ready when the development team gets around to working on them.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky, and ignored business questions: «What are we supposed to do in this case?» It is a thinking/documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved.

In summary, specifying system requirements in use cases have these apparent benefits compared with traditional or other approaches:

User focused

Use cases constitute a powerful, user-centric tool for the software requirements specification process.^[33] Use case modeling typically starts from identifying key stakeholder roles (actors) interacting with the system, and their goals or objectives the system must fulfill (an outside perspective). These user goals then become the ideal candidates for the names or titles of the use cases which represent the desired functional features or services provided by the system. This user-centered approach ensures that what has real business value and the user really want is developed, not those trivial functions speculated from a developer or system (inside) perspective.

Use case authoring has been an important and valuable analysis tool in the domain of User-Centered Design (UCD) for years.

Better communication

Use cases are often written in natural languages with structured templates. This narrative textual form (legible requirement stories), understandable by almost everyone, and complemented by visual UML diagrams fosters better and deeper communications among all stakeholders, including customers, end-users, developers, testers, and managers. Better communications result in quality requirements and thus quality systems delivered.

Quality requirements by structured exploration

One of the most powerful things about use cases resides in the formats of the use case templates, especially the main success scenario (basic flow) and the extension scenario fragments (extensions, exceptional and alternative flows). Analyzing a use case step by step from preconditions to postconditions, exploring and investigating every action step of the use case flows, from basic to extensions, to identify those tricky, normally hidden and ignored, seemingly trivial but realistically often costly requirements (as Cockburn mentioned above), is a structured and beneficial way to get clear, stable and quality requirements systematically.

Minimizing and optimizing the action steps of a use case to achieve the user goal also contribute to a better interaction design and user experience of the system.

Facilitate testing and user documentation

With content based upon an action or event flow structure, a model of well-written use cases also serves as excellent groundwork and valuable guidelines for the design of test cases and user manuals of the system or product, which is an effort-worthy investment up-front. There are obvious connections between the flow paths of a use case and its test cases. Deriving functional test cases from a use case through its scenarios (running instances of a use case) is straightforward.^[34]

Limitations[edit]

Limitations of use cases include:

• Use cases are not well suited to capturing non-interaction-based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere.
• As there are no fully standard definitions of use cases, each project must form its own interpretation.
• Some use case relationships, such as extends, are ambiguous in interpretation and can be difficult for stakeholders to understand as pointed out by Cockburn (Problem #6)^{[35][citation needed]}
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI not be reflected in use cases, it can be awkward to abstract out this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. Another approach to associate UI elements with use cases is to attach a UI design to each step in the use case. This is called a use case storyboard.
• Use cases can be over-emphasized. Bertrand Meyer discusses issues such as driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques.^[36]
• Use cases are a starting point for test design,^[37] but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.^[38]
• Though use cases include goals and contexts, whether these goals and motivations behind the goals (stakeholders’ concerns and their assessments including non-interaction) conflict or negatively/positively affect other system goals are subject of goal-oriented requirement modeling techniques (such as BMM, I*, KAOS and ArchiMate ARMOR).

Misconceptions[edit]

This section needs expansion. You can help by adding to it. (July 2015)

Common misunderstandings about use cases are:

User stories are agile; use cases are not.

Agile and Scrum are neutral on requirement techniques. As the Scrum Primer^[39] states,

Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain «user stories»; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.

Use case techniques have evolved to take Agile approaches into account by using use case slices to incrementally enrich a use case.^[13]

Use cases are mainly diagrams.

Craig Larman stresses that «use cases are not diagrams, they are text».^[40]

Use cases have too much UI-related content.

As some put it,^[who?]

Use cases will often contain a level of detail (i.e. naming of labels and buttons) which make it not well suited for capturing the requirements for a new system from scratch.

Novice misunderstandings. Each step of a well-written use case should present actor goals or intentions (the essence of functional requirements), and normally it should not contain any user interface details, e.g. naming of labels and buttons, UI operations, etc., which is a bad practice and will unnecessarily complicate the use case writing and limit its implementation.

As for capturing requirements for a new system from scratch, use case diagrams plus use case briefs are often used as handy and valuable tools, at least as lightweight as user stories.^{[citation needed]}

Writing use cases for large systems is tedious and a waste of time.

As some put it,^[who?]

The format of the use case makes it difficult to describe a large system (e.g. CRM system) in less than several hundred pages. It is time-consuming and you will find yourself spending time doing an unnecessary amount of rework.

^{[citation needed]}

Spending much time writing tedious use cases which add no or little value and result in a lot of rework is a bad smell indicating that the writers are not well skilled and have little knowledge of how to write quality use cases both efficiently and effectively. Use cases should be authored in an iterative, incremental, and evolutionary (agile) way. Applying use case templates does not mean that all the fields of a use case template should be used and filled out comprehensively from up-front or during a special dedicated stage, i.e. the requirement phase in the traditional waterfall development model.

In fact, the use case formats formulated by those popular template styles, e.g. the RUP’s and the Cockburn’s (also adopted by the OUM method), etc., have been proved in practice as valuable and helpful tools for capturing, analyzing and documenting complex requirements of large systems. The quality of a good use case documentation (model) should not be judged largely or only by its size. It is possible as well that a quality and comprehensive use case model of a large system may finally evolve into hundreds of pages mainly because of the inherent complexity of the problem in hand, not because of the poor writing skills of its authors.^{[citation needed]}

Tools[edit]

Text editors and/or word processors with template support are often used to write use cases. For large and complex system requirements, dedicated use case tools are helpful.

Some of the well-known use case tools include:

• CaseComplete
• Enterprise Architect
• MagicDraw
• Rational Software’s RequisitePro — one of the early, well-known use case and requirement management tools in the 1990s.
• Software Ideas Modeler
• Wiki software — good tools for teams to author and manage use cases collaboratively.

Most UML tools support both the text writing and visual modeling of use cases.

See also[edit]

• Abuse case
• Business case
• Entity-control-boundary
• Event partitioning
• Feature
• List of UML tools
• Misuse case
• Requirement
• Requirements elicitation
• Scenario
• Storyboard
• Test case
• Use case points

References[edit]

Further reading[edit]

• Alexander, Ian, and Beus-Dukic, Ljerka. Discovering Requirements: How to Specify Products and Services. Wiley, 2009.
• Alexander, Ian, and Maiden, Neil. Scenarios, Stories, Use Cases. Wiley 2004.
• Armour, Frank, and Granville Miller. Advanced Use Case Modeling: Software Systems. Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Use Case Modeling, Addison-Wesley Professional, 20 August 2002.
• Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design, Addison-Wesley, 1999.
• Denney, Richard. Succeeding with Use Cases: Working Smart to Deliver Quality. Addison-Wesley, 2005.
• Fowler, Martin. UML Distilled (Third Edition). Addison-Wesley, 2004.
• Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering — A Use Case Driven Approach, Addison-Wesley, 1992.
• Jacobson Ivar, Spence I., Bittner K. Use Case 2.0: The Guide to Succeeding with Use Cases, IJI SA, 2011.
• Dean Leffingwell, Don Widrig, Managing Software Requirements: A Use Case Approach, Addison-Wesley Professional. 7 December 2012.
• Kulak, Daryl, and Eamonn Guiney. Use cases: requirements in context. Addison-Wesley, 2012.
• Meyer, Bertrand. Object-Oriented Software Construction. (2nd edition). Prentice Hall, 2000.
• Schneider, Geri and Winters, Jason P. Applying Use Cases 2nd Edition: A Practical Guide. Addison-Wesley, 2001.
• Wazlawick, Raul S. Object-Oriented Analysis and Design for Information Systems: Modeling with UML, OCL, and IFML. Morgan Kaufmann, 2014.

External links[edit]

• Use case column and Basic Use Case Template by Alistair Cockburn
• Use Cases at GSA’s Usability.gov
• Application of use cases for stakeholder analysis «Project Icarus» at Academia.edu
• Search for «use case» at IBM Developer

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

На что обратить внимание? Use Case используются в различных сферах: от разработки ПО до формирования бизнес-процессов. Главные требования – ясность и лаконичность, ведь от этого зависит, поймут ли его в принципе.

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

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

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

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

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

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

Когда необходим Use Case

Кому нужны сценарии Use Case:

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

Скачать файл

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

Случаи, в которых могут быть использованы сценарии Use Case:

• Для создания качественной спецификации требований системы. При их разработке и применяется также описание интерфейса программы, и возможность ее интеграции с другими.
• При осуществлении технической поддержки. В таком случае UseCase помогает выявить ошибку и определить, на каком этапе она произошла.
• Если требуется дать описание лишь части функциональности системы, взаимодействия пользователя и программой. Здесь на выручку приходит шаблон UseCase, на основе которого и создается сценарий. Допустим, что в основе мобильного приложения лежит описание пользовательского интерфейса. Но не учтен ряд функций, выполнение которых требует создания дополнительных сценариев с использованием таблички: «Действие пользователя – отклик системы» или их совмещения.

Правила написания Use Case

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

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

• Триггеры – элементы, приводящие в действие UseCase.
• Успешный сценарий, то есть происходящий без ошибок и непредусмотренных обстоятельств.
• Альтернативные варианты. Их можно охарактеризовать как запасной план, созданный на базе основного сценария, необходимый при сбоях в функционировании системы.

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

1. Определение пользователей сайта.
2. Выбор одного из них.
3. Формулировка действий пользователя на сайте, которые и будут являться UseCase.
4. Определение потока события для каждого из сценариев.
5. Описание действий пользователя и результата, к которому они ведут. Другими словами, каким должен быть отклик системы.
6. Создание и добавление других вариантов развития событий в сценарий.
7. Выбор других пользователей и описание UseCase для каждого из них (шаги 2 – 6).

Нижеприведенный пример Use Case – это сценарий входа пользователя в школьное приложение:

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

Рекомендации по созданию Use Case

Применяйте диаграммы

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

Люди – первостепенно важный элемент сценария

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

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

Идите за потоком

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

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

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

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

Ошибки при создании Use Case

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

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

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

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

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

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

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

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

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

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

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

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

Элементы use case

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

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

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

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

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

Пример use case

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

Название use case	Login
Описание use case	Пользователь входит в систему, чтобы получить доступ к ее функционалу.
Акторы	Родители, Ученики, Учитель, Админ
Предусловия	Система должна быть подсоединена к сети
Постусловия	После успешного входа пользователю отсылается уведомление на mail id

Основные сценарии	Номер	Шаги
Акторы/пользователи	1	Ввод username Ввод пароля
	2	Проверить имя пользователя и пароль
	3	Разрешить на вход в систему
Расширения	1a	Неверное имя пользователя Система выбрасывает сообщение об ошибке
	2b	Неверный пароль Система выбрасывает сообщение об ошибке
	3c	Неверный пароль введен 4 раза Приложение закрывается

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

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

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

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

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

1. Заказчики

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

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

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

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

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