I have written a paragraph about the business and gone through that, and refined/expanded/adjusted until I get a better picture of the things I'm dealing with and how those fit together (are related).
I like to create some sample data both good and bad. Helps me clarify what it is I'm trying to do.
Then create a data model often on paper, and work through the data and see if the model supports it, or has issues. The secret is to record the issues and reconcile by either adjusting the model ( or refining the test data if you've found something new).
We used to do this with some made up transactions, then played "stump the model" where others would run the data against the model and point out issues. The issues often help you understand intricacies in the data that were never defined. It's an iterative process -- any issues, go back and do the tests against the model until no issues are found.
There is another thing with forms etc. In the old days we called it "stub processing". You have a form with buttons etc. The only thing in the button click event at this stage is just display a message eg "Button was clicked -- data editing/vetting process goes
here" or "Open Form CustomerDataEntry goes here".. minimal info but you start to get a flow worked out, and you can go back and expand upon those "messages".
As you get into data validation , a message like "validate State and Zip goes here"...
Build stubs, and as you move forward, you put some flesh on the stubs.
If you're working with a client, you can go through major processes by means of stubs fairly quickly and get a lot of feedback as to how the "fleshing out" should be done ( from the client's perspective). Too often I've seen systems that were built by programmers --- not designers and with little to no Client involvement,
Get your client involved. Listen to the questions and feedback. Clients often know more about details than they think.
Anyway enough of a soapbox for now.
One thing that I have found repeatedly is that people really don't know/understand their data. Purchase Order, pick list, bill of materials.... use various terms for the same concept and never define what something is suppose to represent. Better to take a few minutes (helpful with documentation and maintenance later) and define the table/entity in 3-4 lines and record it -- add it to the documentation/help system.
It helps when separating things like Client, Customer, Applicant - when you define/describe them in detail it soon becomes apparent how a Customer differs from an Applicant etc.
