Translating Needs into Goals

Systems Architecture · Chapter 11

Aykut C. Satici

From Influences to Goals

Chapters 9–10 surveyed the upstream and downstream influences the architect must navigate — but influences alone don’t tell us what to build
This chapter develops a systematic process: identify stakeholders and their needs, characterize and prioritize those needs, and translate them into goals the architect can actually design against
Running example throughout: a Hybrid Car project, plus a closing case study on the 1998 Nagano Olympics IT system

Figure 11.1 · The Needs-to-Goals Framework

Four major steps: identify stakeholders and beneficiaries, characterize their needs, interpret needs as goals, and prioritize goals with metrics — closing the loop by checking key needs are met. Source: Crawley, Cameron & Selva (2016), Fig. 11.1.

11.2 Identifying Stakeholders and Their Needs

Setting Bounds and Granularity

Two difficulties in stakeholder analysis: setting bounds (how far to trace ripple effects — e.g., the economic multiplier of a contractor’s spending) and setting granularity (individual suppliers, or “Suppliers” as one abstraction?).

Tip

Our test for both: does the choice among architectures under consideration matter to this stakeholder? If every candidate architecture delivers the same benefit, the stakeholder still needs managing — but may not merit shaping the architectural decision.

Two genuine methodological difficulties students will hit in any real project
Bounds: how far to trace ripple effects before stopping — e.g. economic multiplier effect (contractor spends money, employees spend it locally, ripples outward indefinitely). Real economic literature exists, but deep analysis of every ripple is usually impractical
Granularity: right level of abstraction — individual suppliers, or one abstraction “Suppliers”? Matters if individual suppliers have meaningfully different needs/influence
The book’s single test for both (fragment): does the choice among architectures actually under consideration matter to this stakeholder? If every candidate delivers the same benefit, still manage them, but they don’t need fine granularity or extended bounds
→ Worth memorizing — recurs as the practical scope filter for the rest of the chapter

Box 11.1 · Principle of the Beginning

“The beginning of the work is most important.” — Plato, The Republic

“Great warriors position themselves where they will surely win, prevailing over those who have already lost.” — Sun Tzu, The Art of War

The stakeholders included at the early stages of product definition will have an outsized impact on the architecture — be very careful about who’s involved, and how they shape it
Balance engaging stakeholders for their views against their actual decision rights — informed, consulted, voting, or veto

Figure 11.2 · Stakeholders and Beneficiaries

Beneficiaries are those whom the architecture addresses; you are important to them. Stakeholders have a stake in the outcome; they are important to you. Charitable beneficiaries are beneficiaries who aren’t also stakeholders. Source: Crawley, Cameron & Selva (2016), Fig. 11.2.

One of the chapter’s most important distinctions — easy to blur in casual speech, slow down here
“Stakeholder” became extremely broad since Freeman’s 1984 Stakeholder Management — often reduced to a PR activity instead of the upstream process it should be
Beneficiaries: benefit from your actions — you are important to them
Stakeholders: have a stake in your product/enterprise — they are important to you (closer to original “stockholder”: supplies something you need for a stake in the outcome)
Three categories from the diagram (place real examples in each):
- Beneficial stakeholders: intersection — receive from you and provide to you (ideal, mutually-reinforcing)
- Charitable beneficiaries: beneficiaries who aren’t stakeholders — you give value, get nothing back
- Problem stakeholders: stakeholders who aren’t beneficiaries — you need something from them, one-sided, harder to manage
→ Come back to charitable beneficiaries/problem stakeholders concretely with the Hybrid Car in a couple slides

A Starting Checklist of Stakeholders

Driver/owner (primary beneficiary)
Regulator
Producing enterprise or company
Investors in the enterprise

Suppliers
Local community
Environmental NGOs
Competitors (e.g., oil companies)

Tip

This first-pass list gets revisited once we prioritize — treat it as a starting point, not a final answer.

Box 11.2 · Definition of Needs

A need may be defined as: a necessity, an overall desire or want, or a wish for something that is lacking.

Needs exist in the mind (or heart) of the beneficiary — they can be unexpressed, or even unrecognized
Needs are primarily outside the producing enterprise — they are owned by the beneficiary, not chosen by the firm
Needs are a product/system attribute; they are interpreted, in part, by the architect

Pin down “need” precisely — the chapter’s entire logical structure depends on distinguishing needs from goals (Section 11.4). Conflating the two is the #1 student error
Need = a necessity, an overall desire/want, or a wish for something lacking
Three properties, one at a time:
- Exist in the mind/heart of the beneficiary — fuzzy, unexpressed, even unrecognized (sets up “latent needs” ahead)
- Primarily outside the firm’s control — owned by the beneficiary, not invented/chosen by the firm (strong claim: firm can only understand/serve needs, not decide them)
- Still a product/system attribute — must be interpreted, in part, by the architect to define goals
→ This interpretive step is exactly what separates needs from goals: needs live in the beneficiary’s world, goals live in the architect’s design process

Figure 11.3 · Needs of the Beneficiaries for the Hybrid Car

Starting with the primary beneficiary — the driver/owner — and their primary need (transportation), we work outward to the other stakeholders and their needs. Source: Crawley, Cameron & Selva (2016), Fig. 11.3.

