Not Listening to the User | UML 2 For Dummies

Many of the modeling mistakes we see are traceable to someone’s poor listening skills. Rather than listen to what a user needs from a software application, some developers are too busy thinking about how they are going to write their next program. These developers dream up terminology like QualifiedEditableAccount, Tuple, and Xref. In the end, the software does not meet the needs of the user. That’s partly because those arcane terms aren’t much help when the original developers are no longer on the project. When users ask for a better system, the new developers get completely confused because they can’t relate what the user is saying to anything in the program code.

Tip Users provide you with a wealth of information for your software application. Here’s a strategy for making the best use of it:

Listen to your users carefully.
Convert the users’ terminology into classes.

For example, in the insurance domain, define Policy, Customer, Vehicle, Coverage, and Claim.
Convert the users’ required interactions with your software into use cases and sequence diagrams.

Capture what it means to the user to “generate a policy,” “handle a claim,” and “bind a policy.”
Design your system and write the code based on what the user told you.

For example, implement a Policy class that uses the same terminology as that of your users.
Listen to the user after you deliver the software.

Now, when the user talks about changing something related to an insurance policy, you know right where to go in your design the make changes. You will not be hunting down Tuple and Xref to see whether that’s where to change your code.

Tip Recently, while serving on a “panel of experts” at a conference, one of your authors (Jim, in fact) was asked, “How can you tell a good modeler when you see one?” His response was, “The best modelers are the ones who really listen.”