22.1 The Systems Engineering V-Model, Stakeholder Requirements, and Functional Architecture

22.1 The Systems Engineering V-Model, Stakeholder Requirements, and Functional Architecture

Industrial and systems engineers design, optimize, and manage complex, multidisciplinary systems comprising hardware, software, human operators, and physical facilities. Successfully executing these systems requires a disciplined framework that maintains technical coherence from initial concept definition through retirement. The NCEES FE Industrial and Systems examination tests core systems engineering principles, lifecycle progression models, requirement authoring rules, functional decomposition tools, and quantitative trade-off methodologies.

---

1. Systems Engineering Foundations & The INCOSE Framework

Definition of a System

A system is defined as an integrated composite of interacting elements—including hardware, software, personnel, facilities, procedures, and data—organized to satisfy a defined operational objective within a specified operational environment. A fundamental premise of systems theory is emergence: a system exhibits properties, capabilities, and behaviors that emerge exclusively from the collective interactions of its constituent parts and cannot be possessed by any individual element in isolation (e.g., flight capability in an aircraft, or throughput capacity in an automated warehouse).

The Systems Engineering Discipline

According to the International Council on Systems Engineering (INCOSE), Systems Engineering (SE) is:

"A transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems by employing systems principles and concepts, and scientific, technological, and management methods."

Traditional engineering disciplines (such as mechanical, electrical, and chemical engineering) operate via a reductionist approach, subdividing complex problems into specialized component domains. Systems engineering operates via a holistic approach, focusing on:

• Defining customer operational needs and required system functionality early in the development cycle.
• Documenting and allocating verifiable technical requirements.
• Synthesizing balanced physical architectures via formal trade studies.
• Managing configuration changes and cross-disciplinary interfaces.
• Conducting structured verification and operational validation throughout the system lifecycle.

---

2. Systems Engineering Life-Cycle Models

System lifecycle models structure the maturation of a product from initial operational concept to disposal. The FE exam emphasizes three fundamental development models: the Vee Model, the Spiral Model, and the Linear Waterfall Model.

The Systems Engineering Vee Model (V-Model)

The Vee Model (originally developed by NASA and standardized by INCOSE and DoD) is the foundational systems engineering lifecycle framework. It organizes development into a symmetric "V" shape representing two complementary axes:

• Horizontal Dimension: Represents chronological time and technical maturation moving from left to right.
• Vertical Dimension: Represents the level of system abstraction, moving from high-level operational concepts at the top down to detailed physical components at the bottom.

The Systems Engineering Vee Model

Stakeholder Needs & OpsCon ────────────────────────────────────────► System Operational Validation
     \                                                                  ▲
      ▼                                                                │
  System Requirements Definition ──────────────────────────► System Verification & Testing
       \                                                         ▲
        ▼                                                       │
    Subsystem Functional Architecture ───────────► Subsystem Integration & Test
         \                                           ▲
          ▼                                         │
      Component Detailed Design ──────► Unit / Component Testing
           \                             ▲
            ▼                           │
             └───► Implementation ──────┘
                   (Fabrication / Coding)

The Left Leg: Top-Down Decomposition and Definition

The left leg focuses on establishing requirements and decomposing the system hierarchically:

1. Stakeholder Requirements & Operational Concept (OpsCon): Elicit user needs, operating environments, and operational scenarios.
2. System Requirements Definition: Translate operational needs into quantifiable, testable engineering specifications.
3. Subsystem Architecture & Functional Design: Decompose system-level requirements into functional blocks and allocate them to subsystem Configuration Items (CIs).
4. Component Detailed Design: Engineer individual physical components, circuit boards, structural weldments, and software code modules.
5. Implementation / Fabrication (The Vertex): Manufacture hardware parts, code software, and procure off-the-shelf components.

The Right Leg: Bottom-Up Integration and Verification

The right leg focuses on physical assembly, functional checkout, and testing:

