In one line: The structured life-cycle processes, from requirements and design to integration, verification and technical reviews, that large programs use to keep a complex system on track, as documented in the INCOSE and NASA handbooks.
Core idea
Both major handbooks [1], [2] describe systems engineering as a set of interlocking processes applied repeatedly across a project’s life cycle. Each handbook runs to several hundred pages. The practical advice is to learn the vocabulary, skim the main body, and study the appendices, where the working techniques live: guidance on writing good requirements, verification matrices, validation planning, functional and timing analysis, and integration planning.
How it works
The “V.” Work flows down the left side, decomposing needs into system, subsystem and component requirements and designs. It flows up the right side, integrating components and verifying each level against its requirements, until the whole system is validated against the stakeholders’ original need.
Technical reviews. Programs gate progress with formal reviews, each with defined entry and exit criteria. NASA-style names include:
- mission concept review
- system requirements review (SRR)
- preliminary design review (PDR)
- critical design review (CDR)
- system integration review
- operational and flight readiness reviews
Supporting processes:
- requirements management
- interface management
- technical risk management (see Risk Management)
- configuration management (see Engineering Change Control)
- technical measurement (tracking key performance parameters against plan)
- decision analysis
In practice
Most engineering organizations adapt the reviews to their own product. An integrated-circuit design flow, for example, may require specific deliverables, such as simulations, layouts and check results, by each design review, mirroring the handbooks’ entry and exit criteria. A good exercise is to pick one technique from the handbook appendices and explain how you have used it, or could use it, on your own work. Common choices are a timing diagram, a functional flow, an N-squared interface chart, or a requirements verification matrix.
Questions to ask yourself
- Which review is my project heading toward, and what are its exit criteria?
- Is every requirement on my subsystem verifiable, and do we know how we’ll verify it?
- Where on the V are we likely to discover the problems we haven’t found yet?
Connections
- Concept: Systems Engineering. Analysis techniques: Functional Flow Block Diagram, Throughput and Timing Analysis.
- Supporting processes: Risk Management, Engineering Change Control. Commercial counterpart: Product Development Process.
- Capabilities exercised: Realizing the Vision, Decision Making, Responsibility and Urgency to Deliver.