Use Cases

• Reduce the incidence of duplicate and inconsistent requirements
• Communicate requirements that are understandable to both users and developers
• Communicate a vision of what the application needs to do without the distractions inherent in a coded prototype
• Document the entire requirements process clearly and efficiently

Use Cases: Requirements in Context first examines the difficulties of requirements gathering and briefly introduces both use cases and the Unified Modeling Language (UML). Using detailed examples that run through the book, it then elaborates a four-step method for establishing requirements--an iterative process that produces increasingly refined requirements. Drawing on their own extensive experience, the authors offer practical advice on how to manage this process, including guidance on planning, scheduling, and estimating. They also dedicate an entire chapter to the common mistakes made during requirements capture and specification, particularly those related to use case creation.

This detailed, hands-on book shows you how to:

• Describe the context of relationships and interactions between actors and applications using use case diagrams and scenarios Specify functional and non-functional requirements;
• Create the candidate use case list; Break out detailed use cases and add detail to use case diagrams
• Add triggers, preconditions, basic course of events, and exceptions to use cases

Other tools examined in this book include the stakeholder interview, use case name filters, the context matrix, user interface requirements, team organization, and quality assurance.

Table of contents

Preface

1 The Trouble with Requirements

1.1 First and Least of All . . .

1.2 What Is a Requirement?

1.2.1 Functional Requirements

1.2.2 Nonfunctional Requirements

1.3 Requirements Gathering, Definition, and Specification

1.4 The Challenges of Requirements Gathering

1.4.1 Finding Out What the Users Need

1.4.2 Documenting Users' Needs

1.4.3 Avoiding Premature Design Assumptions

1.4.4 Resolving Conflicting Requirements

1.4.5 Eliminating Redundant Requirements

1.4.6 Reducing Overwhelming Volume

1.4.7 Ensuring Requirements Traceability

1.5 Issues with the Standard Approaches

1.5.1 User Interviews

1.5.2 Joint Requirements Planning Sessions

1.5.3 Requirements Lists

1.5.4 Prototypes

1.6 Those Troublesome Requirements

2 Moving to Use Cases

2.1 It's All About Interactions

2.2 Hello World!

2.3 The Unified Modeling Language

2.3.1 Nine Diagrams

2.3.2 Extending the UML with Stereotyping

2.4 Introducing Use Cases, Use Case Diagrams, and Scenarios

2.4.1 The Goals of Use Cases

2.4.2 How Use Case Diagrams Show Relationships

2.4.3 The Use Case Template

2.4.4 Paths and Scenarios

2.5 Use Cases Apply Here

2.5.1 Use Cases for Inquiry-Only Systems

2.5.2 Use Cases for Requests for Proposals

2.5.3 Use Cases for Software Package Evaluation

2.5.4 Use Cases for Non-Object-Oriented Systems

2.6 Applying Use Cases to the Requirements Problem

3 A Use Case-Driven Approach to Requirements Gathering

3.1 Requirements Specification Tools

3.2 Principles for Requirements Success

3.3 Four Steps for Gathering Requirements

3.4 The Role of the Problem Statement

3.5 The Role of the Statement of Work

3.6 The Role of the Risk Analysis

3.7 The Role of the Prototype

3.8 The Roles of Use Cases

3.8.1 Use Cases Are Effective Communication Vehicles

3.8.2 Use Cases Can Be Used for Functional and Nonfunctional Requirements

3.8.3 Use Cases Help Ensure Requirements Traceability

3.8.4 Use Cases Discourage Premature Design

3.9 The Role of the Business Rules Catalog

3.10 Managing Success

4 The Facade Iteration

4.1 Objectives

4.2 Steps in the Facade Iteration

4.2.1 Create a Problem Statement

4.2.2 Identify and Review Existing Documentation and Intellectual Capital

4.2.3 Get the Executive Sponsor's Unique Viewpoint

4.2.4 Identify the Users, Customers, and Related Groups

4.2.5 Interview the Stakeholders

4.2.6 Find the Actors

4.2.7 Create the Facade Use Cases

4.2.8 Start the Business Rules Catalog

4.2.9 Create a Risk Analysis

4.2.10 Create a Statement of Work

4.2.11 Get Informal Approval from the Executive Sponsor

4.3 Tools

4.3.1 System Context Use Case

4.3.2 Use Case Name Filters

4.3.3 Candidate Use Case List

4.3.4 Actor Filter

4.3.5 Verb Filter

4.3.6 Noun Filter

4.3.7 Packages As Placeholders for Functionality

4.3.8 Facade Filter

4.3.9 Peer Review

4.3.10 User Review

4.4 Deliverables

4.5 Roles

.6 Context

4.7 Summary

5 The Filled Iteration

5.1 Objectives

5.2 Steps

5.2.1 Break Out Detailed Use Cases

5.2.2 Create Filled Use Cases

5.2.3 Collect and Document Nonfunctional Requirements

5.2.4 Add Business Rules

5.2.5 Test the Filled Use Cases

5.2.6 Put Some Things Off

5.3 Tools

5.3.1 The Stakeholder Interview

