From Research to Implementation: Use Case Diagrams – Usage and Benefits


Use Case DiagramSome people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still linger in the minds of many Business Analysts, such as:

  • Who is really using them?

  • What kind of projects are they being used on?

  • Why are people not using them?

  • How are people using them?

  • Are they providing any benefit?

Recent research can help Business Analysts answer these questions and provide recommendations for implementation.

The Who, What, Why and How of Use Case Diagrams [1]

The first research paper helps us answer the Who, What, Why, and How questions relating to the actual implementation of Use Case diagrams in the field. This study was conducted by the authors with full support of the Object Management Group (OMG). The authors created a web survey composed of 38 questions designed to inquire about UML usage, including Use Case diagrams. A total of 284 meaningful responses to the survey were collected and analyzed. The first meaningful piece of data to come out of this study indicated that 182 respondents utilize UML while 102 provided reasons why they were not using UML.

Who is really using Use Case diagrams?

The average practitioner has 15.1 years of IT experience, but they only have 4.7 years of UML experience. It is interesting to note that UML has been around for more that 12 years, but many experienced individuals still have a considerably low amount of time working on projects with UML. It is not really clear why there is such a low level of experience as the data showed no correlation between number of years of experience and UML diagram usage.

What kind of projects are Use Case Diagrams being used on?

Figure 1 shows us that UML diagrams are being used on non-trivial projects. Note that the average number of Use Cases per project is 88. This is a lot of information to convey, and it would seem beneficial to provide a Use Case Model that contains Use Case diagrams to help describe the behavior of a system this size. In addition, tools today provide the ability to map traceability between Use Cases and Classes to ensure the solution delivered is meeting the end goals of the user. Furthermore, as requirements change (as they often do), being able to know how many classes are affected by a change to a Use Case can provide invaluable information that relates directly to cost, scope and project planning.

Figure 1: Typical Project Size

Why are people not using Use Case diagrams?

Figure 2 shows the reasons given by respondents for not using Use Case diagrams (respondents were allowed to choose more than one answer, so total % is greater than 100). Looking at this data, there are a few areas that can be addressed easily and cheaply to alleviate the roadblock to Use Case diagram implementation.

  1. Not well understood by analyst – This is easily solved with training or mentoring.

  2. Insufficient value to justify cost – There is very little cost to creating Use Case diagrams when using commonly available corporate tools such as Microsoft Visio which adds no additional cost in tools. In addition, recent research has shown that Use Case diagrams do provide cognitive benefits (see next study, below).

  3. Not useful with programmers – This, again, is easily solved with training or mentoring. In addition, Use Case diagrams provide the abstract view of system behavior which is the end goal of the programmers efforts.

Figure 2: Reasons for not using Use Case diagrams (% responses)

How are people using Use Case Diagrams?

The researchers asked the respondents to provide a rank (on a scale from 1-5) showing how they were using Use Case diagrams (and other UML diagrams) on projects. A review of Figure 3 shows some interesting numbers.

As would be expected, Client Validation has the highest score. However, it seems that the 2.90 score for Document for future maintenance and other enhancements is low. It appears that practitioners are not taking into account that enhancements, in particular, are not always performed by the personnel that originally created the system. Use Case diagrams are extremely useful in providing personnel, not familiar with the original system, a business context to understand. This may be a consequence of the diagram not being well understood by analysts.

The measures for Implement and Clarify, as defined, are expected as Use Case diagrams are not designed to provide detailed implementation detail for technical members of the project team.

Figure 3: Roles for Use Case Diagrams

Benefits of Use Case Diagrams [2]

Measuring the actual benefits of Use Case diagrams has only recently attracted the attention of researchers. As indicated above in Figure 2, 42% of respondents in the previous study indicated that there was “Insufficient value to justify cost, and a further 29% indicated that Use Case diagrams were “Not useful with clients”. Research published this year, however, shows that Use Case diagrams actually aid in the understanding of the use case narrative.

In this study, the researchers identify a process, Conceptual Modeling, that involves the analyst working with stakeholders to identify the initial ideas of the system, model those ideas, and use that Conceptual Model to have the stakeholders validate the requirements. Since Conceptual Modeling techniques often combine words with graphical symbols, the researchers applied the Cognitive Theory of Multimedia Learning (CTML). The CTML “suggests the most effective communication occurs when verbal and visual pathways are utilized simultaneously.”

49 upper-level business students, with no particular knowledge of object-oriented principles or UML, were randomly assigned to two groups. Each group was presented with a pre-test, five use cases (only one group included a Use Case diagram), tasks (measuring comprehension, retention and problem solving), and a post-test.

Retention and Problem solving measures increased by 22% and 20%, respectively, for the group that included a Use Case Diagram. The overall comprehension measure was unaffected. According to the authors: “These results suggest that diagrams, even simple diagrams such as the use case diagram provided in this experiment, can have measurable effects on viewer understanding.” Utilizing the CTML, he authors proposed, and subsequently showed, that by utilizing both visual and textual information, the reader is able to increase understanding of the system domain being designed.

