book

Use Case Modeling

by Kurt Bittner, Ian Spence

August 2002

Intermediate to advanced

368 pages

9h 25m

English

Addison-Wesley Professional

Read now

Unlock full access

What Are “Use Cases” All About?WHO SHOULD BE INTERESTED IN USE CASES?How To Read This BookAcknowledgments
Actors and Use CasesUse-Case DiagramsThe Relationship Between Use Cases and RequirementsTypes of RequirementsFunctional and Nonfunctional RequirementsThe Role of Use CasesUse Cases Place Software Requirements in ContextTo “Use Case” or not to “Use Case”When Are Use Cases Useful?Use Cases Provide a Conceptual Model of the SystemUse Cases Describe How the System Is Used and What It Does for Its StakeholdersDoes Everything the System Does Have to Be Described in a Use Case?General Principles of Use-Case ModelingUse Cases Do Not Exist in IsolationUse Cases Are a Synthetic Rather Than an Analytic TechniqueRules of ThumbSummary
The Use-Case ModelThe Basic Building Blocks of a Use-Case ModelActorsActors According to the UMLActors in SummaryUse CasesUse Cases, According to the UMLThe Use-Case Description Is a Kind of StoryUse Cases in SummaryConnecting Actors and Use CasesUse-Case DiagramsBrief DescriptionsUse-Case DescriptionsThe Flow of EventsThe Flow of Events as a Map ff the TerritoryThe Basic FlowAlternative Flows—Optional Behavior and Variations on a ThemeAlternative Flows—Exceptions/Error ConditionsSubflowsThe Relationship Between the Various FlowsThe Size and Complexity of a Use-Case DescriptionPreconditionsPostconditionsUse-Case Descriptions in SummarySupporting ArtifactsThe Glossary and/or the Domain ModelSupplementary SpecificationsDeclarative and Special RequirementsSummary
Introducing Stakeholders and UsersWhat Are Stakeholders?Identifying Stakeholder TypesIdentifying Stakeholder Representatives and Stakeholder RolesThe Role of Stakeholders and Stakeholder RepresentativesUsers: A Very Important Class of StakeholderStakeholders and Use-Case ModelingInvolving Stakeholders and Users in Your ProjectStep 1: Identify Stakeholder and User TypesStakeholder Type informationStep 2: Identify and Recruit the Stakeholder RepresentativesStakeholder Role informationStep 3: Involve the Stakeholder Representatives in the ProjectCreating a Shared VisionAnalyze the ProblemUnderstand the Key Stakeholder and User NeedsDescribe the Features and Other High-Level Product RequirementsMore on FeaturesDocumenting FeaturesOther Product RequirementsConstraintsOperating RequirementsProvide an Overview of the ProductProduct Position StatementCompleting the Product OverviewBringing It All Together: The Vision DocumentDo You Really Need to do All of This?Summary
Finding ActorsStart by Identifying the Primary ActorsWork from the Specific to the GeneralDon’t Forget the Supporting ActorsConsider All Existing Requirements InformationRemember That Actors Are Not Always PeopleFocus on the System BoundaryIdentify the Information SourcesDon’t Preempt the DesignDon’t Confuse the Actors with the Devices They UseWhen You Can’t Find the Actors, Start with the Use CasesFocus First on the FamiliarEvolve the Set of Actors Alongside the Set of Use CasesDocumenting ActorsHow to Name ActorsDon’t Confuse Actors with Organizational Roles or Job TitlesDon’t OvergeneralizeGive Every Actor a Brief DescriptionCharacterize the ActorsTrace the Actors to the User Types, Stakeholders, and Stakeholder RolesFinding Use CasesStart by Identifying the Actor GoalsConsider the Information Needs of the System and Its UsersDon’t Worry About Commonality (at least at first)Don’t Confuse Use Cases with “Functions”Focus on ValueDerive the Use Cases from the System’s VisionDon’t Forget the Supporting and Operational Use CasesEvolve the Set of Use Cases Alongside the Set of Actors and the Supplementary SpecificationDocumenting Use CasesAssociate the Use Cases to Their ActorsName the Use CasesGive Every Use Case a Brief DescriptionOutline the Use CasesTrace the Use Cases to Stakeholders and Stakeholder RolesTrace the Use Cases to the Features and ConstraintsSummary
Reasons for Having a WorkshopTo Transfer ExpertiseTo Build a TeamTo Create Shared UnderstandingTo Tap into the Creative Power of a GroupPreparing for the WorkshopTrain the ParticipantsUnderstand the VisionKeep the Group Small and InvolvedVary the Composition of the GroupSelect a FacilitatorSet Objectives for the WorkshopSchedule the Workshop and Organize the FacilitiesFinding a MentorFind an Effective CommunicatorFind a Skilled Motivator and ManagerFind a Mentor with Full Life-Cycle ExperienceDon’t Use the Mentor as a CrutchStructuring the WorkshopDefine the Ground Rules for the WorkshopUnderstand the ProblemDefine the Boundary of the SystemIdentify ActorsIdentify Use CasesConsolidate the Model and Validate the ResultsWrap Up the Workshop and Plan the Next StepsSupporting ActivitiesCapture Terminology in a GlossaryCapture Nonfunctional RequirementsCapture Issues, Risks, and AssumptionsHandling Common ProblemsAvoid Functional Decomposition and Dataflow ModelingMaintain FocusSynthesize, Don’t AnalyzeDon’t Describe What Happens Outside the SystemDon’t Just Draw PicturesDon’t Mix Business Use Cases and System Use CasesSummary

