Слайд 2ПЛАН
Виды требований;
Анализ пользователей: методы и средства.
Слайд 3ВИДЫ ТРЕБОВАНИЙ
Группа функциональных требований определяет набор задач, которые система должна выполнять. Часто функциональные требования
представляют в виде сценариев использования (Use Cases).
Слайд 4ВИДЫ ТРЕБОВАНИЙ
Бизнес-требования – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого
программного обеспечения.
Слайд 5ВИДЫ ТРЕБОВАНИЙ
Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при
помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases).
Слайд 6ВИДЫ ТРЕБОВАНИЙ
Функциональные требования (как таковые) – определяют функциональность (поведение) программной системы, которая должна
быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.
Слайд 7ВИДЫ ТРЕБОВАНИЙ
Группа нефункциональных требований задает условия, в которых система должна функционировать (например, время отклика
при максимальной расчетной нагрузке).
Бизнес-правила – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т.д. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос «кто будет осуществлять конкретный сценарий использования» или диктуют появление некоторых функциональных требований.
Слайд 8ВИДЫ ТРЕБОВАНИЙ
Внешние интерфейсы – часто подменяются «пользовательским интерфейсом». На самом деле вопросы организации
пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Слайд 9ВИДЫ ТРЕБОВАНИЙ
Атрибуты качества – описывают дополнительные характеристики продукта в различных “измерениях”, важных для
пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Слайд 10ВИДЫ ТРЕБОВАНИЙ
Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных
решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных и т.п.), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Слайд 11ВИДЫ ТРЕБОВАНИЙ
Системные требования иногда классифицируются как составная часть группы функциональных требований. Описывают высокоуровневые
требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.
Слайд 12сформулировать набор требований к программе «Калькулятор»
Слайд 13АНАЛИЗ ПОЛЬЗОВАТЕЛЕЙ:
МЕТОДЫ И СРЕДСТВА
Персонификация
Этот метод подразумевает составление детализированных типовых профилей потенциальных
пользователей, относящихся к разным группам. Анализ профилей позволяет смоделировать такие поведенческие аспекты, как цели, желания, потребности, предпочтения и ожидания пользователей. Это будет полезным при принятии решений, связанных с возможностями продукта, их визуальным представлением и способами интерактивного взаимодействия.
Слайд 14АНАЛИЗ ПОЛЬЗОВАТЕЛЕЙ:
МЕТОДЫ И СРЕДСТВА
Анализ контекста
Анализ контекста использования состоит в сборе всей
доступной информации о том, что именно делают пользователи в процессе выполнения конкретной задачи и в каком окружении они это делают. Это позволяет направить разработку интерфейса так, чтобы он наиболее полно соответствовал порядку работы пользователей с компонентами системы. Результаты анализа являются основой для составления сценариев использования (Use Cases).
Слайд 15АНАЛИЗ ПОЛЬЗОВАТЕЛЕЙ:
МЕТОДЫ И СРЕДСТВА
Сценарии использования (Use cases)
Сценарии описывают поведение пользователей при
решении производственных задач в определенном контексте. Они представляют примеры использования как отправную точку для проектирования, а также закладывают основу для юзабилити-тестирования.
Слайд 16АНАЛИЗ ПОЛЬЗОВАТЕЛЕЙ:
МЕТОДЫ И СРЕДСТВА
Преимуществами использования сценариев является то, что они позволяют:
моделировать
поведение предполагаемых пользователей, их задачи и окружение;
исследовать вопросы юзабилити на самых ранних этапах проектирования;
определять цели пользователей и вероятное время, затрачиваемое ими для достижения этих целей;
обойтись минимальными ресурсами;
использовать сценарии для дальнейших оценочных исследований;
уменьшить необходимость экспертизы человеческого фактора.
Слайд 17АНАЛИЗ ПОЛЬЗОВАТЕЛЕЙ:
МЕТОДЫ И СРЕДСТВА
Алгоритм разработки пользовательских сценариев может быть представлен следующим
образом:
Определение общего контекста, выделение потенциальных пользователей и их задач в этом контексте.
Функциональная декомпозиция пользовательских задач на последовательности операций, необходимых для их решения.
Разделение операций на те, которые должны выполняться пользователями и те, которые компьютером.
Непосредственное формирование сценариев в виде последовательности операций. При этом не следует выделять, что для решения определенных задач используются какие-то особенности продукта.
Дополнение сценариев оценками времени и критериями завершенности.
Слайд 18СОРТИРОВКА КАРТОЧЕК
Формирование списка материалов и тематик. Для этого используются различные источники, начиная от
материалов, используемых в имеющемся приложении (или в конкурирующих разработках) и вплоть до планируемых в будущих версиях. Включение будущих материалов, которые не предусмотрены в текущей разработке, позволит в дальнейшем сократить затраты, поскольку возможность расширения функциональности и представляемой информации уже будет спроектирована.
Слайд 19СОРТИРОВКА КАРТОЧЕК
Подбор участников. Сортировка карточек может выполняться индивидуально или в группе. Для индивидуального
тестирования потребуется с десяток добровольцев. Для группового тестирования рекомендуется сформировать не менее пяти групп по три человека в каждой. В обоих случаях главное то, что участники тестирования должны быть наиболее типичными представителями целевой аудитории.
Слайд 20СОРТИРОВКА КАРТОЧЕК
Подготовка карточек. Тем или иным способом ранее отобранные материалы наносят на отдельные
бумажные карточки. Подписи на карточках должны быть достаточно короткими, чтобы участники могли их быстро прочитать и в то же время достаточно подробными, чтобы участники могли понять о чем идет речь. Рекомендуется оставить несколько пустых карточек, куда участники тестирования смогут вписать свои предложения. Все карточки, в т.ч. и пустые, снабжаются уникальным идентификатором.
Слайд 21СОРТИРОВКА КАРТОЧЕК
Выполнение теста. Перед началом теста карточки перемешивают, чистые карточки помещают рядом. Участники
теста по одному (или по группам) заходят в комнату и раскладываю карточки так, как считают нужным, при необходимости — записывают свое видение в пустые карточки. Наблюдатель, постоянно присутствующий в комнате, фиксирует результаты сортировки, карточки снова перемешивают и приглашают следующего участника (группу).
Слайд 22СОРТИРОВКА КАРТОЧЕК
Анализ результатов. Результаты тестов сводят в единую таблицу и уже по ней
выявляют те самые пользовательские предпочтения, ради чего все это и затевалось. Здесь нет каких-либо точных инструкций, поскольку любой анализ есть «нечто среднее между магией и наукой».
Слайд 23СОРТИРОВКА КАРТОЧЕК
Таблица 1. Применение метода сортировки карточек
Слайд 24АНАЛИЗ КОНКУРЕНТОВ
Анализ конкурентов — простой, недорогой и эффективный метод, позволяющий выявить сильные и
слабые стороны программных продуктов или сервисов, аналогичных проектируемому, но уже имеющихся на рынке. Небольшое время, потраченное на ознакомление с несколькими наиболее популярными аналогами и представление использованных в них способов решения типичных задач на обсуждение заинтересованным сторонам, исключает необходимость «изобретать велосипед». В ходе обсуждения преимущества и недостатки сторонних разработок анализируются, а результаты фиксируются в виде перечня вопросов, которые предстоит решить, чтобы обойти конкурентов. Также результатом применения этого метода может являться список возможностей, которые, возможно, потребуется включить в новый продукт
Слайд 25ДИАГРАММЫ БЛИЗОСТИ
Оригинальное название этого метода — affinity diagramming — можно перевести как построение диаграммы
тематического сходства/близости. Метод основан на сортировке карточек, но выполняется иначе: группировкой элементов занимаются представители разработчика и эксперты со стороны заказчика в ходе совместного обсуждения. Участникам представляется возможность реструктурировать элементы и/или группы, добавлять новые и удалять не нужные.
Слайд 26МОЗГОВОЙ ШТУРМ
Постановка задачи. В ходе этого этапа проблема, подлежащая решению, должна быть
четко сформулирована.
Генерация идей. Основной этап, на котором от участников требуется быстро предлагать различные, возможно даже абсурдные идеи решения задачи. На этом этапе исключены какие-либо оценки предлагаемых вариантов, поскольку здесь главное — их количество.
Группировка, оценка и отбор идей. Каждая из предложенных идей обсуждается и принимается решение о возможности ее дальнейшего использования.
Слайд 27ФОКУС-ГРУППЫ
Фокус-группа — это неформальное собрание пользователей, у которых запрашивается мнение по определенной
теме. Цель в том, чтобы выявить чувства, восприятие, общее отношение и идеи участников обсуждения применительно к обсуждаемому вопросу. Метод фокус-групп применяется, в первую очередь, для сбора информации, но не для ее оценки, поэтому важно так начать дискуссию, чтобы пользователи перешли к активному обсуждению. Иначе, можно получить ответы не столько выражающие мнение участников, сколько ожидаемые организаторами. Фокус-группы часто применяются для тестирования ранее внедренной или внедряемой системы. Положительным аспектом этого метода является то, что в ходе обмена мнениями пользователи обучают друг друга.
Слайд 28ДНЕВНИКИ НАБЛЮДЕНИЙ
Высокоэффективная, но довольно сложная методика анализа пользователей, основанная на длительном по
времени наблюдении за их действиями при работе с автоматизированной системой. Все действия фиксируются в виде дневниковых записей, в конце эксперимента производится анализ полученной информации. При достаточном объеме данных можно (и нужно) провести статистические исследования и получить количественные значения качественных показателей (например, через количество обращений к определенной операции оценить ее доступность через пользовательский интерфейс).
Слайд 29ДНЕВНИКИ НАБЛЮДЕНИЙ
Сложности метода связаны, в основном, с нежеланием пользователей сотрудничать. Если дневник
ведет наблюдатель-представитель разработчика, то он должен «слиться с фоном», поскольку мало кто из наблюдаемых любит, когда у него «стоят над душой». Если же дневник поручено вести самому пользователю, то часть информации он, скорее всего, «возьмет с потолка» (попробуйте проанализировать эту ситуацию самостоятельно).
Слайд 30ПРОТОТИПИРОВАНИЕ
Прототипирование (создание прототипа) выполняется на основании результатов ранее произведенных исследований. Это позволяет
всем заинтересованным сторонам оценить глубину проработки проекта, сравнить альтернативные варианты с учетом мнения заинтересованных сторон и выбрать то решение, которое пойдет в дальнейшую разработку.
Слайд 31ЮЗАБИЛИТИ-ТЕСТИРОВАНИЕ
Тестирование системы целевыми пользователями, которое может применяться на разных этапах ее создания.
На ранних стадиях этот метод может быть применен в ходе анализа конкурирующих продуктов. При этом на пользователей возлагают задачи субъективной оценки и сопоставления предложений. Юзабилити-тестирование прототипов позволяет оперативно и с меньшими затратами корректировать дизайн пользовательского интерфейса.
Слайд 32СРЕДСТВА
UXSort
UXSort — Windows-приложение, позволяющее выполнять исследования, связанные с определением структуры методом сортировки
карточек. Поддерживает до 1000 карточек, глубна сортировки — до 2-х уровней. Позволяет импортировать карточки из MS Excel или MS Word.
Слайд 33СРЕДСТВА
Pencil Project (Evolus Pencil)
Свободная (GPL v2) программа для создания прототипов, доступая для всех
платформ. Легка в установке и использовании. Имеет большое количество подключаемых наборов шаблонов. Поддерживает экспорт в форматы .html, .svg, .pdf, .odt, .png.
Слайд 34СРЕДСТВА
GUI Machine
GUI Machine — кроссплатформенный инструмент прототипирования интерфейсов десктопных и веб-приложений, позволяющий
быстро и просто создавать высококачественные прототипы и просматривать их в интерактивном режиме. Содержит большое количество нативных и платформо-независимых компонентов.