Concrete payoff of everything so far. Guidance: start with the primary beneficiary and their primary need, tied to changes in the principal value-related operand (Ch. 7)
Driver/owner = primary beneficiary, primary need = fuel-efficient transportation
Trace the diagram: Driver/Owner → transportation, fuel efficiency, driving experience, baggage, environmental satisfaction, financial incentives, gas (grouped as “transportation product”). Regulators → environmental protection, political support. Suppliers → revenue. Enterprise → revenue, investment. Local community → employment, environmental benefits. The project itself → investment, parts, workforce, technology, sales dollars, regulatory approval (it’s its own stakeholder in the network). NGOs → environmental assurance. Investors → ROI. Oil company → revenue
→ Diagram is deliberately not complete — an application of “focus” (Ch. 2). Not every driver need gets met by the real car (e.g. financial incentives/tax deduction — a policy lever outside the firm’s control, even though legitimate)

Latent Needs

Latent needs are needs that are fundamental to the beneficiary, before the product that meets them comes into being. They are not chosen by the firm — advertising changing customer value functions is a dangerously overused idea in engineering contexts.

How did Whirlpool know customers “needed” an ice dispenser before it existed? How did GM know drivers with cell phones would “need” OnStar?
No set procedure identifies latent needs with certainty — the only real answers are deep scrutiny of users, iteration on concepts, and hard work
Caution: Edison in 1922 — “The radio craze will die out in time.” Ken Olson, DEC founder, in 1977 — “There is no reason anyone would want a computer in their home.”

One of the hardest, most important ideas in stakeholder analysis — real class time
Many transformative architectures serve needs nobody had recognized/expressed yet — latent needs: fundamental to the beneficiary, exist prior to and independent of the product that satisfies them
Examples: Whirlpool’s ice dispenser (before it existed, how did they know customers needed it?), GM’s OnStar (drivers already had cell phones — redundant-seeming, yet needed)
Firm stance: “latent” ≠ chosen by the firm. Pushes back on advertising creating needs — book calls that idea “dangerously overused” in engineering. Believing you can manufacture demand stops the hard work of understanding users
How to actually find them (no reliable formula, by definition): Dichter’s in-depth interviews (1950s), IDEO’s “empathic design” (observing customers in context) — only real tools are deep user scrutiny, concept iteration, feedback, hard work
Cautionary quotes — false confidence about latent needs: Edison (1922) — “the radio craze will die out.” Ken Olson/DEC (1977) — “no reason anyone would want a computer in their home”
→ Both serious technologists, both spectacularly wrong. Ask students for modern-day equivalents

Needs Arise from an Exchange

A central tenet of stakeholder theory: value results from an exchange. Your outputs satisfy their needs; their outputs satisfy yours. This completeness criterion helps surface additional stakeholders. Source: Crawley, Cameron & Selva (2016), Fig. 11.4.

Grouping Stakeholders

Having listed needs, we take a first pass at prioritizing by grouping stakeholders into three buckets:

Stakeholders who must be considered and satisfied. Stakeholders who must be considered and should be satisfied. Stakeholders who should be considered and might be satisfied.

Tip

This first-guess taxonomy — applied before an in-depth analysis — is useful precisely because it lets us later compare expectations against what analysis reveals.

Figure 11.6 · Stakeholder Prioritization for the Hybrid Car

Concentric rings show the first-guess priority: enterprise and regulator innermost, then driver/owner and local community, then suppliers, NGOs, and investors — with other car companies and the project itself outside. Source: Crawley, Cameron & Selva (2016), Fig. 11.6.

Concrete application of the three-bucket taxonomy to the Hybrid Car
Innermost ring (must consider + satisfy): enterprise, regulator. Middle ring (must consider, should satisfy): driver/owner, local community. Outer ring (must consider, might satisfy): suppliers, NGOs, investors. Outside even that: other car companies, the project itself
Discussion prompt: shouldn’t driver/owner (primary beneficiary) be innermost, not middle? Good tension to surface — author’s own judgment call at this early, un-rigorous stage
- One legitimate answer: enterprise survival + regulatory compliance are existential threshold gates; serving the driver well is more of a spectrum
→ Keep this figure in mind — Section 11.3 returns with a far more rigorous, quantitative prioritization via the stakeholder network/value loops; compare that result back against this first guess

Section 11.2 Summary

Stakeholder analysis requires setting bounds and granularity — test both against whether the choice among candidate architectures would matter to that stakeholder
Needs exist in the beneficiary’s mind — they are unexpressed, latent, and never invented by the firm, only interpreted by the architect
Value delivery is fundamentally an exchange — tracing outputs and inputs both ways is what reveals a complete stakeholder list
A first-guess grouping of stakeholders, made before deep analysis, is a useful checkpoint against later, more rigorous prioritization

11.3 Characterizing Needs

Dimensions of Stakeholder Needs

“Find the appropriate balance of competing claims by various groups of stakeholders. All claims deserve consideration but some claims are more important than others.” — Warren G. Bennis

Five dimensions along which needs can be characterized: benefit intensity (utility/worth), detriment (adverse reaction if unmet), urgency (how quickly it must be fulfilled), awareness (how aware stakeholders are of it), and coupling (how it relieves or intensifies other needs).

Open with the Bennis quote — frames the section: not a single “most important” claim, but a balance among competing claims, unequal weight acknowledged
11.2 completed column 1 of Fig. 11.1 — now characterize needs to eventually prioritize them
Five dimensions (useful vocabulary beyond this course):
- Benefit intensity — utility/worth of fulfilling
- Detriment — adverse reaction if unmet (distinct from benefit — can be low-benefit/high-detriment or vice versa)
- Urgency — how quickly it must be fulfilled
- Awareness — how aware stakeholders are of having it (ties to latent needs)
- Coupling — degree to which satisfying one relieves/intensifies another
Formal survey methods exist (direct ranking, conjoint analysis, AHP) — but next slide’s Kano analysis is the model the book develops in depth

Figure 11.7 · Kano Analysis

