IAI SP1 cheat sheet

A system is a set of interacting elements organised to achieve a purpose in its environment; the boundary between system and environment is chosen by the analyst, not given by nature.

The SP1 framework separates systems engineering into concurrent streams: requirements, architecture/design, verification/validation, and lifecycle governance, each iterated rather than executed once.

Emergence: system-level behaviour arises from element interaction and cannot be inferred from element properties alone; emergent properties are the primary object of verification.

Holism rule: analyse the whole before decomposing; decomposition follows from required system behaviour, not from an existing organisational or product structure.

System of interest (SoI) must be named explicitly, together with its wider system, enabling systems, and operating environment, before any requirement is written.

The systems engineer's deliverable is a coherent set of models and decisions, not documents; documents are views generated from the underlying model set.

Complexity is managed by abstraction (choosing what to hide) and by separation of concerns (functional, physical, temporal, and lifecycle views kept distinct).

A practice framework is judged by traceability: every artefact must link upward to a stakeholder need and downward to a verification method.

Feedback loop types: reinforcing loops amplify deviation; balancing loops oppose deviation and seek a goal; a system with only reinforcing loops is unstable by construction.

Stock-and-flow distinction: stocks accumulate (inventory, debt, trust), flows are rates that change stocks; only flows can be directly manipulated by a design decision.

Leverage points rank from weak (parameters, numbers) to strong (rules, information flows, goals, paradigm); parameter changes rarely fix structural problems.

Delays between action and effect cause overshoot and oscillation; when a delay exceeds the loop's correction period, add damping or slow the gain.

Emergent-failure heuristic: if a failure requires two or more independent conditions to coincide, look for a shared cause in the system structure rather than in one component.

Causal loop diagrams must label each link with polarity (+, −) and each loop with R or B; an unlabelled loop cannot be validated against evidence.

Unintended consequences arise when an intervention optimises a subsystem objective at the expense of the system objective; check every optimisation against the whole-system goal.

Boundary critique questions: who benefits, who bears cost, who is excluded, and what is treated as environment; answers belong in the context record.

Stakeholder register fields: name/role, interest, influence, impact of the system on them, current knowledge level, engagement method, and owner of the relationship.

Power/interest grid: high power–high interest = manage closely; high power–low interest = keep satisfied; low power–high interest = keep informed; low–low = monitor.

Onion model of context: the SoI sits inside containing systems, which sit inside the wider environment; each layer supplies constraints and interfaces that must be captured.

Contextual inquiry follows four principles: context (observe work where it happens), partnership (user as co-analyst), interpretation (share and check your reading), and focus.

Observation beats interview for tacit work: ask the user to demonstrate a real task, then probe interruptions, workarounds, and exceptions, which carry most requirement content.

Operational context to record: physical environment, operating hours, load profile, degraded modes, operator skill, and regulatory regime.

Conflicting stakeholder needs are resolved by negotiation against explicit criteria, not by averaging; record the rejected option and rationale.

Representative sampling matters: extremes (novice, expert, peak load, failure shift) reveal requirements that average users never mention.

Requirement quality criteria (ISO/IEC/IEEE 29148 style): necessary, unambiguous, complete, singular, feasible, verifiable, traceable, and free of implementation bias.

Well-formed requirement template: [condition] the [system] shall [response] [with performance/constraint]; the word 'shall' marks a binding requirement, 'should' a goal, 'may' a permission.

Requirement types: stakeholder (need, in user language), system (what the system must do), and component (allocated to an element); each must trace to the level above.

Verifiability test: if you cannot name the method (inspection, analysis, demonstration, test) and the acceptance criterion, the statement is not yet a requirement.

Avoid weak words - 'fast', 'user-friendly', 'robust', 'etc.', 'as appropriate' - unless quantified by a stated measure and tolerance.

Functional analysis decomposes behaviour into functions with inputs, outputs, and triggers; non-functional requirements (performance, safety, security, availability) constrain that behaviour.

Interface requirements are bidirectional: state what the system provides and what it requires from each external entity, including timing and data format.

TBD is a tracked defect, not a requirement state: assign an owner, a resolution date, and the risk carried while it stays open.

Architecture is the set of structures comprising elements, their relationships, and the principles guiding their design; a single system has several structures (functional, physical, deployment, information).

Logical architecture allocates functions to logical elements independent of technology; physical architecture binds those elements to implementation choices and interfaces.

