Use the inter-system interface requirement pattern to specify basic details for an interface between the system being specified and any external system or component with which it needs to interact.

Do not use the inter-system interface requirement pattern for user interfaces (though you can treat interactions to user devices and user interface infrastructures as inter-system interfaces if they behave in a similar way to an external system). Also, do not use this pattern for internal interactions between different parts of the system, unless an external system might participate in those interactions at some time in the future (that is, if it might become an external interface).

Getting one system to cooperate with another can be a time-consuming and unpredictable undertaking. Developers might have little idea how hard it will be to implement a particular interface until they get their hands dirty. If we're using an interface defined by someone else, it might not do exactly what we want or might not work as we expected; if we're designing the interface ourselves, we're dependent on the owners of the other system to implement it properly. As a result, it's important that we treat inter-system interfaces with respect and that we don't underestimate their complexity: give them plenty of visibility, pin them down as early as possible, and allocate them sufficient resources. Often these don't happen, in many cases because the requirements specification glossed over the interfaces—or even failed to recognize some altogether. As a result, a system's interfaces might be weak links.

This requirement pattern cares neither about the nature of the interface nor whether the external system is local or remote. It uses the general term "interaction" to describe an activity across the interface (which usually means an exchange of information).

Every requirements specification should contain a system context diagram, and it should be near the beginning. (See the Scope section in Chapter 2.) This is where interfaces make their first appearance, so take the opportunity to give them star billing. On the context diagram, show all external systems (and other components) with which our system needs to interact, and label every connection to them explicitly with an interface ID. Figure 5-2 shows a sample context diagram with features related to interfaces indicated.

There are several points to observe. First, each interface is identified by its unique interface ID (using the convention described in the Content section later in this pattern). Next, each interface ID is either inside or outside the boundary line of the system's scope. Every interface must eventually be either wholly inside or wholly outside. If ownership of the interface has yet to be determined, the interface can be shown straddling the scope boundary; highlight this unresolved issue with a large question mark. Finally, when there are multiple similar systems to which to interface (such as the multiple credit card clearing houses in Figure 5-2), each must be treated separately, because they are all different. The connection to each is a separate interface. Don't lump an indeterminate number together. See the Interface Adapters section that follows for a discussion on how to handle interfacing to multiple systems for the same purpose. If we need to be able to handle multiple instances of a particular type of interface, then there are various extra factors to consider—such as deciding which to use and when. These factors are discussed in the extendability requirement pattern in Chapter 10 .

Figure 5-2. Sample system context diagram

Interface Adapters

We're building a beautiful new system. We want to keep at arm's length anything messy that would spoil its pristine elegance—such as having an indeterminate number of interfaces of some kind (like the credit card clearing houses in Figure 5-2). We can avoid our core system dealing with lots of external interfaces for the same purpose by interposing a single interface of our own choosing and plugging in a piece of software, called an adapter, to do whatever's necessary to convert this into what a particular external interface expects. This is shown conceptually in the following diagram:

The core system deals only with a single interface for this purpose (I_A), and the adapter deals with the external component's interface (I_E). We can build as many different adapters as we need to. This is especially beneficial when building a product because third parties (including our customers) can build their own extra adapters, and we don't have to modify the core system every time. We can, on a case-by-case basis, place each individual adapter either inside or outside the scope of our system.

If there's a widely-accepted standard for a particular interface, we could adopt and use that interface—yet we might still encounter external systems that don't use it. In this situation, we could build adapters for the one-off cases but would need no adapter for the standard interface. Before adopting an externally-specified interface definition and asking third parties to use it, first check whether you're allowed to; it might be proprietary and confidential or carry licensing restrictions.

Adapters are ordinarily a design matter, but it becomes very beneficial to introduce them in the requirements whenever we want the freedom to place interfaces of a particular type in scope and leave some out of scope. See the extendability requirement pattern in Chapter 10 for discussion of additional factors.

Between two systems, there might be more than one interface (for example, a custom messaging protocol for transactions and email for sending monthly reports). Treat each different communication medium as a separate interface, because they'll have to be built and tested separately and will function independently.

