Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: leha от 30 Мая 2007, 13:21:03
-
http://guicci.ru/2007/05/24/galya-masha-misha-dzho-elen-alina-betti-i-migel/
Возможно ли использовать такой подход не только для юзабилити исследований, но и как средство презентации требований для заказчика?
Позволит ли такой подход иногда сэкономить на прототипах?
Или всё это слишком экзотично?
-
Поробуй на практике описать требования с помощью комиксов и тебе сразу станет ясен ответ на этот вопрос.
-
Возможно ли использовать такой подход не только для юзабилити исследований, но и как средство презентации требований для заказчика?
Не совсем понимаю как
Позволит ли такой подход иногда сэкономить на прототипах?
НА каких прототипах?? Системы?? Каким образом?
Или всё это слишком экзотично?
Для меня экзотично. Не понимаю когда их можно использовать. Кроме как в отчётах о презентациях и показах.
Ну а Вы часто ставите смайлики в тех. документы?? Я никогда.
-
Поробуй на практике описать требования с помощью комиксов и тебе сразу станет ясен ответ на этот вопрос.
Я не говорю, что их надо использовать в_м_е_с_т_о нормальных требований. Это скорее вспомогательный материал который позволит:
* повысит степень понимания заказчиком требований (практически иллюстрация требований)
* позволит иногда сэкономить на прототипировании
-
НА каких прототипах?? Системы?? Каким образом?
Часто бывает ситуация, когда заказчик плохо понимает требования зафиксированные в письменном виде. Со всеми вытекающими. Иногда в такой ситуации приходится делать некий прототип, чтобы сдвинуть ситуацию с мёртвой точки.
Для меня экзотично. Не понимаю когда их можно использовать. Кроме как в отчётах о презентациях и показах.
Ну а Вы часто ставите смайлики в тех. документы?? Я никогда.
Я не имел в виду замену требований зафиксированных в стандартном документе комиксом. Подразумевалась именно презентация требований заказчику.
-
2 bibikoff
Это я все понимаю. Примеры приведите пожалуйста.
-
http://guicci.ru/2007/05/24/galya-masha-misha-dzho-elen-alina-betti-i-migel/
Возможно ли использовать такой подход не только для юзабилити исследований, но и как средство презентации требований для заказчика?
Позволит ли такой подход иногда сэкономить на прототипах?
Или всё это слишком экзотично?
Думаю, использование комиксов является развитием техники Storyboarding и вполне жизнеспособно. Действительно, есть такая проблема, как воспринимаемость проектных артефактов, в частности, требований, заинтересованными лицами в процессе их выявления. И эту воспринимаемость можно повысить за счёт использования графики.
Понятно, что все функциональные требования так описывать не стоит, но какие-то наиболее критичные и запутанные - вполне. Правда, полезность комиксов максимальна в эргономической составляющей требований и решений, где важно понимать рабочий контекст. В остальных составляющих они будут не очень полезны.
-
Это я все понимаю. Примеры приведите пожалуйста.
вот пример такого комикса:
http://designcomics.org/examples.html
или вы про примеры использования техники комиксов в реальной работе с заказчиком? тут я вам не отвечу, собственно с этим вопросом я и пришёл на форум
-
Ну да я немного не в той плоскости думал.
Действительно если представлять описание тех же БП или проблем в таком виде, то может помочь.
Здесь тогда встают два вопроса:
1. Трудоёмкость создания комикса
2. Поддержка актуальности комикса
-
Я не говорю, что их надо использовать в_м_е_с_т_о нормальных требований.
Я тоже не говорю "в_м_е_с_т_о". Я говорю п_о_п_р_о_б_у_й_т_е :)
Именно реальные требования к реальной системе, с пониманием которых была проблема у реального заказчика.
Посмотрите, как много времени у вас займет создание версии, которая действительно будет радикально более понимаема заказчиком. И потом попробуйте оценить, сколько времени вам потребоваось бы, чтобы просто сделать понимаемый заказчиком текст.
-
Здесь тогда встают два вопроса:
1. Трудоёмкость создания комикса
2. Поддержка актуальности комикса
Я тоже не говорю "в_м_е_с_т_о". Я говорю п_о_п_р_о_б_у_й_т_е :)
...
Посмотрите, как много времени у вас займет создание версии, которая действительно будет радикально более понимаема заказчиком. И потом попробуйте оценить, сколько времени вам потребоваось бы, чтобы просто сделать понимаемый заказчиком текст.
Цитируемый сайт вроде предлагает какие-то заготовки на эту тему - готовые персонажи, обстановка, исходные файлы. Возможно это не так уж и сложно.
Надо будет поэкспериментировать.
-
Цитируемый сайт вроде предлагает какие-то заготовки на эту тему - готовые персонажи, обстановка, исходные файлы. Возможно это не так уж и сложно.
Самое сложное -- это сценарий. Я пробовал нечто подобное делать для иллюстрации User Stories.
-
Самое сложное -- это сценарий. Я пробовал нечто подобное делать для иллюстрации User Stories.
Не понравилось?
-
По моему скромному мнению, логично продолжить эту идею до уровня мультиков - отражающих собственно это запутанное требование. Даже можно идею развить в плоть до инструментальной генерации мультика на базе требования. Ну к примеру есть вариант использование, который каким-то образом анимирован...
-
Не понравилось?
- Гоги, ты помидоры любишь?
- Есть люблю, а так -- нет.
Результат -- понравился. Процесс -- нет. Я окончательно сдох на третьей UserStory. Суммарно (включая недоделанный последний) это заняло около 2 часов. Не смешно.
-
Насколько я понял, предлагается использовать такой "мультик" для иллюстрации реализации каких-то требований.
Но вот что мне кажется. Если сценарий достаточно прост, то вполне подойдёт и обычный текстовой стиль описания юз-кэйза. В этом случае рисовать кучу картинок - только терять время.
Если же сценарий сложен и сложно текстовое его описание - то и мультик рисовать будет аналогично сложнее. И ещё сложнее - затем модифицировать.
Для текстового способа описания есть устоявшиеся способы структурирования сценария, выделения альтернативных и т. п. А как быть с альтернативной последовательностью кадров? Не знаю.
В любом случае, составить несколько скриншотов прототипа GUI - намного быстрее, чем рисовать картинки для мультика.
-
В любом случае, составить несколько скриншотов прототипа GUI - намного быстрее, чем рисовать картинки для мультика.
Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.
-
Storyboarding он и в Африке storyboarding ... На самом деле совершенно не важно какой мы используем механизм для того чтобы вовлечь заинтересованных лиц в активное обсуждение. Это могут быть обычные карточки, мультики/комиксы, средства проигрывания сценариев типа Borland DefineIT и иже с ними -- когда можно иллюстрировать картинками шаги. Важно одно: а) вовлечь в процесс б) управлять процессом имея внятную цель, чего мы хотим выудить, если это не первая встреча в) не давать увлекаться в ненужные для данного этапа детали (хотя фиксировать для себя интерес к этим деталям следует, для планирования следущих активностей). Реально -- что потом эти мультики/комиксы нужно просто выкидывать и не поддерживать их актуальность, когда мы добъемся понимания чего таки нужно стейкхолдерам, а переходить к спецификациям требований.
Есть другая проблема -- приучив стейкхолдеров к мультикам -- сложно потом заставить их воспринимть что-то другое, те же документы, ибо тут им все разжевали. Тогда придется "ТЗ в картинках" делать :-). Хотя если именно за это готов заплатить заказчик why not? :-)
-
Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.
Скажем так, что те же юзкейсы задают именно контекст использования ... другой вопрос, что они не "заточены" на ДЕТАЛИ юзабилити. Хотя юзабилити в широком смысле они могут учитывать. Другой вопрос, что разрабатывая юзкейс нужно уже четко иметь предстваление о юзабилити -- одно дело коропративная учетная система (на мой взгляд у той же Axaptа юзвабилити не на самом высоком уровне ... и ничего, привыкают работают), другое дело -- когда юзабилити -- один из стратегических факторов успеха продукта/услуги (например какой-нить электронный магазин). Т.к. заполняя форму и отлучась к ребнку увидев что сессия закончена -- не факт что потом придешь в этот эл. магазин еще раз. А операционист в банке -- пока не закончит обслуживать клиента НИКУДА отлучиться не может с раб. места.