Как писать эффективные варианты использования

Вы писали хорошие варианты использования для своей системы?

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

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

use case diagram example

Что такое вариант использования?

objective

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

Теоретически, конечные пользователи будут выполнять действия, поддерживаемые системой, чтобы достичь своей конечной цели, как определено в анализе вариантов использования. Рассмотрим пример онлайн-системы бронирования отелей. «Бронирование» — это несомненно бизнес-цель, а значит, и вариант использования. Возможность найти отель на онлайн-карте также может быть желательной для пользователя. Однако это не является вариантом использования, потому что сама по себе операция не приводит к какой-либо наблюдаемой цели.

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

Истории пользователей сейчас широко используются

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

Истории пользователей, созданные владельцем продукта, кратко и просто фиксируют «кто», «что» и «зачем» требований, и часто пишутся на не-техническом, естественном языке.

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

Практические соображения

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

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

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

Overview of user stories creation

Что такое диаграмма вариантов использования?

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

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

use case diagram exampleДиаграмма вариантов использования в основном состоит из участников, вариантов использования и связей (соединений).

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

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

Построение диаграммы вариантов использования в Visual Paradigm

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

  1. Откройте UeXceler в Visual Paradigm, выбрав “UeXceler > UeXceler с панели приложения.
  2. Откройте диаграмму вариантов использования страницу.
    Open use case diagram
  3. Выберите Актор на панели инструментов диаграммы. Нажмите на диаграмму, чтобы создать актора и назвать его Клиент.
    actor
  4. Клиент может забронировать номер в отеле, что является вариантом использования системы. Давайте создадим вариант использования из актора Клиент актора. Переместите указатель мыши на Клиент актора. Нажмите на каталог ресурсов значок в правом верхнем углу и перетащите его.
    create use case
  5. Выберите Связь -> Вариант использования в каталоге ресурсов.
    select use case in resource catalog
  6. Отпустите кнопку мыши, чтобы создать вариант использования. Назовите его Забронировать. Связь между актором и вариантом использования указывает на то, что актор будет взаимодействовать с системой для достижения связанного варианта использования.
  7. Завершите проектирование, чтобы оно выглядело следующим образом:
    Use case diagram example

Разработка вариантов использования с помощью пользовательских историй

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

  1. Щелкните правой кнопкой мыши по Забронировать и выберите Открыть сведения о варианте использования… из всплывающего меню.
    open use case details
  2. Откройте Истории пользователей страницу.
    Open user story tab
  3. Создайте истории пользователей, дважды щелкнув пустую область внутри вкладки. Создайте три истории: Поиск отеля, Сделать бронирование отеля и Обработать срочное бронирование.
    User stories created

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

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

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

Давайте напишем сценарий истории пользователя.

  1. Дважды щелкните по истории пользователя Поиск отеля чтобы открыть его.
    Open user story
  2. Откройте Сценарий вкладку. Редактор сценария состоит из строк, известных как шаги. Каждый шаг представляет собой ввод участника или ответ системы.
    Open user story scenario tab
  3. Щелкните по первому шагу и введите первый ввод пользователя: Введите город, дату прибытия, дату отъезда, тип номера и нажмите Поиск.
    Entered first step
  4. Используйте инструменты форматирования, доступные под панелью UeXceler для установки слова Поиск в синем и жирном начертании, для акцента.
    Format scenario step text
  5. Нажмите Ввести чтобы завершить этот шаг. Вам будет создан шаг 2.
  6. Шаг 2 касается того, как система реагирует на ввод пользователя. Вы можете начать с написания «Система…», но существует более эффективный способ представления ответа системы. ВыберитеUeXceler > Добавить элемент > Ответ системы из панели инструментов, чтобы добавить шаг ответа системы.
    Add system response to scenario
  7. Теперь вы можете ввести содержимое шага 2:Показать список отелей.
    Entering system response text
  8. Добавьте следующие шаги:
    Ввод пользователя Ответ системы
    Нажмите на логотип отеля, чтобы прочитать его подробности
    Показать подробности отеля

    Scenario steps entered

Дополнительно — создание макета сценария

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

  1. Нажмите на первый шаг.
    Select first step
  2. Переместите указатель мыши на зеленый треугольник справа. Затем нажмите наОпределить макет.
    Define wireframe
  3. Вы видите серую панель, появившуюся справа? Нажмите на нее, чтобы выбрать тип макета для создания.
    Create wireframe
  4. В всплывающем окне выберитеВеб-сайт.
    Select wireframe type
  5. НажмитеНовый макет веб-сайта. Появится новый макет с пустым окном браузера. Здесь вы можете подготовить макет веб-сайта.
  6. Прежде чем начать добавлять различные компоненты в окно браузера, давайте уменьшим его. Нажмите на заголовок окна браузера.
  7. После нажатия появляются обработчики изменения размера вокруг окна браузера, чтобы вы могли вручную изменить размер окна. Давайте попробуем более прямой метод. Щелкните правой кнопкой мыши по заголовку браузера и выберитеРазмер браузера (1024 x 768) > 800 x 600 из всплывающего меню.
    Resize wireframe
  8. Воспользуйтесь инструментами для создания эскиза, перечисленными в панели инструментов диаграммы, чтобы создать эскиз, подобный этому:
    Wireframe created
  9. Вернитесь к редактору сценария, нажав на треугольную кнопку рядом с названием шага.
    Go back to scenario editor
    Готово, и вы можете увидеть миниатюру вашего эскиза в редакторе сценария.
    Wireframe added

Ссылки:

Leave a Reply