The Software Development Life CycleThe Authoring Life CycleState 1: DiscoveredState 2: Briefly DescribedState 3: Bulleted OutlineState 4: Essential OutlineState 5: Detailed DescriptionThe Conversational FormThe Narrative FormUsing the Detailed DescriptionState 6: Fully DescribedTeam WorkingThe Use-Case Modeling ProcessEstablish the VisionProduce an Overview of the SystemReach Agreement on System ScopePackage the Use-Case ModelAddress Areas of Instability and Author Stable Use Cases and Supplementary SpecificationsConsolidate and Review the Use-Case ModelSummary
Use Cases and System StateThe System and External EventsThe System State: More about Preconditions and PostconditionsHow Use Cases InteractThe Side Effects of Using PreconditionsUsing Preconditions Can Reduce the Amount of Validation in a Use CaseUsing Preconditions Can Lead to the Identification of More Use CasesThe Nature of the Flow of EventsThe Structure of the Flow of EventsDefining a Flow of EventsDefining the Basic FlowDefining SubflowsUsing Extension PointsDefining Alternative FlowsExamples of Alternative FlowsManaging Scope Using Alternative FlowsThe Complexity of the Use-Case Model Versus the Complexity of the DesignVisualizing the Flow of EventsWhat Is a Scenario?What Is a Use-Case Realization?Summary
Who Writes Use-Case Descriptions?Programmers Write Poor DescriptionsThe Characteristics of a Good Use-Case AuthorThe Ability to SynthesizeThe Ability to Approach a Problem SystematicallySome Domain KnowledgeAt Least Some Understanding of Software DevelopmentAn Ability to Write WellHow Long Does it Take to Write a Use Case?Getting StartedUse a Style GuideWrite Simply, Directly, and DeliberatelyTreat the Use Case Like a StoryMake a Conscious Decision about the Depth of Detail RequiredDescribe What Happens When the Actors and the System InteractDon’t Rely on Just TextPrototype the User InterfaceManaging DetailGood Use-Case Models Have No “Levels”Adapt the Description to Your Intended AudienceUse the Glossary and Domain Model to Capture DefinitionsUse a Domain Model to Manage Detail in the GlossaryUse the Glossary and the Domain Model TogetherCapture Business Rules in a Domain ModelUse Subflows to Simplify Complex DescriptionsUse Alternative Flows to Capture Unusual or Complex BehaviorDon’t Fill Your Use Cases with CRUDDon’t Be Afraid of Capturing the DetailSummary
How Much Detail is Enough?Describing PreconditionsDeciding Whether a Precondition Is NeededDescribing PreconditionsDescribing PostconditionsDeciding Whether Postconditions Are NeededDescribing PostconditionsWriting the Flow of EventsWriting the Basic Flow of EventsPay Attention to What’s Behind the ScreenUsing the Glossary and the Domain ModelWriting “Named” SubflowsWriting Optional, Alternative, and Exception FlowsIdentifying Alternative FlowsRepresenting Alternative Flows in Separate SectionsNaming Alternative FlowsUsing Extension Points to Target Alternative BehaviorDescribing Alternative Flows That Can Occur Anywhere in the Use CaseResuming the Use Case After the Alternative Flow CompletesAlternative Flows for Alternative Flows and Named SubflowsWriting Special and Supplementary SpecificationsCapturing Use-Case ScenariosSummary
Using Named Subflows and Alternative Flows to Structure TextDefining Relationships Between Use CasesUsing the Include RelationshipCommon Errors Using the Include RelationshipUsing the Extend RelationshipExtension Points, RevisitedEvaluating the Resulting Use-Case ModelUsing Generalization Between Use CasesDefining Relationships Between ActorsSummary
Why Focus on Presenting and Reviewing Use Cases?Types of ReviewsInformal ReviewsFormal ReviewsWhat to Review, and When to Review itWho Should Review the Use CasesUnderstanding the AudienceSetting ExpectationsPreparing for the ReviewRunning the Review MeetingHandling IssuesWhat to Look for When ReviewingReviewing DiagramsReviewing Brief DescriptionsReviewing Use-Case DescriptionsReviewing Preconditions and PostconditionsReviewing the Glossary and Domain ModelThe Role of Prototypes and Storyboards in Use-Case ReviewsSummary
Use Cases and the Project TeamDevelopers and Use CasesTesters and Use CasesUse Cases and the User ExperienceUse Cases and DocumentationManagers, Use Cases, and PlanningUse Cases Across the Life CycleUse Cases and Iterative DevelopmentUse Cases in the Inception PhaseUse Cases in the Elaboration PhaseUse Cases in the Construction and Transition PhasesUse Cases After Product ReleaseEffort Across the Life CycleTraceability, Completeness, and CoverageWhat’s Next?
The ATM ExampleThe ACME Super ATM Use-Case Model SurveyBrief DescriptionActor CatalogueCustomerBurglarBank SystemService AdministratorSecurity AdministratorATM EngineerATM OperatorUse-Case CataloguePrimary Use CasesWithdraw CashDeposit FundsTransfer FundsManage AccountBreak Into MachineSupporting Use CasesRefill and Service the MachineConfigure the MachineCheck the Machine is Iin Working OrderAnalyze System PerformanceReconcile Transaction LogsUpdate System ConfigurationRun Advertising CampaignUse-Case Description—Withdraw CashUse-Case Description—Authenticate CustomerSupporting Glossary Terms

