Сценарии использования
Итак, выполняя действия из первой части этой статьи, мы получили список вариантов использования — действий, которые необходимо выполнять каждому пользователю в системе для получения некоторого конкретного результата.
Теперь нам нужно описать, каким образом пользователь будет получать этот результат в системе.
Описывается это в виде последовательности действий, в виде диалога пользователя с системой. Один шаг — что делает пользователь, следующий шаг — что система делает и какие дальнейшие действия предоставляет пользователю, следующий шаг — что может пользователь сделать и т.д.
Главное окно
Если говорить конкретно, то все сценарии начинаются с того, что пользователь запускает приложение. Либо его запускает кто-то другой и оно отображает некоторый начальный интерфейс, в котором пользователю доступны его варианты использования. Т.е. первый вариант использования всегда будет некий запуск системы и отображение как правило главного окна системы. Вместе с описанием этого самого окна и каким образом пользователь может начать тот или иной сценарий использования.
Непосредственно сценарии
Каждый сценарий начинается с того, что пользователь инициирует свой вариант использования в системе. Как правило он может это сделать, нажав куда-то мышкой, или набрав что-то на клавиатуре и нажав Enter. Если это бизнес-приложение или сайт, то обычно это даже выбор какого-то пункта меню или переход по ссылке.
После этого система предоставляет пользователю некоторое окно для того, чтобы пользователь мог выполнить свой вариант использования. Пользователь выполняет какое-то действие или набор действий в этом окне и нажимает на какую-то кнопку, после чего система выполняет в свою очередь опять набор действий и выдает пользователю следующее окно. Так продолжается до того, пока пользователь не достигнет того результата, который должен быть получен в этом варианте использования. После чего система возвращает пользователя в главное окно приложения.
Таким образом задачей проектировщика на этом шаге является изобретение некоторых удобных интерфейсов, которые позволят системе предоставить все необходимые данные пользователю, позволят пользователю ввести все необходимые данные и позволят системе выполнить нужные пользователю действия для получения пользователем требуемого результата.
Запутал окончательно? Тогда пример:
Задача:
Получить свободные места на определенный поезд. Это наш вариант использования. А нужен он пользователю нашей системы с ролью пассажир. Ну соответственно система наша называется Терминал покупки электронных билетов.
Сценарий:
1. Пассажир в главном окне системы нажимает кнопку Наличие мест.
2. Система отображает окно.
Здесь нужно привести некоторый прототип этого окна. В нем должны быть продуманы основные, а желательно все поля, таблицы, кнопки, которые потребуются пользователю для того, чтобы сделать следующий шаг. А следующим шагом в нашем примере является логично выбор маршрута, на который пассажир хочет выяснить наличие мест. Каким образом пассажир может выбрать требуемый поезд? Указав некоторые его параметры — период времени, в который этот поезд отправляется, откуда пассажир будет уезжать и куда ему нужно попасть. Также он может указать номер поезда. Номер поезда — это его маршрут, поэтому это альтернатива только части параметров — пункту отбытия и пункту прибытия. Т.е. окно у нас может состоять из следующих элементов:
— Выбор одного из двух параметров:
— станция отбытия и станция прибытия
— номер поезда
— Даты От и До отправления поезда
Станция отбытия и прибытия должны содержать в себе возможность выбора из всего набора имеющихся станций. Т.к. станций будет много, то видимо удобно будет для этой цели использовать отдельное окно с возможностью поиска станций по первым буквам и выбора из результирующего списка.
Номер поезда — текстовое поле.
Даты От и До — поле по нажатию на которое отображается календарь, в котором можно выбрать дату и временная лента от 0 до 24 часов, с промежутком в пол-часа, из которой можно выбрать время.
Также должна быть кнопка, нажатие на которую инициирует поиск. Назовем её (как это ни странно) «Поиск».
Всё это мы рисуем удобным нам способом и вставляем прототип окна в наш документ.
И описываем, что означают эти наши поля.
Продолжаем с нашим сценарием:
3. Пассажир вводит параметры искомого рейса и нажимает кнопку «Поиск»
4. Система находит поезда, которые соответствуют критериям поиска, т.е. все поезда, которые отправляются в заданный временной диапазон, у которых заданный номер, или которые проходят между пунктом От и пунктом До.
5. Система отображает найденные поезда в списке со следующими полями:
здесь нам нужно подумать, какие данные о поезде будут нужны пользователю в этом варианте использования и описать их как поля списка
— номер поезда
— пункт начала маршрута / пункт конца маршрута
— дата отбытия из пункта отправления пассажира
— время отбытия из пункта отправления пассажира
— дата прибытия в пункт прибытия пассажира
— время прибытия в пункт прибытия пассажира
— количество свободных мест типа плацкарт/купе/люкс
И также спроектировать, как будет выглядеть окно с нашим списком и прикрепить полученный прототип к документу
6. Пассажир выбирает наиболее подходящий ему поезд и нажимает на строку этого поезда
7. Система отображает окно с подробной информацией о свободных местах в выбранном поезде
Здесь нам опять нужно придумать, как будет выглядеть окно с информацией о свободных местах
Я думаю, что было бы удобно получить информацию с разбивкой по вагонам и с разбивкой по типам вагонов. Т.е. страница будет состоять из блоков, каждый из блоков начинается с номера вагона и его типа (плацкарт/купе/люкс). Далее либо можно просто написать количество свободных мест в данном вагоне, либо написать количество свободных мест по типам мест верхних/нижних/верхних боковых/нижних боковых, либо указать все номера мест от 1 до N и для каждого места указать — свободно или занято.
Соответственно готовый прототип прикрепляем к документу.
Описываем, что означают наши поля, если считаем, что что-то может показаться читателю документа не очень понятным без описания.
Вот и всё, наш сценарий описан.
Вообще говоря это основной сценарий. Могут быть и отклонения от него, например, система может не найти ничего и выдать сообщение пользователю о том, что на его запрос нет подходящих данных. Такие моменты можно также описать в документе, для того, чтобы было ясно, какое именно сообщение выдавать. Нужно ли так детально прописывать сценарий, или достаточно основного — определяется проектировщиком в зависимости от сложности задачи, от уровня взаимопонимания в команде и в общем от целей документа.
Точно также описываем все остальные сценарии использования.
Такое описание гарантирует полное представление о системе с точки зрения требуемых функций системы и помогает в процессе проектирования выявить те детали, которые скрылись при поверхностном описании.
После описания функциональности системы, или вперемешку с этим процессом, выполняется техническое проектирование системы. О котором мы расскажем в следующей статье.