Generally, the level person that I'm talking to is the one that's wanting the reports, so I am talking to the primary for that (grin).


>I agree with what you are suggesting. The only difference is I speak the people who want to see the reports. Besides, thet are generally the ones writing the checks. Designing the reports first help define the structure of the data. Then the data structure help in design of the forms.
>
>>FWIW, I usually start by getting the user/customer/client to tell me what they want to use the application for (Mostly reporting? Mostly data entry with a little reporting? Passthrough for a larger process? Feed into a larger process? Get fed from another process?). The answer to that question actually answers a lot of smaller questions.
>>
>>The next questions I ask are: 1) Does the application need to inteface with ANY other application, if so - contact points for the other applications, 2) Who is the primary contact for data entry, 3) Name of the network/web support personel (never want to surprise them), and last but not least 4) what kind of security they want/need.
>>
>>After that, I generally start from the data and work my way out to data entry and reporting.
>>
>>>Greetings,
>>>
>>>This may be a rhetorical question, but I'm curious as to how you approach designing a new program/application. Everyone doesn't use the same approach, but I'm sure there are similarities.
>>>
>>>For example... you determine data requirements first, then you may develop data entry modules followed by menus, etc.
>>>
>>>Thanks,
>>>
>>>Vernon