Unique ID: APP 130 Copyright International Business Machines Corporation 1998, 1999, 2000

Transcription

1 IBM Global Services Use Case Model Work Product Description (WPD) Unique ID: APP 130 Copyright International Business Machines Corporation 1998, 1999, 2000 Version 3.0, January Description The Use Case Model work product describes the functional requirements of the system under development. The model uses graphical symbols (see Figure 3) and text to specify how users in specific roles will use the system (i.e., use cases). The textual descriptions describing the use cases are from a user s point of view; they do not describe how the system works internally or its internal structure or mechanisms. The Use Case Model is described by the following constructs (see Figure 1): Actors (name, description, status, subclass, superclass, and associations) Use cases (number, subject area, business event, name, overview, preconditions, description, associations, inputs, outputs, traceable to, usability index, and notes) Communication-associations between actors and uses cases Relationships between use cases (same as use case associations) Termination outcomes Conditions affecting termination outcomes Termination outcomes decision table Use case scenarios (number, termination outcome, description, and notes) Problem domain concept definitions System steps decision table Flow of events table System sequence diagram Number: Subject Area: Business Event: Name: Overview: Preconditions: Description: Associations: Traceable To: Usability Index: Inputs: Decision Table Outputs: xxxxxxxxxxxx T T Notes: Decision Table xxxxxxxxxxxx T T F xxxxxxxxxxxx F F F xxxxxxxxxxxx F T T xxxxxxxxxxxx T xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx Use Case F F F F F T T T Scenario Number Use Case Number Termination Outcome Scenario Notes Scenario Describption Termination Outcome: Conditions Affecting: Flow of Events STEP A/S ACTION DATA VALIDATION NOTES xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxx xxxxxxxxxx Figure 1. Use Case Model Constructs Actor Name: Description: Status: Subclass: Superclass: Associations: Problem Domain Concepts System Sequence Diagram Actor names, actor descriptions, use case numbers, use case names, and use case business events, and use case overviews as well as communication-associations between the actors and the use cases Work Product Description Page 1 of 30

2 provides an overview of the functional requirements. The other constructs of the model document the expected usage, user interactions, and behaviors of the system in different styles and depth. 2 Purpose The main purpose of use case modeling is to establish the boundary of the proposed software system and fully state its functional capabilities to be delivered to the users. Other purposes are listed below: Provides a basis of communication between end users and system developers Is the primary driver for estimating the application development effort Provides a basis for planning the development of the releases Allows scheduling of common functionality early in development Allows development of smaller increments while maintaining broad coverage Allows scheduling of complex functionality later in development without changing the code that already exists or having to test for damage to earlier releases Provides a basis for identifying objects, object functionality, interaction, and interfaces Provides the primary basis for defining the user interface requirements Provides a basis for defining test cases Serves as the basis for acceptance testing Provides a basis for producing user support materials, such as user documentation and electronic performance support interventions 2.1 Impact of Not Having This Work Product Use cases describe what the system will do. If a Use Case Model is not produced, there must be some other mechanism of defining the functional requirements and some other way of meeting the goals listed above. 2.2 Reasons for Not Needing This Work Product The Use Case Model should be produced in most engagement contexts. Project situations where use case modeling might be amended or limited are described below: On projects where the user interaction is well understood (e.g., simple conversion), it may not be necessary to develop the more detailed actor-to-system constructs of the model. When the project is substantially based on an existing system or asset, which will be extended and modified incrementally, a requirements delta document may complement a less detailed Use Case Model. If an organization has standardized a particular form of functional specification, it may be expedient to produce one by deriving it from the Use Case Model. Work Product Description Page 2 of 30

