IBM—华为PDM项目System Context

IBM Global Services

System Context

Work Product Description (WPD)

Unique ID: APP 011

? Copyright International Business Machines Corporation 1999, 2000

Version 3.0, January 2000

1 Description

The System Context work product initially represents the entire system as a single object or process and identifies the interfaces between the system and external entities. Usually shown as a diagram, this representation defines the system and identifies the information and control flows that cross the system boundary.

The System Context highlights several important characteristics of the system: users, external systems, batch inputs and outputs, and external devices.

?External events to which the system must respond

?Events that the system generates that affect external entities

?Data that the system receives from the outside world and that must be processed in some way ?Data produced by the system and sent to the outside world

The objects within the system boundary define the scope over which the development team has some control. The users and systems outside the boundary of the system are those that affect the system operation and development but are beyond the control of the developers within the currently defined scope of the project. Due to this scoping aspect of the work product, during early stages of a project it is useful to review this work product with the client to assist in delineating development team and client responsibilities.

Note that the System Context may limit the breadth of its coverage to emphasize just one class of external interfaces, for example, only the interfaces to external systems. Additionally, the details required at lower levels of elaboration will depend upon what interfaces are to be subsequently developed.

2 Purpose

The purpose of this work product is:

?To clarify and confirm the environment in which the system has to operate. Once agreed to by the client and the development team, the System Context becomes very useful for maintaining focus on the development effort.

?To provide the details at an adequate level to allow the creation of the relevant technical specification.

?Verify that the information flows between the solution to be installed and external entities are in agreement with any business process or context diagrams.

2.1 Impact of Not Having This Work Product

In the early stages of a project, without an agreed-on context for the system, it is difficult to define the boundaries of the project effort. There is risk of either expanding the development effort into areas that are not part of the system or of overlooking areas that should be developed.

2.2 Reasons for Not Needing This Work Product

The System Context need not be developed in the following circumstances:

?The system is not complex and has no external interface or data conversion requirements.

?The application being developed is one of a number of applications within an existing system for which context documentation already exists.

?The client or another third party vendor developed this work product and the content has been shared with the current project team.

3 Notation

Several notations can be used to diagram the component of System Context. Most often they are represented as a level-0 process model, although static object models or functional models can represent them. Diagrams are generally better than text for this kind of overview material. The template below shows information flow into and out of the system. Note that in an actual diagram instance, each information flow would be labeled with a descriptive name to help the reader understand the purpose of the interface. Each flow then should be described in more detail in narrative form to supplement the diagram. At a minimum, the following information should be provided for each flow:

?Owner of the external entity

?Number of users / transactions represented by the flow

?Frequency of the transactions for each flow

?Approximate volume of data contained in each transaction

4 Example

The System Context from an advanced intelligent network telecommunications application is shown below. The creation and refinement of this work product instance is an excellent example of the utility of the System Context. When the diagram was first developed with the customer, the customer stated that the association between the Total Customer Service (TCS) and the Service Management System (SMS) was one-to-one. Upon further questioning about what exactly the TCS is the customer said that it was, in fact, an integrated workstation. When the customer was asked how many integrated workstations could be expected to interface with the SMS, the answer was 750 in Phase I and 1500 in Phase II of the project. The customer, upon further questioning, stated that the workstations would input data between 1:00 AM and 5:00 AM.

The difference between one interface device inputting telecommunications service subscription data over 24 hours and 1500 devices inputting large amounts of data over 4 hours had a significant impact on the data handling requirements for the SMS interfaces to the integrated workstations.

When asked about the Service Creation Environment (SCE), the customer explained that there was no physical association between the SCE and the SMS. The customer further explained that the SCE provides service definition to the SMS. After extensive discussion, it was clear that there had to be some means for the SCE to provide the service definition to the SMS, and the developers would have to provide for that interface.

This example shows how the use of the System Context can help resolve system level issues very early in the project and establish an effective method of communication with the customer (and users if different from the customer).

5 Development Approach

1. Identify all external entities and users that need to interface with the system. This information can

often be obtained from business process models and definitions that are either pre-existing or

currently under development.

2. Create the initial context diagram by drawing an object (box or circle) and labeling it with the name of

the system to be developed. Surround this initial object with other boxes labeled with the names of the external objects.

3. Ask the customer, user, or business area expert what the associations are between external objects

and the system and how often these occur. Some of this information may be indicated on business process models, transaction scripts, or context diagrams.

4. If an existing application is being replaced, consider creating a context diagram for the existing

system as well. This may assist in validating the new context information, by indicating existing external interfaces to other systems, equipment, databases, files, users, and communication links. 5. Indicate what volumes of data and what kinds of transactions, with their associated feeds and

speeds, must be supported by the system.

6. Document issues, issue resolutions, and reasons for everything captured on the diagram.

6 Validation and Verification

?Verify the support provided for business process requirements:

?What are the new and re-engineered processes and tasks?

?How many of the new processes will be automated?

?Do they assume any change in the functionality of external systems?

?Do they bring any of the functionality in the external systems into the scope of the new system?

?How does this affect the connectivity to the external entities?

?Verify the System Context against the use case model:

?Verify that important actors mentioned in the use cases are represented in the context diagram.

?Walk through the context diagram with the customer, users, and domain experts to see if it captures all of the external interactions expected.

?Verify the System Context against the user requirements:

?What user profiles will affect the structure of the system?

?How many people does the system support? How might this change?

?Verify the System Context against the data requirements:

? With which existing systems, databases, or files will the system exchange data?

? With which planned systems, databases, or files will the system exchange data?

?Verify changes to the batch systems:

?Which reports that are currently run as batch jobs will be done interactively?

?How does this affect the connectivity to the external entities?

?Consider the Operational Modes of the System:

?What are the operating modes that the system should provide: normal operation, shutdown, startup, training, etc.? How will this change?

?How does this affect the connectivity to the external entities? Verify the relationship of the system with the external entities.

?What, if any, parts of the current system must be retained and interoperate with the new system?

?How much current data must be retained?

?What existing systems will link to the new system?

?When will existing systems need to be replaced?

7 Advice and Guidance

The following guidance is suggested:

?Establish the initial System Context as early as possible in the development process.

?Keep it simple.

?Use it as a reference for more detailed modeling.

?Make sure that more detailed models do not add interfaces that are not in the System Context.

?If you discover the need for interfaces that are not in the System Context through more detailed modeling, the System Context will have to be changed to reflect the new interfaces.

8 References

DeMarco, T. (1978). Structured Analysis and System Specification. Yourdon Press.

Yourdon, E. (1989). Modern Structured Analysis. Yourdon Press.

9 Estimating Considerations

System Context work product should require 40-60 hours to develop.

10 Revision History

Date of this release:Date of next revision:

Revision Number Revision

Date

Summary of Changes Changes

Marked?

3.0January

2000

MIFP published version – no changes.

1.4December

1999Revised WPD to separate data-related content and context

from System Context.

N

1.3September

1999Merged with MethodBlue ‘Current Application Documentation’WPD to create ‘Current System Context Documentation’

System Context Diagram, Version 1.2August 1999 A new template was applied, and the document was edited for grammatical errors, style and content.