The Role of Adjacent Systems

The adjacent systems are those pieces of work that supply your work with information or that receive information and services from your work. An adjacent system might be an organization, an individual, a computer system or some other piece of technology, or a combination of any of these. It is also the customer for the business use case. Examine the adjacent system and consider what it really wants from that business use case. Perhaps the adjacent system may want to do more than passively supply information to, or receive a service from, the work. Consider the type of service or information your organization would provide if the adjacent system participates in some of the activities that make up the business use case.

An adjacent system might be an organization, an individual, a computer system or some other piece of technology, or a combination of any of these.

For example, when an adjacent system initiates a business event, what possibilities do you have to involve that adjacent system more closely in your business?

The intentions of the adjacent system may be disguised by the technological limitations of the products currently in use by the work.

• What are the technological capabilities of the adjacent system? Is it capable of interacting with the product? Is it human? Does it have some interactive technological capability? Could it use, say, a mobile phone or a text message to initiate the business event?

• What is the desired outcome from the point of view of the adjacent system? What are its aspirations at the time of triggering the business event? Keep in mind that the intentions of the adjacent system may be disguised by the technological limitations of the products that are currently in use by the work.

• What is the desired outcome from the point of view of the work? What is it that the work wishes to provide or is capable of providing? To meet this demand satisfactorily, you have to ignore the technology that the work used in the past as well as current organizational limitations.

We are trying to discover the intentions of the adjacent system when it started the event. What outcome does it have in mind? Does the current work scope place restrictions or some burden on the adjacent system? If the adjacent system is a customer of the work, how can the work provide a better service when it responds to this event? Does the adjacent system want to participate in the business use case by performing some of the work or by exerting more control over the work? If you could get inside the brain of the adjacent system, what would you find?

The scope of the product you buildthat is, the functionality you include in the productis largely shaped by the adjacent systems. We need to understand the adjacent systems and their potential role in the work. Let's look more closely at the characteristics and capabilities of adjacent systems, by categorizing them.

Active Adjacent Systems

Active adjacent systems behave dynamically. They can interact with or participate in the work because they are usually humans. When they initiate events, they have some objective in mind. They can collaborate with the work or the product by exchanging data, responding to questions, indicating choices, and providing other signals, until their objective is satisfied. Figure 4.6 shows an example of an active adjacent systema bank customer interacting with the bank

Figure 4.6.

An active adjacent system interacting with a bank. The bank customer initiates a business event, and then supplies information or does whatever is needed until he achieves the desired outcome. In this instance, the business use case is everything the bank does when a customer wants to withdraw money from his account. The precise nature of the flows between the work and the adjacent system depend on the technology used by the bank.

In this example, an active adjacent system interacts with the work. This interaction can occur face to face, by telephone, with an automated teller machine, or over the Internet. For the moment, let's ignore the technology being used. Instead, let's look a little more closely at the nature of the active adjacent system:

Active adjacent systems are humans. They initiate business events with an objective in mind.

• You (the requirements analyst or product designer) can predict the adjacent system's behavior within reason.

• You can expect the adjacent system to respond to signals from your work. As long as there is some perceived benefit to the adjacent system, it will obey(more or less) instructions from the work. For example, if a person is checking in for a flight, he is likely to respond correctly about bags and seat allocations.

• The adjacent system will respond in a suitably short time. It is reasonable to say that the adjacent system will act promptly so as not to delay the transaction any more than necessary.

What can we make of that list? First, because the active adjacent system can interface directly with your work, you should consider it to be part of the work, not just an inert outside body. Of course, you must understand the desires and motivations of the active adjacent system. This knowledge always opens up a rich area of product innovation.

As an example, let's consider a bank customer using an automated teller machine. Don't think of the ATM as an automated product, but rather as the boundary of the bank's work. The customer is currently outside the work. Now imagine that this bank customerthe adjacent systemis a woman taking a lunch break from her office. She approaches your ATM. But what does she really want when she goes to the ATM? Just cash? To see her balance? If that is all you are prepared to give her, then you may fall sadly short of the mark.

Consider whether you can change the scope of your work to provide a better service to the adjacent system. Does allowing the adjacent system to participate in the work mean that it will receive a greater benefit from your work?

Get inside the brain of the adjacent system. Why does the bank customer want the cash? Does she intend to pay her electricity bill on the way back to her office? If so, why not offer her the opportunity to pay it at your ATM or to top up her phone card, or to buy a bus/train ticket? Does the customer want the cash to buy something? Then why not extend the ATM card to act as a debit card in retail outlets so she doesn't have to go to the ATM in the first place? Does the customer just want to look at her account balance? Why not give her the facility to do so on her mobile phone?

