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

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

В этом видео Уильям Хадсон Пользовательский опыт Стратег и основатель Syntagm Ltd представляет варианты использования и объясняет, как Ивар Джейкобсон создал их, чтобы соединить требования с реализацией.

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

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

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

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

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

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

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

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

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

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

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

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

• Имя: описательное имя варианта использования.

• Актеры: Объекты (пользователи или другие системы), взаимодействующие с системой.

• Цель: Чего актер пытается достичь посредством этого взаимодействия.

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

• Основной поток: Типичная последовательность взаимодействий между субъектом и системой.

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

• Постусловия: состояние системы после завершения варианта использования.

Вот простой пример:

• Имя: Зарезервировать место онлайн

• Актеры: Пассажир; Платформа бронирования

• Цель: Выберите и зарезервируйте место в существующем бронировании рейса.

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

  • Пассажир входит в систему бронирования и открывает свое бронирование.

  • Система отображает информацию о рейсе и доступные места.

  • Пассажир выбирает предпочитаемое место.

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

  • Система подтверждает обновление резервирования.

• Альтернативный поток: Выбранное место недоступно — система уведомляет пассажира и предлагает ему выбрать другое место.

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

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

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

• На рейсе должно быть открыто онлайн-бронирование мест.

• Должны быть доступные для бронирования места.

Постусловия

Хотя приведенный выше пример упрощен, повествования об основных и альтернативных потоках на самом деле были бы длинными. Также возникает вопрос, следует ли разрешать пассажирам бронировать места, купленные клиентом, если это разные люди. Agile-подход к таким вопросам оставляет решение на последнюю минуту, что называется «проектирование точно в срок», но если бы это было раннее проектное решение, можно было бы избежать больших усилий и путаницы.

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

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

Вывод

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

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

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

Герой изображения: © Интерактивный дизайн Фонд, CC BY-SA 4.0