systems-engineering-process

name	systems-engineering-process
description	Systems engineering process — V-model, requirements (MoE/MoP/KPP), SRR/PDR/CDR reviews, CONOPS, system architecture, MBSE (SysML), verification and validation, INCOSE SE handbook.
metadata	{"priority":7,"promptSignals":{"phrases":["systems engineering","V model","systems requirements","PDR CDR review","SysML","MBSE","INCOSE"],"minScore":3}}

Systems Engineering Process — Complete Skill

Systems Engineering Definition

IEEE 15288: interdisciplinary approach to enable realization of successful systems Transforms stakeholder needs → system solutions through structured technical processes

INCOSE Systems Engineering Handbook (4th ed.): standard reference ISO/IEC/IEEE 15288:2023: system life cycle processes

V-Model (Verification-Validation Model)

User Needs/Requirements    ←——→ Operational Testing/V&V
    ↓                              ↑
System Requirements   ←——→   System Verification
    ↓                          ↑
Subsystem Requirements ←→ Subsystem Verification
    ↓                      ↑
Component Requirements ←→ Component Testing
    ↓                  ↑
        DESIGN/FABRICATION

Left side: decomposition (requirements and design) Right side: integration (build, verify, validate) Horizontal arrows: verification method for each level

Requirements Engineering

Requirement Types

Stakeholder Requirements: from customers/users; "what" the system must do System Requirements: technical translation; measurable; verifiable Subsystem Requirements: allocated to components; drives design Derived Requirements: emerge from design choices; not directly from stakeholder

Requirement Quality (SMART)

• Specific: unambiguous
• Measurable: quantified; has test criteria
• Achievable: feasible within cost/schedule/technology
• Relevant: traceability to stakeholder need
• Time-bound: when required

Requirement statement template: "The [system] shall [function] [performance] [condition]" Example: "The navigation system shall compute position with accuracy ≤ 10 m CEP when in urban environments"

Key Performance Parameters (KPPs)

MOE (Measure of Effectiveness): operational effectiveness metrics (system level) MOP (Measure of Performance): physical performance (design level) KPP (Key Performance Parameter): minimum acceptable MOE/MOP; failure → program restructure

Example (UAV): KPP1: Endurance ≥ 12 hr (MOE = mission completion capability) KPP2: Payload ≥ 20 kg (MOP → derived from mission requirements) KPP3: Operating altitude ≥ 5000 m MSL

Requirements Management Tools

DOORS (IBM), JAMA Connect, Rational REQUISITEPRO, Polarion, CodeBeamer All support: bi-directional traceability, change impact analysis, automated coverage

CONOPS (Concept of Operations)

Purpose: define how system will be used operationally; drives requirements Content:

• Mission description and operational scenarios
• Environment and threats
• Operational modes (normal/degraded/emergency)
• Interfaces with external systems
• Human role in operations

Process: stakeholder interviews → scenarios → operational view → requirements derivation

System Architecture

Functional Architecture

FFBD (Functional Flow Block Diagram): sequential function decomposition N²/IDEF0: function-interaction matrices; interface identification SysML Activity Diagram (MBSE): visual function modeling

Physical Architecture

Physical block decomposition: system → subsystems → assemblies → components Identifies: hardware, software, firmware, personnel, facilities

Interface definition: Interface Control Document (ICD) or Interface Definition Record (IDR) For each interface: physical connector, signal/fluid/data type, levels, timing, protocol

MBSE (Model-Based Systems Engineering)

Replace document-centric with model-centric; SysML (Systems Modeling Language)

SysML diagrams:

• BDD (Block Definition Diagram): hierarchical system decomposition
• IBD (Internal Block Diagram): interface flows between blocks
• Requirement Diagram: requirements + traces to elements
• Use Case Diagram: operational scenarios
• State Machine Diagram: system behavior and modes
• Parametric Diagram: constraints and performance equations

Tools: Cameo (Teamwork Cloud), IBM Rhapsody, Sparx EA, CATIA Magic, Capella

Technical Reviews

Mission Concept Review (MCR)