Interfaces that are wholly within the system's scope (and don't involve any component outside that scope) normally don't need to be dealt with in requirements. One exception is if development is to be split between multiple teams (especially if one team is not in-house or if the teams are physically remote from each other). Requirements can only deal with this if it's known at requirements time and if the system is clearly segregated—in effect, if we're specifying a "federation" of systems. Another exception is when we envisage part of our system being spun off in the future and used by other systems (as for the Access Controller in Figure 5-2).

If interfacing to a third-party system, it is reasonable to define requirements that its supplier must satisfy: documentation, performance, availability of a test system, test accounts and so on—everything we need to be able to build and test our end of the interface. Bear in mind that third parties might have very different standards and abilities from those of your organization; they might be capable of meeting far higher professional standards than you need—and might charge you accordingly if you use them. At the other end of the scale, they might have poorer practices and skills than your own developers.

An inter-system interface requirement contains the following:

A single requirement like this usually isn't sufficient to fully specify the interface (although it might refer to a standard that does). Its main role is to give the interface "official recognition," so it's treated with the respect it deserves.

An inter-system interface requirement might be followed by several extra requirements, although sometimes none are needed. Run through the following list of topics to see which you need to address:

The first four topics are covered in their own requirement patterns; each of the last five is discussed in its own subsection that follows. This list looks daunting, but it isn't as tough as it appears. The requirements for a typical interface need worry about few of these topics; most can be left to the development team to sort out.

The extra requirements are most readable if they immediately follow the main requirement for the interface to which they relate. But it can be beneficial to group all the main inter-system interface requirements together and then have the extra requirements later on (perhaps even in a later section of the requirements specification). This has the advantage of giving a clear overview of all the interfaces in one go without getting bogged down in the details.

Most interfaces involve some sort of communications mechanism, which occasionally have traffic hiccups. Resilience in an interface means being able to identify anomalies and deal with them: to spot when messages are missed and ask for them to be re-sent and to spot duplicate copies of messages. Some message protocols and other types of interfaces take care of these things for us, but if you want to play it safe, you can write a requirement demanding this kind of resilience, which acts as an instruction to the developers to take care of it. The requirement needn't worry about how it's achieved. If the developer knows that the underlying messaging protocol handles resilience already, there's nothing more they need to do.

Here's an example interface resilience requirement:

Requirements for the availability of an interface—both its normal availability window and downtime targets—can be written in the same way as for the availability of a system as a whole. Follow the availability requirement pattern but limit your focus to the interface only. Clearly identify the interface to which each resulting requirement relates.

This is a mixed bag of features that collectively act as a sort of passport control for the interface. They come into play once messages have safely completed their journey (or before they set out). Consider whether you need to do any of the following:

The motivation for such steps is sometimes legal: to provide proof that another party requested, saw, possessed, or did something. This being so, you need to understand the level of proof needed in your country (or in all the countries in which your system will operate). You might be in for some nasty surprises. You might, for example, need to record messages on a write-once read-many (WORM) medium, to prove that it hasn't subsequently been tampered with.

Here is an example requirement for each of the three topics discussed:

An interface can be tough enough merely to get going in the first place, so why on earth would you want to change it? Well, the functionality might need to change, or a new version of an interface standard might come along. There are two strategies for switching over to a new version of an interface:

These sound like design questions, but they must be addressed in the requirements because they affect external systems. If an interface development guide is written, it should say which strategy is to be used—although it is conceivable for one version to use a different strategy than the previous version used.

For an interface not owned by us, the requirements should say the extent to which we are committed to keeping our system compatible with future versions of the interface. If nothing is said, readers can reasonably assume the system merely has to work with the stated version (or whichever is the current version when the system is built). Refer to the comply-with-standard requirement later in this chapter for further discussion on this subject.

Here are example requirements for strategies and situations discussed in the preceding section:

Whenever the subject of security arises, it's likely to be complex and tricky. This little section has no pretensions to being systematic or comprehensive; it merely raises a few issues for you to consider. Let's divide the problem into two parts: the communication medium used by the interface and the traffic that travels along it.

The communication medium used by the interface needs to be protected to prevent intruders from using it to gain general access to our system (hacking in). Requirements can easily address this in solution-independent terms. (No mention of firewalls or virtual private networks or such here!) Unfortunately, it's difficult to decide or express how much protection we need: it can't be quantified. Here's an example requirement of this kind:

As for the traffic, there are various kinds of attacks we could be subjected to, but they boil down to the active and the passive. In an active attack, an attacker modifies the traffic: creates bogus messages, modifies genuine messages, or prevents the transmission of traffic. A passive attacker simply listens to our traffic to get hold of sensitive information. You need to write a requirement to protect against each type of attack you're worried about. Again, specify what you aim to achieve: avoid specifying in terms of solutions—though you can mention an approach if it's obvious. (Common approaches include encryption to prevent the reading of information, hash codes to detect tampering, and digital signatures to verify who sent messages.) Here are a couple of example requirements:

In sensitive applications, an eavesdropper can glean useful snippets merely by knowing that there is traffic or knowing its quantity—but this is unlikely to be a concern in commercial environments. If it is, engage a security expert to work out your security requirements

If we own the interface, the developers of the system(s) at the other end will need to know what to do, and it's our responsibility to inform them. This means we need to write some kind of "Interface Developer's Guide" for this interface—even if it's rudimentary. How thorough a job we need to do depends on who they are and how many of them there are: if we're building a product, and lots of customers will be implementing this interface, we'll need a slick and comprehensive guide; we don't want our developers spending all their time explaining it over the phone or in emails. Here's an example requirement for an interface developer's guide:

This sort of requirement is very similar to requirements to allow third-party development of drivers, as described in the extendability requirement pattern. See also the documentation requirement pattern, discussed later in this chapter, for further details on what to say.

The external developers also need to be able to test their interface software. This probably means making a test system available for them to use and running it for as long as necessary. If we're writing software to help test the interface, perhaps we can make that available to them—which involves packaging it up neatly. Last, the developer's guide needs to explain all these testing issues. Write requirements covering everything that you decide is needed, and point out suggestions that were rejected.

When designing an inter-system interface, start by running through the topics in the list at the start of the "Extra Requirements" section of this pattern. Some of these topics might be covered in requirements, but most probably aren't. A well-rounded interface design and implementation take these matters into account and can cope without panic when changes are made in the future.

Consider writing software to simulate the interface (and the system at the other end). The value of this depends on the importance of the interface (does your company's future depend on it?), its complexity, and the availability of a test system by the other system's owners. Testing error conditions can be difficult and tedious; some are impractical to cause at all. Sometimes it's useful to have the test software simulate certain types of errors. (One system I worked on let us specify, in the messages themselves, the type of error to simulate during testing. This was very powerful. But we had to take great care that all trace of this feature was removed—compiled out—before the software went into production. I'm not promoting this approach.)

The organization who builds a system must test every component, within the system's scope, that participates in the interface. Treat each participating component separately. Identify, from three sources, all the kinds of interaction that can occur across an interface:

See the inter-system interaction requirement pattern that follows for more about how to test each kind of interaction.

Most commonly, one end of an interface is outside the scope of the system being implemented. Check that a test "other end" system is available. Things become tricky and risky if not. This is often an important issue—especially when dealing with big, powerful organizations such as financial institutions (to test, say, credit card transactions) and government bodies. Sometimes, it even becomes necessary to build a working simulation of another system, which can involve considerable extra time and effort.

See the previous Considerations for Development section. Encourage the development team to build software to test the interface, and then make use of it. But don't rely on test software of this sort for all testing, in case it's incomplete or doesn't simulate the interface faithfully.

Use the inter-system interaction requirement pattern to specify a particular type of interaction across an inter-system interface.

A typical interface involves a range of different types of interactions. A credit card payment service might exist primarily to enable retailers to debit a cardholder, but its interface will do various other things, such as reverse a transaction and check a card's credit limit. These are business-related functions, but the interface might also possess a number of more technical and supporting interactions: initiating a connection (and shutting it down); requesting resend of a previous message; notifying status; and so on. An interaction type, for the purposes of this requirement pattern, means the exchange of a particular type of information—which could involve messages in both directions. For example, a request and corresponding response count as an interaction.

Whether we want our requirements to address specific types of interactions depends very much on who owns the interface. There are four distinct situations in which we might find ourselves, and they have a direct bearing on our reasons for wanting to specify individual types of interactions, which in turn affect how much we should say:

An inter-system interaction requirement needs to contain the following:

Here are a couple of example inter-system interaction type requirements for interfaces we own:

None

Refer to the inter-system interface requirement pattern earlier in this chapter.

Refer to the inter-system interface requirement pattern for the big picture of testing an interface as a whole.