5.3.2 IPA Filter

5.3.3 White Space Analysis Filter

5.3.4 Abstraction Filter

5.3.5 Testing Use Cases with Scenarios

5.3.6 Review

5.3.7 Additional Use Cases

5.4 Deliverables

5.5 Roles

5.6 Context

5.7 Summary

6 The Focused Iteration

6.1 Objectives

6.2 What Are Focused Use Cases?

6.3 Steps

6.3.1 Create the Context Matrix

6.3.2 Remove Duplicate Processes

6.4 Bring Focus to Each Use Case

6.5 Scope Changes During This Iteration

6.6 Strategies for Change

6.7 Risks and Assumptions

6.8 Review

6.8.1 Opportunities Not Taken

6.8.2 System Damage

6.9 Client Sign-Off

6.10 Tools

6.10.1 Context Matrix

6.10.2 Dependency Filter

6.10.3 Surplus Functionality Filter

6.10.4 Narrow the Focus of the System

6.10.5 Identify Surplus Functionality Inside the Use Case

6.10.6 Vocabulary Filter

6.11 Deliverables

6.12 Roles

6.13 Context

6.14 Summary

7 The Finished Iteration

7.1 Objectives

7.2 Steps

7.2.1 Add User Interface Requirements

7.2.2 Abstract and Combine Nonfunctional Requirements

7.2.3 Make Final Scope Decisions and Get Sign-Off

7.2.4 Baseline the Requirements

7.3 Tools

7.3.1 Use Case Review

7.4 Deliverables

.5 Roles

7.6 Context

7.7 Summary

8 Managing the Requirements Activity

8.1 Managing the Iterative, Incremental Lifecycle

8.1.1 Why Switch from Waterfall?

8.1.2 The Meaning of "Incremental"

8.1.3 The Meaning of "Iterative"

8.1.4 From Waterfall to Iterative and Incremental

8.1.5 Developers Love It, but Managers Struggle

8.2 The Role of the Scenario in Management

8.3 Using Scenarios to Plan, Schedule, and Estimate

8.4 You Know the Plan Is Wrong

8.5 The Atmosphere During Requirements Gathering

8.5.1 Hectic Activity

8.5.2 Fear of the Future

8.5.3 Free-Flowing Adaptability

8.6 Managing Application and Architecture Requirements

8.7 Ensuring Quality in Requirements

8.7.1 Provide Unique Identification for Use Cases and Business Rules

8.7.2 Use a Database to Store Use Cases and Business Rules

8.7.3 Identify Change Cases

8.8 A Management Challenge

9 Working in Teams

9.1 Organizing by Team

9.2 Splitting Up the Work

9.3 Deploying Configuration Management

9.4 Avoiding Quality Problems

9.4.1 Catch All the Requirements

9.4.2 Create Consistent Use Cases

9.4.3 Avoid Use Case Redundancy

10 Classic Mistakes

10.1 Mistakes, Pitfalls, and Bruised Knees

10.2 Classic Mistakes: Make Them and Move On

11 The Case for Use Cases

A Use Cases Beyond Requirements

A.1 Business Modeling

A.2 Requirements Gathering

A.3 Analysis

A.4 Design

A.4.1 Use Case Hierarchies for User Interface Design

A.4.2 Using Scenarios As Units of Work for Transaction Processing

A.4.3 Architectural Use Cases

A.4.4 Using Actors As Security Profiles

A.4.5 Using Scenarios to Manage Security

A.4.6 Using Scenarios to Manage Prefetch

A.5 Construction

A.6 Testing

A.7 Deployment

A.8 Project Management

B Case Study: Sell Property

B.1 The Facade Iteration

B.1.1 Problem Statement

B.1.2 Statement of Work

B.1.3 Risk Analysis

B.1.4 Facade Use Cases

B.2 The Filled Iteration

B.2.1 Risk Analysis

B.2.2 Filled Use Cases

B.2.3 Business Rules

B.2.4 Context Matrix

B.2.5 Nonfunctional Requirements

B.2.6 Testing Using Scenarios

B.3 The Focused Iteration

B.3.1 Risk Analysis

B.3.2 Focused Use Cases

B.3.3 Business Rules

B.4 The Finished Iteration

B.4.1 Risk Analysis

B.4.2 Finished Use Cases

B.4.3 Business Rules

C Case Study: Track Costume Sales

C.1 The Facade Iteration

C.1.1 Problem Statement

C.1.2 Statement of Work

C.1.3 Risk Analysis

C.1.4 Facade Use Cases

C.1.5 Business Rules

C.2 The Filled Iteration

C.2.1 Statement of Work

C.2.2 Filled Use Cases

C.2.3 Business Rules

C.2.4 Context Matrix

C.2.5 Nonfunctional Requirements

C.2.6 Testing Using Scenarios

C.3 The Focused Iteration

C.3.1 Risk Analysis

C.3.2 Focused Use Cases

C.3.3 Business Rules

C.4 The Finished Iteration

C.4.1 Finished Use Cases

C.4.2 Business Rules

Bibliography

Index