IAI SP1 flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

System boundary

The analyst's chosen line separating the system of interest from its environment. It determines what is modelled as internal behaviour and what is treated as an external interface or constraint.

Emergent property

A behaviour or characteristic that appears at system level through element interaction and is not present in any element alone. Safety and throughput are typical examples requiring system-level verification.

Separation of concerns

A decomposition principle that keeps distinct issues, such as function, physical form, timing, and lifecycle, in separate views so each can be analysed without interference from the others.

System of interest

The specific system being engineered, explicitly named and bounded. Its wider system, enabling systems, and operating environment must also be identified before requirements are written.

Reinforcing feedback loop

A causal loop in which a change propagates around and amplifies itself. Systems dominated by reinforcing loops grow or collapse exponentially and are unstable without a balancing influence.

Balancing feedback loop

A causal loop that opposes deviation and drives the state toward a goal or reference value. It produces goal-seeking behaviour and, with delays, can oscillate or overshoot.

Stock versus flow

A stock accumulates and can only change over time; a flow is the rate that changes it. Design interventions act directly on flows, and only indirectly on stocks.

Leverage point

A place in a system where intervention produces disproportionate change. Parameters are weak leverage; information flows, rules, goals, and paradigms are strong leverage.

Boundary critique

A structured questioning of who is included, excluded, benefited, or burdened by a chosen system boundary. Its answers are recorded as context assumptions.

Power/interest grid

A stakeholder classification plotting influence against interest. High power and high interest are managed closely; high power and low interest are kept satisfied; low power and high interest are kept informed.

Contextual inquiry

An observational elicitation method conducted where work happens, with the user as partner. The analyst observes real tasks, then checks interpretations and probes exceptions and workarounds.

Onion model of context

A layered view placing the system of interest inside containing systems, which sit inside the wider environment. Each layer contributes interfaces, constraints, and assumptions to be captured.

Stakeholder register

A maintained record of each stakeholder's role, interest, influence, impact from the system, knowledge level, engagement approach, and named relationship owner.

Well-formed requirement

A singular, unambiguous, feasible, verifiable statement of condition, response, and performance. It avoids implementation bias and uses 'shall' to mark binding obligation.

Verifiability criterion

A requirement is verifiable only when a named method (inspection, analysis, demonstration, or test) and a quantified acceptance tolerance can be stated for it.

Requirement traceability

The bidirectional link from stakeholder need to system requirement to component requirement to verification evidence. Gaps reveal unallocated needs and unverified requirements.

Interface requirement

A specification of what a system provides to, and requires from, each external entity, including data content, format, timing, and error behaviour in both directions.

Logical versus physical architecture

Logical architecture allocates functions to technology-independent elements; physical architecture binds those elements to concrete implementation choices, technologies, and defined interfaces.

Cohesion and coupling

Cohesion measures how strongly related the responsibilities inside a module are; coupling measures dependency between modules. Good modularity seeks high cohesion and low, explicit coupling.

Architecture decision record

A versioned note capturing a significant design decision with its context, alternatives considered, rationale, and consequences, so later reviewers can understand why the choice was made.

Allocation matrix

A function-by-element table showing which architectural element performs each function. Empty rows are orphan functions; empty columns are elements with no justified purpose.

SysML diagram families

SysML groups views into requirements, behaviour (activity, sequence, state machine, use case), structure (block definition, internal block), and parametrics. The question asked determines which view is used.

Weighted trade-off matrix

A comparison of options against weighted, normalised criteria producing a total score. Sensitivity analysis on the weights is required before the ranking is trusted.

Pareto front

The set of options not dominated by any other option across all criteria. Choosing within the front is a value judgement, not an analytical outcome.

Monte Carlo analysis

A method that samples input distributions repeatedly to produce an output distribution. Results are reported as percentiles such as P50 and P90 rather than a single value.

Verification versus validation

Verification confirms the system meets its specification, answering whether it was built right. Validation confirms it meets stakeholder need in the operational context, answering whether the right system was built.

Verification methods

The four recognised methods are inspection, analysis including modelling, demonstration, and test. Each requirement names one method and an associated acceptance criterion.

Verification cross-reference matrix

A table linking each requirement to its verification method, level, procedure, result, and status. Missing entries identify requirements that remain unverified.

Incremental integration

An integration strategy that adds components in a defined build order, testing interfaces at each step. It localises interface faults earlier than big-bang integration.

Configuration baseline

An approved, frozen set of configuration items at a point in time. Functional, allocated, and product baselines correspond to requirements, architecture, and as-built states.

Change control board

The body that approves or rejects baseline changes using technical impact, cost, schedule, risk, and affected requirements and tests as decision inputs.

Risk exposure

The product of likelihood and consequence used to rank risks. Residual exposure is what remains after mitigation and must be accepted by a named authority.

Decision rights

The governance assignment of who may approve requirements baselines, architecture, and stage gates. Unclear rights create schedule risk and uncontrolled change.