Setting the Scope

The scope you are interested in at the beginning of the requirements project is the scope of the work for which the product is to be used. Work here means the business activity for which the user needs the product. It can be a commercial activity, some scientific or technical work, currently automated or manual work, or any combination of these or any other types of work. In some cases it can be work that does not yet exist and will be realized only at the end of the project. So long as it involves some processing activity and some information, we call it work. The reason for being interested in the work is that if, and only if, you understand the work can you build a product that can help to support it.

The information that enters and leaves a piece of work defines what that work does.

You set the scope by dividing the work you are about to study from the work that surrounds it. To do so, you must keep in mind that every piece of work you ever study is connected to other pieces of work. Consider, for example, the work you do as a business analyst, or programmer, or whatever it is you do. Your work is not isolated from the rest of your organization. When you do your work, you produce output. Let's say it is a requirements specification. You transmit your outputby paper or verbally or electronicallyto some other person or organization or system or, as we use the term here, some other work. These two pieces of work are connected by one or more flows of information. In fact, the flows of information that enter and leave a piece of work actually define its scope.

In the preceding example, your output was a requirements specification. Assuming your specification is not a work of pure fictionyou didn't sit down and dream up the whole thingthen you must have had information coming into your work from various sources. Thus we can define your work as processing the information and transforming it into a requirements specification. This important idea of defining work and its boundaries by defining the inputs and outputs will be revisited several times in this book.

Setting the scope of the work means you determine what work you are about to study, what other pieces of work surround it, and what flows of information make up the connections.

Setting the scope of the work means that you determine what work you are about to study, what other pieces of work surround it, and what flows of information make up the connections. When you set the scope, you are deciding how much of the work you will study and what you will not study. The product you build will become a significant part of the work. Thus there is a need to study the work and become familiar with it so as to understand what product you can build to best help with that work. The pieces of work you do not need to studythe adjacent systems are outside your scope. You can safely restrict your study to understanding the details of the connections to the adjacent systems.

For example, the work of IceBreaker is to predict the time that ice will form on a road so a truck can be scheduled to treat the roadas close as possible to freezing timeand prevent the ice from forming. To accomplish this, the IceBreaker work needs data about the weather and the condition of the road. It gets this data from sensing devices that measure the atmospheric conditions as well as the temperature and water content of the road surface. The sensing devices' work, in turn, is connected to another piece of workthe weather. The weather is connected to the slope of the earth's axis as it orbits the sun, which is itself connected to the work of the galaxy. You can only say that there is no more connecting work when you reach the edge of the universe, but usually you can stop a little short of that. In your requirements work, you make a decision on how much you intend to study and how much can safely be declared to be outside your scope.

When you set the scope, you are deciding how much of the work you will study and what you will not study.

The decision as to what is inside and what is outside is not made capriciously. It is based on what you need to know, and for that we can look to domains of interest.

Domains of Interest

A domain is a subject matter area, and because it is "of interest," it is a subject matter area you need to know something about. Naturally, domains can be very largefor example, "insurance" or "banking" or "weather"so usually your domains of interest are parts of larger domains.

Let's consider the domains of interest for the IceBreaker work. The customer has told you:

"Roads freeze in winter, and icy conditions cause road accidents that kill people. We need to be able to predict when ice will form on a road so we can schedule a de-icing truck to treat the road in time. We expect a new system to provide more accurate predictions of icy conditions. This will lead to more timely de-icing treatment than at present, which will reduce road accidents. We also want to eliminate indiscriminate treatment of roads, which wastes de-icing compounds and causes environmental damage."

Look through this statement, paying attention to the subjects you need to know about. For example, the statement begins with the word "roads." Roads is likely to be a domain, as any work that predicts freezing roads will need knowledge of roadstheir geography and topography, their surface material, and anything else that helps predict when it will freeze.

"Icy conditions . . . We need to be able to predict when ice will form on a road" suggests a domain that covers the subject of temperature and, if the work is to make predictions, the behavior of temperature. This is the domain of weather.

"Schedule a de-icing truck" suggests that scheduling is a domain, as the product needs to have knowledge of how to schedule, or the aspects of scheduling that are common to any scheduling product.

The description of the work also mentions trucks, which suggests a domain of trucking or transportation. This domain would include information about what trucks can do, information about what they can't do, their carrying capacities, their speeds and ranges, and so on. The work needs to know these things if it is to manipulate a fleet of trucks and their drivers. Let's call this domain trucking.

This exercise gives you four domains:

1. Roads

2. Weather

3. Scheduling

4. Trucking

You are trying to determine the scope of the work you need to study. Clearly, you cannot study everything to do with all of the domains. You need to separate what is feasible and profitable to study from what you consider to be outside the scope of the work. We can highlight this division of study by building a context model that shows the work and its connections to the surrounding adjacent systems.

