Клиентские сценарии это

Как
правило, Веб-приложение — приложение, в
котором клиентом
выступает браузер,
а сервером
— веб-сервер.

Рассмотрим
типы программ, обеспечивающих работу
Веб и использующих HTTP-протокол.

Никакой
HTTP-обмен невозможен без клиента и
сервера. Однако помимо клиента и сервера
в веб-сеансе могут участвовать и другие
программы, которые и являются объектом
веб-программирования.

Результатом
работы веб-приложения является
веб-страница, отображаемая в окне
браузера. При этом само веб-приложение
может выполняться как на компьютере
клиента, так и на компьютере сервера.

Рассмотрим
подробнее обе схемы.

1. Программы, выполняющиеся на клиент-машине

Одним
из типов программ, предназначенных для
выполнения на клиент-машине, являются
сценарии,
например, JavaScript (VBScript).
Исходный текст сценария представляет
собой часть веб-страницы, поэтому
сценарий JavaScript передается клиенту
вместе с документом, в состав которого
он входит. Обрабатывая HTML-документ,
браузер обнаруживает исходный текст
сценария и запускает его на выполнение.

Ко
всем программам, которые передаются с
сервера на клиент-машины и запус­каются
на выполнение, предъявляется одно общее
требование: эти программы
должны быть лишены возможности обращаться
к ресурсам компьютера, на котором они
выпол­няются.
Такое требование вполне обосновано.
Ведь передача по сети и запуск Java-апплетов
и JavaScript-сценариев происходит автоматически
без
участия пользователя,
поэтому работа этих программ должна
быть абсолютно
безопасной для компьютера.
Другими словами, языки, предназначенные
для создания программ, выполняющихся
на клиент-машине, должны быть абсолютно
непригодны для написания вирусов и
подобных программ.

2. Программы, выполняющиеся на сервере

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

Результаты
своей работы программа оформляет в виде
HTML-документа и передает их веб-серверу,
а последний, в свою очередь, дополняет
полученные данные HTTP-заголовком и
передает их клиенту. Взаимодействие
клиен­та и сервера в этом случае
показано на рисунке 1.

Рисунок
1.
Взаимодействие клиента с программой,
выполняющейся на сервере.

3. Насыщенные интернет-приложения

Насыщенное
интернет-приложение
(Rich Internet application) – еще один подход, который
заключается в использовании Adobe
Flash
или Java-апплетов
для полной или частичной реализации
пользовательского интерфейса, поскольку
большинство браузеров поддерживает
эти технологии (как правило, с помощью
плагинов).

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

При
использовании Java-апплетов в состав
HTML-документа включается специальный
дескриптор, описывающий расположение
файла, содержащего код апплета,
на сервере. После того как клиент получает
HTML-код документа, включающего апплет,
он генерирует дополнительный запрос
серверу. После того как сервер пересы­лает
клиенту код апплета,
сам апплет
запускается на выполнение. Взаимодействие
между клиентом и сервером при получении
апплета
показано на рисунке 2.

Рисунок
2.
Передача клиенту Java-апплета.

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

• необходимость
  обеспечения безопасной среды выполнения
  («песочница»);

• для
  исполнения кода должно быть разрешено
  исполнение сценариев;

• потеря
  в производительности (т.к. выполяется
  на клиентской стороне);

• требуется
  много времени на загрузку;

Для
разработки насыщенных интернет-приложений
используются пакеты Curl,
Adobe
Flex
и Microsoft
Silverlight.

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.

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

Прежде чем разработать сценарий, нужно ответить на три вопроса:

1. Кто те люди, что заходят на ваш сайт?

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

2. Почему они заходят к вам?

На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.

3. Какие цели при этом преследуют и как их достигают?

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

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

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

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

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

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

Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.

Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.

Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».

Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:

Создаются с помощью объединения похожих пользовательских историй и отсечения лишнего и несущественного. Такой подход обобщает множество пользовательских историй в несколько сценариев. Например, таких: «Пользователь готовит деньги заранее, ищет через форму поиска, имеет ограниченный бюджет — сразу использует фильтры, принимает решение долго, несколько раз заходит в корзину и сравнивает товары».

А вот, например, шаги сценария, подготовленные при изучении сайта по аренде автокранов. Пользователи выделили вопросы, которые для них важны, теперь можно расписывать разные сценарии поведения.

Составляются уже с позиции персонажа (персоны покупателя). Еще меньше абстракции и больше конкретики. Каждой группе ЦА сопоставляется персонаж, далее прописывается его путь достижения цели.

