Re: How would you approach this?

Interesting problem you have created. The design as stated not only puts you in the hot seat, but also means that you are completely liable for all and any dissatifaction that the client has and you are not in a position to ever be paid because it can be stated that you have not completed the projects in any satisfactory manner.

michael_at_preece.net (Mike Preece) wrote in message news:<1b0b566c.0310260501.72866c5b_at_posting.google.com>... [[ Stuff Deleted]]
> > > >
> > > > There are other requirements - but they are not known/defined at this
> > > > stage. We were lucky to get this much detail. The CEO for the company
> > > > we're writing this application for is a very hard man to pin down. He
> > > > wants it now but he doesn't know what it is exactly. We had a five
> > > > minute chat with him and, based on that, we come up with:-
> > > >

If the requirements are known to exist but are not yet defined then this also means that you do not have any way of knowing the required business rules for the client. Not only doesn't he want you to know his requirements, he also wants you to fail - for his personal aggenda. If you don't know what his aggenda is then it is foolish to even work with him - he is not being honourable in his dealings with you as the developer and it is then probable that he is not being honourable with anyione else either.

[[Stuff Deleted]]

> I don't know. In your equivalent database design you're free to do
> whatever you like - so long as you give the customer what they need.

If you don't know what the customer wants (from above) you can't give them what they need, hence you are not able to do the design as you please. If the client doesn't know what they want (which can be a lot of the time) then it is up to you to find out. If they are not cooperative then it is a matter of saying that you are not in a position to help them and part your ways.

[[Stuff Deleted]]
>
> Clarification: add whatever integrity constraints you deem
> appropriate. Incidentally, these would take the form of validation of
> the input in a typical Pick implementation.

Again, if you don't know the business rules for the client, how on earth are you ever going to determine any integrity constraints which will also depend on the design you undertake.

I have recently finished a contract with a client that involved cleaning up an existing database. A fair amount of my time was spent in analysing the data they already had and in discussions with them in determining their business rules. They were extremely helpful once they understood the necessity of specifying their requirements. This was the first time in a lot of years that anyone even attempted to do this for them. They now have a written specification of all the current relevant business rules for the database and processes concerned. They also now have a process in place to manage any future changes to these rules and hence chnages to their databases.

So as far as I can see, your problem (though it may be real) is not worth the effort to do anything about as you don't have the neccessary support from your client to make it a success for them and for you. It would be far better for them and for you to actively define their business requirements before getting them any product to work with. Otherwise, if they are not willing to do the fundementals first then it is better for them and for you to walk away from the whole deal.

[[Stuff Deleted]]
> >
> > ...The woman in the office says they used to be numbers but they
> > changed some of them to letters a while ago. They still refer to them
> > as numbers though. Some of the products are numbers, some are letters
> > and some have hyphens and things in them.
> >

This is a litle gem but it is still far too little for the design to proceed.

I have been in the above situation of a non-communicative client and I only succeeded because I was able to get hime to talk on many different things and I listened very hard to what his real requirements were. I was also able to obtain information from other people in his organisation that enabled me to define the necessary business rules that were to be implemented.

His hidden aggenda was to obtain a much higher salary package than he already had as well as obtaining the kudos for bringing this system into reality for the organisation. Knowing this enabled the appropriate action to take place.

regards

Bruce Received on Mon Oct 27 2003 - 04:08:35 CET