Лекции (1 курс, 2 семестр) УТкПО / Управление требованиями к программному обеспечению 2
.pdf
Нефункциональные требования
Виды нефункциональных требований
Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объему необходимой памяти, надежности (частоте возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.
Виды нефункциональных требований
Организационные требования отображают политику и
организационные процедуры заказчика и разработчика ПО, включают стандарты разработки программного продукта, требования к реализации ПО (к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.
Виды нефункциональных требований
Внешние требования учитывают факторы,
внешние по отношению к разрабатываемой системе и процессу ее разработки.
Они включают требования, определяющие взаимодействие данной системы с другими системами, юридические требования, следование которым гарантирует, что система будет разрабатываться и функционировать в рамках существующего законодательства.
Также сюда входят и этические требования, при соблюдении которых система будет приемлемой для пользователей и/или заказчика.
Количественные
показатели
нефункциональных
требований
Показатель |
Единицы измерения |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
Число выполненных транзакций в секунду; время |
|
|
Скорость |
реакции на действия пользователя; время |
|
|
|
обновления экрана |
|
|
|
|
|
|
Размер |
Килобайты; количество модулей памяти |
|
|
|
|
|
|
Простота |
Время обучения персонала; количество статей в |
|
|
эксплуатации |
справочной системе |
|
|
|
|
|
|
|
Средняя продолжительность времени между двумя |
|
|
Надежность |
последовательными проявлениями ошибок в |
|
|
системе; вероятность выхода системы из строя; |
|
|
|
|
|
|
|
|
коэффициент готовности системы |
|
|
|
|
|
|
|
Время восстановления системы после сбоя; процент |
|
|
Устойчивость к сбоям |
событий, приводящих к сбоям; вероятность порчи |
|
|
|
данных при сбоях |
|
|
|
|
|
|
Переносимость |
Процент машиннозависимых операторов; количество |
|
|
|
|||
машиннозависимых подсистем |
|
|
|
|
|
|
|
|
|
|
|
Методы
описания
требований
Система записи |
Описание |
|
|
|
|||
|
|
|
|
Структурированны |
Использование стандартных форм и шаблонов для |
|
|
|
|
||
й естественный |
написания спецификаций |
|
|
язык |
|
|
|
|
|
|
|
|
|
|
|
Языки описания |
Специальные структурированные языки (подобно языкам |
|
|
программирования), где спецификация требований строится |
|
|
|
требований |
|
|
|
на основе выбранной операционной модели системы |
|
|
|
|
|
|
|
|
|
|
|
|
Использование диаграмм и блок-схемы, дополненных |
|
|
Графические |
текстовыми пояснениями. Наиболее известные примеры |
|
|
нотации |
такого описания: диаграммы структурного анализа и |
|
|
|
проектирования, метод описания вариантов использования |
|
|
|
|
|
|
|
Системы нотаций на основе математических концепций, |
|
|
|
таких как теория конечных автоматов или теория множеств. |
|
|
Математические |
Формализованная однозначная запись системных |
|
|
требований. Однако многие заказчики не понимают |
|
|
|
нотации |
|
|
|
формальных спецификаций, вследствие чего возникают |
|
|
|
|
|
|
|
|
определенные проблемы при заключении контрактов на |
|
|
|
|
|
|
|
разработку ПП |
|
|
|
|
|
|