Use Cases: Requirements in Context / Edition 2

by Daryl Kulak

Overview

• 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, teamorganization, and quality assurance.

Product Details

ISBN-13:	2900321154988
Publisher:	Pearson Education
Publication date:	07/25/2003
Edition description:	REV
Pages:	272
Product dimensions:	6.00(w) x 1.25(h) x 9.00(d)

About the Author

Daryl Kulak is the President and CEO of Water-Logic Software (www.water-logic.com), an Internet business and technology consulting firm based in Columbus, Ohio. He is a graduate of the Northern Alberta Institute of Technology (NAIT) in Edmonton, Alberta. During much of his 17-year career managing software development projects in the United States and Canada, Daryl has focused on use cases, iterative/incremental development, and component design.

Eamonn Guiney is a consultant at NewtonPartners (www.newtonpartners.com), a company that provides management consulting and system integration services to the money management industry. He is based in Sacramento, California. Eamonn creates business systems using a variety of tools, particularly object-oriented methodologies and use cases.

Read an Excerpt

PREFACE:

Use Cases: Requirements in Context came about, as most books probably do, as the result of a complaint. We felt that there weren't any good books that addressed use cases for requirements gathering. It seemed that a lot of people agreed that use cases were a perfectly good tool to solve the requirements problem, but no one had put down on paper any detailed process to help people understand how to use them this way. In fact, even as we write today, in late 1999, there is no book of this sort that we know of.

Requirements gathering has been a problem on almost every project we've been involved with. The fuzzy nature of requirements makes working with them slippery and unintuitive for most software analysts. Use cases are the first tool we've seen that addresses the specification and communication concerns usually associated with requirements gathering.

Although use cases in themselves are quite intuitive, the process around them is often done poorly. The questions that people have--How many iterations do I do? How fine-grained should a use case be?--are not answered or even addressed in most texts. This is probably because they are hard questions and the answers can vary greatly from one situation to another. However, they are important questions, and we decided to describe our own best practices as a first volley in what we hope will become a spirited industry dialog on how to generate requirements that will address user needs.

Use Cases: Requirements in Context is a practical book for the everyday practitioner. As consultants in the information technology industry, we employ use cases to specify business systems as part of ourdaily lives. We think we understand the issues facing people when they deliver software using tools such as the Unified Modeling Language and use cases. Our main intent is not to describe use case notation, although we do address that. Instead, we show a requirements process that addresses requirements gathering in a way that produces quality results.

While writing, we considered the factors that cause problems in requirements gathering, and we developed a use case method for delivering a requirements-oriented set of deliverables. The methodology breaks down the activity of producing requirements into a series of steps, and it answers the questions that usually come up when people employ use cases. This book relates directly to the real work of delivering a specification, managing that effort with a team, and getting the most bang for your buck.

The sample use cases and use case diagrams that appear throughout the book are also presented in Appendixes B and C. These appendixes demonstrate the development of the use cases and other requirements analysis artifacts through each phase of their development. Appendix B documents a business system for real estate, and Appendix C documents a business system for the garment industry.

We hope you enjoy this book. It was a labor of love for us. This is a process that works well for us. If it works for you, too, that's great. If it doesn't, perhaps you can adapt some of the tools, ideas, or suggestions to your own way of addressing the requirements problem.

0201657678P04062001

Table of Contents

	Preface	xv
	Preface to the First Edition	xix
