Надежность. Конечно, никому не нравятся ошибки, системные сбои или потери данных, и если подобные явления нигде в требованиях не упоминаются

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

· Доступность (availability). Система должна быть доступна для операционного использования в течение указанного времени (в процентном выражении). Иногда требование может указывать непрерывную "nonstop" доступность, т.е. 24 часа в сутки, 365 дней в году. Но чаще можно встретить указание 99-процентной или 99,9 процентной доступности между 8 часами утра и полуночью. Отметим, что требования должны указывать, что понимается под "доступностью". Означает ли 100 процентная доступность, что все пользователи должны иметь возможность использовать все системные услуги в любое время?

· Среднее время между отказами (Mean time between failures, MTBF). Оно обычно указывается в часах, но может также указываться в днях, месяцах или годах. Здесь тоже нужна точность: требования должны четко определять, что понимается под "сбоем".

· Среднее время восстановления (Mean time to repair, MTTR). Как долго системе разрешается не работать после сбоя? MTTR может иметь несколько значений; например, пользователь может указать, что 90% всех системных сбоев должны ликвидироваться за 5 минут, а 99.9% - в течение часа. Вновь важна точность: требования должны четко указывать, означает ли восстановление, что все пользователи снова будут иметь возможность получать доступ ко всем услугам, или допускается частичное восстановление.

· Точность (accuracy). Какая точность требуется системам с числовым выводом? Например, должны ли результаты в финансовых системах быть с точностью до пенни или доллара?

· Максимальный коэффициент ошибок. Как правило, выражается как число ошибок приходящееся на тысячу строк кода (bugs/КLOS) или на одну функцию.

· Количество различных ошибок. Обычно ошибки делятся на незначительные, серьезные и критические. Здесь также важны четкие определения: требования должны определять, что понимается под "критической" ошибкой — полная потеря данных или невозможность использовать определенную часть функциональных возможностей системы.

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