3 3 Notation A Use Case Model is documented using both diagrams and text. The graphical notation employed here (see Figure 3) for use case modeling is adopted from Ivar Jacobson, et al (see Section 8, References). The only addition is the use of a distinct symbol to distinguish non-human actors other systems or external hardware from human actors. The textual descriptions are collected in different sections, with a template defined here for each. Video Clerk A Video Clerk who wants to rent a video to a customer will comm unicate with the use case Rent A Video. Rent A Video Figure 2. Communication-Association Diagram Actors are described using the template shown in Figure 4. Actors are used to represent users in specific roles and other systems that interact (use) the system under development. Use cases are described textually using the template shown in Figure 6. A termination outcome decision table can also be used to help describe use cases (see Figure 5). Termination outcome decision tables are an excellent mechanism for communicating terminating outcomes and the conditions under which the outcomes occur. Use termination outcome decision tables when you need to use Boolean logic and/or there are lots of conditions. Use case scenarios are described using the template shown in Figure 7. Use Case scenarios are real (or imagined) world transactions and thus represent examples of system use. Actors and use cases communicate to execute the interaction described in the use case. This communication is modeled as a communicationassociation, shown in Figure 2. The direction of the arrow shows the direction in which the communication is initiated. The Use Case Model contains a set of communication-association diagrams for each actor-use case combination. Symbol <actor name> <actor name> <use case name> <association name> Meaning / Usage Actor: human user Actor: external hardware, machine or system Use Case Association: communication between Actors and Use Cases Association: extendsor uses relationships between Use Cases inheritancerelationships between Actors. Figure 3. Graphical Notation Used in Use Case Modeling The problem domain concepts catalog can be maintained internally within the Use Case Model or external to the Use Case Model. When maintained internally, use the template shown in Figure 11. Use case actor-to-system interactions can be described via the flow of events table (see Figure 8), the system step decision table (see Figure 9) and the system sequence diagram (see Figure 10). For more information about these constructs, see the Development Approach, Advice and Guidance and Glossary (Appendix A) sections. Work Product Description Page 3 of 30

4 Actor Name Brief Description Status Relationships Inheritance Subclass Superclass Associations To Use Cases <The name should indicate the role that the actor will play in using the system. It should make clear whether the actor represents a human user, external hardware, or another system.> < One or two sentences (a paragraph at most) that defines the role that the actor plays in using the system that is being designed.> < Primary or Secondary Actor> <Actors that this actor inherits from.> <Actors that inherit from this actor.> <Use cases that this actor initiates>. Figure 4. Template for Actor Condition Affecting Termination Outcomes: <condition 1> T F F F <condition 2> T F F <condition n> T F Termination Outcomes: <termination outcome 1> <termination outcome 2> <termination outcome 3> <termination outcome n> Figure 5. Decision Table for Use Case Termination Outcomes Work Product Description Page 4 of 30

5 USE CASE #X Subject Area Business Event Actor(s) Use case Overview Preconditions <Use Case Name: An active verb phrase (or gerund phrase) that describes the particular usage of the system. See criteria governing use case granularity for cross-referring nouns used in the use case name.> <A grouping mechanism, used to group use cases> < Business events are triggers that stimulate activity within the business. They are the stimuli that prompt the business to act. Many business events occur at the interface point between the business and one of the external entities that it interacts with. Other business events are internal triggers based on conditions or predefined time intervals. Business events must be atomic (cannot be decomposed into two or more events) and detectable (observable). Furthermore, it is not possible for a business event to have partially happen.> <The actor initiating this use case. See criteria governing use case granularity when using more than one actor.> <Brief description -- one or two sentences -- that describes in a declarative style the overall scope and content of the use case. Does not describe the flow of events, business or data validation rules. See criteria governing use case granularity for cross-referring nouns used in the use case overview.> <Constraints that must be met for the use case to be executed. The system may have to be in a certain state before the initiation of the use case is enabled. This may include required sequencing of use cases; for instance, one or more other use cases may have to have been executed successfully for this use case to begin.> Termination Outcome Condition Affecting Termination Outcome <Alternative ways that the use case may terminate. Sometimes this means successful and unsuccessful and sometimes there are multiple successful ways in which the use case can end.> <termination outcome #2> <condition(s) for termination outcome #2> Use Case Description Use Case Associations Traceability To: Inputs Summary Output Summary Usability Index Use Case Notes < The condition or conditions under which the corresponding termination outcome occurs. Many times there is a straight one-to-one correspondence between termination outcomes and conditions. However, often there are multiple conditions and/or Boolean logic operators needed to express the right conditions. In these instances, a decision table is often useful for communicating the termination outcomes and the conditions under which they can occur.> <A simple, brief description of the series of events (conversation) of the most likely to occur termination outcome (a/k/a main course). Should be expressed in terms of what the actor does and how system responds. Should not be complicated by too many conditionals. In addition, should not include looping.> <A list of other use cases that this use case is extended by or is used by.> <Other related work products, models, or documents that this use case is traceable to. This may include business rules, data validation rules, a traditional functional requirements document, business objectives, GUI sketches/mockups/screens/prototypes, use case scenarios, etc.> <Summary level listing of data input by the actor. Can be all inclusive but doesn t have to be.> <Summary level listing of data output by the system. Can be all inclusive but doesn t have to be.> <How the use case ranked in terms of satisfaction, importance and frequency.> <Information that is not directly part of the use case but arises while working on the use case. For example, questions, actions-items, design notes.> Figure 6. Use Case Template Scenario Number Use Case Number Termination Outcome Scenario Summary Scenario Notes Scenario Description <A sequential number uniquely identifying the scenario.> <The use case number that this scenario corresponds to.> <The termination outcome of the use case that this scenario corresponds to.> <If scenario description is long and complex, a summary of it might also be developed.> <Free-form notes for things like: participants, if this scenario was a real-world occurrence or just make-believe, date developed, how often this scenario occurs relative to the others, etc > <Text describing the scenario. For example, John Smith, rents the movie Gone with the Wind from store #5, register #3 on Friday, March 10, Mr. Smith is a valid customer of XYZ Videos, currently has no other movies assigned to him and has a zero outstanding balance. > Figure 7. Use Case Scenario Template Work Product Description Page 5 of 30

6 Step Actor/ System Use Case Step Action Use Case Step Data Elements Use Case Step Data Validation Usability Considerations 1 Use Case Step Notes Figure 8. Use Case Flow of Events Template Termination Outcome #: Condition Affecting Termination Outcomes: <condition 1> T F F F <condition 2> T F F <condition n> T F System Steps: <system step 1> <system step 2> <system step n> Figure 9. System Steps Decision Table 1 Usability considerations consist of shortcuts and tools currently used to do the step, difficulties in performing the step today, manual steps required to do the step, and other solutions seen to address the step. Work Product Description Page 6 of 30

7 : Actor 1: step 1 (actor) :system Steps: Textual comments describing what actor/system does. Can contain looping and conditional constructs. 2: step 2 (system) 3: step 3 (actor) 4: step n (system) Figure 10. System Sequence Diagrams Business Concept Synonyms Description <concept> <synonyms> <description of concept> Figure 11. Problem Domain Concepts Catalog 4 Example See Appendix B. 5 Development Approach 5.1 Step 1: Determine System Scope and Boundary Identify and Define Actors Start by identifying all the system s key users. The key users are the ones for whom the system is being built in the first place. They should be obvious from the original project s goals and knowledge about the project. A good place to start is any user profiles that may have been developed. This will give you a good idea of the various user sets and insight into their knowledge, skills, and aptitudes. Identify all the other users of the system, including automated systems and users in support and managerial roles. In what general ways will the users be using the system? List the users main expectations with respect to the system. What roles are the users playing when using the prospective system? Create role names for the users from their main expectations. Role names separate the job description of the user from the Work Product Description Page 7 of 30

8 way they are using the system. It allows the roles to be attached to more than one group of users. Examples: Order taker, Troubleshooter, Account Examiner, Account Representative. It may be useful to pretend one is writing a play and needs to come up with role names for the actors. The play metaphor is powerful and useful, as it allows the users to step outside for a moment and describe their job from the outside. Using the play metaphor, the users can introduce players with different personalities and describe the different ways in which they would interact with the system. Characterizing them as in a play allows the users to disengage themselves from known personalities and capture different uses, requirements, and scenarios for the system. Document the role names and descriptions for the role names using the actor template. Identify Use Cases If available, start by reviewing the use cases identified in the business process model. Review the business events. Business events help to focus attention on the stimuli that prompt the business to act. They give the development team a context for the system to be built. These events provide the starting points for business processes and use cases and provide the opportunity to capture information that will be used throughout the system being built. Determine the fundamentally different ways in which each actor uses the system. What are each actor s specific expectations of the system? Cast each expectation in terms of usage (use case). For each usage, fill in the following fields in the use case template: number, business event, initiating actor, name, and overview. On larger systems, use cases can be organized and grouped according to application subject areas. Grouping can be indicated by writing down a subject area of each use case. The subject area is a single word or phrase that indicates the business mechanism or area involved. Examples: Ordering, Billing, Promotions, Pricing, and Security. In an application that stores information about a set of problem domain concepts, the presence of each problem domain concept automatically implies the existence of a minimum set of use cases. This minimum set is colloquially referred to using the acronym CRUDL, which stands for Create, Read, Update, Delete, and List. Instances of any problem domain concept must follow a minimalist life history initiated by a create event, then consisting of a sequence of zero or more update events and terminating with a logical delete event. At any time during this life history, application users may make requests for information (i.e., Reads) to view the details of one specific instance of a problem domain concept, or require a list of all or a selection of stored problem domain concepts. During a first attempt to catalogue the use cases in an application, the use case modeler is advised to assume the presence of at least these five CRUDL types, although not all types may be required by all applications. Apply the criteria governing the proper level of granularity of use cases (Section 6, Validation and Verification). 5.2 Step 2: Get Ready for Design Specify Terminating Outcomes Use cases typically can be divided into a main or basic course and zero or more alternative courses. Sometimes there is a successful basic course and an unsuccessful alternative course. Other times there maybe multiple successful ways in which the use case can end. Brainstorm with users using actual use case scenarios, and determine all the different courses of the use case. Cast each of these courses into terminating outcomes (ways that the use cases can end). Work Product Description Page 8 of 30

9 Specify Conditions Affecting Termination Outcomes List all conditions, controlling factors, or state changes under which the corresponding termination outcome occurs. Often there is a straight one-to-one correspondence between termination outcomes and conditions. However, sometimes Boolean logic operators are needed to express the correct conditionals. In these instances, use a termination outcome decision table for communicating the termination outcomes and the conditions under which they occur. Again, brainstorm with users using actual use case scenarios to determine the conditions. Specify Preconditions List any and all special constraints that must be met for the use case to be executed. These constraints apply regardless of the terminating outcomes. For example, the system may have to be in a certain state before the initiation of the use case is enabled. This may include required sequencing of use cases; for example, one or more other use cases may have to have been executed successfully for this use case to begin. Write Main Course Description Using actual use case scenarios as a guide, write a simple, brief description of the series of events (conversation/interaction) of the most likely to occur termination outcome (a.k.a., main course). This description should be expressed in terms of what the actor does and how the system responds. Do not complicate the description with too much detail about the conditions affecting main course outcome. If necessary, simplify the description by eliminating some or all of the conditionals. Revisit Criteria Governing the Proper Level of Granularity of Use Cases As more detail becomes known, the granularity criteria may dictate partitioning some of the use cases. 5.3 Step 3: Describe Use Case Actor-to-System Interactions Use case actor-to-system interactions can be described via the flow of events table, the system step decision table, and the system sequence diagram. The use case flow of events table describes in detail the conversation that occurs when an actor runs an instance of a use case. It facilitates discovery of common functionality and complex, alternative behavior and is also the primary input used to develop and refine user interface models. A system steps decision table is an extension of the termination outcome decision table. It is used to communicate what the system must do (steps) under what conditions, as well as the steps required for the termination outcomes. The system sequence diagram is a type of interaction diagram that graphically describes the step-by-step actor-system interactions for all termination outcomes. The text on the left side of the diagram describes the individual steps and, if available, can be taken directly from the use case description of the flow of events. These three constructs can all be used together in any combination, or one of them can be used by it to describe the actor-to-system interaction. For some use cases, none of these actor-to-system interaction constructs will be required. For more information about this, see Section 2.1, Impact of Not Having This Work Product and Section 7, Advice and Guidance. Additional information is provided below for the flow of events table. Work Product Description Page 9 of 30

10 Flow of Events Table The flow of events describes all termination outcomes and can include conditionals and looping constructs 2. The intent is to describe the behavior of the system as it should respond to each stimulus received from an actor. In writing the flow of events, it is important to be clear about the starting/initiating stimulus and about all the terminating conditions. Construct conversations between the actor and the system by describing a sequence of actor actions and system responses. Use concrete, specific use case scenarios to analyze this. Write a single flow of events that considers all alternatives. The flow of events must contain the following: how and when the use case begins and ends, when the use case interacts with actors and what information is exchanged, and how and when the use case accesses data or writes data. Record the information passed to and from the system. Be on the lookout for sequences of interactions that are common across use cases. They may be combined to create a separate supporting use case if doing so will simplify the overall structure of the use cases. Common sequences often occur at the beginning and end of the scenario and sometimes in the middle of the scenario. 5.4 Step 4: Restructure and Layer the Use Case Model Initially, a project team should concentrate on (mainly) identifying concrete use cases. Over time, however, the Use Case Model should be restructured and layered. Restructuring the model deals with separating out commonality to avoid redundancy. Uses associations to new abstract use cases are used for this purpose. Refinement of the requirements model with the uses associations is done by identifying and extracting similar parts of the use cases. These similar parts will then be described only once, and any changes to a part will be automatically incorporated in all use cases that share the part. Common parts to be factored out must be the same a good test is that the shared text is identical. Layering the model deals with capturing the basic requirements first and introducing complexity later (see Section 8, References). The resultant model, therefore, consists of layers and, as such, is much easier to assimilate. Extends associations to new abstract use cases are used to layer the model. A layered model also allows us to develop smaller increments while maintaining broad coverage. Plus, these increments can be added to the system without changing the code that already exists or having to test for damage to earlier releases. The extends association is used to model complex and alternative courses that seldom occur or separate subcourses that are executed only in certain cases. After the use cases are defined, review them, checking for commonality, complexity, and variation. Look for common sequences that can be combined into a single subordinate use case. There are two kinds of such sequences: those that are essential to the main logic and completion of scenarios (these often occur at the beginning and end) and those that represent optional or variant extensions of the main scenario (these usually occur in the middle of a scenario). 2 Another approach is to include the step-by-step conversation for the main course termination outcome and the delta for the other termination outcomes. Work Product Description Page 10 of 30