Three categories: Must have (unmet → strong dissatisfaction; met → no extra credit — “good brakes”), Should have (roughly linear satisfaction — “fuel efficient”), Might have (an excitement/delight attribute — “self-parking”). Categories shift over time as features become expected. Source: Crawley, Cameron & Selva (2016), Fig. 11.7.

Kano methodology — the chapter’s single most useful practical tool, comes back at prioritization
For each need, presence/absence falls into three categories:
- Must have — essential, regret its absence
- Should have — satisfied by presence, regret absence, less dramatically
- Might have — satisfied by presence, but no regret if absent
Diagram axes: performance (x) vs. satisfaction (y)
- Must have (good brakes): flat/low satisfaction across most range, crashes sharply below a threshold — no delight, but serious dissatisfaction if missing
- Should have (fuel efficiency): roughly linear — more MPG, steadily more satisfaction
- Might have (self-parking): “excitement”/delight attribute — absence unnoticed, presence differentiates
→ Dynamic caveat: categories shift over time — self-parking may drift from “might have” to “must have” as market expects it. Today’s delighter becomes tomorrow’s baseline; anticipate the drift

Judgment Still Matters

In many markets, formal methods for prioritizing needs (like Kano analysis) are outmatched by the judgment of seasoned individuals — where large consumer data sets exist, or mature technical buying criteria prevail, analysis is more valuable; otherwise, judgment should not be supplanted
There are many methods for comparing needs within one stakeholder, but few for comparing needs across stakeholders — this tests the limits of human reasoning given the sheer number of needs possible

Stakeholders as a System

Taken as a group, the set of stakeholder exchanges itself forms a system — we can build a stakeholder map
Three steps: (1) who could satisfy each stakeholder’s needs? (2) what are the project’s outputs, and to whom do they flow? (3) combinatorially pair stakeholders and check for relevant transactions between them

Elegant conceptual move, worth pausing on: the whole set of stakeholder exchanges itself forms a system (Ch. 2 sense) — entities + relationships, functionality greater than the sum of parts
→ Justifies building a stakeholder map: systems thinking applied to the stakeholder network itself
Three-step construction procedure (directly builds the next two figures):
1. For each stakeholder’s needs, who could satisfy them? (Hybrid Car → supplier as parts source)
2. What are the project’s own outputs, and to whom do they flow? (e.g. employment → workforce need). Caution: outputs not linked to a real need are “unused outputs” — a valuable finding on its own
3. Most powerful, often-overlooked: combinatorially pair stakeholders, check for any relevant transactions between them, even indirect ones
→ Step 3 reveals indirect transactions ahead — relationships invisible from the project’s own direct inputs/outputs

Figure 11.8 · Hub-and-Spoke Stakeholder Map

The project as hub, with flows to and from each stakeholder — six categories: policy, money, workforce, technology, knowledge, goods and services. Source: Crawley, Cameron & Selva (2016), Fig. 11.8.

Output of applying steps 1-2 (previous slide) to the Hybrid Car. Project at center as hub, stakeholders connected by directional flows:
- Enterprise: provides technology/investment, receives revenue
- Suppliers: provide parts, receive revenue
- Local community: provides workforce, receives employment
- Regulators: provide regulatory approval, receive environmental protection
- Driver/owner: receives the product, provides sales revenue
Legend — six flow types: policy, money, workforce, technology, knowledge, goods and services — a reusable typology beyond this course
Deliberate constraint: links are solution-neutral — potential connections, not commitments or a chosen concept for how
“Value flow” = connection of an output to an input; unidirectional — doesn’t imply a return flow
→ That asymmetry lets us spot stakeholders not in equilibrium exchange — precisely charitable beneficiaries and problem stakeholders (Fig. 11.2), now visual

Figure 11.9 · The Full Stakeholder Network

Pairing stakeholders combinatorially reveals indirect transactions — like the tax credit flowing from local community to driver/owner. NGOs, oil companies, and investors appear here even though they were absent from the hub-and-spoke view, because they don’t transact directly with the project. Source: Crawley, Cameron & Selva (2016), Fig. 11.9.

Direct payoff of Step 3 — combinatorially pairing stakeholders, checking transactions between them, not just with the project
What’s new vs. hub-and-spoke: NGOs, oil companies, investors now appear — absent from Fig. 11.8 because none transact directly with the project. They only appear via transactions between other stakeholders (e.g. investors relate to the enterprise, not the project)
Trace one chain (preview of “value loop” next): local community → tax credit → driver/owner, plus other flows completing a longer loop through environmental benefit, environmental assurance, political support, regulatory approval, cycling back to the project
→ This whole exercise interprets the stakeholders as a genuine system (Ch. 2 sense) — entities + relationships, no defined boundary beyond the completeness criterion (list every potentially relevant stakeholder). Choosing which entities to represent is always a judgment call trading off utility vs. complexity

Value Loops and Indirect Transactions

A value loop is a series of value flows that return to the starting stakeholder — the system behavior of the stakeholder network.

Indirect transactions have one or more intermediaries between the firm and the end stakeholder — common in complex systems, e.g., a firm securing a foreign contract through a local partner who, in turn, provides jobs to a government that grants the contract
We prioritize outputs by tracing backward from important inputs, through the chain, to the stakeholders who ultimately provide them — not just by direct transaction size

