Изучение методов формирования требований к программному обеспечению, страница 2

2.  Добавление, модификация, удаление информации о кинотеатре

Ответственный за формирование репертуара

1. Получить информацию о посещаемости

Оценка идей:

Сначала строим таблицу внутри/вне (только для Зрителя)

№	Функции (потребности)	Внутри	Вне
1	Заказ (бронирование) билетов,	+
2	Просмотр репертуара,	+
3	Просмотр анонсов фильмов,	+
4	Просмотр рекламных роликов,	+
5	Просмотр планов залов,	+
6	Просмотр информации о предоставляемых скидках,	+
7	Просмотр справочной информации (как проехать, как связаться и т.д.),	+
8	Оплата билетов,		+
9	Оформление доставки билетов		+
10	Регистрация в системе	+
11	Отмена бронирования	+

Затем, для тех функций которые внутри системы

Используем вариант оценки по степени важности функций: критическая, важная, полезная. Каждому участнику дается треть голосов типа критическая, треть важная, треть – полезная. Он их расставляет. Потом производится сложение голосов: критические*9 + важные*3 + полезные.

Каждому даем 2 критические, 2 важные, две полезные.

В результате голосования отбираем 6 – 7 функций. Обязательно должны остаться:

1.  Заказ (бронирование) билетов,

2.  Просмотр репертуара,

3.  Просмотр анонсов фильмов,

4.  Просмотр планов залов,

5.  Регистрация в системе

6.  Отмена бронирования

На основании выявленных потребностей формируем варианты использования

Разработка диаграммы вариантов использования.

Варианты использования оформляются в виде Use Case диаграммы. Фрагмент диаграммы:

Затем строим варианты использования для  бронирования билетов и авторизации

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

Основное действующее лицо: зритель

Участники и интересы:

Область действия: система «БРОБИЛ»

Уровень: пользовательский

Гарантия успеха:

Зритель забронировал необходимое количество билетов на интересующий его фильм и сеанс.

Предусловие: Зритель зарегистрирован в системе

Зритель выбрал кинотеатр, фильм и сеанс

Триггер: Зритель активизировал элемент интерфейса  «заказ билетов».

Основной сценарий:

1. Система проводит авторизацию зрителя
2. Система предоставляет зрителю план зала
3. Зритель выбирает места и помечает их для бронирования
4. Система выводит информацию о забронированных билетах и предлагает зрителю подтвердить бронирование.
5. Зритель подтверждает бронирование
6. Система записывает информацию о заказе, выдает номер заказа и прекращает выполнение процедуры заказа

Расширения:

3а. Зритель не находит устраивающих его мест

3а1. Зритель сообщает о прекращении процедуры заказа

3а2. Система прекращает выполнение процедуры заказа.

5а. Зритель не подтверждает бронирование

5а1. Система уведомляет зрителя, прекращает выполнение заказа

Авторизация

Основное действующее лицо: пользователь

Гарантия успеха: пользователь авторизовался

Триггер: пользователь входит в систему

Основной сценарий:

1.  Система предоставляет форму для авторизации

2.  Пользователь вводит имя пользователя и пароль

3.  Пользователь подтверждает введенную информацию

4.  Система авторизует пользователя

Расширения:

3 а  Пользователь отказывается от авторизации

3 а 1. Система возвращается на предыдущий уровень

3 b. Пользователь забыл пароль

3 b 1  Пользователь выбирает элемент интерфейса «Забыл пароль»

3 b 2  Система предоставляет форму «Забыл пароль», содержащую информацию об    адресе администратора, к которому может обратиться пользователь

3 b 3  Пользователь нажимает кнопку «Ok»

3 b 4  Система возвращается на предыдущий уровень

4 a. Пользователь вводит неправильное имя пользователя или пароль

4 a 1. Система выводит сообщение об ошибке и предоставляет форму еще раз

4 b. Пользователь превышает лимит попыток авторизации

4 b 1. Система выводит сообщение, блокирует имя пользователя и возвращается на предыдущий уровень

1.  Формирование функциональных требований. Формируется только та часть URS, которая содержит перечень нумерованных пользовательских требований. Требования формируются в виде: