Обоснование должно быть добавлено на всех этапах определения требований. Обоснование может состоять из свободного текста, ссылок на маркетинговое исследование, других документов, статей или цитат из книг. Цели системы (раздел 2.1.3) часто являются полезны, так как являются источником обоснования. Хукс и Фарри утверждают, что предоставление обоснования является единственным наиболее эффективным способом снижения затрат и повышения качества требований [22].

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

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

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

Наконец, обоснование может снизить затраты на обучение новых сотрудников, предоставляя им справочную информацию о том, почему система ведёт себя именно так. Предоставление обоснования также может повысить качество и снизить затраты на создание требований. Придумать обоснование для плохого требования или ограничения может быть непросто. Принуждая автора спецификации задуматься о том, почему требование необходимо или почему вводится ограничение, мы зачастую улучшаем качество требований. Это может даже привести к отмене требования, поскольку в процессе автор поймёт, что оно не является необходимым или фактически является деталью реализации.

Это устраняет дополнительные ограничения для разработчиков и затраты на проверку ненужных требований. Обоснование также даёт возможность сфокусироваться в требованиях на том, что будет делать система, явно указывая место для справочной информации.

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

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

REQ-MHS-4: Если режим регулятора NORMAL и текущая температура больше или равна нижней желаемой температуре и меньше или равна верхней желаемой температуре, значение регулятора нагрева не должно изменяться.

Обоснование: когда инкубатор нагревается до верхней желаемой температуры, источник тепла следует оставить включённым до тех пор, пока не будет достигнута верхняя желаемая температура. Аналогично, если инкубатор охлаждается до более низкой желаемой температуры, источник тепла следует отключить до тех пор, пока не будет достигнута более низкая желаемая температура.

Не сразу понятно, почему источник тепла следует оставить неизменным в этом диапазоне. Однако логическое обоснование делает стоящие за этим доводы гораздо более ясными. Хукс и Фарри рекомендуют фиксировать обоснование каждого требования [22], чтобы улучшить качество всех требований. Как минимум, должно быть представлено обоснование для каждого требования, для которого причина существования требования неочевидна.

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

Например, одно из ограничений для термостата инкубатора гласит:

EA-IS-1: При включении источника тепла и правильном закрытии инкубатора текущая температура должна повышаться со скоростью не более 1°F в минуту.

Обоснование: Если текущая температура может повышаться со скоростью более 1°F в минуту, термостат может быть не в состоянии отключить источник тепла достаточно быстро, чтобы поддерживать желаемый температурный диапазон, если допустимая задержка, указанная для регулирования температуры, не будет уменьшена.

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

Обоснование также должно быть зафиксировано всякий раз, когда в спецификации вводится число или диапазон. Это помогает разработчику понять, почему-то или иное значение важно или не важно. Это может оказаться неоценимым во время разработки и технического обслуживания.

Например, в термостате инкубатора обоснование одного из ограничений гласит:

EA-OI-3 Нижняя граница безопасного диапазона должна составлять ≥93°F.

Обоснование: Воздействие температуры ниже 93°F приведёт к гипотермии, которая может привести к смерти в течение нескольких минут у тяжелобольных недоношенных детей.

Обоснование наглядно объясняет, почему это число не следует изменять на 90°F, даже если это может позволить использовать более общедоступный и менее дорогой интерфейс пользователя.

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

Обоснование должно быть зафиксировано по ходу разработки требования или ограничения, которое оно объясняет. Это гарантирует, что обоснование будет зафиксировано автором, пока он думает об этом. Это также помогает дать время другим людям на анализ обоснования и возможность подвергнуть его сомнению. В приведённом выше примере, связывающем задержку при регулировании нагрева с максимальным повышением температуры в инкубаторе, гораздо проще записать обоснование, когда вычислялась задержка, чем пытаться перепроектировать обоснование позже.

В следующем разделе мы подведём итоги по данному руководству.

Перейти к 3-ей главе