Home > Articles > Information Technology

  • Print
  • + Share This
This chapter is from the book

Requirement Organization

The development of any Internet-based application requires the development of different work products that stem from the idea. Each of these work products is needed to build a high-quality Internet-based application. Each of these individual work products follows a process similar to a manufacturing process described in the previous chapter. Community, perspective, and focus are dimensions of the organization, which when working together will develop one or more of these work products.

This process is no different from any other manufacturing process. The perspective is the evolution of any product. The development of any product requires different roles for building each piece of the product. To explain the finer details of the framework and the association between categories, the example of building a house is used below.2

A Quality Home

When a house is being built, the idea (or architectural plan) evolves through perspectives (levels of abstraction from the concept) to produce a deliverable (the home). Each different perspective refines the details until the house is built. Each perspective is paired with a specific individual (or contractor) to build a deliverable that assists in creating the final product (see Table 3.1). The deliverable is built according to the perspective of the responsible individual. Each of these phases evolves from the information gathered and analyzed from the previous phase. Each phase has the perspective of another individual role. Figure 3.5 shows those involved in developing a home. Each individual with his own focus evolves deliverables (work products) through the different perspectives.

Table 3.1 Manufacturing a Home

Manufacturing Phase


Output Perspective

The birth of an idea

A ballpark view of how big, how many rooms, etc.; documents the scope


Analyzing the feasibility

A small model depicting and confirming understanding; provides the vision and funding


Designing the product

A detailed design of what is to be built; specifies the physical design


Developing the product

The specifications of how to build it; constructs the physical product


Assembling and testing the product

The individual components; provides the components


Implementing the product

The house; utilizes the end product


Figure 3.5 Perspectives and Focus Areas for Building a Quality Home

Skipping a perspective in building the home increases the risk of building a faulty home. No one would want to live in a home they knew had skipped a phase of this process. Instead, inspectors are available at each phase (perspective) to spot possible defects and correct them early in the process (quality gate). The cost of correction after implementation, if possible at all, is too risky and expensive. To further reduce the cost of building a home, specifications or any of the deliverables from each phase can be reused or expanded upon to build other homes.3 This is only doable if the deliverable passed quality inspections for the original product.

The House That Zachman Built

In 1987 while working for IBM, John A. Zachman published a framework for discussing information systems architecture.4 He described the analogy between the software development process and the construction and manufacturing processes. This architecture is the basis of the requirements set framework. To understand the requirements set framework, it is important to understand John Zachman's architecture.

Zachman illustrated how the process, deliverables, perspective, and focus are conceptually the same. The process can also conceptually be the same for different business communities (for example, legal, human resources, and shipping). For simplicity, we will focus on software products for this example. The output of software development deliverables correlates to architectural output (see Table 3.2). The table documents the evolution of the software detail and how it is a process similar to construction and manufacturing.

Table 3.2 Software Development Deliverables Compared with Architectural Output

Manufacturing Phase

Architectural Output

Information Technology Output

The birth of an idea

A ballpark view of how big, how many rooms, etc.; documents the scope

The scope of the investigation for the software product

Analyzing the feasibility

A small model depicting and confirming understanding; provides the vision and funding

The vision or business view of the software product to be developed along with the appropriate funding

Designing the product

A detailed physical design of what is to be built

The detailed physical representation of the software product to be built

Developing the product

The specifications of how to build it; constructs the physical product

The detail specifications of how the software is to be built

Assembling and testing the product

Provides the individual components

The actual software code and file definitions

Implementing the product

The house; utilizes the end product

The software product

Different Perspectives for Either Process

The roles involved in building a home (see Table 3.3) identify the need for different perspectives. Each individual has a responsibility to concentrate on his particular perspective to ensure the building of a quality end product. As the evolution of the idea to final product occurs, different phases are followed through the different perspectives. Perspectives reflect the areas of responsibility of each role. For example, a designer's perspective is quite different from the owner's perspective; the builder's perspective is different from a designer's. What is important is that the owner's perspective is satisfied in the final product. Though each role has a different perspective, all roles work together as a team to build the quality end product

Table 3.3 Information Technology Community Perspective

Manufacturing Phase

The Architectural Perspective

The Information Technology Perspectivea

The birth of an idea


Business executive

Analyzing the feasibility


Business representativeb

Designing the product


Systems analyst

Developing the product



Assembling and testing the product


Quality analyst

Implementing the product


Business end user

the builder's perspective is different from a designer's.5 What is important is that the owner's perspective is satisfied in the final product. Though each role has a different perspective, all roles work together as a team to build the quality end product.6

