Home > Store

Succeeding with Use Cases: Working Smart to Deliver Quality

Register your product to gain access to bonus material or receive a coupon.

Succeeding with Use Cases: Working Smart to Deliver Quality


  • Sorry, this book is no longer in print.
Not for Sale



Increase software quality, while minimizing development costs, by leveraging industry best practices for quality management in use cases.

° Launch your development efforts to another level with an entirely new set of perspectives on use case driven development

° Deliver true "bang for the buck" with proven techniques for improving software quality and increasing ROI

° Learn to extend the power of use cases as well as proven methodologies such as RUP and Extreme Programming


  • Copyright 2005
  • Edition: 1st
  • Book
  • ISBN-10: 0-321-31643-6
  • ISBN-13: 978-0-321-31643-1

Build on Use Cases to Deliver Higher-Quality, Higher-Value Software

You can dramatically improve software quality and value by integrating use cases with best-practice software quality engineering disciplines.

Richard Denney presents practical, cost-effective techniques that help your entire development organization deliver superior software.

Using realistic examples, Denney demonstrates how to complement use cases with Quality Function Deployment (QFD), Software Reliability Engineering (SRE), Model-Based Specification (preconditions, postconditions, and invariants), Requirements Configuration Management, and Project Portfolio Management. Denney's techniques address challenges faced by project and product managers, team leads, developers, designers, software engineers, and testers alike. These techniques offer immense value no matter what methodology you use—from the Unified Process to Extreme Programming.

  • Use QFD to make sure you release products that are true to your business drivers

  • Drive your project's vision vertically, from senior management and marketing to the development team

  • Align/synchronize distributed development horizontally across component teams, product teams, and business groups

  • Use SRE to maximize reliability and customer satisfaction—while minimizing engineering costs

  • Build use case operational profiles that help you spend development dollars more intelligently

  • Get solid metrics that tell you when it's time to stop testing

  • Use Model-Based Specification to sharpen your analysis of potential failures

  • Understand precondition and postcondition realities they never mentioned in "Use Case 101"

  • Design effective test cases using preconditions, postconditions, and invariants

  • Use Configuration Management of Use Cases to help your company work smarter

  • Leverage use cases in Project Portfolio Management—quite possibly the most valuable process improvement you can make

  • Calculate ROI on your company's investments in a requirements management tool and process

© Copyright Pearson Education. All rights reserved.


Author's Site

Visit the Author's Web Site related to this title.

Sample Content

Online Sample Chapter

An Introduction to Use Cases and Quality Function Deployment: Driving Vision Vertically Through the Project

Downloadable Sample Chapter

Download the Sample Chapter related to this title.

Table of Contents




1. An Introduction to QFD: Driving Vision Vertically.

    Through the Project

    The Language Gap

    QFD in Use Case-Driven Projects

      Business Drivers in QFD

      The "Chaos" of Projects and the Importance of Prioritization

    Running a QFD Workshop: Mega Motors Example

      Workshop Overview

      Identify Use Cases

      Analyze Relationship of Use Cases to Business Drivers

      Analyze Correlations Between Use Cases

      First Matrix Complete; QFD Workshop Status Check

      "Flipping the Matrix": Deployment to Quality Requirements

      Flipping the Matrix: Deployment to Vehicle Components

      Workshop Conclusion and Summary

    Chapter Review

2. Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization.

    Using QFD to Align Decision Making Horizontally Across a Company

      A Brief Overview of Oil and Gas Exploration

      The Problem: Selecting A Shared Earth Modeling Development Kit

      O&G's QFD Road Map

      Matrix 1: Prioritize Use Cases

      Matrix 2: Prioritize Non-Functional Requirements

      Matrix 3: Prioritize Earth Modeling Techniques

      Matrix 4: Prioritize Shared Earth Modeling Dev Kits

      Example Conclusion and Summary

    Using QFD to Synchronize Distributed Development Horizontally Across Component Teams

      Entropy Happens in Distributed Software Development

      Planning the Length of Iterations and Number of Use Cases per Iteration in Distributed Software Development

    Chapter Review


