What a wonderful question! Jenny and I have been writing about use cases, user stories, and requirements for a really long time. This is a favorite topic of mine – we talked all about use cases in our first book,
Applied Software Project Management, and if you Google for "user story use case"
this blog post from 2009 called "Requirements 101: User Stories vs. Use Cases is one of the first things that pops up! That actually goes into a lot more detail, with examples of a user story and a use case to help you see the difference.
"Software requirement" is a large category. I'm sure you looked up the
Wikipedia page for software requirements, which has the IEEE definition of the term "requirement." (That's a good definition—take a seciond and read the very top of the page.)
And now we'll make it really simple: a requirement is
something that the software is supposed to do. Something that we
require of the software that we're going to build... hence the term "requirement." But there are a couple of things that we need ti keep in mind about requirements:
* One way to measure quality is to see how well the software your team builds meets the requirements. From this perspective,
testing means making sure each requirement is met.
* But there's another aspect to this: fitness to use – what you build actually needs to be usable under the conditions that your users will use it.
* At the most basic level, your requirements have to
meet the needs of your users. Requirements are a tool to help you do that,
Use cases and user stories are
types of requirements.
So what's the difference between them? One really simple way to think about it is that
user stories are about the user, and use cases are about the software.
A user story is a really simple tool that tells you about one specific user need. If you want to see some examples of user stories,
here's a handout I used in a training session last month (PDF) that includes a bunch of user stories from a fictitious ATM (cash machine) project. Here's one called "Fast cash withdrawal" from that PDF:
A use case shows one specific interaction between a user and the software, with a series of interactions between a user and the system – and also the system and other systems. For example, a use case that implements this use case might have a set of steps like this (this is off the top of my head, so apologies if it's buggy!) – you'll notice that the ATM is interacting with both the user and other systems:
Precondition: Bank customer has entered her PINStep 1. ATM looks up the user's preferred fast cash withdrawal amount from a back-end preferences systemStep 2. ATM provides a set of options that includes a "fast cash withdrawal" option that indicates the amount looked up in step 1Step 3. Bank customer indicates that she wants to withdraw cashStep 4. ATM contacts the back-end system that manages the accounts and initiates a withdrawal for the amount looked up in step 1Step 5. Bank customer takes the moneyStep 6. ATM displays a prompt to continue the session, print the receipt and end the session, or don't print the receipt and end the sessionStep 7. Bank customer indicates that she wants to print the receipt and end the sessionStep 8. ATM prints the receipt and ends the sessionPostcondition: ATM resets itself and waits for the next customer
The use case might have alternative paths (e.g. the user continues the session or doesn't print the receipt in step 7). But notice that this use case is mainly about how the system will operate. Ideally, it shouldn't constrain the design – for example, this use case doesn't include words like
display a menu, so the developer working on a feature that has an audio prompt for visually impaired people isn't constrained by the
word "display."
I know this didn't have a lot of metaphors, which you specifically asked for. But hopefully the examples helped!
1
