Chapter 6 USE CASES Objectives Identify and write use cases

Chapter 6 USE CASES Objectives Identify and write use cases
“The indispensable first step to getting the things you want out of life: decide what you want.” - Ben Stein Objectives Identify and write use cases Use the brief, casual and fully dressed formats Apply tests to identify suitable use cases Relate use case analysis to iterative development

Feature Lists vs. Use Cases
Older methods of detailing requirements tended to have many pages of detailed feature lists. Usually the details could not be seen in context. Current philosophy is to use a higher level of detail with use cases instead of a list. Use cases focus on who the key actors are, their goals, and common tasks. (High level System Feature Lists are still acceptable when they can give a succict summary of the system and ‘n some feature-driven applications, such as application servers, database products, middleware or back-end systems.) ID Feature FEAT1.9 The system shall accept entry of item identifiers. . . . FEAT2.4 The system shall log credit payments to the accounts receivable system. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Cases Writing Use Cases is not a specifically OO artifact – they are simply written stories: they are stories of using a system However, they are a best practice for elaborating and understanding requirements. Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals. Use cases keep it simple (KISS) They emphasize goals and the user perspective. … Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Example Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment info, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Case Relationships
Use cases, in turn, influence many other analysis, design, implementation, project management and test artifacts. Domain Model Business Model VISION GLOSSARY SUPPLEMENTARY SPECIFICATION Use Case Model Requirements Interaction Diagrams Design Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.1 Sample UP artifact influence
? Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Definitions An actor is something with behavior, such as a person (identified by role), computer system, or organization. Ex. Cashier A scenario (use case instance) is a specific sequence of actions and interactions bw actors and the system. It is one particular story of using a system or one path through the use case. A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. A Use Case Model is the set of all written use cases. It is a model of the system functionality and environment. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Three Types of Actors Primary Actor Supporting Actor Offstage Actor
Has goals to be fulfilled by system Emphasis is on the primary actor for the use case. Ex. Cashier Supporting Actor Provides service to the system. Other actors are listed as stakeholders. Ex. Automated Payment Authorization Service. Offstage Actor Interested in the behavior, but no contribution Ex. Government Tax Agency. In diagrams, Primary actors go on the left and others on the right. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Cases are not diagrams !
Use Cases may have a diagram associated with them, and a use case diagram is an easy way for an analyst to discuss a process with a subject matter expert (SME). But use cases are primarily text. The text is important. The diagram is optional. Use case modeling is primarily an act of writing text, not drawing diagrams. Capture the specific ways of using the system as dialogues between an actor and the system. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use-Case Driven Development
Requirements are primarily recorded in the Use Case model. Iterations are planned around implementing particular Use Cases. Use Case Realizations drive design. The team designs collaborating objects and subsystems in order to perform or realize the use cases. Use Case often influence the way user manuals are organized. Functional or system testing corresponds to the scenarios of use cases. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Working with Use Cases Determine the actors that will interact with the system. We cannot understand a system until we know who will use it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system Examine the actors and document their needs. For each separate need, create a use case. During Analysis, extend use cases with interaction diagrams. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Actors or Use Cases First?
Because you have to understand each part of Use Cases, the parts are presented separately. But those who create use cases switch back and forth. The text describes use cases substantially before paying attention to actors. Each specification must be testable Write from actor’s perspective, in actor’s vocabulary Typically, both actors and use cases are identified early and then examined to see if more use cases can be found from the actors, or more actors found by examining the use cases. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Guideline: Emphasize Goals
Seeing requirements as identifying tasks to be done has a strong bias toward reproducing the existing system, even when it is being replaced because it is seriously defective. Investigating goals rather than tasks and procedures improves information gathering by focusing on the essence of requirements—the intent behind them. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.2 Primary actors and goals at different system boundaries.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Naming Use Cases Appropriate use case names are very important. Because they are selected early, they tend to set the direction for the entire project. Must be a complete process from the viewpoint of the end user. Usually in verb-object form, like Buy Pizza Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the system Golden Rule: Each use case should have a name that indicates what value (or goal) is achieved by the actor's interaction with the system. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Quick Test: Use Case Name Examples
Naming Use-Cases Quick Test: Use Case Name Examples Purchase Concert Ticket Purchase Concert Tickets Purchase Ticket Ticket Purchase Ticket Order Pay for Ticket Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Case Name Examples Naming Use-Cases
Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure, not process) Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Naming Use-Cases CRUD Examples of bad use case names with the acronym CRUD. (All are procedural and reveal nothing about the actor’s intentions.) C - actor Creates data R - actor Retrieves data U - actor Updates data D - actor Deletes data Collapse CRUD into one CRUD use case, idiomatically called Manage <X>. Ex. Manage Users use case. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Singular or Plural This is usually determined by context.
Naming Use-Cases Singular or Plural This is usually determined by context. There is a preference for the simplest form, but most common form can be better. In the example of concert tickets, most people buy more than one, but a significant number buy only one. At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Case Template Name Primary Actor Preface Scope
Level: user-goal or subfunction Stakeholders and Interests Preconditions Success Guarantee Main Success Scenario Extensions Special Requirements Technology and Data Variations List Frequency of Occurrence Miscellaneous (such as open items) This is the basic format used in the text and in Alistair Cockburn’s Writing Effective Use Cases (Addison Wesley, 2000, ISBN ). See also Preface Optional items Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

