Главная » UML » Что такое "требование"

0

В данном случае требование— это условие или характеристика, которой должна соответствовать система.

Далее мы будем опираться на книгу Роберта Грейди (Robert Grady), который, во время работы в компании Hewlett-Packard, занимался определением критериев качества, которые можно было бы использовать при создании метрики для оценки программных систем. Он выделил следующие необходимые параметры качества: функциональные возможности (functionality), практичность (usability), надежность (reliability), производительность (performance) и возможность поддержки (supportability). В дальнейшем мы будем использовать аббревиатуру FURPS, которая напоминает о типах требований, требующих ! рассмотрения для полного определения качественной системы.

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

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

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

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

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

Нефункциональные требования к параметрам качества можно разделить на категории FURPS.

•     Практичность

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

•     Надежность

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

•     Производительность

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

1 Robert  Grady.  Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs, NJ: Prentice-Hall, 1992, p. 32.

 

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

•   Возможность поддержки

Требования этого типа связаны с возможностью тестирования, эксплуатации и другими параметрами качества, необходимыми для обновления системы после ее выпуска. Это единственные требования, которые не обязательно должны включаться в саму систему, но которые часто относятся к процессу, используемому для создания системы или различных артефактов процесса разработки системы. Например, использование специфического стандарта кодировки в языке C++.

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

По теме:

  • Комментарии