Могут добавляться ограничения: например, проработка только варианта заказа с планшета или со смартфона.

Опишите пользовательский опыт по шагам: кто, каким образом и в какой последовательности делает. Это должен быть наиболее детализированный и технически проработанный вариант.

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

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

«Общение» пользователя и терминала по приему платежей:

Еще сценарий от uxforthemasses.com:

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой. 

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

2. Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)

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

1. Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

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

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.

2. Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

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

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

Клиентские сценарии и приложения

Веб-приложение, в котором клиентом выступает браузер, а сервером — веб-сервер.

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

Результатом работы веб-приложения является веб-страница, отображаемая в окне браузера. При этом само веб-приложение может выполняться как на компьютере клиента, так и на компьютере сервера.

Вопрос 1: На каком компьютере может выполняться веб-приложение?

Программы, выполняющиеся на клиент-машине Одним из типов программ, предназначенных для выполнения на клиент-машине, являются сценарии, например, Java. Script (VBScript). Исходный текст сценария представляет собой часть веб-страницы, поэтому сценарий Java. Script передается клиенту вместе с документом, в состав которого он входит.

Обрабатывая HTML-документ, браузер обнаруживает исходный текст сценария и запускает его на выполнение.

Ко всем программам, которые передаются с сервера на клиент- машины и запускаются на выполнение, предъявляется одно общее требование: эти программы должны быть лишены возможности обращаться к ресурсам компьютера, на котором они выполняются.

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

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

Результаты своей работы программа оформляет в виде HTML-документа и передает их веб-серверу, а последний, в свою очередь, дополняет полученные данные HTTP-заголовком и передает их клиенту.

Взаимо действи е клиента с програм мой, выполня ющейся на сервере

Насыщенные интернет-приложения Насыщенное интернет-приложение (Rich Internet application) – еще один подход, который заключается в использовании Adobe Flash или Java-апплетов для полной или частичной реализации пользовательского интерфейса, поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов).

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

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

После того как сервер пересылает клиенту код апплета, сам апплет запускается на выполнение.

Передача клиенту Java- апплета

Проблемы с которыми сталкиваются при использовании насыщенных интернет-приложений • необходимость обеспечения безопасной среды выполнения («песочница»); • для исполнения кода должно быть разрешено исполнение сценариев; • потеря в производительности (т. к. выполяется на клиентской стороне); • требуется много времени на загрузку

Для разработки насыщенных интернет-приложений используются пакеты Curl, Adobe Flex и Microsoft Silverlight

Введение в JScript Java. Script — интерпретируемый язык программирования, стандартизированный международной организацией ECMA в спецификации ECMA-262. Языки Java. Script, JScript и Action. Script являются расширением стандарта ECMA-262.

Название «ECMAScript» явилось фактически компромиссом между организациями, вовлеченными в процесс стандартизации, в частности Netscape и Microsoft. Хотя Java. Script и JScript стремились к совместимости с ECMAScript, они имеют ряд дополнительных возможностей не предусмотренных спецификацией ECMA.

Синтаксис JScript во многом аналогичен языку Java. Script, однако, помимо добавления клиентских скриптов на веб-страницы и некоторых других функций, JScript может использоваться и для других целей, например: • автоматизация администрирования систем Microsoft Windows; • создание страниц ASP.

Вопрос 2 : • Какие задачи позволяет решать использование языка JScript?

Язык JScript получил дальнейшее развитие в виде языка JScript. NET, который ориентирован на работу в рамках платформы Microsoft. NET

JScript — интерпретируемый, объектно-ориентированный язык. Хотя он имеет существенно меньшее количество возможностей, чем такие объектно-ориентированные языки как C++ и Java.

Вопрос 3 Какие из указанных языков программирования являются объекто- • C++ ориентированными? • Java • JScript

Возможности языка существенно ограничены: • язык не позволяет разрабатывать самостоятельные приложения; • сценарии на JScript могут выполняться только при помощи интерпретатора, в частности веб-браузером. • JScript — язык без строгого контроля типов. Поэтому не требуется объявлять тип переменных явно. Кроме того, во многих случаях JScript исполняет преобразования автоматически, когда они необходимы. Например, при сложении строки и числа, число будет преобразовано в строку.

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

Для объявления конца инструкции используется точка с запятой ; . Группа JScript-инструкций, заключенная в фигурные скобки {}, называется блоком.

Комментарием в JScript является текст, расположенный после // до конца строки. Многострочный комментарий начинается с /*, и заканчивается */.

