Главная | Обратная связь | Поможем написать вашу работу!

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

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

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

Вместе с тем нефункциональные требования могут относиться не только к самой программной системе: одни могут относиться к технологическому процессу создания ПО, другие – содержать перечень стандартов качества, накладываемых на процесс разработки. Кроме того, в спецификации нефункциональных требований может быть указано, что проектирование системы должно выполняться только определенными CASE-средствами, и приведено описание процесса проектирования, которому необходимо следовать.

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

Рис. 5.2. Типы нефункциональных требований

Все нефункциональные требования, показанные на рис. 5.2, я разбил на три большие группы.

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

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

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

Во врезке 5.1 приведен пример требований к продукту, организационных и внешних требований. Требования к продукту связаны со средой программирования APSE для языка Ada. Это ограничивает свободу проектировщика системы в выборе символов – можно использовать только символы из пользовательского интерфейса APSE. Организационные требования указывают, что система должна разрабатываться согласно внутреннему стандарту компании на разработку ПО, имеющему код XYZCo-SP-STAN-95. Внешние требования вытекают из необходимости соблюдения законодательства о сохранении конфиденциальности. Вследствие этого системные операторы не будут иметь доступ к тем данным, которые им не требуются для работы с системой.

Врезка 5.1. Пример нефункциональных требований

Требования к продукту

4.C.8. Все взаимодействия между интерфейсом APSE и пользователем осуществляются на основе стандартного множества символов языка Ada.

Организационные требования

Разработка системы и создание сопутствующей документации выполняются на основе стандарта XYZCo-SP-STAN-95.

Внешние требования

7.6.5. Система не должна раскрывать конфиденциальной информации о заказчике системы, кроме его имени, а также телефонного номера системных операторов.

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

Врезка 5.2. Системные цели и проверка требований

Системная цель

Система должна быть простой в эксплуатации для опытного оператора и сводить количество его ошибок к минимуму.

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

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

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

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

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

Показатель

Единицы измерения

Скорость Размер Простота эксплуатации Надежность Устойчивость к сбоям Переносимость

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

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

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

⇐ Предыдущая 34 35 36 37 383940 41 42 43 Следующая ⇒