Б) Подробный сценарий взаимодействия (выдержка из основного пути сценария)

I. Пользователь нажимает на ссылку на профиль одного из пользователей.

II. Система открывает страницу, которая помимо прочего содержит следующие интерактивные элементы:

1. Название ВУЗа пользователя (ссылка);

2. Добавить в друзья (ссылка).

3. Блок «Конспекты пользователя». Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:

a) Название конспекта (ссылка).

4. Остальные конспекты (ссылка);

5. Блок «Книжная полка пользователя». Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:

a) Название книги (ссылка).

6. Остальные книги (ссылка);

7. Блок «Учебные планы пользователя». Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:

a) Название учебного плана (ссылка).

8. Остальные учебные планы (ссылка);

9. Блок «Информация о пользователе». Блок помимо прочего содержит следующие интерактивные элементы:

a) Имя пользователя (ссылка);

b) Название ВУЗа пользователя (ссылка);

c) Специальность пользователя (ссылка);

d) Добавить в друзья (ссылка);

e) Блок «Материалы пользователя». Блок помимо прочего содержит следующие интерактивные элементы:

f) Конспекты (ссылка);

g) Книжная полка (ссылка);

h) Учебные планы (ссылка).

10. Блок «ВУЗы и специальности». Блок помимо прочего содержит следующие интерактивные элементы:

a) ВУЗы (ссылка);

b) Специальности (ссылка);

c) Города (ссылка);

d) Пользователи (ссылка, заблокирована).

11. Блок «Друзья пользователя». Блок помимо прочего содержит следующие интерактивные элементы:

a) Список друзей. Список элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:

a) Имя пользователя (ссылка).

b) Все друзья пользователя (ссылка).

o Альтернативный сценарий: Пользователь уже находится в друзьях у пользователя. Система заменяет ссылки «Добавить в друзья» ссылками «Удалить из друзей». Перезагрузка страницы не производится.

III. Пользователь нажимает ссылку «Добавить в друзья».

o Альтернативный сценарий: Пользователь нажимает на ссылку с названием ВУЗа пользователя.

o Альтернативный сценарий: Пользователь нажимает на одну из ссылок списка конспектов пользователя.

o Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные конспекты пользователя».

o Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Книжная полка пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные книги пользователя».

o Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Учебные планы пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные учебные планы пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку с именем пользователя.

o Альтернативный сценарий: Пользователь нажимает на ссылку с названием специальности пользователя.

o Альтернативный сценарий: Пользователь нажимает на ссылку «Конспекты» блока «Материалы пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Книжная полка» блока «Материалы пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Учебные планы» блока «Материалы пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «ВУЗы» меню раздела «ВУЗы и специальности».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Специальности» меню раздела «ВУЗы и специальности».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Города» меню раздела «ВУЗы и специальности».

o Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Друзья пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Все друзья пользователя».

o Альтернативный сценарий: Пользователь нажимает на ссылку «Удалить из друзей».

IV. Система вносит изменения в базу данных.

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


 

Сценарии, основанные на персонажах, и варианты использования

Как сценарии, основанные на персонажах, так и варианты использования (use cases) представляют собой методы описания взаимодействия пользователя с системой.

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

Варианты использования, в свою очередь, – это методика, основанная на исчерпывающем описании функциональных требований к системе, и ориентированном на низкоуровневые действия пользователя и соответствующие реакции системы. Точное поведение системы (как именно реагирует система), как правило, не является частью обычного, или конкретного, варианта использования; многие предположения относительно формы и поведения проектируемой системы остаются неявными. Варианты использования позволяют провести исчерпывающий перечень пользовательских задач для различных классов пользователей, однако мало или совсем ничего не говорят о том, как эти задачи должны быть представлены пользователю и какие приоритеты они получают в интерфейсе. Самым серьезным недостатком традиционных вариантов использования как основы для проектирования взаимодействия считают то, что все возможные взаимодействия с пользователем считаются одинаково важными и одинаково вероятными. Это происходит потому, что свое начало варианты использования берут скорее в разработке программного обеспечения, нежели в проектировании взаимодействия. Они могут быть полезны для выявления исключительных ситуаций и для определения степени функциональной завершенности продукта, однако их следует применять лишь на более поздних стадиях проверки проектных решений.

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

Действующими лицами (персонажами) являются – руководитель, администратор и тренер. На диаграмме действительно четко выделены функции, закрепленные за каждым персонажем. Но нет приоритетов. Порядка расположения и т.д.

 


 


 

Требования

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

На стадии выработки требований мы должны ответить на вопросы, начинающиеся со слова «что»:

что за функции нужны персонажам и

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

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

Смешение этих двух вопросов (что и как) может стать одной из серьезнейших ошибок при проектировании интерактивного продукта.








Дата добавления: 2016-11-02; просмотров: 933;


Поиск по сайту:

При помощи поиска вы сможете найти нужную вам информацию.

Поделитесь с друзьями:

Если вам перенёс пользу информационный материал, или помог в учебе – поделитесь этим сайтом с друзьями и знакомыми.
helpiks.org - Хелпикс.Орг - 2014-2024 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.01 сек.