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.
Rozanski and Woods categorize the various stakeholders who have an interest in an IT system as:
- Oversee the procurement of the system or product.
- Oversee the system's conformance to standards and legal regulation.
- Explain the system to other stakeholders in documentation and training materials.
- Construct and deploy the system from specifications (or lead the teams that do so).
- Manage the evolution of the system once it is operational.
- 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.
- Test the system to ensure it is suitable for use.
- 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 :
- Requirements that represent the needs of the
users of the system (human or not), and can be further categorized
- 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).
- 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.
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:
- Fault Tolerance
Used Usability as aggregation of:
- 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.
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
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
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
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
The responses were then consolidated into the system NFRs matrix in Figure 5.
Figure 5. 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
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
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.
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.
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.
- Analyze requirements for complex software systems in a new, holistic way (developerWorks, Feb 2009): Learn how functional and non-functional requirements are opposing forces that are handled similarly to forces in civil engineering structures. .
- Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives by Rozanski and Woods is a practitioner-oriented guide to designing and implementing effective architectures for information systems. It is both a readily accessible introduction to software architecture and an invaluable handbook of well-established best practices.
- The Business Rules Group formulates statements and supporting standards about the nature and structure of business rules, the relationship of business rules with the way an enterprise is organized, and the relationship of business rules with systems' architectures.
- The Business Motivation Model: Business Governance in a Volatile World (Sep 2007) deals with the 'motivation' cell of the Zachman Framework.
- N. Nayak, M. Linehan, A. Nigam, D. Marston, J.-J. Jeng, F. Y. Wu, D. Boullery, L. F. White, P. Nandi, J. L. C. Sanz. Core business architecture for a service-oriented enterprise" (IBM Systems Journal, vol 46, no 4, 2007) focuses on the core business architecture, the set of essential elements in each of the five domains, and the interrelationships among these elements.
- Learn more about the ISO 9126 Standard.
- Defining Non-Functional Requirements (Bredemeyer Consulting) lays out important concepts and discusses capturing non-functional requirements in such a way that they can drive architectural decisions and be used to validate the architecture.
- An IBM Rational approach to the Department of Defense Architecture Framework (DoDAF) Part 1: Operational view (developerWorks, Mar 2006) presents an overview of the Department of Defense (DoD) Architecture Framework (DoDAF) and describes its Operational View (OV) products.
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®.