User-goal level Subfunction level A complete process from the
view point of a user to meet a goal of the user, roughly corresponding to an elementary business process. Subfunction level Details steps to support a user goal. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Define Actors Actors should not be analyzed or described in detail unless the application domain demands it. Template for definition: Name Definition Example for an ATM application: Customer: Owner of an account who manages account by depositing and withdrawing funds Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Preconditions and Postconditions
Preconditions are anything that must always be true before beginning a scenario is a precondition. Preconditions are assumed to be true, not tested within the Use Case itself. Ignore obvious preconditions such as the power being turned on. Only document items necessary to understand the Use Case. Success Guarantees (or Postconditions) state what must be true if the Use Case is completed successfully. This may include the main success scenario and some alternative paths. For example, if the happy path is a cash sale, a credit sale might also be regarded a success. Stakeholders should agree on the guarantee. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Scenarios The Main Success Scenario, or “happy path” is the expected primary use of the system, without problems or exceptions. Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Documenting the Happy Path
The Success Scenario (or basic course) gives the best understanding of the use case Each step contains the activities and inputs of the actor and the system response If there are three or more items, create a list Label steps for configuration management and requirements traceability Use present tense and active voice Remember that User Interface designers will use this specification Note: Do not use the term “happy path” in formal documents. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Extensions (Alternative Flows)
Extensions or Alternative Flow Use Cases allow the specification of Different ways of handling transactions Error processes Sections are convenient way to handle alternative courses of action Sections are a segment of a use case executed out of sequence Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Two Parts for Extensions
Condition Describe the reason for the alternative flow as a condition that the user can detect Handling Describe the flow of processing in the same manner as the happy path, using a numbering system consistent with the original section. 3A. Condition: If [actor] performs [action] the system … Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Documenting Extensions
Use same format as Happy Path Document actions that vary from ideal path Include error conditions Number each alternate, and start with the condition: 3A. Condition: If [actor] performs [action] the system … If subsequent steps are the same as the happy path, identify and label as (same) Steps not included in alternate course are assumed not to be performed. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Special Requirements If a non-functional requirement , quality attribute, or constraint affects a use case directly, describe it as a special requirement. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Technology and Data Variations List
Often there are technical differences in how things are done even though what is done is the same. These things can be described in the Technology and Data Variations List. For example, if a card reader cannot read the magnetic stripe on a credit card, the cashier might be able to enter it on the keyboard. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Types of Use Cases High Level Use Case (Brief)
Name, Actors, Purpose, Overview Expanded Use Case (Fully Dressed) Add System Events and System Responses Essential Use Case (Black Box) Leave out technological implications Ex. The system records the sale. (no mention of database etc.) Concrete Use Case (White Box) Specify technology Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Guideline: Defer Decisions
By using essential use cases as long as possible, and only using real use cases during module design, you allow time to understand the problem before you create a solution. Premature use of real use cases often confirms existing technology when a better technology might be available. Define the problem fully before you start to define a solution. Any work that you do on the problem domain tends to increase the range of possible solutions, while work in the solution domain limits your choices. You want to be certain that the problem domain is large enough to hold some good solutions and hopefully an ideal solution before you start to narrow your choices. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Contrasting Examples Essential Style: Concrete Style: ...
Administrator identifies self. Systems authenticates identity. … Concrete Style: Administrator enters ID and passsword in dialog box (See Picture 3). System authenticates Administrator. System displays the “edit users” window. (See Picture 4) Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Technology Types of Use Cases
The distinction between an essential (black box) use case that leaves out technology and a real (white box) use case that includes technology is fundamental. For example, in an Automated Teller Machine, an essential use case can mention identification or validation, but only a real use case can mention a key pad or card reader. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Expanded Essential Use Cases (Fully Dressed Use Cases)
Types of Use Cases Expanded Essential Use Cases (Fully Dressed Use Cases) Purpose: to allow the system designer and client to visualize the flow of actor actions and system responses. From this the client will understand how users will use the system, and the designer will be able to write pseudocode for each function. In addition, it is possible to use this document to anticipate opportunities for user error, which must be accounted for in the final system. Definitions: What it is: an analysis document which describes in detail the elements of functions identified in a High Level Use Case. What is is not: Expanded Essential Use Cases are not graphical drawings. They do not include stick figures, boxes representing the system, or any other icons found in a High Level Use Case although they may be associated with one. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Expanded Essential Use Cases
Types of Use Cases Expanded Essential Use Cases How to make one: Step 1: Name the Use Case (system function, e.g. “enter timesheet information”). Step 2: Identify the Actor(s) involved. Step 3: Describe the Intent of the Use Case in language the client will understand. Step 4: Identify the Assumptions and Limitations relevant to this Use Case and other Use Cases which the current one might extend or build upon. Step 5: Specify the ideal flow of actions (using two columns, if you like) labeled “Actor Actions” and “System Responses.” Number each step. This constitutes the Happy Path for this Use Case. Step 6: Identify opportunities for user error and create an Alternative Path to handle each. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Note (from page 68 of text)
Types of Use Cases Note (from page 68 of text) The example on pages of the text of a fully dressed use case is very detailed and contains just about everything you could put into a use case. It is that detailed mainly for instructional purposes. Almost all use cases are much smaller, usually a page or two. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Segmentation When a use case is repeated, you don’t want to repeat the contents. For example, an alarm clock might show the same display when you are setting the current time and when you are setting the wake-up time Separate out the “Display Time” use case and refer to it in both use cases Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Extension Use Cases Users appreciate simplicity, so most use cases leave out alternate courses You can do this by extending the use case while leaving the original use case alone Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Warning Use cases should not be misused to imitate function specification by successive iteration Don’t refine them until the program is fully specified The uses relation should only be used when the same scenario is encountered more than once Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Cases are always wrong!
Written documentation gives the illusion of authority and correctness, but it is an illusion. Use cases give a preliminary understanding that users and developers can discuss and agree on. But there should be constant feedback from customers in the development process to correct missing information and misinformation before it jeopardizes the functionality of the program. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.3 Partial use case context diagram
NextGen POS Manage Users . . . Cashier System Administrator actor use case communication system boundary Payment Authorization Service «actor» Tax Calculator Accounting alternate notation for a computer system actor HR System Cash In Sales Activity Manage Security Analyze Activity Customer Manager Process Sale Handle Returns Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.4 Notation suggestions AND Alternate actor notation
Payment Authorization Service Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.6 Use case diagram (“context diagram”) for Monopoly system.

