Автоматизация продажи билетов в кинотеатре

 

Основное действующее лицо: Клиент.

Другие участники прецедента: нет

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

Основой для генерирования билета и послужит этот набор предпочтений – заказ, который Клиент составляет сам (для примера – выбирает на какой сеанс пойти, какое место  в зале приобрести).

Для Атомата-Кассира этот Заказ  может представлять собой таблицу  с полями, которые заполняются  Клиентом на основе имеющихся в ИС предложений.

3.1.2 Продажа Билетов

 

2

Клиент

ProdazhaBiletov

Клиент совершает операцию купли-продажи  с целью получения билета на конкретный сеанс

 

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

3.1.3 Просмотр информации

 

3

Клиент

SeeInformation

Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра.

 

Основное действующее лицо: Клиент.

Другие участники прецедента: нет.

Связи с другими вариантами использования: отсутствуют

Краткое описание.

Данный прецедент позволяет  Клиенту получить необходимую и  достаточную информацию о репертуаре театра для составления Заказа. Клиент смотрит информацию о:

Наименование

Время начала

Длительность

Информацию о сеансе

Зал проведения

Цена билета:

Класс A

Класс B

Класс C

3.1.4 Возврат билета

 

4

Клиент

VernutBilet

Клиент возвращает билет Кассиру  с целью возврата денег

 

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир.

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

3.1.5 Бронирование билета

 

5

Клиент

BronirovanieBileta

Клиент закрепляет за собой право  покупки конкретного билета

 

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

3.1.6 Снятие Брони

 

6

Клиент

SnyatBron

Клиент снимает бронь с билета

 

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

Клиент обращается к Кассиру  с целью снятие с Билета брони. Билет возвращается в оборот купли-продажи. Клиент лишается права на этот Билет(Кроме  как в случае если Клиент снова  обратиться к Касиру с целью Купить/Забронировать Билет).

3.2 Специальные требования

3.2.1 Функциональность

3.2.1.1F1. Авторизация и аутентификация  пользователей в системе

В АИС должны быть представлены справочник ролей пользователей (Клиент, Кассир) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли.

3.2.1.3F2. Ведение расписания

В АИС должны быть представлены средства управления расписание сеансов и  информации о сеансах.

3.2.2Применимость

3.2.2.1U1. Удобство использования

Интерфейс АРМ «Клиент» и «Кассир» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей.

3.2.2.2U2. Помощь в режиме online

Все АРМ должны поддерживать контекстную  справку в форме стандартного help операционной системы.

3.2.3Надежность

3.2.3.1R1. Доступность

АРМ Клиента, Кассира быть доступны в рабочие дни в рабочее  время (как правило, с 8 до 18, если иное не указано распоряжением по предприятию).

3.2.3.2R2. Наработка на отказ

Среднее время безотказной работы – 10 рабочих дней.

3.2.3.3R3. Норма дефектов

Максимальная норма ошибок или  дефектов – 1 ошибка на десять тысяч  строк кода.

3.2.4Производительность

3.2.4.1P1. Одновременно работающие  пользователи

Система должна быть способна поддерживать минимум 100 одновременно работающих пользователей, связанных с общей базой данных.

3.2.4.2P2. Время отклика

Время отклика для типичных задач  – не более 2 секунд, для сложных  задач – не более 5 секунд.

3.2.5Пригодность к эксплуатации

3.2.5.1S1. Масштабируемость

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

3.2.5.2S2. Обновление версий

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

3.2.6Ограничения проектирования

3.2.6.1X1. Применяемые стандарты

Система должна соответствовать всем стандартам интерфейса пользователя Microsoft® Windows®, Internet Explorer®.

3.2.6.2X2. Требования к среде выполнения

Система должна удовлетворять вышеуказанным  требованиям на компьютере в следующей  минимальной комплектации:

•64 Mb памяти

•3 Mb свободного дискового пространства

•процессор с тактовой частотой 850 MHz

•Операционная система Windows ХР и выше.

3.2.6.3X3. Требования к СУБД и  доступу к данным.

В ядре системы должна быть представлена промышленная СУБД реляционного доступа.

Все обращения к информации должны осуществляться через драйвер ODBC.

4.Вспомогательная информация

Перечень вспомогательной информации представлен в п. 1.3.