From Use Case Diagram to Operational Profile

In the previous post we explored an important question related to working smart in test design: Does it really make sense to spend the same amount of time and rigor on test design for all use cases? We looked at the idea of an operational profile, a tool used in software reliability engineering to spot the high traffic paths through your system allowing you to concentrate test design on the most frequently used use cases, and hence those having a greater chance of failure in the hands of the user.

In this post we'll look at how to generate an operational profile from a use case diagram.

 

The QFD Matrix

QFD (Quality Function Deployment) is a product-planning tool that is used to translate business drivers into the technical requirements and design aspects of a product. Though originally developed for manufacturing industries in the 1960s, today QFD-like ideas are being used successfully for all sorts of applications, including software development, the services industry, and process management, and is considered an essential part of the quality improvement toolkit.

QFD boiled down to simple mechanics is about establishing priorities, the key tool being a QFD matrix. QFD is an ideal tool for representing a use case diagram – establishing links between actors and use cases -- and for generating an operational profile from that diagram.[1]

The easiest way to see how to generate an operational profile from a use case diagram using a QFD matrix is with an example. Using the public library book management system use case diagram from the previous post, we build a simple QFD matrix, here implemented as an Excel spreadsheet (below). In this matrix, all actors of the use case diagram are placed in rows, and the use cases are placed across the top as columns.

QFD matrix to generate operational profile from use case diagram; rows are actors, column use cases

 

Quantify Numbers of Actors in Use Case Diagram

The next step in analyzing your use case traffic is to quantify the number of each type of actor in the use case diagram. How many book curators are there? How about librarians; self-service kiosks? Don’t get hung-up on precise numbers; ball park numbers are all you need to understand the relative numbers of actors, e.g. how many librarians do you have relative to curators: Same amount; twice as many? How about internet users; how many more than kiosks: Twice as many; a hundred times as many?

At this point you might say, “I have no idea how many internet users to expect!”. To which I would respond: Bingo, we’ve just identified a non-functional requirement that needs clarification! Asking questions about numbers of actors in the use case diagram is a healthy thing to be doing early on.

Keeping in mind that the goal is to get ballpark numbers for the operational profile you might try this. Rather than agonizing over whether there is one versus two book curators, or fifty versus two hundred internet users, try working with orders of magnitude. An order of magnitude estimate is one given in terms of a factor of 10:

10⁰ = 1

10¹ = 10

10² = 100

10³ = 1000

10⁴ = 10,000

etc..

By their nature of separation, it’s usually easier to come up with orders of magnitude estimates. What’s the average life of a person? Rather than getting into debates about the numerous factors that affect people’s longevity—health, lifestyle, country, even what century—it’s pretty clear that it’s on an order of magnitude of 100 years; 10 is way too small and 1000 is way too big. Use order of magnitude estimates to get you in the ball park, then step back and refine your estimates if you feel so inclined, doubling here, and halving there.

So for our library use case diagram, using orders of magnitude estimates, let's say there is one curator, ten librarians, one self service kiosk, and one hundred internet users that might be accessing the system each day. This information is placed in the matrix in column Number of Actors (below)

QFD matrix to generate operational profile from use case diagram; in this step you quantify the number of each type of actor

 

Quantify Use Case Frequency of Use by Actors

With estimates of numbers of each type of actor identified you now turn to the question of who does what, i.e. which actors use what use cases .. and how often! In a use case diagram this information is captured as relationships – depicted as lines – between actors and use cases. In the QFD matrix it is captured by placing a number in the cell that corresponds to the intersection of an actor (row) and use case (column). The number you place in the cell is the number of times a “typical” actor of that type will execute that use case per some unit of time, say daily. If an actor never uses a particular use case the cell is left blank.

Again, using orders of magnitude to estimate frequency of use will help avoid analysis paralysis. Once in the ballpark you can step back and tweak the estimate, doubling here and halving there if needed. For the library use case diagram, orders of magnitude estimates for each actor are provided in the matrix below; frequency is given in times per day each use case is executed by each actor of that type.

QFD matrix to generate operational profile from use case diagram; cells show which actors use what use cases .. and how often!

 

Notice that the Book Curator executes the Add Books to Library Database use case and Remove Books from Library Database use case .5 and .05 times a day, respectively.  Are those order of magnitude estimates? Yes; when a use case is used less than once per unit of time – here daily – you can get the order of magnitude estimate as follows. The curator adds about 100 books (order of magnitude) a year; a year is about 200 working days, so the formula for calculating daily use is:

100 / 200 = .5

Similarly, the curator removes about 10 books a year (order of magnitude; the library is growing!), so the formula for calculating daily use is:

10 / 200 = .05

Getting estimates of the number of actors of each type and frequency of use information is the hard part of analyzing the traffic through your use cases. All that is left is to crank out the results. The matrix below shows the final results: an estimate of the frequency of daily execution of each use case by all actors in the library book management system (also shown are the formulas you need for this; the top formula calculates absolute number of times per day; the bottom formula calculates relative frequency.)

Final QFD matrix to generate operational profile from use case diagram.

In a future post we’ll look at how to put these relative frequencies to work in test design.

---

[1] You really don’t need to know much more about QFD to generate an operational profile from a use case diagram, but if you want to learn more refer to Denney, Succeeding with Use Cases, Part 1, which gives a broader treatment of the combined use of QFD with use cases.