Анализ пользовательских требований: методы и техники

Понимание пользовательских требований является неотъемлемой частью проектирования автоматизированных систем и имеет решающее значение в успехе интерактивных систем. Однако задача определения требований пользователей сложнее, чем кажется. В статье рассмотрены типовые подходы к анализу пользовательских требований, которые могут быть адаптированы для различных ситуаций. Описаны некоторые краткие тематические исследования, иллюстрирующие то, как эти методы применялись на практике.
В основе статьи – материалы исследований М. Магуайера и Н. Бивэна.

1. Введение

Понимание пользовательских требований является неотъемлемой частью проектирования информационных систем и имеет решающее значение в успехе интерактивных систем. Сейчас стало общепринятым, что успешные системы и продукты начинаются с понимания необходимостей и потребностей пользователей. Как описано в стандарте ISO 13407 (ISO, 1999), дизайн, ориентированный на пользователя, начинается с глубокого понимания нужд и требований пользователей. Преимущества могут включать повышенную производительность, улучшенное качество работы, снижение затрат на поддержку и обучение и более высокую удовлетворенность пользователей. Анализ требований – процесс не простой. Конкретными проблемами, предстающими перед аналитиком, являются:

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

В этой статье рассматривается, как эти проблемы могут быть решены выбором соответствующих методов поддержки процесса формирования и утверждения требований пользователя. Кратко описан каждый метод и показано, как он способствует процессу анализа требований.

Основой для применения различных методов анализа) пользовательских требований является простой процесс, охватывающий 4 этапа, как показано на рис. 1:

Рисунок 1: Обобщенный процесс анализа требований пользователя

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

2. Сбор информации

Первый шаг в анализе пользовательских требований – сбор «фоновой» информации о пользователях и заинтересованных сторонах, а также о процессах, которые происходят в данный момент. Для этого могут быть применены следующие методы:

Анализ заинтересованных сторон идентифицирует всех пользователей и заинтересованных участников, которые могут повлиять на систему или быть затронуты ей. Это помогает гарантировать, что потребности всех участвующих сторон будут учтены. Если необходимо, система проверяется ими. Группы пользователей могут включать конечных пользователей, руководителей, специалистов по установке и сопровождению. Другие заинтересованные стороны включают получателей результатов работы системы, покупателей, маркетинговый персонал и сотрудников поддержки (Тейлор, 1990). Анализ заинтересованных сторон выявляет основные роли, обязанности и целевые задачи по отношению к системе для каждого пользователя и группы участников. Один из главных вопросов (здесь в том), как найти в новой системе компромисс между конкурирующими потребностями различных групп заинтересованных сторон (см. 4.5 Распределение функции и анализ пользовательской выгоды).

Исследование вторичного рынка включает изучение опубликованных источников, таких как исследовательские отчеты, данные переписи (населения), демографическая информация, которые проливают свет на ряд возможных пользовательских рынков. Веб-сайты, представляющие специальные группы пользователей, например, Королевский Национальный Институт для слепых (www.rnib.org.uk/digital), дают информацию о характере контингента, который они представляют (Мандер и Смит, 2002).

Анализ контекста использования применяется, когда система или продукт уже разработаны. Качество системы, включающее удобство использования, доступность и факторы социальной приемлемости, зависит от наличия глубокого понимания контекста использования системы. Например, банкомат будет намного более применимым, если будет спроектирован для использования не только днем, но и ночью, как при нормальном освещении, так и при ярком солнечном свете, как здоровыми людьми (способными стоять), так и людьми в инвалидной коляске. Также и в офисной среде, есть множество характеристик, которые могут влиять на юзабилити нового программного продукта: загруженность пользователей, доступность службы поддержки, перебои в электроснабжении и т.п.. Следовательно, сбор контекстной информации является важным, помогая в определении пользовательских требований. Для сбора контекстной информации заинтересованные стороны участвуют в облегченных заседаниях, называемых Контекстными встречами. На них они заполняют опросник, охватывающий характеристики пользователей, их задачи и оперативное окружение (см. основные заголовки в нижеприведенной табл. 1).

Таблица 1. Факторы влияния в контексте использования

Анализ контекста использования был одним из результатов проекта ESPRIT¹ HUFIT² и разрабатывался далее в проекте ESPRIT MUSiC³ (Бивэн и Маклеод, 1994). Анализ контекста использования среди юзабилити-методов также рассматривал Магуайр (2001).

