Definition

With software, a “use case” is a specific situation for which the software must be used to achieve a particular goal. Normally, this will be defined as a set of steps that must be followed to do the work. Use cases are invaluable for customers and suppliers alike. They help a supplier to understand what the customer wants and they help a customer define what they want and test that they are getting what they want.

Examples of use cases

As examples:

  • For word processing software, a use case may be the task of printing a document or adjusting a margin.
  • For CAD software, a use case could be drawing a line or embedding another drawing within the current drawing.
  • For photo editing software, a use case could include cropping a photo or deleting a photo.
    With network modelling software, a use case might specify the adding of a new node or the copying of a large area of network.

Designing use cases

As with most aspects in this newsletter, we are not concentrating on the technical definition as much as on a more practical meaning.  There is a technical meaning, and readers are encouraged to be aware of this (you could start on Wikipedia here: https://en.wikipedia.org/wiki/Use_case), but our main reason for speaking of use cases and their value is because they can be a useful tool in helping to define our requirements and providing a way of testing whether those requirements have been met.  Overall, we aim to be thoroughly practical in trying to understand data modelling and how to model data successfully.

Various other testing methods can be used and you may consider that other processes with different terminology suit your organisation or your requirements better.  The goal is always to assist the process of getting from where we are to where we want to be.  As long as we can satisfy this goal, the process and terminology we use is not important – there are many methodologies, processes, paradigms and frameworks in software engineering.  Use cases can help to define where we want to be in small sections our project.  Looking at how we can design them helps us to learn how to clearly define and state our goals.

At times, just one use case can be made the determining factor in acceptance of software.

Some years ago, I was working for a customer whose main method of assessment of software was “number of clicks”.  At the time, the customer had defined many use cases and selected just a few of them as the best representative samples of the work the software was to implement.  Every week, the customer representative would be back beating the drum about “number of clicks” as they tried to get us to concentrate on their critical “click” targets.  Obviously, minimising the number of user actions can be an important way of improving how quickly a task can be done, but at the time it seemed to foster a focus on reducing user interaction while ignoring flexibility and even accuracy.