Recommendations for Implementation

The first recommendation comes directly out of Figure 2 above. Companies need to provide adequate training and mentoring to both Business Analysts and Programmers to understand Use Case diagrams and UML in general. As the second study points out, Use Case diagrams increase learning performance when trying to understand Use Cases.

The second recommendation is to include Use Case Diagrams with every Use Case narrative or scenario. Regardless of the simplicity of the diagram, including a Use Case diagram can certainly not hurt the project and will, most likely, increase everyone's understanding of the system domain.


  1. Dimensions of UML Diagram Use:A Survey of Practitioners, Journal of Database Management, 19(1), 1-18, January-March 2008

  2. Use Case Diagrams in Support of Use Case Modeling: Deriving Understanding from the Picture, Journal of Database Management, 20(1), 1-24, January-March 2009

Author: Mr. Botz is a working Business Analyst and operates Prime Proficiency, a company specializing in Business Analyst training.

His research and writing focuses on turning recent, relevant research into implementable actions. You can see more of his Business Analyst writings at He can be reached at

Like this article:
  19 members liked this article


ajmarkos posted on Tuesday, January 5, 2010 8:29 AM
Mr Botz:

Informative article, but more focus on the problems with use cases is needed, such athe problem with brute force partitioning, the need for a lithmus test of completedness - to name just a couple.

Tony Markos

bbotz posted on Tuesday, January 5, 2010 11:17 AM

Thanks for the comment. As a tool, use case diagrams definitely have their strengths and weaknesses. There are some additional studies that attempt to address the deeper issues, and most academics suggest the need for further research in this area.

neagust posted on Wednesday, January 6, 2010 1:53 PM
Couple of comments from experience to add to the point in the article.

UC Diagrams proved to be a good tool in the early stages of the design phase during the brainstorming sessions where they helped convey the actors, messages, functions, states of objects and their everyone in the room and invite them to collaborate on the diagrams.

Very useful in documenting both the business and system context, while handing off to another team and when making changes to the existing design.

As a variety of different types of diagrams exist, most non-trivial project require at least several different types of diagrams to show the full context of changes.

Not really sure about the survey results, but most of developers I worked with welcome the diagrams and like to use them to facilitate the communication between the them and the analysist.
zarfman posted on Wednesday, January 13, 2010 12:01 AM


Would UML and Use Case diagrams be useful in implementing the changes required by
FASB 133.

FASB 133 amends FASB Statement No. 52, Foreign Currency Translation, to permit special accounting for a hedge of a foreign currency forecasted transaction with a derivative. It supersedes FASB Statements No. 80, Accounting for Futures Contracts, No. 105, Disclosure of Information about Financial Instruments with Off-Balance-Sheet Risk and Financial Instruments with Concentrations of Credit Risk, and No. 119, Disclosure about Derivative Financial Instruments and Fair Value of Financial Instruments. It amends FASB Statement No. 107, Disclosures about Fair Value of Financial Instruments, to include in Statement 107 the disclosure provisions about concentrations of credit risk from Statement 105.

Regards, a beat up old accounting dude.

bbotz posted on Wednesday, January 13, 2010 3:54 PM

I believe they could be useful in describing an implementation of FASB 133. In fact, I think it could help simplify something that may be much more complex in text-only form.

marcthibault posted on Friday, January 15, 2010 1:23 PM
The thing is, the use cases are there--whether they're documented or not. It's a good idea to document them since anything that's not ultimately visible to an actor need not be built; no one will ever know it's missing.

Use cases aren't just another way of doing a functional specification; they're part of the essential analysis. You have a choice: you can describe the use cases directly or you can circle around them with functional specs and business rules and hope that somewhere in that mess the developers will find what they need to know.

In my sector, the biggest problem is that, all too often, use case terminology and templates are being misused to do functional specs (one clue is system use cases with no external actor, another is postconditions). Then the stakeholders complain about the additional effort with little additional benefit. The number of times I've seen these cargo cult use cases is appalling. The repair work, on the other hand, is good for billable hours.

gbcambridge posted on Thursday, January 28, 2010 4:31 AM
Use Cases, IMHO, need to distinguish between System Use Cases and Business Use Cases, with the latter functioning as the owner/container of ALL of the System Use Cases.
Now, specifically, the subject is the Use Case Diagram. The diagram is helpful for evolution of business and system requirements, but not so useful for analytical work... it is diffiicult to analyse, hard / tedious to scale up and quite verbose. We have often replaced the Use Case diagram with a table showing the interactions between Actors and Use Cases. This is very concise and makes management of large numbers of UCs very easy. For some audiences it is not so helpful, so we tend to use it as a summary of what we have understood from the evolution of the UC Diagrams. The UC/Actor matrix replaces the UC diagram for analytical work and drives the development of the project
marcthibault posted on Thursday, January 28, 2010 8:57 AM
gbcambridge: I have to beg to differ.

