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, www.KnowHowConsulting.biz