Пользовательские интерфейсы и спецификация требований к ПО

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

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

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

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

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

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

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

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

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

«Золотая середина» подразумевает включение концептуальных изображений выбранных экранов — я их называю набросками, несмотря на качество их выполнения, — в требования без обязательного точного соблюдения этих моделей при реализации. На рис. 10-1 показан пример наброска веб-страницы. Включение таких набросков в спецификацию требований предоставляет еще одно представление требований, при этом ясно говорится, что это наброски, а не готовый вид интерфейсе. Например, предварительный набросок сложного диалогового окна может проиллюстрировать назначение части требований, однако опытный дизайнер интерфейсов сумеет превратить его в диалоговое окно с вкладками для повышения удобства работы пользователя.

Рис. 10-1. Пример наброска пользовательского интерфейса, подходящего для включения в документ требований

В командах, работающих над проектами со многими окнами и экранами, часто предпочитают документировать особенности дизайна пользовательского интерфейса в отдельной спецификации пользовательского интерфейса или с помощью средства конструирования интерфейс или создания прототипов. Используйте такие приемы, как создание моделей «отображение-действие-реакция», для описания имена элементов на экране, их свойств и их подробного поведения (Beatty и Chen, 2012).