Use Case UC1: Play Monopoly Game
Scope : Monopoly application Level : user goal Primary actor : Observer Stakeholder and Interests: Observer: wants to easily observe the output of the game simulation. Main Success Scenario: 1. Observer requests new game initialization, enters number of players. 2. Observer starts play. 3. System displays game trace for next player move Repeat Step 3 until a winner or Observer cancels. Extensions: *a. At any time, System fails: 1. Observer restarts System. 2. System detects prior failure, reconstructs state, and prompts to continue. 3. Observer chooses to continue. Special Requirements: Provide both graphical and text trace modes. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Fig. 6.7 Process and setting context for writing use cases.

Association Relationship
An association is the communication path between an actor and the use case that it participates in It is shown as a solid line It does not have an arrow, and is normally read from left to right Here, the association is between a Modeler and the Create Model use case Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Relationships in Use Cases
There are several Use Case relationships: Association Extend Generalization Uses Include Most Use Cases have only associations. Use other relationships sparingly. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Extend Relationship Extend puts additional behavior in a use case that does not know about it. It is shown as a dotted line with an arrow point and labeled <<extend>> In this case, a customer can request a catalog when placing an order. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Uses Relationship When a use case uses another process, the relationship can be shown with the uses relationship This is shown as a solid line with a closed arrow point and the <<uses>> keyword Here different system processes can use the logon use case Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Include Relationship Include relationships insert additional behavior into a base use case. They are shown as a dotted line with an open arrow and the key word <<include>> Shown is a process that I observed in an earlier career. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Use Case Example: Alarm Clock
This is a contrived example, to show many relations. Your diagrams should be simpler. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Chapter 7 OTHER REQUIREMENTS
“Fast, Cheap, Good: Choose any two.” - anonymous Objectives Show Supplementary Specification, Glossary, Vision & Business Rules Compare and contrast system features with use cases Define quality attributes