11 Create new abstract use cases for the identified commonality and significant variation. Note that by definition, simple applications should not have many extends associations. Create a reference to the use case association in both the concrete (uses, extended by) and abstract use cases (used by, extends). For each use case that is to be inserted into another, the position in the use case where it is to be inserted must be clearly stated in the inserting use case (not in the original use case). Be careful with creating the uses and extends. A restructured and layered model should be easier to understand, not more difficult. 6 Validation and Verification The single most important item to validate and verify in the Use Case Model is the level of granularity of the use cases. Use the following criteria for this purpose. Criteria Governing the Proper Level of Granularity of Use Cases The granularity criteria correspond to the concept of Logical Transaction used for estimating: Used by a single actor unless the use case is a request for information 3 type use case. Entails input across the system boundary, processing within the system and output back across the system boundary. Is triggered by a unique and atomic business event or is an individual request for information. Note that a business event can be associated with many use cases. When complete, must leave the application s information in a self-consistent state (entirely successful or fail in its entirety). Is only directly acting on or requesting information from one or more entries in the problem domain concepts catalog and is entirely consistent with the definition contained in the catalog. 4 Other items to check are listed below: Check the Use Case Model for functional content. The Use Case Model should completely describe the system behavior. Any behavior that is not described has not been specified and will probably not be built. Check the Use Case Model for readability. The readers of the Use Case Model should be able to understand and identify with the system being described. The customer should be able to understand what the system will do. The development staff should understand what they have to build. 3 Requests for information are the consequences of the existence of the application. If users wish to remember information about business events, that information must be stored by the application. In order to retrieve some of the stored information, a request (use case) must be made. Therefore, the single actor rule does not apply to request for information type use cases. In addition, request for information type use cases are not always associated to a business event. 4 One of the most important aspects of the Use Case Model is to be rigorous and precise in the use of nouns within the model. Do not allow the name, overview, or description fields of the use case template to refer to nouns that are not defined in the problem domain concepts catalog. Work Product Description Page 11 of 30

12 Check to see that all actors have been identified and each is associated with at least one use case. If the actors defined are not associated with any use cases, then it is likely that some use cases have been missed. Check that all use cases interact with at least one actor. If a use case cannot be associated with an actor, it is likely that the use case is out-of-scope or external to the system. Check that the uses and extends associations have been used judiciously to restructure and layer the overall model. Uses associations should be limited to at most two levels; i.e., a use case might use a use case that uses another. 7 Advice and Guidance The following guidance is suggested: Use Case Modeling is an iterative process and, as such, the activities described in Section 5, Development Approach, do not follow a strict linear process. You will find that the number of actors and use cases will fluctuate during the project. In addition, at any given time, the level of detail of the use cases will vary as well. For example, the project team may have just begun describing some use cases with a number, name, business event, and overview while others will have already been fully described. It is also important to note that not all projects require the same completeness and formality of the Use Case Model. Projects and individual use cases rarely require all constructs of the model or even all fields of the various templates. Choosing how to describe which constructs to use on a given project or for a given use case is an important decision that only an experienced architect can make. In the first phase in the development life cycle, the goal should be to identify and define actors, use cases, and actor-use case relationships. Actors should be identified and defined via the actor template. Here, all template fields should be utilized. Use cases should be described via the number, name, business event, actor, and overview fields of the use case template. The objective here is not to identify and define all possible use cases, but to establish a breadth-first description of the functional requirements of the system. This typically will be about 60% to 80% of the use cases. After a breadth-first description of the functional requirements has been established, the goal should be to analyze a subset of those requirements in more detail so that decisions on technology, architecture, and user interface design can be made. The subset should include: a sampling of use cases from all parts of the system to ensure that a global view is maintained, key use cases that would most likely affect the system architecture or the user interface, and have significant impact on user performance, and high risk uses cases that have either a high priority or high frequency of use. Analyzing the requirement in more detail here means describing the terminating outcomes, conditions affecting terminating outcomes, preconditions, and the main course description for all use cases within the subset. Normally in the construction phases of the project, a fairly robust subset of all the use cases in that release are described in detail. This means that most of the use case template fields should be developed (filled-in), and the actor-to-system interaction should be described through one or more of the constructs presented earlier. There could be reasons on some projects not to do this, but it would be unusual on a large system. If the Project Manager decides not to do this on large projects, he or she will need to be able to justify this. However, the key point is what makes up this fairly robust subset. Since we now have fairly granular use cases, it is not required to go to the full level of detail for every single granular use case. Some use cases will be so similar to others that it wouldn t be worth the effort. This is similar to the development of object interaction diagrams. The use case flow of events table should be developed for use cases that have a high importance/priority rating or low satisfaction rating, that are used frequently, or that have complex, not well understood actor-system interactions. Work Product Description Page 12 of 30

