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

Имущество
Измерение
Скорость	Обработанные транзакции/второй пользователь/время отклика на событие Время обновления экрана
Размер	Количество мегабайт/чипов ПЗУ
Простота использования	Время обучения Количество опорных рам
Надежность	Среднее время отказа Вероятность отказа
Последовательность	Время перезапуска после сбоя Процент событий, вызвавших сбой
Портативность	Процент целевых утверждений Количество целевых систем

цель может быть выражена как «проверенное» ­нефункциональное требование. Объективно проверить предназначение системы невозможно , но в последующее описание можно хотя бы включить программные средства для подсчета ошибок, допущенных пользователями при тестировании системы.
Медицинский персонал может пользоваться всеми функциями системы после двухчасового обучения. После такого обучения среднее количество ошибок, допускаемых опытными пользователями, не должно превышать двух за час использования системы.
Когда это возможно, вы должны количественно определить нефункциональные требования для объективной проверки. На рис . 4.5 показаны индикаторы, которые можно использовать для определения нефункциональных функций системы. Вы можете измерить эти функции во время тестирования системы, чтобы увидеть, соответствует ли система ее нефункциональным требованиям .­
На практике системные заказчики часто испытывают трудности с преобразованием своих целей в измеримые требования. Для некоторых целей, таких как ­устойчивость, не существует простых индикаторов, которые можно было бы использовать. В других случаях, даже если количественные спецификации возможны, клиенты могут быть не в состоянии связать свои потребности с этими спецификациями. Они не понимают, что означают некоторые числа, определяющие надежность (например), с точки зрения повседневного опыта работы с компьютерными системами. Кроме того, стоимость объективной проверки измеримых нефункциональных требований может быть очень высокой, и клиенты, которые платят за систему, могут не считать эти затраты оправданными.
Нефункциональные требования часто конфликтуют и взаимодействуют с другими функциональными или нефункциональными требованиями. Например, требование идентификации на рис. 4.4 требует установки устройства чтения карт на каждом компьютере, подключенном к системе. Однако может быть и другое требование, требующее мобильного доступа к системе с планшетов или смартфонов врачей или медсестер. Обычно они не оборудованы считывателями карт, поэтому ­в таких обстоятельствах может потребоваться поддержка некоторых альтернативных методов идентификации.
В документе требований трудно провести различие между функциональными и нефункциональными требованиями. Если нефункциональные требования указаны отдельно от функциональных требований, взаимосвязь между ними может оказаться трудной для понимания. Однако в идеале следует выделить требования, которые явно связаны с функциями аварийной системы, такими как производительность или надежность. Вы можете сделать это, поместив их в отдельный раздел документа с требованиями или ­отделив их от других системных требований.
Нефункциональные требования, такие как надежность, безопасность и конфиденциальность, особенно важны для критически важных систем. В части 2, в которой описываются методы определения надежности, безопасности и требований к безопасности, ­я рассматриваю эти требования к соединению.