Precise term for the previous slide’s pattern: value loop = series of value flows returning to the starting stakeholder — literally the emergent “system behavior” of the network (Ch. 2 sense)
Hub-and-spoke only shows bilateral exchanges; the full network can contain real feedback loops, visible only once indirect transactions are traced
Indirect transactions: one or more intermediaries between firm and end stakeholder. Example — firm gives technology to a local partner, partner gives employment to a government, government grants the contract back to the firm
→ Firm’s output (technology) and resulting input (contract) are no longer directly linked — works only via the intermediary, but still traceable and prioritizable
Practical prioritization: trace backward from most important inputs, through the full network chain, to find who ultimately provides them (not just by direct transaction size)
Simple metric: multiply the importance of needs satisfied at each link along a loop → one strength number per loop, comparable across different loop structures. Next slide shows this for the Hybrid Car

Figure 11.14 · Prioritized Needs for the Hybrid Car

Computing value-loop strength across the stakeholder network yields a ranked, normalized priority for the outputs the project must deliver — transportation dominates, but environmental assurance and enterprise revenue matter too. Source: Crawley, Cameron & Selva (2016), Fig. 11.14.

Quantitative culmination of the last several slides — applying the value-loop method to the six needs directly fulfilled by Hybrid Car outputs
Transportation dominates (~0.4, normalized to sum to 1) — primary beneficiary’s primary need, strongest direct loop. Then environmental assurance and enterprise revenue meaningfully high, then environmental protection, supplier revenue, employment trailing
→ What’s powerful: ranks stakeholders/needs without the firm subjectively pre-judging importance — inputs are just each stakeholder’s individually-judged need priority (Kano, 11.3) plus the network’s objective structure. The enterprise-vs-regulator ranking emerged, wasn’t declared a priori — same as any emergent property in this course
Honest limitation: ignoring indirect transactions, a simpler method (order by direct need satisfaction) would work — but it misses third-party levers (like the NGO) that are individually unimportant bilaterally but matter through the network toward something big (regulatory approval)
→ Architect must judge which systems genuinely need indirect-transaction analysis vs. simpler bilateral reasoning

Box 11.3 · Principle of Balance

“Bring balance to the Force, not leave it in darkness…” — Obi-Wan Kenobi

“No complex system can be optimized to all parties concerned.” — Eberhardt Rechtin

One may never be able to enumerate, let alone quantify, all the factors — one must make tradeoffs among the factors that come close to satisfying the recognized influences
The system must be balanced as a whole, not just the sum of balanced elements
The architect is always balancing optimality against flexibility — the more optimized for a given application, the less flexible to new use cases and technologies

Closes Section 11.3 with an honest, humbling limit: no complex system can be optimized for every party at once — Obi-Wan (pop-culture) and Rechtin (systems-engineering foundational figure) say the same thing
Three bullets, connected argument:
- You may never fully enumerate/quantify every factor — goal isn’t a perfect optimum, it’s sensible tradeoffs among identified factors
- System must balance as a whole — not locally optimizing each element and assuming the sum balances. Same emergence idea from Ch. 2, applied to stakeholder-balancing: local optimization ≠ global balance
- Architect perpetually trades optimality vs. flexibility — tightly optimized for today’s use case = less margin for future ones, and vice versa
→ This tension recurs the rest of the course — no formula resolves it, it’s a deliberate judgment call informed by this section’s stakeholder analysis

Section 11.3 Summary

Needs are characterized along several dimensions — Kano analysis is one useful conceptual model, but judgment often outperforms formal methods
Treating the stakeholder set as a system — with value loops and indirect transactions — reveals stakeholders and priorities invisible from a purely direct, hub-and-spoke view
Balancing competing stakeholder claims, not optimizing to any single one, is the essence of good architecture

11.4 Interpreting Needs as Goals

Box 11.4 · Definition of Goals

Goals are defined as: what is planned to be accomplished, and what the producing enterprise hopes to achieve. Goals are a product/system attribute.

Needs exist in the stakeholder’s mind; goals are defined by the producing enterprise with the intent of meeting those needs
Goals are under the architect’s control — they are not static, and are often traded off against other product attributes in design

Pivotal definitional slide — the “translating” in the chapter title happens here. Make the need/goal distinction airtight
Goal = what is planned to be accomplished, what the enterprise hopes to achieve — a product/system attribute, contrasting with needs (mind/heart of stakeholder, owned by the beneficiary)
Side-by-side comparison: needs exist in the stakeholder’s mind, prior to any product; goals are defined by the enterprise, intended to meet those needs. Needs aren’t chosen by the firm; goals absolutely are — under the architect’s control
Goals aren’t static — frequently traded off against other attributes during design. Ties back to Ch. 1 “Structured Creativity”: “goals” not “requirements,” specifically to preserve tradability
Subtlety: architect is choosing which needs (beneficiary’s and other stakeholders’) to address. Doesn’t mean corporate strategy/regulation are “optional” — corporate strategy is an active market-choice, regulation is mandatory; the point is these are all needs the architect weighs and interprets, not bypassed commands

Five Criteria for Goals

Criterion	Meaning
Representative	Goals reflect stakeholder needs — meeting the goals meets the needs
Complete	Satisfying all goals satisfies all prioritized needs
Humanly Solvable	Goals are comprehensible and aid the problem solver
Consistent	Goals do not conflict with each other
Attainable	Goals can be reached with available resources

For comparison, INCOSE’s eight requirement criteria collapse into essentially the same five, once “necessary/implementation-independent/clear-and-concise” are folded into Representative and Humanly Solvable. Source: Crawley, Cameron & Selva (2016), §11.4.

