Non-functional requirements are your best weapon in the war against unsatisfactory performance in IT solutions. Whether you use user stories or conventional requirements, non-functional requirements are king. In this KnowledgeKnugget™, you will learn the different types of non-functional requirements, how you can express them, and what value they add to your user story.

A User Story Expresses Wants in Measurable Terms

I would like to preface this KnowledgeKnugget™ with a story that has nothing to do with information technology. It is, however, extremely relevant to the process of expressing user stories in measurable terms.

I was out to dinner a while back with a couple of my friends at a restaurant that one friend in particular, (Brad) frequented. Brad was a huge fan of buffalo wings, but he only enjoyed them when they were extremely well done (in his opinion – I would consider them totally ruined)! He often ate at this particular restaurant and expected that they would know how he liked his wings. He ordered them very well done and added, “You know how I like them.” When his order arrived, the wings were, of course, not even close to well done by his standards. He sent them back and instructed the server to tell the chef to “make them really, really crispy” to make sure that they would be done well enough. The delivered wings were slightly darker, but still not to his liking.

 

Brad sent his wings back 3 more times(!), politely requesting that they “over cook”, “sear”, and “burn the suckers” in attempts to get the meal he wanted. After the fifth time, the wings (although still not entirely to Brad’s satisfaction) were at least edible.

When the restaurant manager showed up to ask if everything was all right, he got the full story. Irritated, he went back to the kitchen to speak with the chef. When he returned, he explained to Brad that they had “deep-fried the wings 12 minutes at the prescribed temperature of 375°F which was excessive by the chef’s standards” and that if he wanted them even more done in the future he should order his wings “deep-fried for 17 minutes”.

 

On his next visit to this restaurant, my friend complied and (after assuring the server three times that he knew exactly what he wanted), finally enjoyed his wings deep-fried to his satisfaction right away.

The moral of this story, of course, is that it is not enough to know what you want. You need to be able to specify in measurable terms how a third party (in this case the chef; in the world of IT, the developers) can deliver what you want. The latest possible time when you have to define the measurable dimensions is immediately before the developers start coding. You should prepare yourself, however, by thinking of this in advance. If your non-functional requirements are not objectively measurable, you need to revise, rewrite, or expand them.

User Stories – a Bridge Between Users and IT

User stories take a dramatically different approach to solving the age-old problem of communication between developers and the user community and that difference has a significant impact on measurability. If you follow the user story paradigm faithfully, you captured your user story on the front of a 3X5” index card. If you use any other tool to capture it, you should still attempt to constrain the length of the user story to one or two brief sentences following one of the two widely recognized molds:

… [end of excerpt]