While we are looking into the brain of this lady, what else does she want? Does she want the bank to identify each cash withdrawal so that her monthly statement tells her which members of her family made each of the withdrawals? Does she want a limit on withdrawals made by her children? Does she want to go to an ATM at all? Would she rather handle most of these tasks at home or while she is shopping at the supermarket, or, more pleasantly, at a café?

Note that, for the purposes of understanding the business, we are ignoring the technology currently being used. While this omission may seem cavalier, it is only by taking a view that ignores current technology and its limitations that we become able to see the opportunities for providing products closer to the innermost needs and wants of our customers.

For example, business event number 10 in the list of business events given in Table 4.1 is called "Truck Depot reports problem with truck." From time to time, trucks salting the road break down, slide off the road, or somehow get into a situation where they cannot complete the treatment of their allocated roads. They then radio the depot, and the supervisor tells the de-icing work. The work responds by rescheduling trucks so as to disperse the broken truck's allocation among the remainder of the fleet. Seems straightforward enough (see Figure 4.7)

Figure 4.7.

Business events are initiated by the truck depots. Because they wish to be more closely involved with the product, we can make the supervisors into active adjacent systems. This choice will probably result in part of the automated product being located in the truck depots so that the supervisors can have direct interaction with it.

The aim of getting into the brain of the adjacent system is to produce a better product.

Let's look more closely at the adjacent system to see what is going on. The supervisor has, like many automated system users, been using the existing de-icing product in a way not intended by its builders. The original designer of the product reasoned that trucks would break down when they were in active duty, but not while they were parked in the garage. The supervisor is using business use case 10, "Truck Depot reports problem with truck," not only to handle breakdowns, but also to take trucks out of service for maintenance. This causes the supervisor a certain amount of inconvenience. However because it is the only way he can prevent his trucks from being scheduled so that he can maintain them, he puts up with it.

Why did this happen? No one looked closely enough at the work of this adjacent system when the original requirements were gathered. By scrutinizing this adjacent system more rigorously, you learn more about its needs: You learn that the supervisor needs to schedule truck maintenance. At first glance, this need appears to call for the definition of a new business event, "Supervisor withdraws a truck for maintenance." However, you should consider whether the product itself could do that. Given that the product has data about each truck's activity, it should be straightforward enough for it to schedule their maintenance via a temporal event, called something like "Time to withdraw trucks for scheduled maintenance."

The result of getting into the brain of the adjacent system is a product that fulfills more of the requirements that exist in the world surrounding itin other words, a better, more useful product.

Autonomous Adjacent Systems

An autonomous adjacent system is some external body, such as another company, a government department, or a customer who is not directly interacting with your work. It acts independently of, or unconstrained by, the work being studied, but has connections to it. Autonomous adjacent systems communicate through one-way data flows.

For example, when your credit card company sends you a monthly statement, you (the card holder) act as an autonomous adjacent system. When you receive your paper statement, you have no interaction with the credit card company: You are acting as a sink for the information your card company sends you. You make no immediate response to the statement: You wait until such time as it is convenient for you to pay the bill. Thus you are acting independently or autonomously as seen from the viewpoint of the work of the credit card company.

An autonomous adjacent system sends and/or receives a one-way data flow to or from the work.

Similarly, when you do eventually pay your credit card bill, you are again an autonomous adjacent system from the point of view of the work of the credit card company. You send your check by post, and you have no expectations about participating in the response the work makes upon the arrival of your check.

Another example of an autonomous adjacent system is a weather station that sends a reading to the work of predicting and scheduling the de-icing of roads (see Figure 4.8). The weather stations are programmed to transmit readings of the air and road-surface temperatures and moisture content periodically. The business event happens when the weather station decides it will transmit a reading. In response to this event, the business use case records the time and values of the reading. The transmission is one way: No signal is sent back to the weather station in acknowledgment, nor does it interact with the work. Thus the weather station acts autonomously from the work.

Figure 4.8.

When a weather station transmits information, its readings arrive as a complete packet of data. The work accepts this data and processes it according to a preplanned policy. The work does not interact with the weather stationthere is no reason to do so. Indeed, it is not possible for the weather station and the work to have any kind of interaction.

Autonomous adjacent systems use a one-way communication, either because of their technology or because of their preference. However, be careful to determine that this mode of communication really is the choice of the adjacent system, not a result of your own business's past technological decisions. If an autonomous system is your customer, then it may well prefer to be connected directly to your productin other words, become an active adjacent systemand not deal remotely.

