6. Низкоуровневые и высокоуровневые функции

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

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

Пример

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

7. Формализация бизнес-ролей пользователей

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

На входе – доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.

На выходе – описание бизнес-ролей пользователей.

Пример

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

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