Not everyone can be proficient at creating and comprehending data models. Modeling is a very abstract concept with its own unique hieroglyphic language. So to make it easy on everyone, why not allow people to experience the model as you design it.
1. As your defining the logical data model, stop each week and create a physical model based on the logical model designed so far
2. Create the data schema scripts and build the database on a server some where
3. Auto generate a “Throw-Away” UI based on the schema using a code generator
4. Release the generated UI on to a web server some where
5. Allow your key users that are giving business input on the design access to the UI
6. Get feed back from these users
Most users will describe data and system requirements in terms of UI presentation and reports. This approach is a very natural way to communicate with users and technology has advanced enough to enable us to accomplish this at very little cost.
There are several code generators that can generate UI and code based on templates and database schema. The one that I would recommend would be http://www.ironspeed.com/, because it just works right out of the box. I was able to generate a complete UI within a matter of hours. This one generates code based on Windows DotNet. There are other UI and code generators out there, but I had difficulties getting the output code to work the first time. It is very important to have hassle free “Throw-Away” UI and code generation. NOTE: Though I say “Throw-Away”, the generated code and UI are actually quite good and usable. Plus you can create your own UI templates.
By generating a “Throw-Away” UI for users to play with, you allow the user to experience the Data Model. This speeds up communication and comprehension of the data model. You can then capture the user’s feedback and categorize them into: data definitions and relationships; business rules; workflow; aesthetics; usability issues. Then place the user feed back into a requirements document. Not a bad week’s worth of work!
During this phase, don't get distracted into customizing the UI for aesthetic and usability reasons unless it is dirt cheap to do so. Just record this information into the requirements document. Stay focused on data definitions and relationships in order to get those defined properly. Once the model has been fully defined and explored, you can then start customizing the Generated UI or start a customized UI from ground up.
Note: If the data model is quite large, then you can break up the model into subject areas in which each subject area has its own exploritory and development cycles.
1. Key users get a better understanding about the data model being designed
2. Better feed back from key users
3. The database scripts can be reused for development
4. The data captured by the users can be used to seed the database with example data for developers and testers to use.
5. The generated UI may turn out to be satisfactory to the users needs and requires little or no further development or customization.
6. You have a solid requirements document to develop a customized UI
7. The weekly delivery primes the development cycle
8. Gets the developers hungry to use a code generator and code templates for elements of code needed to create a customized UI.
9. Lowers the number of development and test resources required for the project
1. Increases your chances of the new system fulfilling the actual business needs
2. Decreases your time-to-delivery for a working system
3. Increases reliability, predictability, and maintainability of the new system by encouraging the use of code generators and code templates in strategic ways early on in the design phase
Warning: Garbage in Garbage out. This is very important. Get an experienced data modeler. Your system is driven by the business definitions as well as processes.