The Unified Modeling Language (UML) diagram commonly used to capture requirements is the Use Case diagram. The goal is to identify every external "something" that interacts with our system. These "somethings" are known as Actors. The one rule for an Actor is that is has to be external to the system. We want to identify every external interface to the system so we can define those interfaces with a specification that covers all possible interactions over the interfaces.

Of course, the Use Case diagram just identifies the interfaces. We will use Scenarios to fill in the details of each use of the interface and what actions and reactions can occur as a result of those (correct and incorrect) uses. We will discuss Scenarios next.

Let's design the Mk IV Grits Maker and Potato Peeler from our last discussion. This device is one our company acquired from a recent acquisition, "Bubba's Grits'N'Spuds, Ltd." Bubba's engineer, Ralph, didn't believe in documentation or formal design, so we are going to have to essentially start a new design, but based around the existing Mk III model. Sound familiar?

First, we want to document the existing Mk III. It has an on/off switch and a switch to choose "peel" or "gritify". The operator places either a potato or an ear of corn in the hopper, closes the lid, selects a mode and turns the machine on. The machine then either grinds the corn kernels into grits or peels the potato skin. It gets messy if they forget to select the proper mode.

We will draw a Use Case for the Mk III to illustrate its existing controls. We will also use the Use Case Drawing to construct scenarios around the operation of the Mk III so we can capture all its present functionality. We then have a good starting point from which to design any changes we want to incorporate into the Mk IV.

We will, for instance, try to correct any operational problems existing in the Mk III. We also probably want to add features so people will junk their Mk IIIs and spend the money on our Mk IV. We also want to try to make the Mk IV cheaper to build than the Mk III was! That is what new and improved technology is all about, isn't it?

So, our Use Case Diagram for the Mk III looks like the following:

We stated Actors directly interact with the Mk III and are external to the system. That's why didn't list the on/of switch and the mode switch as Actors. The operator interacts with these switches, but they are an integral part of the system, not something external that connects to the system. If we had an Ethernet network port on the Mk III, it would be part of the system, but the port wouldn't be listed as an Actor. We would list what ever connects to the network port as an actor. The Use Case Diagram is intended to allow us to define all the interfaces into and out of the system, not internal interfaces.

If we have a temperature sensor we must monitor, we will list the sensor as an actor if it hooks to the system through a set of leads, but not if it is internal to the system, such as an integral part of a motor assembly. Likewise, if we use a remote control to turn our Grits Maker on or off, the remote would be an Actor since we have to define the protocol used to control the system with the remote.

What about the ear of corn and the potato? They are the material the Mk III works on, but does that qualify as interacting with the system? I include them because we are trying to define all of the operating conditions and interfaces for the Mk III. One set of those conditions involves selecting the wrong mode for the type of material placed in the hopper. Corn and Potatoes are the normal input to the hopper, so we list them and not other possible inputs like tomatoes. We will probably describe a scenario where another type of material is input into the hopper, but that is not part of a "normal" Use Case.

I also drew one Use Case Diagram and not two, one each for corn and potato. We may also draw these separate Use Case Diagrams, but they would be redundant to our single diagram and would not show any more detail than the single diagram. A Use Case Diagram is one possible use of the system, usually a "normal" use. If the Mk III was more versatile, we could end up with many Use Case Diagrams for its many modes of operation. If, for instance, we had an attachment that could be used or left off the Mk III, we would probably have separate Use Case Diagrams for each configuration.

Let's say we had a French-Fry attachment we could put onto the Mk III which automatically took the peeled potato and output French fries. Since it is external to the basic Mk III, we include it as an additional Actor and show any interfaces between it and the Mk III. We do not show interactions between Actors on the Use Case Diagram, but we are free to describe details in text notes.

Out Mk IIIF diagram looks like this:

The next installment will go into detail on Scenarios and we will then come back to Use Case Diagrams and construct a much more elaborate set of diagrams for the Mk IV model.

Pat