# Systems analysis Systems analysis is the disciplined decomposition of a problem situation into interacting components — actors, flows, constraints, objectives — in order to decide what a system should do before anyone decides how to build it. It sits between [[Operations_research|operations research]], which optimizes well-posed problems, and [[Systems_engineering|systems engineering]], which realizes chosen solutions: the analyst's contribution is problem *formulation* — drawing the boundary, naming the objectives, exposing the [[Feedback|feedback]] structure, and comparing alternatives under explicit criteria. Practiced everywhere from defense procurement to [[Information_system|information systems]] and public policy, it is [[Systems_thinking|systems thinking]] with a deliverable: a defensible recommendation, plus the [[Mathematical_model|model]] and assumptions that produced it. ## Origins: RAND and the economics of choice The name crystallized at the RAND Corporation after 1948, where analysts evaluating bomber basing and weapons portfolios found that engineering optimization answered the wrong question unless costs, doctrine, and adversary response entered the model — [[Decision_theory|decision theory]] applied to hardware. E. S. Quade's RAND volumes codified the method: alternatives, criteria, models, uncertainty analysis, iteration. The approach jumped to government wholesale when McNamara's Pentagon institutionalized it as PPBS (1961) — and the era's philosophers of the method, [[C._West_Churchman|C. West Churchman]] and [[Russell_L._Ackoff|Russell Ackoff]], immediately supplied the standing warnings: [[Operations_research|OR]] tools solve the problem you posed, and the commonest failure is solving the wrong problem precisely. Ackoff's distinction between puzzles, problems, and *messes* — systems of interacting problems — remains the field's best one-line job description. ## The core loop: mess → model → intervention Whatever the domain, the working cycle is stable. First, structure the mess: identify stakeholders, purposes, and the boundary (what is inside, what is environment). Second, model: begin with the system as a [[Black_box|black box]], then open it stepwise into a [[Grey_box_model|grey-box]] and finally a mechanistic model, using [[System_identification|system identification]] where data must speak. Third, analyze: run the [[Simulation|simulation]], propagate [[Uncertainty|uncertainty]] with [[Monte_Carlo_method|Monte Carlo]] sampling, do sensitivity analysis to find which assumptions actually move the answer. Fourth, compare alternatives against criteria — cost-effectiveness, robustness, risk — and recommend. Fifth, close the [[Feedback|loop]] after implementation, because the measured system never matches the modeled one. The cycle is [[Operationalization|operationalization]] in the strict sense: vague purposes become measurable variables, and disagreement moves from adjectives to numbers, where [[Analytics|analytics]] can adjudicate. ## Hard tools of the trade The notation shelf is deep because representation choices steer analysis. Structural views use the [[Block_diagram|block diagram]], [[Process_flow_diagram|process flow diagram]], and [[Signal-flow_graph|signal-flow graph]]; functional decomposition uses [[Function_model|function models]] such as the [[IDEF|IDEF]] family (IDEF0 descends from SADT, 1970s) and structured analysis's data-flow diagrams (DeMarco, Yourdon, late 1970s); dynamic hypotheses use the [[Causal_loop_diagram|causal loop diagram]] and [[Stock_and_flow|stock-and-flow]] maps of [[System_dynamics|system dynamics]]. Management structure comes from the [[Work_breakdown_structure|work breakdown structure]]; dependability questions get [[Failure_mode_and_effects_analysis|FMEA]] and [[Fault_tree_analysis|fault tree analysis]] from [[Reliability_engineering|reliability engineering]]; congestion and capacity questions get [[Queueing_theory|queueing theory]]; allocation questions get [[Mathematical_optimization|optimization]] — linear programming via [[George_Dantzig|Dantzig's]] simplex, sequential decisions via [[Dynamic_programming|dynamic programming]]. The craft skill is matching tool to question: a [[Metamodeling|metamodel]] mismatch, like modeling a queueing problem as a static flow, fails silently. ## Soft systems: when the problem is the problem By the 1970s it was clear the hard method assumes agreed objectives — routinely false in human systems. [[Peter_Checkland|Peter Checkland's]] Soft Systems Methodology (Lancaster, culminating in *Systems Thinking, Systems Practice*, 1981) responded by modeling *purposeful activity as perceived*: rich pictures instead of premature diagrams, root definitions structured by CATWOE (Customers, Actors, Transformation, Weltanschauung, Owner, Environment), and comparison of conceptual models against the real situation to structure debate rather than end it. [[Brian_Wilson_(systems_scientist)|Brian Wilson]] extended the toolkit toward information requirements; the whole school works in [[Action_research|action-research]] mode, learning by intervening. [[John_Seddon|John Seddon's]] later campaign against target-driven management in services applies the same lesson: numerical targets grafted onto an unanalyzed system produce gaming, not improvement — measure demand and flow first, a warning [[Sensemaking|sensemaking]] research keeps re-validating. ## Handoff: requirements, design, and the V When analysis commits to a solution concept, its outputs become the front end of [[Systems_engineering|systems engineering]] and software development. Findings are recast as specifications through [[Requirements_engineering|requirements engineering]] — functional requirements plus the [[Non-functional_requirement|non-functional]] ones (latency, availability, safety) that dominate architecture; each [[Function_(engineering)|function]] is allocated to components; traceability links every requirement to a [[Design_review|design review]] artifact and test. [[Arthur_David_Hall_III|Arthur Hall's]] methodology (1962) and lifecycle texts by [[Benjamin_S._Blanchard|Blanchard]] and Fabrycky made this a teachable pipeline, managed under [[Configuration_management|configuration management]] and [[Quality_assurance|quality assurance]] across the [[Enterprise_life_cycle|enterprise life cycle]]. In the software world the same role is played by the analyst who turns [[Business_process|business processes]] into [[Information_model|information models]] and system specs — the classic "systems analyst" job title — feeding [[Software_engineering|software engineering]] proper. At the largest scale, [[System_of_systems_engineering|system-of-systems]] problems (air traffic, power grids) blur the handoff entirely: analysis never stops because the system never holds still. ## Failure modes of the method itself Honest practitioners keep a defect list. Sub-optimization: polishing a part while degrading the whole — the original sin [[Systems_theory|systems theory]] exists to prevent. Boundary politics: whoever draws the system boundary predetermines the answer; [[C._West_Churchman|Churchman]] insisted boundary critique is ethics, not technique. Metric corruption: once a measure becomes a target it stops measuring (Goodhart's observation), Seddon's service-industry evidence being one long case study. Model idolatry: mistaking the [[Simulation|simulation]] for the system, forgetting that every model's validity is conditional on a [[Black_box|boundary]] someone chose. The discipline's mature stance is therefore iterative humility: analyze, intervene, measure, and let the system's actual [[Feedback|feedback]] — not the model's — have the last word. **On the spine:** [[Systems_engineering]] · [[Operations_research]] · [[Systems_thinking]] · [[System_dynamics]] · [[Requirements_engineering]]. ## Wikipedia : Wikitube **Strict pair:** [Wikipedia](https://en.wikipedia.org/wiki/Systems_analysis) : [Wikitube](https://en.wikitube.io/wiki/Systems_analysis) ## Previous hub tags Hubs: `Systems`. Portals: [[PORTAL_Systems_science]], [[PORTAL_Cybernetics]], [[PORTAL_Reliability_engineering]], [[PORTAL_Control_theory]], [[PORTAL_Systems_engineering]]. --- *Repopulated 2026-08-12 · redlink fill · 0 deletions.*