Could you please use your metaphores/examples to depict these concepts? And most important, in which relationship are use cases and requirements: one to one or one to many?
I received a partial response already from a JavaRanch Sherif, but still would not harm to exploit your marvelous abilities to explain things simple
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 PIN
Step 1. ATM looks up the user's preferred fast cash withdrawal amount from a back-end preferences system
Step 2. ATM provides a set of options that includes a "fast cash withdrawal" option that indicates the amount looked up in step 1
Step 3. Bank customer indicates that she wants to withdraw cash
Step 4. ATM contacts the back-end system that manages the accounts and initiates a withdrawal for the amount looked up in step 1
Step 5. Bank customer takes the money
Step 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 session
Step 7. Bank customer indicates that she wants to print the receipt and end the session
Step 8. ATM prints the receipt and ends the session
Postcondition: 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!
Author of Head First Agile, Learning Agile, Beautiful Teams, Head First C#, Head First PMP, and Applied Software Project Management (O'Reilly)