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

2.11.1 Указывайте обоснование на всех этапах разработки требований, чтобы объяснить, почему требование нужно в принципе или почему указаны конкретно эти значения.

2.11.2 Не используйте обоснование для указания того, что будет делать система, то есть в качестве альтернативного источника требований. Если обоснование имеет важное значение для требуемого поведения системы, оно должно быть сформулировано в качестве требования.

2.11.3 Укажите обоснование для каждого требования, у которого нет очевидной причины, по которой это требование к системе действительно необходимо.

2.11.4 Укажите обоснование для каждого ограничения, у которого нет очевидной причины, почему оно нужно.

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

2.11.6 Обоснование должно быть кратким и соответствующим поясняемому требованию или ограничению. Для больших документов опишите общими словами их актуальность в обосновании и вставьте цитаты из документа.

2.11.7 Как можно скорее зафиксируйте обоснование автора утверждения (первоисточник).

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

В следующем разделе мы подробно разберём, где и как должно быть представлено обоснование в спецификации требований.

Далее к пункту 2.11.1