CSEP flashcards

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

System boundary

The conceptual line separating a system from its environment. Everything crossing it is an interface that must be defined in type, direction, range, and units.

Emergent behavior

System-level behavior arising from element interactions that cannot be predicted from element behavior alone, which is why integration testing is required after component verification.

System of systems

A set of independently operable and managed systems that cooperate to produce emergent results, characterized by operational and managerial independence plus evolution.

Vee model

A life cycle representation where the left leg decomposes requirements and design and the right leg verifies and validates each level against its paired decomposition artifact.

Open system

A system that exchanges matter, energy, or information with its environment, allowing it to maintain low internal entropy through feedback and maintenance.

Trade study weighting

A decision method where evaluation criteria and weights are fixed before alternatives are scored, followed by sensitivity analysis to test whether the selection is robust.

Life cycle processes

ISO/IEC 15288 defines concurrent processes such as stakeholder needs, requirements, architecture, verification, and validation that apply across all life cycle stages.

Feedback control error

The difference between a setpoint and the measured output. A controller acts on this error, and loop stability depends on gain and phase margin, not on small error alone.

Requirement quality attributes

A well-formed requirement is necessary, unambiguous, complete, singular, feasible, verifiable, and traceable. Conjunctions and vague qualifiers violate singularity or verifiability.

Shall versus should

'Shall' states a binding requirement, 'should' a recommendation, and 'will' a statement of fact. Mixing them in one specification undermines verifiability.

Architecture view and viewpoint

Per ISO/IEC 42010, a view addresses one concern of stakeholders, and its viewpoint defines the conventions, models, and notations used to construct that view.

Quality attribute requirement

A non-functional requirement constraining how well behavior is delivered, such as availability, latency, throughput, security, or maintainability, and it must be measurable.

Requirement allocation

The assignment of each system requirement to at least one architectural element or derived requirement. Unallocated requirements reveal an architecture gap.

Derived requirement

A requirement created by a design decision rather than stated by the stakeholder, traceable to its parent requirement and to the rationale for the design choice.

Interface control document

A jointly owned record of an interface's source, destination, data type, units, range, accuracy, rate, protocol, and failure behavior, controlled by both sides.

MOE versus MOP

Measures of effectiveness assess mission success from the stakeholder view; measures of performance assess system behavior. Technical performance measures track design progress against thresholds.

Verification versus validation

Verification confirms the system meets its specified requirements; validation confirms the system meets stakeholder needs in the intended operational environment.

Verification methods

Inspection, analysis, demonstration, and test. The method must be selected when the requirement is written, since verifiability depends on an available method.

Bidirectional traceability

Requirements trace forward to design and test cases, and results trace backward to requirements. Both directions are needed to demonstrate completeness and coverage.

Zero-failure reliability test

Demonstrating reliability R at confidence C with no failures requires sample size n = ln(1-C)/ln(R); a single successful run proves almost nothing.

Regression verification

Re-verification triggered by a configuration change, covering the changed item plus all items whose verification depends on it through the traceability graph.

Qualification versus acceptance test

Qualification proves design margin under worst-case environments; acceptance proves workmanship on each production unit using different levels and durations.

Hardware-in-the-loop

A validation environment where real hardware runs against a simulated plant, trading fidelity against cost and risk compared with full operational testing.

Test readiness review

A review confirming that test plans, procedures, facilities, instrumentation, trained personnel, and configured test articles are ready before test execution begins.

Functional baseline

The approved system-level requirements and concept documentation that define what the system must do, placed under configuration control at establishment.

Allocated baseline

The approved set of requirements allocated to configuration items, describing what each item must do to satisfy the functional baseline.

Product baseline

The approved as-built configuration documentation, including drawings, software builds, and specifications that define the produced item.

Configuration control

Every change to a baselined item passes identification, evaluation, disposition, and implementation. An unapproved change is a configuration escape.

Risk exposure

The product of probability and consequence. Handling options are avoid, mitigate, transfer, and accept, and each accepted risk needs an owner and trigger.

Cost performance index

CPI equals earned value divided by actual cost. A value below one means cost overrun, and EAC equals BAC divided by CPI when current performance continues.

Critical path

The longest path through the project network, possessing zero total float, so any delay along it delays project completion by the same amount.

Design review sequence

SRR confirms requirements understanding, PDR confirms preliminary design adequacy, CDR confirms detailed design buildability, and TRR confirms readiness to test.