A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the. An actor may be a class of users, roles users can play, or other systems. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance.

A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system.

Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.

Generally, use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain. This is engaging for users who can easily follow and validate the use cases, and the accessibility encourages users to be actively involved in defining the requirements.

A scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.). Scenarios maybe depicted using sequence diagrams.

 

 

 

UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UML Use Case Diagrams can be used to show all of its available functionality. It is important to note, though, that UML Use Case Diagrams are fundamentally different from sequence diagrams or flow charts. Because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed.

Incorrect use of Use Cases

UML Use Case Diagrams have only 4 major elements: The actors that the system you are describing interacts with, the system itself. The use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements.

You should use UML Use Case Diagrams to represent the functionality of your system from a top-down perspective that is, at a glance the system's functionality is obvious, but all descriptions are at a very high level. Further detail can later be added to the diagram to elucidate interesting points in the system's behavior.

Example: A Use Case Diagrams is well suited to the task of describing all of the things that can be done with a database system, by all of the people who might use it (administrators, developers, data entry personnel.)

You should NOT use UML Use Case Diagrams to represent exception behavior (when errors happen) or to try to illustrate the sequence of steps that must be performed in order to complete a task. Use Sequence diagrams to show these design features.

Example: A Use Case Diagrams would be poorly suited to describing the TCP/IP network protocol. Because there are many exception cases, branching behaviors, and conditional functionality (what happens when a packet is lost or late, what about when the connection dies?)

When working from an Action/Response table, identifying the actors is easy: entities whose behavior appears in the "Actor's Actions" column are the actors, and entities whose behavior appears in the "System's Response" column are components in the system.

If you are working from an informal narrative, a sequence diagram, or a scenario description, the actors are typically those entities whose behavior cannot control or change (i.e., agents that are not part of the system that you are building or describing).

The most obvious candidates for actors are the humans in the system; except in rare cases when the system you are describing is actually a human process (such as a specific method of dealing with customers that employees should follow). The humans that you must interact with will all be actors. If your system interacts with other systems (databases, servers maintained by other people, legacy systems) you will be best to treat these as actors, also, since it is not their behavior that you are interested in describing.

Example: When adding a new database system to manage a company's finances, your system will probably have to interface with their existing inventory management software. Since you did not write this software, don't intend to replace it, and only use the services that it provides, it makes sense for that system to be an actor.

Remember that a typical UML Use Case description will be composed of many diagrams and sub-diagrams), and should contain use case ovals. One for each top-level service that your system provides to its actors. Any kind of internal behavior that your system may have that is only used by other parts of the system should not appear in the system box. One useful way to think of these top-level services is as follows:

If a use case represents a top-level service, then it should make sense for the actors who interact with it to request only that service of your system in a single session. In whatever sense a "session" is intelligible in your system.

Killing A Project With Use Cases

There are many ways to help kill a project with use cases. A few are list here:

