CSEP study materials
CSEP study resources

CSEP cheat sheet

CSEP · Keep the key ideas within reach.

Quick reference

General Systems Engineering

  • System boundary rule: anything outside the boundary is environment; inputs crossing the boundary are interfaces, and each interface must be documented with type, direction, range, and units.

  • INCOSE definition: a system is an integrated set of elements that accomplish a defined objective; a system of systems adds operational independence, managerial independence, emergence, evolution, and geographic distribution.

  • Life cycle stages (ISO/IEC 15288): concept, development, production, utilization, support, retirement; each stage has processes, not phases, and processes may run concurrently.

  • Emergence rule: system-level behavior cannot be predicted from element behavior alone; verification of elements does not verify the system, so integration testing is mandatory.

  • Vee model mapping: left leg decomposes requirements to architecture to detailed design; right leg maps unit test to integration test to system validation; each level pairs a decomposition artifact with a verification artifact.

  • Entropy and open systems: a system maintains low internal entropy by importing energy or information; a closed system degrades toward disorder, which explains why feedback and maintenance loops are required.

  • Trade study rule: define weighted evaluation criteria before scoring alternatives; the sensitivity analysis on weights determines whether the chosen alternative is robust.

  • Cybernetic control law: error = setpoint - measured output; a controller acts on error, and stability requires the loop gain and phase margin to satisfy the Nyquist criterion, not merely a small error.

Quick reference

Requirements and Architecture

  • Requirement quality tests: necessary, unambiguous, complete, singular, feasible, verifiable, and traceable; a requirement containing 'and/or' or 'etc.' fails singularity or completeness.

  • Shall versus should: 'shall' denotes a binding requirement, 'should' a recommendation, 'will' a statement of fact; mixing them in one specification destroys verifiability.

  • Architecture views (ISO/IEC 42010): each view addresses one concern of one or more stakeholders, and every view must have a corresponding viewpoint that defines its conventions.

  • Functional versus non-functional: functional requirements state behavior (transformations of inputs to outputs); quality attributes such as availability, latency, and maintainability constrain how well behavior is delivered.

  • Allocation rule: each system requirement must be allocated to at least one architectural element or to a derived requirement; unallocated requirements indicate an architecture gap.

  • Derived requirements arise from design decisions (e.g., choosing a bus protocol creates a timing requirement) and must be traced to their parent requirement and to the design rationale.

  • Interface definition content: source, destination, data or energy type, units, range, accuracy, update rate, protocol, and failure behavior; omitting failure behavior is the most common interface defect.

  • MOE versus MOP versus TPM: Measures of Effectiveness are mission-level and stakeholder-facing; Measures of Performance are system-level; Technical Performance Measures track design progress against thresholds.

Quick reference

Verification and Validation

  • Verification answers 'did we build the system right' against specified requirements; validation answers 'did we build the right system' against stakeholder needs and the operational concept.

  • Verification methods: inspection, analysis, demonstration, and test; the method must be chosen at requirement-writing time because 'verifiable' depends on an available method.

  • Test coverage rule: each requirement needs at least one verification method and evidence record; a requirement with no verification method is untestable and must be rewritten or deleted.

  • Traceability direction: requirements trace forward to design, code, and test cases; test results trace backward to requirements; both directions are needed to prove completeness.

  • Statistical test design: to demonstrate a reliability with confidence C at a given failure rate, the required sample size grows as ln(1-C)/ln(R); zero-failure tests still need sample size, not just one successful run.

  • Regression rule: a change to any configuration item triggers re-verification of that item plus all items whose verification depends on it through the traceability graph.

  • Environmental testing: qualification tests prove the design margin under worst-case environments; acceptance tests prove workmanship on each unit; they use different levels and durations.

  • Validation environments: simulation, hardware-in-the-loop, and operational test each trade fidelity against cost; a validation claim is only as strong as the fidelity of the environment used.

Quick reference

Systems Engineering Management

  • Technical baseline triad: functional baseline (system requirements), allocated baseline (requirements allocated to configuration items), product baseline (as-built configuration); each is change-controlled after establishment.

  • Configuration management rule: every change to a baselined item passes identification, evaluation, disposition, and implementation; an unapproved change is a configuration escape.

  • Risk exposure formula: risk = probability x consequence; risk handling options are avoid, mitigate, transfer, and accept, and each accepted risk needs an owner and a trigger condition.

  • Earned Value formulas: CV = EV - AC; SV = EV - PV; CPI = EV/AC; SPI = EV/PV; EAC = BAC/CPI when current cost performance is expected to continue.

  • Critical path rule: the critical path is the longest path through the network; it has zero total float, and any delay on it delays the project finish one-for-one.

  • Interface management: an interface control document is jointly owned by both sides of the interface; unilateral change to an ICD is a management failure even if technically correct.

  • Reviews by purpose: SRR confirms requirements are understood; PDR confirms the preliminary design satisfies requirements; CDR confirms the detailed design is buildable; TRR confirms test readiness.

  • Decision analysis: the Kepner-Tregoe or weighted-sum matrix requires criteria, weights, and scores fixed before evaluation; documenting rejected alternatives is what makes the decision auditable.