Анализ задач включает изучение того, что пользователю необходимо делать, касательно действий и/или мыслительных процессов, направленных на решение (достижение) задачи. Подробный анализ задач может быть проведен для понимания имеющейся системы, ее информационных потоков, проблем для людей, а также возможностей, которые указывают на потребности пользователей. Есть много вариантов анализа задач и систем условных обозначений для записи деловой активности. Одним из наиболее широко используемых является иерархический анализ задач, где задачи верхнего уровня раскладываются на более детализированные компоненты и последовательности. В другом методе создается диаграмма потоков, показывающая последовательность действий человека и связанные с ней входные данные и результаты (Эрикссон, 2001). Кируан и Эйнсуорт (1992) представляют руководство по различным методикам анализа задач, в то время как Хакос и Редиш (1998) разъясняют некоторые простейшие методы проектирования пользовательского интерфейса.

Раскадровки (Детальные изображения) могут помочь заинтересованным сторонам очертить, исследовать и понять сложноcть проблемы и, тем самым, помочь в определении скрытых требований (Чеклэнд, 1981). Эта техника включает создание серий набросков, показывающих взаимоотношения людей и систем в организации. Они могут отображать роли людей, устойчивые структуры, связи и механизмы отчетности. Рисование упрощенных фигур людей с их речью и мыслями в текстовых выносках может выявить частные проблемные области в имеющемся окружении, которые могут приводить к новым пользовательским требованиям.

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

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

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

3. Выявление (идентификация) пользовательских потребностей

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

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

Опросы обычно состоят из смеси «закрытых» вопросов с фиксированными ответами и «открытых» вопросов, где респонденты свободны отвечать по желанию. Этот метод полезен для получения как количественных, так и качественных данных от большого числа пользователей о сложностях существующих задач или имеющейся системы. Для получения дополнительной информации см. Прис и др. (1994).

Фокус-группы собирают участников с пересекающимися интересами в формате дискуссионной группы. Этот метод полезен для выявления потребностей и может помочь для идентификации проблем, которые необходимо охватить. Общая идея в том, что каждый участник может стимулировать появление идей у других участников и что в процессе обсуждения закрепляется коллективная точка зрения, которая лучше, чем отдельные части. Для получения дополнительной информации см. Брюсберг и МакДона-Филп (2001).

Интервьюирование — широко используемая методика, где пользователи, заинтересованные стороны и эксперты в соответствующих областях опрашиваются для получения информации об их необходимостях и потребностях по отношению к новой системе. Опросы обычно полуструктурированы и основаны на последовательностях фиксированных вопросов с областью для расширенных ответов пользователей. Опросы могут быть также использованы как часть анализа задач. Для получения дополнительной информации см. Прис и др. (1994) и Маколей (1996). Опросы на сайте клиента, проводимые командой разработчиков системы, могут быть очень информативны. Наблюдение за окружением также дает яркую ментальную картину того, как пользователи работают с имеющейся системой и как новая система может поддерживать их (Мандер и Смит, 2002).

Сценарии и варианты использования дают детализированные реалистичные примеры того, как пользователи могут выполнять их задачи в специализированном контексте новой системы. Первичная цель создания сценариев — представить примеры будущего использования чтобы помочь в понимании и разъяснении требований пользователей и представить основу для последующего тестирования юзабилити. Сценарии могут помочь в выявлении целей юзабилити и вероятных сроков выполнения задачи. Метод также способствует разработчику вкладывать средства и поощрять подход с применением человеко-ориентированного дизайна. Сценарии использования иногда называют «вариантами использования», хотя данный термин также используется разработчиками программного обеспечения в отношении использования функций.

В связанном методе, называемом «Персонажи», создается карикатурный образ с именем, персональной информацией и картинкой, представляющий каждого из наиболее важных пользователей групп. Затем потенциальные проектные решения могут быть сопоставлены с потребностями конкретного персонажа и задачами, которые предполагается выполнять. Персонажи используются инновационными дизайнерскими группами скорее для стимулирования креативности, чем для уточнения дизайнерских решений (Купер, 1999).

