Use Case

A Use Case is a technique for capturing functional requirements of system. Each Use case Provides one or more scenarios that convey how the system should interact with the users called actors.

Advantages:
1. Use Cases are traceable.
2. Use Cases are reusable within the project.
3. Use Cases can serve as the basis for the estimating, Scheduling, and validating effort.

In software engineering and system engineering, a use case is a technique for capturing functional requirements of systems and systems-of-systems. According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful" ^[1]. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by business analysts and end users. Use cases are separate and distinct from use case diagrams, which allow one to abstractly work with groups of use cases.

Within system engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms.

A use case should:

• describe how the system shall be used by an actor to achieve a particular goal.
• have no implementation-specific language.
• be at the appropriate level of detail.
• Not include detail regarding user interfaces and screens. This is done in user-interface design.

Use case templates

There is no standard template for documenting detailed use cases. There are a number of competing schemes, and individuals are encouraged to use templates that work for them or the project they are on. Standardization within each project is more important than the detail of a specific template. There is, however, considerable agreement about the core sections; beneath differing terminologies and orderings there is an underlying similarity between most use cases.

Typical sections include:

• Use Case Name
• Iteration
• Summary
• Preconditions
• Triggers
• Basic course of events
• Alternative paths
• Postconditions
• Business rules
• Notes
• Author and date

Different templates often have additional sections, e.g., assumptions, exceptions, recommendations, technical requirements. There may also be industry specific sections.

[edit] Use case name

The use case name provides a unique identifier for the use case. It should be written in verb-noun format (e.g., Borrow Books, Withdraw Cash), should describe a completable goal (e.g., Register User is better than Registering User) and should be sufficient for the end user to understand what the use case is about.

Goal-driven use case analysis will name the use cases according to the Actor's goals thus ensuring use cases are strongly user centric. Two to three words is the optimum length. If more than four words are proposed for the name, there is usually a shorter more specific name that could be used.

[edit] Iteration

Often an iteration section is needed to inform the reader of the stage a use case has reached. The initial use case developed for business analysis and scoping may well be very different from the evolved version of that use case when the software is being developed. Older versions of the use case may still be current documents, because they may be valuable to different user groups.

[edit] Summary

The summary section is used to capture the essence of the use case before the main body is complete. It provides a quick overview which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

[edit] Preconditions

A preconditions section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case. Where one or more preconditions are not met, the behavior of the use case should be considered indeterminate.

[edit] Triggers

The Triggers section describes the starting condition(s) which cause a use case to be initiated. This can be external, temporal or internal.

[edit] Basic course of events

At a minimum, each use case should convey a primary scenario, or the typical course of events. The main basic course of events is often conveyed as a set of usually numbered steps, for example:

1. The system prompts the user to log on.
2. The user enters his name and password.
3. The system verifies the login information.
4. The system logs user on to system.

...and so on.

[edit] Alternative paths

Use cases may contain secondary paths, or alternative scenarios which are variations on the main theme. Exceptions, or what happens when things go wrong, may also be described, either within the alternative paths section or in a section on their own. The alternative paths make use of the numbering of the basic course of events to show at which point they differ from the basic scenario, and if appropriate where they rejoin. The intention is to avoid repeating information unnecessarily.

An example of an alternative path would be:

1. The system recognizes cookie on users machine.
2. Go to step 4 (Main path)

An example of an exception path would be:

3. The system does not recognize user's logon information

4. Go to step 1 (Main path)

According to Anthony J H Simons and Ian Graham, alternate paths were not originally part of use cases. Instead, each use case represented a single user's interaction with the system. Or in other words, each use case represented one possible path through the system. Multiple use cases would be needed before designs based on them could be made. In this sense, use cases are for exploration, not documentation.

[edit] Postconditions

The post-conditions section summarizes the state of affairs after the scenario is complete.

[edit] Business rules

Business rules are written or unwritten rules that determine how an organization conducts its business with regard to a use case. Business rules are a special kind of assumption. Business rules may be specific to a use case or apply across all the use cases, or across the entire business.

[edit] Notes

Experience has shown that whatever template is used, analysts discover there is always important information that doesn't fit the structure of the template. Therefore each template usually includes a section for such seemingly inevitable information.