The distinction between business UC and system UC is too important to waste on an arbitrary hierarchy. Some business UCs (eg a client or supplier interacts with the business) are supported by system UCs; an association that needs to be documented, keeping in mind that it's usually a many to many association.

Some system UCs have only internal actors and are unrelated to business UCs except in the general sense that internal processes ultimately serve business UCs. Those connections are too tenuous to deserve much attention. There is no business UC associated with the "prepare special paycheck" system UC. Not everything "useful" is a UC.

The only Business UC that owns ALL the system UCs is "Shareholder collects dividend".

For the developer, system UCs are his marching orders, business UCs are useful background information.

If you're having a problem working with UCs, someone is giving you lousy UCs. The purpose of a UC is to simplify, not complicate. A high-level diagram showing many interactions between actors and use cases is called a use case navigation diagram and it's a standard part of the presentation.

Use cases must first be usable; any use case that has so many different kinds of actors that it needs a matrix is definitely a lousy use case, or you're putting people's names on the actors, or you haven't discovered inheritance. In general, a use case will have one actor--rarely two or three. If you aren't seeing this you have a serious problem in use case definition.

There's more at

gbcambridge posted on Thursday, January 28, 2010 9:27 AM
marcthibault: I guess I have to differ too :-)

Assuming that we have a shared understanding of a Business Use Case as opposed to a System Use Case, then we need to look at a System Use Case when exceptions can occur. Generally an exception can occur at any and every step of a Use Case, as each step is some operation / transaction. When such exceptions occur they are normally handled by the invoking / containing Business Use Case, because the recovery will often involve a manual business process, such as reset, etc. In embedded systems and the like, this simple hierarchy may be less visible but ultimately is still there in the "turn it off and turn it on again" recovery strategy. So, exceptions with "Prepare special paycheck" may require manual intervention, which should be documented as part of a business process. Consequently I think the BUC is rather more than "useful background information" to the developer. It needs to be (demonstrably) able to handle whatever a SUC throws at it. Failure to do this leads to operators not knowing how to deal with unexpected messages appearing on screens.

Hence, although SUCs are the "marching orders" for the developer, they must fit into the surrounding business Process so as to deal properly with exceptions.

When I mentioned the use of a table in my previous comment, I was refrring specifically to Use Case Diagrams, not Use Cases. A Use Case Diagram may be an aid to navigation, but as far as I know "navigation" is not part of its title. See
When the Use Case Diagram (not the Use Case) refers to many Actors and Use Cases, which is not unusual, a matrix view gives a concise expression. A matrix together with State Diagram would give legal as well as possible navigation paths.

The only tables which I find useful to provide within Use Cases themselves are Decision Tables to allow expression of Business Rules (when the clients are comfortable with this approach) and State Diagrams to explain context. With Decision Tables a large part of the logic of the UC can be automated.

Some clients have indeed dropped the diagrams which form part of the standard Use Case description. Generally I have recommended against this but for the simpler cases I don't have a problem with this decision. Personally I am very happy with UC-driven development, it is a simple and pretty reliable method for certain types of application. Try a Use Case Diagram for a Chess-playing program and see how far the technique goes :-)
marcthibault posted on Thursday, January 28, 2010 10:36 AM
We'll have to agree to disagree. I can't bring myself to throw the use case mantle over everything that moves.

In particular, I find things get very confusing if "business process" is conflated with "business use case". I find it aids in clarity of understanding to keep them separated in the same way as we keep "x=6**y" separate from the system use case it may be helping to realize.

"Prepare special paycheck" in the example is a system use case complete with actor; manual intervention is how it got enacted in the first place. The exception is in the business process leading up to it. Use cases are defined from the outside looking in.

In my lexicon (which, admittedly, may be ideosyncratic) business use cases are realized by business processes, which may be aided by system use cases, which in turn are realized by system processes (code execution). Clear and simple.

A phrase like "THE use case diagram" is scary. Every project I've been on has needed many use case diagrams and other diagrams to provide enough different views of the desired product that no one can possibly misunderstand what needs to be built; the use case, as a unit of development, is where it all comes together. Use cases are one of the tools we use to make sure the developers are fully informed of the results needed. It's my job as an analyst to pull that off; muddying the water by failing to distinguish between use and process is a sure path to failure.

The use case is the one way to achieve the actor's goal; the process is one of the many ways to realize the use case. It's much like the distinction between strategy and tactics.

Only registered users may post comments.

Latest Articles

The Goal Is to Solve the Problem
Oct 15, 2017
A requirement is “a condition or capability needed by a user to solve a problem or to achieve an objective” (AKA a goal). Thinking in term...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC