Сценарии взаимодействия. Пара слов перед большой статьей
Сценарии взаимодействия или использования — отличная связка внешних (схемы страниц и визуальный дизайн) и внутренних спецификаций (техническое задание и вспомогательные документы). Они описывают, как и какие функции системы должны работать, чтобы интерфейс воспринимался целостным и логичным. Я собирался написать длинный материал о подходах к написанию таких сценариев, но после новогодней паузы осилить такой объем непросто. Так что для начала — нулевая часть этой тройной статьи, которая выйдет на следующей неделе. И мне раскачаться, и вам убедиться что блог не умер.
Форматов описания сценариев взаимодействия много и я в работе пользуюсь большинством из них. Для каких-то проектов используются варианты попроще, для каких-то — более проработанные. Главное, чтобы логика работы пользователя с системой была понятно и недвусмысленно описана. Если схемы страниц (wireframes) показывают, какую информацию и элементы управления содержат страницы системы, то сценарии взаимодействия — как работают эти элементы управления и в каких случаях выводится та или иная информация.
Если не считать этапа проработки концепции проекта, проектирование начинается как раз с создания сценариев взаимодействия. Сперва это просто перечень сценариев, затем — краткое текстовое описание наиболее общих из них. По ходу проектирования создаются все более подробные версии этих документов. Цель — наиболее подробное пошаговое описание алгоритма работы пользователя с каждой из функций.
Для описания модуля новостей на простом корпоративном сайте достаточно будет пары предложений. Например, “Пользователь может читать новости компании. Каждая новость имеет отдельную страницу.”. Если это новостной портал с возможностью комментирования и рейтингования материалов, описание будет уже посерьезнее. Неплохо бы расписать принципы работы комментариев и рейтингов, имеющиеся ограничения. Здесь уже парой фраз не обойтись, иначе в документации будет белое пятно. И либо разработчик заделает его по своему усмотрению, либо эти новые работы обнаружатся аккурат перед сдачей проекта. А если бизнес-логика функциональности достаточно сложна, без основательной детализации сценариев никак.
Я использую два подхода к написанию сценариев взаимодействия — use cases и user stories. Первый используется достаточно давно, второй выработался в относительно новых гибких методологиях разработки. Необходимости четко придерживаться стандартов у меня нет, так что за основу берется их основная идея, а остальное — как удобнее для проекта. Use cases — способ более дотошный, но менее гибкий. У меня это описанный в текстовом виде пошаговый алгоритм действий пользователя, каждому из которых соответствует реакция системы. User stories подходят к вопросу с другой стороны — здесь действия пользователя показаны без четко определенного порядка. Это скорее перечень того, что пользователь может делать в системе.
Большая часть документов — это текстовые описания. Но и диаграммы тоже здорово помогают в работе. Правда, о них уже лучше в основной части статьи. В правильный ритм письма я как раз отлично влился.
Подпишитесь на RSS-ленту блога, чтобы сразу получать свежие записи
January 30th, 2008 at 22:28
Use Case - это не часть UML.
January 31st, 2008 at 0:11
netklon,
Это как это так?
Вот хотя бы иллюстрация из статьи в Википедии:
January 31st, 2008 at 15:48
(-; Ну и? На картинке написано “Use Case Diagram”. Use Case - это описание варианта использования, а уж в каком виде оно представлено - графически ли с помощью UML, или написано на бумаге - другой вопрос.
User Story кстати - это частный случай Use Case.
January 31st, 2008 at 16:15
netklon,
Согласен, неточность — исправляю. Хотя я пользуюсь и текстовым описанием, и диаграммами. Про user stories — да, частный случай, но лучше выделить его в отдельное понятие чтобы не мешать.
February 2nd, 2008 at 22:57
Точно следовать терминам необходимо лишь при составлении “руководящий документов”, ТЗ, “постановок задач”, и местных стандартов. Здесь же главное чтобы бы было понятно. Когда ждать полной статьи?
February 4th, 2008 at 10:56
Алексей,
Да и в случае ТЗ и постановки задач можно быть гибким
Полная статья будет на следующей неделе — сейчас готовлю запуск еще одного связанного с интерфейсами проекта. Очень хочется чтобы на следующей неделе он уже работал — так что основные силы уходят туда. Там воздастся всем за ожидания — будет много и интересно 
Ну а на этой будет промежуточный материал, тоже, думаю, неплохой 
February 6th, 2008 at 19:35
Насколько мне не изменяет склероз
use case - это текстовый документ очень гибкий и очень полезный. Диаграммами представлять шаги - всё равно что забивать гвозди мобильником. (Хотя я это много раз видел. Особенно любят Sequence Diagram)
Сценарий - это отдельно взятый вариант (маршрут) проигрывания use case.
user stories - это способ агильщиков перекладывать работу и ответственность на пользователей. По сути является другим названием для сценария.
February 8th, 2008 at 12:53
Vit,
Да, он текстовый — тут просто небольшая путаница сперва в терминах получилась. Диаграммы полезны как альтернативное представление — краткий обзор процесса работы функциональности. Они всегда идут у меня в качестве оглавления набора wireframes. В остальном — и про сценарий, и про user stories все так
February 22nd, 2008 at 12:12
[…] что через неделю в блоге будут не только обещанные материалы, но и рассказы о двух свежезапущенных проектах. […]
February 26th, 2008 at 22:40
Ну всё, в конец запутали.
Кейсы, истории, сценарии…
Давайте уже русские эквиваленты введем для ясности.
Поправьте, если напутал.
Вариант использования - это, грубо говоря, история типовой работы с системой. Есть персонаж - посетитель, у персонажа есть цель, он реализует её в системе (на сайте). То, как персонаж достигает цели и является сценарием взаимодействия.
Для почтового клиента в общем виде это выглядит так:
Пользователь запускает программу, при необходимости инициирует получение новых писем (если это не было проделано автоматически). Пришедшие сообщения просматриваются в общем списке в сокращенном виде. Из списка выбираются письма, достойные прочтения содержимого. Пользователь читает письмо и закрывает программу.
В англоязычной терминологии это user stories. Верно?
Сценарий взаимодействия - это описание определенных действий пользователя и откликов системы на них. В виде пошаговых инструкций или диаграммы.
Пример:
- Пользователь нажимает кнопку “Проверить почту”.
– Система запрашивает указание ящиков для проверки.
- Пользователь отмечает галочками доступные ящики и нажимает кнопку “Проверить выбранные”.
– Система получает письма, сортирует и отмечает новые письма согласно настройкам пользователя.
- Пользователь кликает на заголовок письма.
– Система открывает окно с содержимым выбранного письма.
И это у нас use case, опять же, если не ошибаюсь.
У меня ещё попутно вопрос: как правильно называются такие штуки, которые я предлагал людям использовать для тестирования (juniorman.ya.ru/replies.xml?item_no=345).
p.s. Юрий, пишу в первый раз, хотя читаю ваш блог давно. Здравствуйте, Юрий.
February 27th, 2008 at 12:23
Вариант использования (Use Case) - это описание того, как должна работать некоторая функциональная часть системы. Вариант использования имеет такие свойства как формализованность и подробность.
Пользовательская история (User Story) - это самый простой, неформализованный и неподробный вид варианта использования. Зачастую истории пишут прямо во время интервью с заинтересованным лицом. В гибких методологиях разработки ограничиваются фиксированием требований в виде историй, мотивируя тем, что требования все равно изменятся, а поддержка актуальных подробных вариантов использования обойдется дорого.
Зачастую для экономии времени вариант использования пишут только для одного успешного потока, не оговаривая исключения (это пример, который привел Дмитрий).
February 27th, 2008 at 12:27
Дмитрий,
“Штуки” называются персоны. А производимые ими действия - сценарий тестирования.
February 27th, 2008 at 17:01
netklon, т.е. изначально можно написать историю (story), а потом “ужесточить её”, приведя к формальным описаниям (таблицы, диаграммы, UML), добавим ветки событий/исключений/прочее и в итоге получим вариант использования (case)?
February 27th, 2008 at 17:07
Ага, спасибо. Я уже додумался потом, после того как написал сообщение.
Бывает так со мной.
February 27th, 2008 at 17:08
Пользовательская история это и есть один из форматов вариантов использования. Неформализованный и неподробный.
Да, можно сначала написать историю, а потом уже дополнить ее подробностями, обвязать служебными полями и добавить графическую нотацию. Степень формализованности и подробности зависит от контекста проекта.