Large Documents Or Just Software?
bas says : What works best in your opinion, writing large documents with highly analysed requirements or just throw some prototyping in front of the user and let them shoot from the hip?
salcorp says : IŽd say 50/50
I once had a client who simply refused to read any kind of documents until he had a visual prototype developed for him so he could then start talking. When I finally presented the prototype for him he just asked... "humm... where is the documentation?".
Bernard says : If you do not have a specification nailed down, they client is free to change the specifications at will. You better have a cost plus (or time and material) contract!
A fixed bid (or lump sum) contract should be based upon a detailed specification IMO.
aspx says : Documents are always helpful in progress of any software and also uses
in enhancement of any project.so i think that documents are necessary for S/W.
Of course prototype is needed to show any client to judge that it is working according to his specification or not.For testing,of both progammer and client.
Alf says : I always use CASE tools to produce a comprehensive documentation.
Bas, very nice forum. If your visitors visit and participate, this can be a real learning place for many facets of our industry. Great initiative.
ross_valusoft says :
bas>What works best in your opinion, writing large documents with highly analysed requirements or just throw some prototyping in front of the user and let them shoot from the hip?
These two choices are almost at the opposite ends of the spectrum. I think the answer is almost always in between (but of course there are exceptions). My experience with small sized businesses shows that clients are either lazy (very few though), uninformed about software, or too embarrassed to admit that they do not have the skills to write their own statement of needs.
They know their business backwards and also know that they want to improve some aspect of it, but often have difficulty expressing their need in the technical jargon that they think we need to hear. I like to take a verbal brief and then develop a written draft that addressess what the client does now, wants changed, the method of change, my assumptions and constraints for this project. We may dance around this document refining it several times before it is signed off and becomes the basis of our work. This works for me and my clients.
An added benefit, is that I get to talk with the client on a number of occassions and get to know him better, and he me. This helps to break down any mistrust that there might be initially. It is much easier to resolve misunderstandings if both sides have an earlier commitment to each other through previous meetings and negotiating. Would be interested if others have this experience also.
Ross
