As I take on more complex database work, the main problem seems to be
getting the specification from the client.

I have created some simple spread sheets that allow the client to enter
field names, type, size and sample data. But this isn't enough. I have been
reading up on data flow diagrams and I am keen to use this method to
describe the database back to the client. But I keep thinking there must be
a "standard" way to do all this stuff. Stage 1, Stage 2....etc..

Can anyone give me some tips on how to construct a 'model' (?) of a
database to ensure that the client and I have a clear vision before
development starts.

Thanks,

Paul

"Paul H" <paul@nospam.comwrote in message
news:APGdnfxWYuK5FMTYnZ2dnUVZ8s2dnZ2d@eclipse.net. uk...

As I take on more complex database work, the main problem seems to be
getting the specification from the client.
>
I have created some simple spread sheets that allow the client to enter
field names, type, size and sample data. But this isn't enough. I have
been reading up on data flow diagrams and I am keen to use this method to
describe the database back to the client. But I keep thinking there must
be a "standard" way to do all this stuff. Stage 1, Stage 2....etc..
>
Can anyone give me some tips on how to construct a 'model' (?) of a
database to ensure that the client and I have a clear vision before
development starts.
>
Thanks,
>
Paul
>

I think you'll get some good responses from some of the experts on here so
I'll keep my 2p brief. I think one way to approach it is to ask your client
what reports they want out of the app. If you know that then you're well on
your way to knowing what data they want to store and how you might structure
it. Once you have a prototype, offer it to them for testing and get their
feedback. You should then be able to define a design spec for review and
eventual sign-up. Make sure you do get them to sign up and make it clear
that any additional enhancements will be at additional cost. Once a client
realises what your app is capable of they'll want more and more whistles and
bells added.

HTH - Keith.
www.keithwilby.com

I read somewhere that you will never get a complete answer from the
client. Simply because they usually aren't sure what they want. In a
face to face meeting take copious notes and document everything. This
way when they comeback and say that wasn't what they wanted, you have
it in writing. Also, when setting up the proposal make sure they read
and sign it for your own protection.

Paul H wrote:

As I take on more complex database work, the main problem seems to be
getting the specification from the client.
>
I have created some simple spread sheets that allow the client to enter
field names, type, size and sample data. But this isn't enough. I have been
reading up on data flow diagrams and I am keen to use this method to
describe the database back to the client. But I keep thinking there must be
a "standard" way to do all this stuff. Stage 1, Stage 2....etc..
>
Can anyone give me some tips on how to construct a 'model' (?) of a
database to ensure that the client and I have a clear vision before
development starts.
>
Thanks,
>
Paul

Paul H wrote:

Can anyone give me some tips on how to construct a 'model' (?) of a
database to ensure that the client and I have a clear vision before
development starts.

I never let the client mess with database. He.she has three functions:
1. describe the problem
2. applaud when shown the solution
3. pay

1 and 2 are optional.