Project Practitioners > Project Management Survival Tools - Part B (Use Cases)

Project Management Survival Tools - Part B (Use Cases)

By Matt Glei

Good use of tools can still save your life (as a project manager)! As a project manager, you face many challenges in a project. Each of us can use all the help we can get. For this 2nd post on this subject I’d like to focus on the value of Use Cases.

One of the challenges of specifying a new system, process, or product, is to capture the desired or required behaviors. These behaviors occur at very high levels of abstraction and at very detailed levels (and everything in between).

 A good use case describes the system’s behavior under various conditions as the systems responds to a request from a stakeholder, or actor. In many cases, a few (< 10) use cases can describe the [design scope] functionality of a system well enough to bound its edges and describe the major features of the system.

Use cases can be developed at many levels, including Summary, User Goals and Sub-functions. When people hear the term "use cases," they often think of very detailed descriptions of design, with flowcharts or UML [Unified Modeling Language] notation, deep in the design. Although these may be useful in very complex or detailed design activity, use cases can initially help frame the problem to be solved well enough that major features are all "discovered" and detailed. It can also help identify all the stakeholders, both public [user] or hidden [accounting].

An excellent and practical reference on writing use cases is "Writing Effective Use Cases," by Alistair Cockburn, part of the Agile Software Development Series, ISBN 0-201-70225-8. There are dozens of other books on Use Cases and UML that can help.

A use case focuses on what a user of the system wishes to do, what the steps the user will take and how the system will respond. At a summary or user level, it is usually in black box form so it doesn’t describe details inside the system as much as what the user will see. It usually also focuses primarily on a successful scenario, with notes on exceptions or special cases. Other use cases may describe an unsuccessful attempt and what happens in that case. Many examples describe ATM interactions, because although these are relatively simple machines, there are many parts of the system that must all work for the transaction to be successful. Imagine some of the use cases that must be detailed:

1. User signs in to the ATM and wants to withdraw cash and has adequate funds.

2. User signs into the ATM and wants to withdraw cash, but doesn’t have adequate funds.

3. User signs into the ATM and wants to check balances, then withdraw cash (or not).

4. User signs into the ATM and wants to withdraw cash, has adequate funds, but has
    exceeded the maximum daily withdrawal.

5. And many more, plus power failure, network failure, sign-in failure, etc.

None of these get into detailed design, but help describe the system’s key behaviors. When these have been brainstormed and documented using simple text forms or templates, they can act as a good communication tool and as a jumping off point for more detailed requirements capture or design activities. Although use cases have been used extensively in software development, the technique is very helpful in hardware, mixed systems and even in business process design.

Remember that the value of any technique is in adding value to your project. The project manager must use his or her expert judgment in deciding how deep to use any of the techniques and tools available.

I’d love to hear about good and bad experiences with use case techniques. I’ll talk more about other tools, methods and processes in future blogs.

-- Matt Glei,

Related Links
Sinikka Waugh has provided a document outline you can follow when writing use case specifications. Agile project teams may prefer requirements cards and user stories. Context diagrams can help you identify a system's boundaries and interaction before writing the use cases.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I am a definite proponent of use case models for system development projects. The primary and alternative paths are the main part of this type of exercise. I usually also include pre-conditions – what event(s) must be met before the case is initiated, post conditions – what event(s) transpire after the case is completed, the frequency of the event/case being described and what triggers the event (e.g. a human, another system, etc.).

Thanks, Ann. You're right - in fact, although I just hit the high points, the book on wiriting use cases I cited goes into great detail about all the specifics. The breakthrough for me recently was that capturing the use cases or user stories can start at a very high level and then be decomposed into greater detail that will help the team uderstand and model the desired action. In the past I had always seen the detailed approach only. At a high level, even a product manager could write a use case! {Not to put product managers down - I've been one in a previous job}

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.