Recommended Read: Consequences of the Easy Way Out
One issue in project management that I encounter is this: There's no time for requirements gathering meetings. Lately, there's a project where the customer was complaining about my persistence to do "proper" requirement gathering. We were spending too much time to discuss requirements, working from high level workflow, drilling into details like screen design, exception handling, validations etc. Each meeting, there were issues, disagreements. Indeed, it was tedious.
Sometimes, I also wonder if I am just wasting everyone's time. Should I just take the easy way out and go ahead with development, without satisfying myself that requirments gathering is complete?
Reading this article, I am reminded that taking the easy way out is not the best way out. Great results does not come about by taking the path of least resistance. It is achieved by taking the efforts to getting our fundamentals right. I am reminded of all the things that can go wrong in a software project with incomplete requirements, with all too much assumptions; these translates into error discovered late, costly rework, and frustrations.
Is it worth the effort? All these tedious work? I believe so. But only time will tell. The road is still long... long...
Sometimes, I also wonder if I am just wasting everyone's time. Should I just take the easy way out and go ahead with development, without satisfying myself that requirments gathering is complete?
Reading this article, I am reminded that taking the easy way out is not the best way out. Great results does not come about by taking the path of least resistance. It is achieved by taking the efforts to getting our fundamentals right. I am reminded of all the things that can go wrong in a software project with incomplete requirements, with all too much assumptions; these translates into error discovered late, costly rework, and frustrations.
Is it worth the effort? All these tedious work? I believe so. But only time will tell. The road is still long... long...
posted by Cyrus at 10:33 PM
2 Comments:
You need to be very carful how much requirement gathering you do. I would agree, that in general requirements are too blur. However if you go into too much detail you create the impression that you don't understand the clients industry.
So I make it part of my requirement gathering to research on the industry and understand the specific issues at hand independend from the client. This help me to ask better questions.
An I do think it is not necessary to go onto a form level detail (font/sequence/colors) when gathering requirements. Since there allways will be ambiguity don't try to weed it out with rigor.
I tend to keep requirement gathering sessions rather short and then switch gear and let users work with the prototype -- since I got this favour for paper prototyping it is not expensive to ammend or alter the prototype.
Generally I find it easier to work with users when they have something to interact with (the prototype) than a more generic requirement session. The secret here is interact. It makes such a huge difference between showing a screen shot and letting users act on it.
My 2c
;-) stw
Hi STW,
thanks for the great advice! Indeed, it's a fine line between how much requirements gathering is too much. I believe that can come only with experience.
A pity I cannot do paper prototyping, as my users are regional; our meetings are teleconferences. But I do concur to its usefulness for requirements gathering.
Post a Comment
<< Home