Systems engineering begins at the top of the V:
So why is it the last thing funded?

Almost every engineer I've worked with on complex systems can draw the V-Model from memory. Draw it on a whiteboard at an EV, drone or robotics startup and nobody argues. Then ask when the company hired its first dedicated systems engineer, or when requirements moved out of a shared spreadsheet into something with IDs, owners and links. The honest answer is usually some version of: after it started hurting.

That's the irony this series is about. Systems engineering begins in the framing layer, the work every downstream decision inherits. In practice it tends to arrive last: once traceability has gaps, rework is eating the schedule, and someone outside the company has asked for evidence the team can't produce quickly.

The title asks why; I'm going to hold that question until the last post in this series. The usual answers (funding pressure, speed versus rigor, tools built for large OEMs) are real, they're easy to argue about but hard to act on. It's more useful to first be precise about what actually happens when systems engineering (SE) arrives late, and why the costs behave the way they do. Diagnosis before explanation.

What "the top of the V" actually means

The "V" as systems engineers know it was first presented publicly by Kevin Forsberg and Harold Mooz in October 1991, at the first annual conference of the National Council on Systems Engineering in Chattanooga, the body that became INCOSE a few years later [1].

Forsberg and Mooz drew systems engineering across the whole project cycle, not just its opening stages [1]. On the right arm, SE covers verification planning and the traceability that gives testing something to check against. But there is one part of the work that belongs to SE more than to any other discipline, and it sits at the top left: turning stakeholder needs into a coherent requirement set, allocating those requirements to an architecture, and deciding where the interfaces sit. Everything downstream inherits those decisions.

For years, INCOSE's own definition put that early work at the center, describing SE as focused on "defining customer needs and required functionality early in the development cycle" [2]. The current definition, adopted in 2019 and reflected in ISO/IEC/IEEE 15288:2023, widens SE's remit to cover a system's realization, use and retirement [3]. It adds to the early work rather than replacing it. Which makes it odd that, in practice, the early work is usually where SE is missing.

The structural consequence is simple. The right side of the V can only verify what the left side defined. A system test traces to a system requirement; an integration test traces to an interface in the architecture. If the left side was never captured with any rigor, the right side has nothing to verify against, and teams end up testing against their collective memory of intent.

How it usually happens

The pattern is common enough that most people who build complex systems will recognize it. It's a pattern, not a law; plenty of teams break it.

Early. Requirements live across a Google Doc, a few Sheets, Jira tickets, Confluence pages, Slack threads and the heads of the founding engineers. This genuinely works, because the whole system fits in three or four heads and everyone is in every design review. The traceability matrix is a conversation.

Growth. Headcount passes the point where anyone holds the full system. Subsystems get owners. Interfaces multiply faster than people. A requirement changes in a ticket; the spreadsheet it came from doesn't. Nobody notices, because nothing is connected to anything.

Trigger. Something external forces the issue. An OEM customer asks for an Automotive SPICE assessment. A space or defense customer wants a verification cross-reference matrix. A regulator changes the rules. A field issue needs a root cause that crosses three subsystems.

Retrofit. SE arrives as a hire, a consultant or a tool, with a mandate to reconstruct what should have been captured as the work happened.

Notice where the trigger comes from. It's rarely an internal decision that the time has come. It's someone outside the team asking a question the team can't answer quickly.

Three symptoms of late SE

1. Traceability with holes

Safety and process standards don't treat traceability as optional. ISO 26262-8 Clause 6 requires each safety requirement to trace up to its source at the next higher level, down to the requirements derived from it or its realization in the design, and across to its verification [4]. Automotive SPICE 4.0 asks for bidirectional traceability between system requirements and stakeholder requirements [5], with similar links expected at each level further down the left arm.

Retrofitting links is tedious, but possible. The deeper problem is one the ASPICE model itself points out: the mere existence of links doesn't mean the linked information is consistent [5]. A retrofitted link records that two artifacts are related today. It can't tell you whether the design satisfied the requirement when the design was made, or whether the requirement was quietly edited afterward to match.

2. Rework that scales with lateness

The most-cited hardware data comes from a NASA-led study published in 2004. Taking the cost of fixing a requirements error during the requirements phase as 1 unit, the study found the same fix cost 3–8 units in design, 7–16 in build, 21–78 in integration and test, and 29 to 1,615 in operations [6]. The study modeled programs like spacecraft and military aircraft. An early-stage startup's multipliers will differ; the direction is what carries over.

A related view comes from the INCOSE Systems Engineering Handbook, which plots the life-cycle cost committed by decisions against the cost actually spent [7]. By the end of development, a program has spent about a fifth of its total cost but committed nearly all of it. NASA's handbook redraws the same curve less steeply and notes that the numbers vary by project [8]. Both adapt one Defense Acquisition University figure, so read the percentages as illustrative rather than as a forecast for an early-stage startup. What holds up is the shape: cheap early decisions lock in most of what gets spent later. SE that arrives late arrives after most of the cost is committed, and its job shifts from shaping commitments to explaining them.

Cost committed vs. cost spent. Sources: INCOSE Systems Engineering Handbook, 4th ed. (2015), Figure 2.4; NASA Systems Engineering Handbook Rev2 (2016), Figure 2.5-1.

