You're saying the same thing I did. Determine functionality first, then figure out what data is needed for the functionality.

>Most clients that I have worked with do not understand what data they actually need from the technical point of view. Most think they do, but when it comes to it, they don't. They have general ideas, but not specifics. Trying to define the data object first then becomes problematic -- you have to change based on business requirements.
>
>If you first understand what they want to do -- what is the point of the application, then you can guide them in understanding the data elements that they need. You also need to determine what data attributes they want but are for information (non-processed in transactions, but come along for the ride).
>
>This is my experience over many years -- I have worked on contract for large multi-national customers (multi-billion in revenue) as well as mid-market customers (multi-million to low billion). The same is true -- they understand what they want to do, but do not understand the data model, nor do they generally care about it. They want their data in a transaction to perform some business function. So you need to understand the business function first, then the data attributes associated with the transaction.
>
>In all my projects, the first step is the Business Blueprint -- what is the business requirement. This includes the functionality required and the data attribute definitions. Not the data model. This comes in the next phase, the Realization Phase.
>
>The data model is geek material...