Uses for Use Cases
The requirements-gathering process is often an overlooked part of systems development, particularly in more modern methodologies designed to code immediately or fast-track a project. It makes sense to “not” document for document’s sake – but when you don’t know what the end goal is, it makes less sense to start coding in my opinion.
What is a use case?
A use case is simply an activity that the system is going to perform. Normally this is a request by a user.
There are several methods for working with users to develop use cases. A common one is user goal technique where users simply state the goals they need to achieve with various parts of a system. There is also event decomposition which involves examining interactions with the system to reveal use cases.
Use cases should define functional requirements
If the case doesn’t have anything to do with the system, it doesn’t belong in a use case analysis.
This is one of my favorite images regarding this topic for a variety of reasons… But the main point here is that you get a ton of information that has absolutely nothing to do with the system when working with users. A good analyst can sort through the unnecessary and arrive at the right conclusion.
While a list like this of use cases may seem like a complete waste of time to a great programmer, good project leads can see that they have some great value. Use cases:
- Identify all users of the system
- Hey – we’re human, we may miss someone!
- Create a methodical list of requirements
- It’s easy to follow; it makes sense.
- Everybody can get on the same page.
- The requirements become infinitely clearer.
- Show acceptance criteria for everyone
- If someone isn’t happy, you may not get paid!
- Verifying that all use cases are to be included in your software makes the project much more likely to succeed.
- Lead to test cases
- There’s software out there that will do this for you.
- How nice of the users to show you what you need to test!
Before you bash use cases or decide that you can take a shortcut around them, make sure you are prepared for the other possibility – that you’ll leave something out, upset a potential stakeholder in your project, or cost your company money with rewriting code that doesn’t meet the bar.