How can I get my users to read my use cases?

by Gary K. Evans

The simple answer is: make your use cases relevant to them, and they will have a motivation to read them.

Is it possible that the use cases are not well-written, and difficult to understand because the writer of the use case cannot write well? Is it possible that the use cases are really design specifications written not for users, but for developers?

No matter how correctly one presents a use case in proper format on a printed page, one must never forget that it is a written document targeted to one primary audience, but consumed by other constituencies as well.

First and foremost, you must be able to write well. Putting words and sentences on a page is not writing. An effective writer always identifies two criteria:

1. What is my topic that I will address?
2. Who is my primary audience?

The topic of your use case is the service, or business process, you will describe in the use case. How you identify these use case names depends on your project, and the requirements specification process you employ. The primary audience for whom you write a use case is your user community, or user surrogates: someone who may or may not be an actual user of an application, but is charged with the responsibility of representing the interests of that community. The surrogate does not have to have all the answers, but is willing to obtain the correct answers from the actual users. Each use case that you identify and write must conform to the "3 C's":

1. Clarity of expression.
2. Communication of intent, so you can obtain...
3. Consensus with your end users.

But there are audiences for the use case other than the end users. These are constituencies that consume the content of the use case in order to derive information that will enable them to better meet their responsibilities on the project. Some of these other consumers are:

1. Architects - who derive their architectural model from the behavior of the system described in the use cases.
2. Testers - who use the behavioral descriptions in the use cases to derive their test cases and test procedures.
3. Developers - who gain an understanding of the "big picture" of the system from the use cases, so they appreciate the value that the system should deliver to the end users.
4. Marketing - who consume the use cases to derive the major features provided, and the business justifications for the project.
5. Business Analysts - who validate that the use case conforms to the "3 C's", and that the use cases cover the major behavioral requirements of the end users.

Use cases should be targeted to your end users. They should be written clearly so that the value delivered by the use case is easily identifiable. And they should provide useful information needed by the other project constituencies. Use cases that meet these criteria will hopefully motivate your users to read them and interact with the business analyst to effectively scope and describe the needed system behavior.

Give your users what they need, not what you need, and you will find them to be a lot more interested in being active participants.

Visit our website for a more detailed version of the article above.

The Jazz of Agile

Before entering my computing career I spent several years on the road as a professional drummer in a show band. Although I started playing professionally late in high school, I quickly learned the critical difference between an amateur and a professional: you can tell an amateur by how much he throws into the music; you can tell a professional by how little she puts into the music to accomplish her goal. A professional will not play 3 notes if 2 will suffice, and why play 2 if one will do? And sometimes, what is not played at all - the silence - is the defining part of the music. In music, or on software projects, most of us start out as amateurs. Hopefully, we do not stay amateurs forever.

That musical analogy is usually how I start my answer when I am asked, “What is agile software process all about?” It’s about doing only what is appropriate to accomplish your software goals.

There is a recurrent perception in our industry suggests that agile means

• Not doing design
• Not writing documentation

• Not producing requirements specifications . . .

Agility cannot be defined by what you do not do. It is a highly disciplined approach to developing software quickly with only the appropriate overhead - playing only the necessary notes, if you will. It is a way of thinking about software development that demands more, not less, from each person on the project team. And like jazz, it gets better as the individuals learn to be an ensemble with a single mind, rather than a group of soloists positioning for center stage.

Moving to an agile method - whether extreme Programming, Scrum, or agile RUP - requires not only commitment, but also a good understanding of the mechanics of an agile project. Our Primer on Agile Process is a brief discussion of the iterative structure of agile process, and the major points of agile philosophy:

• Uncertainty and Risk
• Fear of Failure
• Predictability, and
• Process Variance

If your team is considering moving to an iterative or agile process, or you have made that move but you are not obtaining the benefits you expected, please contact us or call 803-781-7628. I would love to talk with you informally and with no obligations. If we can help you, I will share specifically what we could join together to accomplish; if I do not think we are the right ones to help, I will honestly tell you that, too.

Have a productive month,

    Gary K. Evans