1. Unit / Component Testing: Verify that fabricated components comply with detailed manufacturing drawings and unit specifications.
2. Subsystem Integration & Testing: Assemble components into functional subsystems and test their mutual interfaces.
3. System Verification & Testing: Verify that the fully integrated system complies with the System Requirements Specification under controlled test conditions ("Did we build the system right?").
4. System Operational Validation & Acceptance: Evaluate the complete system in its true operational environment with actual end-users to confirm it satisfies the original operational concept ("Did we build the right system?").

The Fundamental Horizontal Traceability Principle: Every specification level on the left leg directly defines the acceptance criteria and test protocols for the corresponding verification phase on the right leg. System verification tests do not test component drawings; they test against the system-level functional requirements established during the left-leg definition phase.

Boehm's Spiral Model

Developed by Barry Boehm, the Spiral Model is an iterative, risk-driven lifecycle model. Rather than proceeding in a single linear sequence, the project progresses through repeated spiral cycles, expanding outward in scope and cumulative cost. Each cycle traverses four sequential quadrants:

1. Determine Objectives, Alternatives, and Constraints: Define the specific technical goals and boundaries for the iteration.
2. Evaluate Alternatives, Identify and Resolve Risks: Conduct formal risk assessments, analytical simulations, benchmarking, and rapid prototyping to retire critical technical uncertainties.
3. Develop and Verify Next-Level Product: Construct and test the next evolutionary release or prototype.
4. Review and Plan Next Phase: Review results with stakeholders and formulate the engineering plan for the subsequent spiral cycle.

Key Advantage: Highly effective for first-of-a-kind systems featuring high technological uncertainty and evolving requirements where early prototyping prevents late-stage catastrophic failure.

The Linear Waterfall Model

The Waterfall Model executes development through strictly sequential, non-overlapping phases: Requirements $\to$ Design $\to$ Implementation $\to$ Verification $\to$ Maintenance. Formal gate reviews separate each phase.

Critical Pitfall: The Waterfall model defers system integration and verification until the very end of the project schedule ("big bang integration"). If architectural disconnects or interface conflicts are discovered during late integration, the required rework causes severe schedule delays and budget overruns.

---

3. Stakeholder Requirements Elicitation & The Operational Concept (OpsCon)

Systems engineering initiates with problem definition rather than solution synthesis. Stakeholder requirements define the problem domain—what the customer, operators, and regulatory agencies require to achieve mission success.

Concept of Operations (ConOps) vs. Operational Concept (OpsCon)

Although frequently conflated, INCOSE and IEEE standards distinguish between two key operational artifacts:

• Concept of Operations (ConOps): An enterprise-level document written from the viewpoint of user leadership and stakeholders. It describes the high-level operational vision, organizational goals, enterprise mission scenarios, and how the system fits into overall corporate or defense strategy.
• Operational Concept (OpsCon): An engineering-level document generated during the early requirements phase. It details the operational characteristics of the proposed system, including:
  • Detailed mission phases (transport, startup, continuous production, degraded modes, emergency shutdown).
  • Environmental profiles (temperature, humidity, mechanical shock, vibration, dust, electromagnetic interference).
  • Operational scenarios, human-machine interface (HMI) interactions, and user skill profiles.
  • Maintenance, logistics support, and decommissioning concepts.

Translating User Needs into System Technical Requirements

Stakeholders express their desires in the language of the user domain, which is often qualitative, vague, and solution-biased. The systems engineer must translate these "voices of the customer" into unambiguous, verifiable engineering requirements:

---

4. Requirements Engineering & SMART Criteria

A requirement is a formal statement identifying a system capability, characteristic, or constraint that must be satisfied. Poorly formulated requirements are the primary root cause of engineering project failure.

SMART Requirement Characteristics

Every professional engineering requirement must satisfy the SMART criteria:

