I start by asking the business what things they care about (nouns). I then request business definitions of all of those things. These things are either entities or facts of entities. These definitions and some iterative discussions with the business provide me with the information that I need to create a data model. I can then sit down with the business and validate the data model.
My premise is that the things a business cares about change relatively little with time, at least as long as they stay in the same business. Their processes are more likely to change with time. In my experience, once the business has a good handle on what data they are managing, good business processes to manage that data become more readily apparent. I took this approach over 30 years ago when I designed the patient and claims databases for a large health insurance company. We did not have a relational database at the time but used an in-house written database. The structure remained unchanged for over 14 years, except for new data elements being added as a result of contract changes. I am told that the database was eventually replaced with a relational database.