Мастер-классы по «проектированию будущего» — это способ помочь пользователям и дизайнерам «вырваться» из сложившейся ситуации и размышлений. Главным образом они включают сбор участников и постановку перед ними вопросов, таких как: «Где бы вы хотели быть через 10 лет?». Как только участники примут подходящую цель, они будут стремиться наладить процесс, с помощью которого она может быть достигнута. Другой вариант — определение новых технологических разработок, обсуждение возможности их достижения и возможных последствий для организации пользователя.

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

4. Предвидение и оценка

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

Мозговой штурм — это сессии, объединяющие экспертов по дизайну и задачам, которые вдохновляют друг друга в креативной фазе генерации идей в процессе решения задачи. Такие сессии применяются для генерации новых идей, путем освобождения сознания для принятия любых предложенных идей, тем самым разрешая свободу творчества. Этот метод широко используется на ранних этапах проектирования. Результатами мозгового штурма является, что ожидаемо, множество хороших идей и общее ощущение области решения задачи удовлетворения пользовательских потребностей.

Сортировка карточек — это метод раскрытия иерархической структуры в множестве концепций, путем обращения к пользователям для группировки элементов, записанных в наборе карточек. Например, этот метод часто используется для работы по организации веб-сайта. Пользователям выдают карточки с названиями соответствующих страниц сайта и просят сгруппировать их в связанные категории. После выполнения группировки несколькими пользователями, разработчики, как правило, могут четко определить структуры, пересекающиеся для многих пользователей. Статистический анализ может выявить лучшие группировки данных там, где они явно не просматриваются. IBM (2002) представляет собой пример программы анализа.

Диаграммы сходства — это связанная техника, которая может быть использована для организации структуры новой системы и позволяющая участникам работать в группе. Проектировщики или пользователи записывают элементы, такие как возможные виды экранов или функции, на стикерах и затем группируют их, выявляя структуру и отношения в домене. Этот метод — зачастую хороший следующий шаг после мозгового штурма. Для получения дополнительной информации см. Бийер и Хольцблатт (1998).

Раскадровки, также определяемые как «Презентационные сценарии», представляют собой последовательности изображений («кадров»), иллюстрирующих отношения между действиями пользователей или входной информацией и выходной информацией системы. Типичная раскадровка будет содержать ряд картинок, изображающих характерные особенности, такие как системные меню, диалоговые формы и окна. Последовательности кадров представляют платформу для исследования и уточнения вариантов пользовательских потребностей путем статичного представления будущей системы, демонстрируемой потенциальным пользователям и участникам команды проектировщиков (Андриоль, 1989).

Прототипирование — метод, в котором дизайнеры создают статические или динамические бумажные или программные модели элементов пользовательского интерфейса (меню, кнопок, пиктограмм, окон, диалогов и т. п.). Когда бумажный прототип выполнен, представитель группы проектировщиков садится перед пользователем и «играет в компьютер», перемещая бумажные и картонные элементы пользовательского интерфейса в ответ на действия пользователя. Сложности, встречающиеся у пользователя и его комментарии, записываются наблюдателем. Программные прототипы представляют более высокий уровень реалистичности по сравнению с простым бумажным макетом. В этом случае целью является создание «быстрого» прототипа, используемого для установления приемлемого для пользователя дизайна, но отбрасываемого вплоть до полной реализации. Некоторые процессы проектирования основаны на т. н. RAD⁴-подходе. В этом случае небольшая группа проектировщиков и пользователей интенсивно работают над прототипом, внося частые изменения в ответ на комментарии пользователей. Прототип развивается в полную систему. Халл (2001) обсуждает достоинства и экономические выгоды прототипов различной степени достоверности.

Распределение функций — важный элемент для многих систем. Как определено в п. 7.3.2 стандарта ISO 13407⁵ (1999), распределение функций — это «разделение задач системы на те, что выполняются людьми и те, что выполняются технологией» для точного установления системных ограничений. Для определения оптимального разделения труда устанавливается диапазон опций, чтобы обеспечить выполнение должностных обязанностей и эффективную деятельность на всем протяжении рабочего процесса. Затем выполняется анализ пользовательской выгоды, позволяющий определить, насколько приемлемым находит новый порядок каждый пользователь группы. Использование диаграмм распределения задач и анализа выгоды приносит больше пользы в системах, затрагивающих целые рабочие процессы, а не в однопользовательских, однозадачных продуктах. Также они обеспечивают возможность переосмысления дизайна системы или ролей пользователя, чтобы представить более приемлемое решение для всех групп. Процесс анализа выгоды пользователя описан Исоном (Eason, 1988).

