Home > Store

Managing Software Requirements: A Unified Approach

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

Managing Software Requirements: A Unified Approach

Premium Website

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


  • Copyright 2000
  • Edition: 1st
  • Premium Website
  • ISBN-10: 0-201-61593-2
  • ISBN-13: 978-0-201-61593-7

"A comprehensive solution to the requirements challenges faced by every development team. Full of insight and ideas all developers can learn from." --Ivar Jacobson
"Many projects fail for the simple reason that the developers fail to build the right thing: They either deliver a system that does not meet the expectations of its intended users, or they deliver a system that focuses on secondary functions at the expense of its primary use. Drawing on their extensive experience, Dean and Don demonstrate how to employ an industrial-strength requirements process, one that helps ensure you will build the right thing. Developers of any kind of application should read this book." --Grady Booch

Despite the wealth of development knowledge, experience, and tools generally available today, a substantial percentage of software projects continue to fail, often because requirements are not correctly determined and defined at the outset, or are not managed correctly as the project unfolds. Clients do not always know or express their needs precisely, and too often designers and developers do not ask the right questions at the right times. As a result, projects often spin out of control as "feature bloat" and shifting priorities cause budgets and schedules to exceed expectations. Managing Software Requirements focuses on this critical cause of failure and offers a practical, proven approach to building systems that meet customers' needs--on time and within budget.

The authors are skilled practitioners who have spent their careers in the trenches building high-quality applications, including safety-critical, real-time systems. Using an informal, approachable style, their own war stories, and a comprehensive case study they show how designers and developers can effectively identify requirements by employing the power of use cases and more traditional forms of requirements expression. The book illustrates proven techniques for determining, implementing, verifying, and validating requirements. It describes six vital Team Skills for managing requirements throughout the lifecycle of a project: Analyzing the Problem, Understanding User Needs, Defining the System, Managing Scope, Refining the System Definition, and Building the Right System. Managing Software Requirements specifically addresses the ongoing challenge of managing change and describes a process for assuring that project scope is successfully defined and agreed upon by all stakeholders.

Topics covered include:

  • The five steps in problem analysis
  • Business modeling and system engineering
  • Techniques for eliciting requirements from clients, users, developers, and other stakeholders
  • Applying and refining use cases
  • Prototyping
  • Organizing and managing requirements information
  • Establishing project scope and managing customers
  • Using both informal and technical methods for specifying requirements
  • How to measure and improve the quality of your product's requirements
  • Moving from requirements to implementation
  • Verifying and validating the system
  • Managing change

The book concludes with a step-by-step guide to incorporating these powerful techniques into future projects.


Sample Content

Table of Contents




Chapter 1. The Requirements Problem.

The Goal.

A Look at the Data.

Root Causes of Project Success and Failure.

The Frequency of Requirements Errors.

The High Cost of Requirements Errors.


2. Introduction to Requirements Management.


What Is Requirements Management?

Application of Requirements Management Techniques.

Systems Applications.

The Road Map.

The Problem Domain.

Stakeholder Needs.

Moving Toward the Solution Domain.

Features of the System.

Software Requirements.

An Introduction to Use Cases.


3. The Software Team.

Software Development as a Team Activity.

Requisite Team Skills for Effective Requirements Management.

Team Members Have Different Skills.

The Organization of Software Teams.

The Case Study.

Background for the Case Study.

The HOLIS Software Development Team.



4. The Five Steps in Problem Analysis.

Step 1: Gain Agreement on the Problem Definition.

The Problem Statement.

Step 2: Understand the Root Causes--The Problem Behind the Problem.

Addressing the Root Cause.

Step 3: Identify the Stakeholders and the Users.

Step 4: Define the Solution System Boundary.

Step 5: Identify the Constraints to Be Imposed on the Solution.


Looking Ahead.

5. Business Modeling.

Purpose of Business Modeling.

Using Software Engineering Techniques for Business Modeling.

Choosing the Right Technique.

The Unified Modeling Language (UML).

Business Modeling Using UML Concepts.

From The Business Models to the Systems Model.

When To Use Business Modeling.


Looking Ahead.

6. Systems Engineering of Software Intensive Systems.

What Is Systems Engineering?

Pragmatic Principles of Systems Engineering.

The Composition and Decomposition of Complex Systems.

Requirements Allocation in Systems Engineering.

On Derived Requirements.

A Quiet Revolution.

When Generations Collide: Graybeard Meets Young Whippersnapper.

Avoiding the Stovepipe System Problem.

When Subsystems Are Subcontracts.

Making It Work Out Right.

The Case Study.

Preliminary User Needs.

Problem Analysis.