Purpose: validate mission needs and feasibility Criteria: stakeholder needs agreed; concept viable; alternative concepts evaluated

System Requirements Review (SRR)

Entrance: requirements baseline candidate Exit criteria: all Level 1 requirements complete; traceable to stakeholder needs; no TBDs Assessment: requirements completeness, feasibility, verification approach

Preliminary Design Review (PDR)

Entrance: functional baseline (requirements approved) Content: system architecture; subsystem designs; design-to specifications; mass/power budgets Exit criteria: allocated requirements baselined; design approach feasible; risk areas identified Key products: Part I drawings (functional/preliminary); Mass/Power/Link budget (preliminary)

Critical Design Review (CDR)

Entrance: product baseline (detailed design complete) Content: detailed designs; all hardware drawings released; software design complete Exit criteria: "Build to" drawings released; margins positive; qualification test plan approved Risk: TRL ≥ 6 for all critical items at CDR for flight programs

Test Readiness Review (TRR)

Before each major test; verify test hardware, procedures, safety, expected results documented

Flight/Production Readiness Review (FRR/PRR)

Before first article delivery/launch; all anomalies dispositioned; risk retired

Verification and Validation

Four verification methods:

• Test (T): physical measurement; highest confidence
• Analysis (A): calculation/simulation; use when test impractical
• Inspection (I): visual examination; for physical characteristics
• Demonstration (D): observe operation without measurement; for functional requirements

Verification Matrix: Rows = requirements; Columns = V&V method; Cell = test procedure reference 100% coverage required before CDR exit

Validation (V): Did we build the right system? User demonstrates operational effectiveness meets CONOPS Validation occurs at system level with real users in representative environment

Test Levels

1. Unit test: individual component; developer-run
2. Subsystem test: integrated assembly; engineering
3. System Integration Test (SIT): all hardware + software integrated
4. Acceptance Test (AT): customer witnesses; verifies contract requirements
5. Operational Test (OT): user environment; real or simulated threats/environment

Technical Performance Measures (TPM)

Track key parameter throughout development to predict maturity Plot: TPM vs. time; compare to planned maturity curve Alert: if TPM falls below planned threshold → risk triggered; management attention

Example TPMs: System mass (track vs. mass budget) Software code coverage (track toward 100%) Requirements verified (track toward 100%) Power consumption vs. allocated budget

Risk Management (SE Context)

Technical risk register: Risk = Likelihood × Consequence Likelihood: 1–5 scale (1 = rare; 5 = frequent) Consequence: 1–5 scale (1 = negligible; 5 = catastrophic) Risk score = product; > 10 → mitigation required

Risk mitigation strategies:

• Accept: monitor; document
• Avoid: change design/approach
• Mitigate: reduce likelihood or consequence
• Transfer: insurance, subcontract

Configuration Management (CM)

Baseline types:

• Functional baseline: approved requirements (after SRR)
• Allocated baseline: approved design-to specs (after PDR)
• Product baseline: approved build-to drawings (after CDR)

Change control: Engineering Change Request (ECR) → Engineering Change Notice (ECN) Changes after baseline: formal review process; impact to cost/schedule assessed

Standards: MIL-HDBK-61B (CM); EIA-649C (National CM Standard)

DoD Acquisition Framework (for defense context)

Milestone A (Technology Development): approved CONOPS + preliminary requirements Milestone B (Engineering and Manufacturing Development): SRR passed; PDR planned Milestone C (Production and Deployment): CDR passed; LRIP authorized

ACAT levels: I (major defense program) to III (non-major); determine oversight level

Output

Provide: CONOPS operational scenarios list, draft system-level requirements (5–10 with measurable criteria), requirements traceability matrix structure, functional decomposition (Level 1–3), physical architecture block diagram, KPPs with threshold/objective values, V&V method for each KPP, TPM plan for top 5 parameters, risk register (top 5 risks with mitigation), review schedule (SRR/PDR/CDR dates), and applicable standard (INCOSE SE Handbook 4th ed., ISO/IEC 15288:2023, NASA NPR 7120.5).