7 The Scope of the Work

7a. The context of the work.

Content

The work context diagram identifies the work that we need to investigate in order to be able to build the product. Note that this includes more than the intended product. Unless we understand the work that the product will support, there is little chance of building a product that will fit cleanly into its environment.

The adjacent systems on the example context diagram e.g. Weather Forecasting Bureau, indicate other subject matter domains (systems, people and organizations) that need to be understood. The interfaces between the adjacent systems and the work context indicate why we are interested in the adjacent system. In the case of Weather Forecasting Bureau, we can say that we are interested in the details of when, how, where, who and why they produce the District Weather Forecast information.

Motivation

To clearly define the boundaries for the work study and requirements effort. Without this definition, there is little chance of building a product that will fit seamlessly into its environment.

Examples

Considerations

The names used on the context diagram should be consistent with the naming conventions discussed in section 5.

7b. Work partitioning

Content

An event list, identifying all the business events to which the work responds. The business events are user-defined. The response to each event represents a portion of work that contributes to the total functionality of the work.

The event list includes:

Event Name

Input from other systems (identical with name on context diagram)

Output from other systems (identical with name on context diagram)

Internal objects/entities that are connected to this business event. For example, both events 8 and 9 would be connected to an internal object called road. In other words there is a need within the context to remember information about roads and that information is relevant to events 8 and 9 (and many other events as well). It is this identification of common internal objects that provides a link between events.

Motivation

To identify logical chunks of the system that can be used as the basis for discovering detailed requirements. These business events also provide the subsystems that can be used as the basis for managing detailed analysis and design.

Example

Event List

Event Name	Input & Output
1. Weather Station transmits reading	Weather Station Readings (in)
2. Weather Bureau forecasts weather	District weather Forecast (in)
3. Road engineers advise changed roads	Changed Road (in)
4. Road Engineering installs new weather station	New Weather Station (in)
5. Road Engineering changes weather station	Changed Weather Station (in)
6. Time to test Weather Stations	Failed Weather Station Alert (out)
7. Truck Depot changes a truck	Truck Change (in) Amended De-icing Schedule (out)
8. Time to detect icy roads	Road De-icing Schedule (out)
9. Truck treats a road	Treated Road (in)
10 Truck Depot reports problem with truck	Truck Breakdown (in) Amended Gritting Schedule (out)
11. Time to monitor road gritting	Untreated Road Reminder (out)

Considerations

Attempting to list the business events is a way of testing the work context. This activity uncovers uncertainty and misunderstanding about the project and helps with precise communications.