HOLIS: The System, Actors, and Stakeholders.

HOLIS Systems Engineering.

The Subsystems of HOLIS.


7. The Challenge of Requirements Elicitation.

Barriers to Elicitation.

The "Undiscovered Ruins" Syndrome.

The "User and the Developer" Syndrome.

Techniques for Requirements Elicitation.

8. The Features of a Product or System.

Stakeholder and User Needs.


Managing Complexity by Picking the Level of Abstraction.

Attributes of Product Features.

9. Interviewing.

The Interview Context.

Value-Added Context.

The Moment of Truth: The Interview.

Compiling the Need Data.

The Analyst's Summary: 10+10+10 _ 30.

The Case Study.

A Note on Questionnaires.

10. Requirements Workshops.

Preparing for the Workshop.

Selling the Concept.

Ensuring the Participation of the Right Stakeholders.


"Warm-Up Materials".

Role of the Facilitator.

Setting the Agenda.

Running the Workshop.

Brainstorming and Idea Reduction.

Production and Follow-Up.

11. Brainstorming and Idea Reduction.

Live Brainstorming.

Idea Reduction.


Grouping Ideas.

Feature Definition.


Web-Based Brainstorming.

The Case Study: The HOLIS 2000 Requirements Workshop.


The Workshop.

The Session.

Analysis of Results.

12. Storyboarding.

Types of Storyboards.

What Storyboards Do.

Tools and Techniques for Storyboarding.

Tips for Storyboarding.


13. Applying Use Cases.

Building the Use Case Model.

Applying Use Cases to Requirements Elicitation.

Case Study: The Use Cases for HOLIS.


14. Role Playing.

How to Role Play.

Techniques Similar to Role Playing.

Scripted Walkthroughs.

CRC (Class-Responsibility-Collaboration) Cards.


15. Prototyping.

Types of Prototypes.

Requirements Prototypes.

What to Prototype.

Building the Prototype.

Evaluating the Results.



16. Organizing Requirements Information.

Organizing Requirements of Complex Hardware and Software Systems.

Organizing Requirements for Product Families.

On "Future" Requirements.

Business and Marketing Requirements versus Product Requirements.

The Case Study.


17. The Vision Document.

Components of the Vision Document.

The "Delta Vision" Document.

Vision Document for Release 1.0.

Vision Document for Version 2.0.

The Delta Vision Document in a Legacy System Environment.

18. The Champion.

The Role of the Product Champion.

The Product Champion in a Software Product Environment.

The Product Champion in an IS/IT Shop.


19. The Problem of Project Scope.

Components of Project Scope.

The Hard Question.

20. Establishing Project Scope.

Setting Priorities.

Assessing Effort.

Adding the Risk Element.

Reducing Scope.

A Reasonable First Estimate.

The Case Study.

21. Managing Your Customer.

Engaging Customers to Manage their Project Scope.

Communicating the Result.

Negotiating with the Customer.

Managing the Baseline.

Official Change.

Unofficial Change.

22. Scope Management and Software Development Process Models.

The Waterfall Model.

The Spiral Model.

The Iterative Approach.

Life Cycle Phases.


Work Flows.

What to Do, What to Do....


23. Software Requirements.

Definition of Software Requirements.

Relationship Between Features and Software Requirements.

The Requirements Dilemma: What versus How.

Exclude Project Information.

Exclude Design Information.

More on Requirements versus Design.

Iterating Requirements and Design.

A Further Characterization of Requirements.

Functional Software Requirements.

Nonfunctional Software Requirements.

Design constraints.

Are Design Constraints True Requirements?

Using Parent-Child Requirements to Increase Specificity.

Organizing Parent-child Requirements.

Looking Ahead.

24. Refining the Use Cases.

Questions to Ask.

When Are Use Cases Not the Best Choice?

Is Redundancy a problem?

Refining Use Case Specifications.

How Use Cases Evolve.

The Scope of a Use Case.

The Case Study: Anatomy of a Simple Use Case.

Define the Actor(s).

Define the Use Case by Naming It.

Write a Brief Description.

Define a Flow of Events.

Identify Pre- and Postconditions.

Looking Ahead.

25. A Modern Software Requirements Specification.

The Modern SRS Package.

Who Owns the SRS Package?

Organizing the Modern SRS Package.

Documenting Functional Requirements.

Looking Ahead.

26. On Ambiguity and Specificity.

Mary Had A Little Lamb.

Techniques for Disambiguation.

What to Do?

27. Quality Measures of Software Requirements.

Nine Quality Measures.

Correct Requirements.

Unambiguous Requirements.

Completeness of the Requirement Set.

