В теме 15 ответов, и 7 участников, последнее обновление сделано пользователем 
Елена Гунёва 12 г, 1 мес. назад.
-
Сообщения
-
Всем доброе время суток!
Недавно посетила один интересный тренинг по анализу пользовательских требований с помощью Use Cases, после которого у меня остался вопрос, который я хочу обсудить с вами. Вопрос возник во время анализа системы кратко описанной ниже (ненужные моменты опущены
). Итак, система. Web система позволяет бронировать билеты. Однако, в процессе бронирования участвуют как покупатель билета, так и кассир. Процесс бронирования выглядит следующим образом:
1 — Покупатель создаёт заявку на бронь билетов
2 — Кассир находит эту заявку в списке заявок
3 — Кассир обрабатывает заявку, звонит покупателю, покупатель подтверждает бронь, кассир бронирует билетыЕсли применять технику Use Cases(UC), то возможны как минимум следующие варианты при описании бронирования билетов:
1 — один UC — "забронировать билеты",
2 — два UCs, первый — "забронировать билеты", который включает второй — "обработать заявку",
3 — два UCs, первый — "создать заявку", второй — "обработать заявку".Внимание вопрос, какой из вариантов правильный и почему?
Если абстрагироваться, должны ли возможности будущей системы влиять на на пользовательские требования? Ведь в данном примере, с одной стороны цель пользователя — "забронировать билеты", НО систем не должна давать ему возможности сделать это самому.Прежде, чем отвечать на вопросы, хотелось бы уточнить, бы говорим о Business Use Cases или System Use Cases?
Как, зачем и для кого будут далее использоваться данные Use Cases?Забыла уточнить
, на тренинге мы обсуждали только системные юз кейсы.
Заказчик будет утверждать эти System Use Cases, разработчики будут разрабатывать систему по ним (и не только по ним).
/me запасся попкорном
В качестве системных лично я бы выбрал третий вариант. В качестве бизнес (который реализуется при помощи 2х системных) — 1ый./me открыл бутылочку пивка и расположился рядом с Денисом (:
Ещё полезно ознакомиться с главой 5 "Три поименованных уровня цели" книги "Современные методы описания функциональных требований", Алистер Коберн (2002)А если отвечать на вопрос "какой из вариантов правильный и почему?": Все правильные, каждый в своем контексте.
ИМХО,
бизнес-процесс включает:
1. Создание заявки клиентом
2. Согласование и утверждение заявки кассиромКак я понимаю, дальнейшая жизнь заявки в рамках кейса не рассматривается.
На уровне бизнес-требований я бы выбрал вариант 3.Для создания заявки пользователю наверняка понадобится только заполнить одну форму на какой-то странице (на которую он явно легко должен попасть).
Поиск и обработка заявки также, думаю, подразумевают работу кассира на одной-двух страницах. Поэтому весьма вероятно, что и одного юзкейса будет достаточно.
Пусть будет несколько альтернативных сценариев, если понадобится.
Юзкейс для заказчика будет понятен (а еще более понятная диаграмма активностей, но раз тренинг этого не подразумевает, то ограничимся юзкейсом).С другой стороны для разработчика, наверно, удобнее будет 2 юзкейса, т.к. функционал можно четко разделить: 1) логика и GUI для кассира, 2) логика и GUI для пользователя.
Второй вариант со включением одного юзкейса в другой не зря никто не рассматривает в качестве рабочего
.В итоге — 1 либо 3, если при этом объяснить, в каком контексте использовать.
Андрей!В чем бизнес-требования в варианте 3? У пользователя бизнес-цель добавлять заявки в систему? У кассира или владельцев системы бизнес-цель обрабатывать заявки? Процесс-то единый, а уже на этапе реализации нам удобнее это разнести на 2 системных кейса, и то, только потому что у нас реализация явно раздельная.
з.ы. что самое интересное — все сразу включают "реализаторку" и начинают проектировать приложение. Предположим, в данном случае оно вроде более-менее очевидно. А если мы начинаем работать над проектом, в котором вариант реализации ещё нифига не очевиден?
доброго дня)Исходя из условий задачи, я бы выбрала вариант 3:
1) отталкиваясь от primary actors — их тут 2 — покупатель и кассир — поэтому и юзкейса лучше два раздельных. При этом никто не мешает слинковать эти юзкейсы друг с другом. А эти два актора явно перерастут потом в пользовательские роли — два раздельных юзкейса будет просто удобнее, мне кажется.
2) лично мои убеждения, что более атомарные вещи проще реализовывать и поддерживать — поэтому 2 более мелких юзкейса (в рамках здравого смысла), лучше, чем 1 крупный.Еще я бы подумала о структуре всего документа с юзкейсами. Принцип формирования юзкейсов (их атомарность, способ связи друг с другом и т.д.) лучше бы не сильно отличались на протяжении всего документа. Так будет проще всем, кто будет создавать и работать потом с документом.
Андрей!
В чем бизнес-требования в варианте 3? У пользователя бизнес-цель добавлять заявки в систему? У кассира или владельцев системы бизнес-цель обрабатывать заявки? Процесс-то единый, а уже на этапе реализации нам удобнее это разнести на 2 системных кейса, и то, только потому что у нас реализация явно раздельная.
з.ы. что самое интересное — все сразу включают "реализаторку" и начинают проектировать приложение. Предположим, в данном случае оно вроде более-менее очевидно. А если мы начинаем работать над проектом, в котором вариант реализации ещё нифига не очевиден?
А зачем кассиру обрабатывать заявки? Какую дополнительную ценность кассир может добавить в заявку? Правильный ответ — никакой.
На самом деле, в рамках БП у кассира цель частично совпадает с целью клиента: добавлять правильную заявку. У кассира есть еще одна цель — блокировать неправильную заявку; понятно, чтобы их далее не обрабатывать.Поэтому 2 части: 1) добавлять заявку; 2) проверять заявку
Посвятите: а почему обрабатывать заявки это бизнес-цель?Посвятите: а почему обрабатывать заявки это бизнес-цель?
Обрабатывать заявки не является бизнес-целью. Бизнес-цель — добавлять (принимать) правильные заявки. Каждая правильная заявка создает доходы. Каждая неправильная — расходы.
Пришел Андрей и добавил бочку неразберихи. Неразбериха была зачетная
Я бы предложил выделить следующие вопросы:
· Что является бизнес-процессом/бизнес-процессами, их границы.
· Как эти бизнес-процессы реализуются системными процессами, какие границы будут у этих системных процессов.На мой взгляд тут каша из бизнес/системного, что приводит в размытию границ.
Пришел Андрей и добавил бочку неразберихи. Неразбериха была зачетная
Я бы предложил выделить следующие вопросы:
· Что является бизнес-процессом/бизнес-процессами, их границы.
· Как эти бизнес-процессы реализуются системными процессами, какие границы будут у этих системных процессов.На мой взгляд тут каша из бизнес/системного, что приводит в размытию границ.
С нетерпением жду ответы на поставленные вопросы
Вы должны авторизироваться для ответа в этой теме.