Let's start by looking for adjacent systemsthe works that surround the work. The domains of interest that you have identified act as input to discovering your adjacent systems.

For each domain, ask if there are physical entities that somehow represent the domain. Consider the domain of weather. Yes, there are physical things like wind and rain and clouds, but they are probably too far removed from our problem area to be useful. Instead, there is a weather forecasting service that can supply the work with information about the weather. Your client is always able to help with identifying these physical entities. As the work is involved in predicting to a great degree of accuracy where ice will form on roads, it needs more precise information than it can get from a weather forecast. The weather stations measure this kind of information and can transmit it to the IceBreaker work. However, weather stations are expensive and the client is anxious not to install thousands of them throughout Northumberland, so he tells you thermal map suppliers can provide information about temperature differentials for each yard of a road between the weather stations.

Each of these physical entities is potentially an adjacent system. We say "potentially" because we have to examine them before committing to any decisions. For each entity, we ask if it forms part of the work or if it lies outside the project's authority and should not be considered as part of the work. For example, forecasting the weather is something we are not keen to be involved in, particularly when we can buy forecasts from the weather forecasting service. Similarly, the weather stations and the thermal mapping supplier are things we can safely exclude from our studythe IceBreaker Company does not own them and has no interest in altering them in any way. Thus we consider them to be adjacent systems.

Not all domains have a physical presence. Some domains, for example, are purely policies the work has to adopt. For example, the scheduling domain is a policy domain: The rules for scheduling, optimizing truck usage, manipulating a fleet of vehicles, and so on have no physical presence. Nevertheless, this policy must be part of the work but does not appear as an adjacent system on the context model.

A physical entity represents the domain of roadsa department called Road Engineering. These people build and maintain the roads, so it is appropriate they inform the ice-predicting work about the roads. It seems unlikely you would have any desire or need to change Road Engineering, so there is probably an adjacent system called Road Engineering. The work communicates with it through one or more flows of data.

The client says the truck depot is the adjacent system that represents the domain of trucking. One of the main reasons for the work's existence is to schedule the trucks, so we would expect to see flows of this nature between the work and the truck depot (which is another physical entity).

First-Cut Work Context

Using our knowledge of the work's responsibilities and the information from the domains given previously, we can build a model showing the work in its context. This model appears in Figure 3.5.

Figure 3.5.

The work context diagram identifies the scope of the work that we intend to study. It shows the work as a single, as-yetuninvestigated process, surrounded by the adjacent systems. The named arrows represent the data that flows between the work and the adjacent systems. The adjacent systems are the physical representatives of the domains. The Truck Depot represents trucking. The Weather Station, the Weather Forecasting Service, and the Thermal Mapping Supplier represent the weather domain. Road Engineering is the physical representation of the roads domain. The remaining domain, scheduling, is represented by policy inside the work and has no external connection.

The work context shows where the responsibilities of the work and the responsibilities of the adjacent systems start and end. The flows of data between these entities identify what is done by the work and what must be done by an adjacent system. For example, the flow called Truck Change advises the work about changes to the de-icing trucksnew trucks added to the fleet, trucks taken out of service, modifications to trucks that would affect the way that they are scheduled. Why is this flow there? The work needs to know about trucks because it allocates trucks to roads when it produces the de-icing schedule. But what if we changed this responsibility? What if the depot became responsible for determining which truck was allocated to which road? The flow would be different. In fact, the Truck Change flow would not appear on the work context diagram at all, as there would be no need for it.

The work context shows where the responsibilities of the work and the responsibilities of the adjacent systems start and end.

Flows around the boundary of the work are the clearest indication of its responsibilities. By defining these flows, we define the precise point at which one area of work ends and another starts.

One problem commonly arises in setting the context: Often we see product-centric contexts that contain only the intended software product. Remember that you are investigating some work, and the eventual product will become part of that work. To specify the best possible product, you must understand as much of the work as possible. In most cases, projects that restrict their study to what they think the product will contain build less useful products and often miss important functionality that could well have been included in the eventual product. If you do not have any human beings inside your work context, then chances are that your work context is too narrow.

The moral of the story: First understand the work, then decide which product best supports that work.

Also consider the possibility that by enlarging the scope of the work you will find other potential areas for automation or other types of improvements. All too often, before we understand the work, we think of an automation boundary, and we never rethink it. Of course, then the "hard stuff"the work that we did not intend to automateis not considered. But by casting our nets wider, we can very often find aspects of the work that would benefit from automation, and in the end turn out to be cheaper than we thought. The moral of the story: First understand the work, then decide which product best supports that work.