Нефункциональные требования к ПО: как их определять и откуда брать цифры

Разрабатываете ли вы настольное приложение (desktop application), web-cайт или систему для автоматизации процессов предприятия, вы неизбежно сталкиваетесь с тем, что вы определяете нефункциональные требования. В этой статье я расскажу, какими они могут быть, и что нужно для того, чтобы определить их значения.

Нефункциональные требования: какими они бывают

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

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

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

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

Чтобы составить полный перечень нефункциональных требований, можно открыть книгу Вигерса и ГОСТ 34; в большинстве случаев этого должно хватить.

Я же пока сосредоточусь на атрибутах качества и расскажу, как определить для них численные значения.

Все атрибуты качества с точки зрения архитектуры системы делятся на две большие группы: первая группа (runtime) – это атрибуты, относящиеся ко времени работы приложения или системы; вторая группа (design time) определяет ключевые аспекты проектирования приложения или системы. Многие из этих атрибутов взаимозависимы.

Рассмотрим более подробно каждую из этих групп.

Группа runtime

• Доступность – атрибут качества, определяющий время непрерывной работы приложения или системы. Чтобы определить этот параметр, обычно указывают  максимально допустимое время простоя системы.
• Надежность – требование, описывающее поведение приложения или системы в нештатных ситуациях (примеры: автоматический перезапуск, восстановление работы, сохранение данных, дублирование важных данных, резервирование логики)
• Требования к времени хранения данных (например, использование БД в качестве постоянного хранилища данных, продолжительность хранения данных)
• Масштабируемость – требования к горизонтальному и/или вертикальному масштабированию приложения или системы. Говоря о вертикальной масштабируемости, мы определяем требования к вертикальной архитектуре системы или приложения. К требованиям вертикальной масштабируемости могут относиться, например, возможность переноса приложений на более мощные SMP-системы, поддержка большого объема памяти и файлов. Говоря о горизонтальной масштабируемости, мы определяем требования к горизонтальной архитектуре системы или приложения. К требованиям горизонтальной масштабируемости могут относиться, например, возможность использования технологий кластеризации. Следует особо заметить, что вертикальное масштабирование обычно направлено на повышение производительности системы. Горизонтальное масштабирование, помимо производительности, позволяет повысить отказоустойчивость системы. Более подробно о вертикальном и горизонтальном масштабировании можно прочитать, например, здесь.
• Требования к удобству использования системы/приложения (с точки зрения пользователя) и требования к удобству и простоте поддержки (Usability)
• Требования к безопасности, как правило, включают в себя три большие категории: требования, связанные с разграничением доступа, требования, связанные с работой с приватными данным, и требования, направленные на снижение рисков от внешних атак
• Требования к конфигурируемости приложения, взаимодействия и расположения компонентов можно условно разделить на четыре уровня: 1. конфигурируемость на основе предопределенного набора параметров (predefined configurability), когда необходимый уровень модификации достигается путем изменения значений параметров из предопределенного набора; 2. конфигурируемость на основе предопределенного набора базовых объектов (framework constrained configurability), когда необходимый уровень модификации достигается путем перекомпоновки предопределенного набора процессов, сущностей и служебных процедур; 3. конфигурируемость путем реализации новых базовых объектов (basis reimplementation), когда обеспечивается расширение набора процессов и сущностей; 4. конфигурируемость путем новой реализации системы (system reimplementation), когда система должна устанавливаться и настраиваться с нуля.
• Требования к производительности решения, определяемые в терминах количества одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, а также скорости и пропускной способности каналов связи
• Ограничения, накладываемые на объем доступной памяти, процессорного времени, дискового пространства, пропускную способность сети, при которых приложение должно эффективно выполнять возложенные на него задачи

Группа design time

• Требования к повторному использованию реализации или компонентов приложения или системы (Reusability). О том, как это выражается в конкретной реализации, будет рассказываться далее. Пока ограничимся лишь тем, что чаще всего эти требования будут возникать там, где общие компоненты используются несколькими модулями разрабатываемой вами системы.
• Требования к расширяемости (Extensibility) приложения или системы в связи с появлением новых функциональных требований, тесно связанное с таким архитектурным атрибутом качества, как переносимость кода. Как правило, на начальном этапе сбора требований можно ограничиться указанием тех функциональных областей, которые в дальнейшем должны удовлетворять требованию расширяемости.
• Требования к переносимости (Portability) приложения или системы на другие платформы
• Требования к взаимодействию между компонентами решения, между внешними компонентами, использование стандартных протоколов и технологий взаимодействия (Interoperability). Например, к таким требованиям можно отнести возможность использования нескольких стандартных протоколов для обмена данными между одной из подсистем разрабатываемой системы и внешней системой-поставщиком данных (на примере ArcGIS)
• Требования к поддержке системы или приложения (Supportability). Среди этих параметров могут быть названы такие как, напрмиер, дешевизна и скорость разработки, прозрачность поведения приложения, простота анализа ошибок и проблем в работе
• Требования к модульности приложения или системы (Modularity). Обычно такие требования указывают, каким образом система должна быть разделена на модули, или перечисляют список обязательных модулей, которые должны входить в состав системы.
• Требования к возможности тестирования (Testability) приложения или системы определяют объем требований к автоматическому и ручному тестированию, наличие необходимого инструментария
• Требования к возможности и простоте локализации (Localizability) приложения или системы определяют возможности и специфические архитектурные требования, накладываемые процессом локализации. Эти требования содержат также перечень языков, на которые предполагается выполнять локализацию приложения или системы
• Требования к совместимости между версиями приложений, между различными приложениями и внешними подсистемами (Compatibility) определяют предыдущие версии продукта или системы, а также список версий внешнего ПО, с которыми должны быть совместимы разрабатываемый продукт или система.

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