[edit] Author and date

This section should list when this version of the use case was created and who documented it. It should also list and date any versions of the use case from an earlier stage in the development which are still current documents. The author is traditionally listed at the bottom, because it is not considered to be essential information; use cases are intended to be collaborative endeavors and they should be jointly owned.

Use case diagrams depict:

• Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
• Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
• Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use.
• System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system. Figure 2 shows how this could be done.
• Packages (optional). Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams. I use packages only when my diagrams become unwieldy, which generally implies they cannot be printed on a single page, to organize a large diagram into smaller ones. Figure 3 depicts how Figure 1 could be reorganized with packages.

In the example depicted in Figure 1 students are enrolling in courses with the potential help of registrars. Professors input the marks students earn on assignments and registrars authorize the distribution of transcripts (report cards) to students. Note how for some use cases there is more than one actor involved. Moreover, note how some associations have arrowheads¾any given use case association will have a zero or one arrowhead. The association between Student and Enroll in Seminar (in the version shown in Figure 4) indicates this use case is initially invoked by a student and not by a registrar (the Registrar actor is also involved with this use case). Understanding that associations don’t represent flows of information is important; they merely indicate an actor is somehow involved with a use case. Information is flowing back and forth between the actor and the use case, for example, students would need to indicate which seminars they want to enroll in and the system would need to indicate to the students whether they have been enrolled. However, use case diagrams don’t model this sort of information. Information flow can be modeled using UML activity diagrams. The line between the Enroll in Seminar use case and the Registrar actor has no arrowhead, indicating it is not clear how the interaction between the system and registrars start. Perhaps a registrar may notice a student needs help and offers assistance, whereas other times, the student may request help from the registrar, important information that would be documented in the description of the use case. Actors are always involved with at least one use case and are always drawn on the outside edges of a use case diagram.

Figure 1. System use case diagram.

Figure 2. Using System boundary boxes to indicate releases.

Figure 3. Applying packages to simplify use case diagrams.

Creating Use Case Diagrams

I like to start by identifying as many actors as possible. You should ask how the actors interact with the system to identify an initial set of use cases. Then, on the diagram, you connect the actors with the use cases with which they are involved. If an actor supplies information, initiates the use case, or receives any information as a result of the use case, then there should be an association between them. I generally don’t include arrowheads on the association lines because my experience is that people confuse them for indications of information flow, not initial invocation. As I begin to notice similarities between use cases, or between actors, I start modeling the appropriate relationships between them (see the Reuse Opportunities section).

The preceding paragraph describes my general use case modeling style, an “actors first” approach. Others like to start by identifying one actor and the use cases that they’re involved with first and then evolve the model from there. Both approaches work. The important point is that different people take different approaches so you need to be flexible when you’re following AM’s practice of Model With Others.

Reuse Opportunities

Figure 4 shows the three types of relationships between use cases -- extends, includes, and inheritance -- as well as inheritance between actors. I like to think of extend relationships as the equivalent of a "hardware interrupt" because you don't know when or if the extending use case will be invoked (perhaps a better way to look at this is extending use cases are conditional). Include relationships as the equivalent of a procedure call. Inheritance is applied in the same way as you would on UML class diagrams -- to model specialization of use cases or actors in this case. The essay Reuse in Use Case Models describes these relationships in greater detail.

Figure 4. Use case reuse.

Remaining Agile

So how can you keep use case modeling agile? First, focus on keeping it as simple as possible. Use simple, flexible tools to model with. I’ll typically create use case diagrams on a whiteboard, as you see in Figure 5 which is an example of an initial diagram that I would draw with my project stakeholders. AM tells us that Content is More Important Than Representation so it isn’t a big issue that the diagram is hand drawn, it’s just barely good enough and that’s all that we need. It’s also perfectly okay that the diagram isn’t complete, there’s clearly more to a university than what is depicted, because we can always modify the diagram as we need to.

Figure 5. Whiteboard sketch.

In parallel to creating the sketch I would also write a very brief description of each use case, often on a whiteboard as well. The goal is to record just enough information about the use case so that we understand what it is all about. If we need more details we can always add them later either as an essential/business use case or a system use case.