13 A use case should express what happens from the user s point of view. The details of how the system works internally are irrelevant to a use case. Therefore, a Use Case Model does not describe internal structure, internal mechanisms, or internal algorithms. Avoid functional decomposition. Start concretely by walking through specific use case scenarios. Use active verb phrases, increasing readability as well as clarifying responsibilities for described behavior. Make sure customers and users are heavily involved. Simple, clear requirements encourage commitment and enthusiasm on the part of customers and end users. This is often a prerequisite for overall success. Choose an appropriate level of detail for the Use Case Model, detailed enough to the meet the project goals while remaining within the budgeted time and cost. In some applications, processing occurs after the system has monitored or polled and found a specific condition or state. In these types of uses of the system, we say that the system is acting on behalf of a user in a system administration or system management role. Therefore, the actor would be a System Administrator or System Manager. The one actor rule within the criteria governing granularity should be considered a rule of thumb. Although there may be times when it would be proper for more than one actor to initiate a use case, this should be considered the exception and not the rule. 8 References External TextBook Style References Ivar Jacobson, I., et al. (1992). Object-Oriented Software Engineering A Use Case Driven Approach. Addison-Wesley. Ivar Jacobson is the inventor of use cases. (This is THE classic reference for use cases. This book is also good reference for general object-oriented concepts.) Texel, P. P., and Williams, C. B. (1997). Use Cases Combined with Booch OMT UML. Upper Saddle River, NJ: Prentice Hall. ISBN X Scenario-Based Design, Ed: Carroll J. M. (Ed.). (1995). New York: John Wiley & Sons. ISBN (See chapters by Wirfs-Brock on Responsibility Driven Design, Jacobson on Use Cases.) External Article Style References Wirfs-Brock. (November/December 1993). Designing Scenarios: Making the Case for a Use Case Framework. Smalltalk Report. (Wirfs-Brock states here that expanded use case descriptions should include: 1) steps and logical sequencing of actions that must be performed by the system, 2) a description of necessary information that must be supplied from the actor, 3) data validation or business constraints, 4) formats of reports that are generated, and 5) timing of and contents of any significant system feedback. Goes on to say that the expanded description is important to ensure that the main course is indeed the most common task that users want to perform. Expanded description also helps find preferred conversation patterns. ) Wirfs-Brock. (February 1994). The Art of D-esigning Meaningful Conversations. Smalltalk Report. Jacobson. (July/August 1994). Basic Use Case Modeling. ROAD. (This is a short and basic introduction to use case modeling. Includes the concept of use case views of the object model and a definition for what a good use case is.) Work Product Description Page 13 of 30

