Welcome, You are Visitor Number
 |
 |
 |
 |
Home Page - Family/Extracurricular - How we make our living - Memorable Links - FeedBack
Current Wisdom: (updated periodically)
Prototypes can keep customers' expectations in line. (an article by Kevin Strehlo)
The hardest Aspect of specifying requirements is that no matter what you put down on paper or discuss, your customers' expectations aren't going to match.
The easy answer? If a picture is worth a thousand words, then a prototype is worth a million.
When prototyping fails;
Unfortunately, this easy answer applies only to the easiest of projects. Although there are some kinds of applications in which a simple prototype is enough to show the ultimate customer a reasonable facsimile (one iteration after another) of the final product, most applications aren't so easy.
For example, in the project I began discussing last week - to put a game on our Web site - I've given the developers a specification, but they need to get a ton of work done before they'll have anything to show us.
Not Unusual;
Designing an application that meets a customer's expectations is a challenge as old as time. Consider the project in which Microsoft Corp's bill Gates and Paul Allen were creating the first Basic interpreter for MITS Inc's Altair computer. MITS founder Ed Roberts recalls getting a call from Gates to the effect of "We have a Basic interpreter for your machine - would you like to buy it?" He said yes, and Gates went away for weeks - as did all the other people who called saying they had written software for the Altair. Eventually, Gates called again to say that he had a Basic interpreter for the Altair computer but wondered how to send output to the Altair's terminal.
This was the first time the question had been posed to Roberts, who concluded that maybe Gates and Allen had something worth looking at.
Gates and Allen had a full language specification to keep them on target. If you and your customer have the luxury of doing an extensive specification, you'll also probably stay on track. But most teams lack an appropriately extensive specification or the ability to demonstrate work at the right moment.
What to do;
The basic rule is simple: Whenever you need to discuss a question regarding the program's features with your customer, direct the discussion by presenting an answer based on a simplifying assumption. Focus your presentation on benefits rather than simplification.
For example, someone on the Web game development team realized that our initial "king of the hill" specification, which asked for the capability to run a new game entry against the 20 best entries already on the Web site, was going to produce an unacceptably long wait for any feedback.
Moreover, he said, it might be more satisfying for the players to pit themselves against the existing best entrants one at a time.
Behind the scenes this developer had made the simplifying assumption that a "king of the hill" approach would require a ton of infrastructure and a great deal of work because the outcome of a game depends not on a numeric score, but on a subtle interaction of two entries that can change drastically when two different entries face off. The situation is entirely analogous to determining a "king of the hill" winner in the game of rock, paper, and scissors. Rather than argue that point, he sold us on the benefits of a one-on-one approach.
William & Sharon Arnold