Сценарии использования

Итак, выполняя действия из первой части этой статьи, мы получили список вариантов использования — действий, которые необходимо выполнять каждому пользователю в системе для получения некоторого конкретного результата.

Теперь нам нужно описать, каким образом пользователь будет получать этот результат в системе.

Описывается это в виде последовательности действий, в виде диалога пользователя с системой. Один шаг — что делает пользователь, следующий шаг — что система делает и какие дальнейшие действия предоставляет пользователю, следующий шаг — что может пользователь сделать и т.д.

Главное окно

Если говорить конкретно, то все сценарии начинаются с того, что пользователь запускает приложение. Либо его запускает кто-то другой и оно отображает некоторый начальный интерфейс, в котором пользователю доступны его варианты использования. Т.е. первый вариант использования всегда будет некий запуск системы и отображение как правило главного окна системы. Вместе с описанием этого самого окна и каким образом пользователь может начать тот или иной сценарий использования.

Непосредственно сценарии

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

После этого система предоставляет пользователю некоторое окно для того, чтобы пользователь мог выполнить свой вариант использования. Пользователь выполняет какое-то действие или набор действий в этом окне и нажимает на какую-то кнопку, после чего система выполняет в свою очередь опять набор действий и выдает пользователю следующее окно. Так продолжается до того, пока пользователь не достигнет того результата, который должен быть получен в этом варианте использования. После чего система возвращает пользователя в главное окно приложения.

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

Запутал окончательно? Тогда пример:

Задача:

Получить свободные места на определенный поезд. Это наш вариант использования. А нужен он пользователю нашей системы с ролью пассажир. Ну соответственно система наша называется Терминал покупки электронных билетов.

Сценарий:

1. Пассажир в главном окне системы нажимает кнопку Наличие мест.

2. Система отображает окно.

Здесь нужно привести некоторый прототип этого окна. В нем должны быть продуманы основные, а желательно все поля, таблицы, кнопки, которые потребуются пользователю для того, чтобы сделать следующий шаг. А следующим шагом в нашем примере является логично выбор маршрута, на который пассажир хочет выяснить наличие мест. Каким образом пассажир может выбрать требуемый поезд? Указав некоторые его параметры — период времени, в который этот поезд отправляется, откуда пассажир будет уезжать и куда ему нужно попасть. Также он может указать номер поезда. Номер поезда — это его маршрут, поэтому это альтернатива только части параметров — пункту отбытия и пункту прибытия. Т.е. окно у нас может состоять из следующих элементов:

— Выбор одного из двух параметров:

— станция отбытия и станция прибытия

— номер поезда

— Даты От и До отправления поезда

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

Номер поезда — текстовое поле.

Даты От и До — поле по нажатию на которое отображается календарь, в котором можно выбрать дату и временная лента от 0 до 24 часов, с промежутком в пол-часа, из которой можно выбрать время.

Также должна быть кнопка, нажатие на которую инициирует поиск. Назовем её (как это ни странно) «Поиск».

Всё это мы рисуем удобным нам способом и вставляем прототип окна в наш документ.

И описываем, что означают эти наши поля.

Продолжаем с нашим сценарием:

3. Пассажир вводит параметры искомого рейса и нажимает кнопку «Поиск»

4. Система находит поезда, которые соответствуют критериям поиска, т.е. все поезда, которые отправляются в заданный временной диапазон, у которых заданный номер, или которые проходят между пунктом От и пунктом До.
5. Система отображает найденные поезда в списке со следующими полями:

здесь нам нужно подумать, какие данные о поезде будут нужны пользователю в этом варианте использования и описать их как поля списка

— номер поезда

— пункт начала маршрута / пункт конца маршрута

— дата отбытия из пункта отправления пассажира

— время отбытия из пункта отправления пассажира

— дата прибытия в пункт прибытия пассажира

— время прибытия в пункт прибытия пассажира

— количество свободных мест типа плацкарт/купе/люкс

И также спроектировать, как будет выглядеть окно с нашим списком и прикрепить полученный прототип к документу

6. Пассажир выбирает наиболее подходящий ему поезд и нажимает на строку этого поезда

7. Система отображает окно с подробной информацией о свободных местах в выбранном поезде

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

Я думаю, что было бы удобно получить информацию с разбивкой по вагонам и с разбивкой по типам вагонов. Т.е. страница будет состоять из блоков, каждый из блоков начинается с номера вагона и его типа (плацкарт/купе/люкс). Далее либо можно просто написать количество свободных мест в данном вагоне, либо написать количество свободных мест по типам мест верхних/нижних/верхних боковых/нижних боковых, либо указать все номера мест от 1 до N и для каждого места указать — свободно или занято.