3. The audit scramble

The third symptom is the one founders feel most, because it comes with a deadline someone else set.

India's EV sector offers a clear example. Following electric two-wheeler fire incidents in 2022, the Ministry of Road Transport and Highways formed an expert committee [9]. Its recommendations became amendments to AIS-156 and AIS-038 (Rev 2), adding requirements covering battery cells, battery management systems, on-board chargers, pack design and thermal propagation, phased in from 1 December 2022 and 31 March 2023 [10]. Pack traceability was among the Phase 1 requirements [9]. The industry asked for more time, including to re-homologate battery packs [11].

I'm not suggesting any specific incident traces back to missing systems engineering, that's not a claim I can make. The point is the clock; when requirements change from outside, a team with structured requirements, allocations and verification links can run an impact analysis: which requirements change, which components they touch, which tests need re-running. A team without them runs an archaeology project against a deadline it didn't choose.

That's the gap between evidence you can query and evidence you have to reconstruct.

"We'll add it later" is a different kind of debt

Software teams know technical debt: ship something rough, refactor later. The code is still there. The debt is expensive, but the principal is recoverable.

Deferred systems engineering doesn't behave that way. What gets deferred can be split into two kinds:

• Reconstructable: links between artifacts that still exist. If the requirements, design documents and test reports survived, someone can connect them later. Painful, but possible.
• Unrecoverable: reasoning that was never written down. Why passive cooling instead of a cold plate? What thermal-margin assumption sits behind that requirement? Which alternative architectures were considered and rejected, and on what grounds?

Retrofit projects usually deliver the first kind. The second is what engineers need when a requirement changes, and what an assessor is asking for when they ask "why?" It disappears when the person who knew it leaves or forgets. No retrofit recovers it. The best you can do is reconstruct a plausible story.

That line, between what late SE can rebuild and what it can only guess at, is where Part 2 picks up.

What's next

• Part 2: What early SE actually buys you.
• Part 3: The compounding cost of deferral.
• Part 4: Why systems engineering is not really a process problem.
• Part 5: Back to the title: why SE keeps landing at the end of the roadmap anyway.

A question for anyone building complex systems: when did systems engineering actually arrive on your program, and what forced it?

---

Srivardhan Chandrapati is the founder of SysenAI. He spent about twelve years in systems engineering and functional safety across advanced mobility and energy, at Cummins, Rivian, EnerDel, Fisker and BorgWarner, and now builds from Bengaluru.

References

1. Forsberg, K. & Mooz, H. (1991). "The Relationship of System Engineering to the Project Cycle." Proceedings of the First Annual Conference of the National Council on Systems Engineering (NCOSE), Chattanooga, TN. DOI: 10.1002/j.2334-5837.1991.tb01484.x
2. INCOSE. "What is Systems Engineering?" (long-standing definition, superseded in 2019). Reproduced in INCOSE IW2014 SE Summit materials: incose.org (PDF)
3. INCOSE (2023). INCOSE Systems Engineering Handbook, 5th ed. Wiley. Definition per INCOSE (2019) and ISO/IEC/IEEE 15288:2023. See also INCOSE: About Systems Engineering
4. ISO 26262-8:2018. Road vehicles — Functional safety — Part 8: Supporting processes, Clause 6 (Specification and management of safety requirements).
5. VDA QMC. Automotive SPICE Process Assessment Model, v4.0, SYS.2. Via UL Solutions, Automotive SPICE Pocket Guide v4.0 (PDF)
6. Stecklein, J. M., Dabney, J., Dick, B., Haskins, B., Lovell, R., & Moroney, G. (2004). Error Cost Escalation Through the Project Life Cycle. NASA Johnson Space Center; presented at INCOSE International Symposium 2004. NTRS 20100036670 (PDF)
7. INCOSE (2015). INCOSE Systems Engineering Handbook, 4th ed. D. D. Walden, G. J. Roedler, K. J. Forsberg, R. D. Hamelin & T. M. Shortell (eds.). Wiley. Section 2.8 and Figure 2.4 (pp. 13–14), "Committed life cycle cost against time", adapted from Defense Acquisition University (1993).
8. NASA (2016). NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2. Figure 2.5-1 (p. 13), "Life-Cycle Cost Impacts from Early Phase Decision-Making", adapted from the INCOSE handbook. nasa.gov (PDF)
9. EVreporter. "AIS 156 Standard – additional safety requirements | Practitioner's Perspective." evreporter.com
10. Press Information Bureau, Ministry of Road Transport and Highways (2022). "Amendments to EV battery testing standards: AIS-156 and AIS-038 (Rev 2) to be implemented in two phases w.e.f 1st Dec, 2022 and 31st March, 2023." pib.gov.in
11. Deccan Herald (17 September 2022). "Deadline to meet battery safety norms likely to be extended: report." deccanherald.com

Further reading

• Cook, S. & Wilson, S. (2019). "The Enduring Path to System Success: Investment in Quality Early-phase Systems Engineering." INCOSE International Symposium 2019.
• National Research Council (2008). Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Systems Acquisition. The National Academies Press. DOI: 10.17226/12065