aleks624,

1. FR1 - "Система должна сформировать ответное письмо" - функциональное требование
2. NFR1 - "FR1 должен выполняться не более чем за 1 секунду" - нефункциональное требование


3. SWAR1 - "Для формирования писем НЕЛЬЗЯ использовать CrystalReport (потому что по испытаниям не успевает сформировать письмо за 1 сек)" - архитектурное требование.

1. Нефунциональное требование всегда связано с функциональным (ну или с ПО в целом, как с куском .... функциональности :) ).
2. Реализация нефунционального требования может выявить новые функциональные требования. А к ним могут появиться новые нефункциональные :)

aleks624, какие ещё варианты?
Это нефункциональное требование (если есть отдельное функциональное требование на формирование письма).
То что его изменение приводит к изменению "подхода" и изменению фунциональности - ни о чём не говорит, и ни на что не указывает.

И да, это не ограничение, это обычное нефункциональное требование (в данном случае - к производительности функции формирования письма).
Ограничение - это когда вероятность изменить или отменить такое требование стремятся к нулю... А за 1.001 секунду реализация не подойдёт? :)

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

aleks624, ограничение это такое требование, изменить которое очень маловероятно. Ну, например, уговорить корпорацию использовать ПО на линкус, когда всё в этой корпорации, кроме сетевых маршрутизаторов, работает на винде. Но если вы предлагаете им уникальный софт с параллельными вычислениями, умеющий работать только на линуксе, и переписывание под винду стоит на порядок больше бюджета или 2летней выгоды от проекта, то вот реальное ограничение "ПО будет работать только под управлением линукс". А ваш пример легко как нарушить - отправить письмо за 2 секунды, так и с заказчиком договориться его изменить... Так что это обычное нефункциональное требование :)