3. Operational Profiles: Quantifying Frequency of Use of Use Cases.

    Operational Profile of Use Case Scenarios

      Decision Graphs

      Pareto Principle and Guesstimates

    Working Smarter: Scenarios of a Use Case

      Time-Boxing an Inspection

      Bottom-Up Estimation of Tests Needed per Scenario

    Operational Profile of a Use Case Package

      Sanity Check Before Proceeding

      Use Case Relationships

      Sales Order Example

      Probability that Include/Extend Use Cases Are Actually Used

      Concluding Thoughts About Use Case Relationships

    Working Smarter: Use Case Packages

      Time-Boxing for a Package of Use Cases

      Transitioning from High-Level to Low-Level Planning

      Air Bags and Hawaiian Shirts

    Extending Operational Profiles to Address Critical Use Cases

      What Does "Critical" Mean?

      It's a Calculated Risk

      Hardware Widget Example

      Profiling Risk in Use Cases

      What Have You Got to Lose?

    Chapter Review

4. Reliability and Knowing When to Stop Testing.

    What Is "Reliability"?

      Software Reliability is User-Centric and Dynamic

      Software Reliability Is Quantifiable

      Reliability: Software Versus Hardware

    Failure Intensity

      Visualizing Failure Intensity with a Reliability Growth Curve

      Selecting a Unit of Measure for Failure Intensity

      Setting a Failure Intensity Objective

      But What's the Right Failure Intensity Objective?

    The Swamp Report

      Dashboard Layout

      Establish Planned Test Coverage as per Operational Profile

      Initialize Dashboard Before Each Test Iteration

      Update the Dashboard at the End of Each Test Iteration

      Tracking the Swamp Through Time

    Determining the Effectiveness of Your SRE-Based Test Process

      Final Notes on DDE

    Chapter Review


5. Use Case Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!

    Sanity Check Before Proceeding

    A Brief History of Preconditions and Postconditions

    Calculating Preconditions from Postconditions

      Use Case Overview

      Step 1. Find a "Risky" Postcondition: Model as an Equation

      Step 2. Identify a Potential Failure: State an Invariant

      Step 3. Compute the Precondition

    Why Does This Work?!

    Modeling State Change

    Model-Based Specification

    Reasoning About State Through Time

      Use Case Overview

      Step 1. Find "Risky" Postconditions: Model as Equations

      Step 2. Identify a Potential Failure: State an Invariant

      Step 3. Calculate Preconditions

    Exploring Boundary Condition Failures

      Step 1. Identify Postconditions Associated with Boundaries of Operation

      Step 2. State an Invariant the Postconditions Should Not Violate

      Step 3. Calculate Preconditions

    Further Thoughts: Preconditions, Postconditions, and Invariants in Use Cases

      Preconditions and Postconditions of Individual Operations Versus the Use Case as a Whole

      Scope of Preconditions and Postconditions: Scenario Versus Whole Use Case

      Postconditions Can Have More than One Precondition

      Weak and Strong Preconditions

      Types of Invariants in Use Cases

    Working Smart in How You Apply What You've Learned

      Prioritize Where You Apply Model-Based Specification

      Stick to Numeric Problems

      The Absolute Least You Need to Know: One Fundamental Lesson and Three Simple Rules

    Chapter Review

6. Triple Threat Test Design for Use Cases.

    "Triple Threat" Test Cases?

      Threat #1-The Precondition

      Threat #2-The Postcondition

      Threat # 3-The Invariant

    Applying the Extended Use Case Test Design Pattern

      Step 1. Identify Operational Variables

      Step 2. Define Domains of the Operational Variables

      Step 3. Develop the Operational Relation

      Step 4. Build Test Cases

    Closing Thoughts

    Chapter Review


7. Calculating Your Company's ROI in Use Case Configuration Management.

    Overview of ROI

    Requirements Management Tools

    Calculating the ROI

    Conventions and Starting Assumptions

      Assumptions About Cost of a Fully Burdened Employee

      Initial Actual Data about Use Cases

    The Cost

      Cost of Tools, Training, Consulting, and Rollout Team

      Cost of Tool Use Overhead

      Cost of Added Review and Rigor

    The Benefits

      Savings from Staff Working more Efficiently

Savings from Avoiding the Cost of Lost Use Cases from Staff Churn

      Savings from Avoiding Cost of Unnecessary Development

      Savings from Reducing the Cost of Requirements-Related Defects

    Bottom Line: Benefit to Cost Ratio

    Dealing with Uncertainty in the Model

    Chapter Review

