How Do I Motivate My Users to Read My Use Cases?

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

Is it possible that your use cases are too detailed? That is, are they really design specifications written not for your users, but for developers?

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?

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, when you write a use case you must regard yourself as a writer. You must be able to write well. If you cannot write at all, you will not be able to write a use case. 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?

As a use case writer you should know the answers to these questions before you write the use case, and be able to articulate them at a moment’s notice.

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 audience for a use case is strangely confused on many projects. The primary audience for whom you write a use case is your user community. On your project the user community may be real users who have been enlisted to provide features and requirements, or it may be a user surrogate: 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. (Warning: if your user community is represented by managers of the actual users, you are in a very precarious situation: the managers wield political power, but will invariably suggest software behavior that may make perfect sense to that manager, but often does not correspond to what an actual user would request.)

Each use case that you identify and write must conform to what I call the “3 C’s”:                                   

1. Clarity of expression.  The use case must be well-written, targeted to the understanding of the primary audience of users, and should serve the information needs of the other audiences who consume the use case for their own needs on the project ― e.g. architects who inform their architectural constructs from the behavioral descriptions in the use case.
2. Communication of intent. The use case must clearly communicate the purpose and goal of the process it is describing. What is the business value provided by this process? What is the value delivered to the primary actor of the use case? If the use case does not communicate the intent of this process, then how can anyone confidently approve submitting the use case into the development process? Alistair Cockburn says: when you read a well-written use case, you don’t see a “use case”, you see your business. That is what we should always seek in our use case descriptions. If your end users say your use cases are too technical, then listen to them and have someone else write the use cases.
3. Consensus with your end users.  The whole purpose of writing use cases is to have them validated by their primary audience ― the end users― so we can confidently write code that delivers to those end users the promise of the use case. If our end users do not agree with what a use case describes, then the use case is wrong, period. It is irrelevant that the developers, architects and technical management think the use case is perfect. If the end users have not blessed the use case, you cannot move forward.

But there are audiences for the use case other than the end users. The use case is not written for the approval of these other groups as they are for 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 that are targeted to the end users, that are written clearly so that the value delivered by the use case is easily identifiable, that provide the 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.

But, of course, there is another reason your users may not be reading them, and not giving you feedback. It may simply be they do not want to get involved, or be held accountable on the project. Writing great use cases will not solve this problem, and how you might remedy this problem requires a different set of solutions outside the scope of this article.