>I've done lots of research on design over the past couple of years. One quote stands out, IMO especially for Fox developers:

>“When data is the centerpiece of your object, you assign data to objects before saying what they do. Descriptions of data don’t tell you squat about your objects." http://www.theserviceside.net/articles/content/ businessobjects/businessobjects.html
>
>>From my perspective, the first is
>>
>>What do you want to do with the data you will collect -- is it a data feed to other systems, is it an application (like POS or inventory, etc.).
>>
>>Then, what data elements do you want (not structure) -- which ones you already have (legacy) and which ones you don't have (new).
>>
>>Then what functionality -- entry, search, etc.
>>
>>Then reporting.
>>
>>Then interfaces (inbound and outbound) -- type and data elements.
>>
>>The structure and layout is for you to determine in design. They may have some layout (forms) standards, but generally it is up to you to build.

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...