System context

The result should show how the business works, with the component of interest being one element. A component can (and usually does) play several distinct roles, providing a different interface to each of several other objects, or actors, as they aie often called in this context as usual, they may be other pieces of software, people, or equipment. A collaboration diagram can be used to illustrate the different interactions (see Figure 5.8). This is often called a system context diagram it is traditional to draw the external roles as stick figures, although type boxes are also OK. 

Figure 5.8 System context with abstract actions.

Figure 5.9 System context with refined actions.

Make a model by adapting the initial statement of requirements, by interviewing prospective users, and by using domain knowledge and existing systems and standards. Much of the static type model will be taken over from the business model. The big difference is in the system context what the system is required to do and, more important, how people will do their jobs after it is installed. 

System or component contexts A section that describes the use of the system by external agents to accomplish business tasks. It includes system contexts as collaborations, scenarios, user-interface sketches, and prototypes. 

When initially describing the system context, we avoid describing UI specifics, because these can vary. Detailed interactions via the user interface are better treated as a refinement of the abstract use cases that are being carried out. The basic MVC architecture applies to many forms of user interfaces, including graphical, character-based, touch screen, and voice-response. 

Understand problem, system context, architecture and nonfunctional requirements... 

Functional requirements on the system Usually in the form of a system context diagram with use cases and scenarios... 

System context Acollaboration centered on the target software system, intended to clearly define the boundary of the system. The use cases in which the system is an actor are those that must be developed as part of the system. 

Type model plus system specs The system context is defined, and the primary actions that the system participates in are first specified as abstract actions, and then refined to a level of an approximately atomic interaction with the system. Atomic interactions are those that, unless completed, would not constitute meaningful or useful operations on the system. 

Apply Abstraction and Re-refine to Each Development Layer. Do this for the business model, the system context model, and the abstract and detailed layers of design, as listed in Section 13.5, Main Process Patterns. Each of the three principal layers can be approached differently. 

As early as possible, define the system context and all known constraints on the system, its initial architecture, and internal components. Examine interfaces to external systems. There is often significant work in realizing the connections to those systems, whether it involves communications, hardware interfaces, database requests, and so on. This work can be started early. 

A business improvement effort may be triggered by the installation or upgrade of a software system, a perceived quality problem in business performance, or the hiring of a new senior executive. Although the explicit request may be simply to work on a software project, the analyst s scope often expands to include business improvement. This is part of what the system context diagram (see Pattern 15.5, Make a Context Model with Use Cases) is about—the computer system as one element in the design of a business process. 

Similarly, we could model a video store as one large-grained object—an external view or we could describe internal roles and interactions, such as the store clerk, the stockkeeper, the manager, and the video system—an internal view. We illustrate two levels of action abstraction in this chapter the object granularity will be refined later, when we define the system context and user roles. 

The specifications of a component you are asked to design may come from a larger design. This situation contrasts with the more user-facing situation of an end-product design, where your team s responsibility includes documenting the system context use-cases (Pattern 14.32, Use-case led system specification (p.619)). 

Many of the collaborations will follow stereotypical interaction patterns e.g. an interaction which consists of log in, conduct some transactions, and log out or make a selection, and then operate on that selection. These can be abstracted as frameworks (Chapter 9, Model Frameworks and Template Packages (p.371)), then applied and composed to define the system context collaboration... 

You can model the system context, and corresponding scenarios, system type model, and action specs, at any consistent level of granularity. The actions should be refined to the level where completion of the action accomplishes an atomic transaction with the system, and must be completed in its entirety by the actor to be meaningfully handled by the system. 

Do not go overboard with separating actor roles. Specifically, if there are strong dependencies in state or attributes of the actor involved across two actions, do not needlessly split into two actor roles. For example, if the system requests authorization from an external system for a credit card, and follows with an approval request for a payment amount on that same card, it would be better to use a single external role for the authorization system. Similarly, it would not be helpful to distinguish reserver , borrower , and returner as separate roles in a library. Map the user-roles in the system context to roles in the business model perhaps eventually to job descriptions. 

We already have a system context model (Pattern 14.34, Make a Context Model with Use-Cases (p.623)). 

Note that the model represents the state of the whole system from its external users point of view — not just the business logic, and not just the software hardware may be included too. So if a display shows the result of some calculation, and that display is part of the boundary the system, then that value can be an attribute in the model, even if the software forgets it immediately after sending it to the display. It s the system context model that sets this boundary. 

In such cases, most of the work illustrated in this section should already have been done and in considerably more formality than shown here. In fact the relationship betwen our system and its context is then exactly that of a Major Component as illustrated below in Section 14.3, System context diagram, on page 656. 

Software systems are a part of the business and its operations, and should be a part of business models — at least at some level of detail. So what is the link between business models, the system context for a particular software component, and the subsequence software specifications and designs ... 

In identifying the system context and use cases, we have actually considered some details of user-interfaces and fine-grained interactions yet the system context seems to step back to a more abstract level of use case. This process can be rationalized as follows ... 

Modeling and assessments provide the capabilities to evaluate technology options in a total systems context (i.e., considering costs and impacts over the full product cycle). Further, the societal and environmental effects are analyzed to provide a basis for assessing trade-offs between local environmental impacts and global impacts. 

This is an example of a practical problem of considerable importance, where the relevant research would certainly be described as applied . Yet it would require quite specialised inputs of scientific information (for example, the life-cycles of parasitic nematodes) to be harnessed within a systems context. We are thus brought back to the need for a systems approach to research and the questions here is how can that be organised and funded ... 

The chemistry of the atmosphere is diverse, driven in the main by the interaction of light with a few molecules that drives a complex array of chemistry. The type and impact of atmospheric chemistry varies in concert with the physical and biological change throughout the atmosphere. An integral understanding of atmospheric chemistry within the earth system context underpins many contemporary global environmental problems and is therefore vital to sustainable development. 

Design reviews (also known as design qnaliflcation) mnst be conducted and documented to verify that nser and regulatory requirements are satisfied in the wider system context inclnding eqnipment, processes, and mannal interaction. 

User/site acceptance testing of compnterized systems (known as qualihcation) must cover installation, operation, and performance in the wider system context inclnding equipment, processes, and operator interaction (i.e.. Installation Qnalihcation, Operation Qualification, and Performance Qualification). 

Context refers to additional data or information that show how the record is related to its application as well as to other records or systems. Context is often described by metadata (i.e., data about data) or meta-information (i.e., information about information). 

Figure 2. Overall system context of the pheromone detection system in moths (shown in centre). AL is the antennal lobe, MB the mushroom bodies and, LH the lateral horn. This schematic shows the animal in an input/output diagram with respect to its environment.

Rasmussen, J. (1979), On the Structure of Knowledge A Morphology of Mental Models in Man-Machine Systems Context, Report M-2192, Riso National Laboratory, Denmark. 

Many prescriptive models of organizational design exist (e.g., Hackman 1990), but relatively few studies applied specifically to test and inspection. Early work by Jamieson (1966), Thomas and Seaborne (1961), and McKenzie (1958) established that humans change their inspection behavior, and hence performance, in predictable ways when social and oiganizational variables are changed. Inspection, McKenzie notes, is always of people. The inspector is always judging the work of others, or even his or her own work. Thus, pressures on the inspector are to be expected. More recent work (e.g., Taylor 1991) has examined the sociotechnical systems context of inspection in aviation main-... 

---