When considering the nature of adjacent systems, bear in mind that the same physical entity can be any of several different types at different times. For example, when you send a check to pay a bill, you are autonomous; in contrast, when you go to that business in person and make an inquiry, phone it, or interact with it over the Internet, you are an active adjacent system.

Let's look at another example of a business event involving an autonomous adjacent system, as shown in Figure 4.9. The Weather Forecasting Service sends the District Weather Forecasts by fax. When we ask the service, we find that it cannot, or will not, send the data to the work any other way. Thus its one-way transmission of data makes the service an autonomous system. Faxes are not a suitable medium for any automated product to utilize directly, so we must employ clerks to act as interpreters of the faxes and enter the weather data into the IceBreaker product. Thus the only available boundary for our product is one that interfaces with the clerks rather than with the autonomous Weather Forecasting Service.

Figure 4.9.

The autonomous adjacent system uses a transmission medium that makes it impractical for the product to receive it directly. We must therefore install some other processin this case, a human clerkto manually transcribe the data for the product.

An autonomous adjacent system does not involve itself in the response to the business events that it triggers. Similarly, when it acts as the receiver of the output of a business use case, such as a report or invoice, then it is a passive receiver of the output and makes no attempt to respond immediately.

While it appears there are few opportunities to involve autonomous adjacent systems in the work, you must be certain the adjacent system actually chooses to be autonomous, and is not forced to be so by your work's technology. For example, our bank forces us to fill in forms whenever we need a new service from it. That makes us, as customers, autonomous. We would much prefer to initiate any appropriate business use case with some direct interactiontelephone, the Internet, or face-to-face meetingand thereby give the bank the information it needs. That way, the bank could make use of the information it already holds about us, and not ask us to fill in yet again our name, address, account number, and so on.

There are many opportunities to make better products by involving the adjacent systems. We will revisit this idea in Chapter 5, Trawling for Requirements. For the moment, simply note that you must be familiar enough with the autonomous adjacent system that you understand precisely the desired interface between it and the work. If there is no real desire for, or limitation to, one-way communication, then take the opportunity to expand the scope of the product to involve the adjacent system in the work.

Cooperative Adjacent Systems

Cooperative adjacent systems can be relied on to behave predictably when called upon. They cooperate with the work during the course of a business use case. This is almost always done by means of a simple request-response dialog. A cooperative adjacent system might be another automated product containing a database that is accessed or written to by the work, an operating system, or any other system that provides a predictable and immediate service to the work.

Cooperative adjacent systems are computerized.

An example of a cooperative adjacent system: The Thermal Mapping Supplier provides data used by the de-icing prediction work. In particular, this data is used by the business use case that schedules the trucks to treat the roads. The Thermal Mapping Supplier has the needed data on a database, and it allows the IceBreaker product to access that information. Because the data is fairly volatile, it makes good sense to retrieve current data when it is needed, rather than IceBreaker maintaining its own version of it. We could summarize this situation rather neatly: The product has on-demand access to the Thermal Mapping Database.

This situation involving a cooperative adjacent system is shown in Figure 4.10. When the ice prediction work asks for data from the database, the adjacent system responds with the requested data in an agreed-upon and timely manner. Thus the cooperative adjacent system receives a single input, the district for which it wants the thermal conditions, and produces a single output in response. The response is quick enough that the requesting product is prepared to wait for it.

Figure 4.10.

An adjacent system maintaining the Thermal Mapping Database is not owned by the de-icing business, but rather is the responsibility of another party. However, the de-icing system may access the data; when it does, it expects to get data quickly.

This immediate and predictable response means that you can think of the cooperative adjacent system as conceptually part of the business use case. In our example, it forms part of the business use case responding to business event 8, "Time to predict icy roads." The processing of the business use case does not stop when it reaches the adjacent system, as would normally occur with other kinds of adjacent systems; instead, it continues until the desired outcome of the business use case has been reached. For the sake of convenience, we generally include it in our models of the business use case, as illustrated in Figure 4.11.

Figure 4.11.

The processing for a business use case does not stop when it involves a cooperative adjacent system. Even though the adjacent system is outside the scope of the work, it can be considered part of the work due to its ability to respond immediately. The double arrow indicates a special type of adjacent system, in which the data flow "passes through" the adjacent system. This kind of adjacent system does not initiate events, nor does it act as an external sink for information flows.

It is unlikely that you will needor wantto change the interfaces with the cooperative system. Cooperative systems are black boxes, their services are stable, and there is rarely much to be gained from trying to change them. The only reason to change them is if your product needs a different service or data.