1. Specific: States a single, well-defined function or constraint without ambiguity. Avoid compound requirements containing the word "and" that combine multiple disparate functions.
2. Measurable: Defines a definitive numerical performance threshold, range, or pass/fail criterion with appropriate engineering units. If a parameter cannot be measured, it cannot be verified.
3. Achievable (Attainable): Technically feasible within the bounds of physical laws, current technology readiness levels (TRL), project budget, and schedule constraints.
4. Relevant: Directly necessary to achieve the mission objectives, user needs, or regulatory compliance.
5. Traceable: Possesses a unique identifier and is bidirectionally linked to a parent user need and child design/test artifacts.

Strict Syntactic Rules and Binding Language

In formal systems engineering specifications, language carries legal and technical weight:

• "Shall": Expresses a binding, mandatory requirement that must be satisfied and verified during test.
• "Should": Expresses a goal, recommendation, or non-binding preference. Systems cannot be rejected for failing to meet a "should" statement.
• "Will": Expresses a statement of fact, operational intention, or declaration of purpose (e.g., "The customer will provide $480\text{ V}$ 3-phase electrical power"), not a requirement on the engineered system.

Unacceptable Ambiguity Words on the FE Exam: Requirements containing words such as user-friendly, adequate, robust, state-of-the-art, rapid, heavy-duty, or cost-effective are fundamentally defective because they lack objective, measurable pass/fail criteria.

Bidirectional Requirements Traceability Matrix (RTM)

A Requirements Traceability Matrix (RTM) maintains explicit links across all project documentation:

• Forward Traceability: Tracks each stakeholder need down through system requirements, subsystem specifications, physical component drawings, and finally to test verification procedures. Ensures that zero stakeholder needs are orphaned.
• Backward Traceability: Tracks each design feature, physical component, and verification test case back to an authorized parent requirement. Ensures zero gold plating (the unauthorized addition of extraneous, expensive features that were never requested by the customer).

---

5. Functional Analysis and Architectural Decomposition

Systems engineering enforces a strict design principle: Functional architecture precedes physical architecture. Engineers must comprehensively define what the system must accomplish before deciding how (the hardware and software components) it will be built.

Functional Analysis Tools

Functional analysis decomposes top-level mission goals into a hierarchy of discrete, lower-level functions stated as active verbs paired with nouns (e.g., "Filter hydraulic fluid," "Transmit sensor data," "Convert electrical energy"). Three primary functional modeling tools are tested on the FE exam:

1. Functional Block Diagram (FBD)

A static visual model depicting system functions and their logical relationships. FBDs represent functional interfaces (inputs and outputs of energy, data, or materials) without explicitly showing temporal execution sequences or time-based logic.

2. Functional Flow Block Diagram (FFBD)

A dynamic, time-sequenced model illustrating the sequential execution order of functions. FFBDs incorporate formal logical control gates:

• AND Gate ($&$, parallel execution): All parallel functional paths must complete before proceeding to the next function.
• OR / XOR Gate (conditional branching): Execution proceeds along one path based on conditional criteria.
• Loop / Iteration: Functions repeat cyclically until an exit condition is satisfied.

Functional Flow Block Diagram (FFBD) Logic Gates

     ┌────────────┐               ┌────────────┐
     │ Function A │               │ Function A │
     └─────┬──────┘               └─────┬──────┘
           │                            │
         [AND]                         [OR]
        ┌──┴──┐                       ┌──┴──┐
        ▼     ▼                       ▼     ▼
     ┌─────┐┌─────┐                ┌─────┐┌─────┐
     │ F-B ││ F-C │                │ F-B ││ F-C │
     └──┬──┘└──┬──┘                └──┬──┘└──┬──┘
        └──┬──┘                       └──┬──┘
         [AND]                         [OR]
           ▼                            ▼
     ┌────────────┐               ┌────────────┐
     │ Function D │               │ Function D │
     └────────────┘               └────────────┘

3. $N^2$ Interaction Diagram ($N$-Squared Chart)

