Chapter 2
Systems are created for a given purpose; therefore, it is critical to understand why we are building a given system. No matter how technically elegant, it is no good if a system’s purpose is not clear and it fails to meet its intended objectives. These intended objectives are typically found in the strategic vision that prompted an organization to undertake the development of a system of interest.
Consider a company that sells building automation devices along with software applications that manage these devices. Software helps with the sale of these hardware devices but does not make any money. Over the years, the marketing and sales divisions have come to realize that the hardware is being commoditized and their profit margins on the sale of the hardware devices are shrinking. To sustain their business long term, the vice president (VP) of product development in consultation with the chief technology officer (CTO), decides to create a new building automation system that will be profitable. They wish to accomplish this by doing two things: reducing internal development costs and expanding the market. Internal development costs can be reduced by replacing several of the existing applications with a single building automation system. Market expansion can be achieved by entering new and emerging geographic markets and opening new sales channels in the form of value-added resellers (VARs). VARs sell the new building automation system under their own brand to support building automation hardware devices of many different manufacturers.
What are the intended objectives of the new building automation system? Do you think these objectives will significantly influence the architecture of the system of interest? Who are the stakeholders for these objectives?
The development of the new building automation system is prompted by the following business goals:
Market expansion requires taking language, culture, and regulatory concerns of different markets into account. Partnering with VARs requires the new building automation system to work with hardware devices from many different manufacturers. Reduction in development costs may be achieved through consolidation of development and maintenance efforts for disparate software applications.
Certain business goals (such as market expansion and partnering with VARs) can give rise to requirements that can have a significant impact on the architecture of a system of interest; others (such as reduction in cost) may not (Sangwan and Neill, 2007). Depending on the context, there can be many such influential goals. Although in the case of a building automation system they were fairly explicitly stated, on other projects there may be a need for engaging stakeholders to elicit these goals. To help with this process, Table 2.1 lists typical categories of business goals that apply to projects undertaken by corporations.
Categories of Such Business Goals
Goal Category |
Goal Examples |
Goal Category |
Goal Examples |
Organization’s growth and continuity |
System promotes growth and continuity through
|
Meeting financial objectives |
System meets financial objectives through
|
Meeting personal objectives |
System meets personal objectives through
|
Meeting responsibility to employees |
System fulfills responsibilities to employee through
|
Meeting responsibility to country |
System fulfills responsibilities to a country through
|
Meeting responsibility to society |
System fulfills responsibilities to a society through
|
Meeting responsibility to shareholders |
System fulfills responsibilities to shareholders through
|
Managing market position |
System helps manage market position through
|
Improving business processes |
By improving business processes, a system creates opportunities for
|
Managing product’s quality and reputation |
System helps
|
Sourc e: Based on P. Clements and L. Bass, IEEE Softwar e pp. 38–46, November/December 2010.
There is some overlap within these categories, but the intent is not for them to be mutually exclusive. They are simply there to serve as a vehicle for facilitating the elicitation of business goals from the stakeholders of a system under design.
When eliciting these objectives, care must be undertaken to engage all stakeholders from the organizations involved in development, acquisition and operation of a system that can include any group or individual affected by or in some way accountable for the outcome of an undertaking. Because arriving at an agreed-to set of these objectives can be a long and arduous process, it is important also to know who the primary stakeholders are that exert a greater degree of influence on a project and have the authority to help resolve conflicts when they arise (National Aeronautics and Space Administration [NASA], 2007).
Business goals define the purpose for which a system is being created. The architecture is designed to fulfill that purpose.
A business goal scenario is a six-part structure that makes a business goal concrete and actionable (Clements and Bass, 2010):
We show the business goals for the building automation system in Table 2.2. Initially, the business goals may be captured informally as shown in the middle column and later expressed as detailed scenarios shown in the leftmost column in Table 2.2.
Business Goals for the Building Automation System
Goal Category |
Informal Business Goal Statement |
Business Goal Scenario |
Goal Category |
Informal Business Goal Statement |
Business Goal Scenario |
Organization’s growth and continuity |
We need to reduce the internal development cost by replacing several applications with a single building automation system. |
|
|
||
|
||
|
||
|
||
|
||
Meeting financial objective |
We need to expand by entering new and emerging geographic markets. |
|
|
||
|
||
|
||
|
||
|
||
Meeting financial objective |
We need to open up new sales channels through partnership with VARs. |
|
|
||
|
||
|
||
|
||
|
A business goal scenario makes a business goal concrete and actionable.
One observation to make is that business goals can be fairly broad, such as a company’s desire to be profitable, and may need refining. As also pointed out previously, we must carefully examine the business goals and see if they give rise to requirements that have an influence on the architecture of the system under development. For example, profitability may be achieved by making changes to the business processes of a company and therefore may not have anything to do with the architecture of the system to be developed.
Table 2.3 shows the business goals and their relevance to the building automation system introduced in the previous section. Business goals are synonymous with mission objectives, a term typically used by the Department of Defense (DoD) and NASA when creating architectures of weapon and space systems (NASA, 2007). Just like business goals are refined to determine how they apply to the system under development, mission objectives are refined into operational objectives, some of which would be relevant to the product being engineered. The relevant operational objectives are sometimes called engineering objectives.
Business Goals and Engineering Objectives for the Building Automation System
Business Goal (Mission Objective) |
Goal Refinement (Engineering Objective) |
Expand by entering new and emerging geographic markets |
Support international languages |
Comply with regulations that have an impact on life-critical systems such as fire alarms |
|
Open new sales channels in the form of VARs |
Support hardware devices from different manufacturers |
Support conversions of nonstandard units used by the different hardware devices |
Notice that the reduction in internal development costs can be achieved by aggregating the development and maintenance functions of several small applications into one project for the building automation system. It has more to do with changes to the organizational structure than the architecture of the system to be developed and therefore is not included in Table 2.3.
Engineering objectives refine business goals/mission objectives to show their relevance to the system under design.
Another important observation to make is that business goals relevant to a system correspond to quality attributes the end system must exhibit. These quality attributes become the basis for translating the business goals and their associated engineering objectives into architectural requirements. For instance, a business goal to maintain market reputation can correspond to creating products that are highly usable and reliable and perform well. Can you think of some of the quality attributes that correspond to the business goals of the aforementioned building automation system?
To support a multitude of hardware devices and consider different languages and cultures, the building automation system must be able to accommodate these changes easily (a modifiability requirement). To support different regulations in different geographic markets, the system must respond to life-threatening events in a timely manner (a performance requirement). It is critical that the business goals and their implied quality concerns be fully understood because they are the very reason a system is created. They will play a significant role in the creation of architecture for a given system. If ignored or not fully understood, you risk creating a system that may not be fit for its intended purpose. We list some predominant quality attributes (Bass et al., 2013) and their description in Table 2.4.
With crowded highways, traffic congestion, and rising fuel prices, consumers are looking for cars that are not only safe but also less dependent on gasoline. The worldwide emissions legislation for automobiles is also requiring a reduction in fuel consumption and emissions to reduce greenhouse gases that cause environmental pollution. These factors that have become the cornerstone for innovation in the automotive industry must be largely achieved with the help of electronics and software. They are the business goals or mission objectives that are driving the manufacturing of modern-day automobiles. Some significant quality attributes associated with these business goals are the following:
As shown in Figure 2.1, a high-end vehicle today has upward of 80 ECUs that communicate over a complex in-vehicle network that runs over 100 million lines of code to satisfy these quality attribute requirements, and you never hear of a blue screen of death or the need to reboot when operating a vehicle; it is simply not an option (Mossinger, 2010).
Quality Attributes and Their Descriptions
Quality Attribute |
Description |
Availability |
Concerned with preventing, detecting, and recovering from system failures |
Interoperability |
Concerned with meaningful exchange of information among two or more systems |
Modifiability |
Concerned with the impact of making a change to a system |
Performance |
Concerned with latency and throughput measured as the length of time it takes for a system to respond to an event (latency) and how many events a system can respond to in a given period of time (throughput) |
Security |
Concerned with a system’s ability to resist unauthorized usage while providing its services to legitimate users with the following guarantees:
|
Testability |
Concerned with the ease with which a system can be made to demonstrate its faults through testing |
Usability |
Concerned with the ease with which a user can perform a given task and the type of support a system provides for it |
Table 2.5 lists the business goals, their refinement (showing relevance to the system under consideration), and their corresponding quality attributes.
Business Goals, Engineering Objectives, and Their Corresponding Quality Attributes
Business Goal (Mission Objective) |
Goal Refinement (Engineering Objective) |
Quality Attribute |
Expand by entering new and emerging geographic markets |
Support international languages |
Modifiability |
Comply with regulations that have an impact on life-critical systems such as fire alarms |
Performance |
|
Open new sales channels in the form of VARs |
Support hardware devices from different manufacturers |
Modifiability |
Support conversions of nonstandard units used by the different hardware devices |
Modifiability |
Quality attribute requirements must provide sufficient detail to be truly useful. As an illustration, imagine you are the architect for the building automation system and suppose you have a requirement that the building automation system must be modifiable with respect to the hardware devices it must support from different manufacturers. Do you think the requirement is sufficient in its given form?
It may not be sufficient to say that a system must be modifiable. Any system is modifiable with respect to something, and a system can be modified with respect to any aspect given enough time and money. The question relates to its modifiability with respect to what, when, and the amount of effort needed to do so. The given requirement for the building automation system clearly states the what, but not when and how much effort. It may be more useful to state the requirement as follows:
A field engineer is able to integrate a new field device into the system at runtime, and the system continues to operate with no downtime or side effects.
Now, it is clear that a new field device (what) has to be added at runtime (when) by a nonprogrammer (how much effort).
This form of expressing a requirement is called a quality attribute scenario (Bass et al., 2003). Stated this way, the quality attribute requirement is more concrete. Architectural design decisions can be made to satisfy the requirement, and the system can be tested to see if it meets this requirement.
A quality attribute scenario is a requirement with six parts: a stimulus, the source of stimulus, an environment, an artifact, a response, and a response measure. These six parts for the scenario just described are as follows:
Stimulus—integrate a new field device
Source of stimulus—field engineer
Environment—runtime
Artifact—the system
Response—system continues to operate
Response measure—with no downtime or side effects
So, the stimulus is something that incites a system, the source of stimulus is something that generates the stimulus, the environment is the condition under which the stimulus is generated, the artifact is the part of the system that is affected by the system, response is the reaction of the system to the stimulus, and response measure is a way for measuring the system’s reaction.
Engineering objectives have implied quality concerns that are elaborated into architectural requirements expressed as quality attribute scenarios.
Because they are the drivers for the architectural decisions, the first task is to determine the important quality attribute requirements for a given system. You may have observed one important aspect of quality attribute requirements is that they typically conflict with each other. For instance, trying to increase the security within a system through the use of encryption may have a negative impact on its response time. For any given system, therefore, you can only have a handful of such requirements; otherwise, they can create conditions that make conflicts challenging to resolve.
How might you go about discovering this set of most important quality attribute requirements for a system under consideration?
One approach may be to consider a standard taxonomy of quality attributes such as International Organization for Standardization (ISO) 9126. You may examine each quality attribute in this taxonomy and see how it applies to your system. As you go down the list, it will be hard to find any quality attribute that does not apply. After all, who will say that their system does not need to be secure, reliable, usable, testable, scalable, and so on? So, this approach does not seem practical.
Another way you could approach this problem is to examine each function to be supported by the system and ask the stakeholder for that function to describe some quality attributes associated with that function. Again, it would be hard for any stakeholder to resist saying the function desires should be high performing, secure, reliable, usable, and so on. This approach seems even worse than the first one because the quality attribute requirements in this case will be some multiple of the total number of functional requirements. Clearly, this number is much more than a handful.
A pragmatic approach is to elicit quality attribute scenarios from stakeholders that directly relate to the business goals for a system. Because there are only a handful of business goals, the same will apply to the quality attribute scenarios. More significantly, these would be the most important scenarios to consider if one is to create a system that fulfills its intended purpose (Ozkaya et al., 2008).
Quality Attribute Workshop (Barbacci et al., 2003) is an architecture-centric method that can be used for eliciting quality attribute requirements from the stakeholders of a given system. The goal of this method is to establish a prioritized set of quality attribute requirements in the form of quality attribute scenarios that are mapped to the business goals. Clearly, it is important that these goals are known before the workshop can be conducted even if they are initially general and will need subsequent refinement.
Table 2.6 shows a prioritized set of scenarios derived from the business goals for the building automation system.
Quality Attributes and Scenarios Derived from Engineering Objectives
Engineering Objective |
Quality Attribute |
Quality Attribute Scenario |
Priority |
Support hardware devices from many different manufacturers |
Modifiability |
A field engineer is able to integrate a new field device into the system at runtime, and the system continues to operate with no downtime or side effects. |
H |
Support conversions of nonstandard units used by the different devices |
Modifiability |
A system administrator configures the system at runtime to handle the units from a newly plugged in field device, and the system continues to operate with no downtime or side effects. |
H |
Support international languages |
Modifiability |
A developer is able to package a version of the system with new language support in 80 person-hours. |
M |
Comply with regulations |
Performance |
A life-critical alarm should be reported to the concerned users within 3 s of the occurrence of the event that generated the alarm. |
H |
Note: H, high; L, low; M, medium.
The priorities are based on how business critical a quality attribute requirement is. High (H) means the customers would not consider the product if that requirement is not satisfied, medium (M) means the product would not be competitive in the absence of that requirement, and low (L) means it is something nice to have.
Quality attribute requirements often conflict with each other, leading to complex trade-off situations. Hence, it is important to prioritize these requirements and only consider half a dozen or fewer most significant ones.
The ISO/IEC (International Electrotechnical Commission) 42010 standard was introduced briefly in Chapter 1. This chapter explored the shaded portion of this conceptual framework shown in Figure 2.2.
It is important to know who are the key stakeholders with a vested interest in the system under design. The stakeholders have concerns that define the purpose for which the system is being created. These concerns are expressed as business goals or mission objectives and can have a significant impact on the architecture of a system. Therefore, they must be used as a starting point for determining architecturally significant requirements. Because not all business goals may be relevant, they must first be refined into engineering objectives that relate them to the system under design. The engineering objectives are then refined into quality attribute scenarios. Because these scenarios may conflict with each other, they need to be prioritized, and only a handful of the most significant ones should be considered to avoid complex trade-off situations.
M. Barbacci, R. Ellison, T. Lattanze, J. Stafford, C. Weinstock, and W. Wood, Quality Attribute Workshops (QAWs), third edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, third edition. Boston: Addison-Wesley, 2013.
P. Clements and L. Bass, The business goals viewpoint, IEEE Software, November/December, 2010, pp. 38–46.
International Organization for Standarization. ISO/IEC Standard 9126: Software Engineering — Product Quality, part 1. 2001.
ISO/IEC/IEEE Systems and software engineering—Architecture description, ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471-2000), pp. 1–46, 2011.
J. Johnson, Chaos Report. Boston: Standish Group, 2002.
J. Mossinger, Software in automotive systems, IEEE Software March/April 2010, pp. 92–94.
National Aeronautics and Space Administration (NASA), Systems Engineering Handbook (NASA/SP-2007-6105 Rev1). Washington, DC: NASA Headquarters, December 2007.
I. Ozkaya, L. Bass, R. Sangwan, and R. Nord, Making practical use of quality attribute information, IEEE Software, March/April 2008, pp. 25–33.
R. Sangwan and C. Neill, How business goals drive architectural design, IEEE Computer, August 2007, pp. 101–103.
18.118.2.240