8. Leveraging Your Investment in Use Case CM in Project Portfolio Management.

    What this Chapter Is (and Isn't) About

    The Good Thing About Use Cases...

    Use Case Metadata (Requirements Attributes)

    How Are You Currently Invested?

      Inventory of Projects

      Metadata Needed for Use Cases

      Assign Use Case to Project and Estimate Effort

      Checking the Mix

    Managing the Pipeline

      Full Time Equivalent (FTE) Models of the Project Portfolio

      Run Chart of FTEs Through Time

    Tracking the Status of the Portfolio via Use Cases

      Status of Use Cases

      Tracking the Progress of Projects with the Status of Use Cases

    Chapter Review


Appendix A: Sample Use Case.

Appendix B: Bare-Bones Project Portfolio Database and Use Case Metadata.

    Bare-Bones Portfolio Database

      Use Case Metadata

      Checking the Mix of Project Types

Appendix C: Run Chart of FTEs Required by Project Portfolio.

    Query to Sum Use Case Effort by Project Code

      Query to Prepare Data for Import to Microsoft Project

Appendix D: Reports for Tracking Progress of Projects in Portfolio.

    Metadata for Use Case Status

      Report for Tracking Status of Projects in the Portfolio by Use Case Status




Untitled Document If the Unified Software Development Process (USDP) were a coloring book, I'm afraid I'd be characterized as one of those kids who just can't color within the lines. I've been using use-case-like "things" for quite some time, although they may have been called something else: workflows, scenarios when Object Modeling Technique (OMT) came out, and then eventually use cases. But the funny thing is, more often than not I wasn't using them like the USDP described them being used. Rather, I was combining them first with this technique, and then that one. It's not that I was trying to be a rebel; use cases just seemed to fit in nicely with other techniques to solve a problem. Eventually, as the USDP matured, I began to notice that others were starting to mention QFD in conjunction with use cases and discuss operational profiles of use cases. Scott Ambler added project portfolio management to his Enterprise Unified Process, an extension to USDP; and preconditions and postconditions actually became an official part of use cases. It finally occurred to me: other people were coloring outside the lines too! The motivation for this: problems that were best solved with techniques that were not a part of USDP proper; problems for which other disciplines already had solutions.

It was this realization that led to this book: that my experiences with disciplines, such as QFD, Software Reliability Engineering, Model-based Specification (preconditions, postconditions, and invariants), Requirements Configuration Management, and Project Portfolio Management combined with use cases might benefit others in the use case development community.

This book presents what I hope you will agree is a whole new set of perspectives on use case-driven development. Innovation, solutions to problems, and ways of working smarter often arise when ideas from multiple areas are combined. As use cases continue to mature, future improvements in use case-driven development are likely to arise from just such cross-pollination of use cases with other disciplines of software engineering. This book looks at four areas that focus on quality engineering.

•Quality Function Deployment (QFD)

•Software Reliability Engineering

•Model-Based Specification (Preconditions, Postconditions, and Invariants)

•Requirements Configuration Management/Project Portfolio Management

From each discipline, the book pulls practical, 20/80, "high bang for the buck" ideas that help you and your organization work smart to deliver quality products in use case-driven development.1


1 "Quality" as used in this book is the project stakeholders' (especially customers') relative valuation of scope (functions and features), schedule (speed of delivery to the customer), cost and degree of defect-free operation (i.e. reliability). This is the same definition used by Jim Highsmith (2000) and others in the software quality arena.


Overview of Parts and Chapters
The book is organized into four parts—one per quality engineering discipline—with two chapters each. Here's an overview of what you'll find in each part of the book.

Part 1—Quality Function Deployment
Like it or not, software development is increasingly becoming a team sport! And it's a game being played on a "two dimensional field." Chapter 1, "An Introduction to QFD: Driving Vision Vertically Through the Project," introduces QFD, a team-oriented product-planning tool that is used to translate business drivers into the technical requirements and design aspects of a product. You will learn how to use QFD in use case-driven development as a mechanism for moving vision vertically—the first dimension of the playing field—through projects starting at the senior management/marketing level, where vision is hatched and business priorities are being set, downward to the development team level, so that the product that is released is true to the original vision and business priorities.

The second dimension in which the "team sport" of use case-driven development is played out in a company is horizontally. Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization," looks at the factors that make use case-driven distributed development difficult and the combined use of QFD and use cases to align decisions and synchronize use case-driven development horizontally across multiple component or product teams, or business groups in a company. You'll learn how to use QFD and simple optimization problem-solving tools to find the optimum duration for a development iteration and the optimum set of high-priority use cases that can be implemented in that time across distributed teams.

