Эти два примера, как вы сказали. Фактически, все нефункциональные требования такого рода могут потенциально конфликтовать друг с другом. В книге «Построение эволюционных архитектур» есть таблица из примерно сотни этих «способностей» (как их часто называют).
Для разработчиков программного обеспечения это своего рода упражнение по рассмотрению потенциального конфликта между любыми двумя из них. Вы можете решить, какие из них важны для ваших проектов, а затем отслеживать эти конфликты.
Чтобы вернуться к своему точному примеру и взглянуть на определение термина robustness
в Википедии:
В информатике устойчивость - это способность компьютерной системы справляться с ошибками во время выполнения [1] [2] и справляться с ошибочными данными.
Как видно из определения, устойчивость связана с ошибками . С другой стороны, вы хотите иметь правильность, что в основном означает отсутствие ошибок.
Чтобы сделать конфликт более очевидным, давайте рассмотрим простое поле ввода. Исходя из требования корректности, любой ошибочный ввод, сделанный пользователем, проще всего отклонить. Но надежность требует от вас возможности работать с этим входом, что может быть не совсем правильно.
Чтобы привести все это к вашей книге: каков сейчас приемлемый компромисс ? Допустим, вы пишете научное приложение, в котором пользователь может ввести величину напряжения, включая величину. Таким образом, правильные входные значения будут примерно такими: «10 кВ» или «200 мВ». Приемлемые компромиссы могут включать разрешение входов, таких как «10 кВ», «10 кВ» или даже просто «10», и для корректности сопоставьте их с действительным значением напряжения. Обратите внимание, что это все еще компромисс, а не «лучшее из двух миров». Рассмотрим прописные и строчные буквы: «10 кВ» и «10 кВ» могут быть хорошими, но «10 мВ» и «10 МВ» могут не быть. Корректность становится сомнительной, так как вы не уверены, сейчас она милли или мега,