Consistency in the Requirement Set.

Requirements Ranked for Importance and Stability.

Verifiable Requirement.

Modifiable Requirements Set.

Traceable Requirements.

Understandable Requirements.

Quality Measures for the Use-Case Model.

Use Case Specifications.

Use Case Actors.

Quality Measures of the Modern SRS Package.

A Good Table of Contents.

A Good Index.

A Revision History.

A Glossary.

28. Technical Methods for Specifying Requirements.


Finite State Machines.

Decision Trees and Decision Tables.

Graphical Decision Trees.

Activity Diagrams.

Entity-Relationship Models.

Object-Oriented Modeling.

Data Flow Diagrams.

Maintenance of Specifications.

VI. Building the Right System.

29. Building the Right System Right: Overview.

Continually Confirm that the Development Is on Track.

Principles of Software Verification.

The Cost of Verification.

Verification at All Levels.

The Reason for Verification.

Confirm that the Development Results Are Correct.

Learn How to Cope with Change that Occurs During the Development Process.

Looking Ahead.

30. From Requirements to Implementation.

Mapping Requirements to Design and Code.

The Orthogonality Problem.

Object Orientation.

The Use Case as Requirement.

Managing the Transition.

Modeling Software Systems.

Role of the Use-Case Model in Architecture.

Realizing Use Cases in the Design Model.

Structural and Behavioral Aspects of Collaborations.

Using Collaborations to Realize Sets of Individual Requirements.

From Design to Implementation.


Looking Ahead.

31. Using Traceability to Support Verification.

The Role of Traceability in Requirements Verification.

Implicit versus Explicit Traceability.

Additional Traceability Options to Consider.

Using Traceability Tools.

Maintenance of Traceability Relationships.

Proceeding without Traceability Tools.

Omitted Verification Relationships.

Excess Verification Relationships.

Thinking About Verification and Traceability.

Looking Ahead.

32. Validating the System.


Validation Testing.

Validation Traceability.

Requirements-based Testing.

Case Study: Testing Use Cases.

Test Case 1 Description.

Tracing Test Cases.

Testing Discrete Requirements.

Omitted Validation Relationships.

Excess Validation Relationships.

Testing Design Constraints.

Looking Ahead.

33. Using ROI to Determine the V&V Effort.

Depth versus Coverage.

V&V Coverage.

What to Verify and Validate.

Option 1: Verify and Validate Everything.

Option 2: Use a Hazard Analysis to Determine V&V Necessities.

Hazard Analysis as Return On Investment (ROI).

Looking Ahead.

34. Managing Change.

External Factors.

Internal Factors.

"We Have Met the Enemy, and They Is Us".

A Process for Managing Change.

Step 1: Recognize that Change Is Inevitable, and Plan for It.

Step 2: Baseline the Requirements.

Step 3: Establish A Single Channel to Control Change.

Step 4: Use a Change Control System to Capture Changes.

Step 5: Manage Change Hierarchically.

Requirements Configuration Management.

Tool-based Support for Change Management.

Elements Impacted by Change.

Audit Trail of Change History.

Configuration Management and Change Management.


35. Getting Started.


What We've Learned So Far.


Team Skill 1: Analyzing the Problem.

Team Skill 2: Understanding User Needs.

Team Skill 3: Defining the System.

Team Skill 4: Managing Scope.

Team Skill 5: Refining the System Definition.

Team Skill 6: Building the Right System.

Your Prescription for Requirements Management.

Simplifying Assumptions.

The Recipe.

Now, On To the Next Release!

Appendix A.
Appendix B.
Appendix C.
Appendix D.
Appendix E.
Index. 0201615932T04062001


Context and Acknowledgments

The knowledge delivered in this book represents the cumulative experience of a number of individuals who have spent their careers defining, developing, and delivering world-class software systems. This book is not an academic treatment of requirements management. During the 1980s, Don Widrig and I were executives in a small company producing software solutions for customers. When we developed many of the requirements management practices described in this book, our perspective was of those accountable for both the outcomes of the software systems we developed and the results that had to be delivered to shareholders. As the performance of the delivered software was critical to the success of the business venture itself, we tended to discourage petty biases, personal preferences, and experimentation with unproven techniques.

Over the past decade, the techniques have evolved and have been enhanced by new experiences, extended with the help of additional expertise, in different companies and in different circumstances. But all of the techniques presented are "real-world" proven and have withstood the test of time. Perhaps even more important, they have withstood the technological change that has occurred in the industry during this period. Indeed, most of the principles in this book are independent of changing trends in software technology. We can therefore at least hope that the knowledge expressed herein can deliver some lasting value.

