Технические требования (Requirements Engineering; RE — англ. «требования проектирования») — как следует из собственно названия этой отрасли компьютерных наук — представляют собой инженерную дисциплину, выясняющую требования пользователей и определяющую программное обеспечение, необходимое для разработки, внедрения и поддержки цифрового продукта. Существует множество различных определений RE, но все они поддерживают тезис о том, что требования включают в себя выяснение, что пользователи хотят получить от компьютерной системы, и понимание, что эти потребности означают с точки зрения проектирования пользовательского опыта (User eXperience, UX).
Технические требования тесно связаны с разработкой программного обеспечения, в которой большая часть внимания уделяется процессу проектирования системы, соответствующей пожеланиям пользователей. Возможно, что самое краткое определение RE дал выдающийся американский инженер-разработчик, профессор информатики Барри Бём (Barry Boehm) в статье «Экономика разработки программного обеспечения» (Software Engineering Economics), увидевшей свет в 1981 г.: требования описывают «правильное решение», а не разработку программного обеспечения «правильным способом». В 2000 г. Башар Нусейбе (Bashar Nuseibeh) и Стив Истербрук (Steve Easterbrook) сформулировали более всеобъемлющее определение: «Технические требования к программным системам — это обнаружение цели, для достижения которой разрабатывается продукт, осуществляемое посредством определения заинтересованных сторон и их потребностей с последующим документированием полученной информации в форме, позволяющей осуществлять ее анализ, передачу и последующую реализацию в виде завершенного цифрового приложения».
Технические требования разделяют многие общие концепции, методы и соображения с областью человеко-компьютерного взаимодействия (Human Computer Interaction, HCI), в частности, ориентированный на пользователя дизайн, совместную разработку и проектирование взаимодействия. Тем не менее, отрасль RE отличается от HCI взглядом на сферу разработки; например, социально-техническое проектирование редко упоминается в документации по техническим требованиям в том контексте, в котором организационная и «человеческая» часть системы являлась бы явной целью пользовательских потребностей и разработки продукта. Другое отличие заключается в том, что HCI сосредотачивается на дизайне как таковом и на проектировании взаимодействия — на видах деятельности, в которых пользовательские требования рассматриваются как часть процессов исследования дизайна, создания прототипа и оценки с участием пользователей, а не как более линейная последовательность процессов «спецификация-проектирование-имплементация», одобряемая и практикуемая сообществом разработчиков RE.
Тем не менее, технические требования — это метод, безусловно поддерживающий итеративный дизайн, прототипирование и оценку продукта (в терминах RE — валидацию). Кроме того, в среде профессионалов растет осознание того факта, что собственно требования не могут быть указаны без наличия какой-либо предварительной разработки, что привело к появлению такого понятия как «требования к архитектуре» (Architecture requirements). Ниже будет рассказано об общих чертах и различиях, наблюдающихся между такими дисциплинами как человеко-компьютерное взаимодействие и технические требования, чтобы дать читателям пищу для размышлений о том, как два метода решают одну и ту же проблему: как создать цифровой продукт, удовлетворяющий потребностям целевой аудитории?
1. Действия и процессы, связанные с техническими требованиями
1.1. Оценка масштабов
Разработка требований часто начинается с расплывчатого заявления о намерениях. Первая проблема заключается в установлении границы исследования и, в частности, масштабов предполагаемой системы. К сожалению, решение этой задачи редко бывает простым, поскольку клиенты часто не знают точно, чего хотят, а представление о предполагаемой системе туманно. Оценка масштабов, как правило, является итеративной деятельностью, поскольку границы поля деятельности становятся более ясными с увеличением области взаимопонимания между всеми заинтересованными сторонами. Тем не менее, упоминаемый процесс плохо изучен, и было проведено совсем небольшое число исследований, непосредственно затрагивающих эту сложную проблему.
Рассмотрим, например, систему, помогающую эпидемиологам в проведении исследований, — она в виде технического задания была представлена в рамках британского проекта ADVISES. К заинтересованным сторонам в данном случае относятся аналитики, работающие в системе общественного здравоохранения и проявляющие интерес к области эпидемиологии, а также медицинские исследователи. Ряд возможных инструментов поддержки процессов принятия решений может включать средства сбора и подготовки данных, статистический анализ, визуализацию, графики, карты, а также поддержку совместного обсуждения результатов. Владелец и масштаб системы были неясны, так как проект был инициирован в рамках программы исследований в области электронных наук, поддерживаемой правительством Великобритании, и предназначался для пользователей, являвшихся академическими исследователями в области эпидемиологии и взаимодействующих с аналитиками из сферы общественного здравоохранения, работающих в местных больницах.
Будучи примененным для общей оценки масштабов метод моделирования предприятий предоставляет способ описания бизнес-контекста для выявления требований в целом (то есть целей, задач, политик), но не дает почти никаких указаний относительно анализа отдельных процессов. В ходе семинаров часто применяется метод KJ-брейнсторминга, названный так в честь его изобретателя Дзиро Кавакиты (Jiro Kawakita), и быстрая разработка приложений (Rapid Applications Development) — таков текущий уровень отрасли; обе эти техники поддерживают использование списков и неформальных карт проблемного пространства, однако же и эти методов предлагают недостаточное количество систематических указаний. Более детально оценка масштабов была исследована Майклом Джексоном (Michael Jackson) и Памелой Зейв (Pamela Zave) в работе 1993 года «Описание областей» (Domain Descriptions), в которой предлагаются методики установления границы системы путем изучения предполагаемых обязательных системных реакций, генерируемых в ответ на события реального мира, однако это не помогает в проведении исследований, которые начинаются с самых обобщенных пользовательских заявлений о намерениях.
Оценку масштаба лучше всего осуществлять посредством обсуждений со всеми заинтересованными сторонами, а также при помощи документирования системных целей высокого уровня, определяемых в качестве круга полномочий. Документальная регистрация масштаба, как правило, фокусирует внимание пользователей на том, где должны пролегать границы системного исследования, и помогает идентифицировать хотя бы первоначальную сферу охвата системы.
1.2. Сбор фактов
По большей части методы этой деятельности были заимствованы из системного анализа — например, интервьюирование, наблюдение, анкетирование, анализ текстов и документов. Для сбора фактов использовались различные технологии получения знаний, такие, например, как сетки каталогизации и протокольный анализ, но систематическое изучение сущности этой исследовательской методики не проводилось — за исключением работы 1994 года «Методы получения знаний для разработки технических требований» (Knowledge acquisition techniques for requirements engineering; Maiden, N. A. M. and Rugg, G.). Интересной формирующейся техникой представляется использование этнографических — и связанных с ними — методов наблюдений. Тем не менее, до сих пор не существует четких правил по сбору и анализу фактов, поэтому разработчики программного обеспечения предлагают свои собственные «быстрые и грязные» способы решения задач.
1.3. Анализ
Анализ и моделирование обычно следуют «нисходящему» подходу, концентрируясь на декомпозиции целей. Движущей силой анализа чаще всего являются 5 вопросов:
- Каково предназначение системы (её цели)?
- Какие объекты задействованы?
- Где находится система?
- Когда что-то должно произойти?
- Почему система необходима (цели или проблемы, которые она намеревается решить)?
В качестве широко распространенного подхода рассматривают ориентированный на цели анализ, использующий сценарии для обнаружения препятствий или потенциальных проблем, вызванных внешними агентами, с которыми приходится сталкиваться системе. Посредством рассмотрения препятствий можно разработать цели, служащие поддержанию, недопущению и исправлению определенных ситуаций.
Другие методы декомпозиции целей следуют таксономическому подходу и пытаются анализировать цели в контексте типовой схемы. Британский профессор системотехники Питер Чекленд (Peter Checkland) разработал методологию «мягких систем» (Soft Systems Methodology, SSM), дающую средства неформального моделирования и представляющую аналитический подход к обнаружению проблемно-ориентированных требований. В рамках SSM для документирования анализа по мере его осуществления используются неофициальные диаграммы и эскизы, которые можно назвать типовыми схемами или комплексными изображениями. Типовая схема для проекта ADVISES показана на рисунке 1.
Рисунок 1: типовая схема проекта ADVISES, выполненная в качестве неофициальной диаграммы, показывающей заинтересованные стороны и организации.
Участвующие организации показаны в прямоугольниках как вторичные заинтересованные стороны (Secondary stakeholders), то есть люди, которые заинтересованы в выходе системы, но не являются основными практическими пользователями, изображенными в виде кругов и эллипсов. Первичными заинтересованными сторонами (Primary stakeholders) были аналитики общественного здравоохранения в Фондах первичной медико-санитарной помощи (Primary Care Trusts, местные подразделения, действующие в рамках Национальной службы здравоохранения Великобритании — UK National Health Service) и академические ученые в области медицинской информатики, коллективно сформировавшие подразделение NIHBI (North West Institute of Bio-Health Informatics — Северо-западный институт биомедицинской информатики).
Методы, базирующиеся на логических обоснованиях, также подходят для анализа и моделирования. Таким является структурный анализ иерархических графиков, связывающих цели с потенциальными решениями и обосновывающими их аргументами поддержки.
1.4. Моделирование
В этой сфере деятельности используются результаты анализа и структурируются факты, впоследствии представляемые в виде схем и диаграмм. Технические требования заимствовали приемы, применяемые в рамках этого направления, из методов разработки структурированных систем и концептуального моделирования. Здесь широко используются графические представления неформального моделирования, такие как диаграммы потоков данных и диаграммы отношений сущностей. Многие формальные подходы к моделированию были импортированы из разработки программного обеспечения, хотя эффективность этих методов еще не продемонстрирована в промышленной практике. В процессе выработки технических требований анализ и моделирование часто чередуются, поскольку благодаря актам репрезентации растет понимание проблемной области.
Некоторые примеры записей процесса моделирования показаны на рисунках 2-4. Диаграмма отношений сущностей на рисунке 2 показывает собственно сущности и их функциональные отношения («has» — «был», «prices» — «цены» и т. д.), обеспечивающие моделирование данных и, в конечном счете, разработку базы данных.
Рисунок 2: диаграмма отношений сущностей; объекты показаны как прямоугольники, отношения как соединительные линии.
Рисунок 3: схема потока данных, на которой прямоугольники — это процессы, овалы — внешние движущие силы, а стрелки показывают направления потока информации между процессами.
Диаграммы потоков данных моделируют аспекты системы, связанные с обработкой данных, и дополняют цифровое представление информации схемой отношений сущностей.
Рисунок 4: диаграмма типа i*, также известного как представление целевых требований (GRN, goal requirements notation).
Здесь кругами изображаются действующие силы (факторы), овалами — цели; «облачные формы» обозначают «мягкие цели» или критерии качества, прямоугольники — это ресурсы, а отношения, помеченные буквой D — это зависимости. Задачи, цели которых уже были достигнуты, исключены для упрощения диаграммы.
Диаграмма i* на рисунке 4 иллюстрирует взаимоотношения между заинтересованными сторонами, основные цели и нефункциональные требования (мягкие цели в терминологии i*) в приложении ADVISES. Зависимости между действующими силами и целями обозначаются заглавными буквами D (от англ. Dependencies) на линиях.
1.5. Валидация
Эта ключевая деятельность в области технических требований, несмотря на ее тщательные исследования, продолжает оставаться проблематичной. Валидация подразумевает, что пользователи будут понимать последствия воплощения технического задания, а затем согласятся с ним, то есть подтвердят, что оно точно отражает их пожелания. Сегодняшний уровень отрасли — это методы пошаговых руководств, в которых полуформальные спецификации, такие как диаграммы потоков данных, подвергаются критическому обсуждению в ходе совместных семинаров разработчиков и пользователей.
Пошаговые руководства обладают тем преимуществом, что проверка продукта на соответствие техническому заданию проводится в максимально ранний срок, тогда как прототипы, вероятно, более эффективны, поскольку пользователи более активно реагируют на реальную рабочую систему. К сожалению, применение прототипов по-прежнему сопряжено с затратами на их создание, а плохо организованное использование прототипирования может иметь пагубные последствия. Однако прототипы в сочетании с методами сбора и оценки обратной связи с пользователями могут быть весьма эффективными. В целом, процесс валидации пока что плохо изучен, а разъяснение технических требований является важным, но часто игнорируемым компонентом проектирования. Был проведен ряд исследований, продемонстрировавших необходимость комбинации визуализации, примеров и моделирования для разъяснения сложных требований.
Представления на основе сценариев и анимированные симуляции помогают пользователям увидеть последствия поведения системы и тем самым улучшить валидацию; кроме того, раннее прототипирование со сценарием является мощным средством получения обратной связи. Техника цикла запросов, описанная Колином Поттсом (Colin Potts) и его коллегами в статье «Анализ требований на основе запросов» (Inquiry-based requirements analysis. In IEEE Software ,1994 г.) приближает валидацию к сравнению сценария воображаемого поведения в реальном мире с требуемым поведением, описанным в спецификации. Валидация все еще мало изучена, потому необходимы ее дальнейшие исследования, позволяющие понять, как взаимодействуют между собой объяснение, представление и понимание системных спецификаций пользователями.
В проекте ADVISES валидация требований выполнялась как процесс показа пользователям различных проектов — первоначально как раскадровок, а затем в качестве макетов и прототипов. Это упростило выяснение пользовательских пожеланий в ходе дискуссии, а также помогло команде разработчиков требований лучше узнать рабочий процесс пользователей. Презентация проекта перед целевой аудиторией для того, чтобы получить от нее полезную обратную связь, редко терпит неудачи, и поэтому подобный подход занимает центральное место в ориентированном на пользователя дизайне.
Рисунок 5 A-B: иллюстрации раскадровок, выполненных в рамках проекта ADVISES и используемых в сеансах валидации с участием пользователей.
Демонстрация прототипа ADVISES на видео:
На рисунке 5 показаны две конфигурации бумажных прототипов для проекта ADVISES, предназначенные для поддержки исследований эпидемиологических данных. На иллюстрации A показана карта вымышленного города, разделенного в соответствии с границами ответственности локальных подразделений Фонда первичной медико-санитарной помощи, включая предполагаемую «горячую точку» в одной области, обозначенной штриховкой для указания на то, что среднее значение эпидемиологической угрозы для этой зоны приходится на крайние значения статистического распределения.
На иллюстрации B изображена та же карта, но теперь разделенная на более мелкие подрайоны, дополненные гистограммами. Прозрачные ацетатные пленки используются для наложения изображений, поэтому различные варианты карт могут быть представлены в интерактивной последовательности, в то время как примечания, записанные на стикерах используются для записи идей и предложений, поступающих по каналам обратной связи во время сеансов валидации. Пользователям предлагается использовать бумажные прототипы, чтобы проиллюстрировать их собственные дизайнерские идеи (см. рис. 6).
Рисунок 6: пользователи в ходе сеанса валидации технических требований обсуждают идеи, зафиксированные на стикерах.
1.6. Анализ компромиссов
Зачастую для удовлетворения технических требований недостаточно составить спецификацию. Технические задания не охватывают нефункциональные требования: хотя проектирование может в какой-то степени их охватывать, их полное решение в рамках технологии не представляется возможным. Требования часто выдвигаются различными заинтересованными сторонами, обладающими противоположными точками зрения, поэтому анализ компромиссов является важным действием для сравнения, определения приоритетов и принятия решений с учетом отличающихся потребностей или вариантов дизайна. Для проведения анализа компромиссов целесообразным представляется применение ранжированных списков или методов на основе матриц с использованием таблиц решений.
Методы моделирования, предложенные Лоренсом Чангом (Lawrence Chung) для сопоставления соотношений и зависимостей между целями, задачами, действующими сторонами и нематериальными целями (таковы, например, нефункциональные требования), содержат некоторые рекомендации по анализу компромиссов. Его метод облегчает отслеживание взаимных влияний между целями и нефункциональными требованиями (NFR), а также дает действенное руководство по поводу потенциальных коллизий, возможных между различными типами NFR (например, требования безопасности могут препятствовать простоте использования). Работа Чанга представляет собой значительный шаг вперед в деле выработки компромиссов.
Пример анализа компромиссов для проекта ADVISES приведен в таблице 1. В ней представлены два набора требований: один от академических исследователей, другой — от аналитиков общественного здравоохранения. Связь между требованиями и различными критериями качества, или нефункциональными требованиями, такими как точность, конфиденциальность и т. д., показана в таблице ниже.
Таблица 1: взаимозависимости между целями требований и критериями качества для точек зрения различных заинтересованных сторон в проекте ADVISES. Значки (✓) показывают приоритетность целей для каждой группы заинтересованных сторон, (-) — нейтральное значение, (–) отображают неодобрение или конфликт целей, а символы (+) подразумевают ассоциации между целями и нефункциональными требованиями. Надписи в ячейках обозначают: Goals — цели, Medical researchers — академические медицинские исследователи, Health analysts — аналитики общественного здравоохранения, Non-functional requirements — нефункциональные требования, Accuracy — точность, Security — безопасность, Usability — юзабилити, Plot data on maps — выводить данные на карты, Show hotspots on maps — показывать «горячие точки» на картах, Provide simple statistics — предоставлять упрощенную статистику, Annotate maps — аннотировать карты, Check data errors — проверять данные на ошибки, Provide advanced statistics — предоставлять расширенную статистику, Prevent analysis errors — предотвращать аналитические ошибки, Encrypt data — шифровать данные, Integrate maps and charts — интегрировать карты и диаграммы.
Таблицы решений, древовидные структуры и блок-схемы — это другие формы представления данных, облегчающие анализ компромиссов и обсуждение за счет того, что они делают пространство вариантов понятным и помогают заинтересованным сторонам видеть их собственные приоритеты с точки зрения других участников.
1.7. Согласование
Социальный аспект технических требований на данный момент изучен недостаточно хорошо. Этот вид деятельности включает в себя многие другие, например, анализ компромиссов и моделирование, но суть его заключается в рассмотрении, обсуждении и согласовании противоречивых требований. Проблемы, согласуемые в рамках проекта ADVISES, приведены в таблице 1. Очевидно, что две группы заинтересованных сторон имеют разные приоритеты, располагая всего несколькими общими целями (проверка данных на ошибки, карты и упрощенная статистика). Если цели заинтересованных сторон не вступают в явный конфликт, то все они могут быть включены в проект, хотя это может усложнить ситуацию. Однако, когда цели конфликтуют, как в случае с опцией «предотвратить ошибки анализа», противоречивые мнения должны быть согласованы в процессе переговоров. Аналитики министерства здравоохранения поначалу восприняли эту цель как оскорбление их профессиональной добросовестности; однако, когда выяснилось положительное влияние этой опции на повышение точности результатов, они приняли это требование.
Труды Чанга в области моделирования способствуют согласованию через создание общего артефакта, при помощи которого можно обсуждать влияния и разрабатывать альтернативные варианты. Это задание выполняется путем создания модели стратегической зависимости для определения отношений между целями, задачами, участниками и т. д., вслед за которой производится моделирование стратегического обоснования, иллюстрирующее потенциальные системные решения, позволяющие обеспечить требования — с аргументами «за» и «против».
К сожалению, эти модели не предоставляют никаких действенных руководящих указаний для согласования требований, хотя Барри Бём (Barry Boehm) и его коллеги в статье «Технические требования в качестве обсуждаемых выигрышных условий» (Software requirements as negotiated win conditions, 1994 г.) предлагают некоторые эвристические правила эвристики для структурирования успешных переговоров относительно требований». Методы анализа заинтересованных сторон при сборе коллективных требований предложенные профессором системного проектирования Линдой Маколей (Linda Macaulay) помогают структурировать состав семинаров с участием различных заинтересованных сторон и обеспечивают основу для рассмотрения целевых потребностей с разных точек зрения. Однако руководства по управлению встречами для обсуждения технических требований, ведению переговоров и разрешению конфликтов по-прежнему трудно найти.
Исследования в области социальных наук, посвященные проведению совещаний, описывают роли, требования к руководству и формирование консенсуса в группах; однако подобные изыскания не применялись к области технических требований.
Рисунок 7: различные группы пользователей могут иметь противоречивые требования, которые обсуждаются на семинарах, проводимых при содействии разработчиков/дизайнеров.
1.8. Схема технических требований
Формирование технических требований происходит различными способами и сочетает в себе многие виды деятельности; процесс может начаться с обнаружения проблем с текущей системой или с примеров продуктов, которые хотят получить пользователи.
Основанные на планировании закупок технические спецификации для выбора цифровых продуктов выходят за рамки этой статьи, поэтому здесь будет объяснен только распространенный, ориентированный на конкретные результаты метод. Разработка требований инициируются старшими менеджерами и руководителями компаний в качестве политик, целей, задач и других заявлений о намерениях, исходящих от высокопоставленных лиц. Этот путь, проиллюстрированный на рисунке 8, требует значительной деятельности по оценке масштабов, поскольку разработка требований начинается с нечетко выраженных намерений и списков пожеланий пользователей.
Стадии процесса формирования требований заимствуются из бизнес-аналитики, например, «Задайте цели политики» (1. Set policy objectives на рис. 8) или «Проведите анализ и создайте модель бизнеса» (2. Analyse and model business; см. рис. 8). Политика может быть проанализирована в бизнес-контексте по корпоративным моделям. К числу не относящихся к техническим требованиям видов деятельности, касающихся анализа политики, принадлежат бизнес-моделирование, анализ цепочки стоимости, теории конкурентных преимуществ и реорганизация бизнес-процессов. На данном этапе применимы также методы бизнес-аналитики, такие как анализ бизнес-процессов, создание концептуальных карт и обнаружение критически важных факторов успеха; однако предложение детальной методологии выходит за пределы компетенции области технических требований.
Ключевая проблема заключается в создании бизнес-модели, позволяющей выявить возможности разработки компьютерных систем, способствующих улучшению конкурентных преимуществ. Хотя некоторые предложения можно найти в моделях цепочки создания стоимости, а также в фактических прецедентах проектирования межорганизационных систем, эта область плохо изучена.
Методы и подходы в сообществе бизнес-аналитиков по-прежнему в значительной степени определяются интуитивным подходом, поэтому, к сожалению, из этого источника можно почерпнуть лишь ограниченное руководство.
Рисунок 8: ориентированный на поставленные цели процесс разработки технических требований (переводы названий стадий процесса приводятся в тексте этого параграфа).
Нисходящая декомпозиция — это распространенный подход, при котором намерения, объявляемые на уровне политики, последовательно разлагаются на отдельные цели. Задачи, поставленные со стороны руководства, комбинируются с пользовательскими фактами, информацией и целями, собранными на стадии выявления требований (3. Elicit requirements; см. рис. 8) с помощью интервью, фокус-групп, семинаров и т. д. Они составляют исходные данные для анализа требований (4. Analyse requirements; см. рис. 8), в процессе которого предварительная информация, обычно представляемая в форме списков и заметок, организуется в виде связей, устанавливаемых между фактами. Например, в схему постепенно добавляются взаимоотношения, поскольку контекст политики понимается с точки зрения того, что предстоит сделать для её достижения (цели), и проявляющихся последствий — как для людей (участники), так и для их организаций (организационные единицы, объекты и т. д.).
Анализ требований «переплетается» с моделированием требований и определением их сферы (5. Model requirements and domain; см. рис. 8), поскольку в результате анализа создаются модели, документирующие факты и их взаимосвязи. Например, моделирование целей в контексте того, как они влияют на задачи и организацию, имеет жизненно важное значение не только для конкретизации смысла неофициальных заявлений о намерениях, но и для оценки воздействия изменений. Цели в качестве лингвистических заявлений о намерениях должны быть уточнены до той стадии, когда может быть описано желательное состояние системы, когда формализация становится возможной. Гипертекстовые инструменты могут оказать помощь в представлении неформальной иерархии целей, а также создании стандартных концептуальных моделей, например, диаграммы потоков данных, но опять-таки в данной области имеется мало рекомендаций или руководств по целенаправленному анализу требований.
Концепция Чанга обеспечивает представление целей в контексте моделей, показывающих зависимости между целями (как функциональными, так и нефункциональными), участниками и задачами, позволяя применять определенные руководящие принципы для декомпозиции целей и моделирования. Моделирование является важным предшественником этапа валидации требований (6. Validate requirements; см. рис. 8), поскольку цели не могут быть легко поняты без контекстуальной детализации того, как они могут быть достигнуты, и выяснения их связей с действующими силами и процессами.
Валидация требований обычно пересекается с согласованием требований (7), поскольку их обсуждение между заинтересованными сторонами и дизайнерами приводит к согласованию или отклонению требований и разрешению конфликтов.
Этапы 4-7 в данном процессе образуют итеративный цикл, поскольку требования редко когда правильно определяются с первого раза. Напротив, требования формируются через неоднократные итерации анализа, моделирования, валидации и согласования. «Маршрут» политики сближается с другими путями формирования технических требований для совместных действий по анализу и согласованию компромиссов, которые важны для целенаправленной разработки требований. После того, как цели разложены до стадии, где желаемое состояние системы поддается описанию, по крайней мере, неформально, могут быть приняты первичные решения об использовании технологии. Некоторые цели становятся функциональными требованиями, в то время как другие имеют последствия только для менеджмента (например, решения, касающиеся ресурсов, организации и человеческой активности).
После описания видов деятельности, осуществляемых в рамках разработки инженерных требований, в следующем разделе будут рассмотрены основанные на сценариях подходы, формирующие точки соприкосновения между отраслями RE и HCI.
2. Проектирование на основе сценария: точки соприкосновения между HCI и RE
Человеко-компьютерное взаимодействие и «родительская» по отношению к техническим требованиям (RE) отрасль — разработка программного обеспечения (Software Engineering; SE) — обе являются дисциплинами проектирования, нацеленными на разработку софтверных систем. Их тесная связь была предметом обстоятельных обсуждений, однако, к сожалению, не увенчавшихся конструктивным синтезом этих двух направлений. Инженерные требования можно рассматривать как своеобразный «интерфейс» или «фронт-энд» разработки программного обеспечения, поскольку RE фокусируется на требованиях и этапах процесса, предшествующих имплементации ПО, хотя граница между RE и SE становится все более размытой. HCI, напротив, охватывает весь процесс проектирования. Установление границ между этой дисциплиной и SE зависит от центров приложения внимания в каждой из них.
Основной сферой интересов RE является программное обеспечение, поэтому пользователи и системы — воспринимаемые в социально-техническом смысле, — в рамках дисциплины выступают как малозначительные проблемы. В то же время HCI фокусируется на людях и пользовательских интерфейсах, а также на разработках более широкой социально-технической системы — в ущерб вниманию, уделяемому архитектуре программного обеспечения.
Точками соприкосновения RE и HCI являются общие процессы и представления, поддерживаемые в различных направлениях проектной деятельности — таких как ориентированный на пользователя дизайн (User-centered design), проектирование на основе сценариев (Scenario based design), итеративная разработка (Iterative development) и гибкая методология разработки (Agile methods).
Как HCI, так и RE использует сценарии в качестве мотивации для проектирования, хотя их формы и функции различаются для каждой отрасли. К сожалению, термин «сценарий» (scenario) широко используется в искусствоведении, вследствие чего у него имеется большое количество определений. Действительно, большая часть литературы по сценариям — особенно в сфере традиционной разработки программного обеспечения — на самом деле описывает последовательности событий, отслеживаемых через модели переходных состояний. В объектно-ориентированном программировании становится трудно различать варианты использования, альтернативные пути прохождения ситуаций использования и сценарии, являющиеся просто очередным вариантом применения приложения. Сценарии в проектировании играют несколько ролей — от «когнитивного протеза», стимулирующего воображение дизайнера, до описания использования системы и проблем, из которых произрастают требования.
В области технических требований сценарии, как правило, рассматриваются как исходные данные для моделирования и тесно связаны с ситуациями использования и требованиями, составляющими раннюю стадию рационального унифицированного процесса (Rational Unified Process; RUP — методология разработки программного обеспечения, созданная компанией Rational Software). Напротив, HCI уделяет меньше внимания связям между сценариями и моделированием; вместо этого сценарии и другие методы — такие как разработка персоны пользователя — применяются для стимулирования мышления в процессе проектирования. Сценарии могут быть связаны с персонами, усиливающими повествовательный опыт путем описания типичных пользователей. Более того — некоторые разработчики предлагают сценарии, умышленно создаваемые как нечто исключительное, чтобы спровоцировать появление конструктивных идей. Можно утверждать, что сценарии являются отправной точкой для моделирования и проектирования в целом; однако в HCI моделирование не пользуется благосклонностью разработчиков, а модели редко упоминаются в качестве компонентов процесса дизайна. В областях формирования технических требований и разработки программного обеспечения моделирование по-прежнему является основным видом деятельности, и этот факт иллюстрирует ключевое расхождение между дисциплинами RE и HCI (см. рисунок 2).
Одним из продуктивных сближений сценариев и моделей является использование сценариев в качестве тестовых данных для валидации моделей проектирования. Этот подход активно изучается в методе цикла запросов, рекомендующем использовать сценарии в качестве конкретных контекстов для проверки полезности и приемлемости выходных результатов, обеспечиваемых системой. Анализируя релевантность показываемых системой результатов потребностям заинтересованных сторон и задачам, описанных в сценарии, аналитик может обнаружить препятствия на пути достижения системных требований. Из сценариев могут быть позаимствованы вводные события, применяемые для тестирований стандартной процедуры валидации и других функциональных требований. Этот подход был усовершенствован до формального процесса выявления достижимости системных целей применительно к ряду состояний окружающей среды, взятых из сценариев.
Рисунок 9: использование сценариев на разных этапах процесса разработки программного обеспечения/технических требований.
Чтобы проиллюстрировать некоторые примеры из разработки электронной научной системы ADVISES, рассмотрим сценарий первоначального видения описывающий, как медицинские исследователи смогут работать в будущем:
- Эпидемиологи рассматривают массивы данных, полученные из разных регионов Великобритании и отображаемые на картах и различных графиках. Учение могут задавать вопросы по поводу этой информации, пользуясь ограниченным естественным языком и простыми элементами управления, такими как ползунки, чтобы сразу увидеть результаты различных анализов своих данных в разных районах страны. Когда они находят интересные результаты, то могут добавлять свои текстовые замечания и отправлять результаты коллегам из других исследовательских групп.
Чтобы сосредоточиться на намеченных результатах, сценарии видения устанавливают сцену для разрабатываемого проекта прежде, чем появится какой-либо прототип.
Сценарии использования, напротив, рисуют более детальное представление того, как система будет работать, и часто сопровождаются раскадровками и прототипами, служащими для иллюстрации разработки:
- Иэн, условный эпидемиолог, желает узнать, существует ли какая-либо связь между астмой и ожирением у детей школьного возраста в различных районах Большого Манчестера. Он загружает наборы данных для распространения астмы и ожирения в разных областях. Отображаемые карты показывают, что в большинстве районов существует слабая взаимосвязь между этими недугами, за исключением двух местных округов, где карта помечена цветовыми кодами, свидетельствующими как о высоком уровне ожирения, так и повышенной заболеваемостью астмой. Иэн проверяет точность полученных результатов, применяя коррекцию плотности статистических данных по районам, а затем выполняя корреляционный анализ. Проверка показывает значимость результатов. Однако неправильная диета и недостаток физических упражнений являются более распространенными причинами детского ожирения, поэтому
- Иэн загружает на карту местоположение спортивных объектов обнаруживает, что в горячих точках, где наблюдаются астма вкупе с ожирением, также располагаются несколько спортивных объектов. Его расследование продолжается.
На более поздних этапах цикла разработки сценарии контекста и использования описывают использование системы, но с учетом того, как можно будет применить системные выходные данные, включая тестовые пробы для употребления в сессиях валидации и оценки.
- Вы аналитик общественного здравоохранения в Большом Хитоне, пригороде Манчестера. Вы заинтересованы в том, чтобы посмотреть индекс массы тела учеников шестого года обучения (в возрасте 11 лет) на подведомственной вам территории. Используя свой первый набор данных создайте новую карту, основанную на среднем уровне статистического охвата района. Загрузите наборы данных детей младшего возраста и внимательно изучите отображаемую карту, используя ползунки, чтобы изменить представление результатов в зависимости от возраста, пола и других переменных. Взгляните, сможете ли вы обнаружить какие-либо общие закономерности, когда вы смотрите на карту только для мужчин, только для женщин и совместную для обоих полов
- Вы заметили «горячую точку» в одном районе на вашей карте подготовительных классов, в которой, как вам представляется, наблюдается более высокий уровень ожирения. Загрузите наборы данных детей младшего возраста и осмотрите изображенную карту, используя ползунки для изменения представления результатов, то есть применяя различные переменные для критериев возраста, пола и другие. Выясните, похож ли этот пик на подлинную «горячую точку».
- В отрасли человеко-компьютерного взаимодействия сценарии похожим образом используются для оценки юзабилити, хотя их роль в этом виде деятельности сформулирована недостаточно четко. Тем не менее скрипты задач или тестов, применяемых в методах валидации, являются ничем иным как сценариями. Другие роли — это сценарии использования, наглядно демонстрирующие проблемы, могущие проявиться в системе; сценарии перспективного видения, стимулирующие разработку новых артефактов; а также сценарии прогнозируемого использования, в которых описывается будущее использование уже спроектированного артефакта.
3. Представление моделей и дизайна
Моделирование представляют собой центральный вопрос сферы RE, поскольку оно используется для представления системы и поддержки обоснований, применяемых в роде разработки требований. Наиболее популярными моделями в области технических требований являются примеры использования, которые применяются совместно с разработкой коммерческих систем и программной инженерией (см. таблицу 2).
Таблица 2.
Для области технических требований более конкретно используется семейство i*-моделей, фиксирующее действующее силы, цели, задачи и ресурсы, соединенные между собой отношениями зависимости и причинно-следственными связями, как показано на рисунках 4 и 11.
Рисунок 10: контекстная диаграмма примера использования и его низкоуровневый аналог, зафиксированный в шаблоне последовательности действий.
Рисунок 11: модель стратегической зависимости в i*-формате, показывающая действующие силы (окружности), цели или функциональные требования высокого уровня (скругленные прямоугольники), ресурсы (прямоугольники) и мягкие цели, или нефункциональные требования («облака»).
Модели целей и целенаправленный анализ также являются ключевыми факторами в разработке требований. Иерархии целей представляют собой декомпозицию пользовательских потребностей с фиксацией отношений, показывающую виды возможного взаимодействия, такие как поддержка, запрет или препятствие. Модели целей разделяют общее наследие с моделями задач, хотя модели задач записывают не только намерение, но и последовательность операций, согласно которой будет выполняться задача. Модели задач связывают иерархии цели-декомпозиции с описаниями последовательности действий на более низких уровнях детализации. Обе модели — целей и задач — используют иерархическую нотацию, как показано на рисунке 12.
Рисунок 12: разработанная для библиотеки модель цели, в которой цели верхнего уровня разлагаются на нижестоящие подцели. Модели задач в HCI выполняются по аналогичной схеме.
Отношения зависимости, обозначаемые символом D на линии, означают, что ассоциация, такая как цель, зависит от действующей силы, которая ее реализует, или цель зависит от ресурса, необходимого для ее достижения. Причинно-следственные отношения фиксируют, как цели будут достигаться посредством задач, действующих сил и ресурсов. Цели относятся к пользователям и эквивалентны их требованиям. В i*-моделировании проводится различие между жесткими целями, становящимся функциональными требованиями, которые должны быть реализованы при программного обеспечения, и мягкими целями (нефункциональными требованиями), воплощающими требования в отношении качества продукта, такие как юзабилити, безопасность, стоимость или точность.
Программная инженерия включает в себя технические требования для того, чтобы обеспечить представление различных точек зрения на софтверную систему — как структуру обработки данных в диаграммах классов, как поведение на диаграммах последовательности действий или как последовательность событий в диаграммах переходных состояний.
Модели задач обеспечивают абстрактный взгляд на реальный мир при помощи семантического набора, мотивированного целью моделирования. Аналогичным образом диаграммы классов в программной инженерии представляют собой абстрактную структуру наследования системных объектов, тогда как диаграммы перехода состояний представляют собой ориентированную на деятельность спецификацию. Модели задач соответствуют жанру моделирования, репрезентирующему намерения (цели) и активность (процедуры или последовательности действий). Область моделирования задач была расширена для охвата ориентированных на данные представлений через структуры предметных знаний в методологии TKS (Task Knowledge Structures — англ. «структуры целевых знаний») и адаптировано к объектно-ориентированной парадигме в подходе, получившем название MAD (Methode Analytique et Description — фр. «Аналитический метод и описание»).
Ключевая роль моделей задач заключается в обозначении проблемного пространства, когда возникает необходимость обосновать распределение функций. Хотя литература по распределению признает необходимость анализа задач, в ней редко представлены непосредственно модели задач. Вместо этого сценарии могут использоваться для мотивации решений о распределении функций в рамках связанных с задачами шаблонов проектирования, таких как IDAS (Information, Decision, Action, Supervision — англ. «информация, решение, действие, наблюдение»). Однако модели задач могут использоваться для разделения активности во время распределения функций, и это остается одной из главных ролей подобного моделирования.
Одно из критических замечаний в адрес анализа задач заключается в том, он не отражает всего богатства взаимодействий, происходящих в реальном мире, по сравнению со сценарными нарративами, концентрирующимися на контекстуальных описаниях. Тем не менее, модели задач были расширены, чтобы описать требования к информации, содержащейся в задачах, а также роль рабочих артефактов в разработках экологических интерфейсов. Другим упущением является отсутствие явного представления связей между действующими силами, участвующими в осуществлении совместных задач. Наконец, модели задач могут быть подвергнуты критике за то, что они не представляют отношения между действующими силами, видом деятельности и организационными структурами, хотя эти концепции описаны в проектных основах социально-технических систем.
Анализ задач в качестве метода не был с готовностью воспринят на практике ни в каких областях проектирования, помимо сообщества инженеров по безопасности, ориентированных на человеческий фактор. Кроме того, моделирование вышло из моды в HCI, где простые способы репрезентации проектов — такие как иерархические диаграммы для информационной архитектуры и эскизы дизайна, структурные схемы и раскадровки — стали общепринятым стандартом.
Общим жанром репрезентации стало обоснование разработки (Design Rationale) — метод, который был принят как в HCI, так и в RE в качестве стандарта для записи проектных решений и представления альтернативных дизайнерских решений для обсуждения. В области технических требований успешно прижилась система записей gIBIS (graphical Issue-Based Information System — англ. «Графическая тематическая информационная система»), применяемая для представления пользовательских целей в качестве требующих решения проблем, сопоставляемых с альтернативными разработками (требованиями), подкрепленными аргументами. Метод QOC, как вариант человеко-компьютерного взаимодействия, следует аналогичному формату, что становится ясно из расшифровки аббревиатуры: Questions — «проблемы проектирования», Options — «альтернативные разработки», Criteria — «критерии выбора компромисса между проектами» (см. рисунок 13).
Рисунок 13: схема обоснования разработки, показывающая технические требования в формате gIBIS.
Проблемы проектирования, показанные на рисунке 13, взяты из тематического исследования анализа требований для критически важной системы управления пожаротушением на контейнерных судах. Ситуация применения системы такова: температурные датчики обнаружили пожар, теперь проблема заключается в том, как уведомить экипаж. На диаграмме показаны три альтернативные проектные решения, связанные с критериями компромиссов. Верхний вариант предлагает использовать для оповещения о пожаре звуковой сигнал, слышимый по всему судну, но не дающий важной информации о месте пожара. Средний вариант — визуальная сигнализация на дисплее панели управления — является надежным, но более локализованным, в то время как в третьем варианте используется визуальная диаграмма корабля, на которой выделяется местоположение пожара, что обеспечивает наилучшую подачу информации. Графические диаграммы обоснования позволяют пользователям видеть компромиссы между различными требованиями в качестве вариантов разработки; однако QOC было непросто внедрить в новые сообщества специалистов-практиков. С аналогичными проблемами также встретилась система записей обоснований gIBIS.
4. Процессы проектирования в областях технических требований и человеко-компьютерного взаимодействия
Одно из ключевых различий между техническими требованиями и HCI заключается в процессах, лежащих в их основаниях. Технические требования — это систематизированная инженерная дисциплина, поэтому предпочтение в ней отдается стандартизированным методам и систематическому процессу разработки. Хотя в отрасли RE нет стандартных методов, таких как методология Rational Unified Process (RUP) в программной инженерии, однако в разработке технических требований соблюдаются устоявшиеся процедуры и применяются определенные наборы методик для выявления, анализа, определения и проверки требований. В программной инженерии характер руководства процессом может варьироваться от значительного — как при использовании RUP — до облегчения в случае употребления agile-методов, аналогичных по своей сути проектам на основе сценариев.
В HCI процесс проектирования осуществляется по принципам ориентированного на пользователя дизайна, где итеративные циклы исследований вариантов разработки и их пользовательской оценки постепенно улучшают продукт, чтобы приблизиться к решению, приемлемому с точки зрения потребностей пользователей. В этой сфере отсутствуют официально принятые процедуры проверки или тестирования дизайна. В противоположность такому положению дел, в области технических требований более пристальное внимание уделяется автоматизированной проверке спецификаций, часто называемой проверкой модели. Она включает в себя автоматическую проверку технических требований к программному обеспечению, чтобы гарантировать, что софтверный код в конечном итоге будет работать правильно и надежно.
Одним из наиболее влиятельных формальных подходов к проектированию требований является метод KAOS и соответствующие инструменты. (KAOS — подход, ориентированный на достижение целевых требований к программному обеспечению. Аббревиатура истолковывается двумя способами: как Knowledge Acquisition in automated specification — «Приобретение знаний в автоматизированных определениях», или, как второй вариант, Keep All Objectives Satisfied — «Достижение всех целей»). KAOS следует основной тенденции RE — целенаправленному подходу, — но требует дополнительных определений, поскольку цели уточняются до элементов более низкого уровня, указывающих на состояние, которого система должна достичь, поддержать или избежать. Проверочные устройства моделей затем подтверждают — или опровергают, — что цели могут быть достигнуты при помощи указанных процедур.
KAOS обеспечивает инструментальную поддержку технических требований, поэтому можно оценить ограничения, преграды и барьеры, совокупно называемые препятствиями; например, можно понять, какие предположения необходимы для достижения конкретной цели? Этот пример просто показывает суть того, что может сделать KAOS и его инструментарий поддержки GRAIL; в реальности он является чуть более сложным, поскольку поддерживает временную логику, позволяющую рассуждать о том, когда цели могут быть достигнуты.
Тем не менее, KAOS и все прочие формальные подходы к разработке программного обеспечения предполагают, что известно значительное количество информации о спецификации продукта и системной среде. Это ключевой момент расхождения с HCI, формирующим концепцию проектирования как более динамичного процесса, в рамках которого знания разработчика продукта могут быть неполными. В сфере HCI раньше отмечался значительный интерес к формальному анализу, с годами последовательно ослабевавший, хотя всё еще наличествующий.
5. Рекомендации по проектированию и многократное использование знаний
Как HCI, так и технические требования применяют многократное использования знаний, хотя и разными способами. В области RE основным подходом к повторному использованию является применение технических требований к продуктовой линейке, при котором они ассоциируются с набором связанных проектов, относящихся к конкретной области применения. Линии продуктов — это вариации на определенную тему, являющиеся обычным явлением для инженерных секторов; в качестве примера можно упомянуть программное обеспечение, применяемое в автомобильной промышленности для управления двигателем и тормозной системой. Требования могут быть классифицированы как основные, общие для многих приложений, и вариативные, то есть изменяющиеся в соответствии с различными версиями дизайна.
Отрасль разработки технических требований переняла методы из более широкой области повторного использования программного обеспечения, в которой создаются иерархические диаграммы характеристик, показывающие ключевые точки в декомпозиции функций, где может происходить адаптация. В области разработки требований эти процессы изучались для того, чтобы получить возможность управлять требованиями к линейкам товаров, что позволяет планировать выпуски очередных релизов и определять приоритетность вариантов и версий продуктов.
Многократное использование требований пользовалось меньшим вниманием, хотя некое их обобщение было предложено в исследовании цифровых контроллеров авиационных двигателей, проведенном в 1997 году и озаглавленном «Десять шагов к повторному использованию систематизированных требований» (Ten Steps Towards Systematic Requirements Reuse). На более теоретическом уровне библиотека «многоразовых» обобщенных требований была связана с моделями абстрактных проблем в работе Алистера Сатклиффа (Alistair Sutcliffe) «Ориентированный на пользователя подход к техническим требованиям» (User-Centred Requirements Engineering, 2002 г.). Эти абстрактные модели являются «отдаленными родственниками» более детализированных и относящихся к отдельным конкретным областям продуктовых линеек, поэтому их повторное использование предназначено лишь обеспечить средства для обдумывания требований, а не для адаптации технических спецификаций под конкретный случай. В области технических требований наиболее абстрактной моделью использования являются структурные описания проблем (Problem Frames), описывающие высокоуровневые требования с точки зрения зависимости между программными процессами и их внешней средой. 4 структуры описывают контроль и управление устройствами (требуемое поведение), реагирование на внешние команды (командование поведением), состояния редактирования и обновления (заготовки) и общие преобразования. Подобные абстрактные модели предоставляют детализированную информацию по 11 семействам проблем, включая транзакции, мониторинг управления, логистику и отслеживание процессов.
HCI уделяет пристальное внимание повторному использованию знаний — в рамках отрасли было выпущено большое количество руководств, включавших в себя описание принципов разработки и эвристические методы, пригодные для использования в качестве рекомендаций общего характера по вопросам дизайна. Цикл «задача-артефакт», показанный на рисунке 14, способствует повторному использованию знаний через артефакты, которые являются образцами завершенного дизайна и могут быть организованы в семейства, подобные линейкам продуктов, хотя создание подобных артефактов, как правило, мотивировано проблемами проектирования взаимодействий, а не функциональности, как в требованиях к продуктовой линейке.
Артефакты связаны с заявками, формулируемыми в виде положительных и отрицательных сторон проектных компромиссов, аналогичных обоснованиям проектирования. Заявки также связаны со сценариями использования, что позволяет зафиксировать рекомендации по проектированию для реальных условий.
Рисунок 14: цикл «задача-артефакт» для создания многократно используемых знаний в HCI.
Превосходства и недостатки в формулировке заявки представляют собой аргументы юзабилити в качестве компромиссов, достигнутых в базирующемся на психологической точке зрения обосновании проектирования. Заявки создаются путем имплементации разработки, оценки юзабилити реализованного артефакта, затем извлечения претензий и итеративного улучшения дизайна. Артефакт становится образцом, воплощающим требование к разработке, в то время как собственно заявка и ссылки на теорию дают обоснование того, почему данное требование должно обеспечить юзабилити продукта, предоставляя дополнительную информацией о зависимостях и компромиссах, допустимых в дизайне (см.таблицу 3).
Таблица 3: пример заявки.
Заявки предполагают более целенаправленную передачу знаний о HCI, чем рекомендации — на основании цикла «задача-артефакт», обеспечивающего контекст взаимодействия. Заявка имеет привязку к конкретной области в контексте применения артефакта; однако они могут быть связаны с универсальными моделями проблем, чтобы дать широкий контекст для повторного использования: например, проблемы, обусловленные человеческим фактором, связаны с задачами мониторинга или обработкой транзакций для найма/займов, продаж и логистики/ распределения и т. д. Кроме того, заявки могут ассоциироваться с паттернами интеракции для того, чтобы увязать знания человеко-компьютерного взаимодействия с примерами использования умений в области разработки программного обеспечения.
Процесс покупки
Проблема
Пользователи хотят приобрести уже выбранный продукт
Решение
Покажите пользователям шаги, которые необходимо совершить для закрытия сделки.
Когда использовать
На сайтах, позволяющих приобретать физические товары — это, как правило, страницы интернет-магазинов, но это также могут быть сайты музеев, продающие другие продукты типа электронных билетов. Покупка также может быть частью более крупных задач, таких как бронирование.
Как
Чтобы пометить товары в корзину покупок, посетителям необходимо выбрать действие по оформлению заказа. Подтверждение покупки — это пятиэтапный процесс со следующими задачами:
- Идентифицировать клиента
- Выбрать адрес доставки и ее специальные параметры.
- Выбрать метод оплаты
- Просмотреть информацию о заказе целиком
- Подтвердить и разместить заказ
- Получить подтверждение по электронной почте
Пользователи могут прервать процедуру оформления заказа на любом этапе. Когда пользователи возвращаются к прерванной процедуре позже, они вынуждены начинать ее выполнение с первой задачи. Рассмотрим применение «мастер»-алгоритма, который помогает пользователю выполнить эти задачи, сводя к минимуму количество используемых веб-страниц. Однако «мастер» не всегда нужен для завершения покупки. Часто сайты запрашивают детали, которые не являются строго необходимыми для обработки заказа. Во многих случаях вся информация о заказе может легко помещаться на одной странице и, следовательно, устранять необходимость в «мастере».
Сведение к минимуму навигационных и нерелевантных элементов страницы
Поскольку покупка — задача, требующая довольно пристального внимания, стандартная компоновка страницы во время процесса покупки должна быть упрощена. Вспомогательные навигационные и контекстные элементы не должны отображаться на странице оформления заказа. Все отвлекающие элементы должны быть удалены с нее.
Вход с использованием логина пользователя
Многие сайты требуют, чтобы в качестве первого шага процесса пользователи вводили свой логин. Хотя это удобно для возвращающихся клиентов, потому что все их личные данные могут быть использованы повторно, подобная процедура не слишком приятна для новых пользователей. Новые клиенты должны иметь возможность приобретать товары без создания учетной записи. По завершении покупки пользователям может быть предложено зарегистрироваться. Процесс регистрации может быть сделан очень простым, поскольку все основные данные уже были зафиксированы во время процесса покупки — необходимым остается выбрать только имя пользователя и пароль.
Подтверждение по электронной почте
Очень важно предоставить пользователям то, что легко доступно после закрытия страницы оформления «заказа». Электронное письмо с информацией о покупке похоже на «квитанцию» для пользователей. Оно должно содержать номер заказа, список предметов в заказе, всю сумму, выставленную к оплате, адрес доставки, информацию о платежах, дату размещения заказа. В письме также должна содержаться подсказка о том, как отслеживать заказ, отменять его или обращаться за помощью.
Зачем
Новым клиентам или тем, кто нечасто пользуется данным сайтом, лучше всего помогают «мастера», позволяющие пользователю совершать покупку небольшими шагами. Возвращающиеся клиенты обычно используют неизменный адрес доставки и одну и ту же кредитную карту. Поэтому процесс можно более эффективно выполнять только на одном обзорном экране с единственной кнопкой призыва к действию — «покупка».
Рисунок 15: пример шаблона HCI для проектирования такого взаимодействия как покупка на сайте электронной коммерции.
Подобный взгляд на проектные заявки аналогичен применению шаблонов, общему для обеих дисциплин. Паттерны фиксируются как советы по разработке, предназначенные для многократного использования, снабженные примерами практического применения, мотивирующим сценарием, описанием контента для приложения и компромиссов между преимуществами и недостатками проекта.
В HCI шаблоны имеют тенденцию к сосредоточению на проблемах и вариантах дизайна пользовательского интерфейса, в то время как в области разработки программного обеспечения обобщенные паттерны варьируются от низкоуровневых программных решений до процессов и конструкций более высокого уровня. Разработчики метода шаблонов рекомендуют, чтобы советы по проектированию были представлены в контексте мотивирующей проблемы совокупно с примерами их конкретного использования. Хотя в методе шаблонов наличествует положение, указывающее на обобщенный ряд проблем, к которым могут быть применены рекомендации по проектированию, этот способ решения задач каждый раз используется в рамках данного конкретного случая (лат. «Ad hoc»). Защитники метода предлагают устанавливать взаимоотношения между отдельными моделями, построенными в гипертекстовую сеть паттернов или язык, чтобы определить контекст использования шаблонов. К сожалению, языки шаблонов также определяются как ad hoc и имеют тенденцию к неполноте описаний ситуаций возможного применения готовых решений.
6. Выводы и будущие направления деятельности
HCI и RE имеют много общих представлений о процессе проектирования. Обе дисциплины выступают за итеративные циклы разработки с тестированием и оценкой, хотя степень сосредоточенности на пользователях в HCI и RE различается. Одной из тем, которая игнорируется обеими дисциплинами, является определение границ автоматизации. Этот вопрос изучается в рамках исследований человеческого фактора, где методы и эвристики для функционального распределения определяют, какой процесс должен быть полностью автоматизирован, либо может выполняться пользователем вручную или же проводиться в режиме совместного человеко-компьютерного сотрудничества. Однако в области разработки технических требований эта проблема рассматривается сравнительно редко, а основное направление HCI предполагает, что границы применения пользовательского интерфейса определяются в процессе исследования дизайна продукта.
В то время как человеко-компьютерное взаимодействие с течением времени становится все менее ориентированным на методики, отрасль технических требований придерживается более систематического инженерного подхода. Методы, рекомендации, принципы и модели редко используются специалистами-разработчиками. Проектирование на основе сценариев является самым близким к тому, что в сфере HCI может считаться систематическим методом, хотя в отраслевом контексте подобный подход может рассматриваться скорее как инструмент мышления, нежели пошаговое руководство. Сценарии, как утверждает Джон Кэрролл (John Carroll), основоположник исследований человеко-компьютерного взаимодействия, оказывают поддержку проектированию, в ходе его выполнения выступая в качестве своеобразных «зондов», позволяющих проверять предположения и стимулировать созидательные способности разработчиков.
Сценарии могут поощрять творческое мышление, но полученные знания могут быть повторно использованы только в обобщенной форме — в качестве требований, принципов и руководящих положений.
HCI расширила сферу своей деятельности от ориентированных на достижение четко поставленных бизнес-целей офисных «рабочих» приложений до пользовательского опыта в области развлечений и проектирования продукта, причем учет роли эмоций и чувств признан важным требованием для проектирования успешных интерактивных систем. Технические требования — в отличие от HCI — практически не разделяют точку зрения, что ориентированные на достижение конкретных целей приложения не могут существовать в отрыве от периодического обращения к эмоциональным потребностям и ценностям пользователей. Сфера RE нуждается в расширении своих усилий, чтобы охватить требования к пользовательскому опыту и основанный на ценностях дизайн.
С другой стороны, HCI может извлечь выгоду из разработки технических требований, заново открыв прошлые исследования, изложенные в систематизированных спецификациях, где проблемы человеко-компьютерного взаимодействия имеют первостепенное значение в критически важных для безопасности приложениях.
Методы анализа препятствий и обоснование предположений и предпочтений пользователей могут быть с пользой инкорпорированы в арсенал исследовательских инструментов отрасли человеко-компьютерного взаимодействия.
Наконец, обе дисциплины должны признать изменяющийся характер программного обеспечения, поскольку цифровые приложения становятся более интеллектуальными, «самосознающими» и адаптируемыми. Ориентированная на человека разработка интеллектуального и поддерживающего множество социальных сетевых связей программного обеспечения — вот задача, которую в будущем предстоит решать в отраслях HCI и RE.
Высоких вам конверсий!
По материалам: interaction-design.org
