Цвет в требованиях к программному обеспечению

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

Но что такое цвет в данном контексте и к какому виду требований следует отнести подобные предписания? Предлагаю порассуждать.

Начнём с понятия цвета.

Цвет — это некая качественная характеристика электромагнитного излучения, влияющая на зрительное восприятие человека различать объекты. В этом определении мало что понятно, но в бытовом плане все мы представляем, что это. Теперь перейдём к видам требований.

Функциональные требования

Функциональные требования (ФТ) описывают возможности, которыми должна обладать система. Например, они определяют то, как система должна реагировать на те или иные воздействия пользователя. И в этом смысле требование, чтобы кнопка была доступна пользователю для нажатия и чтобы она при нажатии меняла свой цвет на синий, является функциональным требованием. Функция заключается в изменении цвета кнопки на синий цвет. Это всё равно, что требование зажигать определённый цвет на светофоре: цвет имеет значение.

Нефункциональные требования

Нефункциональные требования (НФТ) описывают условия, которым система должна соответствовать. То есть они описывают не сами функции, а то, как система должна выполнять эти функции. Можно сказать, что НФТ — это такие требования, при невыполнении которых система продолжает приносить пользу (выполняя свои функции), но уже не всем и не всегда (т.к. работает медленно, неудобно, небезопасно, её невозможно сопровождать и т.п.).

И в этом ключе требование о том, чтобы при нажатии кнопки запускался расчёт пенсии, а во время выполнения этого расчёта у кнопки был бы синий цвет, выглядит как 2 требования, зафиксированные вместе: во-первых, это функциональное требование относительно необходимости расчёта по нажатию кнопки и, во-вторых, это нефункциональное требование относительно поведения интерфейса пользователя. Здесь уже цвет кнопки не является целью, а выполняет вспомогательную роль.

Давайте посмотрим, в каком контексте цвет ещё может фигурировать в качестве НФТ. Для этого рассмотрим категории НФТ, упоминаемые в различных источниках.

В статье, среди прочих, упоминаются группа требований "Качество в использовании" (Quality in Use). Внутри этой группы есть несколько видов требований, но в данном случае стоит обратить внимание на "точность применения" и "утомляемость при применении". Очевидно, что требования по использованию нейтральных цветов и отказа от полутонов одного цвета может быть продиктовано именно этими соображениями.
В статье, опубликованной Microsoft приводится обширный перечень НФТ, и в контексте рассматриваемой темы стоит обратить внимание на категорию "Доступность" (Accessibility) группы "Требования к взаимодействию с пользователем" (User Experience Requirements). Там говорится: "Решение должно быть пригодным для использования людьми с ограниченными возможностями". Пример требования: "Приложение должно использовать цветовые схемы, которые соответствуют рекомендуемому коэффициенту контрастности между цветами переднего плана и фона, чтобы обеспечить видимость для пользователей с плохим зрением".
ISO 25010 в своей классификации выделяет категорию "Удобство использования" (Usability), в которую входят разные требования. Некоторые перекликаются с уже упомянутыми выше, но из нового стоит отметить эстетику пользовательского интерфейса (User Interface Aesthetics). Так что не только вопросы усталости глаз и различимости элементов UI интересуют авторов ISO, но и вопросы эстетики.
Также стоит вспомнить такую категорию НФТ, как "Концептуальная целостность". Требование довольно широкое. Оно про то, что надо быть последовательным в своих решениях, оно касается самых разных аспектов проектирования систем, и оттого разные авторы порой по-разному на него смотрят (с примером можно ознакомиться здесь). Для нашего случая будет полезным считать, что это про то, что все пользовательские интерфейсы должны быть выполнены в едином стиле, соответствовать единому дизайну. А это автоматически включает в себя и вопросы цветового оформления.
Теперь обратимся к BABOK. Он выделяет такую категорию НФТ, как "Удобство использования", поясняя, что идёт речь про "лёгкость, с которой пользователь может научиться использовать решение". Звучит пространно, но, наверное, можно представить ситуацию, когда на экране монитора информация о сбойных ситуациях будут отображаться синим или даже зелёным цветом. Неочевидность такого выбора явно не пойдёт на пользу удобству использования подобного интерфейса, а значит в требованиях будет нелишним зафиксировать необходимость использования цветов, адекватных ситуациям.
Другая, выделяемая в BABOK категория НФТ, — это сертификация. Это "ограничения решения, которые необходимо удовлетворить для соответствия неким стандартам или отраслевым соглашениям". В этом контексте можно рассмотреть требования и рекомендации правительств некоторых стран (США, Австралии, Канады и пр.) соблюдать при разработке государственных веб-сайтов положений WCAG (Web Content Accessibility Guidelines). Эти положения направлены на улучшение доступности веб-контента.
В развитие темы с точностью применения (п. 1) и удобства использования (п. 5) точно стоит посмотреть на требование из ГОСТ Р ИСО 9241-161—2016 под названием "Состояния графических элементов интерфейса пользователя". Данное требование гласит, что "элементы интерфейса пользователя в зависимости от состояний системы и действий пользователя могут иметь различные состояния. Необходимо, чтобы каждое состояние было чётко отличимо от другого". И тут можно привести в качестве примера требования к системам автоматизации производства об использовании конкретных цветов элементов для штатной работы и аварийной. В условиях производства цветовая маркировка может иметь критическое значение.

Думаю, можно достаточно долго углубляться в существующие в мире классификации НФТ и открывать для себя всё новые грани этого вопроса, но всё же на этом я предлагаю сделать паузу и двигаться дальше.

Бизнес-правила

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

Если обратиться к известной книге К. Вигерса, то он включает в эту категорию корпоративные политики, нормативные требования, отраслевые стандарты и вычислительные алгоритмы. Цитата из той же книги: "Бизнес-правила влияют на бизнес процессы путём определения словаря, наложения ограничений, инициирования действий и управления порядком выполнения вычислений".

Из этого можно сделать вывод, что цвета, зафиксированные на уровне корпоративной политики, — это бизнес-правила типа "Ограничение". И в этом смысле нефункциональные требования, предъявляемые к UI на основе данных политик, будут производными от этих бизнес-правил.

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

Выводы. "Если между событиями A и B прошло более 15 минут, тогда кнопка "Внимание" должна сменить фон на красный".
Вычисления. "Если уровень заполнения бака превышает 50%, то на схеме индикация уровня должна иметь зелёный цвет; при уровне от 30 до 50% — жёлтый; при уровне менее 30% — красный".
Атомарные бизнес-правила. "Красный, оранжевый и жёлтый уровни относятся к опасным уровням пожарной опасности".

Переходные требования

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

На практике мне встречались разные переходные требования, но в контексте цвета стоит вспомнить требование о цвете иконки десктопного приложения. Приведу контекст.

Сотрудники работают с ПО. Однако в ходе одного из проектов потребовалась миграция на более новую версию этого же ПО. В этом процессе было два нюанса:

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

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

Напоследок

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