1	The Trouble with Requirements	1
1.1	First and Least of All ...	1
1.2	What Is a Requirement?	5
1.2.1	Functional Requirements	9
1.2.2	Nonfunctional Requirements	9
1.3	Requirements Gathering, Definition, and Specification	10
1.4	The Challenges of Requirements Gathering	12
1.4.1	Finding Out What the Users Need	12
1.4.2	Documenting Users' Needs	13
1.4.3	Avoiding Premature Design Assumptions	13
1.4.4	Resolving Conflicting Requirements	13
1.4.5	Eliminating Redundant Requirements	14
1.4.6	Reducing Overwhelming Volume	14
1.4.7	Ensuring Requirements Traceability	14
1.5	Issues with the Standard Approaches	15
1.5.1	User Interviews	15
1.5.2	Joint Requirements Planning Sessions	16
1.5.3	Contract-Style Requirements Lists	17
1.5.4	Prototypes	19
1.6	Those Troublesome Requirements	20
2	Moving to Use Cases	21
2.1	It's All About Interactions	25
2.2	The Unified Modeling Language	27
2.2.1	Nine Diagrams	28
2.2.2	Extending the UML with Stereotyping	34
2.3	Introducing Use Cases, Use Case Diagrams, and Scenarios	35
2.3.1	The Goals of Use Cases	36
2.3.2	How Use Case Diagrams Show Relationships	38
2.3.3	The Use Case Template	42
2.3.4	Paths and Scenarios	46
2.4	Use Cases Apply Here	49
2.4.1	Use Cases for Inquiry-Only Systems	49
2.4.2	Use Cases for Requests for Proposals	50
2.4.3	Use Cases for Software Package Evaluation	50
2.4.4	Use Cases for Non-Object-Oriented Systems	50
2.5	Applying Use Cases to the Requirements Problem	51
3	A Use-Case-Driven Approach to Requirements Gathering	53
3.1	Requirements Specification Tools	53
3.2	Principles for Requirements Success	53
3.3	Three Steps for Gathering Requirements	55
3.4	The Role of the Mission, Vision, Values	56
3.5	The Role of the Statement of Work	57
3.6	The Role of the Risk Analysis	57
3.7	The Role of the Prototype	57
3.8	The Roles of Use Cases	59
3.8.1	Use Cases Are Effective Communication Vehicles	59
3.8.2	Use Cases Can Be Used for Functional and Nonfunctional Requirements	59
3.8.3	Use Cases Help Ensure Requirements Traceability	59
3.8.4	Use Cases Discourage Premature Design	60
3.9	The Role of the Business Rules Catalog	60
3.10	Managing Success	62
4	The Facade Iteration	63
4.1	Objectives	63
4.1.1	Users	64
4.1.2	Project Team	64
4.1.3	Industry Experts	65
4.1.4	IT Management Group	65
4.1.5	User Management Personnel	66
4.1.6	Owners of the Data	66
4.2	Steps in the Facade Iteration	67
4.2.1	Create the Mission, Vision, Values	67
4.2.2	Identify and Review Existing Documentation and Intellectual Capital	67
4.2.3	Get the Executive Sponsor's Unique Viewpoint	69
4.2.4	Review the Business Process Definitions	71
4.2.5	Identify the Users, Customers, and Related Groups	71
4.2.6	Interview the Stakeholders	72
4.2.7	Create a Stakeholders List	73
4.2.8	Find the Actors	73
4.2.9	Create the Use Case Survey (A List of Facade Use Cases)	73
4.2.10	Collect and Document Nonfunctional Requirements	74
4.2.11	Start the Business Rules Catalog	81
4.2.12	Create a Risk Analysis	81
4.2.13	Create a Statement of Work	81
4.2.14	Begin Experimenting with User Interface Metaphors	81
4.2.15	Begin User Interface Storyboards	83
4.2.16	Get Informal Approval from the Executive Sponsor	84
4.3	Tools	84
4.3.1	The Use Case Diagram	84
4.3.2	The Hierarchy Killer	84
4.3.3	Use Case Name Filters	86
4.3.4	Actor Filter	86
4.3.5	Verb Filter	87
4.3.6	Noun Filters	88
4.3.7	Packages as Placeholders for Functionality	89
4.3.8	Facade Filter	89
4.3.9	Peer Review	89
4.3.10	User Review	90
4.4	Deliverables	90
4.5	Roles	90
4.6	Context	91
4.7	Summary	91
5	The Filled Iteration	93
5.1	Objectives	93
5.2	Steps	94
5.2.1	Break Out Detailed Use Cases	94
5.2.2	Create Filled Use Cases	96
5.2.3	Add Business Rules	101
5.2.4	Test the Filled Use Cases	102
5.2.5	Put Some Things Off	103
5.3	Tools	104
5.3.1	The Stakeholder Interview	104
5.3.2	IPA Filter	104
5.3.3	White Space Analysis Filter	105
5.3.4	Abstraction Filter	105
5.3.5	Testing Use Cases with Scenarios	105
5.3.6	Review	105
5.3.7	Additional Use Cases	106
5.4	Deliverables	106
5.5	Roles	106
5.6	Context	107
5.7	Summary	107
6	Focused Iteration	109
6.1	Objectives	109
6.2	What Are Focused Use Cases?	110
6.3	Steps	110
6.3.1	Merge Duplicate Processes	110
6.3.2	Bring Focus to Each Use Case	111
6.3.3	Manage Scope Changes During This Iteration	112
6.3.4	Manage Risks and Assumptions	113
6.3.5	Review	113
6.4	Tools	114
6.4.1	Surplus Functionality Filter	114
6.4.2	Narrow the Focus of the System	114
6.4.3	Identify Surplus Functionality Inside the Use Case	115
6.4.4	Vocabulary Filter	115
6.5	Deliverables	116
6.6	Roles	116
6.7	Context	116
6.8	Summary	117
7	Managing Requirements and People	119
7.1	Introduction	119
7.2	Waterfall Lifecycle Management	120
7.2.1	Nell and the Coffee Shop	121
7.2.2	Disadvantages of Waterfall	123
7.3	Alternatives to Waterfall	125
7.3.1	Rapid Application Development (RAD)	125
7.3.2	Spiral	126
7.3.3	Staged Delivery	126
7.3.4	Holistic Iterative/Incremental (HI/I)	127
7.4	Introducing the Holistic Iterative/Incremental Use-Case-Driven Project Lifecycle	127
7.4.1	The Meaning of Iterative	128
7.4.2	The Meaning of Incremental	129
7.4.3	The Meaning of Holistic	130
7.4.4	The Meaning of Adaptivity	131
7.4.5	Complex Adaptive Systems	132
7.5	Process	133
7.6	Principles of the Holistic Iterative/Incremental Software Lifecycle	135
7.6.1	Manage Requirements Not Tasks	136
7.6.2	The Important Goals Are the Business Goals--Dates and Budgets	137
7.6.3	Think Like a Businessperson--What Have You Done for Me Lately?	138
7.6.4	Divide and Conquer	138
7.6.5	Cut the Job into Programs and Projects	141
7.6.6	Tie Everything Back to the Business	144
7.6.7	Create Demonstrable Deliverables	145
7.6.8	Learn the Art of "Good Enough" Quality	145
7.6.9	The Pieces Will Be Smaller Than You Think	146
7.6.10	Expect Negotiation, Not Specification	146
7.6.11	Forget about Baselines and Sign-offs	147
7.6.12	Estimate by Doing	147
7.6.13	Calculate Return-on-Investment in a New Way Using Portfolios	148
8	Requirements Traceability	149
8.1	Tracing Back to Use Cases	152
8.1.1	Analysis Model Traceability	153
8.1.2	Design Model Traceability	153
8.1.3	CRC Card Session Traceability	154
8.1.4	Test Model Traceability	154
8.1.5	User Interface Design Traceability	154
8.1.6	Application Architecture Traceability	154
8.1.7	Project Management Traceability	155
8.1.8	Documentation and Training Traceability	155
8.1.9	Product Marketing Traceability	155
8.1.10	Security Traceability	155
8.1.11	Release Planning	155
8.2	Tracing Back to Nonfunctionals	156
8.3	Tracing Back to Business Rules	157
8.3.1	Structural Facts	157
8.3.2	Action-Restricting and Action-Triggering Rules	157
8.3.3	Calculations and Inferences	157
9	Classic Mistakes	159
9.1	Mistakes, Pitfalls, and Bruised Knees	159
9.2	Classic Mistakes: Make Them and Move On	160
10	The Case for Use Cases	173
10.1	Why Did Use Cases Win?	174
10.1.1	Use Cases Are Sensible to Businesspeople	174
10.1.2	Use Cases Are Traceable	175
10.1.3	Use Cases Are an Excellent Scoping Tool	175
10.1.4	Use Cases Don't Use a Special Language	175
10.1.5	Use Cases Allow Us to Tell Stories	175
10.1.6	The Alternatives Are Awful	176
10.2	Use Cases Beyond Software	176
10.2.1	Service Use Cases	176
10.2.2	Business Use Cases	178
10.3	Summary	181
A	Real Estate Management System	183
A.1	Overview	183
A.2	The Use Cases	184
A.2.1	The Actors	186
A.2.2	Technical Requirements and Business Rules	187
A.3	Scope Decisions	187
A.3.1	List of Use Cases	190
A.4	Refining the Requirements	212
A.4.1	Investment Returns Calculation	213
A.4.2	Tightening Requirements	215
B	Integrated Systems	219
B.1	Overview	219
B.2	Background	219
B.3	Problem Description	221
B.4	Solution Analysis	222
C	Instant Messaging Encryption	225
C.1	Overview	225
C.2	The Use Cases	226
D	Order a Product from a Catalog	229
	Bibliography	235
	Index	237