The same is true with software development (including Internet-based products). Each phase (see Table 3.3) has a different perspective. Each phase develops another level of detail to build the final quality product. What is important is that the perspective of the "owner" (business executive) is satisfied in the final product.

Different Perspectives for Requirements

Each of the Zachman framework perspectives involved defining requirements and requirement details (see Table 3.4). The first three perspectives are require requirements that are more commonly referred to as "business requirements." The first perspective (planner) identifies the list of what is in and out of scope (primary requirements) as it relates to the initiating requirement (the product concept). The second perspective (owner) defines the requirements and their dependencies (derived requirements) on other requirements. The third perspective (designer) defines the specific details that are essential in defining the requirements and their relationship with other requirements. The details may include additional derived requirements due to the specific interaction between business communities.

Table 3.4 Perspective Requirements

requirements) as it relates to the initiating requirement (the product concept). The second perspective (owner) defines the requirements and their dependencies (derived requirements) on other requirements. The third perspective (designer) defines the specific details that are essential in defining the requirements and their relationship with other requirements. The details may include additional derived requirements due to the specific interaction between business communities.

Manufacturing Phase

Zachman Perspective

Information Technology Translation

Requirement Deliverable

The birth of an idea

Entity classes and scope (planner)

Defines the scope of the investigation

Lists descriptive needs by each business community that define the scope of the investigation; includes lists of what is to be investigated and what is not included

Analyzing the feasibility

Model of the business (owner)

Defines how the business communities view the scope

Takes the lists one step into descriptive detail by providing association and dependencies between requirements (relationships)

Designing the product

Model of the information system (designer)

Defines the essential details to run the business; still technology independent

Each requirement and its relationship with other requirements within and outside of the business community fully attributed with the details that clearly define the need

Developing the product

Technology model (builder)

Defines the technological solution to the logical view; technology dependent

Derived requirements associated to specific needs of the builders to help them develop the solution to the requirements

Assembling and testing the product

Technology model (subcontractor)

Assembly and testing

Derived requirements associated to specific needs of the testers and distributors of the solution to help them implement the solution to the requirements

Implementing the product

Functioning system (user)


Continue capturing feedback for process improvement or product improvement requirements

The fourth perspective (builder) is the break away from the business requirements. These define specific requirements (derived requirements) that need to be satisfied in order to build the solution. These requirements may or may not be captured by the requirements engineer. In some companies, technology specialists such as a database administrator or technical architect may capture these requirements. In truth, these specialists are the suppliers of this perspective's requirements. It is the responsibility of the requirements engineer to ensure that the requirements are elicited, analyzed, specified, validated, and approved (especially high-price items or items that go against corporate standards) and to ensure they are managed.

The fifth perspective (subcontractor) begins the process for the next iteration of the product. These requirements include what metrics or information should be captured in order to judge the success of the product. For Internet applications, requirements may state the need to capture customer feedback, click history, response time, and sales figures. These are requirements geared toward understanding the success of the first iteration and providing valuable information that could foster a change in direction to retain market presence.

The sixth perspective (user) is the implemented product or iteration. Requirements relate more to the next iteration of the product, thus initiating the next cycle, which begins with the planner perspective.

Each business community has the same perspectives; each perspective for each community has a different specification. Each perspective follows the same subprocess to elicit, analyze, specify, validate, and approve the requirements for its community and perspective.

Different Views of the Same House

When building a home, each phase or perspective requires a different focus or view. These views concentrate on a specific area for that perspective. For example, the house requires an architect's view, a plumber's view, an electrician's view, a landscaper's view, and so forth (see Table 3.5). Each has similar deliverables: scope, owner's model, physical model, specifications, components, and the final product. Each deliverable at each perspective level has its own focus. Each focus (see Table 3.5) still has the same architectural perspective. Nothing can be viewed independently! All views and perspectives are important to build a high-quality house. Each focus area must narrow down a concept into finite detail to ensure compliance and quality and to ultimately meet the owner's needs.

Table 3.5 Focuses for Building a Home

The Architectural Perspective

Architect's Focus

Plumber's Focus

Electrician's Focus

Landscaper's Focus

Planner: documents scope

Planner: number of rooms, size of property, etc.

Planner: number of facilities, features, etc.

Planner: number of connections, etc.

Planner: number of shrubs, trees, sprinklers, etc.

Owner: documents view

Owner: look of building

Owner: look and location of kitchens and bathrooms

Owner: each room's electrical requirements

Owner: layout of the outside

Designer: documents design