An inter-system interaction requirement specifies only what the interaction must achieve, its goal. The implementation might turn out to be more complex. For example, a requirement might imply there will be one request and one response, whereas in practice, it takes two of each. Therefore, testing an interaction requirementmust be concerned with only whether the goalis achieved, not the intricacies of the implementation. Additional testing should be done to verify that the physical interactions work properly. Data flow diagrams can be useful in devising tests for the physical interactions but will be less so for the logical interactions.

Formulate both valid cases and invalid (erroneous) cases. In the first case, identify valid but unexpectedcases. Does the interface deal properly with valid interactions that won't happen every day but can come along at any time? It's never possible to test every eventuality, but try to cover as representative a spread of situations as possible.

Use the technology requirement pattern to specify technology that must (or must not) be used to build or run the system, or with which the system must be capable of interacting or otherwise compatible.

Do not use the technology requirement pattern to make technology choices.

Technology is any externally-produced hardware or software that is used in building, installing, and running a system. That's what it means here, at any rate. Requirements must not make decisions about which technology to use; they must describe whatever is known about the technology landscape into which the system must fit—to constrain in some way the technology that can be used in the system. We can conveniently divide that landscape into the following three areas:

Specifying development technology is most important when outsourcing development, especially if maintenance and ongoing development will be done in-house: constrain the external developers so the system suits our existing environment and skills. When developing in-house, we can usually rely on the development team to pick technology that is compatible with other systems and their skills, but not always. A developer might have their pet programming language or might just want the chance to learn a popular new skill—and you might have good reasons for keeping them to tried and true old ways. Carelessly introducing a hotchpotch of technologies contributes—invisibly, and probably significantly—to incompatibilities between systems—and thus inflexibility as well as extra development cost.

All requirements for technology to be used in development must have the highest priority; it's not practical to change these things after development starts.

It's not necessary to specify all this stuff—or, indeed, any of it. Just specify whatever is a given. The less we specify, the more freedom the development team has to pick whatever technology best fits the constraints placed upon it plus the goals of the system.

Where do technology requirements come from? We can expect demands for the technology that must be used (or not used) and interacted with in production to become apparent during the requirements process: someone's likely to mention them. On the other hand, we're likely to discover development environment matters only if we go looking for them—by talking to the development team. But that doesn't mean we should mechanically record such information: only specify it in requirements if there is a good reason to.

A technology requirement should contain:

