The operational context diagram

How it complements the system context diagram, and helps you design technical aspects of a system

For many years, application architects and analysts have used the system context diagram (SCD) as a powerful tool to share the high-level view of a system. The SCD provides only a functional view of the system, a view that later leads to the use case model. To completely specify the system under development, non-functional requirements must be taken into account. NFRs create another view of the system context: the operational context diagram, which then segues to the operational model. In this article, learn about a technique to complement the SCD with a non-functional oriented operational context diagram.

Vito Losacco (losacco@it.ibm.com), Executive IT Architect, IBM

Vito Losacco photoVito Losacco is an executive IT architect with IBM Global Technology Systems in Italy. After eight years at the Rome development lab, in 1998 he joined IGS to in technical and leadership roles on major customer projects, focusing on IT operations and infrastructure architectural solutions designs. He currently has a technical pre-sales position as ITSA for large, cross-industry and cross-LoB engagements. Vito has been a speaker at the IBM Global Security Conference II in 2003, and TLE speaker in 2008.



Fabio Castiglioni (f.castiglioni@it.ibm.com), Senior IT Architect, IBM

Fabio Castiglioni photoFabio Castiglioni is a senior IT architect with IBM Sales and Distribution in Italy. He has 13 years of experience in a development lab, where he covered technical and management positions on international projects. In 1995 he was appointed Technical Director for a research project on OO technologies. In 1998 he was an IGS Senior IT Architect working on major government projects. Fabio is one of the teachers of Component Modeling classes for IBM architects. He was a speaker at the SOA and Web Services conference in 2005, and TLE speaker in 2006 and 2008.



17 February 2009

Also available in Vietnamese

Introduction

We've always liked the simplicity of a system context diagram (SCD). You can draw it in front of a customer, and in just a few minutes reach a shared understanding of the scope of a project, the actors, and even of the major use cases that the system has to sustain.

If we were journalists and had to describe the news instead of a system, our SCD would have answered the Who and, as a first cut, the What. But, the SCD would not have answered the Where, When, How and How Much questions. Without this information the context of our system is only partially defined.

The initial analysis task has to focus on the functional content only. Even the functional architecture can be impacted by the resolution of the non-functional requirements (NFRs). There is no conceptual difference between the functional and non-functional requirements, since both are expressions of motivations by one of the stakeholders, or influencers, in the system under definition.

See Resources for information about the business motivation model.

Rozanski and Woods categorize the various stakeholders who have an interest in an IT system as:

Acquirers
Oversee the procurement of the system or product.
Assessors
Oversee the system's conformance to standards and legal regulation.
Communicators
Explain the system to other stakeholders in documentation and training materials.
Developers
Construct and deploy the system from specifications (or lead the teams that do so).
Maintainers
Manage the evolution of the system once it is operational.
Suppliers
Build or supply the hardware, software, or infrastructure on which the system will run.
Support staff
Provide support to users for the product or system when it is running.
System administrators
Run the system once it has been deployed.
Testers
Test the system to ensure it is suitable for use.
Users
Define the systems functions and ultimately make use of it.

Where an Enterprise Architecture (EA) framework is in place, many stakeholder requirements would already be specified in the EA itself. They should be taken into account as primary input. Otherwise, interviewing the stakeholders can be a good way to capture their needs. The needs should be categorized as functional or NFRs. The NFRs should be categorized into qualities (objective) and constraints (given). Non-functional qualities can be ranked by their perceived importance by the stakeholder (from VH = Very High to VL = Very Low).


Categorizing the requirements

Many taxonomies have been proposed for organizing NFRs: runtime and non-runtime qualities, business and technical constraints, ISO9126 categories, and so on. This article uses a slightly different one based on the concept of "primary need."

In our approach, NFRs are what the stakeholders need from the system under design. Those requirements will shape the system from the operational point of view. Each requirement may be expressed by several classes of stakeholders, but it's usually coming from a primary source. For example, a "pages per second" objective is a requirement for the:

  • Acquirers, who have to include and verify it in the procurement process.
  • Developers and Maintainers, who have to reach and maintain the established target.
  • System Administrators, who have to track and measure the runtime performance.

