What is a “Use Case”? How is Use Case Modeling used to manage software development projects?

The History of Use Case Modeling

A gentleman by the name of Ivar Jacobson invented what later has become known as Use Cases while working on telephony systems at Ericsson in the late 1960s. In the later 1980s, he introduced them to the OOP, or Object Oriented Programming, community. Within that community, Use Cases were instantly recognized as filling an important gap in the requirements process.

Alistair Cockburn (pronounced “Coburn”) constructed the Actors and Goals conceptual model while writing Use Case guides for the IBM Consulting Group in 1994, after studying under Ivar Jacobson in the early 1990s. Cockburn’s Actors and Goals conceptual model help to resolve much of the mystery of Use Cases and provided a guide on how to write and structure Use Cases. I was exposed to Jacobson and Cockburn’s Use Case modeling concepts while working as a consultant and business analyst for IBM in the 1990s. Cockburn’s IBM Consulting Group Actors and Goals conceptual model has circulated informally since 1995 at http://alistair.cockburn.us/ and later at http://www.usecases.org. The ideas finally were published in the Journal of Object Oriented Programming in 1997, in an article I read and loved written by Alistair Cockburn entitled “Structuring Use Cases with Goals“.

From the early 1990s through the end of the dotcom Boom around 1999, the ideas remained static, even though many in the OOP community still felt that there were some underlying loose ends in the theories behind Use Case Modeling. Alistair Cockburn, the originator of so many of the Use Case Modeling conceptual underpinnings, continued to teach and coach his Actors and Goals model, eventually gaining insights into why many in the OOP community were having such a hard time coming to grips with the ideas being presented. He finally released his new insights, complete with some of his resolutions to the unresolved questions forwarded to him regarding the Actors and Goals model, as the Stakeholders and Interests Model.

UML and Use Case Modeling: differences and coexistence

I personally, when introducing these concepts to a new Project Team, have often been asked, “What impact or overlap is there between the Use Case Modeling ideas and UML, or the Unified Modeling Language”?

A former colleague of Jacobson’s, Gunnar Overgaard, wrote most of the UML use case material and worked to preserve the heritage of Jacobson’s ideas. But it is well known within the OOP community that the UML standards group has within it a strong drawing-tools influence, which results in the loss of much of the textual, prose-based nature of Use Case Modeling.

Alistair Cockburn has written that he has met with both Gunnar Overgaard and Ivar Jacobson, and both assured him that Use Cases may fit within one of the UML ellipses,and hence the UML standard is agnostic when it comes to the Use Case Modeling ideas. The ideas forwarded by Alistair Cockburn are fully compatible with the UML 1.3 use case standard.

I think it is very important, however, to realize that if you only were to read the UML standard, which does not discuss the content or writing of a Use Case, you will not understand what a Use Case is or how to write or use it, and you will be led in the dangerous direction of thinking hat Use Cases are a graphical, as opposed to a textual, or prose, construct.

What is a “Use Case”, and how is Use Case Modeling used?

A Use Case is a fundamentally prose text description of a system’s behavior under various conditions. These conditions are primarily responses of the system to requests from one of the stakeholders of the system in question, usually referred to as a “Primary Actor”.

A Use Case represents a type of contract between the stakeholders of a system about the behavior of that system under these various conditions, or “States”. The Primary Actor initiates an action with the system in order to accomplish a task or achieve a goal. Myriad scenarios can unfold subsequently, and those scenarios depend upon the type of interactions or requests made by the Primary Actor and the conditions or states which accompany those requests. The use case succinctly codifies these various scenarios together into a presentable format.

Although use cases can take the form of flow charts, “Petri nets”, sequence charts or even programming languages, they are usually (and through general practice and agreement, best) presented in a prose text format. They are a way to communicate the intended behavior of a system (many times of course a software system) amongst members of a project team. It should not be necessary for project team members to have special training in order to interpret a well written use case. Use cases serve to encourage communication between project team members and also to stimulate discussion around contention points of a system’s intended behavior.

Some project teams may choose to document the requirements of a software system only through the use cases themselves. Other project teams may choose to have separate, traditional requirements documents. Many project teams may choose to provide both forms of documentation, use cases and requirements documents. I am of the school that use cases, requirements documents, and test cases form a triad that can help to unequivocally clarify the intended behavior of even the most complex software systems and also give the testing team the very best chance to perform their job with precision and efficiency.

The same basic rules of writing apply to all of the above listed approaches, even though different project teams will choose to write with unique levels of technical detail and completeness of description.

A well written use case should be easy to read and consists of sentences that are succinct and written in only one grammatical format, that being a simple action step. An action step is defined as an event in which one actor achieves a result or passes information or results to another system actor. An actor is defined as anyone or anything with behavior.

Reading a use case should not take more than a few minutes, although learning how to write a good use case is considerably harder. Three fundamental concepts apply to the writing of use cases, all three of which need to be mastered in order to become an effective use case writer:

1. Scope: What is the system being discussed, and what are the boundaries of the actions within that system to be described?
2. Primary Actor: Who is the user who hopes to achieve a goal through interaction with the system in question?
3. Level: Is the goal trying to be achieved by the Primary Actor primarily a high level goal or a low level goal?

