EGATSU-SP key terms

An interdisciplinary approach that defines stakeholder needs, then designs, verifies, and sustains a system across its whole life cycle, balancing technical, cost, schedule, and risk considerations.

The staged progression of a system from concept through development, production, operation, and retirement, used to plan activities, reviews, and decision gates at each stage.

A statement of what a user, customer, or other affected party needs the system to achieve, usually expressed in their terms and independent of any particular design solution.

A verifiable statement of what the system must do or how well it must do it, derived from stakeholder needs and allocated to system elements during design.

A document describing how the system will be used in its operational environment, including users, scenarios, interfaces, and constraints, before detailed design begins.

The recorded linkage between a requirement and its source, its derived child requirements, and the tests or evidence that prove it is satisfied, enabling impact analysis and coverage checks.

A specification of the data, signal, physical, or protocol exchange between two system elements or between the system and an external entity, including format, timing, and error behavior.

Attributes such as unambiguous, complete, consistent, feasible, necessary, and verifiable that a well-written requirement should satisfy, used to review requirement statements before baselining.

An approved, frozen set of requirements placed under configuration control, so that any later change must be formally proposed, assessed, and authorized.

A representation of a system's elements, their responsibilities, relationships, and governing principles, often organized into multiple views serving different stakeholder concerns.

A specification of the conventions for constructing one kind of architectural view, defining the concerns it addresses, its notation, and the model elements it exposes.

The assignment of required functions and their performance budgets to specific system elements, establishing which component is responsible for delivering each behavior.

A structured comparison of design alternatives against weighted criteria such as performance, cost, risk, and maintainability, documented so the selection rationale is auditable.

The degree to which a system is composed of discrete, loosely coupled elements with well-defined interfaces, so changes in one element have limited effect on others.

An entity designated for configuration management, such as a document, hardware unit, or software module, treated as a single unit for identification, control, and status accounting.

The disciplined process of identifying configuration items, controlling changes to them, recording their status, and auditing that delivered items match their approved documentation.

A formally approved and frozen version of a configuration item or set of items, used as the reference for future changes and for verification of delivered products.

A group authorized to review proposed changes to baselined items, assess their impact on cost, schedule, risk, and interfaces, and approve, defer, or reject them.

A controlled document that precisely defines the agreed physical, electrical, or data interface between two parties or items, including formats, timing, and responsibility boundaries.

Verification confirms the system was built correctly against its specified requirements; validation confirms the correct system was built to meet stakeholder needs in the intended environment.

The extent to which requirements, code paths, interfaces, or risk scenarios are exercised by the test suite, used to judge whether testing is sufficient.

Re-execution of selected existing tests after a change to confirm that previously working behavior remains intact and that no new defects were introduced.

Predefined, testable conditions that a deliverable must satisfy to be accepted by the customer or authorized receiver, often written per user story or requirement.

A systematic investigation that traces an observed failure back to its underlying cause rather than its symptom, so corrective action prevents recurrence.

A documented process for eliminating the cause of a detected nonconformity and for preventing potential nonconformities, including implementation and effectiveness verification.

A described sequence of events and interactions between users, the system, and its environment during a specific mission or task, used for design, training, and test design.

The average operating time between consecutive failures of a repairable system or component, commonly used to express reliability and to plan maintenance intervals.

The ease and speed with which a system can be restored to a specified condition after a fault, influenced by accessibility, diagnostics, modularity, and documentation.

The possibility that a technical uncertainty, immature technology, or unresolved issue will cause the system to miss performance, cost, or schedule objectives.

A maintained record of identified risks, each with likelihood, consequence, owner, mitigation plan, and current status, reviewed periodically through the life cycle.

A structured technique that enumerates the ways each element can fail, rates severity, occurrence, and detectability, and prioritizes actions to reduce the highest-risk modes.

A requirement that constrains system behavior to keep harm to people, property, or the environment within an accepted level, often derived from hazard analysis.

A binding duty imposed by law, regulation, contract, or standard that the system and its processes must satisfy, with evidence retained to demonstrate conformity.

Records, observations, or statements of fact that an auditor examines to determine whether requirements, processes, and controls are actually being met.