An $N^2$ diagram is a systematic $N \times N$ matrix used to map all data, energy, and physical material interactions among $N$ functional elements or physical subsystems:

• The $N$ functional or physical components are placed exclusively along the principal diagonal (from top-left to bottom-right).
• All off-diagonal cells represent directed interfaces.
• Standard Convention: A component in row $i$ outputs data, power, or material to any component in column $j$. Conversely, any cell in column $i$ represents an input received by component $i$ from row $j$.
• Empty off-diagonal cells denote zero direct interface between the respective components.
• Clustering: $N^2$ charts allow systems engineers to rearrange subsystem ordering along the diagonal to group tightly coupled components together into unified physical modules, minimizing external cross-module interfaces.

Sample N2 Interaction Chart for an Automated Workcell

┌──────────────┬──────────────┬──────────────┬──────────────┐
│  Workcell    │  Actuator    │  Status      │              │
│  Controller  │  Commands    │  Display     │      ─       │  Row 1 Outputs
├──────────────┼──────────────┼──────────────┼──────────────┤
│  Motor Temp  │  Robotic Arm │  Position    │  Joint Gripper│
│  Feedback    │  Manipulator │  Telemetry   │  Actuation   │  Row 2 Outputs
├──────────────┼──────────────┼──────────────┼──────────────┤
│  Stop / Abort│              │  HMI Touch   │              │
│  Requests    │      ─       │  Screen      │      ─       │  Row 3 Outputs
├──────────────┼──────────────┼──────────────┼──────────────┤
│  Part Seated │  Proximity   │              │  End-Effector│
│  Interlock   │  Signals     │      ─       │  Tooling     │  Row 4 Outputs
└──────────────┴──────────────┴──────────────┴──────────────┘
  Col 1 Inputs   Col 2 Inputs   Col 3 Inputs   Col 4 Inputs

Translating Functional Architecture to Physical Architecture

Once functional decomposition is complete, functions are mapped to physical hardware, software algorithms, or human operators via a Functional Allocation Matrix.

• Modular Architecture: Functional blocks map one-to-one onto distinct physical modules with well-defined, decoupled interfaces. Advantages: High serviceability, independent subsystem upgradeability, parallel development by isolated supplier teams. Disadvantage: Suboptimal weight and spatial efficiency.
• Integral Architecture: Multiple functional blocks are combined into a single, highly integrated physical component (e.g., an aircraft wing acting simultaneously as an aerodynamic lift surface, a structural spar, and a fuel containment tank). Advantages: Maximizes structural efficiency and minimizes weight. Disadvantage: High coupling; modifying one function forces redesign of the entire assembly.

---

6. Trade Studies & Multi-Attribute Utility Theory (MAUT)

During conceptual design, engineers evaluate competing architectural alternatives (e.g., electric vs. hydraulic actuation, centralized vs. distributed processing). A trade study is a formal, objective decision-making methodology.

Multi-Attribute Utility Theory (MAUT)

MAUT provides an axiomatic mathematical foundation for concept selection under multi-criteria constraints:

1. Establish Evaluation Criteria ($k = 1, 2, \dots, m$): Select independent performance criteria (e.g., weight, cycle time, unit cost, safety factor).
2. Determine Attribute Weights ($w_k$): Assign normalized weights reflecting stakeholder priorities such that: $\sum_{k=1}^m w_k = 1.0 \quad \text{where } w_k > 0$
3. Formulate Single-Attribute Utility Functions ($u_k(x_k)$): Convert raw engineering performance metrics $x_k$ (in dollars, kilograms, seconds) into a dimensionless utility scale from $0.0$ (least desirable) to $1.0$ (most desirable). For a linear "more is better" criterion: $u_k(x_k) = \frac{x_k - x_{k,\min}}{x_{k,\max} - x_{k,\min}}$ For a linear "less is better" criterion (such as cost or mass): $u_k(x_k) = \frac{x_{k,\max} - x_k}{x_{k,\max} - x_{k,\min}}$
4. Calculate Total Multi-Attribute Utility ($U_j$): Compute the weighted additive utility for each candidate alternative $j$: $U_j = \sum_{k=1}^m w_k \cdot u_k(x_{jk})$ The alternative with the maximum utility $U^* = \max(U_j)$ is selected.