Стандарты и руководства по дизайну, на которые ссылаются проектировщики и специалисты по человеко-машинному взаимодействию как на нормативные документы по вопросам эргономики, связанным с разрабатываемой системой. Стандарт ISO 9241⁶ (ISO, 1997) охватывает многие аспекты дизайна пользовательского интерфейса аппаратного и программного обеспечения и содержит общепризнанные основополагающие рекомендации по эргономике программного обеспечения. Для дополнительной информации о стандартах ISO см. Бивэн (2001). Руководства по стилям воплощают полезный опыт в дизайне интерфейсов. Следование руководствам увеличивает согласованность между экранными формами и уменьшает время разработки. Для GUI (графических пользовательских интерфейсов) необходимо следовать стилевым нормативам операционных систем, чтобы реализовать (осуществлять) полезный опыт и обеспечить согласованность. Руководства по дизайну веб-сайтов еще развиваются, но хорошие принципы веб-дизайна постепенно устанавливаются (Нильсен, 2000). Николь и Абаскал (2001) обсуждают проблемы и представляют руководства по созданию систем, доступных для людей с ограниченными возможностями.

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

5. Спецификация требований

Общее руководство по спецификации пользовательских и организационных требование и целей представлено в ISO 13407.

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

Следующий раздел описывает техники и методы поддержки спецификации пользовательских и организационных требований.

Сопоставление «задача/функция» определяет функции системы, которые потребуются каждому пользователю для различных задач, которые он выполняет. Показывая отношения между задачами и соответствующими функциональными требованиями в виде матрицы связей, можно будет найти компромисс между различными функциями или добавить и удалить функции, в зависимости от их значимости для поддержки специфичных задач. Также полезно, чтобы многопользовательские системы гарантировали, что задачи пользователей каждого типа являются поддерживаемыми.

Категории требований

Пользовательские требования: Важно выявить и задокументировать пользовательские требования, так как они приводят к процессу проектирования системы. Пользовательские требования будут включать краткие описания задач, которые система будет поддерживать, и функций, обеспечивающих их поддержку.

Требования юзабилити: Также необходимо описать подробные требования к юзабилити для того, чтобы установить цели для проектной группы и помочь расставить приоритеты в работе над юзабилити. Общеприемлемыми для определения целями юзабилити являются:

• эффективность — степень успешности, с которой пользователи достигают своих целей в задаче;
• оперативность — время, необходимое для выполнения задач;
• удовлетворение — комфорт пользователя;
• приемлемость, см. ISO 9241, часть 11 «Руководство по юзабилити» (ISO, 1997).

Эти цели легче всего выводятся из оценки существующей системы. Другие, более подробные вопросы юзабилити обеспечивают более специфичные цели дизайна, такие как, понятность, обучаемость, поддерживаемость, гибкость и привлекательность. Установив требования юзабилити, необходимо перевести их в спецификацию (спецификация = требование + мера). ISO 9126-4 (ISO, 2002) обеспечивает основу для определения измеримых требований (см. также раздел 6.3).

Организационные требования: Третьим элементом является спецификация организационных требований к комплексу «пользователь — система», т. е. то, что на выходе системы размещается в социальном контексте. Понимание организационных требований способствуют созданию систем, которые могут поддерживать структуру управления организацией и внутренние коммуникации так же хорошо, как группы и совместная работа. Определение и группировка задач подходящим способом поможет в создании мотивирующих и удовлетворяющих работ, в идеале позволяющих пользователям автономность, гибкость, обеспечение хорошей обратной связью при выполнении этих работ и возможность развивать свои навыки и карьеру. Нормативные и законодательные требования также могут быть классифицированы как организационные (требования).

Информация, необходимая для определения пользовательских, организационных и требований к юзабилити может быть получена из контекста использования и деятельности по определению потребностей пользователя, описанной в предыдущих разделах. Магуайр (1998) и Робертсон и Робертсон (1999) обеспечивают основу спецификации пользовательских требований.