If the system must work with a range of technologies (for example, a couple of popular Web browsers), write a separate requirement for each one. This makes it harder for any one of them to be neglected (that is, it's easier to trace that each technology is supported), and it allows each one to be assigned its own priority.

Use one of these templates as a starting point only. As the examples that follow demonstrate, the most suitable phraseology varies considerably depending on what an individual requirement says.

The following examples should not be regarded as advocating (or deprecating) any of the technologies they mention. This is not a coherent set of requirements that apply to one system: a few contradict one another. The second example demonstrates how expressing technology and versions in terms of a "formula" can be tortuous to specify precisely.

Observe that these examples are not divided into the three areas discussed (use in production, interact with, and use in development), yet mixing them up does not confuse the role of each requirement.

Some nonfunctional requirements that we wish to impose on our system also need to apply to technology that we use. In this case, write extra requirements for the purpose. One example is accessibility: our system can't be regarded as satisfying its accessibility requirements if some of its functions are implemented using a third-party product that doesn't satisfy them. (See the accessibility requirement pattern in Chapter 8 ) Write extra nonfunctional requirements for each of the technologies used. That's usually preferable to attempting to broaden the original nonfunctional requirements so they also apply to the technology used. The latter is certainly easier to specify, but it isn't helpful to developers because the work involved in building a feature into our own software is of a different nature than that of choosing a compliant product. It's equally unhelpful to testers for similar reasons.

Technology is too varied to be able to make suggestions here on how to tackle particular types. But it is possible to say a little about how to react to the two main kinds of technology requirement, because they are very different as far as development is concerned:

As with development, the two main kinds of technology requirements place very different demands on testing:

For both kinds of requirement, pay special attention to any requirement that insists that the system work with multiple different technologies (and/or multiple versions of each one), especially if the number of permutations looks impractically large. Be alarmed if two or more technology requirements have impact on each other, yielding vastly more permutations. This situation is likely to be hard to test—because you have to acquire, configure, and run all the technologies to test them. Then tests must be repeated for each one. It's tolerable for client technologies with which the system must interact (such as several Web browsers and browser versions). But it's a major headache when it relates to the system's own environment, such as testing that server applications run on several different operating systems or types of hardware.

Use the comply-with-standard pattern to specify that the system must comply with a particular standard.

A standard, for the purpose of this pattern, is any document or collection of documents that makes demands on how things in its sphere are to be done. It includes laws (tax, privacy, access by people with disabilities), government regulations, industry-specific regulations and codes of conduct, company standards, quality standards (such as ISO 9001), information standards (such as currency and country codes), and technical standards of diverse kinds (for example, file formats, communication protocols, and user interface conventions).

Comply-with-standard requirements tend to be very straightforward: you must comply with whatever-it-is. But more often than not, it isn't good enough to leave it at that, and you should write extra requirements that expound the implications. See the Extra Requirements section later in this pattern for more. (Note that this pattern has been named "comply-with-standard" for clarity: calling it the "standard" requirement pattern would invite misreading its purpose.)

Let's divide standards into a few categories for the purpose of saying a little about how to approach them:

A requirement that mandates a standard should specify:

If a suitable standard exists for a particular aspect of a system, it is generally a good idea at least to seriously consider using it before devising something in-house for the same purpose. If you're not sure whether a standard exists, go and look. There are plenty out there. (This is not quite the same as the famous saying, "The nice thing about standards is that there are so many of them to choose from.") A few good starting points are

All the examples that follow relate to real standards (except for a couple for a fictitious company). They are divided into the four types already discussed: industry-specific, applicable to all companies, company-specific, and technical. Examples relating to accessibility legislation can be found in the accessibility requirement pattern. The first examples are industry-specific:

These examples demand compliance with various laws:

Here are a couple of example requirements for company-specific standards:

Here are example requirements for a few technical standards:

The natural reaction to reading a typical comply-with-standard requirement is bemusement: what's it mean? What are developers and testers supposed to do with it? If it's clear, the original requirement will suffice. If not, someone has to figure out the implications for the system by going through the standard in detail—and for consistency and efficiency, it makes sense to do this only once, rather than having several people independently making their own, uncoordinated interpretations. That person should be the analyst, and extra requirements should be their medium. It still makes sense for representatives of the development and/or testing teams to verify the analyst's interpretation against the standard itself, but the importance of that depends on the nature of the standard. Also, a small project might not have the resources to perform a lot of double-checking.

There are three levels of detail at which compliance with a standard can be specified by using requirements:

If you write a separate requirements specification for the standard, the original comply-with-standard requirement must identify the separate specification (its name, version, and where it can be found), and state explicitly that all its requirements must be satisfied. The comply-with-standard requirement then takes on the role of a refer-to-requirements requirement, and you should use that pattern instead.

Usually, you need to specify requirements for everything that the system must do to comply with the standard—just as if the standard were replaced by a customer who insists on everything in the standard. There are a couple of situations where it's not necessary to go into such detail: first, if you are outsourcing development to an external organization that can be expected to properly determine the implications of the standard for themselves; and second, if you intend to purchase a product. But beware of suppliers that comply with the letter of the standard but not its spirit. If you're worried about this, add requirements covering areas of potential concern.

Standard-related requirements needn't all have the same priority. For example, when a new standard is introduced, it might introduce its provisions gradually over time. (Some imposers of standards are reasonable!) Or a compliance auditor (say, for a government regulator) might grant dispensation from some demands for a given time (just like a health inspector granting a restaurant time to clean its dirty kitchen).

Some requirements that have been requested already might contribute to compliance with a standard. Add a note to this effect to each such requirement. Every requirement that contributes to compliance with a standard should say so explicitly, unless it is obvious from its context (such as being in a section of the requirements specification devoted to that standard).

If you're supplying your requirements specification to a third party (outside your organization), they must have access to all the standards you expect them to comply with. This means you must make internal organization standards available to them, and supply industry standards if the third party is unable to obtain them because they don't belong to the requisite industry body (or to save them the expense of buying them). Wherever possible, distribute copies of standards to third parties along with the requirements specification itself: it saves everyone the time of asking for and supplying them later, and it brings to light any supply problems before you suffer any embarrassment. Also bear in mind that standards can be relatively expensive, and those available only in hard copy can take significant time to order and receive. This can cause considerable difficulties if you're asking for responses (bids) from third parties, especially if you impose a closing date (for example, for a tender). This reinforces the fact that it's always helpful to your readers to spell out in detail the implications of a standard, so they don't have to pore over it themselves. It's a much better use of time for one person to figure out the implications than for multiple readers each to do it for themselves, particularly since they know less about the author's intent. It also minimizes differences in interpretation.

Many standards appear to be intentionally mean and bloody-minded. But if we consider they're nearly all written by people who aren't directly accountable for any unreasonablenesses, ambiguities, contradictions, and omissions in them, and who don't have to pay for or carry out the work necessary to comply with them—well, perhaps we should be grateful that standards aren't worse than they are.

Developers are strongly advised to consider the factors discussed in the Complying with Multiple Versions of a Standard section.

Be especially careful when a standard defines an interface (for example, for a communications protocol) or some other aspect of system interoperability (for example, when one system must read files produced by another system). It's very easy for two systems built to the same standard not to be able to talk to each other: it only takes very small differences in interpretation of the standard. If possible, coordinate development as closely as possible with the other organization(s) implementing the same standard.

Standards vary considerably, so testing depends on the nature of the standard. The key to thorough and sensible testing against a standard is to get to know it firsthand.

If requirements have been specified for all the detailed implications of the standard, the parent requirement for the standard itself need not be tested.

Use the refer-to-requirements requirement pattern to specify that some or all requirements in an external requirements specification must be satisfied as if those requirements were present in the current specification.

A detailed requirements specification for a serious commercial system is a significant document that takes considerable effort to write and, equally importantly, to read and review. Moving certain parts into separate specifications makes it easier to deal with. Spinning off the less visible or more technical parts gives the main specification a clearer focus on the matters closer to the heart of the business, but at the risk of masking from key stakeholders the overall scale and complexity of the system. Improved clarity and manageability is one good reason for referring to external specifications. Another is that those specifications can be referred to by other systems, thus saving effort (via reuse) and increasing consistency between systems. A third reason is that a specification on a specific subject tends to be written more diligently than when it's an afterthought in another specification.

Make sure that the referenced specification is accessible to the whole audience of the current system's specification. If that's not possible, either create a version of the referenced specification that everyone can access, or copy the individual requirements into the main specification. Developers mustbe able to read all requirements that they are expected to satisfy.

A requirement that refers to external requirements needs to contain:

None.

Treat each applicable requirement in the external specification as if it were present in the current specification.

The suggestion in the Considerations for Development section applies to testing, too.

Use the documentation requirement pattern to specify that a particular type of documentation needs to be produced.

Documentation can be regarded as anything that is written about a system, no matter what form it takes—not just traditional documents. Online help, presentations (in Microsoft PowerPoint, for example) and comments and other annotations in program source code all count as documentation. Some people might dispute whether anything in source code should count as documentation, but the output from utilities like Javadoc—which generates a coherent set of HTML pages about a body of Java software—must certainly count as documentation, and it seems artificial to include some types of annotations of source code but not others.

For the purpose of this requirement pattern, it's also possible to extend the definition of documentation beyond what's written, to include instructional videos, interactive tutorials, and informative material in other media. In an increasingly multimedia age it seems inappropriate to place artificial limits on what counts as documentation in the broad sense.

A requirement for documentation should contain those parts of the following that are appropriate:

Here are representative requirements for several common (and one or two uncommon) types of documentation. The mention of a type of documentation here is not a suggestion that it should be produced for every system.

A documentation requirement is usually self-contained. There are the following rare cases when extra requirements might be needed:

The development team's biggest interest in complying with documentation requirements is in producing whatever is expected of them. When reviewing documentation requirements, check that those demands aren't unreasonable.

It is, of course, good practice to comment source code when writing it. It's also very helpful to the whole development team to make good use of tools that generate source code–based documentation (such as Javadoc) and to generate it for the whole system regularly as a matter of course (say, whenever a build of all the software is performed).

For the purposes of testing, we can divide documentation into four types, each of which needs to be tested in a different way:

Also test that all documentation complies with any accessibility requirements. See the accessibility requirement pattern in Chapter 8.