Всем привет! Заключительная часть о требованиях, которые вспоминают в последний день перед релизом.
В первой части мы говорили о производительности и масштабируемости, во второй — о сопровождаемости, надёжности и безопасности.
Сегодня в повестке требования, которые влияют на пользовательский опыт и ощущение качества продукта. Да, вы верно догадались, речь про юзабилити, совместимость и переносимость.
Можете ли вы ответить на вопрос, насколько легко использовать вашу систему? Вступает ли она в противоречия с другими приложениями и процессами? На каком оборудовании, операционных системах, в каких браузерах она работает?
Часто на бумаге эти требования выглядят второстепенными, но по факту именно они определяют, будут ли вашим продуктом пользоваться вообще.
Требования к юзабилити
Юзабилити это, по сути, пользовательская дружелюбность продукта. Интерфейс должен быть интуитивно понятным и простым в навигации, функции легко обнаруживаемыми и очевидными, а главное, продукт должен действительно решать задачи пользователя, а не заставлять его разбираться в логике системы.
Несмотря на то что юзабилити часто воспринимается как субъективная характеристика, в инженерной практике её можно и нужно оценивать формально. Существует несколько моделей оценки удобства использования, и одна из самых распространённых предложена Nielsen Norman Group. Она рассматривает юзабилити через пять измерений.
Во‑первых, обучаемость. Насколько быстро пользователь может выполнить основные действия, впервые увидев интерфейс?
Во‑вторых, эффективность. Как быстро пользователь достигает своей цели после того, как освоился с системой?
Далее идёт запоминаемость. Может ли пользователь, вернувшись к интерфейсу спустя время, сразу работать с ним без повторного обучения?
Отдельно оценивается частота ошибок. Как часто пользователи ошибаются и насколько критичны эти ошибки?
И, наконец, удовлетворённость. Субъективное ощущение комфорта от работы с продуктом.
Примеры требований к юзабилити
Требования к юзабилити обычно формулируются через измеримые показатели. Например, доля пользователей, допустивших ошибку при вводе платёжных данных на странице оформления заказа, не должна превышать 10%. Или пользователь должен иметь возможность найти нужный товар не более чем за три клика от главной страницы.
Для продуктов с активным взаимодействием важно отдельно фиксировать доступность ключевых элементов управления. Так, во время видеозвонка кнопки отключения микрофона, камеры и включения демонстрации экрана должны быть всегда видны и доступны без переходов по вложенным меню. Аналогично, наиболее часто используемые функции должны находиться в зоне быстрого доступа и не требовать сложной навигации.
Как формулировать требования к юзабилити
Основной инструмент работы с требованиями к удобству использования это юзабилити‑тестирование. Именно оно позволяет перейти от субъективных ощущений к количественным метрикам и понять, насколько продукт действительно удобен для пользователей.
Если продукт уже существует, имеет смысл начать с оценки текущего состояния, то есть зафиксировать базовый уровень удобства и только после этого формулировать цели улучшения. Если же продукта или прототипа ещё нет, полезно анализировать и тестировать решения конкурентов, чтобы задать измеримые ориентиры.
Важно привязывать требования к юзабилити к бизнес‑метрикам. Например, допустим ли сценарий, при котором только половина пользователей находят нужную функцию? Или какое значение будет приемлемым с точки зрения стратегии продукта и его KPI?
И наконец, проверять удобство использования стоит на прототипах, а не на готовом продукте. Это банальная, но часто игнорируемая истина. Исправлять проблемы юзабилити до релиза значительно дешевле и быстрее, чем после выхода продукта на рынок.
Требования к совместимости
Совместимость определяет, как система может сосуществовать и взаимодействовать с другими системами в одной среде. Проще говоря, эти требования описывают, насколько программный продукт совместим с ��ругими программами, компонентами и инфраструктурой, в которой он работает. Например, приложение, установленное в операционной системе, должно корректно функционировать совместно с системным файрволом или антивирусным ПО. Недостаточная совместимость почти всегда приводит к деградации производительности, ошибкам выполнения или даже потере данных.
Отдельным аспектом совместимости является интероперабельность, то есть способность системы корректно обмениваться данными с внешними системами. Это критически важный тип требований для интеграционных решений, где продукт редко существует в изоляции. От того, насколько чётко сформулированы требования к совместимости, напрямую зависит стабильность и предсказуемость интеграций.
Совместимость тесно связана с переносимостью. Обе категории затрагивают операционные системы, устройства, браузеры, стороннее ПО и их версии. Однако если переносимость отвечает на вопрос, может ли система быть запущена в другой среде, то совместимость сообщает насколько корректно она взаимодействует с окружением. Для современных веб‑приложений стандартом де‑факто стала кроссплатформенность, кроссбраузерность, адаптивность под мобильные устройства и корректная работа в гетерогенной среде.
Примеры требований к совместимости
Требования к совместимости обычно формулируются через перечень поддерживаемых платформ, систем и форматов. Например, iOS‑приложение должно корректно работать на устройствах iPhone с версиями операционной системы 15, 16 и 17.
Для корпоративных и отраслевых решений ключевым становится обмен данными. Так, система управления медицинскими данными должна быть интероперабельной с различными EHR‑системами, обеспечивая безопасный и корректный обмен медицинской информацией. Аналогично, ERP‑система часто обязана быть совместимой с существующим легаси‑ПО компании, чтобы сохранить непрерывность бизнес‑процессов и избежать дорогостоящей миграции.
В пользовательских продуктах требования к совместимости могут касаться аппаратного окружения. Например, сервис видеоконференций должен корректно работать с камерами, микрофонами и акустикой разных производителей. В банковских и финансовых системах часто отдельно фиксируется поддержка распространённых форматов данных (CSV, XLSX, QIF) д��я импорта и экспорта информации.
Как формулировать требования к совместимости
Работу с требованиями к совместимости стоит начинать с определения целевых систем. Необходимо составить список внутренних систем и компонентов, с которыми продукт должен взаимодействовать, и зафиксировать ожидаемый уровень корректности и стабильности этого взаимодействия.
Далее важно явно определить совместимость со сторонними решениями. Если система должна работать в окружении 3rd‑party приложений или интегрироваться с ними, это должно быть отражено в требованиях. При этом имеет смысл сразу обозначить не только сам факт совместимости, но и ожидаемые характеристики — например, допустимые задержки при обмене данными или ограничения по объёму передаваемой информации.
Требования к переносимости
Переносимость определяет, может ли система или её отдельные компоненты работать в различных средах эксплуатации. Обычно речь идёт о различиях в аппаратном обеспечении, операционных системах, программных платформах или способах использования продукта. По сути, требования к переносимости отвечают на вопрос: насколько корректно действия, выполняемые в одной среде, воспроизводятся в другой без изменения поведения системы.
Кроме запуска в разных средах, переносимость также описывает, насколько хорошо компоненты системы могут быть доступны и взаимодействовать между собой при переходе из одного окружения в другое. Для современных продуктов это особенно актуально. Пользователи ожидают, что приложение будет одинаково работать на разных устройствах, в разных ОС и браузерах, без потери функциональности и качества пользовательского опыта.
Примеры требований к переносимости
Требования к переносимости часто формулируются через перечень поддерживаемых платформ и ожидания по неизменности поведения системы. Например, мобильное приложение должно корректно работать и обеспечивать единый пользовательский опыт на устройствах с разными размерами экранов и разрешениями.
В корпоративных системах переносимость может выражаться в поддержке нескольких операционных систем. Программное обеспечение должно запускаться на Windows, macOS и Linux без необходимости доработок. Более узкий, но распространённый пример — требование, чтобы приложение, работающее на Windows 10, без изменений запускалось на Windows 11, сохраняя производительность и поведение.
Для веб‑приложений переносимость часто сводится к полноценной работе во всех основных браузерах (типа Chrome, Firefox, Safari и Edge) с одинаковой логикой, вёрсткой и скоростью отклика.
Как формулировать требования к переносимости
Работа с требованиями к переносимости начинается с понимания целевой аудитории и рынка. Обычно такие требования опираются на результаты маркетинговых исследований, полевых исследований или аналитики по уже существующему продукту. Важно понимать, какими устройствами, операционными системами и браузерами реально пользуются ваши пользователи, а не пытаться поддерживать всё сразу на всякий случай (это сложно, дорого и, зачастую, избыточно).
Полезным источником данных становятся инструменты аналитики. Например, Google Analytics (в Яндекс.Метрике так же есть похожие данные) позволяет определить наиболее распространённые комбинации устройств, браузеров и их версий. Это помогает сформировать реалистичный и приоритетный набор требований к переносимости.
Наконец, имеет смысл зафиксировать максимально полный и однозначный список требований. Такой документ не только направляет разработчиков, но и сразу определяет объём тестирования. Обычно в него входят поддерживаемые операционные системы и их версии, сетевые особенности, перечень браузеров и устройств, а также требования к аппаратному обеспечению. Чётко зафиксированные границы переносимости позволяют избежать размытых ожиданий и конфликтов на этапе приёмки.
Хорошим примером требований к переносимости является официальная документация Visual Studio, где зафиксированы поддерживаемые и неподдерживаемые операционные системы, архитектуры и среды выполнения.
Ну что ж. Иногда нефункциональные требования ошибочно отождествляют с техническими. На практике это разные категории, и понимание различий между функциональными, нефункциональными и техническими требованиями существенно упрощает работу с качеством продукта.
Спасибо за внимание!
Если рассматривать качество продукта системно, аналитика данных становится связующим звеном между требованиями, цифрами и решениями. Курс «Аналитик данных» как раз об этом: работа с запросами стейкхолдеров, статистикой, SQL/Python и BI, чтобы превращать сырые данные в понятные выводы и управленческие решения, а не просто отчёты.
Если хотите понять формат обучения и задать вопросы экспертам — записывайтесь на бесплатные демо-уроки от преподавателей курса:
24 декабря. Строим простой дашборд в Tableau. Записаться
15 января. Топ-5 SQL инструментов, которые используют аналитики каждый день. Записаться
21 января. Ищем аномалии в данных: от простых графиков до машинного обучения. Записаться
