Friday, April 24, 2015

Good Requirements, Good Requirements, Good Requirements

The incantation of the title of this post will unfortunately not make good requirements appear out of nowhere. So what does? Teamwork!

Good requirements are all about communication. What is a software requirement/specification anyways but a communications from the consumer to the supplier? As in any form of communications, there must be an understanding between the senders and the receivers of the nomenclature.

Imagine someone called a contractor for an estimate to build a deck, but the consumer really meant a patio. Lets say Joe Consumer communicated the following whilst getting an estimate - "How much would it coat to build a big deck in my back-yard." What's the first thing that contractor would ask? How big...if Joe doesn't know the measurements he'd have to give an approximation. Not being very savvy of measurements because Joe never needed to and he didn't pay attention in the 4th grade, Joe says - "from the garden to the kitchen window and to the end of the third fencepost." Well, since this is a phone call, the contractor obviously doesn't have enough information to give even the remotest estimate. So, says the contractor - "I'll have to come out and take some measurements to give an estimate."

That is to say that the contractor has to take the time to drive to the site, get out some simple tools, measure, and likely draw up some rough sketches before she can have any remote idea of the costs. The information the contractor needs could be what kind of wood, how many stairs, benches, flower boxes, shape, coatings, height, etc... So goes the conversation...until the consumer and the contractor reach a point when they cannot communicate any further because things are getting really confusing and difficult.

Finally, the consumer grabs a magazine and shows the contractor a picture of a stone patio. Somehow it all makes sense at that point. The customer's frustration with the contractor's obsession with wood and the contractor's confusion about why the customer would want the deck at ground level are all abated. There is a clear communication.

The moral of the story is that a communication can and should take several forms. Ultimately what the contractor would likely do is draw a diagram with markings and notes and use that to build the patio. The contractor would include all the hidden parts that make the patio stable while perhaps referencing the picture for aesthetic touches.

In the end, it took a conversation about the details of the project to build the right thing. It's the same in software. If the consumer and builder of software are not talking about the same thing, details can become frustrating. This is why it is important for the askers and the builders to produce requirements/specifications together.

Addendum: Of course when the contractor gives the estimate, she says "I could do it for..." as they always do. Why do they say it this way? Let us pontificate...

Consider the following key elements - time, cost, and quality. The patio could be built for more cost and better quality. Could be built fast for the same price but lower quality. So, what are the driving factors in the estimate that was given? Just something to think about...

No comments:

Post a Comment