Business Use Cases and Product Use Cases

We have stressed the importance of understanding the work, not just the product. By looking at the larger scope of the work, you ask more questions about the business requirements and build a better product. The following example comes from a recent consulting assignment: "The product is to rip a CD into MP3 or some other digital format." When the engineers looked at the technical part of the product (they are engineers, after all), they saw a use case that was triggered by the insertion of the CD and then went on to rip the CD.

However, when we stand back and look at the wider context of the real business being done herethe business use casewe see something else. What is the end user trying to accomplish? What are his aspirations and desired outcomes? We define them as "getting the music from the CD into an MP3 player." Thus the real question is not about the technicalities of ripping CDs and converting to MP3 format, but the remainder of the true business.

For example, the end user wants the track names to appear on his MP3 player. So, when the CD is inserted, one of the early functions of the business use case must be to add the track namespresumably via an automated process that would use the Gracenote database or something similarand to add the album cover artagain, presumably from one of the many sources on the Internet. Once that operation is complete, the business use case continues by allowing the user to change the order of tracks, delete unwanted ones, and make any other organizational changes to the music.

So what do we have? At the outset, we have the scope of the work being studied. This scope is bounded by the communications with the adjacent systems that surround the work. Business events happen in the adjacent systems when they decide they want some information or service from the work, or they want to send some information to the work. Once the business event has happened and the resulting data flow has reached the work, the work responds. This response constitutes the business use case.

Study the business use case, considering what the work does and what the adjacent system desires or needs. In other words, consider whether the organization is making the correct response to the adjacent system. We will have more to say about how to investigate and understand the work in Chapter 5, where we discuss trawling for requirements, and in Chapter 6, where we present scenarios as a way of documenting your understanding.

Once you understand the correct work of the business use case, determine the scope of the product for that business use case. As part of this effort, consider whether the adjacent system is capable (or desirous) of making a different contribution to the work than it currently does. Do not assume the responsibilities of the product and the adjacent systems at the beginning of the project; instead, derive them from an understanding of the work and from what the external customer considers to be a useful product.

The part of the response handled by the proposed automated system is a product use case. But note how we got to this point: The product use case is simply a part of the business use case, and we found it by examining what the work is and how the work responds to outside demands. The involvement and intentions of the adjacent systems determineor at least strongly influencethe role the product plays in the work's response.

Thus the product use cases are derived from the business events that are the driving force of the work. This relationship is shown graphically in Figure 4.12.

Figure 4.12.

The business event is either some happening or a decision taken by the adjacent system. The resulting information flow notifies the work of the event and triggers a response (the business use case). After study, the requirements analysts and the interested stakeholders decide how much of the business use case is to be handled by the proposed product (the product use case). Whatever is immediately outside the scope of the product becomes the actor, who manipulates the functionality of the product use case within the product.

Sometimes, for technical reasons, you might choose to implement a business use case with a number of product use cases. Perhaps you wish to subdivide the work inside the computer into smaller pieces. Or perhaps you have the opportunity to reuse product use cases that have previously been developed for other parts of the product or for other products.

When you are looking to reuse product use cases, keep in mind that linking constructs called <<include>> and <<extend>> are available for this purpose. These constructs are similar enough not to bother with the distinction between them here. What they mean is that one product use case can make use of the functionality of another product use case.

The selection of product use cases is somewhat driven by technical considerations. If the product is to be recognizable and usable by its intended users, however, then the product use cases must be based on the original business events and business use cases.

When you determine the product use cases, you are also selecting the actors who interact with the product.

Actors

Actors are the people or systems that interact with the automated product. In some cases, the actors are adjacent systems that are outside the work or organization that owns the productfor example, the organization's customers. In other cases, you appoint actors from inside the organization, as theadjacent systems. Figure 4.13 shows the product use cases that were selected for the IceBreaker product as well as the actors that operate each of the product use cases.

Figure 4.13.

The use case diagram for the IceBreaker product, including the product use cases, the actors involved in each product use case, and the product's boundary. An active actor is represented as a stick figure (you can draw these any way you like). Autonomous actors are shown as houses, and the cooperative one as a rounded square with two-way arrows.

You can take advantage of the product use cases in many ways:

• They provide a vehicle for discovering and clustering groups of related requirements.

• You can use the product use cases to plan implementation versions.

• Testers may use product use cases as input when writing test cases.

• A product use case provides a business-related basis for building simulations and prototypes.

• It is easier to deal with changes because the product use case can be traced back to the business use case and hence the business event.