Documented use cases fall into the same category as several other valuable development tools like Gantt charts and workflow diagrams: while not technically necessary, they add far more value than they cost in time and effort. (Although it’s important to note that use cases can account for a much larger part of the overall analysis period than some other tools because they are fairly in-depth.)

Even though they’re somewhat time- and labor-intensive, the value of creating and documenting every possible use case scenario cannot be overstated.

What the use case offers

So we’re all on the same page, here’s a workable definition for the use case from Wikipedia:

In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals.

I’m not intending to provide an in-depth treatise on use cases, how they’re created, or how to best use them to achieve optimal results in this article. So if that interests you, I highly recommend setting aside a half-hour to review this excellent resource published on ACMQueue.

To break it down, the standard use case includes the following basic components:

• Actors – either a person or an outside system (like a web app that needs to integrate with the system under development.)
• Roles – a specific characteristic that the actor displays when interacting with the system under development.
• Goals – the mission the actor playing a particular role is on. What specific action they want to accomplish.

So, a standard use case description will define these three elements in order to look at the software from a practical use standpoint:

What steps does this user (or system) need to take to accomplish their goal?

A practical use case example

To provide a simple example, let’s assume we’re developing a custom software application to allow employees in a manufacturing firm to access an end-to-end view of the manufacturing process from order to shipping and subsequent billing.

One realistic use case that must be documented should detail the exact steps needed for an end user (the actor) in the billing department (the role) to pull up an updated list of outstanding invoices (the goal.)

The resulting use case might look something like this:

Billing Specialist accessing outstanding invoices:

1. Accesses system and logs in (verifying security level)
2. Clicks “Billing” (accessing that module)
3. Clicks “Display” (setting up DB query)
4. Inputs filter requirements (specifies Type: invoice, Status: outstanding)
5. Clicks “Submit” (submitting DB query)
6. DB Query (secondary Use Case)
7. Results displayed
8. Chooses to print, download, share, or edit results list

As you can see, every step of the process is noted, following this specific user as they navigate the system to accomplish whatever their goal is. In Step #6, the system calls up a database, which we’ll assume is housed in a separate system. That makes the new system where the database is housed another actor with a different role. So, Step #6 will need to be broken out into a new use case of its own that describes the technical steps the database system will take to receive and process a query and return valid results.

The more complicated a given system or application is, the more nested use cases you’re likely to need in order to cover all your bases.

How we use use cases

At CSPreston, we enjoy creating use cases as an integral part of our development process. We find that taking the time to do so offers some powerful benefits that can’t really be consistently obtained any other way:

• Documented use cases help clarify a client’s requirements as to functionality by interpreting a given function into a real-world application showing how it would be useful in accomplishing a business goal.
• Use cases help unearth previously unidentified functionality that needs to be developed in order to accomplish one or more business goals.
• Finally, use cases can help identify functionality that has no practical application, removing unnecessary fluff from the project requirements and streamlining the development process.

Use cases tend to alter the client’s and the developer’s perspective to a more productive customer-centric view – looking at the resulting application from the standpoint of the end user and how they are actually likely to use it rather than from the standpoint of the developer or what the client’s intentions are.

As you can imagine, formally documented use cases aren’t necessary for very simple development projects like a brochure-style website. There are likely no more than one or two uses any user is likely to want out of a site like that, and those uses would be intrinsic to the design and development process from the start.

But for complex projects that involve a number of possible scenarios and that need to interact with multiple systems, documenting all the potential use cases provides an excellent opportunity to analyze and optimize the development process and produce a much better product for the end user.

So, once again, no – your project doesn’t need documented use cases to succeed. But, if it’s a complex project, its chances of success are greatly reduced without them.