The components of a use case consist of the following:

Stakeholder:  someone with an interest at stake in the proper behavior of the system under discussion.

Preconditions and Guarantees:  States or conditions that must be true both before and after the execution of the sequenced steps in the use case.

Main success scenario: A use case scenario in which no deviations from the expected behavior of the system are encountered.

Extensions:  Extensions describe alternate scenarios or states that can be encountered during the execution of a use case. Numbering convention used in the writing of a use case indicate to the reader points at which deviations from the main success scenario are possible. For example, steps 2a and 2b are indicative of twin conditions that can be arrived at by the primary actor during the execution of step 2.

How can Use Case Modeling assist Project Managers in managing complex software development projects?

Use cases provide a scaffolding construct that can be used by Project Managers or Program Managers to link many of the requirements details used on a modern software development project. Information contained within different parts of the software requirements definition (SRD) such as user profile information, data formating requirements, validations, and business rules can be cross linked and cross referenced through the utilization of Use Case Modeling.

In addition to this linking of requirements for a software development project, Use Cases and Use Case Modeling can help structure the project planning process by providing a framework upon which to hang information such as development status, release dates, teams, and priorities. The project team can employ Use Cases to track results, in particular the design of the User Interface components and system tests. It is for these benefits that many people seem to consider Use Cases as at the center or hub of a giant wheel of requirements consisting of spokes for performance requirements, UI requirements, UI design, business rules, data formats, input / output protocols, and performance requirements. Use Cases are often thought of in the OOP community as being the central element of the requirements or even the central element of the software development project’s development process.

At what points in a software development project do Use Cases add value?

Use Case modeling has garnered such a popular and ardent following within the OOP community precisely because Use Cases have the ability to tell coherent stories about how the System under discussion will behave in use. The end Users of the System get to see just what this new System will be and what functionality it will possess. They have the option to react early or fine tune or reject the User Stories implied in the Use Cases themselves (“You mean we’ll have to do what in order to cancel an Order?”). As important as this reason is to the widespread adoption of Use Case Modeling, this is only one of the ways in which Use Cases can contribute value to a software development project, and quite possibly not the most significant.

The very first moment during the course of a typical software development project that the Use Cases create value is upon the naming of these Use Cases as the User Goals that the System will support. These User Goals, in the form of the collected and named Use Case Catalog, form a list which announces what the System will do, revealing the scope of the System, its purpose. The list of named User Goals becomes a communication device between the different Stakeholders on the software development project.

The list of User Goals will be reviewed and debated upon by user representatives, software development engineers, executives, and project managers, who will use this list to estimate the cost and complexity of the System by using it as a guide to the functionality under construction. The list of User Goals will be used to negotiate which functions will be built first and how the teams are to be set up. The User Goal list is a framework upon which complexity, status, cost and timing metrics may be hung. It collects diverse and myriad project information over the course of the life of a software development project.

Why you should perservere through the writing of the Use Case failure conditions

The second instance where Use Case Modeling adds value during the course of a software development project is when the people or person writing the Use Cases brainstorm all the things that could go wrong in the MSS (Main Success Scenario). When the Use Case writers list out all the failure conditions, and how the System under discussion will handle these error or failure conditions, this is the point in the process where the Project Team is likely to uncover something surprising, maybe even something that nobody, including the Use Case writers themselves or the primary stakeholders, ever thought about as requirements.

The writing of the Use Case failure conditions is probably one of the most simultaneously frustrating and rewarding steps in the process of writing the Use Cases. I highly encourage everyone ever involved in writing of a catalog of Use Cases to hold out until this part of the process.  It is during the writing of the extensions, or failure conditions, that I regularly uncover a new User Goal, primary or secondary stakeholder, business rule or business process. Some of the most collaborative and productive design review sessions have resulted from discussions surrounding topics of how to handle these failure conditions. These design review sessions frequently end up involving a group of SMEs, or Subject Matter Experts, reviewing business processes or even questioning why it is things have been done a certain way inside a particular organization for so long. The process of trying to resolve what the System’s behavior should be during failure condition scenarios oftentimes is the process that generates the best requirements, even ex post facto to the formal discovery process.

If your Project Team skips over the writing of the Use Case failure conditions, then you will miss a valuable opportunity to catch many of the error conditions of the software application your Team is designing, leaving this vital Project task to a programmer who may discover them while typing a fragement of computer software code. This is far from the ideal juncture of your software development Project to be discovering new functions and business rules. If a lone programmer is left to his or her own devices in this type of scenario, with the business experts probably not around or gone home for the day, time pressure mounting, delivery schedules slipping, a programmer may be pressed, and understandably so, to just type whatever they think up at the moment instead of determining the correct functional behavior for the System they are programming, not necessarily designing.

I encourage Project Team to at least draw up one or two paragraph Use Case Briefs — for the very simple reason that Project Teams who write one-paragraph Use Cases save a lot of time by writing so little and already reap one of the major benefits of Use Cases. Project Teams who perservere through failure handling save mountains of time by finding subtle requirements early.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.