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

Опубликовано: 2015-08-21

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

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

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

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

Пример – 1

Детали варианта использования Комментарии

Название варианта использования — Заказать билеты

Имя хорошее. Это ясно дает представление о том, какой вариант использования

Цель – Клиент успешно бронирует билеты на футбольный матч на веб-сайте.

Описание- Актер заходит на сайт, просматривает
расписание, выбирает матч
и места, бронирует
билет и производит оплату футбольного матча

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

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

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

Основной поток — шаги

  1. Актер заходит на сайт и выбирает билеты.
  2. Система отображает информацию о бронировании
  3. Актер подтверждает детали матча (подробнее в спецификации пользовательского интерфейса)
  4. Актер подтверждает информацию о месте (подробнее в спецификации пользовательского интерфейса)
  5. Система подтверждает доступность
  6. Система представляет форму для получения информации о пользователе
  7. Актер предоставляет информацию о пользователе (подробности в другом варианте использования)
  8. Система представляет форму для платежной информации
  9. Актер предоставляет платежную информацию (подробности в другом варианте использования)
  10. Система подтверждает детали и выдает идентификатор бронирования
  11. Актер спасает билет
  12. Актер выходит из системы.

Включенные варианты использования

- Совершить платеж

- Создать идентификатор бронирования

Варианты расширенного использования

- Создать уведомление об отказе платежа

- Распечатать билет

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

Альтернативный поток

-отменить билеты

  1. Актер отменяет транзакцию
  2. Система отменяет транзакцию

Поток исключений

-Билеты недоступны для выбранного матча/выбранных мест

1. Система отображает сообщение об ошибке

Подробно описаны альтернативные потоки и потоки исключений.

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

Пример – 2

Детали варианта использования Комментарии

Название варианта использования — Заказ билетов

Имя не с точки зрения пользователя и похоже на определение бизнес-процесса.

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

Цель варианта использования отсутствует. Дизайнеры, тест-аналитики и разработчики не поймут, зачем нужно разрабатывать этот функционал.

Действующие лица – клиент, представитель службы поддержки клиентов
Триггер — актер получил доступ к системе для бронирования билетов.
Постусловие — актер может бронировать билеты. Система обновляет информацию.

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

Основные шаги потока

  1. Клиент заходит на веб-сайт и выбирает опцию «Забронировать билеты», чтобы забронировать билеты.
  2. Система отображает список совпадений в раскрывающемся списке.
  3. Представитель службы поддержки клиентов выбирает из раскрывающегося списка
  4. Система отображает информацию о местах на карте мест.
  5. Актер выбирает места. Если места недоступны и отображается сообщение об ошибке.
  6. Актер сообщает реквизиты для оплаты
  7. Актер бронирует билет, иначе отменяет билет.
  8. Система генерирует идентификатор бронирования, используя имя клиента и случайно сгенерированное 4-значное число.

Включенные варианты использования
- Совершить платеж

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

Этому варианту использования не хватает ясности и детализации, и он не поможет команде правильно разработать функциональность.

Что должно быть в сценарии использования Чего не должно быть в сценарии использования
  1. Имя
  2. Описание/Цель
  3. Предварительные условия
  4. Вызывать
  5. Основной поток и альтернативные потоки
  6. Сценарии исключений
  7. Почтовые условия
  8. Особые требования, если таковые имеются
  9. Ссылка на детали пользовательского интерфейса и другие связанные модели/диаграммы
  1. Детали реализации
  2. Внутренняя обработка
  3. Нефункциональные требования
  4. Детали пользовательского интерфейса должны быть сделаны одновременно с вариантами использования, но в отдельном документе.

.

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

  1. Напишите шаги варианта использования с точки зрения актера.
  2. Сценарии использования не должны иметь деталей дизайна и архитектуры. Он должен концентрироваться на бизнес-процессе.
  3. Лучше, если шаги в прецеденте будут прописаны в хронологическом порядке.
  4. В зависимости от требований и сложности решите, нужно ли хранить операции CRUD (создание, чтение, обновление и удаление) в отдельных вариантах использования или их можно объединить в одном.
  5. Важно давать ссылки на альтернативные потоки, потоки исключений, включенные варианты использования и расширенные варианты использования и из них, чтобы бизнес-дизайн был завершен.
  6. Выберите шаблон (определенный проектом, определенным компанией или любой подробный) и следуйте структуре для всех вариантов использования.
  7. Важно иметь диаграммы вариантов использования.
  8. В Agile у нас есть пользовательские истории для фиксации требований. Пользовательские истории можно детализировать с помощью бережливых вариантов использования в итеративной манере.
  9. Валидации должны быть подробно описаны.

После того, как вы написали вариант использования, задайте эти вопросы, и это эффективный вариант использования, если ответ «Да» на все вопросы —

  1. Будет ли пользователь знать, когда бизнес-поток, представленный в варианте использования, будет выполнен?
  2. Ясно ли, кто будет выполнять какой шаг варианта использования?
  3. Является ли описание бизнес-логики достаточным для анализа, проектирования, разработки и тестирования?
  4. Имеются ли правильные ссылки из основного потока на альтернативные потоки и потоки исключений?
  5. Присутствует ли диаграмма вариантов использования?

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