The emphasis in Kulak & Guiney 2003 is on the use of UCDs as a tool in preparing system requirements.

If, on the other hand, the purpose is to try to make sense of the system as it is (the old, flawed system) it may be necessary to do some work before high-level executives get around to making clear statements.

UCDs can also be used to help analysts explore how the current system works. These should be considered drafts or rough sketches, preliminary to beginning the work of defining system requirements. Once that task begins, UCD designers need to have the organization's mission, vision, and values statements clearly in mind so they can communicate the intent of the system clearly.

Requirement: Object Management Group (OMG: www.omg.org/uml), defines a requirement as "a desired feature, property, or behavior of a system."

Requirements are of several types:

• Needs - what stakeholders believe the system must do
• Features - system capabilities described in a general way, at any level of detail. (For marketing, or from a user interview.)
• Software requirements - precise, detailed definition of external behavior of the system: inputs, outputs, and relations between the two.

Relating requirements to use-case diagrams:

• Use-cases provide us one way to translate features into requirements
• "The granularity of the features and the use-cases are very different. ... Not all features would make sensible use-cases."
• "[T]here can be many features provided by a single use-case, or a feature could be provided by more than one use-case.
• Features are not use-cases, and vice versa." (Bittner & Spence 2002, Chapter 1)
  

Keep these guidelines in mind as you prepare your UCDs:

1. Focus on Effective Communication. The purpose of the use-case model is to facilitate communications.
2. Pursue Simplicity. The model should be as simple and straightforward as possible.
3. Remember Your Stakeholders. The audience for the model is the entire stakeholder community.
4. Good Enough Is as Good as It Gets. There is no such thing as perfection in use-case modeling.
5. Write Things Down. You will have to write down what the system is supposed to do in detail - there is no way to avoid this.

What UCDs are not

• Use-case diagrams are not data-flow diagrams. Their focus is on value to the users, not the process by which the value is delivered.
• Use-case diagrams are not a list of functions. Their focus is on value to the users, not the sub-parts that deliver the value.

(Bittner & Spence 2002, Chapter 1)

Use-case diagrams consist of four elements:

Actors are outside the system; in the object-oriented world-view, actors exchange messages with the system. In UML, they are represented by stick figures.

Use-cases (referred to here as "use-case entities") are things actors do with the system to accomplish a goal; they are how the system provides value to users. They are represented by ovals in UML.

Successful use of this type of analysis requires choosing appropriate levels of generality and specificity ("granularity") for each actor and use-case. This is largely a matter of experience.

You can run into problems either being overly specific or overly general:

• Being too specific results in too many use-cases, with no clear view of the overall purpose and interactions of the system.
• Being too general obscures details that are necessary for understanding the system.
  

Here are some things to consider as you analyze a system to determine who and what the actors are:

• Many actors are people; what are the roles they play with respect to the system?
• Other actors are non-human: devices and systems that interact with the system we're looking at.
• What are the different types of users? What are the roles of each type? Model each role as an "actor"
• Actors are not the same as organizational job titles or roles
• There are two main types of actors, defined by their goals and relationship to the system:
  1. Primary actor: one for whom the system is built
  2. Supporting actor: one who supports the system, for example by providing information or maintenance functions.
• Ask: Who are the users? "The real users are the ones without whom the system itself would be pointless and unnecessary." These are the primary actors.
• When systems interact with each other, they view each other as actors.
• Where will the system get the information it needs? Does it have the information already? Information sources are often secondary actors.
• However, OSs, networks, databases, input/output devices, and other infrastructures are not considered actors. They are considered a part of the system.

Here are some procedural guidelines: where to start, what order works best. It's not exactly a step-by-step procedure, because you're likely to have to repeat steps and jump around a bit.

Overall: Work from specific to general: almost always easier

1. Start by defining the boundaries of the system you're analyzing.
   "[Y]ou need only focus on what your system must do for its actors"
2. Name the actor in a way that describes their distinct purpose for interacting with the system.
3. Briefly describe each actor (2-3 sentences)
4. Characterize the actors by:
   • Scope of responsibility
   • Physical environment
   • Number of users represented (rough estimate)
   • Frequency of use
5. For human actors, determine:
   • Level of familiarity
   • Computer experience
   • Demographics (gender, age, language, education)
6. Trace actors to actual people or entities.
• If human, are they customers, stakeholders, technicians, managers, etc.
• Otherwise, describe physical devices or external systems that play the role

Here are guide-lines for creating use-case entities in a system. They are not rules, just advice on what usually works best.

1. Before beginning, be clear what the overall purpose of "the system" is. Recall that the system (or sub-system) illustrated by a UCD will be identified by a rectangle with the use-case entities inside, and actors outside. This means it's important to know what will be inside the system (the use-case entities) and what will be outside (the actors).
2. Identify needs of each actor; each use-case should provide some sort of value for its user-actor(s).
3. Identify information needed by the system and the users.
4. Identify supporting and maintenance operations necessary for the system, and develop use cases for them.
5. Based on the purpose and needs of the system and its actors, create use-case entities that address each need or cluster of closely related needs identified in the preceding steps.
6. Name the use-case entities. Simple is better (but not required at first); "The names of use-cases are active and expressed as goals of the actors." Active is better than passive; for example, in a fire alarm system, which name better expresses one purpose?
   • "Report a fire" (active)
   • "Fire notification" (passive)

Relations, also called associations, are the lines that represent message transmission between actors and use-case entities.

Usually, the line is an arrow that points from the initiator of the communication to the first recipient. This can be confusing at first, because messages can flow both ways even though the arrow only points one way.

Relations can be represented by lines without arrow heads as well.

Use the documentation features of your UML software to connect information with each part of the diagram.

1. Describe the system on which this UCD is focused.
2. Describe the actors in the UCD.
3. Connect the actors with stakeholders in the organization as well as users or customers outside the organization.
4. Explain relations: describe briefly how messages are transmitted between actors and use-case entities.
5. Describe the use-cases. Explain the purpose of each use-case and the value it produces.
6. Connect the use-cases with stakeholders. Explain what value each use-case has for the specified stakeholders.
7. Connect the use-cases to system features and constraints. This part of the documentation is vital to making the system requirements clear and understandable.

Here are some systems you can practice creating UCDs with:

• Fire alarm system
• ATM
• Airport security
• Automobile ignition system
• E-commerce site