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

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

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

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

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



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



Storyboarding он и в Африке storyboarding ... На самом деле совершенно не важно какой мы используем механизм для того чтобы вовлечь заинтересованных лиц в активное обсуждение. Это могут быть обычные карточки, мультики/комиксы, средства проигрывания сценариев типа Borland DefineIT и иже с ними -- когда можно иллюстрировать картинками шаги. Важно одно: а) вовлечь в процесс б) управлять процессом имея внятную цель, чего мы хотим выудить, если это не первая встреча в) не давать увлекаться в ненужные для данного этапа детали (хотя фиксировать для себя интерес к этим деталям следует, для планирования следущих активностей). Реально -- что потом эти мультики/комиксы нужно просто выкидывать и не поддерживать их актуальность, когда мы добъемся понимания чего таки нужно стейкхолдерам, а переходить к спецификациям требований.
Есть другая проблема -- приучив стейкхолдеров к мультикам -- сложно потом заставить их воспринимть что-то другое, те же документы, ибо тут им все разжевали. Тогда придется "ТЗ в картинках" делать :-). Хотя если именно за это готов заплатить заказчик  why not? :-)
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



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

Скажем так, что те же юзкейсы задают именно контекст использования ... другой вопрос, что они не "заточены" на ДЕТАЛИ юзабилити. Хотя юзабилити в широком смысле они могут учитывать. Другой вопрос, что разрабатывая юзкейс нужно уже четко иметь предстваление о юзабилити -- одно дело коропративная учетная система (на мой взгляд у той же Axaptа юзвабилити не на самом высоком уровне ... и ничего, привыкают работают), другое дело -- когда юзабилити -- один из стратегических факторов успеха продукта/услуги (например какой-нить электронный магазин). Т.к. заполняя форму и отлучась к ребнку увидев что сессия закончена -- не факт что потом придешь в этот эл. магазин еще раз. А операционист в банке -- пока не закончит обслуживать клиента НИКУДА отлучиться не может с раб. места.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19