Evaluative standard for the rest of the chapter/Part 3 — since goals are architect decisions, we need explicit criteria to judge them
Representative — meeting the goals actually meets the underlying needs
Complete — satisfying all goals satisfies all prioritized needs (qualifier matters — measured against 11.3’s prioritization, not every conceivable need)
Humanly Solvable — comprehensible, enhances (not hinders) the solver — hardest in practice, gets its own slide next
Consistent — goals don’t conflict
Attainable — reachable given available resources
INCOSE comparison (for SE-background students): their eight (Necessary, Implementation-independent, Clear-and-Concise, Complete, Consistent, Achievable, Traceable, Verifiable) collapse into these five — Necessary/Traceable/Verifiable → Representative; Implementation-independent/Clear-and-Concise → Humanly Solvable
→ Not a competing framework — a deliberately compressed version, emphasizing tradeoffs between goals

Crafting Humanly Solvable Goals

The problem statement itself is one of the architect’s greatest levers — it predisposes how human designers interpret the goals
Extraneous information distracts, even if not strictly wrong: “Find the voltage drop across a 5-ohm resistor… in a 120-V DC circuit” — the “120-V DC circuit” detail can mislead designers into reasoning about resistance–temperature dependency that was never intended
Information not in the problem statement may be wrongly assumed excluded — crafting a statement is a balancing act: enough solution-neutral information, without extraneous or misleading detail

Tip

Maier & Rechtin: the F-16’s original problem statement, “build a Mach2+ fighter,” focused designers on top speed — when the underlying need was really to exit a dogfight quickly, better served by thrust-to-weight ratio.

Hardest of the five criteria — Humanly Solvable. Core insight: problem-statement wording has an enormous, almost psychological effect on how it’s interpreted and solved — one of the architect’s most powerful levers
Toy example: “voltage drop across a 5-ohm resistor, 12-amp current, in a 120-V DC circuit” — physics is trivial (5×12=60V), everything stated is true, but “120-V DC circuit” is extraneous and predisposes readers to reason about irrelevant things (e.g. resistance-temperature dependency)
Simple problems: extraneous distraction is easy to catch. Complex systems: can’t so easily dismiss extra info as irrelevant — genuinely misleading
Flip side, equally dangerous: information not stated can be wrongly assumed excluded (e.g. omitting temperature data silently read as “no temperature dependency,” even if unintended)
→ Crafting a statement is a balancing act: enough solution-neutral info, no extraneous/misleading detail either way
F-16 example (Maier & Rechtin, fragment): original statement “build a Mach2+ fighter” — real need was to exit a dogfight quickly, better served by thrust-to-weight ratio (acceleration) than top speed. Same need, different wording, very different aircraft

Box 11.5 · Principle of the System Problem Statement

The statement of the problem defines the high-level goal and establishes the boundaries of the system — it divides content from context. Challenge and refine it until you are satisfied it is correct. It is rarely stated properly on first formulation.

The System Problem Statement (SPS) is the single assertion of what the system is intended to accomplish to deliver value — much like a mission statement
A common failure mode: the de facto problem statement reverts to a previous product with a modifier — “cheaper electric toaster,” “more efficient roadster”

Formalizes the F-16 lesson: the System Problem Statement (SPS) — the single assertion of what the system is intended to accomplish to deliver value, like an organization’s mission statement
Core claim: the problem statement defines the high-level goal and establishes the system boundary (Ch. 2’s content/context split) — real architectural consequences for scope
Rarely stated correctly on first formulation — challenge and refine repeatedly, treat the first draft as a starting point for interrogation, not a finished artifact
Common failure mode: de facto problem statement = previous product + modifier (“cheaper electric toaster,” “more efficient roadster”) — smuggles in solution-specific assumptions, forecloses design space
→ Maier & Rechtin: real problem statements are often ill-formed, incomplete, over-constrained, a tangled mix of needs/goals/functions/forms — exactly what the next slide’s To-By-Using framework untangles

The To-By-Using Framework

To…[the statement of (solution-neutral functional) intent] By verb-ing…[the statement (solution-specific) of function] Using…[the statement of form]

Example, from 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.”

Tip

The value delivery to the primary beneficiary must be presented first — targeting the Hybrid Car at police fleets instead of consumers would change the SPS, and with it, priorities like crash safety and idle time.

To-By-Using framework — the practical tool for writing a good SPS (a canonical structure, not the book’s own invention)
To = solution-neutral functional intent (pure purpose, no mechanism). By verb-ing = solution-specific function. Using = form — connects to Ch. 2 form/function and Ch. 7 solution-neutral function
U.S. Constitution example (non-engineering, memorable): “to form a more perfect union…promote the general welfare” (To) / “by laying and collecting taxes, paying debts” (By) / “using the powers of…Congress” (Using) — shows the pattern generalizes beyond product design
Sequencing point (fragment): primary beneficiary’s value delivery must come first — shapes the reader’s interpretation most
→ Hypothetical: targeting police fleets instead of consumers changes the SPS entirely, shifting priorities to crash safety, idle-time tolerance. To-By-Using maps directly onto the OPM concept template (intent → function → form) from Ch. 7 — goals and concepts are deeply intertwined

Figure 11.16 · System Problem Statement for the Hybrid Car

The To-By-Using framework maps directly onto the familiar OPM concept template (Fig. 7.4): intent → function → form. To change the location of people and cargo inexpensively and environmentally; by driving fuel-efficiently with good handling; using a hybrid car. Source: Crawley, Cameron & Selva (2016), Fig. 11.16.

Finished Hybrid Car SPS, traced against the OPM diagram
To: change, inexpensively and environmentally, the location of people and possessions (still abstract — not “driving” or “a car” yet)
By: driving — driver drives themselves, passengers, light cargo, fuel-efficiently, good handling
Using: a hybrid gas/electric car
Full prose: “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”
Note: “provide our customers…” openers indicate the firm’s internal organizational intent, distinct from the externally-delivered value
→ Next slide proceeds systematically through the template to enumerate detailed descriptive goals — keep this SPS visible, nearly every later goal traces back to one of these three components