Requirements Lessons from Building Software for Others

At first, I just hated computers. ("What? I stayed here all night and I have to submit this batch job again because I left out a 'space'? Are you crazy? Let me in that room....") My first "real computer" was a minicomputer, which, although incredibly limited in performance by today's standards, was unique in that I could touch it, program it, and make it do what I wanted. It was mine.

My early research applied the computer to analyze physiological signals from the human body, primarily EKGs, and the dedicated computer was a wonderful tool for this job. Out of this experience, I began to apply my programming skills and experience with real time software systems to the needs of the industry.

Eventually, I incorporated RELA, Inc., and began a long, and perhaps unusually difficult, career as CEO of a contract software development business. My coauthor, Don Widrig, joined me at RELA in the early years as Vice President of Research and Development. He had the primary accountability for the success of the many systems that we developed.

Over the years, the company grew rapidly. Today, the company employs many hundreds of people and has diversified beyond providing just software to providing complete medical devices and systems that encompass software, as well as mechanical, electronic, optical, and fluidics-handling subsystems. However, at the heart of each and every machine, including the latest DNA fingerprinting in vitro diagnostic clinical laboratory, lies one or more computers, reliably and routinely delivering its steady heartbeat through the rhythm of a real-time multitasking system.

Initially, we would program anything for anybody, from antenna positioning software to such games as laser tag, automated guided vehicles for amusement parks, educational products, welding robots, and automated machine controls. We even developed a large distributed computer system that auto-matically detected and counted the presence of commercials on television. (Our motto then was "We make computers to watch commercials so you don't have to!") Perhaps the only thing the software we developed was that we developed it for others--we were not domain experts in the field, and we couldn't cover our own paychecks if we had to. We were completely dependent on the cus-tomer's satisfaction as the final determination of outcome. In many ways, such an environment was very conducive to effective requirements management. Here's why:

  • We knew little about the domain, so we were dependent on customers for the requirements. There was little temptation to simply make them up; we had to ask, and we had to learn how to ask the right questions the right way, at the right time.
  • Our customers often knew little about computers, so they were dependent on us to translate their needs and wishes into technical requirements.
  • The fact that money changed hands created a rigorous interface between the developer and the customer.
  • Quality was easy to measure: We either got paid or didn't.

It was in this environment that we discovered the first of two fundamental questions that face software developers on each and every project. This question dominated our behavior for many years and remains today as perhaps the toughest question to answer in any software project. And the Big Question is:

Big Question 1: "Exactly what is this software supposed to do?"

The principles and techniques presented in Team Skill 1, Analyzing, the Problem; Team Skill 2, Understanding User Needs; and Team Skill 3, Defining the System, were developed over more than a decade as a means to discover the answer to this question. Each of these techniques has proved its worth and has demonstrated its effectiveness in many real-world projects. It was also during this period that I first became aware of the work of Donald Gause, and Jerry Weinberg especially their book Exploring Requirements: Quality Before Design, (1989). Because their book heavily influenced our work, we have borrowed a few key concepts from it for this book, both because the concepts work and because we thought it only fair that you share the Gause and Weinberg experience.

Lessons from Building High Assurance Systems

Over time, RELA began to specialize in the development of various types of computer-based medical devices and systems: portable ventilators (breathing machines), infusion pumps, pacemaker programmers, clinical diagnostic systems, blood pumps, patient-monitoring equipment, and a plethora of other diagnostic and therapeutic devices.

It was early during the ventilator development project that the ultimate accountability for what we were doing really hit us: Whoa, if we screw this up, somebody could die! Our primary concern was for the patient and for the family of the patient who was tethered to the device, a device on which we were executing some of the earliest, most time-critical, resource-limited software the world had yet seen. (Imagine the challenge of alpha and beta testing. You go first!)

Clearly, this high-stakes endeavor caused us to take software very seriously at a fairly early time in the evolution of the embedded-systems industry. It became clear very quickly that sustainable success would require a combination of

  • A pragmatic process for defining and managing the requirements for the software
  • A solid methodology for the design and development of software
  • The application of various proven, innovative, techniques for verifying and validating that the software was safe and effective, and
  • Extraordinary skills and commitment on the part of both the software development and software quality assurance teams.

I strongly believed at that time, and I am even more convinced today, that all of those elements are required to deliver any reasonably reliable software system of any significant scope. At RELA, Inc., this was to be the only way we could possibly ensure each patient's safety, the very survival of our company, and the economic futures of the employees and their families who depended on the company.

Given our earlier success in the development and application of the various techniques we used to answer Big Question 1, we now moved on to the second fundamental question facing software development teams worldwide. Big Question 2 is

