Интерпретация и уровни требований

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

Заказчики зачастую считают, что требования — это развитая концепция продукта, предназначенная для разработчиков. Те, в свою очередь, полагают, что это детальная разработка интерфейса пользователя. Универсального определения требований нет. В данной работе будем использовать определение требований, предложенное ШЕЕ (Institute of Electrical and Electronics Engineers) и отраженное в стандарте «Standard Glossary of Software Engineering Terminology» как:

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

Эти различия типов требований подтверждается определением, данным И. Соммервиллем [9]:

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

Для определения требований к разрабатываемой системе целесообразно рассмотреть взаимодействие системы с пользователем, представив систему как «черный ящик», взаимодействующий с системной средой (рис. 4.6).

При этом полное определение системы возможно описывать по методу, предложенному Аланом Дэвисом, рассматривая следующие пять основных категорий элементов [100].

• 1. Вводы системы. Описывается содержимое ввода, а при необходимости — и протокол ввода. Этот класс может содержать значительный объем сведений и подвергаться частым изменениям, особенно в средах графического пользовательского интерфейса, мультимедиа и Интернета.
• 2. Выводы системы. Описываются поддерживающие устройства вывода, такие как речевой вывод или видеотерминал, а также протокол и форматы генерируемой информации.
• 3. Функции системы. Отображение вводов в выводы и их различные комбинации.
• 4. Атрибуты системы. Типичные нефункциональные требования, которые должны учитывать разработчики: надежность, удобство сопровождения, пропускная способность.
• 5. Атрибуты системной среды. Дополнительные нефункциональные требования: способность системы функционировать в условиях определенных операционных ограничений и нагрузок, а также совместимость с операционной системой.

Рис. 4.6. Элементы системы.

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

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

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

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

Например, если в начальных требованиях для компьютерной обучающей системы был заложен модуль клиент/доступ к данным/GUI^[1], то альтернативой ему может быть навигационный интерфейс, преимущества которого были выявлены на этапе проектирования. Именно в этом и состоит суть эффективного управления требованиями.

• [1] Graphic User Interfase — графический интерфейс пользователя