Табл. 2. Реестр вариантов использования.
| Код | Основной автор | Наименование | Формулировка |
| 1 | Клиент | ZapolnenieZakaza | Клиент указывает в билете необходимую информацию, для последующего бронирования билета или его заказа |
| 2 | Клиент | ProdazhaBiletov | Клиент совершает операцию купли-продажи с целью получения билета на конкретный сеанс |
| 3 | Клиент | SeeInformation | Клиент смотрит наиболее полную информацию о сеансах,ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра. |
| 4 | Клиент | VernutBilet | Клиент возвращает билет Кассиру с целью возврата денег |
| 5 | Клиент | BronirovanieBileta | Клиент закрепляет за собой право покупки конкретного билета |
| 6 | Клиент | SnyatBron | Клиент снимает бронь с билета |
2.2 Предположения и зависимости
Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии.
В случае изменений в формах документов АИС должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы).
В случае приобретения или разработки информационных систем, автоматизирующих смежные участки, будет необходимо разработать соответствующие средства импорта-экспорта информации.
3.1 Краткие описания вариантов использования
| 1 | Клиент | ZapolnenieZakaza | Клиент указывает в билете необходимую информацию, для последующего бронирования билета или его заказа |
Основное действующее лицо: Клиент.
Другие участники прецедента: нет
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Данный вариант использования позволяет Кассиру осуществить генерирование билета или брони, на основе сформулированных предпочтений Клиента для последующей финансовой операции купли-продажи.
Основой для генерирования билета и послужит этот набор предпочтений – заказ, который Клиент составляет сам (для примера – выбирает на какой сеанс пойти, какое место в зале приобрести).
Для Атомата-Кассира этот Заказ может представлять собой таблицу с полями, которые заполняются Клиентом на основе имеющихся в ИС предложений.
| 2 | Клиент | ProdazhaBiletov | Клиент совершает операцию купли-продажи с целью получения билета на конкретный сеанс |
Основное действующее лицо: Клиент.
Другие участники прецедента: Кассир
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Клиент обращается к Кассиру с сгенерированным заранее Заказом, с целью приобрести билет на сеанс указанный в Заказе. Происходит беглая проверка корректности Заказа. Кассир принимает платеж от Клиента и генерирует Билет. В случае Автомата-Кассира существенных отличий нет.
| 3 | Клиент | SeeInformation | Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра. |
Основное действующее лицо: Клиент.
Другие участники прецедента: нет.
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Данный прецедент позволяет Клиенту получить необходимую и достаточную информацию о репертуаре театра для составления Заказа. Клиент смотрит информацию о:
Наименование
Время начала
Длительность
Информацию о сеансе
Зал проведения
Цена билета:
Класс A
Класс B
Класс C
| 4 | Клиент | VernutBilet | Клиент возвращает билет Кассиру с целью возврата денег |
Основное действующее лицо: Клиент.
Другие участники прецедента: Кассир.
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Данный вариант использования позволяет Клиенту сдать имеющийся у него действительный билет Кассиру и получить обратно средства, затраченные на его покупку. Данная операция действительна не позднее 10 минут до начала сеанса – это необходимо чтобы возвращенные билеты могли быть допущены к продаже до того момента как они станут недействительны.
| 5 | Клиент | BronirovanieBileta | Клиент закрепляет за собой право покупки конкретного билета |
Основное действующее лицо: Клиент.
Другие участники прецедента: Кассир
Связи с другими вариантами использования: отсутствуют
Краткое описание.
На основе сгенерированного ранее Заказа Клиет может закрепить за собой право на конкретный билет не совершая финансовую операцию с Кассиром. Бронь осуществляется по желанию Клиента. Бронирование действительно до того момента когда до начала сеанса остается более 20 минут. В случае если билет не выкуплен по истечению этого срока бронь автоматически снимается с целью вернуть билет в оборот купли-продажи. Если билет выкупается до этого срока, то Клиент становится обладателем билета, а Кинотеатр получает деньги.
| 6 | Клиент | SnyatBron | Клиент снимает бронь с билета |
Основное действующее лицо: Клиент.
Другие участники прецедента: Кассир
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Клиент обращается к Кассиру с целью снятие с Билета брони. Билет возвращается в оборот купли-продажи. Клиент лишается права на этот Билет(Кроме как в случае если Клиент снова обратиться к Касиру с целью Купить/Забронировать Билет).
3.2.1.1F1. Авторизация и аутентификация пользователей в системе
В АИС должны быть представлены справочник ролей пользователей (Клиент, Кассир) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли.
В АИС должны быть представлены средства управления расписание сеансов и информации о сеансах.
3.2.2.1U1. Удобство использования
Интерфейс АРМ «Клиент» и «Кассир» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей.
3.2.2.2U2. Помощь в режиме online
Все АРМ должны поддерживать контекстную справку в форме стандартного help операционной системы.
АРМ Клиента, Кассира быть доступны в рабочие дни в рабочее время (как правило, с 8 до 18, если иное не указано распоряжением по предприятию).
Среднее время безотказной работы – 10 рабочих дней.
Максимальная норма ошибок или дефектов – 1 ошибка на десять тысяч строк кода.
3.2.4.1P1. Одновременно работающие пользователи
Система должна быть способна поддерживать минимум 100 одновременно работающих пользователей, связанных с общей базой данных.
Время отклика для типичных задач – не более 2 секунд, для сложных задач – не более 5 секунд.
3.2.5Пригодность к эксплуатации
Система должна быть способна поддерживать минимум 100 одновременно работающих пользователей, связанных с общей базой данных и иметь возможность увеличить их количество на случай увеличения штата сотрудников предприятия.
Обновление версий должно осуществляться в автоматизированном режиме на основе системы контроля версий и системы (сервера) обновления версий на рабочих местах пользователей.
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.
Перечень вспомогательной информации представлен в п. 1.3.