Designer: physical design and material of the house

Designer: physical design and material for the water rooms

Designer: physical design and material of the electrical system

Designer: physical design and material of the landscape

Builder: documents specifications

Builder: detailed specifications on how to build the house

Builder: detailed specifications on how to insert the plumbing

Builder: detailed specifications on how to wire the house

Builder: detailed specifications on what and where to plant

Subcontractor: documents components

Subcontractor: the building

Subcontractor: the plumbing

Subcontractor: the electrical wiring

Subcontractor: the trees and shrubs

User: uses the final product

User: the home

User: the kitchen, laundry, and bathrooms

User: the electrical outlets and fixtures

User: the landscape

Different Focuses of the Same Software Solution

Building software solutions also requires different focuses. In his Information Systems Architecture, John Zachman identified the following areas of focus:7

  • Who is involved (people/organization/systems)?
  • What is it made of (data)?
  • Where are things located (network)?
  • When do things happen (business events)?
  • Why are things done (business policy)?
  • How does it function (process)?

Though we are concentrating on the business area of information technology, the same focuses apply to each of the other business communities: business practice, business organization, and business support. Each of the business communities has a deliverable that has "who, what, where, when, why, and how" requirements to capture. They all need to be elicited, analyzed, specified, validated, and approved in order to build the specific deliverable.

The purpose of drawings, models, and other documentation deliverables is to enable the reviewers and those who must act on the deliverables to relate to them and to agree or disagree with the contents. The deliverables, in respect to requirements, are specifications used to validate for quality and to build upon.

Let's walk through the focus (special interest) areas to obtain an understanding of the specifics of each one. Note that each of these focus areas captures the functionality the product must have. This functionality lives with the product through each iteration until either the requirement is no longer needed or the entire product is no longer needed.

The People ("Who") View

This view focuses on associations to the product. The importance is that all the people, departments, organizations, and systems that interface with the product are well documented as to their needs. They trigger action on the part of the product.

The "who" needs include supplying information, accessing information, triggering functionality, and receiving results (such as reports). For example, a customer may submit an order and receive merchandise. The Internal Revenue Service may also be involved by being the recipient of quarterly financial reports. For the book retailer example, the shipping company personnel may have access to the book retailer's system in addition to the book retailer personnel having access to portions of the shipping system. For B2B, both forms of access from opposite systems are documented. In the world of the Internet, businesses, including competitors, are users. This category of requirements may need information such as supplier data.

It is important to also note who should not have access to the product. This observation spawns additional security-related requirements. The most common example in traditional manufacturering is the childproof cap used on medicine bottles. For the book retailer application, requirements could call for a user-initiated security key of the user's specified functionality and information. The objective is to prevent hackers from obtaining valuable customer or company information.

"Who" refers to the product interfaces. At each perspective, the interfaces may evolve into identifying security requirements as to what information they may have access to and what functionality they may perform. At the first perspective, you have a list of who should have access. You have a second list that clearly defines who should not have access. The "should not" list evolves as you refine the requirements through each perspective for specific functionality and information.