• Expecting use cases to capture all your requirements.
  (They don't; they just capture functional requirements and enforce business rules.)

• Emphasizing notation over business goals and content.
  (The use case diagram is like a Table of Contents; it is not the book itself.)

• Designing inside use cases.
  (Use cases are not part of the design process and should not discuss technology issues; use cases are a way to capture the requirements so you can then do analysis and design.)

• Coding from Use Cases.
  (They are not part of the design process; they are a way to capture the requirements so you can do analysis and design and then implementation.)

• Trying to use all the defined notations just because they are defined.
  (Just because UML introduces generalization between use cases, are you going to look for ways to use it?)

• Identifying system functions as use cases.
  (Yes, system functions e.g., "validate Name", are important; but a use case describes a business process and business goal, and the system functions which will be used to achieve that goal will be determined in design, not requirements capture.)

If you have been involved with use cases on a project of any size at all, you may have experienced some of these symptoms. But we want to be more upbeat and take a positive approach. So let's talk about what you can do right to raise your chances of success with use cases.

The Right Stuff

To capture requirements successfully with use cases, you must not confuse use cases with code, or design, or any other part of the software development lifecycle. To succeed with use cases it has been found that how you think about the process of capturing requirements is even more important than what you do in that process.

Staff For Skill sets, Not Job Positions

The project need people who have the right skill sets, not just people who are "available". To do use cases successfully you need:

• Subject Matter Experts and

• Business Analysts

These are resources who provide raw material for the business content of the use case description. They are the ones who absolutely should understand the business as-is, but much more importantly, are willing to define the system to-be.

The Business analysts facilitate the use case development, it is the Business analysts who analyze and write the use cases period.

The Business analysts must be able to think abstractly and have a high tolerance for incompleteness. The Business analysts need to thoroughly understand the process and goals of use case development. They also must be comfortable with intentionally circumventing the process so they can achieve the goal of developing use cases.

Do not Let Developers Write Use Cases!

By "developer" it means a person who is a linear thinker: one who starts at point A, and proceeds one by one through intermediate steps to arrive at point Z. The linear thinker cannot comfortably jump around within the use case description process. Some persons are linear thinkers by nature. They were born with this skill and others are trained that way.

Some persons adopt a strongly linear approach to solving a problem if they are uncomfortable with the solution process, so they fall into doing the rote mechanics. Some don't understand the goal to be achieved. They do not have a vision of the end result and become retentive about rigidly following a prescribed set of steps because they mistake making the journey for reaching the goal. However they come to this unique skill, linear thinkers are invariably uncomfortable when there are holes in what they are doing.

Use cases are text: i.e., prose. They are not derived like theorems—they are composed. This is why linear thinking is a decided liability in use case development. Writing a use case has nothing in common with writing code or writing a Fault Isolation manual for a Field Engineer. A use case is closer in style to writing a short story than writing a technical specification, and for this reason linear thinking developers will not be successful at writing them.

Use cases often grow in fits and starts, almost organically until they express their goal. They are not technical documents, so don't let your technical people be the ones to write them. Various instances of "The World's Worst Use Case" float around the OO community: some of them are textual flowcharts, some are pseudo-code replete with IF…ENDIF statements. This is not how to succeed with use cases.

Now, realistically, some very technical people are also very good at written expression, and some business people cannot speak in complete sentences. To succeed with use cases they must be written well, by people who have the skills to accurately express the interplay between the system and its actors.

In use case development our total focus is on what work the system must do for the user, not how the work will be done. The bottom line: choose your use case writers very, very wisely. They are not technical documents, so why would you have technical thinkers doing them?

Think High-Level…Business Level

Bad use cases describe isolated system functions that seem useful from a technical perspective. A good use case represents an identifiable business transaction that has business value from the end-user’s perspective. In other words, a use case must provide a meaningful result of measurable value to the end-user. Use cases that only deal with a low-level, elementary process (e.g., Retrieve Reservation or Update Reservation) are likely to be too simple. And are invariably modeled on the technical CRUD- functions of a relational database management system: Create, Retrieve, Update and Delete.

Typically a use case will include the series of steps the actor must go through and require significant business policies and rules to implement. But a good use case does not itself describe design, performance, or implementation issues. A good use case does not describe the relationships between subsystems. A good use case does describe how the system to-be carries out the work that the actor needs done to accomplish his/her business goals.

Follow a Process—Loosely

Use case development is not like building a model airplane: just putting known pieces into the proper place. It is a discovery process. It is a process of defining that which does not yet exist, and which may not yet be understood. often a project team have read books on use cases, have selected use case description templates, and have written perhaps dozens of use cases—yet do not understand any of the dynamics of the process for developing the use case descriptions. Some will have taken expensive courses on Requirements Gathering with Use Cases, or some similar title in which they learn about <<include>>, <<extend>> and generalization relationships. But they don't understand how to "compose" a use case.

The basic use case description process is rather simple. For each candidate use case in your system-to-be:

1. First, articulate the goal of the use case.
2. Second, produce an outline use case description focusing on the "Happy Path". The "happy path" is that sequence of steps where everything works perfectly (so we don't have to worry about exceptions and errors yet) and the goal of the use case is achieved.
3. Next, construct a simple use case description framework to think about the happy path. This framework lets us write an accurate, but non-detailed, use case description. At this point our description is analogous to a pen and ink drawing: it conveys the overall form and structure of the use case but without any "color" yet.
4. Fourth, flesh-out the use case description framework with more business-process detail for the happy path (but not technology detail!). This is equivalent to filling-in our pen and ink drawing with oil colors. Now our use case description has depth and personality.

What is not simple is that although this use case description process is written as a time-sequence of steps, you do not want to be linear here—especially within steps 3 and 4. Detail does not flow in an orderly fashion from top to bottom. This is a dynamic detective and discovery process, and the single most unique characteristic of developing use case descriptions is that your approach must be opportunistic rather than deterministic, lateral rather than linear.

We hunt and scrounge for any piece of relevant information and do not care whether we find it in the "right order". A deterministic thinker wants to build a jigsaw puzzle from top left to bottom right. An opportunistic thinker will look for patterns and first will put together small groups of pieces and then will build the puzzle from these groupings in what seems a haphazard fashion. (It is also interesting that the opportunistic approach will complete the puzzle sooner than the deterministic approach).

It is this pseudo-random, opportunistic approach that is absolutely central to developing use cases successfully. It is a pseudo-random approach because an experienced use case facilitator will always have an appreciation for what remains to be done, and knows just what he or she wants from the use case under development. It is also an approach that drives linear thinkers over the brink, and makes them dig in their heels, trying to bring "order" to the process. Alas, it is this "order" which too often results in missed and misunderstood requirements.