IAI SP1 key terms

An interdisciplinary approach that defines customer needs and required functionality, then designs and validates a solution while considering the whole life cycle, cost, schedule, and interacting parts rather than isolated components.

The specific system being engineered or analysed, whose boundary, purpose, and interfaces are deliberately chosen. Everything outside that boundary is treated as its environment, even if it interacts strongly with it.

The conceptual line separating the system of interest from its environment. It determines what is inside the design scope and what is treated as an external influence, input, output, or interface.

A set of independently owned, operationally independent systems that together deliver capability greater than any alone. Managerial and operational independence make integration, governance, and evolution significantly harder than within a single system.

Behaviour or properties that appear at the level of the whole system and cannot be predicted simply from the parts in isolation. Emergent behaviour may be desirable, such as synergy, or harmful, such as unexpected oscillation.

Examining a system as an integrated whole, including interactions, feedback, and context, rather than decomposing it into parts and studying each independently. It exposes effects that component-level reasoning misses.

The analytical strategy of understanding a whole by breaking it into constituent parts and studying them separately. It is powerful for tractable problems but can miss interaction effects and emergent behaviour in complex systems.

A circular causal path where an output influences a later input to the same part of the system. Reinforcing loops amplify change; balancing loops resist it. Loops explain growth, stability, and oscillation.

A qualitative systems-thinking diagram of variables connected by arrows labelled positive or negative to show reinforcing and balancing feedback. It communicates dynamic hypotheses rather than precise quantities or simulation results.

A quantitative simulation of stocks, flows, and feedback loops used to explore how a system's behaviour unfolds over time under different assumptions, delays, and policies. It supports experimentation where real-world trials are impractical.

Any person, group, or organisation that affects, is affected by, or has an interest in the system across its life cycle. Stakeholders include users, operators, maintainers, sponsors, regulators, and affected third parties.

A maintained record of identified stakeholders, their interests, influence, concerns, and engagement approach. It is a living artefact updated as the project context and stakeholder landscape change.

Systematically assessing stakeholders by influence, interest, impact, and attitude in order to prioritise engagement and manage conflicting expectations. Its output shapes communication plans and requirements negotiation.

An elicitation technique in which an analyst observes people doing real work in their own environment and asks questions in context. It reveals tacit knowledge and workarounds that interviews away from the workplace often miss.

Expertise and know-how that people hold but struggle to articulate explicitly, such as habits, judgement calls, and workarounds. Observation-based techniques are usually needed to surface it as usable requirements.

The activity of drawing out needs, constraints, and information from stakeholders and other sources. It is not simply collecting pre-existing requirements; it involves discovery, probing, and recognising gaps and inconsistencies.

A structured facilitated meeting that brings diverse stakeholders together to identify, clarify, and agree requirements. Good facilitation, clear scope, and documented outcomes make it an efficient way to resolve conflicting views.

A statement of a need or obligation that the system must satisfy, expressed with enough precision to be verified. Requirements may concern function, performance, quality, constraints, or interfaces.

A statement of need expressed from the perspective of a stakeholder, often in their language and about desired outcomes. It is the starting point that is analysed and transformed into more precise system requirements.

A technical statement describing what the system must do or how well it must do it, derived from stakeholder needs and solution constraints. It is written to be unambiguous, testable, and traceable.

The process of resolving conflicting stakeholder demands by trade-off, prioritisation, or compromise so that an agreed, feasible requirement set emerges. It is essential because stakeholders rarely agree and resources are limited.

The ability to follow the relationships between requirements, their sources, design elements, and verification evidence in both directions. It supports impact analysis, coverage checks, and demonstration of compliance.

An approved, formally agreed set of requirements that serves as the reference for further development. Changes to it are controlled through configuration management and change control rather than informal amendment.

The fundamental organisation of a system embodied in its components, their relationships to each other and the environment, and the principles guiding its design and evolution. It captures decisions that are costly to change later.

A representation of a system's architecture from one particular perspective, such as functional, physical, or operational, addressing specific stakeholder concerns. Multiple views are needed because no single view shows everything.

A specification of the conventions, concerns, and notation used to construct one kind of architectural view. It defines what to show and for whom, so views stay consistent and comparable across a project.

Early design work that establishes the overall solution approach, major functions, and candidate architectures before detailed design. It explores alternatives at a level where change is still affordable.

A shared boundary across which two or more system elements exchange matter, energy, or information. Interfaces must be defined precisely because most integration failures occur where separately developed elements meet.

The disciplined identification, definition, documentation, and control of interfaces between system elements, teams, or organisations. It prevents mismatched assumptions and assigns clear ownership of each interface specification.

An abstraction of a system or problem created for a defined purpose, omitting detail irrelevant to that purpose. Models support communication, analysis, and prediction but are only as trustworthy as their assumptions.

Comparing design alternatives against multiple, often conflicting criteria such as cost, performance, risk, and schedule, to justify a selection. The method, criteria, and weighting should be explicit and documented.

A distinct candidate solution that satisfies the same need in a different way. Generating and evaluating several alternatives before committing reduces the risk of locking into a poor early choice.

The progressive combination of system elements into larger assemblies and ultimately a complete system, together with checking that they work together as intended. It follows a planned sequence from lower to higher levels.

Confirming that a system or element meets its specified requirements, answering whether it was built right. It relies on methods such as inspection, analysis, demonstration, and test against defined criteria.

Confirming that the system fulfils its intended purpose in its operational context, answering whether the right system was built. It focuses on stakeholder needs rather than conformance to written specifications.

The sequence of stages a system passes through from concept to disposal, including development, production, operation, support, and retirement. Decisions at early stages constrain cost and options throughout later stages.

The total cost of owning and operating a system over its whole life, including acquisition, operation, maintenance, support, and disposal. It often dwarfs purchase price and should inform early design choices.

The disciplined control of system artefacts and their versions, including identification, change control, status accounting, and audit. It ensures everyone works from a known, consistent, and recoverable definition of the system.

An entity, such as a document, component, or software unit, designated for configuration management and treated as a single controlled unit. Its changes are recorded, approved, and traceable.

The formal process for proposing, evaluating, approving, and implementing changes to baselined artefacts. It protects against uncontrolled scope creep and ensures impacts on cost, schedule, and risk are assessed.

The expected conduct of a systems engineer, including competence, honesty about uncertainty, respect for stakeholders, and adherence to relevant codes and standards. It underpins trust in technical judgements and recommendations.

The framework of decision rights, accountability, policies, and oversight that directs how a system project is controlled. Clear governance defines who approves baselines, accepts risk, and authorises changes.