Preface

Use Cases: Requirements in Context came about, as most books probably do, as the result of a complaint. We felt that there weren't any good books that addressed use cases for requirements gathering. It seemed that a lot of people agreed that use cases were a perfectly good tool to solve the requirements problem, but no one had put down on paper any detailed process to help people understand how to use them this way. In fact, even as we write today, in late 1999, there is no book of this sort that we know of.

Requirements gathering has been a problem on almost every project we've been involved with. The fuzzy nature of requirements makes working with them slippery and unintuitive for most software analysts. Use cases are the first tool we've seen that addresses the specification and communication concerns usually associated with requirements gathering.

Although use cases in themselves are quite intuitive, the process around them is often done poorly. The questions that people have—How many iterations do I do? How fine-grained should a use case be?—are not answered or even addressed in most texts. This is probably because they are hard questions and the answers can vary greatly from one situation to another. However, they are important questions, and we decided to describe our own best practices as a first volley in what we hope will become a spirited industry dialog on how to generate requirements that will address user needs.

Use Cases: Requirements in Context is a practical book for the everyday practitioner. As consultants in the information technology industry, we employ use cases to specify businesssystems as part of our daily lives. We think we understand the issues facing people when they deliver software using tools such as the Unified Modeling Language and use cases. Our main intent is not to describe use case notation, although we do address that. Instead, we show a requirements process that addresses requirements gathering in a way that produces quality results.