Pugh Concept Screening Matrix

For early conceptual screening, a Pugh Matrix provides a qualitative baseline comparison. A current or industry-standard concept is chosen as the datum (baseline) and assigned a score of S (Same) across all criteria. Competing concepts are evaluated against the datum as:

• + (Better than baseline)
• - (Worse than baseline)
• S (Identical / equal to baseline)

Concepts with high net positive scores are selected for detailed MAUT evaluation or hybrid refinement.

---

7. Step-by-Step Worked Engineering Calculations

Worked Example 22.1.1: Multi-Attribute Utility Trade Study for AGV Drivetrain Selection

Problem: An industrial systems engineering team is selecting the drivetrain architecture for a next-generation Automated Guided Vehicle (AGV) deployed in a high-density warehouse. Three candidate concepts are evaluated:

• Concept A: Differential Two-Wheel Drive
• Concept B: Mecanum Omnidirectional Four-Wheel Drive
• Concept C: Quad-Steer Dual-Bogie Drive

The systems engineering team establishes four evaluation criteria with stakeholder weights:

1. Payload Capacity ($C_1$): Weight $w_1 = 0.30$ (More is better; range: $500\text{ kg}$ to $1,500\text{ kg}$)
2. Turning Radius / Maneuverability ($C_2$): Weight $w_2 = 0.35$ (Less is better; range: $0.0\text{ m}$ to $1.5\text{ m}$)
3. Battery Operating Duration ($C_3$): Weight $w_3 = 0.20$ (More is better; range: $6.0\text{ hr}$ to $14.0\text{ hr}$)
4. Manufacturing & Maintenance Unit Cost ($C_4$): Weight $w_4 = 0.15$ (Less is better; range: $$8,000$ to $$20,000$)

The raw performance values achieved by the three concepts are recorded below:

1. Calculate the normalized single-attribute utility scores ($u_k \in [0.0, 1.0]$) for each concept.
2. Compute the total multi-attribute utility ($U$) for Concepts A, B, and C.
3. Determine which concept should be selected based on MAUT.
4. Conduct a sensitivity check: If warehouse aisle layout changes and makes turning radius weight $w_2 = 0.15$ and payload capacity weight $w_1 = 0.50$ (with $w_3 = 0.20, w_4 = 0.15$), does the winning concept change?

Solution:

Step 1: Normalize Raw Engineering Scores into Utility Values ($u_k$)

• Criterion 1: Payload (More is better, $\min=500, \max=1500$, range $= 1000$ kg): $u_1(x) = \frac{x - 500}{1000}$

  • $u_{1,A} = \frac{800 - 500}{1000} = 0.300$
  • $u_{1,B} = \frac{600 - 500}{1000} = 0.100$
  • $u_{1,C} = \frac{1400 - 500}{1000} = 0.900$

• Criterion 2: Turning Radius (Less is better, $\min=0.0, \max=1.5$, range $= 1.5$ m): $u_2(x) = \frac{1.5 - x}{1.5}$

  • $u_{2,A} = \frac{1.5 - 0.6}{1.5} = \frac{0.9}{1.5} = 0.600$
  • $u_{2,B} = \frac{1.5 - 0.0}{1.5} = \frac{1.5}{1.5} = 1.000$
  • $u_{2,C} = \frac{1.5 - 0.9}{1.5} = \frac{0.6}{1.5} = 0.400$

• Criterion 3: Battery Duration (More is better, $\min=6.0, \max=14.0$, range $= 8.0$ hr): $u_3(x) = \frac{x - 6.0}{8.0}$

  • $u_{3,A} = \frac{12.0 - 6.0}{8.0} = \frac{6.0}{8.0} = 0.750$
  • $u_{3,B} = \frac{7.5 - 6.0}{8.0} = \frac{1.5}{8.0} = 0.1875$
  • $u_{3,C} = \frac{10.0 - 6.0}{8.0} = \frac{4.0}{8.0} = 0.500$

