Системные требования приложения.
С другой стороны это может решать заказчик. Например требование к поддерживаемым ОС он вполне может выставить.
Но ведь это же бабушка на двое сказала!0_о Если с инструкциями процессора и апи оси все ясно, то как определить минимальную тактовую частоту, рекомендуемую частоту процессора, минимальный и рекомендуемый объем памяти и так далее?
Если разработка софтины идет на некоторой платформе - .NET или J2EE и не слишком выделяется среди прочих, то требования копируются из требований к платформе. Аналогично можно поступить и в отношении ОС. Смотрим системные требования для, напиример, Windows XP и выставляем их. Когда программа реализует какой-то нетривиальный алгоритм, можно "порекомендовать" ту конфигурацию системы, когда время работы программы приемлемо.
По крайней мере в Enterpsise такое подход используется повсеместно.
P.S. Тесты принятия (acceptance test, AT) это набор тестов, составленных обычно заказчиком (но иногда и изготовителем). И направлен он на то, чтобы показать, что разработанная система отвечает всем заявленным заказчиком требованиям (Requirements).
P.S. Тесты принятия (acceptance test, AT) это набор тестов, составленных обычно заказчиком (но иногда и изготовителем). И направлен он на то, чтобы показать, что разработанная система отвечает всем заявленным заказчиком требованиям (Requirements).
Вот чтобы не брать требования с потолка, их и определяют по результатам UAT.
Кстати, я не скажу что это именно "набор тестов", потому что набор тестов скорей звучит как нечто из модульного-функционального автоматизированного тестирования. А UAT скорей (на практике в Enterpise-applications разработке) - некоторый отрезок времени (у нас например, начинается после QA и идет от 2-3 недель до нескольких месяцев), в течении которого "настоящие" пользователи работают с системой.