From SPS to Detailed Goals

Given the SPS, we enumerate descriptive goals for each need the project intends to satisfy:

Shall provide transportation performance
Shall be inexpensive
Shall have environmental satisfaction
Shall accommodate a driver (size)

Shall carry passengers and cargo
Shall have good fuel efficiency
Shall have desirable handling
Shall satisfy regulatory requirements

Tip

Note we deliberately say goals, not “requirements” — architects must be free to make tradeoffs among them, which “shall” language tends to obscure.

Direct systematic expansion of the SPS — a goal per need, no priority yet (comes in 11.5)
First goals shown (transportation performance, inexpensive, environmental satisfaction, driver accommodation, passengers/cargo, fuel efficiency, handling) trace to vehicle attributes vs. the driver/owner’s value function
Full list continues to other stakeholders (from 11.3’s prioritization): modest investment/volume sales (investors/enterprise), stable supplier relationships, stable employment (community), regulatory/environmental requirements (regulators/NGOs)
Some require interpreting a whole indirect value loop into one goal — e.g. environmental assurance to NGO → NGO converts to political support → regulator grants approval, requires stating the goal and recording the intent for the NGO to pass the benefit along
→ Terminology matters: “goals,” not “requirements” — deliberate, load-bearing choice so architects stay free to trade off. “Shall” language implies non-negotiable mandate, obscuring the reality of tradeoffs. These are all flat “shall” statements for now — unprioritized, which 11.5 picks up next

Section 11.4 Summary

Goals are enterprise-defined, prioritizable interpretations of stakeholder needs — evaluated against five criteria: representative, complete, humanly solvable, consistent, attainable
The System Problem Statement, built with the To-By-Using framework, is the architect’s most powerful lever for shaping how a design team interprets the problem
Early architecting should stay solution-neutral (To) as long as possible before adding solution-specific function (By) and form (Using)

11.5 Prioritizing Goals

Critical, Important, Desirable

Critical goals

The 3–7 absolute necessities for product success — “live or die” goals.

Important goals

Major goals that contribute to, but are not absolutely necessary for, success.

Desirable goals

Objectives that would be nice to meet, but are not critical to the project.

Tip

This framework allocates limited project resources: spend on critical goals, trade among important goals, and apply leftover resources to desirable goals.

Goals Need Metrics and Targets

A goal without a metric and target value is incomplete — “should have good fuel efficiency” implies a metric (MPG) but sets no target
The rigidity of a goal matters too: constraining (“must accommodate a driver of dimensions XYZ”) vs. unconstrained (“should have good fuel efficiency”) — the architect must decide which needs constrain the design, accepting the consequence of a narrower target market

Practical refinement: a goal without a metric + target value is incomplete — can’t check if it’s met. “Should have good fuel efficiency” implies MPG but sets no number — how much counts as “good”?
Rigidity — second, orthogonal attribute: constraining (“must accommodate driver dimensions XYZ” — hard boundary) vs. unconstrained (“should have good fuel efficiency” — optimization target, no pass/fail line)
Architect decides goal by goal — real tradeoff: more constraining goals shrink the target market (fewer designs satisfy every constraint); more unconstrained goals risk under-delivering on something firmly needed
→ Many organizations blur this, treating all needs as equally rigid “musts” — exactly what the next slide’s Principle of Ambiguity pushes back on

Box 11.6 · Principle of Ambiguity and Goals

“Always aim higher than you want to climb, for one usually stops below the goal one sets.” — Traditional Chinese Saying

The early phase of system design is characterized by great ambiguity — the architect must resolve it into a small, complete, consistent, humanly solvable set of goals
No one designs or rigorously controls the upstream process — expect uncoordinated, incomplete, and conflicting inputs
Because context and customer needs evolve, there must be a process to continuously reexamine and update the goals

Consistency and Attainability

Consistency is subtle: many goals will genuinely conflict (range vs. battery weight) — the architect must understand whether that tradeoff is shallow, steep, or oddly shaped, sometimes only checkable with an analytical model
Attainability means goals can be reached within technology, schedule, resource, and risk constraints — much easier for derivative products than clean-slate designs. When goals aren’t attainable: reduce scope, or add resources

Figure 11.17 · Checking Whether Goals Meet Criteria

Two nested loops: the validation loop asks “is the goal representative?” by comparing delivered function against upstream influences; the verification loop asks “is it attainable, complete, consistent, solvable?” by comparing delivered goals against the concept, form, and intended function. Source: Crawley, Cameron & Selva (2016), Fig. 11.17.

Compact visual summary tying together all five criteria — where each gets checked as a project proceeds from goal-setting to delivered system
Outer path: upstream influences → goals (metrics + targets) → concept → form → intended function → functional deployment → delivered function
Validation loop: “is the goal representative?” — compares delivered function against the original upstream influences. Checks whether we built something addressing real stakeholder needs, not just a self-consistent spec
Verification loop: the other four criteria (attainable, complete, consistent, solvable) — compares delivered goals against concept/form/intended function, using a model where needed
→ Maps onto classic V&V: verification = “did we build the system right?” (per its own goals); validation = “did we build the right system?” (per real upstream needs). Can pass verification and still fail validation if goals were never truly representative — why Representative sits apart, checked by its own loop

Section 11.5 Summary

Goals should be grouped as critical, important, and desirable — this framework governs how limited resources get allocated
Every goal needs an explicit metric, target value, and a stated rigidity (constraining vs. unconstrained)
Consistency and attainability may require analytical models to check — logical inspection alone is often not enough

Chapter 11 Summary