Separation of concerns drives modularity: cohesion inside a module should be high, coupling between modules low and explicit.

Interface definition belongs to the architecture, not to the implementing team; an undefined interface is a schedule and integration risk.

Design patterns to recognise: layered, client–server, publish–subscribe, pipeline, blackboard, and broker; each trades coupling against latency and complexity.

Conceptual design generates multiple candidate architectures before selection; a single-option design cannot be traded off and is therefore not a design decision.

Allocation matrix (function × element) exposes orphan functions (no owner) and orphan elements (no function) - both are defects.

Architecture decisions are recorded as ADRs: context, decision, alternatives considered, rationale, and consequences, kept under version control.

Model purposes: communication, analysis, specification, and verification; the purpose determines the required fidelity and notation.

SysML view mapping: requirements (requirement diagrams), behaviour (activity, sequence, state machine, use case), structure (block definition, internal block), and parametrics (constraint blocks).

A model is fit for purpose when its assumptions, scope, and level of abstraction are stated; an unstated assumption is an unverified requirement.

Trade-off method: define weighted criteria, normalise scores to a common scale, compute weighted sum, then run sensitivity analysis on the weights before deciding.

Dominance rule: if option A is at least as good as B on every criterion and strictly better on one, B is eliminated without weighting.

Pareto front: the set of options not dominated by any other; selecting from the front is a value judgement, not an analytical result.

Monte Carlo analysis propagates input distributions to an output distribution; report percentiles (P50, P90), never a single deterministic mean.

Model validation asks whether the model represents the real problem; verification asks whether the model is correctly built - both are required.

Verification answers 'did we build the system right' against the specification; validation answers 'did we build the right system' against stakeholder need.

Four verification methods: inspection, analysis (including modelling), demonstration, and test; each requirement names one method and its acceptance criterion.

Integration strategies: big-bang, bottom-up, top-down, and incremental; incremental with defined build order localises interface faults earliest.

Verification cross-reference matrix links each requirement to method, level, procedure, result, and status; gaps in the matrix are unverified requirements.

Validation in the operational environment is distinct from acceptance testing in a factory or lab; environmental fidelity is itself a validity assumption.

Regression testing scope is set by impact analysis over the traceability graph, not by the size of the change.

Independent verification and validation uses personnel organisationally separate from the developers to reduce confirmation bias.

A verification result is pass/fail against a pre-agreed tolerance; a result recorded without tolerance cannot be judged and must be re-run.

Lifecycle stages typically include concept, development, production, utilisation/support, and retirement; each stage has entry/exit criteria and decision gates.

Lifecycle model choice (waterfall, incremental, iterative, spiral) is driven by requirement stability, risk profile, and delivery constraints, not by preference.

Configuration management covers identification, control of change, status accounting, and audit of configuration items; without all four, baselines are unreliable.

Baseline types: functional (requirements), allocated (architecture), product (as-built); change to a lower baseline requires impact analysis upward.

Change control board decision inputs: technical impact, cost, schedule, risk, and traceability to affected requirements and tests.

Throughput and supportability are designed, not added later: maintainability, spares, training, and obsolescence planning belong in the concept stage.

Obsolescence management monitors component lifecycle against the system's planned service life and defines last-time-buy and redesign triggers.

Retirement planning covers data migration, decommissioning, disposal constraints, and residual support obligations to users.

Governance sets decision rights: who approves requirements baselines, architecture, and gate passage; unclear rights are a schedule risk, not an administrative detail.

Technical reviews have defined entry/exit criteria and named independent reviewers; a review without recorded actions and closure has not occurred.

Risk register fields: description, cause, effect, likelihood, consequence, exposure (likelihood × consequence), owner, mitigation, and residual exposure.

Ethical duties of the systems engineer: public safety and welfare first, competence limits declared, conflicts of interest disclosed, confidential data protected.

Professional body codes (e.g. engineering council-style codes) require reporting of risks to public safety even when doing so is commercially inconvenient.

Assurance evidence must be proportionate to consequence: higher-consequence systems require independent assessment and documented safety arguments.

Audit trail requirement: every decision links to evidence, owner, date, and version; undocumented decisions cannot be defended after the fact.

Competence boundary rule: sign off only work within your competence; state assumptions and residual uncertainty explicitly to the decision-maker.