Приоритезация пользовательских требований важна для того, чтобы производственные ресурсы могли быть направлены подходящим образом. В методе разработки DSDM⁷ используются «временнЫе ящики», в которых функции и возможности в каждой фазе выпуска системы определены доступностью ресурсов. Это помогает управлять рисками в процессе разработки системы и позволяет заказчику перенаправить усилия в будущем, чтобы более полно соответствовать потребностям пользователей.

Установка критериев относится к необходимости для критериев помочь решить, какие пользовательские требования были достигнуты. Это может быть выполнено инспекционной группой или пользовательским тестированием, в котором типичный пользователь просто выполняет обычные задачи в системе, а оценки производительности и рейтинги отношения помогают решить, приемлема ли система. Определение критериев приемки заранее может быть достигнуто путем выполнения предварительных тестов в существующей или конкурирующей системе, чтобы установить критерии, по которым новая система должна быть, по крайней мере, такой же хорошей, как эти имеющиеся системы.

6. Сравнительный обзор

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

Таблица 2. Сравнение методов анализа пользовательских требований

7. Тематические исследования

Далее приведены примеры некоторых тематических исследований, чтобы показать, как методы, описанные в этой статье, способстовали разработке пользовательских требований. Обычно совместно использовалось несколько методов и техник.

Разработка интранет-сайта. Исследование было проведено HUSAT⁸ (Магуайр и Хёрст, 2001b), чтобы оценить и выполнить редизайн интранет-сайта для полицейской службы в Великобритании. Консультанты по человеческим факторам провели исследование, работая совместно с офицером полиции, который был менеджером проекта для внутренней разработки, и гражданским координатором со знаниями полицейских процедур и человеческих факторов. Были произведены полуструктурированные опросы пользователей и заинтересованных сторон, охватывавшие: потребности и пожелания относительно внутренней сети, как хорошо имеющаяся система отвечает их потребностям и возможные изменения, которые желательно сделать. Опрашиваемым представляли доступ к интранет-сайту, чтобы они могли продемонстрировать свои комментарии. Это были констебль, сержант, инспектор, старшие офицеры и неполицейский административный персонал.

После проведения опросов был сделан экспертный обзор, чтобы установить сильные и слабые стороны имеющегося сервиса. Затем, после экспертной оценки, были даны общие рекомендации для изменения. Они обсуждались с представителями полиции, которым были предложены раскадровки и экранные прототипы различных вариантов концептуального дизайна. Эти методы совпали с требованием к созданию и обсуждению быстрых прототипов внутри команды разработчиков. На основе разработанной концепции дизайна было создано несколько вариантов графического оформления сайта в виде программных прототипов, чтобы продемонстрировать и внешний вид, и общее ощущение. Окончательным дизайн домашней страницы и информационных страниц второго уровня стал, когда был выполнен с применением веб-шаблонов, чтобы позволить полиции устанавливать новые страницы и поддерживать их в будущем.

Проект показывает, как комбинация методов может вырабатывать подходящий новый дизайн системы в относительно короткое время (3 месяца).

Экспертная оценка учебных возможностей. Оценка была выполнена HUSAT (Магуайр и Хёрст, 2001a), который представил информацию о бизнес-курсах среднему и малому бизнесу. Это было частью программы работы над выработкой пользовательских требований для веб-ориентированного обучающего сервиса, т. н. «виртуального кампуса». Оценка выполнялась двумя экспертами по человеческим факторам, которые затратили время на обзор каждой из основных частей системы, исходя из их собственного опыта, знания типичных задач и принципов юзабилити. При представлении замечаний к системе, целью было не улучшение имеющейся системы, а выявление возможностей и последствий для новой системы.

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

Опросы для оценки будущих требований к финансовым сервисам. Опросы в семейных группах были выполнены HUSAT, чтобы изучить их управление домашними финансами (Магуайр, 1999). Контекст использования информации был собран при поддержке фотографий, полученных в помещениях, где выполнялись финансовые задачи. Интервью проводились как серии занятий в фокус-группах с каждой семьей, чтобы обсудить, как и где они выполняют финансовые задачи, как им понравилось бы получать услуги в будущем и с помощью каких устройств, например, ТВ, компьютера или другой бытовой техники. На занятиях велась видеозапись, помещения и устройства в доме фотографировались. Исследование показало, где были размещены домашние устройства и где члены семьи выполняли текущие финансовые операции. Это обеспечило основу для идентификации инновационных способов доставки будущих финансовых услуг на дом.

