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

Показатель Единицы измерения

П роизводительность Количество выполненных транзакций в секунду; время реакции на действия пользователя; время обновления экрана

Размер Килобайты; количество модулей памяти

Удобность использования Время обучения персонала; количество статей в справочной системе

Надежность Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе; вероятность выхода системы из строя; коэффициент готовности системы

Устойчивость к сбоям Время восстановления системы после сбоя; процент событий, приводящих к сбоям; вероятность порчи данных при сбоях

Переносимость Процент машинно-зависимых операторов; количество машинно-зависимых подсистем

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

Нефункциональные требования часто вступают в конфликт с другими требованиями, предъявляемыми к системе. Например, в соответствии с одним из требований размер системы не должен превышать 4 Мбайт, поскольку она должна полностью поместиться в постоянное запоминающее устройство ограниченной емкости. Другое требование обязывает использовать для написания системы язык программирования Ada, который часто применяется для создания критических систем реального времени. Но, допустим, откомпилированная системная программа, написанная на языке Ada, занимает более 4 Мбайт. Итак, одновременное выполнение этих требований невозможно. В этой ситуации следует отказаться от одного из требований. Нужно или применить другой язык программирования, или увеличить объем памяти, выделяемый для системы.

6.8. Определение требований к программному изделию по технологии ssadm

Одной из перспективных технологий создания программных изделий является технология SSADM (Structured Systems Analysis and Design Method), разработанная в Великобритании и принятая в 1993 году в качестве национального стандарта. Эта технология состоит из ряда взаимосвязанных методик для выполнения каждого из предусмотренных по технологии этапов работ.

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

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

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

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

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

В методике определены следующие основные положения:

- функции разработчиков программного изделия при определении требований;

- как осуществляется сбор первичных сведений;

- порядок ведения "Каталога требований";

- виды требований к программным изделиям;

- формулирование требований.