Use Cases. Цели пользователя. Возможности будущей системы.




В теме 15 ответов, и 7 участников, последнее обновление сделано пользователем Аватар (Елена Гунёва) Елена Гунёва 5 г, 2 мес. назад.

Показано 15 ответов - от 1 до 15 (всего 16)
  • Автор
    Сообщения
  • 02.06.2012 в 23:41 # 5977
    Аватар (Елена Гунёва)
    Елена Гунёва
    Подписчик
    Всем доброе время суток!

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

    Итак, система. Web система позволяет бронировать билеты. Однако, в процессе бронирования участвуют как покупатель билета, так и кассир. Процесс бронирования выглядит следующим образом:
    1 — Покупатель создаёт заявку на бронь билетов
    2 — Кассир находит эту заявку в списке заявок
    3 — Кассир обрабатывает заявку, звонит покупателю, покупатель подтверждает бронь, кассир бронирует билеты

    Если применять технику Use Cases(UC), то возможны как минимум следующие варианты при описании бронирования билетов:
    1 — один UC — "забронировать билеты",
    2 — два UCs, первый — "забронировать билеты", который включает второй — "обработать заявку",
    3 — два UCs, первый — "создать заявку", второй — "обработать заявку".

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

    Поделиться:

    Цитировать

    03.06.2012 в 16:14 # 5978
    Прежде, чем отвечать на вопросы, хотелось бы уточнить, бы говорим о Business Use Cases или System Use Cases?
    Как, зачем и для кого будут далее использоваться данные Use Cases?
    Поделиться:

    Цитировать

    03.06.2012 в 21:54 # 5979
    Аватар (Елена Гунёва)
    Елена Гунёва
    Подписчик
    Забыла уточнить :blush2:, на тренинге мы обсуждали только системные юз кейсы.

    Заказчик будет утверждать эти System Use Cases, разработчики будут разрабатывать систему по ним (и не только по ним).

    Поделиться:

    Цитировать

    04.06.2012 в 08:27 # 5980
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    /me запасся попкорном *offtopic*
    Поделиться:

    Цитировать

    04.06.2012 в 09:42 # 5981
    В качестве системных лично я бы выбрал третий вариант. В качестве бизнес (который реализуется при помощи 2х системных) — 1ый.

    /me открыл бутылочку пивка и расположился рядом с Денисом (:

    Поделиться:

    Цитировать

    04.06.2012 в 11:37 # 5982
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Ещё полезно ознакомиться с главой 5 "Три поименованных уровня цели" книги "Современные методы описания функциональных требований", Алистер Коберн (2002)

    А если отвечать на вопрос "какой из вариантов правильный и почему?": Все правильные, каждый в своем контексте.

    Поделиться:

    Цитировать

    04.06.2012 в 12:41 # 5983
    Аватар (AndrewK)
    Андрей Курьян
    Участник
    ИМХО,
    бизнес-процесс включает:
    1. Создание заявки клиентом
    2. Согласование и утверждение заявки кассиром

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

    Поделиться:

    Цитировать

    04.06.2012 в 14:55 # 5984
    Для создания заявки пользователю наверняка понадобится только заполнить одну форму на какой-то странице (на которую он явно легко должен попасть).
    Поиск и обработка заявки также, думаю, подразумевают работу кассира на одной-двух страницах. Поэтому весьма вероятно, что и одного юзкейса будет достаточно.
    Пусть будет несколько альтернативных сценариев, если понадобится.
    Юзкейс для заказчика будет понятен (а еще более понятная диаграмма активностей, но раз тренинг этого не подразумевает, то ограничимся юзкейсом).

    С другой стороны для разработчика, наверно, удобнее будет 2 юзкейса, т.к. функционал можно четко разделить: 1) логика и GUI для кассира, 2) логика и GUI для пользователя.

    Второй вариант со включением одного юзкейса в другой не зря никто не рассматривает в качестве рабочего :).

    В итоге — 1 либо 3, если при этом объяснить, в каком контексте использовать.

    Поделиться:

    Цитировать

    04.06.2012 в 15:57 # 5985
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Андрей!

    В чем бизнес-требования в варианте 3? У пользователя бизнес-цель добавлять заявки в систему? У кассира или владельцев системы бизнес-цель обрабатывать заявки? Процесс-то единый, а уже на этапе реализации нам удобнее это разнести на 2 системных кейса, и то, только потому что у нас реализация явно раздельная.

    з.ы. что самое интересное — все сразу включают "реализаторку" и начинают проектировать приложение. Предположим, в данном случае оно вроде более-менее очевидно. А если мы начинаем работать над проектом, в котором вариант реализации ещё нифига не очевиден?

    Поделиться:

    Цитировать

    04.06.2012 в 17:06 # 5986
    доброго дня)

    Исходя из условий задачи, я бы выбрала вариант 3:
    1) отталкиваясь от primary actors — их тут 2 — покупатель и кассир — поэтому и юзкейса лучше два раздельных. При этом никто не мешает слинковать эти юзкейсы друг с другом. А эти два актора явно перерастут потом в пользовательские роли — два раздельных юзкейса будет просто удобнее, мне кажется.
    2) лично мои убеждения, что более атомарные вещи проще реализовывать и поддерживать — поэтому 2 более мелких юзкейса (в рамках здравого смысла), лучше, чем 1 крупный.

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

    Поделиться:

    Цитировать

    04.06.2012 в 18:31 # 5987
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Андрей!

    В чем бизнес-требования в варианте 3? У пользователя бизнес-цель добавлять заявки в систему? У кассира или владельцев системы бизнес-цель обрабатывать заявки? Процесс-то единый, а уже на этапе реализации нам удобнее это разнести на 2 системных кейса, и то, только потому что у нас реализация явно раздельная.

    з.ы. что самое интересное — все сразу включают "реализаторку" и начинают проектировать приложение. Предположим, в данном случае оно вроде более-менее очевидно. А если мы начинаем работать над проектом, в котором вариант реализации ещё нифига не очевиден?

    А зачем кассиру обрабатывать заявки? Какую дополнительную ценность кассир может добавить в заявку? Правильный ответ — никакой.
    На самом деле, в рамках БП у кассира цель частично совпадает с целью клиента: добавлять правильную заявку. У кассира есть еще одна цель — блокировать неправильную заявку; понятно, чтобы их далее не обрабатывать.

    Поэтому 2 части: 1) добавлять заявку; 2) проверять заявку

    Поделиться:

    Цитировать

    04.06.2012 в 19:51 # 5988
    Аватар (Igor Tkachenko)
    Igor Tkachenko
    Подписчик
    Посвятите: а почему обрабатывать заявки это бизнес-цель?
    Поделиться:

    Цитировать

    04.06.2012 в 20:49 # 5989
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Посвятите: а почему обрабатывать заявки это бизнес-цель?

    Обрабатывать заявки не является бизнес-целью. Бизнес-цель — добавлять (принимать) правильные заявки. Каждая правильная заявка создает доходы. Каждая неправильная — расходы.

    Поделиться:

    Цитировать

    05.06.2012 в 08:54 # 5990
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик
    Пришел Андрей и добавил бочку неразберихи. Неразбериха была зачетная *drink*

    Я бы предложил выделить следующие вопросы:

    · Что является бизнес-процессом/бизнес-процессами, их границы.
    · Как эти бизнес-процессы реализуются системными процессами, какие границы будут у этих системных процессов.

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

    Поделиться:

    Цитировать

    05.06.2012 в 12:19 # 5991
    Аватар (AndrewK)
    Андрей Курьян
    Участник

    Пришел Андрей и добавил бочку неразберихи. Неразбериха была зачетная *drink*

    Я бы предложил выделить следующие вопросы:

    · Что является бизнес-процессом/бизнес-процессами, их границы.
    · Как эти бизнес-процессы реализуются системными процессами, какие границы будут у этих системных процессов.

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

    С нетерпением жду ответы на поставленные вопросы *dance*

    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 16)

Вы должны авторизироваться для ответа в этой теме.