By Topic

Ask for Examples

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
Rainsberger, J.B. ; Diaspar Software

Getting features right isn't easy, whether you try to get them all right before writing code or approach each one as you go. It's tense work, much like contract talks. It starts out well enough: the customers describe what they need, and the programmers estimate the cost. Before long, though, lack of trust creeps in, and each side withholds information from the other. As a means of defense, the programmers demand precise, unambiguous statements of the requirement. When the customers try to provide them, they end up expressing their needs in complex, run-on prose. No wonder the requirements are mostly full of holes. Rather than fill the holes, the programmers usually try to meet the requirements as best they can, misinterpreting them along the way, and the result is software nobody wants. Examples help both with complex rules, which are difficult to describe with prose, and with simple rules filled with jargon, whose terms are easy to misinterpret. So the next time you're not quite sure what your customer means, ask for an example. It's the most effective technique to avoid building the wrong features.

Published in:

Software, IEEE  (Volume:24 ,  Issue: 4 )