Исследование с целью установления пользовательских потребностей для системы (контроля) изменения климата. Проект EuroClim (http://euroclim.nr.no) нацеливается на то, чтобы разработать продвинутую систему мониторинга и предсказания климата для Европы. Климатические данные, собранные в сети сайтов по всей Европе, будут сохраняться в цифровой форме. Система будет генерировать растровые карты и наборы данных для ученых и публичных пользователей, отображая изменения снежного покрова, ледников, морского льда и общие климатические тренды. Чтобы понять разнообразие пользовательских требований к точности данных, метаданным и форматам (данных), совместно с климатологами (климатическими профессионалами) и обычными пользователями по всей Европе, было выполнено исследование пользовательских потребностей. Наибольшие усилия потребовались для анализа всех различных потребностей и сведения их в форму, которую команда разработчиков сможет усвоить. Требования пользователей к качеству данных варьировались среди пользователей. Поэтому, были построены графики, чтобы показать какая доля пользователей в этом исследовании может быть удовлетворена различными компонентами качества данных, такими как разрешение, точность и задержка в доставке. Для специализированных систем, таких как EuroClim, важно иметь возможность отследить возможность возврата требований в организацию, которая их установила, чтобы можно было получить пояснения к пользовательским потребностям. Разрабатывался макет пользовательского интерфейса, основанный на информации, собранной в исследовании, чтобы продемонстрировать концепцию системы и «прототипировать» пользовательские требования до того, как спецификация системы будет утверждена и начнется разработка.

Дизайн, ориентированный на пользователя в IAI⁹. Serco¹⁰ работал совместно с IAI LAHAV¹¹, чтобы оценить выгоды применения методов дизайна, ориентированного на пользователя, в типовом проекте. Из методов дизайна, ориентированного на пользователей, рекомендованных TRUMP¹² (Бивен и др., 2000), были выделены такие, которые просты в планировании и применении и легки для освоения командами разработчиков.

1. Встреча заинтересованных сторон и семинар по контексту использования. Встреча заинтересованных сторон выявляет и согласует роль юзабилити, цели юзабилити, и то, как они соотносятся с бизнес-целями и критериями полноты системы. Контектный семинар собирает детальную информацию о целевых пользователях, их задачах и технических и экзогенных ограничениях. Оба мероприятия длились примерно по полдня.

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

3. Оценка имеющейся системы. Оценка предыдущей версии или конкурирующей системы для выявления проблем юзабилити и получения мерных характеристик юзабилити как исходных данных для формирования требований к юзабилити.

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

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

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

7. Оценка машинных прототипов. Неформальное тестирование юзабилити с помощью 3-5 выборочных пользователей, выполняющих ключевые задачи, чтобы получить быструю обратную связь.

8. Тестирование юзабилити. Формальное тестирование юзабилити 8-ю представителями группы пользователей, выполняющих ключевые задачи, чтобы выявить любые оставшиеся проблемы юзабилити и оценить, какие цели юзабилити уже были достигнуты.

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

8. Заключение

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

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

9. Ссылки

1. Andriole, S. J. (1989), Storyboard prototyping: a new approach to user requirements analysis, QED Information Sciences, Inc.
2. Bevan N (2001) International Standards for HCI and Usability. International Journal of Human Computer Studies, 55, 4.
3. Bevan, N, Bogomolni, I, k Ryan, N (2000) Cost-effective user centred design, www.usability.serco.corn/trump
4. Bevan, N. k, Macleod, M (1994) Usability measurement in context. Behaviour and Information Technology, 13, 132-145
5. Beyer, H. k, Holtzblatt, K. (1998), Contextual design: defining customer-centered systems, Morgan Kaufmann Publishers.
6. Bruseberg, A. & McDonagh-Philp, D. (2001), New product development by eliciting user experience and aspirations, International Journal of Human Computer Studies, 55(4), 435-452.
7. Checkland, P. (1981), Systems thinking, systems practice, Wiley.
8. Cooper, A. (1999), The inmates are running the asylum: why high tech products drive us crazy and how to restore the sanity, Sams publishing.
9. Eason, K.D. (1988), Information technology and organisational change, Taylor and Francis.
10. Ericsson Infocom Consultants AB and Linkoping University (2001), The Delta method. www.deltamethod.net/
11. Hackos, J. & Redish, J. (1998), User and Анализ задач for interface design, Wiley.
12. Hall, R.R. (2001), Prototyping for usability of new technology, International Journal of Human Computer Studies, 55, 4, 485-502.
13. IBM (2002), EZSort http: //www-3.ibm.corn/ibm/easy/eou ext.nsf/Publish/410
14. ISO (1997), ISO 9241: Ergonomics requirements for office work with visual display terminals (VDTs), 17parts, International Standards Organisation.
15. ISO (1999), ISO 13407: Human centred design -processes for interactive systems, International Standards Organisation.
16. ISO (2002), ISO/IEC 9126-4: Software engineering – software product quality – Part 4: Quality in Use Metrics, International Standards Organisation.
17. Kirwan, B. & Ainsworth, L.K. (eds.) (1992), A guide to Анализ задач, Taylor and Francis.
18. Macaulay, L.A. (1996), Requirements engineering, Springer Verlag Series on Applied Computing.
19. Maguire, M.C. (1998), User-centred requirements handbook. EC Telematics Applications Programme, Project TE 2010 RESPECT (Requirements Engineering and Specification in Telematics), WP4 Deliverable D4.2, version 3.3, May. http:www.lboro.ac.uk/research/husat/respect/rp2.html
20. Maguire, M.C. (1999), NCR Knowledge Lab. Report on study of the management of domestic finances by family groups, 7 May, RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK.
21. Maguire, M.C. & Hirst, S.J. (2001a), Usability evaluation of the LINK project TIGS website and feedback on OVC specification. HUSAT Consultancy Limited, 2 March 2001. RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK.
22. Maguire, M.C. & Hirst, S.J. (2001b), Metropolitan Police Service redesign of corporate intranet pages. HUSAT Consultancy Limited, 26 March 2001. RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK.
23. Maguire, M.C. (2001c), Context of use within usability activities, International Journal of Human-Computer Studies, 55(4), 453-484.
24. Mander, R. & Smith, B. (2002), Web usability for dummies, New York: Hungry Minds.
25. Nielsen, J. (2000), Designing web usability: The practice of simplicity, New Riders Publishing.
26. Nicolle, C. & Abascal, J. (eds.) (2001), Inclusive design guidelines for HCI, Taylor & Francis.
27. Olphert, C.W. & Damodaran, L. (2002), Getting what you want, or wanting what you get? - beyond user centred design, Proceedings of the Third International Conference on Design and Emotion, Loughborough, UK, 1-3 July 2002.
28. Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. & Carey, T. (1994), Human-computer interaction. Addison-Wesley.
29. Robertson, S. & Roberston, T. (1999), Mastering the requirements process, Addison- Wesley and ACM Press.
30. Taylor, B. (1990), The HUFIT planning, analysis and specification toolset, In D. Diaper, G. Cockton, D. Gilmore & B. Shackel, (eds.), Human-Computer Interaction - INTERACT'90, 371-376. Amsterdam: North-Holland.

1 ESPRIT (European Strategic Program on Research in Information Technology) — Европейская стратегическая программа исследований в области информационных технологий.

2 HUFIT (HUman Factors in Informational Technology) — Человеческий фактор в области информационных технологий.

3 MUSiC (Metrics for Usability Standards in Computing) — Метрики стандартов юзабилити в вычислительной технике.

4 RAD — rapid application development, концепция быстрой разработки приложения с использованием визуальных инструментальных средств.

5 ISO 13407:1999 Human-centred design processes for interactive systems

6 ISO 9241 — Ergonomic requirements for office work with visual display terminals (VDTs)

7 Dynamic Systems Development Method — метод разработки, целью которого является выпуск готового проекта в указанный срок и без превышения бюджета посредством регулирования изменения требований в процессе разработки.

8 Human Sciences and Advanced Technology (Loughborough University; UK)

9 Israel Aerospace Industries

10 https://www.serco.com/about

11 http://www.epicos.com/EPCompanyProfileWeb/GeneralInformation.aspx?id=17621

12 Technical Review & Update of Manuals and Publications

CC-BY-CA Анатольев А.Г., 21.12.2015