There’s a right time and place for everything in life. Use Case Modeling is no exception to this rule.
New Business Analysts focus far too heavily on use cases as a modeling tool (I know because I’ve done this myself early in my career). This happens for a few reasons:
- Every job posting seems to be asking for “use cases” as a mandatory skill.
- Use cases are easier to understand than some of the other more abstract modeling tools that we need (e.g. ERDs and State Machine Models)
- Use cases seem like they’re easier to produce. Just make a list of the steps that the user has to perform in the system and viola.. you’ve done requirements, right?
No, Not Right. Let Me Explain Why
Like user stories, use cases are a good modeling tool for describing half of the user interaction level of a solution. A use case basically describes the sequence of steps that the user and the system perform back and forth to achieve some end goal.
For example, use case with the end goal to make an online payment might look like this:
UC: Pay for Product Using Credit Card
- User has already selected the item(s) they want to purchase
- User has already decided to check out with their shopping cart
- Order has successfully been placed with fulfillment department
- User navigates to payment entry screen
- System displays list of optional and mandatory data fields
- User enters data into fields
- User chooses to submit the data
- System validates the data in accordance with rule-set #14
- System creates order
- The validation rules in Rule-Set #14 can be found in Appendix C1 of this document
We can see how neatly this describes the user interaction. We can even add a wire-frame with this use case to give the customers and the dev team an idea about the layout of the screen that the user might be interacting with during the execution of this use case.
So What’s Missing Then?
What’s missing are the answers to many, many, questions that the development team is going to have after reading this use case.
- What exactly is an Order? Can the same user create in multiple orders for the same product?
- Is there anything else that has to happen to the order before it goes to the fulfillment department?
- Can the same user create in multiple orders for the same product?
- What is the relationship between an Order and a Purchase?
- Can the user Purchase this Product multiple times with the same credit card?
- Does our system store the credit card information internally in the system, or are there other workarounds that can be applied here to reduce privacy issues and development scope?
- How does this flow into our accounting system for financial reporting?
- and on, and on…
These Questions are Answered at The Lower Levels of the Solution
I’ve mentioned before that a solution has multiple levels. Something we call the SOLUTION STACK. Each level serves a different purpose for the BA during requirements & design. The BA can use the solution stack as a guide to determine which modeling tools they should use in different situations.
So, When Should We Write Use Cases?
BA’s should write Use Cases only when they need to describe the user interaction with the system for their requirements.
Would anyone else find this useful?
Please share this article with one person who you know is interested.