Атрибуты, важные для пользователей

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

Доступность. Под доступностью понимается запланированное время доступности (uptime), в течение которого система действительно доступна для использования и полностью работоспособна. Формально доступность равна среднему времени наработки на отказ (mean time to failure, MTTF) системы, деленному на сумму среднего времени наработки на отказ и ожидаемого времени до восстановления системы после сбоя. На доступность также влияют периоды планового технического обслуживания. Некоторые авторы рассматривают доступность как совокупность надежности, легкости в эксплуатации и целостности (Gilb, 1938).

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

Доступность-1. Система должна быть доступна как минимум на 99,5% по рабочим дням, с 6:00 до полуночи по местному времени и доступна как минимум на 99,95% по рабочим дням, с 16:00до 18:00 по местному времени.

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

Эффективность. Эффективностью называется показатель того, насколько эффективно система использует производительность процессора, место на диске, память или полосу пропускания соединения (Davis, 1993). Эффективность связана с производительностью еще одним классом нефункциональных требований, который обсуждается далее в этой главе. Если система тратит слишком много доступных ресурсов, пользователи заметят снижение производительности — видимого показателя неэффективности. Недостаточная производительность раздражает пользователей, которые ожидают вывода на экран результата запроса к базе данных. Но проблемы производительности кроме того, ставят под удар безопасность, например, при перегрузке системы контроля процессов реального времени. Определите минимальную конфигурацию оборудования, при которой удается достичь заданных эффективности, пропускной способности и производительности. Чтобы позволить нижний предел в случае непредвиденных условий и определить последующий рост, вы можете воспользоваться такой формулировкой:

Эффективность-1. Как минимум 25% пропускной способности процессора и оперативной памяти, доступной приложению, не должно использоваться в условиях запланированной пиковой нагрузки.

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

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

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

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

Целостность. Целостность, которая включает в себя безопасность, о чем уже говорилось в главе 10, связана с блокировкой неавторизированного доступа к системным функциям, предотвращением потери информации, антивирусной защитой ПО и защитой конфиденциальности и безопасности данных, введенных в систему. Целостность очень важна для интернет-приложений. Пользователи систем электронной коммерции хотят обезопасить данные своих кредитных карточек. Посетители Web-сайтов не желают, чтобы приватная информация о них или список посещаемых ими сайтов использовались не по назначению, а поставщики услуг доступа к Интернету хотят защититься от атак типа «отказ в обслуживании» и прочих хакерских атак. В требованиях к целостности нет места ошибкам. Используйте следующие точные термины для формулирования требований к целостности: проверка идентификации пользователя, уровни привилегий пользователя, ограничения доступа или определенные данные, которые должны быть защищены, Вот как можно' сформулировать требования к целостности:

Целостность-1. Только пользователи, обладающие привилегиями уровня Аудитор, должны иметь возможность просматривать транзакции клиентов.

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

Способность к взаимодействию. Способность к взаимодействию показывает, каким образом система обменивается данными или сервисами с другими системами. Чтобы оценить способность к взаимодействию, вам необходимо знать, какие приложения клиенты будут применять совместно с вашим продуктом и обмен каких данных предполагается. Пользователи Chemical Tracking System привыкли рисовать химические структуры, с помощью нескольких коммерческих инструментов, поэтому они выдвинули следующее требование к способности взаимодействия:

Способность к взаимодействию-1. Chemical Tracking System должна иметь возможность импортировать любые допустимые химические структуры из пакетов ChemiDraw (версии 2.3 или более ранней) и Chem-Struct (версии 5 или более ранней).

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

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

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

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

Устойчивость к сбоям. Однажды клиент компании, разрабатывающей устройства для измерений, пожелал, чтобы их следующий продукт «был, как танк». Сотрудникам компании так понравилось сравнение, что они ввели в обиход новый, слегка ироничный атрибут качества — «как танк». Его стали применять, когда речь шла об устойчивости к сбоям, которую еще иногда называют отказоустойчивостью (fault tolerance). Под устойчивостью к сбоям понимают уровень, до которого система продолжает корректно выполнять свои функции, несмотря на неверный ввод данных, недостатки подключенных программных компонентов или компонентов оборудования или неожиданные условия работы. Устойчивое к сбоям ПО легко восстанавливается после различных проблем и «не замечает» ошибок пользователей. Выясняя требования к устойчивости работы ПО, спросите пользователей, какие ошибочные ситуации возможны при работе с системой и как система должна на них реагировать. Вот один из примеров требования к устойчивости к сбоям:

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

Несколько лет назад я занимался разработкой программного компонента многократного использования Graphics Engine, который преобразовывал файлы с графическими схемами и выводил изображение на назначенное устройство вывода (Wiegers. 1996b). Несколько приложений, которым было необходимо создавать графики, обращались к Graphics Engine. Поскольку разработчики не могли контролировать, какие именно данные приложения передают в Graphics Engine, важным атрибутом качества была названа устойчивость к сбоям системы. Одно из наших требований звучало так:

Устойчивость к сбоям-2. Для всех параметров, описывающих графики, должны быть указаны значения по умолчанию, которые ядро Graphics Engine будет использовать в случае, если данные входного параметра указаны неверно или отсутствуют.

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

Удобство и простота использования. Также называется легкостью использования и инженерной психологией. Этот атрибут связан с массой факторов, которые составляют основу того, что пользователи часто описывают как дружелюбие к пользователю. Но в лексиконе аналитиков и разработчиков нет термина «дружественное ПО», они говорят о ПО, которое спроектировано для эффективного и необременительного использования. В последнее время вышло несколько книг, посвященных разработке удобных в использовании программных систем, например Constantine и Lockwood (1999) и Nielsen (2000). Удобство и простота использования измеряется усилиями, требуемыми для подготовки ввода данных, эксплуатации и вывода конечной информации.

Аналитики требований для Chemical Tracking System задавали представителям пользователей такие вопросы, как «Насколько важна для вас возможность быстрого и простого запроса химикатов?» и «Сколько времени вы готовы отвести на запрос?» Все это — несложные исходные точки для определения многих характеристик, которые могут сделать ПО удобным в работе. При обсуждении этого атрибута удается выявить параметры, поддающиеся измерению, например:

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

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

Удобство и простота использования-2. Всем функциям меню File должны соответствовать быстрые клавиши, нажимаемые одновременно с Ctrl. Командам меню, которые также присутствуют в меню File пакета Microsoft Word XP, должны соответствовать те же быстрые клавиши, что и в Word.

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

Удобство и простота использования-3. Химик, который прежде никогда не использовал Chemical Tracking System, должен не более чем 30 минут разобраться, как правильно запросить химикат.