The Information ('What") View

This view focuses on the information requirements of the product. For software, this describes all the data needed to fulfill the requirement. For the book retailer and shipping connection, examples are the pickup location (warehouse) and the delivery location (customer site).

"What" represents the data needed by the Internet-based application. Data come in different forms, thanks to multimedia. Data can be textual, video, graphical, animation, and audio, all of which can be transmitted via files or messages across the Internet on cable, telephone, or wireless connections. The information can be distributed to PCs, laptops, televisions, personal digital assistants, and cellular telephones. All of these details are captured as requirements evolve through the different perspectives.

Data or object models are the most common deliverables in defining the "what" requirements. The models are more than just diagrams. A model contains textual information about the contents of the diagram. In fact, the diagram supports the textual description. Data and entity classes can be classified as information models for the purpose of explaining the "what" focus area.

An information model defines the common business vocabulary. Getting concurrence on specific definitions is the challenge of all good modelers. The models and the diagram depict relationships. These relationships define many of the business rules that must be supported. For example, a person cannot place an order without supplying at least one valid credit card number and a valid address. In the United States, the credit card address may be a post office box, but a shipping address must be a street address (a common oversight made by many online shopping sites) if a non–United States Postal Service (USPS) company is used.

Technical information models organize the information for performance for a specific technology. They are a step removed from defining the business. Both the business information model (defined at early perspective levels) and the technical information model are required. The technical model is built from the business model and will change more frequently than the business model. These changes are typically intended to improve performance or to take advantage of new technologies. These technology-related changes rarely affect the business model. However, any changes to the business model must be reflected in the technology model. The business model defines the business; the technology model defines how the business is supported technically. The businesspeople validate the business model, whereas technicians (and requirements engineers) validate the technology model.

In many business information models, audit trails may be left to the technology models. This is not true in the Internet world. When capturing "what" requirements, it is important to include confidential information that will provide audit trails. This requires information about the data that was captured: when and by whom. It must be proven that a transaction took place (especially changes and deletions). This information must be incorporated and approved by the business community.

The Location ('Where") View

"Where," the third focus area, represents the location or networking type of requirement. The "where" requirements, as with the "who" and "what" requirements, evolve through the different perspectives. Unfortunately, many requirements engineers capture this type of information later rather than earlier in the process.

Network engineers must meet the expectations of the different users as well as maintain the network infrastructure for the organization. Their requirement needs may be captured in other focus areas, but they must still take that information and reformulate it into their own models, evolving them into router configurations and other network work products. The information they need to capture includes

  • The type of access by user, event, and function. The type of access could be batch file, online access, wireless access, or Internet access. Knowing this information assists in determining the type of communication that is needed to meet the requirement of the user.

  • What is needed at each location. This includes what data and how much data will be transmitted from one node to another. How often will the transactions be executed? Are there peak periods? The objective is to determine the load on the network.

  • Security requirements for each location. This includes security at the data and function by actor ("who") and access type. For example, a wireless transmission to a mobile telephone may be restricted to only summary information.

The "where" view focuses on connectivity. This entails describing the desired location where the product will be used and who must have access to it. For a stock-trading system, locations may be worldwide. Wireless has added a new dimension to the Internet. Devices such as handheld organizers can connect to the Internet application from anywhere. No longer must a device be physically attached. For the "where" requirements of an Internet application, location pertains to the traffic concentration areas for the customer base and the functions and amount of data they transmit.

The Event ('When") View

This view focuses on timings that trigger action by the product. It identifies when things must or usually occur, for example, the closing of the U.S. stock market at 4 p.m. EST. Can the book retailer accept the order for a next-day delivery request with the shipping company's logistics plan? The shipping company may have rules on what they can pick up late in the day and still be able to deliver to certain locations within a 24-hour period.

There are four basic types of events:

  1. Initiated by time (for example, order received past shipper's latest pickup time)

  2. Initiated by action from outside the product (for example, order placed for next-day shipment)

  3. Conditionally triggered (for example, back-order products arrived at warehouse)

  4. Arrival of information (for example, order picked up)

There are different models that can be created to reflect "when" requirements. The first perspective includes lists of the events with a list of associated responses. The events are to be correlated (requirement relationship) with "who" requirements in the detailed perspective, along with a list of conditions and actions the event incurs. When capturing the essential requirement details, the correlations between "what," and "how," and "where" as well as other focus areas have not yet been discussed. The point is that just as with any of the other focus areas, the "when" requirements evolve in detail and level of abstraction through the different perspectives.

The Rule ("Why") View

This view focuses on business rules and policies that must be adhered to when arriving at the solution. Rules are critical to the survival of a corporation. They can never be violated. Rules are defined for both normal and abnormal business circumstances. For example, an automobile can be sold as "new" only once during its life. A stock trader cannot cancel a submitted stock trade (buy) if the other party has already submitted his side (sell) of the transaction. The information about a customer order cannot be displayed if it is marked as secure without a password being supplied by the user.

The Internet has changed the way business is conducted. This means that the current business rules and policies that exist may need to be changed or tweaked or perhaps totally abandoned. This is a new economy based on a new business model that is filled with a new set of business rules. Keeping outdated business rules in place can limit business opportunities on the Net!8

Rules define the policies for a particular situation. When the situation in question occurs, it is an obligation that the rule be satisfied. These rules may affect the other focus areas, and these other focus area models must include a correlation to the business rule.

Some rules are defined outside the organization, including governmental (legal, IRS) and others rules dictated by competitors or the culture of the times. For example, state laws may prohibit a car from being sold as new when the mileage exceeds a specific number, which varies from state to state. Another example is the tax applied to the purchase. Is the ship-to or the ship-from tax charged according to the product's or service's value, and is it according to the date of order or the date shipped? This also varies from state to state and from country to country.

Policies that control the processing of the organization are usually defined internally. They define the culture and style of the organization. For example, the business rule for an Internet application for purchasing merchandise may state that the item must be requested from the supplier when the inventory dips below a specific level. Each item in the inventory may have its own specific reorder business rule.

Rules can also be technical in nature. For example, when the transaction reaches a specific level on the network, additional lines, typically reserved for backup situations, will be used to handle short periods of unexpected traffic.

There are five different types of business rules:

  1. Constraints: limiting instructions. A person must respond to an end-of-auction notice within three days.

  2. Heuristics: characterization instructions. A customer in good credit standing should be notified of sales of similar products that have been purchased by the customer in the past.

  3. Computations: calculation instructions. Foreign currency will be calculated by using the value of the currency for the day the item was shipped multiplied by the price of the item.

  4. Inference: implied instructions. A customer who charges 35 percent more than his average daily transaction level will be placed on the customer watch list.

  5. Timing: conditional instructions. Once a back-ordered item is received in the warehouse, it must be shipped to the next customer in line by the end of the next business day.

Timing is a type of rule associated with or often documented as a "when" requirement. In fact, all the business rules must be associated with other focus-type requirements. They may correlate to "what, how, when, and where" requirements. They may affect community requirements other than those of information technology. It is important during validation to evaluate each business rule for its impact on other requirements.

The Process ("How") View

This view focuses on the workflow of a specific function: the procedure, step by step. For example, an invoice that is 30 days past due requires a secondary notice and placement of the client's name on the delinquent watch list. Alternatively, for the online access to your customized view, one of the process requirements could describe:

  1. If an incorrect password is supplied to retrieve secure information, the user will be allowed three opportunities.

  2. If after the third opportunity the correct password is not supplied, the secure data will not be displayed.

  3. If the user has forgotten his password, he is allowed to select the "secret word" to remind himself of the password.

  4. If the user assesses the "secret word," another opportunity to supply a correct password is made available.

  5. If the password is correct, the system displays the information.

  6. If the password is incorrect, the system notifies the user that he can request a new password.

In our Internet example, the key business processes for the book retailer are

  • Order entry: includes presentation and ease of use for the client

  • Payment: involves calculating the cost of the product plus any surcharges (taxes and delivery) in the client currency via the acceptable methods (credit card, bank note, and so on)

  • Delivery: involves packaging the requested item (virtual or physical) and delivering the goods after the payment has been determined acceptable (but not cleared)

  • Inventory management: involves the supply chain

  • Settlement: involves the actual conversion for goods and services


The following rules of thumb depict the average number of functional requirements. This is helpful when you are planning the requirement effort. It is also helpful when taking a first cut at validation to identify whether you have a complete set of requirements for a specific community, perspective, and focus. Again, this is just a rough estimate to raise a potential flag that something may be missing from the requirements set.

  • There should be a "how" requirement associated with every "when" requirement.

  • There should be five "how" transactions requirements (including object methods) that impact a business entity "what" to support: (1) a create function, (2) a read function, (3) an update function, (4) a delete function, and (5) a list (includes search) function.

  • There should be at least one requirement for each cell (category described by community, perspective, and focus).

  • There should be a business rule "why" for every relationship between "what" entities or entity classes.

  • There should be a "who" associated with every "how," "when," and "where" requirement.

These guidelines pertain to functional requirements. As shown in the next section, functional requirements are only a portion of the requirements set.

Extensions to the Information Systems Architecture

The Zachman framework for Information Systems Architecture ties the perspective, focus, and deliverable together for developing software (see Figure 3.6). To develop a business solution using information technology requires different integrated views and details. The contents of each cell identify possible deliverables for a software development project. This comprises the functional focus. These areas describe what features the Internet product must have and perform.

Figure 3.6 Perspectives Objectives

Additional Focuses

Two additional focuses are required to cover the needed information to build the product, as they constrain the product development decisions. One area describes the constraints that must be applied to the product, and the other the constraints on running the project.9 These are called nonfunctional requirements.

  1. The product constraint's view documents any restrictions that may affect how the product will be designed. In system engineering terms, these would include the system requirements10 pertaining to expectations as far as response time, security, and fault tolerance. Design constraints could also include restrictions as to the size of the application. Here they describe the environment and operation of the product. They may be referred to as quality of service (QoS) requirements.

  2. The project constraint's view documents any restrictions that may affect the running of the project. This might include the number of resources and time constraints.11 (Restrictions of tools, standards, and formats also fall under the category of project constraints.12)

The requirements that fall into these views should be written in a format that meets the same quality characteristics as functional requirements. They evolve through the same perspectives as the product's functional requirements. These additional focus areas include requirements that are crucial to the success of the Internet application.

  • + Share This
  • 🔖 Save To Your Account

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