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

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

Другими словами, нефункциональные требования связаны с критериями, которые определяют:

1) качество выполнения отдельных функций и работы программного изделия в целом;

2) условия функционирования системы;

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

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

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

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

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

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

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

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

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

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

На практике выразить нефункциональные требования с помощью количественных показателей весьма затруднительно. Часто заказчик ПИ не может оформить свое видение будущей системы посредством требований, выраженных количественными показателями. Либо некоторые системные требования, например удобство сопровождения, вообще нельзя выразить через количественные показатели. Кроме того, затраты на объективное измерение количественных нефункциональных требований могут оказаться крайне высокими. Поэтому часто документ, специфицирующий требования к системе, содержит описание системных целей совместно с четко сформулированными требованиями. Эти системные цели полезны, поскольку отражают представления (и приоритеты) заказчика о будущей системе. Вместе с тем заказчик должен понимать, что его системные цели могут трактоваться различными способами и их невозможно объективно проконтролировать.

Таблица 6.1