SPECIAL OFFERS
Keep up with new releases and promotions. Sign up to hear from us.
Register your product to gain access to bonus material or receive a coupon.
This eBook includes the following formats, accessible from your Account page after purchase:
EPUB The open industry format known for its reflowable content and usability on supported mobile devices.
PDF The popular standard, used most often with the free Adobe® Reader® software.
This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.
Thoroughly updated and revised, the second edition of a popular tutorial on how to apply use cases effectively in determining requirements.
° An excellent introduction to this increasingly popular topic that assumes no prior knowledge of uses cases or requirements
° Shows how use cases can be applied to solve the most challenging requirements issues faced daily in industry
° Expanded coverage, including thorough treatment of iterative/incremental use case driven project management
This book describes how to gather and define software requirements using a process based on use cases. It shows systems analysts and designers how use cases can provide solutions to the most challenging requirements issues, resulting in effective, quality systems that meet the needs of users.
Use Cases, Second Edition: Requirements in Context describes a three-step method for establishing requirements—an iterative process that produces increasingly refined requirements. Drawing on their extensive, real-world experience, the authors offer a wealth of advice on use-case driven lifecycles, planning for change, and keeping on track. In addition, they include numerous detailed examples to illustrate practical applications.
This second edition incorporates the many advancements in use case methodology that have occurred over the past few years. Specifically, this new edition features major changes to the methodology's iterations, and the section on management reflects the faster-paced, more "chaordic" software lifecycles prominent today. In addition, the authors have included a new chapter on use case traceability issues and have revised the appendixes to show more clearly how use cases evolve.
The book opens with a brief introduction to use cases and the Unified Modeling Language (UML). It explains how use cases reduce the incidence of duplicate and inconsistent requirements, and how they facilitate the documentation process and communication among stakeholders.
The book shows you how to:
The book also highlights numerous currently available tools, including use case name filters, the context matrix, user interface requirements, and the authors' own "hierarchy killer."
Download the Sample Chapter related to this title.
Preface.
Preface to the First Edition.
1. The Trouble with Requirements.
First and Least of All.
What Is a Requirement?
Functional Requirements.
Nonfunctional Requirements.
Requirements Gathering, Definition, and Specification.
The Challenges of Requirements Gathering.
Finding Out What the Users Need.
Documenting Users' Needs.
Avoiding Premature Design Assumptions.
Resolving Conflicting Requirements.
Eliminating Redundant Requirements.
Reducing Overwhelming Volume.
Ensuring Requirements Traceability.
Issues with the Standard Approaches.
User Interviews.
Joint Requirements Planning Sessions.
Contract-Style Requirements Lists.
Prototypes.
Those Troublesome Requirements.
It's All About Interactions.
The Unified Modeling Language.
Nine Diagrams.
Extending the UML with Stereotyping.
Introducing Use Cases, Use Case Diagrams, and Scenarios.
The Goals of Use Cases.
How Use Case Diagrams Show Relationships.
The Use Case Template.
Paths and Scenarios.
Use Cases Apply Here.
Use Cases for Inquiry-Only Systems.
Use Cases for Requests for Proposals.
Use Cases for Software Package Evaluation.
Use Cases for Non-Object-Oriented Systems.
Applying Use Cases to the Requirements Problem.
Requirements Specification Tools.
Principles for Requirements Success.
Three Steps for Gathering Requirements.
The Role of the Mission, Vision, Values.
The Role of the Statement of Work.
The Role of the Risk Analysis.
The Role of the Prototype.
The Roles of Use Cases.
Use Cases Are Effective Communication Vehicles.
Use Cases Can Be Used for Functional and Nonfunctional Requirements.
Use Cases Help Ensure Requirements Traceability.
Use Cases Discourage Premature Design.
The Role of the Business Rules Catalog.
Managing Success.
Objectives.
Users.
Project Team.
Industry Experts.
IT Management Group.
User Management Personnel.
Owners of the Data.
Steps in the Facade Iteration.
Create the Mission, Vision, Values.
Identify and Review Existing Documentation and Intellectual Capital.
Get the Executive Sponsor's Unique Viewpoint.
Review the Business Process Definitions.
Identify the Users, Customers, and Related Groups.
Interview the Stakeholders.
Create a Stakeholders List.
Find the Actors.
Create the Use Case Survey (A List of Facade Use Cases).
Collect and Document Nonfunctional Requirements.
Start the Business Rules Catalog.
Create a Risk Analysis.
Create a Statement of Work.
Begin Experimenting with User Interface Metaphors.
Begin User Interface Storyboards.
Get Informal Approval from the Executive Sponsor.
Tools.
The Use Case Diagram.
The Hierarchy Killer.
Use Case Name Filters.
Actor Filter.
Verb Filter.
Noun Filters.
Packages as Placeholders for Functionality.
Facade Filter.
Peer Review.
User Review.
Deliverables.
Roles.
Context.
Summary.
Objectives.
Steps.
Break Out Detailed Use Cases.
Create Filled Use Cases.
Add Business Rules.
Test the Filled Use Cases.
Put Some Things Off.
Tools.
The Stakeholder Interview.
IPA Filter.
White Space Analysis Filter.
Abstraction Filter.
Testing Use Cases with Scenarios.
Review.
Additional Use Cases.
Deliverables.
Roles.
Context.
Summary.
Objectives.
What Are Focused Use Cases?
Steps.
Merge Duplicate Processes.
Bring Focus to Each Use Case.
Manage Scope Changes During This Iteration.
Manage Risks and Assumptions.
Review.
Tools.
Surplus Functionality Filter.
Narrow the Focus of the System.
Identify Surplus Functionality Inside the Use Case.
Vocabulary Filter.
Deliverables.
Roles.
Context.
Summary.
Introduction.
Waterfall Lifecycle Management.
Nell and the Coffee Shop.
Disadvantages of Waterfall.
Alternatives to Waterfall.
Rapid Application Development (RAD).
Spiral.
Staged Delivery.
Holistic Iterative/Incremental (HI/I).
Introducing the Holistic Iterative/Incremental Use-Case-Driven Project Lifecycle.
The Meaning of Iterative.
The Meaning of Incremental.
The Meaning of Holistic.
The Meaning of Adaptivity.
Complex Adaptive Systems.
Process.
Principles of the Holistic Iterative/Incremental Software Lifecycle.
Manage Requirements Not Tasks.
The Important Goals Are the Business Goals--Dates and Budgets.
Think Like a Businessperson--What Have You Done for Me Lately?
Divide and Conquer.
Cut the Job into Programs and Projects.
Tie Everything Back to the Business.
Create Demonstrable Deliverables.
Learn the Art of "Good Enough" Quality.
The Pieces Will Be Smaller Than You Think.
Expect Negotiation, Not Specification.
Forget about Baselines and Sign-offs.
Estimate by Doing.
Calculate Return-on-Investment in a New Way Using Portfolios.
Tracing Back to Use Cases.
Analysis Model Traceability.
Design Model Traceability.
CRC Card Session Traceability.
Test Model Traceability.
User Interface Design Traceability.
Application Architecture Traceability.
Project Management Traceability.
Documentation and Training Traceability.
Product Marketing Traceability.
Security Traceability.
Release Planning.
Tracing Back to Nonfunctionals.
Tracing Back to Business Rules.
Structural Facts.
Action-Restricting and Action-Triggering Rules.
Calculations and Inferences.
Mistakes, Pitfalls, and Bruised Knees.
Classic Mistakes: Make Them and Move On.
Why Did Use Cases Win?
Use Cases Are Sensible to Businesspeople.
Use Cases Are Traceable.
Use Cases Are an Excellent Scoping Tool.
Use Cases Don't Use a Special Language.
Use Cases Allow Us to Tell Stories.
The Alternatives Are Awful.
Use Cases Beyond Software.
Service Use Cases.
Business Use Cases.
Summary.
Overview.
The Use Cases.
The Actors.
Technical Requirements and Business Rules.
Scope Decisions.
List of Use Cases.
Refining the Requirements.
Investment Returns Calculation.
Tightening Requirements.
Overview.
Background.
Problem Description.
Solution Analysis.
Overview.
The Use Cases.
It has been an interesting three years since the first edition of this book was published. At that time, use cases were still an "interesting technique" but had not been widely adopted. Today, we see a software development marketplace where use cases are the standard practice for gathering requirements and have even migrated to other applications, including business processes, service offerings. We would not have predicted this wave of popularity in our happiest visions.
Of course, our book was not the only one in the last few years to proselytize use cases. But it has been gratifying to be part of this new technique's recognition in the software world. Given this trend, we've decided to publish a second edition of Use Cases: Requirements in Context, putting together the lessons we've learned since our original thoughts. And the lessons have been many. Our approach in the first edition was something we had created after several use case driven project efforts, but it was still a young process. Using it on many more projects since the book was published, we have had a chance to collaborate with the many of best minds in the software business and fine tune the process into something much workable, practical and scaleable. We have also taken ideas from other emerging fields, including the ideas of chaordic organizations (Dee Hock, Margaret Wheatley and others) as well as Drs. Theodore Williams and Hong Li of Purdue University and their Purdue Enterprise Reference Architecture. Both bodies of work have had a tremendous impact on how we've applied use cases on our projects and how we've recast our ideas in this new edition.
In our second edition, you can expect these changes. First and most noticeably, we have only three "F" iterations this time - Facade, Filled and Focused. The last F (Finished) has proven troublesome on one project after another. First of all, in an iterative approach, nothing is every truly finished. It is always evolving. Also, as an iteration, it really contained only the mesh between use cases and the user interface design. We have moved the user interface ideas into the Facade iteration, because the evolution of the user interface should proceed in parallel with the early use case creation, not following.
Another big change is our approach to our Management chapter. Although we are not directly contradicting anything from before, we have expanded our explanation of iterative/incremental use case driven project management greatly in this edition. We call it holistic iterative/incremental, or HI/I (hi-eye). We believe this area of the lifecycle requires the most work of anything, since the waterfall project management processes from years past are not keeping up with the faster pace, more "chaordic" software lifecycles of today. We present our chapter on management here, but we eagerly look forward to other authors expanding on these ideas and inventing new ways of tackling this big problem. Also, the Project Management Institute (PMI) have made some gestures toward embracing some of the new software lifecycle ideas.
The appendixes in our first edition were regarded by many readers we heard from as the best and the worst parts of the book. We were the first to try to show partially complete use cases in our examples, which is a crucial step to understanding the iterative nature of use case creation. However, the presentation was quite confusing, because we repeated use cases through the four iterations, sometimes they changed, sometimes they didn't, and it was hard to tell what changed when it did. This time we're taking a very different approach. We still want to tell the story of how use cases are applied to software requirements gathering, but we're doing it in a much less formal way. In each appendix, we've picked a style of application (large business application, technical subsystem, package evaluation, etc.) and show how the use cases and other artifacts evolve through the story. We hope this will retain the good aspects of the first edition, but add some coherence to the evolution of use case versions.
We've found on many, many projects that the idea of use case hierarchies does nothing but add confusion. Creating use cases that are "high level" and then "detailed" use cases later is hurting the requirements process. Hierarchies that are taller and more complex (some books advocate four-level hierarchies or more) create more and more distance from the original business requirements. Even though our original process had only two levels of hierarchy (system context-level use case and one level below) we always had trouble with teams who wanted to add levels and confuse themselves. Similarly, using <
Use cases are different from other types of requirements techniques in many ways, but one particular difference is in the realm of traceability. Use cases are much more traceable back to the business needs, and also traceable into the software development artifacts, to everything from UML analysis and design artifacts to testing, documentation, training, security and even parts of the architecture. We've decided to dedicate a chapter to this traceability phenomenon of use cases, to show opportunities for making sure the team is "working on the right thing."
Finally, in the interests of keeping up-to-date with the technological tools of requirements gathering, we've listed the tools available at this writing and given some ideas as to their best use. Since these tools change so quickly (and books get written so slowly, especially by us!) we decided to keep this brief.We hope you enjoy this second edition of Use Cases: Requirements in Context. We've enjoyed creating the updates and going through the publishing cycle again with our publishers at Pearson Education. Please feel free to contact us with your ideas, experiences and comments anytime. Our e-mail addresses are listed at the end of the last chapter in the book.
Daryl Kulak
Download the Index
file related to this title.