Overview

Developers who effectively employ use cases deliver better applications--on time and under budget. The concept behind use cases is perhaps as old as software itself; they express the behavior of systems in terms of how users will ultimately interact with them. Despite this inherent simplicity, the use case approach is frequently misapplied, resulting in functional requirements that are confusing, cumbersome, or redundant.

In Use Case Modeling, experienced use case practitioners Kurt Bittner and Ian Spence share their tips and tricks for applying use cases in various environments. They delve into all aspects of use case modeling and management, demonstrating how development teams can capitalize on the approach's simplicity when modeling complex systems.

In this ready reference, readers will discover how to

Introduce a development team to use cases and implement a use case approach

Identify the key elements of a use case model, including actors; and the components of a use case, including basic flow, preconditions, post-conditions, sub-flows, and alternate flows

Master the objectives and challenges of creating detailed descriptions of use cases

Improve their descriptions' readability and consistency

Prevent and remedy common problems arising from the misuse of include, extend, and generalization use case relationships.

Organize and conduct a review of a use case model to realize the best possible approach

The book draws extensively on best practices developed at Rational Software Corporation, and presents real-life examples to illustrate the considerable power of use case modeling. As such, Use Case Modeling is sure to give development teams the tools they need to translate vision and creativity into systems that satisfy the most rigorous user demands.

0201709139B08062002