Part 2—Software Reliability Engineering
Software Reliability Engineering (SRE) is about increasing customer satisfaction by delivering a reliable product, while minimizing engineering costs. Use case-driven development and SRE are a natural match, both being usage-driven styles of product development. What SRE brings to the party is a discipline for focusing time, effort, and resources on use cases in proportion to their estimated frequency of use or criticality, called an operational profile. In Chapter 3, "Operational Profiles: Quantifying Frequency of Use of Use Cases," you'll learn how to build an operational profile for the scenarios that make up a single use case and for a package of use cases. Examples are provided to illustrate the use of operational profiles to enable you to work intelligently in how you plan the activities that affect your product reliability. The chapter concludes by showing how to extend operational profiles to address risk profiling of use case packages.

Your product has been in final system test for days—or has it been weeks? Surely it must be time to stop testing and release it! Chapter 4, "Reliability and Knowing When to Stop Testing," looks at another important concept that Software Reliability Engineering brings to use case development: A concrete way to talk about "reliability." This includes how to define it, measure it, set goals in terms of it, and track it in testing. In this chapter, you will learn how to set quantitative reliability goals in the form of a failure intensity objective. The development and testing group then tracks product reliability in system tests against this objective providing a sound method to determine when the reliability goal has been reached, testing can terminate, and the product can be released.

Part 3—Model-Based Specification (Preconditions, Postconditions, and Invariants)
In Chapter 5, "Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!" you are introduced to a time-tested technique for specifying the expected behavior of abstract data types and objects—model-based specification—and learn how to apply it in a fresh way to pose sharp questions in use case failure analysis: the analysis of potential ways a system, specified by a use case, might fail. In doing so, you'll learn some things about preconditions and postconditions they forgot to mention in "Use Case 101." The chapter concludes with ideas on how to work smartly in applying model-based specification, including the section "The Absolute Least You Need to Know: One Fundamental Lesson and Three Simple Rules," which, if you get nothing else from the chapter, will give you a take away you can apply to any and all use cases right away. The goal of this chapter is nothing less than providing you a whole new perspective on use case preconditions and postconditions.

Not only does the model-based specification with its preconditions, postconditions, and invariants provide an integrated basis for use case failure analysis, taken as a unit they are a veritable triple threat test case. In Chapter 6, "Triple Threat Test Design for Use Cases," you'll learn how to take the preconditions, postconditions, and invariants generated from failure analysis in the previous chapter and design test cases from them using Robert Binder's Extended Use Case Test Design Pattern.

Part 4—Use Case Configuration Management
There is no question that a commercial requirements management tool is useful for use case management; but can it pay for itself at your company? Chapter 7, "Calculating Your Company's ROI in Use Case Configuration Management," looks at a model to help you calculate the Return On Investment (ROI) on requirements management tools for use case management. Not only will it help you decide if such tools make sense for your company, it also helps illustrate some of the types of problems configuration management of use cases is meant to address.

In Chapter 8, "Leveraging Your Investment in Use Case CM in Project Portfolio Management," you'll learn how to leverage your company's investment in use case CM to provide metrics and reports for what could well be the most far-reaching, single process improvement possible in your company: Project Portfolio Management. Project Portfolio Management is the measured allocation of development resources according to some strategic plan. You'll learn how to leverage use case-based metrics and reports to evaluate the mix of strategic project types in the project portfolio and evaluate if projects are executable in the times specified by the portfolio, an approach called pipeline management.

Part 5—Appendices
Appendices A through D provide further supporting materials. They provide more detailed, how-to information that should prove useful as you read the chapters.

Who Should Read What
This book is for anyone doing use case-driven development who wants to think outside the box a little to try some new ideas. Here's some guidance on who should read what parts and chapters of the book, and what background you are assumed to have.

Knowledge About Use Cases
The only assumption made about your background as a reader is that you are already familiar with use cases. The scope of the book does not include an introduction to use cases, UML, Unified Software Development Process, and so on. Many excellent books already cover these topics.

Knowledge About the Other Software Engineering Disciplines
Previous knowledge of the other software engineering disciplines discussed in this book is not necessary. Do keep in mind that whole quality engineering disciplines have been condensed down to two chapters each. These are disciplines that merit whole books, and have large conferences and research and development communities, so what you will see is only a small part of what are large disciplines, but they are parts that yield a good bang for the buck for the use case community. Ample references have been provided to allow you to explore topics in more depth if you desire. A goal of this book is to increase the visibility of these other disciplines to the use case community, and I think references are key to this goal.