Introduction While the primary requirements of a computer system tend to be the functional requirements, i.e.,the list of activities that the system must perform, it is also necessary to capture an number of other requirements to build a system, called non-functional requirements. in a Vision Statement, Glossary, Business (Domain) Rules and Supplementary Specification. Produce only the required (or enough) documentation to produce the desired results efficiently and effectively. Documentation costs money and takes time. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Other Requirement Artifacts
Supplementary Specification Captures and identifies other kinds of attributes, such as reports, documentation, packaging, supportability, licensing, and so forth. Glossary Captures terms and definitions; it can also play the role of a data dictionary. Vision Summarizes the `vision` of the project – an executive summary. Business Rules (or Domain Rules) Capture long-living and spanning rules or policies, such as tax laws, that transcend one particular application. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Vision When someone joins the project, it is useful to be able to say : “Welcome! Please go read the 7-page Vision at the project web site.” It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

The Vision The Vision serves to communicate to project sponsors and key stakeholders the reasons for the project, the problems to be solved, a description of the stakeholders and their needs, Root problems and goals, along with a description of the proposed solution. It includes the core requirements and becomes the contractual basis to develop further requirements. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Topics for a Vision Product Overview System Features
Introduction Positioning Business Opportunity Problem Statement Product Position Alternatives and Competition Stakeholder Descriptions Market Demographics Non-user Interests User Interests Key high-level goals and problems for stakeholders User-Level Goals User Environment Product Overview Product Perspective Summary of Benefits Assumptions and Dependencies Cost and Pricing Licensing and Installation System Features Other requirements and constraints See Section 7.6 NexGen Example Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Why system features in Vision?
Use cases are not the only way to describe functional requirements. Sometimes a succinct list of key functional requirements, called system features, will give a better immediate grasp of the problem and proposed solution. A system feature is an externally observable service provided by the system which directly fulfills a stakeholder need. Features are behavioral functions a system can do. They should pass the linguistic test: The system does <feature X>. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Glossary The Glossary captures terms and their definitions in the business domain supported by the system. Be careful. Even simple terms may mean different things to different stakeholders and need to be defined. The Glossary can also perform the role of a Data Dictionary, or be supplemented by one. Data Dictionary records data about the data, that is metadata. Aliases relationships to other elements Description range of values Format (type, length, unit) - validation rules See Section 7.8 NexGen Example Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Supplementary Specification
The Supplementary Specification captures such requirements as documentation, supportability, packaging, licensing and many of the “-ilities” of systems. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Supplementary Specifications
Common Functionality Logging Error Handling Pluggable Business Rules Security Usability Human factors Reliability Recoverability Performance Supportability Adaptability Configurability Implementation Constraints Purchased Components Free Open Source Components Interfaces Noteworthy hw and interfaces Software interfaces Application-specific Domain Rules Legal Issues Info in Domains of Interest Pricing Credit and Debit Payment Handling Sales Tax Item Identifiers See Section 7.4 NexGen Example Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

More Specifications Reports Operating Systems Networking Systems
Process Tools Development Tools Design Constraints Internationalization Standards Physical Environment Operation Rules Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Domain Rules Domain or Business Rules are not functional requirements.
Domain Rules tell how the business works, while functional requirements tell how the system works. Company policies, the laws of physics, and government regulations are examples of Domain Rules. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Industry Domains Most computer consulting firms organize their staff by industry, so that they can develop application specific knowledge that will be useful to the companies hiring them. In New Jersey, most consulting companies have at least a Telecommunications Practice and a Pharmaceutical Practice. Other areas might include Retail, Insurance, Wholesaling, Light Manufacturing, and Electric Utilities. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Knowledge Domains In addition to Industry specific knowledge, there are many areas of knowledge that apply across a number of industries. The most thoroughly specified of these knowledge domains is accounting. Others might include inventory, scheduling, and queuing. Each has a body of specific knowledge that specialists know well. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Guidelines Should we analyze these thoroughly during inception?
Reliable Specifications: An Oxymoron? Should these artifacts be at the project web site? Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Requirements Reliability
Never assume that requirements are completely understood, adequately captured, effectively described, or reasonably complete. Requirements discovery and scope creep tend to occur throughout the software development process and even after the system is put into production. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

UML Diagrams in Inception
Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text. Most diagramming occurs in the Elaboration Phase. Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Process: Evolutionary Requirements in Iterative Methods
Discipline Artifact Inception Elaboration Construction Transition Iteration-> I1 E1…En C1…Cn T1..T2 Business Modeling Domain Model s r Requirements Use-Case Model Vision Supplementaty Specification Glossary Business Rules Design Design Model Sw Arch Model Data Model Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005

Chapter 6 USE CASES Objectives Identify and write use cases

Similar presentations

Presentation on theme: "Chapter 6 USE CASES Objectives Identify and write use cases"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 6 USE CASES Objectives Identify and write use cases

Similar presentations

Presentation on theme: "Chapter 6 USE CASES Objectives Identify and write use cases"— Presentation transcript:

Similar presentations

About project

Feedback