21. Soviet Style
,
©2007, Milan Ilnyckyj, sindark.com
The delivered product has the functionality requested by its customers, and yet it is disliked and soon discarded.
More and more of us book our travel using Web sites. When you use a travel site, you enter origin and destination, date, number of passengers, and so on, then select a flight from the search results. If you want to rerun the search to check whether flying business class makes a difference, some sites make you reenter all the data you just entered. If you are patient, you may find a flight that pleases you, but chances are, you’ll grow annoyed enough to give up and try some other provider. Companies with such inferior usability usually go out of business quickly. But that does not stop other companies from making the same mistakes.
You have probably used some of these Soviet-style products that do more or less what they are intended to do but in a way that you find awkward or irritating. You find that the products’ usability is not what it should be; their look and feel is unattractive; they lack certain security aspects you feel are needed; or they contain cultural references you find disconcerting or offensive. These are failures to meet the products’ nonfunctional requirements—those that make them appealing to the humans who use them. Such requirements are every bit as important for eventual acceptance as the functional requirements.
Consider the iPod. It represents the opposite of Soviet style. At the time of this writing, the iPod is the most popular portable music player in the world, commanding about 80 percent of the market. Why is it so popular? It wasn’t the first MP3 player on the market, nor the cheapest. It does what any other MP3 player does. Its success is largely due to its nonfunctional qualities—its attractive packaging, ease of use, capacity, battery life, small size, and—let’s face it—its sheer coolness. These are the nonfunctional requirements that are often overlooked by project teams.
The reason that nonfunctional requirements are often neglected is in part historical. For many years, systems analysis methods concentrated on functional requirements, expressed in notations that captured the functions and data of the products. These methods assumed that somebody else would deal with the requirements for quality of service. The methods were more than a little vague on exactly how an analyst might capture nonfunctional requirements. Analysts knew perfectly well how to specify a use case and draw entity models or activity diagrams, but none of those are any use when addressing nonfunctional requirements such as cultural suitability or look and feel.
When I was about thirty-five,Tom DeMarco gave me my first pair of scissors made for left-handed people. It was a revelation; I could actually use the scissors with my left hand, and I could actually see where I was cutting.
—TRL
It is not difficult to tease out the system’s nonfunctional requirements. Templates are readily available to guide you through all of the important quality-of-service categories. Successful teams make systematic elicitation of nonfunctional requirements a special path in their process, constructing usability models and employing specialists in these areas.
Customer complaints will tell you if you have built a Soviet-style product. Another indicator is an unusual amount of rework and modification. Alternatively, you may receive a lack of feedback—say, fewer than expected bug-fix and enhancement requests—this may mean your customers are not using the product at all. In all of these cases, of course, it’s too late—you’ve already spent your development money.
How can you avoid building a Soviet-style product? Make sure your project plan includes tasks explicitly focused on nonfunctional requirements. That sounds easy, but consider that most Soviet-style systems got that way because nonfunctional qualities were simply ignored. Beyond an ongoing focus, use early project prototyping to generate meaningful feedback on the nonfunctional qualities that will win user affection.