Complex systems face real challenges managing stakeholders: many of them, often with unclear relative priority, sometimes providing only non-monetary inputs, and often delivering value indirectly
Value delivery is an exchange — your outputs meet their needs, and their outputs meet yours
Stakeholders should be prioritized by the inputs they provide to the project — directly or through indirect value loops
Needs are translated into goals via the System Problem Statement and the To-By-Using framework, then checked against five criteria and prioritized as critical/important/desirable

Tip

Reference: Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 11.

Full-chapter recap — walk back through Fig. 11.1 one more time
Three opening challenges: many stakeholders; unclear relative priority (especially non-monetary inputs like political support vs. revenue); value often delivered indirectly through intermediaries
Process built in order:
- Identify stakeholders/beneficiaries via exchange-based value (definitional anchor + completeness check)
- Characterize needs (Kano as key tool)
- Treat stakeholders as a system — stakeholder map, indirect transactions, value loops, network-based prioritization
- Translate needs into goals (enterprise-defined, not beneficiary-owned) via SPS + To-By-Using, checked against five criteria, prioritized critical/important/desirable
→ Why this matters: Chapter 12 takes this prioritized goal set for the Hybrid Car as the starting point for generating/evaluating concept alternatives — none of that is possible without this groundwork

Case Study: 1998 Nagano Winter Olympics — Stakeholders in IT Architecture

IBM’s Daunting Scope

By Dr. Victor Tang, Director of IT Client Relations for IBM’s 1998 Olympic Winter Games

IBM was contractually obligated to build, operate, and maintain the entire IT system for the Games: computing and delivering competitors’ results, accrediting athletes and staff, recording drug-testing results, and more
25 million lines of software; 10 mainframes, 5,000 PCs, 1,500 printers, 160 servers, 2,000 routers — serving ~150,000 athletes, officials, and volunteers
A genuine system-of-systems: each constituent system has a different stakeholder, with distinct priorities, interests, and biases

Unusual provenance: written directly by Dr. Victor Tang, IBM’s actual Director of IT Client Relations for the 1998 Games — first-hand practitioner account, not a retrospective
Scale and stakes: IBM, one of 11 top sponsors (~$60-80M sponsorship), contractually obligated to build/operate/maintain the entire IT system: results computation/delivery, athlete records, accreditation, drug-testing results, more
Numbers: 25M lines of software, 10 mainframes, 5,000 PCs, 1,500 printers, 160 servers, 2,000 routers, serving ~150,000 athletes/officials/volunteers
→ Genuine system-of-systems (Ch. 2 emergence): each constituent system has its own distinct stakeholder (IOC, media, games admin, sports federations, Nagano Organizing Committee…) with different priorities/interests/biases — not one clean customer, exactly the hard multi-stakeholder situation this chapter built tools for

Figure 11.18 · The Nagano IT System, Clients, and Users

Athlete Qualification, Games Management, Results, and INFO98 form the core — surrounded by dozens of client stakeholders: press, medical, accreditation, transportation, accommodation, volunteers, and more. Source: Crawley, Cameron & Selva (2016), Fig. 11.18.

Concrete visualization of the system-of-systems scale: four core systems (Athlete Qualification, Games Management, Results, INFO98) connected by athlete/results/bio data flows
Surrounding client-facing layer: press, scoreboards, local print, TV graphics/commentator info, medical, accreditation, volunteers, transportation, accommodation, data collection, email/info retrieval
→ Echoes the chapter’s stakeholder-map exercises — same logic, real historical high-stakes system, mostly data flows instead of money/goods
Discussion prompt: how would you identify the primary beneficiary and prioritize among all these stakeholders? No single obviously-dominant beneficiary like the Hybrid Car’s driver/owner — genuinely hard, and the rest of the case study shows IBM navigating exactly this

Rethinking IBM’s Strategy

After a widely visible fiasco at the 1996 Atlanta Summer Games — showcasing products/technology that weren’t ready — the IOC told IBM they “didn’t find any part which worked well.”
IBM shifted from a myopic product-technology-centric strategy to one where products and technology were the means to deliver a service, not the end itself
IBM communicated this explicitly: “IT as a service…helping those running the Games, run the Games.” IBM had moved the system boundary

The genuine crisis heading into Nagano: 1996 Atlanta fiasco — IBM showcased products/tech not actually ready, widely-publicized disruptions. IOC’s verdict: “didn’t find any part which worked well”
→ Chapter’s core theme (needs vs. goals, getting the problem statement right) plays out at enormous real stakes
IBM’s strategic shift: from product-technology-centric to products/technology as the means to deliver a service. Publicly stated: “IT as a service…helping those running the Games, run the Games…enhancing the Olympic experience”
Connect to Ch. 2’s system boundary: IBM literally moved the boundary — not “IT products IBM builds” with organizers as an external customer, but redrew the boundary to include the organizers’ success itself
→ Exactly the difference between solution-specific “By/Using” (specific IBM tech) and solution-neutral “To” (successfully running the Games) — the To-By-Using discussion almost exactly

Co-Development With and Without X-Teams

Task	Without X-Teams	With X-Teams
Requirements	IBM does; others only review	IBM + stakeholders co-develop and review
Write/run test cases	IBM does; others review	IBM + stakeholders co-develop, review
Training	IBM does; others concur	IBM + stakeholders co-develop, concur

X-teams enable domain experts to work across organizational boundaries with their counterparts — stakeholders became competent spokespeople and credible advocates, not just critics. Source: Crawley, Cameron & Selva (2016), Fig. 11.19.

