Требования к пи

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

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

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

• Стиль ПИ.

• Платформа и другие стандарты ПИ для приложения.

• Совместимость с ведущим ПО, работающим на данной платформе (например, приложение X или пакет Y).

• Содержание экрана (например, данные и функции, необходимые в ключевые моменты выполнения задач).

• Поведение экрана (например, входной фокус на первом элементе управления при отображении экрана).

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

• Методы взаимодействия пользователей с системой (например, доступ к командам, способы образования комбинаций клавиш и т.д.).

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

• Обратная связь пользователя в ответ на состояние системы и время отклика.

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

• Запоминание результатов операций расположения и изменения размеров окна, а также данных, состояния и контекста.

• Возможности навигации для приложения.

• Сохранение данных пользователя при навигации.

• Запоминание промежуточных данных пользователя при навигации.

• Интерактивное обучение, поддержка производительности и справочная система.

• Предотвращение ошибок и восстановление системы после ошибок.

• Методы прямого ввода для устранения диалога.

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

• Стандартное использование цвета, индикаторов, графики и т.д.

• Средства обеспечения доступа для пользователей с физическими недостатками.

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

Основные требования по практичности

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

В табл. 9.1 перечислены стандартные или часто используемые метрики, которые могу быть полезными при фиксации практичности ПО. И вновь, цель состоит в том, чтобы неявные требования превратить в явно выраженные и поддающиеся измере­нию. Этот список можно пополнить и другими требованиями.

Таблица 9.1. Примеры требований по практичности

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

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

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

Переменную задачу, выполняет задачу, вызвавшую прерывание, а затем возвращается прерванной задаче и завершает ее.

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

• Количество поддерживаемых прерываний задач.

• Функциональные возможности, поддерживаемые во время прерываний и навигации.

• Поддержка ПИ во время прерываний.

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

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

• Отсутствуют какие-либо отклонения от стандартов платформы (например, согласованность экранного "поведения" клавиатуры и мыши или стандартных и пользовательских элементов управления ПИ).

• Отсутствуют какие-либо отличия между приложениями.

• Уровень удовлетворенности пользователей в отношении согласованности составляет более 90%.

Полезное правило. Необходимо стремиться к устранению каких-либо отличий (т.е. искать доступное и удовлетворительное непротиворечивое решение относительно согласованности и других требований по практичности).

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

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

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