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

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

Если же сценарий сложен и сложно текстовое его описание - то и мультик рисовать будет аналогично сложнее. И ещё сложнее - затем модифицировать.

Для текстового способа описания есть устоявшиеся способы структурирования сценария, выделения альтернативных и т. п. А как быть с альтернативной последовательностью кадров? Не знаю.

В любом случае, составить несколько скриншотов прототипа GUI - намного быстрее, чем рисовать картинки для мультика.

В любом случае, составить несколько скриншотов прототипа GUI - намного быстрее, чем рисовать картинки для мультика.

Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.

Storyboarding он и в Африке storyboarding ... На самом деле совершенно не важно какой мы используем механизм для того чтобы вовлечь заинтересованных лиц в активное обсуждение. Это могут быть обычные карточки, мультики/комиксы, средства проигрывания сценариев типа Borland DefineIT и иже с ними -- когда можно иллюстрировать картинками шаги. Важно одно: а) вовлечь в процесс б) управлять процессом имея внятную цель, чего мы хотим выудить, если это не первая встреча в) не давать увлекаться в ненужные для данного этапа детали (хотя фиксировать для себя интерес к этим деталям следует, для планирования следущих активностей). Реально -- что потом эти мультики/комиксы нужно просто выкидывать и не поддерживать их актуальность, когда мы добъемся понимания чего таки нужно стейкхолдерам, а переходить к спецификациям требований.
Есть другая проблема -- приучив стейкхолдеров к мультикам -- сложно потом заставить их воспринимть что-то другое, те же документы, ибо тут им все разжевали. Тогда придется "ТЗ в картинках" делать :-). Хотя если именно за это готов заплатить заказчик  why not? :-)

Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.

Скажем так, что те же юзкейсы задают именно контекст использования ... другой вопрос, что они не "заточены" на ДЕТАЛИ юзабилити. Хотя юзабилити в широком смысле они могут учитывать. Другой вопрос, что разрабатывая юзкейс нужно уже четко иметь предстваление о юзабилити -- одно дело коропративная учетная система (на мой взгляд у той же Axaptа юзвабилити не на самом высоком уровне ... и ничего, привыкают работают), другое дело -- когда юзабилити -- один из стратегических факторов успеха продукта/услуги (например какой-нить электронный магазин). Т.к. заполняя форму и отлучась к ребнку увидев что сессия закончена -- не факт что потом придешь в этот эл. магазин еще раз. А операционист в банке -- пока не закончит обслуживать клиента НИКУДА отлучиться не может с раб. места.