Практичность

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

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

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

• Указать время выполнения типичных задач или транзакций, осуществляемых конечным пользователем. При создании системы ввода заказов на покупку, вероятно, наиболее типичными задачами, выполняемыми конечными пользователями/ будут ввод, удаление или модификация заказа, а также проверка состояния заказа. Если пользователь знает, как выполнять эти задачи, сколько времени он потратит на ввод типичного заказа? Минуту? Пять минут? Час? Конечно, это будет зависеть от технической реализации (скорости модема, пропускной способности сети, ОП, мощности ЦП, которые совместно определяют время ответа, обеспечиваемое системой), но время выполнения задач также напрямую зависят от практичности системы, и нужно иметь возможность определить это отдельно.

• Сравнить практичность новой системы с уже существующими современными системами, которые известны и пользуются успехом у пользователей. Иными словами, требование может выглядеть так: "Новая система должна быть признана подавляющим большинством (90%) пользователей такой же практичной, как и существующая ХYZ-система". Напоминаем, что такие требования, равно как и все остальные, должны допускать возможность проверки соответствия; мы должны описывать требование так, чтобы пользователи могли проверить соответствие практичности установленному нами критерию.

• Оговорить существование систем интерактивных подсказок, программ помощников, средств предупреждения, руководств пользователя и других форм документации и помощи, а также определить их необходимые функции.

• Следовать соглашениям и стандартам, разработанным для человеко-машинного интерфейса. Чтобы новая система работала "почти так же, как та, которую я уже использовал". необходимо следовать согласованным стандартам от приложения к приложению. Например, вы можете указать требование соответствия общим стандартам практичности, таким как стандарты CUA (Common User access)компании IВМ или стандарты Windows-приложений, опубликованные компанией Microsoft.

Примером подлинного прорыва в сфере практичности в компьютерном мире может служить разница между командными строками операционных систем DOS и UNIX и GUI интерфейсами операционных систем Windows и Macintosh. GUI-интерфейсы значительно упростили использование компьютера для пользователей, не имеющих технического образования. Еще одним примером является Internet-броузер, который стал окном в мир World Wide Web и радикально ускорил освоение Internet средним пользователем.

Было предпринято несколько интересных попыток сделать более строгим весьма расплывчатое понятие практичности. Наибольший интерес представляет так называемый "Билль о правах пользователей" (Карат (Кarat), 1998). Последняя его версия состоит из десяти основных пунктов.

1. Пользователь всегда прав. Если возникает проблема с использованием системы, то дело в системе, а не в пользователе.

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

3. Пользователь имеет право на то. чтобы система делала в точности то. что обещано.

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

5. Пользователь имеет право на внимание со стороны системы, а также на то, чтобы иметь возможность получить ответ системы на запрос о внимании.

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

7. Пользователь имеет право на то, чтобы его информировали обо всех системных требованиях для успешного использования программного о6еспечения или аппаратуры.

8. Пользователь имеет право знать о пределах возможностей системы.

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

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

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