Соответственно готовый прототип прикрепляем к документу.

Описываем, что означают наши поля, если считаем, что что-то может показаться читателю документа не очень понятным без описания.

Вот и всё, наш сценарий описан.

Вообще говоря это основной сценарий. Могут быть и отклонения от него, например, система может не найти ничего и выдать сообщение пользователю о том, что на его запрос нет подходящих данных. Такие моменты можно также описать в документе, для того, чтобы было ясно, какое именно сообщение выдавать. Нужно ли так детально прописывать сценарий, или достаточно основного — определяется проектировщиком в зависимости от сложности задачи, от уровня взаимопонимания в команде и в общем от целей документа.

Точно также описываем все остальные сценарии использования.

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

После описания функциональности системы, или вперемешку с этим процессом, выполняется техническое проектирование системы. О котором мы расскажем в следующей статье.

Кто я?

Друзья, хочу начать с философского вопроса: а что же основное в создании информационной системы? Что мы создаем?

Я вижу ответ в том, что мы берем потребности в виде идей и создаем инструменты их реализации — информационные системы. Мы формализуем идеи и доводим их до почти физического состояния — программного продукта 🙂

Ну вот, так как же нам описать систему так, чтобы ничего не забыть?

Цели

Для этого вернемся к цели — реализация потребностей. И к целям нам нужно будет возвращаться всегда, так часто, как будем об этом вспоминать. Т.к. цели имеют свойства утопать в деталях и за деревьями можно потерять из виду лес. Поэтому в первую очередь нужно описать цели, к которым мы хотим прийти, используя эту систему. Для чего она нам нужна? В целом. Своими словами. Этому учить Вас не надо, потому что я уже вижу Ваши горящие глаза и как реализация Вашей идеи легко выливается на бумаге в виде одного-двух параграфов текста. Ведь это то, чего мы хотим 🙂

Хочу, чтобы у меня был сайт, на котором пользователи могли бы заказывать мои товары.

Хочу базу данных по клиентам.Чтобы видеть кто как с клиентами общался, что они заказывали, когда нужно связаться с клиентом.

Хочу расписание поликлиники, чтобы можно было его удобно редактировать, чтобы пациенты и врачи видели его из интернета.

И т.д.

Бизнес-процессы

Это проще, чем может показаться. Последовательность действий, которую нужно выполнить, чтобы прийти к вышеописанным целям. Кто это будет делать. И что он будет делать, чтобы прийти к результату.

Например, чтобы организовать запись пациентов к врачам, нужно сначала врачам сделать расписание своей работы, потом показать пациентам свободное время врачей, потом дать возможность пациенту записаться на свободное время к врачу. Можно еще добавить возможность заведующему просмотреть занятость врачей из расписания за прошедший месяц. Вот и всё.

Типы пользователей

Итак, наша цель — реализация некоторых потребностей. Т.е. некоторому человеку нужно выполнять некоторые действия с помощью компьютера и получать вполне определенный результат этих действий. А пользователей у информационной системы на сегодня как правило не один, а несколько.

Получается, что для описания системы, нам нужно знать, кто будет пользоваться системой. Конечно здесь имеются ввиду не имена конкретных пользователей — Иван Петрович, Василь Семеныч, а их роли — типы пользователей. Можно это назвать еще должностью человека в системе. Т.к. роль будет определять набор результатов, которые этот пользователь хочет получить от системы. Например: менеджер по продажам, бухгалтер, анонимный посетитель сайта, зарегистрированный посетитель сайта, администратор системы, руководитель компании, клиент и т.д. Все эти пользователи (роли, типы пользователей) будут пользоваться системой для получения несколько различных результатов. Хотя некоторые их потребности могут и совпадать.

Варианты использования системы

Еще нам нужно знать сами результаты, которых хочет достичь каждый тип пользователя, используя нашу систему. После того, как мы знаем, кто будет пользоваться системой, мы для каждого типа пользователя даем название каждому результату, который он должен получать, используя нашу будущую систему. Например, это может быть «Учет прихода товара», или «Поиск отеля», или «Создание нового пользователя», «Получение отчета о финансовых показателях». Мы называем возможности пользователя в системе. Или еще можно сказать, его должностные обязанности по работе с системой.

Сценарии использования

Теперь мы знаем, что каждый пользователь может получить от системы. Осталось описать, каким образом система нам может помочь в этом. Т.е. спроектировать систему, чтобы каждый пользователь мог получить от неё каждый из описанных нами результатов. Вот и всё.

Как проектировать систему на основе вышеописанного, я расскажу в следующей статье.