14 Jacobson. (September/October 1994). Basic Use Case Modeling Continued. ROAD. (Discusses here mainly the importance of the extends association. Points out that extends association allow us to introduce requirements in layers. Includes real world examples of how using extends associations reduces development cost.) Rumbaugh. (September 1994). Getting Started: Using Use Case to Capture Requirements. JOOP. (This is another basic introduction to use case modeling. Includes a good example (assign seat in airline system) and also states that analysis should use a combination of direct domain analysis and use cases.) Jacobson. (March/April 1995). Modeling with Use Cases: A Growing Consensus on Use Cases. JOOP. (States here that, objects should be simply derived from the use cases. This derivation is based on some simple, yet fundamental principals of what makes an application changeable and extensible. Mapping between use cases and objects is a key design transformation that forms the basis for traceability. The object designer must define object responsibilities such that it is consistent and behaves as needed in every use case in which it participates. Defines extends as, use extends when you want to add functionality to a complete, meaningful concrete use case. Also discusses other approaches: Rumbaugh, Booch, Wirfs-Brock, and object behavior analysis.) Jacobson. (June 1995). Formalizing Use Case Modeling. JOOP. (States here that, text descriptions that informally describe the dynamic behavior between an actor and a use case can be formalize with interaction diagrams. ) Jacobson. (September 1995). A Confused World of OOA and OOD. JOOP. (Identifies here two ways in which OOA is completed data driven (OMT, Booch, Fusion) and behavior driven (OOSE & Wirfs-Brock). Data-driven identifies entities of the real world of the problem domain and assigns behavior and attributes. Behavior driven, objects fall out of use cases. Also discusses OOSE, business modeling, and how you accomplish maintainability and reusability (object types). (March/April 1998). Building an Object Process Around Use Cases. ROAD. (Discusses the stair and fork patterns between control and entity objects.) Internal IBM References IBM OTP. (1995). Methodology for Object-Oriented Reuse-based Engagements (MORE) - Use Case Modeling. (Note that the MORE methodology predates WSDDM. This is a very good but long (70+ pages) document on use case modeling. The author was once a consultant and an instructor for Objectory (Jacobson s methodology) and has considerable experience with use case modeling. 9 Estimating Considerations The main factors affecting effort for this work product are: Available documentation Process model, interactions with system Number of users to interview Number of JAD sessions Number of sites Expected number of use cases/scenarios Expected number of classes or entities Number of actors Work Product Description Page 14 of 30

15 Examine available material: If there is a lot, and some of it is directly usable, you need to factor that into your estimate. The context is assumed to be a greenfields application using facilitated requirements gathering through workshops (JADs) of candidate use cases and high level use cases. Detailed use cases are performed by business analysts through interviews, or additional JADs as required. Expect to take three passes to reach completion of detail for a use case, and validation of the use case model. The number of use case that can be covered in a JAD depends on whether high-level use cases are being produced or detailed ones. Use cases are assumed to be developed to the fine level of granularity specified in this work product (traditional use cases take 4-5 times longer). To develop a candidate use case list: Allow.25 hours for every interaction with the system identified in the business process model. To develop a high level use case, showing just termination outcomes, and without a structured flow of events: Allow 1 to 2 hours hour per high-level use case. To develop a use case without data elements and data validation rules, but having full specification of the flow of events: Allow 1 to 2 days of business analyst effort for a greenfields application. Allow.5 to 1 day of business analyst effort for an application for which a thorough traditional functional specification has been produced to IEEE standards. Allow.5 days to fill in remaining detail. The more outcomes there are, and the more paths there are, the longer each use case will take. Allow the following additional elements for the requirements gathering process. 1. Interview sponsor and other key executives. Allow.5 day each including prep and write-up. 2. Prepare basic material to familiarize users with the JAD. Allow.5 days 3. Prepare for JAD. Allow 3 days for 1st in a project, 2 days subsequently. 4. Each JAD runs typically 3 days for 2 facilitators. Allow 6 days effort per typical JAD. (Allow for any optional work products to be produced in use case model) 5. Wrap-up and document JAD. Allow 1.5 days. 6. Build Use Case model. This should include review of identified classes. Allow 2 days per JAD. One day for Use Case model, one day for OM. 7. Review. Allow half-day workshops. 8. Refine and Rework. Assume as a sanity check on the total that it takes 1-3 weeks to sort out the implications of each business object. Work Product Description Page 15 of 30

16 10 Revision History Date of this release: Date of next revision: Revision Number Revision Date Summary of Changes Changes Marked? Version 3.0 January 2000 MIFP published version no changes. Version 1.3 December 1999 Removed context information from Estimating Considerations. N Version 1.2 September 1999 A new template was applied, the document was edited for grammatical errors, style and content and Estimating Considerations were added. Version 1.1 February 1999 Updated content Version 1.0 September 1999 Base Version Work Product Description Page 16 of 30

17 11 Appendix A: Glossary Abstract Use Case Abstract use cases are not instantiated directly by an instance of an actor; instead they are generalized use cases created for the purpose of being used in a uses or extends association with other concrete use cases and are instantiated by those concrete use cases. These types of use cases are used to restructure and layer the Use Case Model. Actor An actor is anything external to the system under development that interacts with it. An actor can be an instance of a user (specific human) or another system. An instance of an actor can create instances of uses cases. Note that actors are types. That is, a registrant actor (see Section 4, Example) represents registrants in general and not a particular registrant. Actor types are not usually job titles. Instead, they are prospective users playing a specific role with the system. Several users can play the same role, and one user can perform several roles. An actor (descendant) may have an inheritance association to another actor (ancestor) indicating that the descendant inherits the role the ancestor can play. The are many reasons why actors are used with use cases. Some of these are listed below: Defining actor types allows us to define use cases in terms of specific expectations (uses) of the system. In other words, it allows us to narrow the expectations to specific roles in which a human user would be using the system. Defining actors helps to identify the system border this is what is inside the system and what is outside the system. Defining actor types helps us show user training needs for particular aspects of the system. Defining actor types helps us show which security needs are required for which user types. Finally, it is important to remember that since the system under development has not been placed into the user environment, user types/job titles probably do not exist specifically for the new system. After the new system is placed in the user environment, it is not unlikely that job titles/user types will be redefined and possibly reflect the actor types defined in the Use Case Model. Business Events Business events are triggers that stimulate activity within the business. They are the stimuli that prompt the business to act. Many business events occur at the interface point between the business and one of the external entities that it interacts with. This might be considered a perturbation across the membrane that surrounds the business, separating it from its environment. For example, an inquiry may trigger activity that leads to an order, or a trouble call may trigger dispatch and repair activity. Other business events are internal triggers based on conditions or predefined time intervals. For example, an inventory level may trigger a reorder point, or the 15 th of the month may trigger an automatic billing cycle. Business events must be atomic (cannot be decomposed into two or more events) and detectable (observable). Furthermore, it is not possible for a business event to partially happen. Concrete Use Case A concrete use case is instantiated directly by an instance of an actor. These types of use cases are the ones we typically focus on identifying early in the development life cycle. Work Product Description Page 17 of 30

18 Extends Use Case Association The extends use case association may be employed to separate complex and alternative behavior from a single use case, creating a new abstract use case from this extracted behavior. Extends associations are used in this way to layer the Use Case Model. Extensions can be described in a very simple way, and changes and additions of functionality are more easily made. Figures 12 and 13 illustrate use of the extends association. Create sales order can be extended by customer credit limit exceeded extends Create Sales Order Customer Credit Limit Exceeded Figure 12. Extends Association Example 1 Flight check in can be extended by upgrade class extends Flight Check In Upgrade Class Figure 12. Extends Association Example 2 Primary Actor Primary actors are those roles for which the system is being built to serve. They are associated with sets of use cases that reflect the primary functions of the system. Problem Domain Concepts Catalog A concept catalog consists of a list of terms and concepts that provide a concise, common vocabulary and consensus definition of domain terminology. The Use Case Model must make comprehensive use of either an internal problem domain concepts catalog or other external work product. 5 The catalog is used for maintaining consistency across concepts and use cases, including details of naming and semantics. Secondary Actor Secondary actors have associated use cases for supporting the system in providing its primary functions. These roles will typically be for maintaining and customizing the system, such as a system administrator. System Sequence Diagram The system sequence diagram is a type of interaction diagram that graphically describes the step-by-step actor-system interactions for all termination outcomes. Like the flow of events, the system sequence diagram also can include conditionals and looping constructs. Use Case Associations Use case associations are relationships between use cases. These relationships are used to restructure and layer the Use Case Model, so it is easier to understand and modify. This process minimizes dependencies, reduces complexity, and eliminates redundancies through refactoring. There are two types of use case associations: extends and uses. 5 Examples of external work products that may be used for this purpose include classified business terms, object type descriptions and business object model. Work Product Description Page 18 of 30

19 Use Case Flow of Events Use case flow of events represents the conversation that occurs when an actor runs an instance of a use case. Flow of events are specified for several reasons. First, they facilitate discovery of common functionality and complex, alternative behavior (see use case association and abstract use case). Flow of events also is the primary input for understanding conversational patterns between a human actor and the system and is used to develop and refine user interface models. Use Case Scenario Use case scenarios are instances of use cases. That is, they represent real (or imagined) world transactions (logical) with specific values for entities used in the business. When discovering use cases, it is often helpful to first discuss with users concrete situations rather than conceptual generalizations. The text below is an example of a use case scenario in a video rental application. John Smith, rents the movie Gone with the Wind from store #5, register #3 on Friday, March 10, Mr. Smith is a valid customer of XYZ Videos, currently has no other movies assigned to him, and has a zero outstanding balance. Use Case Subject Area Use case subject area is a grouping mechanism for organizing use cases. Large systems can contain more than 100 use cases. To organize this large number of use cases, a key word can optionally be assigned to each use case. The key word assigned usually represents a business domain subarea. Uses Use Case Association The use case association may be employed when two or more use cases have common behavior. This relation is called uses because it resembles some kind of inheritance but does not have exactly the same semantics as inheritance in object-oriented analysis/design. It typically enables descriptions of abstract use cases to be used in the descriptions of concrete use cases. Common activities that can be shared across use cases suggest the uses association. Abstract use cases can be used by other abstract use cases. It is Verify Membership difficult to state exactly when there is no point in extracting more uses uses abstract use cases. A useful heuristic is that uses should be limited uses to, at most, two levels; i.e., a use case might use a use case that Reserve A Video Rent A Video uses another. Deeper nesting of uses should be questioned and carefully scrutinized, because it may reflect a mistaken Add Spouse Membership understanding of the purpose of Figure 13. Uses Association Example uses and will make the Use Case Model harder to understand and to walkthrough in order to validate it. Figure 14 illustrates use of the uses association between use cases to share a common part of the flow of events. Work Product Description Page 19 of 30