While writing, we considered the factors that cause problems in requirements gathering, and we developed a use case method for delivering a requirements-oriented set of deliverables. The methodology breaks down the activity of producing requirements into a series of steps, and it answers the questions that usually come up when people employ use cases. This book relates directly to the real work of delivering a specification, managing that effort with a team, and getting the most bang for your buck.

The sample use cases and use case diagrams that appear throughout the book are also presented in Appendixes B and C. These appendixes demonstrate the development of the use cases and other requirements analysis artifacts through each phase of their development. Appendix B documents a business system for real estate, and Appendix C documents a business system for the garment industry.

We hope you enjoy this book. It was a labor of love for us. This is a process that works well for us. If it works for you, too, that's great. If it doesn't, perhaps you can adapt some of the tools, ideas, or suggestions to your own way of addressing the requirements problem.

Editorial Reviews

Describes how to gather and define software requirements using a process based on use cases. First examines difficulties of requirements gathering and introduces both use cases and UML. Presents detailed ongoing examples and a four-step method for establishing requirements, with practical advice provided on planning, scheduling, estimating, and common mistakes. Other tools examined include the stakeholder interview, team organization, and quality assurance. Kulak is president and CEO of an Internet business and technology consulting firm; Guiney works with a company that provides management consulting and system integration services. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Booknews