Знак равенства (=) используется в JScript как присваивание. Следующий код Pi = 3. 14; подразумевает «Присвоить значение 3. 14 переменной Pi».

При сравнении двух значений на равенство применяется двойной знак равенства (==). JScript выражения можно разделить на логические или числовые. Выражения содержат некоторые особенности, к примеру, символ «+» означает «добавить к. . . «. Любая допустимая комбинация значений, переменных, операторов, и других выражений является выражением.

Объявление переменной перед использованием является необязательным. Для этого используется инструкция var. Инструкция var является обязательной при объявлении локальной переменной внутри функции. Разрешается объявление переменной неявно — без инструкции var. Однако, в выражениях применять необъявленные переменные не допускается. JScript различает регистр в имени переменной. Name и name рассматриваются как различные переменные.

Типы данных JScript — язык с нестрогим контролем типов, переменные в JScript не имеют строго фиксированного типа. Переменные имеют тип, эквивалентный типу значения, которое они содержат. Однако, в некоторых случаях, необходимо принудительное преобразование переменной в определенный тип. Числа могут быть объявлены как строки, а строки необходимо преобразовать в числовой тип. Для этого применяют функции parse. Int() и parse. Float().

Вопрос 4 Отметьте верные утверждения: • JScript — интерпретируемый язык • JScript — объектно- ориентированный язык • переменные в JScript не имеют строго фиксированного типа

В JScript используется шесть типов данных. Основные из них — числа, строки, объекты, логический. Остальные два — null и undefined (т. е. неопределенный).

Строки объявляются при помощи двойных кавычек или апострофов. Строка может состоять из нуля или более символов unicode. Когда количество символов равно нулю, это называется пустой строкой («»).

JScript поддерживает числа как целые, так и с плавающей запятой. Также существуют специальные представления чисел, например Na. N (не число).

Примеры чисел: 3. 14 // Вещественное число 26 // Целое число 0177 // Восьмеричное число 0 XA 8 // Шестнадцатиричное число

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

Undefined – означает, что тип не определен. Значение undefined имеет переменная после ее объявления и до присвоения ей какого-либо определенного значения. Переменная типа null — не имеет никакого определенного значения.

Операторы Язык поддерживает условные выражения if и if. . . else. При использовании нескольких условий одновременно можно использовать операторы || (ИЛИ ) или && (И).

В JScript поддерживается несколько типов циклов: for, for. . . in, while, do. . . while и switch. Также существует инструкция остановки выполнения цикла. Оператор завершения break может использоваться, чтобы остановить цикл, при выполнении какого-либо условия. Инструкция continue используется, чтобы немедленно перейти к выполнению следующей

Функции и объекты В JScript имеется два вида функций: встроенные и определяемые. Программист имеет возможность создавать собственные функции. Определение функции состоит из объявления параметров и блока инструкций JScript.

Объекты в JScript, по-сути, являются совокупностями методов и свойств. Все объекты можно разделить на три вида: встроенные, созданные и браузерные. Обработка объектов и массивов идентична. Можно обратиться к любой части объекта (его свойствам и методам) либо по имени, либо по индексу. Нумерация индексов в JScript начинается с нуля.

Краткая характеристика VBScript Visual Basic Scripting Edition (обычно просто VBScript) — сценарный язык программирования, интерпретируемый компонентом Windows Script Host. Он широко используется при создании скриптов в операционных системах семейства Microsoft Windows.

Язык был создан компанией Microsoft как замена устаревшему пакетному языку, интерпретируемому приложением command. com. Синтаксис VBScript является упрощенной версией синтаксиса языка Visual Basic.

Сценарии на языке VBScript чаще всего используются в следующих областях, использующих программные продукты Microsoft: • автоматизация администрирования систем Windows; • серверный программный код в страницах ASP; • клиентские сценарии в браузере Internet Explorer.

Вопрос 5 Отметьте неверные утверждения: • VBScript — объектно-ориентированный язык • VBScript интерпертируется приложением command. com • синтаксис VBScript является упрощенной версией синтаксиса языка Visual Basic

Java-апплеты Java-апплет — это программа, написанная на языке Java и откомпилированная в байт-код. Выполнется в браузере с использованием виртуальной Java-машины (JVM). Апплеты используются для предоставления интерактивных возможностей веб-приложений, которые не возможны в HTML. Так как байт-код Java платформо-независим, то Java- апплеты могут выполняться браузерами на многих операционных платформах.

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

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