X-teams: the organizational mechanism making “IT as a service” real, not just a slogan — domain experts from different organizations work directly across boundaries with counterparts, instead of isolated work + review-at-the-end
Table contrast: without X-teams, IBM does the work (requirements, test cases, training), other stakeholders only review/concur after the fact — outside critics. With X-teams, jointly co-developed from the start, collaborative not adversarial
→ Payoff: engineers got a far more comprehensive understanding of both technical requirements and reciprocal organizational dependencies. Stakeholders became competent spokespeople/credible advocates for the work, not just external critics — real skin in the process
Concrete illustration of Box 11.1’s decision-rights spectrum (informed/consulted/voting/veto) — X-teams deliberately move stakeholders from informed/consulted toward genuine co-development

Rebuilding Trust Through the ICPG Process

Four “IBM Must Do” goals emerged from the Atlanta debrief: meet all technical/management requirements, ensure no surprises during the Games, provide 24/7 operations, and ensure highly secure/usable systems
IBM used International Competitions Prior to the Games (ICPGs) — practice events, often World Cup competitions — as a forum with sports federations and the IOC to surface and resolve errors before the real Games
Solving the documented ICPG errors and shortcomings became management’s agreed interpretation of satisfying “all requirements” — turning an impossible-to-fully-specify requirement set into something tractable

Four “IBM Must Do” goals from the Atlanta debrief: meet all technical/management requirements, no surprises during the Games, 24/7 operations, highly secure/usable systems — reads exactly like Section 11.5’s critical-goals category
Clever practical move: tackling “meet all technical and management requirements” — the full documented requirement set (Seiko timing, Xerox printing/distribution, accreditation/security, volunteer training, more) was “voluminous,” daunting to fully satisfy
ICPGs (International Competitions Prior to the Games): real practice events (often existing World Cup competitions) testing new/modified Olympic rules and IT systems under live conditions first
Formal plenary convocation on ICPG performance — federations/IOC came with documented errors/shortcomings from practice events. After negotiation: solving all documented errors became the agreed interpretation of “all requirements”
→ Turned an impossibly vague, unverifiable goal into something tractable — anchoring “complete” to a concrete, finite list. A clever real-world instance of making a goal “humanly solvable” under organizational pressure

Architecture as a Utility

“Form follows function.” — Louis Sullivan, inventor of the skyscraper

IBM re-conceptualized the Olympics IT system as a utility: highly secure, plug-and-play, with networked servers as the power plant/distribution grid, applications as generators, and structured data as the utility’s output — serving stakeholders and the public as clients
This concept was initially received with reserve and skepticism — a reminder that even sound architectural reframing has to earn buy-in
The Results System — the most important subsystem — used stepwise decomposition and the classic pattern of reliability through redundancy, duplicating key components so a single failure never took down operations

Open with the Louis Sullivan quote (skyscraper’s inventor) — connect to Ch. 7’s concept/form material: architecture is a mapping from function-space to form-space, and meaningful architecture needs workable concepts embodying an abstract idea into a real, functioning artifact
Book calls this embodiment of an idea — the most creative, challenging part of architecting; brilliant architectures need brilliant embodiments, not just correct requirements
IBM’s concept, worth spelling out in full: re-conceptualized the system as a utility (highly secure, plug-and-play) —
- networked servers = power plant/distribution grid (24/7 availability, satisfies one of the four “Must Do” goals)
- applications = generators
- structured data = the utility’s actual output, serving stakeholders/public as clients
Honest detail: this concept was initially received with reserve and skepticism — sound architectural reframing doesn’t automatically earn buy-in; trust still had to be built (ICPG process + X-teams doing exactly that in parallel)
Results System — most important subsystem (processes actual competition performance data): stepwise decomposition (per competition venue) + reliability through redundancy — key components duplicated throughout (timing interfaces, PCs, LANs, WANs, databases, mainframe/medium servers)
→ No single point of failure could take down the whole system during the live Games

Key Lessons Learned

1. To paraphrase Clemenceau: “IT architecture is too important to be left to technical experts.” IT is a technical expression of business policy — architecture must be positioned within that context to be meaningful to decision makers, stakeholders, and users.

2. The architect is always accountable for the integrity of the system, but not responsible for its implementation — which must be delegated. This is especially true for large-scale social and technical systems.

IBM began Nagano with zero confidence from the IOC. After the Games, the IOC director general said: “Technology at the Winter Games in Nagano has been outstanding.” IBM’s strategy of conceiving IT as a service — and its underlying architecture — was validated.

Two headline lessons IBM itself drew — connect each back to the chapter’s themes, the whole point of closing on this case study
Lesson 1: paraphrase of Clemenceau (war too important to be left to generals) — IT architecture too important to be left entirely to technical experts, since IT is a technical expression of business policy. Must be positioned within that context to be meaningful to decision-makers, stakeholders, users — restates this chapter’s core argument: architecture grounded in real needs/goals, not technical elegance alone
Lesson 2: architect is always accountable for overall system integrity, but not personally responsible for implementation — implementation must be delegated. Especially critical for large-scale social/technical systems — no one person could implement it alone, but someone must hold the integrated whole together and answer for whether it works
Close on the resolution: IBM entered Nagano with zero IOC confidence after Atlanta. Afterward, IOC Director General Francois Carrad (not known for handing out compliments) said: “Technology at the Winter Games in Nagano has been outstanding”
→ Validates not just engineering execution but the strategic reframing — IT as a service, moved system boundary, X-teams co-development, ICPG tractability — everything this case study, and the chapter, built toward

Next: Applying Creativity to Generating a Concept

Chapter 12 turns from goals back to synthesis — the structured creativity techniques architects use to generate concept alternatives once goals are in hand.

Tip

Reference: Crawley, E., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson. Chapter 11.