Ah - I'll get it.
Of course that's right, but (there always has to be a but...)
The depth in wich you can gain knowledge about the processes of the customer and gather the requirements is limited by the time (and money) the customer allows you to spend for this. In my experience - like stated before - some customers see almost all value in the finished software but not in the requirements eginieering are the development process itself. A lot non-IT people will never get beyond "the data must be saved permanently" by themselves. They might even omit "permanently" and only say "the data must be saved".
It is then up to us, to ask lots and lots of questions about the data to save, how to save it, how it should be searchable and so on - only a tiny fraction of customers will be able to give you in depth requirements by themselves.
So it's not easy explain a software development process to your customer and get the answers you need (gather reqirements) without pestering someone with questions or making this process a hard-fact interview (this is what a lot of developers would like to do I think: "What data does a customer of you have?" -> "Name, Surname, Address"; "How to save that data?" -> "Please use a relational db with some normalization, but don't overdo it"; "How should the client software look like?" -> "Please make a full featured heavy weight client and a light web client with basic viewing", ... ---- of course communication cannot work like this with non IT / non dev people).
If - as another example - a customer wants you to write a "Customer Management Software" and all you get as requirements is (exaggerated!) "it should manage a list of customers which is to be searchable" (any question will give you this answer permutated) you'll have a very bad time presenting the result to that customer.
=> Customer: "Why does the customer not have billing information saved?" You: "What billing information?" C: "You must have known that once a customer has given us his billing information we need to save it for future use; haven't you looked at our billing process?" Y: "We have never spoken about billing information; you just wanted a list of customers in the easiest way possible" C: "Do you want to tell me, I have not told you to do *bla* *bla*?"
Such things make you look bad in the end, as in this possition you won't be able to argue with your customer - but as some customers even resist to write down requirements specifically you can get into such situations easily.
In my earlier post my point was, that if a customer tells me
"Please stop asking me that stupid questions and get my software done, please"
or
"Can we cut out the time and budget for testing (maybe after squezzing it to the minimum amount even posible and even hiding some in test driven development) so you can spend more time on implementing more features on time?"
then I'll kindly refuse and start explaining again why this is not possible. Everyone who promises something else is fearful of loosing the job or maybe just lying (and supposing to get away with spending 50% more time on the project anyway after locking the customer into it).
I want do make high quality software, have fun along the way developing it and do this in a way wich resonates with my value system (i.e. not lying to someone, not making bad work on purpose - even if forced to, ...).
This belongs in project planning literature, but I'll show it to explain further - this facts are tied together like a triangle:
Product Quality (=> no bugs) <--------> Budget (time, money)
\ /
\ /
\ /
Complexity (lines of code, used tools, features)
Just look a bit around on "The Daily WTF" to get a feeling how you can screw up (or be screwed up).
Welcome
FAQ
Downloads
Wiki
