The requirements engineering research and consulting communities are not serving the interests of software developers who build off-the-shelf application software. Most of our models and methods evolved with the aid of funding from organizations interested in obtaining unique systems under contract and in which there is a clear interface between "customer" and "developer". These origins have spawned many assumptions about what requirements are. Through several design scenarios I illustrate how these assumptions break down in the case of off-the-shelf software. I then suggest some alternative priorities that would address these shortcomings. My aim is to provoke and stimulate thought, not to propose a developed solution.