• Criterion 4: Unit Cost (Less is better, $\min=8000, \max=20000$, range $= 12000$ $): $u_4(x) = \frac{20000 - x}{12000}$

  • $u_{4,A} = \frac{20000 - 10000}{12000} = \frac{10000}{12000} = 0.8333$
  • $u_{4,B} = \frac{20000 - 15000}{12000} = \frac{5000}{12000} = 0.4167$
  • $u_{4,C} = \frac{20000 - 18000}{12000} = \frac{2000}{12000} = 0.1667$

Step 2: Compute Total Multi-Attribute Utility ($U = \sum w_k u_k$)

• Concept A (Differential): $U_A = 0.30(0.300) + 0.35(0.600) + 0.20(0.750) + 0.15(0.8333)$ $U_A = 0.0900 + 0.2100 + 0.1500 + 0.1250 = 0.5750$

• Concept B (Mecanum): $U_B = 0.30(0.100) + 0.35(1.000) + 0.20(0.1875) + 0.15(0.4167)$ $U_B = 0.0300 + 0.3500 + 0.0375 + 0.0625 = 0.4800$

• Concept C (Quad-Steer): $U_C = 0.30(0.900) + 0.35(0.400) + 0.20(0.500) + 0.15(0.1667)$ $U_C = 0.2700 + 0.1400 + 0.1000 + 0.0250 = 0.5350$

Step 3: Selection

• Ranking: $U_A (0.575) > U_C (0.535) > U_B (0.480)$.
• Engineering Conclusion: Under the baseline weighting, Concept A (Differential Drive) is selected because its balanced performance across low cost, long battery duration, and moderate turning radius yields the highest total utility.

Step 4: Sensitivity Analysis under Revised Weights

With $w_1 = 0.50$, $w_2 = 0.15$, $w_3 = 0.20$, $w_4 = 0.15$:

• $U_A' = 0.50(0.300) + 0.15(0.600) + 0.20(0.750) + 0.15(0.8333) = 0.1500 + 0.0900 + 0.1500 + 0.1250 = 0.5150$
• $U_B' = 0.50(0.100) + 0.15(1.000) + 0.20(0.1875) + 0.15(0.4167) = 0.0500 + 0.1500 + 0.0375 + 0.0625 = 0.3000$
• $U_C' = 0.50(0.900) + 0.15(0.400) + 0.20(0.500) + 0.15(0.1667) = 0.4500 + 0.0600 + 0.1000 + 0.0250 = 0.6350$
• Sensitivity Conclusion: When payload capacity priority increases to $w_1 = 0.50$, Concept C (Quad-Steer) surges to $0.6350$ and becomes the clear winner, illustrating how stakeholder weight adjustments fundamentally alter architectural selection.

---

8. NCEES Reference Handbook Tips & Realistic Exam Traps

• The Vee Model Horizontal Mapping Trap: When matching development phases to verification phases, remember: System Requirements pair with System Verification; Subsystem Specifications pair with Subsystem Integration & Test; Detailed Component Designs pair with Component / Unit Testing; and the OpsCon / Stakeholder Needs pair with Operational Validation. Never map detailed drawings directly to system validation.
• Binding Language on the Exam: If an exam question presents four candidate requirement statements and asks which is legally binding and valid, eliminate any option that uses should (preference), will (statement of fact), or vague terms (durable, fast). The correct requirement will always use "shall" and provide a quantifiable numeric metric.
• $N^2$ Diagram Data Flow Convention: Remember the universal reading rule: Row outputs to Column. The cell in Row 2, Column 4 is an output from Subsystem 2 that enters Subsystem 4 as an input. Do not reverse this flow!