How to conceptualize/structure certain requirements

Something I've been pondering in my mind.

If you imagine you're doing a project to implement a COTS system, which is becoming increasingly common for corporate BA's. It's likely you'd have gathered some user requirements around the goals & functionality that the system needs to accommodate, so that the right system could be selected. Once the system has been selected, you are unlikely to go through a detailed functional requirement phase because its an already developed system. However there is bound to be a fair bit of configuration to do within the COTS platform.

If we take for example an ecommerce engine, there is going to be a lot of analysis work to:

• Understand the clients product catalog and how this needs to be modelled within the ecommerce engine 
• Understand the clients pricing model so this can be mapped into the ecommerce engine (e.g. customer specific pricing, volume pricing, discounts etc.)
• Understand shipping options that the client wishes to offer so these can be set up

I'm pondering where this kind of information gets stored and how it gets translated into requirements / backlog items etc. A lot of it isn't functional requirements in the sense of 'user needs to do something'. A lot of it is more about having the right business rules configured, and right data model set up, the right data migrated etc. 

How does everyone conceptualise this kind of information as requirements, and structure them along with all the more typical 'user shall be able to..' requirements.