Al_Frost
Некоторые моменты(на практике) выглядят не так однозначно...
Хоть и определял Вигерс: "В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта...", однозначно разделить сложно...
В особенности "внешние взаимодействия между системой и внешним миром"...

Сильной неоднозначности нет. Обычно неоднозначность возникает в трактовке Вигерса возникает когда функциональными требованиями искренне считают юзкейы (кстати это мелькает в вашем примере) .. а это таки пользовательские требования.
Нефункциональные требования, и в частности атрибуты качества могут относиться как к системе в целом, так и к конкретному требованию. Пример связки ФТ и НФТ: "Система должна иметь возможность формирования и отображанения отчета ААА по след. форме .... ". "... Отчет должен формироваться не более чем за 5 секунд при выборке данных за период не превышающий 1 месяц".
В данном случае вы можете размещать такое требование как в рамках иерархии корневого ФТ, но при этом в вашей системе УТ оно должно быть идентифицировано как НФТ соответстующего типа, или же вы можете разместить его в отдельном (специальном) разделе вашего SRS с обязательной ссылкой на ФТ к которым оно относится. Обысно вынос ТАКОГО случая в отдельный раздел делают для того, чтобы обратить внимание архитекторов на НФТ, а не заставлять их выискивать требования к быстродействию по всему тексту документа.