One of the biggest problems in delivering a website, and yet probably the least talked and written about, is how to decide, specify, and communicate just what, exactly, is it that we’re going to build, and why. What problem are we solving? Who needs it? What’s this site for, anyway?

Poor understanding of target user needs or our client’s vision, ineffective use of limited resources, misguided emphasis on the wrong design priorities, over-emphasis on pet technologies — all will contribute to a failed, late, inappropriate or too-expensive website. Experience can teach us how to avoid pitfalls, but the greatest lesson can be learned by the least experienced: the earlier that purpose and goals are clearly defined and recorded, the more easily problems are identified and solved, the easier it is to stay focused, and the better the result is for everyone.

Somewhat surprisingly, web developers seem reluctant to adopt methods and approaches from other disciplines that could reduce their problems. Particularly during the crucial initial phase of projects, we can benefit from emulating certain software engineering practices.

Introducing use cases
An especially useful technique to consider is use cases. Use cases provide a simple, fast means to decide and describe the purpose of a project. They’re successfully employed by many software engineers as a way to capture the high-level objectives of an application during the initial phase of development. There’s no reason that web site developers shouldn’t also benefit from a use-case driven approach. Even a project that initially seems straightforward can balloon into an unmanageable behemoth if the purpose isn’t kept in mind.

So, just what is a use case?

To define a project’s use cases, we need to consider two concepts, and how they relate:

• the actors
• the goals

Actors are everyone and everything that will use (or be used) by our new website. Goals are what one, some, or all of the actors want to achieve. To be complete, every use case must describe a specific goal and the actors that will perform tasks to achieve that goal.

The actors are external to our site — we can’t create or directly control them — but they do perform roles to achieve its goals. The most obvious actor in the case of any website is a visitor to the site. Perhaps their goal is to buy one of our thingamajigs or to check an account balance, book an appointment, download software, or simply absorb content that interests them. Actors are not necessarily human; perhaps we are developing syndication system to deliver information to many subscriber-sites. In this case, the remote consumer-servers are actors.

Whatever our vision, use cases will describe the goals achieved by actors who perform tasks.

Applying use cases
A weblog enables its owners to communicate thoughts about a topic and others to read them and perhaps respond. The obvious weblog actors are the authors and the visitors to the web log. The author plays the role of generating the content and the visitor plays the role of reading the content and responding. The goals are to inform and to be informed.

After a little brainstorming, we could decide that some of these actors’ tasks should include reading an item, creating, editing, and deleting blog content, commenting, syndicating, and some administrative tasks, such as controlling access, permissions, and accounts. Some of these tasks are common to all actors and some may be exclusive to a single actor. All of them can be encapsulated in a use case that describes our initial idea: “Publish Weblog”.

This use-case diagram illustrates the relationship between actors and goals:

Use-case diagrams make it easier to think about the relationships, or dependencies, between use cases and actors. Perhaps visitors and authors would like to be able to search for particular content already published in the weblog:

Both visitors and authors want to be able to search. Furthermore, it’s not possible to search for content that hasn’t yet been published. The “Search Content” use case is therefore dependant upon “Publish Weblog”.

We’ve decided to employ Google for our searching function. Google becomes an actor and the “Search Content” use case is dependent upon Google. Google’s task as an actor is to deliver search results.

By now we’ve already identified some of the actors involved with our weblog, the goals they are trying to achieve and some dependencies between them. We can consider this a high-level conceptual architecture of our site, which will be useful when making design decisions later.

It’s all good
The crucial benefit of use cases is the way they encourage a directed method of considering project requirements. From the very beginning, we are designing a product by concentrating upon the needs and wants of those who will use it.

As with any foundation, the better our understanding of the use cases, the easier, more focused, and more appropriate will be the work that follows. Use cases are the context that allows us to easily picture where, within a project’s life, a particular element will fit, thus promoting clearer decision-making throughout design and development.

The purpose of describing use cases is emphatically not to fully specify the exact nature of what a new site will contain and how it is to be built. Instead, use cases define goals and purpose: the problems we are trying to solve. Establishing these goals lays the foundation for the scope that will follow. Additionally:

• If we simply consider the roles played by the actors and their goals, the use-case model can very rapidly emerge.
• Use-case diagrams can distill a complex project into a more easily comprehensible picture.
• A well-constructed use-case model can be understood by all the stakeholders in a project: developers, managers and clients. It’s a powerful aid to collaborative development.
• Use cases ensure that scope is under control from the outset. The identification of use cases and their dependencies makes it easy to distinguish between core goals that must be satisfied and subsidiary enhancements that may be postponed as. Scoping in this manner allows for better planning and prioritization.
• It’s an implementation-neutral picture of a project. No assumptions about tools and technologies are made, nor should they be.
• It’s transportable. No special tools are required — sticky notes, a whiteboard, pencil and paper, or your favorite graphics application can all be used to document your vision.

Use-case driven development is a mindset, as much as it is a technique. By emphasizing the actors and what they wish to achieve, project teams can advance with greater confidence and clarity. A solid early foundation of understanding amongst all concerned allows more rapid decision-making later on, and encourages a continual focus on the project’s true purpose. Much has been written about best practices for describing use cases — Alistair Cockburn’s is probably the best [1].

To see some more use cases in action, visit guibot.com, which offers alternative, use-case views of many pages.

[1] Writing Effective Use Cases. Alistair Cockburn. Addison-Wesley, 2001. ISBN 0-201-70225-8

Translations
Italian (mronca.it)
Dr. Timothy Meehan is a software architect and VP for Technology Development at Nuvotec, Inc. He is a co-inventor of eXtended Activity Semantics (XAS), an implementation-agnostic way to model user-interaction employed by Guibot tools for rapid requirements gathering.