Апплет может быть внедрен в веб-страницу с помощью использования HTML тэга , или (что рекомендуется) тэга

1. Составить общее представление о продукте.
Система может состоять из множества компонентов, а вся команда, включая аналитика, должна знать, как они работают. Например, в какой базе данных хранится нужная информация или в какую подсистему нужно отправить запрос для выполнения расчётов. Если команде нужно понять, как обычный человек взаимодействует с ПО, поможет use case.

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

Часто команды, которые давно разрабатывают продукт, говорят: «Нам это приложение уже как родное, мы знаем, как и что должно в нём работать. Давайте как-нибудь без юзкейсов. Сразу будем делать задачки». Однако в большом потоке задач можно упустить разные сценарии использования и забыть, что пользователи не идеальны и могут ошибаться, а системы не всегда выдают тот результат, который устроит пользователя. Например, при поиске авиабилетов пользователю может не подойти ни один из вариантов перелёта. Нужно предусмотреть, чтобы была возможность скорректировать параметры поиска.

3. Иногда помочь тестировщику.
Юзкейс может использовать тестировщик, когда проверяет готовую задачу. В этом случае use case — это классический тест-кейс. Тестировщик идёт по нему, и если что-то в продукте работает не так, как описано, пишет в баг-репорте: ожидаемое действие такое, фактическое — другое. В документе он ссылается на юзкейс.

Как системные аналитики пишут use case

Допустим, аналитик пришёл в команду, которая разрабатывает приложение для такси. Разработка use case пройдёт в несколько этапов:

1. Сбор информации

Перед тем как писать use case, аналитик должен собрать:

● требования того, что хочет получить бизнес;

● пользовательские требования, что хочет получить от системы пользователь. Например, доехать на такси из точки А в точку В, выбрать из нескольких тарифов, расплатиться картой, наличными или бонусами.

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

Пользовательские требования бизнес-аналитик и системный аналитик формируют вместе. Если аналитиков на проекте нет, то эта задача может лечь на менеджера проекта или UX/UI-дизайнера, который глубоко погрузился в тему и проводил исследования с пользователями. Например, выяснил, что люди хотят доехать из точки А в точку В, но им не нравится заказывать такси по телефону.

2. Общая картина в виде диаграммы

Системный аналитик работает по принципу от общего к частному: сначала описывает задачу в целом, а затем постепенно детализирует её до мельчайших подробностей.
Составить общую картину помогает use case диаграмма. На ней отображаются все участники процесса, все варианты использования ПО, а иногда и системы, которые отвечают за сервис.

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

Элементы текстового use case

Для текстовых use case используют стандартные шаблоны, которые можно менять для команды или проекта. В одних компаниях шаблоны очень подробные, другие сокращают их до минимума, но есть обязательные поля, которые важно заполнять в любом use case.

Примеры написания use case

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

В каждой компании или команде по-разному адаптируют стандартные шаблоны юзкейсов. Главное для системного аналитика — понять, какой шаблон нужен именно для его проекта.

Вот подробный пример use case для интернет-магазина — новичку лучше начать с такого шаблона.

Use case, из-за которого пользователь не придёт туда, куда нужно

В результате сценария использования все участники процесса должны понять, что use case успешно завершён, а пользователь получит результат, который описан в пункте «гарантии успеха».
Если убрать из описания пункты «Пользователь перемещает товар в корзину» и «Система добавляет товар (-ы) в состав корзины пользователя», получится, что гарантий успеха нет, и пользователь может не увидеть товар в корзине.

Use case, который приведёт к ошибкам в разработке

Классическая ошибка, которая почти всегда приводит к проблемам, — в юзкейсе нет поля с расширениями, то есть альтернативными сценариями. В примере ниже забыли описать ситуацию, когда нужного количества товара нет в наличии. Значит, в корзину могут положить товара больше, чем есть на складе. Придётся потом объяснять пользователю, почему компания не может привезти заказ.

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

Правила написания use case и несколько советов, как сделать его лучше

● Читать теорию. Новичкам стоит начать с книги Карла Вигерса «Разработка требований к программному обеспечению» — это библия системного аналитика. По шаблонам из этой книги учат в Практикуме и других школах. Принципы Вигерса используют в компаниях в России и по всему миру.

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

● Не усложнять. Если хорошо знать теорию, то в структуре юзкейса разобраться просто. Главное — формулировать мысль так, чтобы коллеги её поняли. Не нужно писать слишком подробно или использовать деепричастные обороты, как в художественных произведениях. Предложения должны просто и коротко описывать, что должен сделать пользователь и что должна ответить система.