However, even if apparently very technical, the pages per second need is ultimately rooted in the Number of Business Transactions per front-desk employee, a line of business (LOB) or user need.

As a guideline, we'll use the following classification for NFRs :

Actor-dependent
Requirements that represent the needs of the users of the system (human or not), and can be further categorized as:
  • System qualities needed by users or external systems interacting with the system, as represented in the SCD.
  • System qualities required by the IT Service Manager, for example the set of the specialized actors (human and system) managing the operations of the system under design.

Actors can require an NFR to become an actor’s constraint, which the system has to comply with. Think of constraints as NFRs that cannot be negotiated (although sometimes they can be rejected).

Actor-independent
Requirements that represent system qualities which cannot be rooted to an actor but to one of the other stakeholders. Some NFRs can belong to both the actor-dependent and actor-independent categories at the same time. For example, security can simultaneously be a requirement for a specific class of users and a standard for the enterprise.

Actor–independent NFRs that the system has to comply with may become actor-independent constraints.

Generally, NFRs can be ranked by their stakeholder's perceived importance, for both categories, but constraints will be specified through a statement (such as the standard or regulation to be met).

This classification has the advantage of tying directly to the SCD and therefore allowing, as you'll see later, a similar representation.


The realm of NFRs

The starting point in listing NFRs is the ISO 9126 taxonomy. Since the final objective is to build an operational context diagram to drive the development of the operational model (OM) of the system, the following modifications were made to the ISO 9126 list.

  • For simplicity, used Reliability as aggregation of:
    • Maturity
    • Recoverability
    • Fault Tolerance

    Used Usability as aggregation of:

    • Learnability
    • Understandability
    • Attractiveness
  • Dropped Functionality and Interoperability (which simply defines that one external system is an actor of our SCD), since both have little impact on the OM definition.

    Dropped Stability, Changeability, and Replaceability for the same reason.

  • Added Security Compliance as an important factor for today's system designs.
  • Inserted a set of business-related constraints to categorize the LoB's inputs that may affect the OM:
    • Business policies (business behavioral policies are the constraints related to the LoB's business decision, for example multi-channel customers support).
    • Business domain (business structural policies are the constraints resulting directly from the industry or domain policies, such as the opening hours for shops).
    • Schedule/Budget refers to the financial constraints of the project.
    • Locations are the constraints of the sites that have to be served by the system.

    The list can be expanded, depending on the project.

Gathering NFRs

Since the operational context, as the system context, will be defined very early in the analysis process, don't expect precise quantitative targets for most NFRs -- just qualitative ones.

While gathering information from stakeholders, you might need to supply a more quantitative, though artificial, view of the requirement to avoid all NFRs being rated “Very High.” Using performance as an example, you might ask stakeholders if acceptable response time would be less than one second, less than two seconds, and so on. For availability, the question may be whether the system has to be available 24x7, 24x6, or 12x6.

It's important to understand that you might use only representative values, depending on the type of system under design. It is up to the IT architect to devise such a representative set of values. The real NFRs quantification will be later in the design cycle (unless these requirements are real constraints for the system).

The resulting list of NFRs, shown in Figure 1, can be used to gather stakeholder needs.

Figure 1. Categorizing NFRs
Non Functional Requirements categorization|outline

Stakeholders are organized into three main groups:

  • SCD actors.
  • Stakeholders who interact with the system's artifacts (run time or development time), such as developers.
  • Stakeholders who interact only with the process of introducing the system in the business context, such as assessors.

Those inputs will be consolidated in the table in Figure 2, which represents the system's NFRs matrix and drives the operational context diagram representation.

Figure 2. System NFRs Matrix
System NFRs Matrix

Let’s now see how our chief architect can exploit the operational context diagram and the system NFRs matrix to provide a first, technology-neutral view of the operational architecture. If component modeling work is not available, other techniques such as the Conflicting Requirements Matrix cannot be used.


The operational context diagram

The operational context diagram is the starting point for designing the technical aspects of the system. To help explain the concepts, the following scenario involves a fictitious company derived from a real home shopping business, as shown in Figure 3.

Figure 3. Home shopping system context diagram
Home shopping system context diagram

The customer wants to start a home shopping capability, with the ability to offer every single service in several ways: telephone call center, Internet, or in-store kiosk.

The company environment consists of a main office, and a warehouse at a separate location. The call center is outsourced.

The chief architect collected NFRs from the stakeholders, which lead to the table in Figure 4. Only primary sources for a given requirement are shown.

Figure 4. Example stakeholders responses
Example stakeholders responses

The responses were then consolidated into the system NFRs matrix in Figure 5.

Figure 5. Example system NFRs matrix
Example system NFRs matrix

The table above shows that the stakeholders assigned relative importance to the requirements. Some of them were also categorized as system constraints.

The operational context diagram in Figure 6 represents the same information in a graphic layout. Only requirements with High and VeryHigh importance are shown. Qualities (in red) and constraints (in blue) are connected to the originating actor, or to the system's boundary, in case they are common to all actors. Qualities and constraints which are not originated by a specific actor are aligned on the left of the figure as system characteristics.

Figure 6 concisely shows the different expectations that the actors have of the system. The operational context diagram is a very good aid for explaining and verifying the system’s complexity to the customer. For example, for both Internet and kiosks, usability is a main concern and will probably require a channel-specific interface, while 24x7 operations is a constraint only for the Internet option.

Figure 6. Home shopping operational context diagram
Home shopping operational context diagram

The chief architect can now exploit the operational context diagram and the system NFRs matrix to provide an early, technology-neutral view of the operational architecture.

The actor-specific quality related NFRs translate into requirements on the conceptual nodes supporting that actor. Usually, this involves multiple nodes, and some nodes have to support more than one actor type. Of course, the more demanding requirements apply to the common nodes.

Using the information supplied with the Locations requisites and some connections constraints, you can now draft an initial zoning for the system's main infrastructural components. You know where to place conceptual nodes, which eventually will host the components supporting the application level functions:

  • The central runtime location of the system will host the main application services (CN_App Svcs) that need an AAA integration service to reuse the existing AAA system (a stated constraint), and an integration interface service (CN_Old WH Interface Svc) to allow interoperability with the warehouse’s existing interface.
  • The kiosk, Internet user, and Call Center representative require highly usable, channel-specific interfaces, suggesting a separation of the systems.

    Perhaps adoption of a different technology for the rendering of the interfaces is in order.

  • Consider a conceptual node, enabling manageability service, to satisfy the high operability requirement for the IT service manager actor.
  • The Call Center, in a remote location with low reliability connectivity, requires Very High performances. It can be supported by caching local copies of 'low volatility' data (similar to a catalog's descriptions and pictures) through a dedicated system.
  • To guarantee interoperability with the credit card system, you need to add dedicated gateway conceptual nodes.

Figure 7 shows the resulting conceptual operational architecture of our system.

Figure 7. A first cut of the operational architecture
A first cut of the operational architecture

Starting from this view, and with input from the application level component model, the infrastructure IT architect is lead directly into detailing the system's final operational model, as follows.

  • Nodes with reliability set to High or Very High would imply a clustered or balanced infrastructure.
  • Performance needs would require appropriate connections and servers throughout.
  • The requirements are for a highly-secure system, so you have to "seal," with a security provider, all the external interfaces (Internet and external networks like the credit agency or the call center company) and the interfaces with insecure areas of the intranet, such as the warehouse and stores.
  • The resource utilization target would require an appropriate capacity planning activity in later stages.

By using the specifications of NFRs at the system's actor level, the approach outlined in this article enables a more precise shaping of the infrastructure. You can avoid, for instance, providing resources that are not justified by an actor's actual needs.


Conclusion

In this article you learned about a technique to complement the well-known system context diagram with a non-functional oriented operational context diagram.

The operational context diagram is the starting point for designing the technical aspects of the system, including the supporting infrastructure.


Acknowledgements

The authors thank Philippe Binet, Distinguished Engineer with IBM GTS in Italy, Piero Sguazzero, Distinguished Engineer with IBM SWG in Italy, and Raffaele Pullo, Executive IT Architect with IBM GTS in Italy, for their encouragement and valuable comments on this article.

Resources

Learn

Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=369447
ArticleTitle=The operational context diagram
publish-date=02172009