EXMP key terms

The full span of stages a system passes through, from initial concept and requirements through design, build, operation, and eventual retirement. It frames where each engineering activity fits.

Any person or group with an interest in a system's outcome, including users, operators, sponsors, maintainers, and regulators. Their needs and constraints shape what counts as an acceptable solution.

A statement describing a capability, characteristic, or constraint the system must satisfy. Good ones are unambiguous, testable, and traceable to a source such as a stakeholder need or regulation.

A requirement specifying what the system must do: the behaviors, inputs, outputs, and transformations it performs. It answers what function is needed rather than how well it must perform.

A requirement describing a quality attribute or constraint rather than a behavior, such as performance, reliability, usability, security, or portability. These often determine architecture more than functional needs do.

A formally agreed and frozen set of requirements that serves as the reference for further work. Changes after baselining go through controlled review so scope and commitments stay visible.

The ability to follow a requirement forward to design elements and tests, and backward to its source. It supports impact analysis, coverage checks, and audits of completeness.

A concrete narrative of how users or the system interact in a real setting, including triggers, steps, and expected outcomes. Scenarios expose gaps that abstract requirement lists often miss.

A structured description of interactions between an actor and a system that produces a measurable result of value. It captures normal flow, alternates, and error handling for one goal.

An early assessment of whether a proposed solution is technically achievable, affordable, and worthwhile given constraints. It informs the decision to proceed, revise scope, or stop.

The fundamental organization of a system embodied in its components, their relationships, and the principles guiding its design and evolution. It captures the decisions that are costly to reverse.

Structuring a system into parts with well-defined boundaries so each can be understood, changed, and tested with limited knowledge of the others. It reduces coupling and localizes the effects of change.

Two paired measures of design quality: coupling is how much modules depend on each other, cohesion is how strongly a module's internal parts belong together. Low coupling and high cohesion are generally preferred.

A defined boundary through which components exchange information or control, specifying what is provided and what is expected. Clear interfaces let teams build and replace parts independently.

A document that records the agreed details of an interface between two components or parties, including signals, formats, timing, and responsibilities. It is the reference for both sides during build and test.

A named, reusable solution to a recurring design problem in a given context, described by its structure and tradeoffs. Patterns spread vocabulary but still require judgment about when they fit.

A measurable property of a system such as availability, latency, modifiability, or safety that shapes architecture and acceptance. Each attribute implies scenarios that can be tested.

A structured comparison of alternative solutions against weighted criteria to support a defensible choice. It documents options, assumptions, and rationale so decisions can be revisited.

An entity treated as a unit for configuration management, such as a document, component, or baseline. Each has an identified version, owner, and change history.

The discipline of identifying items, controlling changes to them, recording status, and auditing conformance. It keeps what is built, tested, and deployed consistent and reproducible.

A defined process for proposing, evaluating, approving, and recording changes to baselined items. It prevents unmanaged drift and makes the impact of each change explicit.

The activity of moving a built and validated system into its target environment so users can rely on it. It includes installation, configuration, data migration, and rollback planning.

A versioned collection of changes made available together as a coherent unit. Releases are identified, documented, and supported so users know exactly what they are running.

Restoring a system to a previously known good state after a failed change or deployment. It requires prior backups, versioned artifacts, and tested procedures to be dependable.

Confirming that a work product meets its specified requirements, often phrased as building the system right. It relies on reviews, analysis, inspection, and test against defined criteria.

Confirming that the system fulfills its intended use and stakeholder needs, often phrased as building the right system. It typically involves realistic scenarios and user acceptance activities.

A documented set of preconditions, inputs, steps, and expected results used to exercise a specific requirement or behavior. Good cases are repeatable and tied to pass criteria.

Re-running selected tests after a change to confirm that previously working behavior still works. The test set is chosen to cover areas most likely affected by the modification.

The agreed conditions a deliverable must satisfy to be accepted by the customer or stakeholder. They convert vague expectations into checkable statements used at review and sign-off.

A structured investigation to find the underlying reason a problem occurred rather than only its visible symptom. Techniques include fault trees, five-whys, and causal mapping.

An unplanned event that degrades or interrupts service and requires response. Incidents are logged, prioritized, resolved, and later reviewed to prevent recurrence.

A change made to eliminate the cause of a detected problem so it does not recur. It differs from a workaround, which only restores service temporarily.

A documented commitment between a provider and a customer defining expected service levels, such as availability or response time, plus measurement and remedies. It makes performance expectations enforceable.

The ease with which a system can be corrected, adapted, or improved without introducing defects. It depends on documentation, modularity, test coverage, and clear interfaces.

The combination of the likelihood of an uncertain event and the severity of its consequences for objectives. Risks are identified, assessed, prioritized, and treated throughout the life cycle.

A living record of identified risks with their likelihood, impact, owner, and planned response. It is reviewed regularly so priorities reflect current conditions.

An action taken to reduce the likelihood or impact of a risk before it occurs. It may involve design changes, redundancy, training, or contractual protections.

A chronological record of who did what and when, sufficient to reconstruct and review activity. It supports accountability, investigation, and compliance evidence.

Granting each user or process only the access needed to perform its function, and no more. It limits the damage from error, misuse, or compromised credentials.

The mechanisms that decide who or what may use a resource and in what way. Approaches include role-based, attribute-based, and discretionary models chosen to fit risk.