Use Cases - Overview

Use Cases cause a lot of confusion for many people new to UML and SysML.  The OMG UML Infrastructure specification calls Use Cases "a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do." (OMG Unified Modeling Language (OMG UML) Superstructure, V2.1.2, p. 585).  This definition seems a bit academic, so let me try to bring some practical world experience.

Let's be clear:  Use Cases ARE requirements.  They provide much more than simple shall statements, however.  From a Systems Engineering perspective, think of about the problem space this way: a Request for Proposal or Statement of Work provides the requirements for any competitor's solution, but your Use Cases explain your organization's specific solution.  They list the capabilities of the system.  You will use the descriptions to allocate functionality to different parts of the system.  Taken together, the Use Cases described your proposal.  Each of the functional shall statement requirements should trace from a Use Case.


Since Use Cases detail the system requirements, they tell what the system will do, not how the system will do it. Use Cases do not show functional decomposition, nor do they specify how to write the code.

Another confusing aspect of use cases are the relationships « extends » and « includes » .  I am not going to spend much time describing these here because it is an academic argument.   Whether you show a capability as « extends » or « includes » is almost irrelevant.  Either way, you will need to detail the additional Use Case.  Therefore, I only use « includes » ; and then I only use it when multiple Use Cases require the exact same capability.


A Use Case's meat exists in its description.  The description shows, step by step, what the system does to implement a capability.  It shows the response to external stimuli (Actors).  As important, a Use Case description shows the exception conditions when the normal flow of events does not happen.  These discussions of exception handling show the real power of Use Cases.  They force the engineers, both Systems and Software, to think about the exception conditions up front.


In the next two sections, we will discuss different methods for detailing Use Cases.  The first method uses text.  The second uses and Activity Diagram.