CSEP cheat sheet
CSEP · Keep the key ideas within reach.
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.
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.
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.
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.