● Развивать насмотренность. Художники и дизайнеры постоянно смотрят чужие работы, чтобы развиваться. То же самое полезно делать и начинающим системным аналитикам — вбивать в поисковую строку «Use case варианты и примеры» и смотреть как можно больше чужих юзкейсов.
● Писать юзкейсы по другим продуктам. Если аналитик видел аналогичный продукт или функциональность, полезно зайти в этот сервис, пройти путь пользователя и составить по нему юзкейс. Так можно получить важные подсказки по проекту.

Центром любого дизайн-проекта является пользователь.

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

Чтобы понять, как этот метод изучения пользовательского опыта (User Experience, UX) реально помогает создавать удобные интерфейсы, рассмотрим несколько основных моментов, включая определение пользовательских сценариев, их роль в UX-дизайне, отличие от пользовательских историй и многое другое.

Содержание статьи

Что такое пользовательские сценарии?

Зачем нужны сценарии?

Как создать пользовательский сценарий

Отличие пользовательского сценария от пользовательской истории

Привлекаем команду контроля качества

Заключение

Что такое пользовательские сценарии?

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

Создание сценариев требует особого мышления: необходимо сосредоточиться на целях пользователей. Чего они будут пытаться достичь на вашем сайте или в приложении? Будет ли ваш продукт им полезен? Также важно подумать о сопровождающем их контексте (нюансы поведения и использования продукта, условия, влияющие на UX), их предыдущих знаниях и опыте.

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

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

Зачем нужны сценарии?

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

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

Пользовательские сценарии также применяются для определения наиболее важных для юзабилити-тестирования областей, они позволяют понять, как именно должен проводиться каждый тест.

Благодаря сценариям мы можем определить:

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

Как создать пользовательский сценарий

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

1. Решите, какие сценарии создавать, отталкиваясь от наиболее значимых действий каждого вида персон.

2. Напишите правдоподобную историю, содержащую:

• сюжет (триггеры, действия, достигнутая цель);
• контекст использования (где? когда? каковы окружающие пользователя условия?);
• мотивации, причины;
• ответ на вопрос: как продукт/сервис помогает достигнуть конечной цели?

5. Уберите все, что не вписывается в сценарий.

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

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

Отличие пользовательского сценария от пользовательской истории

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

Пользовательские истории:

• короче (как правило, одно предложение), не содержат деталей о пользователе и его прошлом опыте, мыслях и мотивациях;
• с точки зрения пользователя описывают некую потребность, которая должна удовлетворяться вашим продуктом;
• представлены прямой речью самого пользователя.

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

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

Отличие сценария от примера использования

Пример, или кейс, использования (Use Case) — это, скорее, технический план, чертеж проекта, в центре которого находятся функции, а не чувства и мысли. Кейсы представляют собой список действий при взаимодействии человека с системой.

Привлекаем команду контроля качества

Над пользовательскими сценариями обычно работают координатор или менеджер проекта, а также UX- и UI-разработчики. Специалисты по контролю качества (QA, Quality Assurance) или, попросту говоря, тестировщики привлекаются не всегда, хотя именно они знают каждый кейс и каждое условие (позитивное или негативное) с точки зрения пользователя. С их помощью вы будете писать более точные сценарии.

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

Почему этот шаг действительно важен?

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

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

1. Изучите своих пользователей, их привычки и потребности.

2. Начните сами использовать продукт всеми возможными способами. Представьте, что вы и есть тот самый пользователь, который при этом хочет сделать что-то на вашем сайте или в приложении.

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

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

5. Придумайте как можно больше негативных кейсов. Такой подход позволяет обнаруживать больше пробелов.

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

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

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

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

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

Заключение

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

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

По материалам: interaction-design.org, uxknowledgebase.com, uxplanet.org 

17-10-2021

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой. 

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя. 

Один сценарий использования имеет несколько потоков: основной и альтернативные. 

Выделение сценариев 

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

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

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

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

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

2. Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)

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

1. Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

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

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов  с высоким уровнем риска. 

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

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

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

 Пример: 

UC-1. Регистрация в личном кабинете 

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину 

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”. 

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

1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.

2. Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка  “добавил товар в корзину” неверная. 

Правильно:  “нажимает на кнопку “Добавить товар в корзину” и далее-  реакцию системы на действия пользователя. 

Альтернативные сценарии 

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария. 

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пример альтернативного сценария 

Альтернативный сценарий №1 

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации. 

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

2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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