11.4 Interpreting Needs as Goals
For any product/system there will be many stakeholders, each potentially with many needs. It is hardly ever possible to meet all the goals of all the stakeholders, but there should be a well-defined subset of all of these needs that will be represented by the goals adopted by the enterprise. In this section we move to the third column of Figure 11.1, Interpret Needs as Goals.
We have structured this analysis to proceed from needs to goals, but we have yet to define goals. We define goals (Box 11.4) as what is planned to be accomplished and what the designer hopes to achieve or obtain. The purpose of this definition is to explicitly recognize that goals are decisions made by the architect, whereas needs are fundamental to the beneficiary.
Needs exist in the mind and heart of the stakeholders, but goals are defined by the producing enterprise with the intent of meeting them. They define how the system that the enterprise builds will meet the needs of the beneficiary. Goals are under the control of the producing enterprise. They are not static and are often traded off against other product/system attributes in design. Therefore, they should be considered independent attributes of the system. Goals are defined, at least in part, by the architect.
We will create goals by choosing which needs of the beneficiary we believe the product or system should address, in addition to which needs of other stakeholders the project should address, such as corporate strategy and regulation. This raises concerns for many. We have suggested that corporate strategy needs are an active choice, rather than an imperative, and similarly for regulation. It is not our intent to suggest that architects should build systems that violate mandatory regulations. Rather, our point is that the firm has a choice of markets in which to compete, in whether or not to deploy products well in advance of regulatory deadlines, and so on.
Various industries speak in terms of goals, specifications, requirements, intent statements, and constraints and use these terms to mean different things. We will simply call them all goals, which incorporate various statements of intent. In the spirit of expressing decisions rather than imperatives, we explicitly avoid the term “requirements.” It is our observation that many engineering organizations do not use the prioritization ‘shall, should’ for goals, and, further, do not view requirements as tradable. System architecture fundamentally represents tradeoffs among competing objectives. Paradigms based on the search for a single design that meets all constraints often fail to reflect the potential value delivery, because value is not well formulated as a constraint. These issues are treated informally in Part 4, but here we present the scalable, human process.
Criteria for Goals
If goals are decisions made by the architect, we should establish the criteria by which those decisions can be evaluated. We advance five criteria for goals:
Representative Goals are representative of stakeholder needs, so that a system that meets the goals will in turn meet those needs.
Complete Satisfying all the goals will satisfy all prioritized stakeholder needs.
Humanly Solvable Goals are comprehensible and enhance the problem solver’s ability to find a solution.
Consistent Goals do not conflict with each other.
Attainable Goals can be accomplished with the available resources.
For comparison, the INCOSE Systems Engineering Handbook defines eight criteria for requirements (Necessary, Implementation-independent, Clear and Concise, Complete, Consistent, Achievable, Traceable, Verifiable). In view of the fact that Necessary, Traceable, and Verifiable are all part of Representative, and that Implementation-independent and Clear and Concise are part of Humanly Solvable, these are essentially the same criteria. Our intent is to express goals, which others might call high-level requirements, in such a way that we can place more emphasis on trading between goals.
Although we did not state it as such, the purpose of the detailed stakeholder needs analysis is to build the relevant knowledge to write representative and complete goals. Representative and complete goals are analogous to validation of requirements, where the fundamental assertion is that satisfying the requirements will satisfy the customer. Included in this notion is the idea of completeness—that all customers have been satisfied. A systems perspective on the stakeholder network allowed us to make all of the stakeholders an endogenous part of the system, and by closing the loops, we have a (partial) check on completeness. The other key completeness check that can be performed is to compare the goals to the list of upstream influences to see whether each has been captured or rationally excluded. The criteria Consistent and Attainable are discussed in Section 11.5.
Humanly Solvable can be the most difficult criterion to capture. One of the greatest levers the architect has available is crafting the problem statement used in the design of the system. How will the human designers and builders interpret the goals? We offer several ideas about human solvability.
First, the goals should be clear and minimalist. The information contained in the problem statement predisposes readers to consider them. Take, for example, “Find the voltage drop across a 5-ohm resistor to which a 12-A current is applied in a 120-V DC circuit.” The information “120-V DC circuit” is extraneous at best, but also potentially distracting or disruptive. In the context of simple problems with known physics, this information can be eliminated with confidence, but in complex systems, additional information cannot be so easily eliminated. In crafting a problem statement, architects should be judicious in their use of information.
Second, information not contained in the problem statement may be ignored or, worse, used to reason about priorities. For example, we could reason that the exclusion of temperature data implies that there is no resistance–temperature dependency.
The principle of solution-neutral function (Box 7.1) influences how the problem statement is crafted. INCOSE calls this implementation-independent. Solution-neutral statements enhance the creativity of the process and leave a larger design space open. We will build a procedure for goals on this principle below.
To paraphrase Herb Simon, problems are more complex than our brains can handle, so we oversimplify and ignore parts of the problem statement, or fill in the unknown with our mental models of the way we think it should be, sometimes with dramatic effects on the results.
Creating a useful problem statement is therefore a balancing act, a matter of providing enough solution-neutral information to capture important needs, without providing extraneous or misleading information.
Maier and Rechtin [8] note that the original problem statement for the F-16 was to build a Mach2+ fighter. This performance goal was set by the Air Force, but it was based on an underlying need to be able to exit a dogfight quickly. The problem statement for the Mach2+ fighter focuses the mind on the maximum speed of the fighter, rather than on its acceleration capability. A revised problem statement might have addressed building a Mach1.4 fighter with a high thrust-to-weight ratio, enabling it to out-accelerate its opponent when necessary.
Humanly Solvable Goals; System Problem Statements
We focus our discussion of creating humanly solvable goals around the idea of a System Problem Statement (SPS). Much like the mission statement for an organization, the system problem statement is the single assertion of what the system is intended to accomplish to deliver value, which is representative of real success (Box 11.5 Principle of the System Problem Statement). A current challenge with requirements engineering is that the long documents produced are not quickly comprehensible; they fail to articulate the forest through the trees. In this frame, the de facto problem statement often reverts to a previous product with a modifier, such as “cheaper electric toaster” or “more efficient roadster.” Maier and Rechtin note that problem statements are often ill-formed, incomplete, or over-constrained. Further, they are often a mixture of needs, goals, functions, and forms.
We will begin with a typical problem statement for the Hybrid Car and work to modify it until we have crafted a humanly solvable goal statement.
Iteration 1: System Problem Statement
Manufacture and sell a successful hybrid gas/electric car to environmentally conscientious consumers.
What is wrong with this statement? It tells us something—“manufacture” implies that we will not outsource production, and “consumers” indicates that the primary customer is not government. However, it is also ambiguous. How is “successful” an attribute of the car? Who would want to architect an “unsuccessful” product? What type of car is implied (sedan, city car, coupe?) and, more important, which subset of consumers?
Phrased more specifically, what is the solution-neutral operand implied in Iteration 1 of the SPS? What is the solution-specific process? Clearly it shouldn’t be “selling” or “manufacturing,” because neither is related to the primary beneficiary.
The canonical framework for problem statements is shown below. We call it “To-By-Using” but it is by no means our invention.
To . . . [the statement of (solution-neutral functional) intent]
By verb-ing [the statement (solution-specific) of function]
Using [the statement of form]
An example appears in the U.S. Constitution:
… to form a more perfect union, . . . promote the general welfare, . . . .
(By) . . . laying and collecting taxes, paying debts, . . .
(Using) . . . the powers of . . . The Congress
The most important purpose of the To-By-Using framework is to focus the problem statement on the intent on value delivery to the primary beneficiary. For example, we focused our Hybrid Car on the driver/owner as the primary beneficiary. If we had targeted our Hybrid Car at police vehicle fleet buyers rather than consumers at large, the SPS would have changed, and this change would have had a substantial impact on the architecture of the system, in terms of prioritization of crash safety, modularity for equipment additions, vehicle idle time, and the like. The value delivery to the primary beneficiary needs to be presented first.
Note that the full problem statement contains solution-neutral function (To . . .) and the solution-specific function (By . . .) and form (Using . . .). Yet we cautioned before that crafting the statement of specific function and form too early can prejudice the eventual design and limit creativity. In the discussion that follows, we will present the complete SPS, from which a detailed design could be executed, but the architect needs to recognize that the SPS is developed during the architecting phase. Early stage meetings should make use of only the solution-neutral functional intent. Later, the solution-specific function and form will be added.
Figure 11.15 shows a detailed view of the To-By-Using framework and its relation to the now-familiar Object Process Methodology (OPM) representation of the functional intent and concept of a system (Figure 7.4)—this should not come as a surprise!
Figure 11.15 To-By-Using framework for formulating a good System Problem Statement.
For the hybrid gas/electric car, we identify the driver/owner as the primary beneficiary and “changing the location of people and their possessions” as the solution-neutral transformation, which could also be called transporting people and their possessions. Below, we have translated this into the second iteration of the problem statement. This statement of the problem indicates which attributes in the goal are related to intent, function, and form.
Iteration 2: System Problem Statement
Provide our customers a product:
To transport them and their possessions inexpensively and in an environmentally sound manner
By allowing them to drive themselves, their passengers, and light cargo fuel-efficiently and with good handling characteristics
Using a hybrid gas/electric car
Enterprise goals such as “provide our customers . . .” often appear at the beginning of a goal statement. They are indicative of internal organizational intent, not external value delivery.
Figure 11.16 represents the system problem statement in the full template. Given this SPS, we can now proceed from item to item in the template and begin to enumerate a more detailed set of descriptive goals. For now, we will enumerate goals for each of the needs that the Hybrid Car project intends to satisfy, regardless of their relative priority.
Figure 11.16 System Problem Statement for the Hybrid Car using the To-By-Using framework.
Descriptive goals:
Shall provide transportation performance (range, speed, acceleration, etc.)
Shall be inexpensive
Shall have an environmental satisfaction to the driver
Shall accommodate a driver (size)
Shall carry passenger (size and number)
Shall carry cargo (mass, dimension, and volume)
Shall have good fuel efficiency
Shall have desirable handling characteristics
Shall require modest investment from corporate, shall sell in volume, and shall provide good contributions and return, with the intent of securing investment and technology
Shall engage suppliers in long-term, stable relationships with good revenue streams to them, with the intent of an uninterrupted supply of quality parts
Shall provide stable and rewarding employment, with the intent of securing a dedicated workforce
Shall satisfy regulatory requirements, particularly regarding environmental protection, and environmental assurance to the NGO
Notice that the first eight goals reflect attributes of the vehicle produced to satisfy the transportation need and should be evaluated against the beneficiary’s value function. The remainder of the goals reflect desired value delivery to other stakeholders, as illustrated in the stakeholder system (Figure 11.14). This implies that we will have to interpret desired flows in the network as goals, sometimes concatenating flows together into a desired indirect value exchange. For example, take the value delivery loop whereby the project provides environmental assurance to the NGO, which in turn provides political support to the regulator in support of regulatory approval for the project. To capture this as a goal, we need to write a goal on the delivery of the environmental assurance, but it is also necessary to record the intent that the NGO pass this on to the regulatory agency. Note that at this stage, all goals are stated as “shall.” They have not yet been prioritized.
In summary, we use the term goals rather than requirements to emphasize that the architect must frequently make tradeoffs among goals. We developed the To-By-Using framework for creating a System Problem Statement, the purpose of which is to succinctly communicate the goal of the product. We advanced five criteria for goals and developed a list of detailed goals that follow from the SPS.