The Use Case Model

The use case model is, essentially, a visual representation of all the people and computers that will interact with a system and all the tasks that the people and computers can do with the system. In other words, it's a high level view of what a system will do.

This blog describes how to draw a use case model (it's not hard) and, much more importantly, how to reason about a system using a use case model. Because use case models can be drawn very quickly at the beginning of a project, any reasoning we can do with a model can have huge pay-off down the line.

What is a Use Case Model?
The thing I like most about use case models is that they're damn easy to understand. Take my most often used example: a pizza company:

This model tells us that there are two key people using the system - someone who takes orders and someone who makes them. The person who takes the orders can do three things - order a pizza, cancel an order, and deliver a pizza. The person who makes the order can only do one thing - make a pizza.


For a bit extra reasoning power, I call the "people" in the diagram "user roles". This is because, in reality, one person might play both roles. Or there might be one role played by multiple people. To get technical, a "user role" is a role that a person takes on when using the system.


Are there any guidelines for drawing one?
In fact, yes. The use case model above is pretty damn awful. Here are some guidelines and how they're broken above:

• A user role describes a role that a particular user takes on when interacting with the system. In the diagram above, the "order taker" role can perform activities relating to manipulating orders in the system and activities related to delivering pizza. This is bad because when we come to do solution design, we want to be able to support the tasks for a user role on as few screens as possible - and having order delivery support on the same screen as entering new orders would most probably be dumb.
  
• The task names like "make pizza" relate to the overarching goals of the user as opposed to the goals from a particular interaction with the system. Much more sensible names would be things like "get next order to make" and "mark order as complete". In other words, the tasks performed at the system boundary are not well defined.
  
• The complete set of tasks described is insufficient to achieve the key business scenario - get the right food to the right customers within 30 minutes. To support that scenario we need tasks like "view list of waiting orders".
  

Here is an updated use case model with the first two points applied:

This is a much more precise model. We're now clearly defining the key functional requirements of the system in a much less ambiguous way. We've also identified three types of user roles that require different types of solution support. For example, the requirements of the order taker, a person who has to deal with a customer who will change their mind are quite different to the requirements of the order maker - a person who doesn't need a high degree of interactivity in any solution. We can reasonably expect that the order taker will become an expert user of the system as their goal is to get the orders into the system whereas, for the order maker, using the system is secondary to their main goal of making the orders!



What kinds of reasoning can we do with them?
There are several kinda of reasoning that we can now do. 

The first is identifying missing functionality. Given that our key business scenario is "get the right food to the right customers within 30 minutes", we might want to add in a "order delay manager" user role and use cases that let them examine the order queue and assign staff to particular parts of the shop. We might want to add in basic cash management and accounting functions - or even inventory control functions. 

The second is around scope and prioritization. With a simple quick diagram we can have a conversation with our customers about how they view the system being used. We can then talk about which functions are the most important - and if we're doing things in an agile way, we can start building those key functions straight away.


Finally, we can use the diagram as a jumping point for analysis. There will be business rules applying to all functions. For example,  there might be a cost to the customer of canceling an order. However, to read about how to best document these rules - and the process required for describing the requirements for a function - you'll have to wait for the "use case" blog post I've got lined up!

Quality Function Deployment - The Quality Chart

"The iPhone is a quality product."

Let's think about that statement for a while. Do you agree with it? Why? What does the word "quality" mean for you? Do have any colleagues/friends who do agree with it? What does "quality" mean for them? What about your colleagues/friends who do not agree with it? What does quality mean for them? Hopefully it's clear that 'quality' is a subjective aspect of a product. One person's quality is not another person's quality.

This blog post looks at quality. There's a lovely methodology that helps us determine how to build quality into a product. It's called Quality Function Deployment (QFD). I'm going to be blogging a bit about the QFD methodology and will start with the first model in QFD – the quality chart. The quality chart helps us understand what our target audience mean by quality - and what elements we need to build into a product to ensure that we are achieving quality for our audience.

Along the way we look at using the quality chart to drive product development - an interesting side topic!

The Quality Chart
The Quality Chart is, basically, a matrix linking customer demanded quality items with quality elements that we can deliver. It's designed to help translate a customer's perception of quality into a set of elements in the language of the company engineers (or software developers :). Consider this example (which I just made up for a phone  - a proper analysis might have quite different things):

The items in the 'demanded quality' side of the matrix are things that have come up in customer research. To determine the quality elements that the product must have to deliver the demanded quality, we first determine all the elements (the top of the matrix) that are necessary to deliver the demanded quality and then analyze the demands to define exactly which elements are necessary to deliver each attribute of quality that is demanded.

We then rearrange this matrix to be explicit about which elements support which demanded characteristics.

• finish does not degrade - scratch resistance, waterproof
  
• easy to find features - consistent navigation; unambiguous naming scheme
  
• etc, etc, etc.

This view of the information tells us exactly which elements we need to deliver a particular attribute. The advantage of this view is that each demanded quality characteristic appears only once in the list - it may appear multiple times in the matrix due to the decomposition.


Product Selection, Creation, and Modification

A really useful thing about the demanded quality items is that we can group sets of items into products. For example, one product might have demanded quality items 1, 2, 3.1, and 4.1.2. Another product might have 1, 2, 3, 4.1.3. This lets us carve up our products into a user centered set of demanded qualities - and then determine the quality elements we will have to build into each product. As our understanding of demanded quality and quality elements changes, we can: update the matrix, determine the impacts on the quality elements for each product, and produce new versions of each product for the next release.

This process of updating our quality chart provides a product delivery cycle based on the demanded qualities of our products - quite a useful because as customer expectations (demanded quality) change, our product's features (quality elements) changes to match.

Decomposition of Demanded Quality
Demanded quality is what our customers/users/stakeholders want. We produce this though customer workshops, interviews, surveys, feedback, market research, etc, etc, etc. The key things about demanded quality items are:

• Items at the 3rd level must be SMART (specific, measurable, achievable, realistic, time-bound).
• Items should not be restricted to a particular product. Let the people determine the scope of the items.

Personas and Scenarios (as exposed by Cooper) might also be very useful in determining demanded quality.

Decomposition of Quality Elements

Quality elements are, essentially, what we can build into a product. The experience that the product team has will impact the comprehensiveness of the set of quality elements. Because creating a comprehensive list is hard, it's more important to prioritize elements than attempt comprehensive analysis.

Luckily, the ISO has defined 6 quality elements for software:

• Functionality: are the required functions available, including interoperabilithy and security
• Reliability: maturity, fault tolerance and recover-ability
  
• Usability: how easy it is to understand, learn, operate the software system
• Efficiency: performance and resource behaviour
• Maintainability: how easy is it to modify the software
• Portability: can the software easily be transfered to another environment, including installability

We can (probably) produce a standard 3 level docomposition for each of these. For example, usability might break down at the 2nd level to:

• easy to understand
• easy to learn
• avoids errors
• guessable (or 'intuitive')
• user experience
  
• etc

then we can decompose each of those further - to a level that is clearly measurable.

Is this a thinking tool?
For any product of reasonable complexity, the quality matrix is going to be large. This means that an analyst won't be able to cognitively understand and reason about the entire quality matrix. However, it does give us these abilities:

• Confidence that the features being built/designed will achieve the demanded quality
• Ability to perform an impact analysis of a particular feature not being delivered
• Ability to prioritize quality elements for design and development.

Those are all very good things. However, because of the lack of abstraction and ability to cognitively manipulate the matrix (like we can do with use cases and use case models), I call this a reasoning tool - it helps us reason about quality and determine impacts.