Big Question 2: "How, exactly, will we know when the software does exactly that and nothing else?"

The techniques we used to answer this question form the basis of Team Skill 5, Refining the System Definition, and Team Skill 6, Building the Right System.

So, you can be confident that the techniques presented in this book are road hardened and well proven. Also, even if you are not in the business of developing safety-critical systems, you can rest assured that what follows is useful, practical, and cost-effective advice that you can use to develop software systems of the highest quality.
Although the techniques that we borrowed, modified, developed and applied at RELA, Inc., to address the two big questions were highly effective, I must also admit to one nagging uncertainty that kept me awake during the most serious crunch times on these projects:
"Given the highly manual nature of the requirements process, how long would it be before we made a single, but potentially dangerous, mistake?"
And there was also the matter of cost, as manual verification and validation were expensive and error prone. During this period, the discipline of mechanical engineering had advanced from a mechanical drawing arm to 3-D computer-aided design systems. In the same period, our software advances were limited, for all practical purposes, to having increased the level of abstraction in our programming languages: a good thing, for certain, but defect rates, lines-of-code productivity factors, and quality measures were relatively constant. Our experiments with the CASE tools of that period were met with mixed results. Frankly, as a software engineer and entrepreneur, I found the state of the art in "software engineering" to be embarrassing.
Although it was obvious that automation would never eliminate the critical- thinking skills required in software development, I did become convinced that automating some of the manual, record-keeping, and change management aspects of the process would free scarce resources to focus on higher, value-added activities. And, of course, we anticipated that development costs would be lower while reliability would be increased!

Lessons from the Requirements Management Business

So, in 1993, REQUISITE, Inc., was born, and a number of us committed to a course of action to develop and to market an innovative requirements management tool: RequisitePro. As we were continuously helping customers address their requirements management challenges during this time, much additional material for this book was born. We owe much of this work to those customers, and the customers at RELA, who essentially taught us everything we know on the subject.

This portion of my career was heavily influenced by Dr. Alan Davis, who was Editor in Chief of IEEE Software magazine and held the El Pomar Endowed Chair of Software Engineering at the University of Colorado in Colorado Springs. Al joined the company as a director and advisor early on and was instrumental in influencing our technology and the business direction. He is well known for his leadership in the field of requirements engineering. Al was also active in consulting activities and had developed a number of techniques for helping companies improve their requirements process. These techniques were merged with some of the RELA-derived techniques and became the basis of a professional training offering called Requirements College, the basis for parts of this book.

In addition, operating under the insufficiently popular business theory of "you can never have too much professional help," we recruited renowned software author and expert Ed Yourdon to join the board of the company. Ed was also highly influential in guiding the course of the technology and busi-ness direction. Both Ed and Al were earlier contributors to this work, and many of the words that appear in this book are theirs. Indeed, we had intended to release the book jointly a few years ago. But times change, and Ed and Al have graciously donated all of their earlier work to us. However, you will often hear them speaking through these words.

Experiences at Rational Software

Rational Software Corporation purchased Requisite, Inc., in 1997. At Rational, we have gained significant additional experience in requirements management as it applies to developing and releasing a full family of application development tools, as well as continuing to help customers address their requirements problems. Don continues to work with us and help refine the techniques. In addition, at Rational, I have had the pleasure of working with software experts and authors Grady Booch, Ivar Jacobson, James Rumbaugh, Walker Royce, and Philippe Kruchten. Each of them contributed to my view of the requirements management challenge, and Walker and Philippe were early reviewers of this work.

We also became exposed to the use case technique for requirements capture. The application of notion of using use cases within the design model pro-vides a common thread to drive architecture, implementation, and testing.

I am also a fan of Rational's promulgation of the iterative approach for software development, of which I like to think that we were early practitioners at RELA, as well as the Rational Unified Process, a full life cycle software development process.
Rational helped me complete this work, and for that I am grateful. Also, Rational graciously provided permission to use certain ideas, text, and diagrams.
Finally, we would also like to thank the reviewers and many others who contributed to this work, including Al Davis, Ed Yourdon, Grady Booch, Philippe Kruchten, Leslee Probasco, Ian Spence, Jean Bell, Walker Royce, Joe


In a sense, few, if any, ideas in this book are original. Instead, it represents harvesting the shared software development experiences of two decades, with a focused, consistent, and measured emphasis on the requirements challenge. In so doing, the work, we hope, assimilates the experiences and opinions of some of the best minds in the industry on this unique and difficult software challenge. We firmly believe that the result--these six requisite team skills for effective requirements management, will help you deliver quality software systems on time and on budget.



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