For Those Who Hate Math
Two parts of the book—Part 2, "Software Reliability Engineering," and Part 3, "Model-Based Specification"—have a little math in them.

Part 2 involves a little probability and an equation or two, all of which you will be walked through carefully, so no prior background in probability is needed.

Part 3—especially the first chapter—may be the book's most challenging technically, more due to the concepts than the math. The only assumption made is that you are familiar with arithmetic and simple algebra.

Unified Software Development Process
All the ideas in this book can be applied whether or not you are following the Unified Software Development Process (USDP). If you are, however, following USDP you might find Table P.2 useful: It provides guidance on phases of the USDP in which you will find the application of the techniques of each chapter most beneficial. A checkmark indicates the phase in which the techniques as exemplified in the chapter would likely occur. A plus sign indicates other phases in which the techniques could be applied, but which are not specifically illustrated in the chapter.

To review Table P.2, moving top to bottom, QFD is a technique that by design is capable of being applied in all phases of a project. The example provided in Chapter 1 illustrates its use during inception in helping a team decide the focus of a release. The application of QFD in Chapter 2 is focused on planning and coordinating use case distributed development and would be used in elaboration and/or construction.

Chapter 3 is concerned with operational profiles that would be created during elaboration, then their results used in all subsequent phases for prioritization of effort and resource. The setting of reliability goals discussed in Chapter 4 would occur as part of planning done in elaboration. The use of those reliability goals would then be used in tracking reliability growth of the product during testing in construction and transition.

Having used QFD or operational profiles to identify use cases that were frequently used, critical and/or important to business drivers, the model-based specification techniques of Chapter 5 would be used in elaboration for failure analysis of the system as described by those key use cases. In construction, those same techniques could also be used in specifying class or component interfaces using design by contract. In Chapter 6, test planning based on the work of Chapter 5 would be done as part of late elaboration or early construction. The test cases would be used in all subsequent phases as a basis for testing.

Finally, the calculation of ROI on a requirements configuration management tool, covered in Chapter 7, and project portfolio management, covered in Chapter 8, would occur as separate programs apart from any single software product release and so are not applicable to specific phases per se. The results of project portfolio management would of course be used as part of the input to the inception phase of all projects.

How Parts of This Book Relate
Each of the four parts of this book—like the disciplines they pull from—are standalone and can be read and used independently of one another. A few of the techniques can, however, be leveraged off of one another.

Project portfolio management (Part 4, Chapter 8) is over-arching in relationship to all other topics in this book in that stresses in a company due to "too much work, too little time" affect virtually every other aspect of software development and the quality of products produced. A company that has not sorted its vital few projects from the trivial many is likely to have staff with neither the interest nor time for new innovative ideas.

The biggest bang for the buck in applying the ideas of Part 3, "Model-Based Specification," will come from application to use cases that are frequently used and/or are critical in nature. The techniques on describing operational profiles in Part 2, "Software Reliability Engineering," are ideal for identifying such use cases, as are the prioritization techniques of Part 1, "Quality Function Deployment."

It is also possible to use frequency of use information or criticality information obtained from an operational profile (Part 2, "Software Reliability Engineering") as one of many business drivers used to prioritize use cases with QFD. An example of this is provided in Chapter 2, "Aligning Decision Making and Synchronizing Distributed Development Horizontally in the Organization."

Conversely, you may find that a QFD matrix (Part 1, "Quality Function Deployment") is an ideal tool for building informal operational profiles for a product (Part 2, "Software Reliability Engineering").

What This Book Is Not
As with the scope of software projects, it's probably as important to be clear about what this book is not as it is what it is. I've touched on a couple things already, but they are worth reiterating.

The book does not provide an introduction on use cases: what they are, their benefit, or how to write them.

Nor will this book provide an overview of UML or the Unified Software Development Process. In general, this book is largely software development life-cycle neutral. Some of the ideas presented in the book actually work just as well with Extreme Programming's (XP) Stories as they do with use cases, and these will be pointed out.

While you will be getting a good impression of what the other disciplines are about—QFD, Software Reliability Engineering, Model-Based Specification, CM/Project Portfolio Management—the intent is not to present a definitive tutorial on any of these topics. Having said that, what you do get in this book from a use case-driven development standpoint may be all you ever need.

Richard Denney
Austin, Texas


Download the Index file related to this title.



Untitled Document

Errata for Succeeding with Use Cases can be found on the author's web site

Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020