What early systems engineering actually buys you

Part 1 ended on a split. When systems engineering (SE) arrives late, some of what was deferred can be rebuilt; the links between artifacts that still exist and some cannot, because it was reasoning nobody wrote down.

That raises an obvious question. If a team is shipping complex systems without a systems engineer, and the hardware works, what exactly is missing? Something is clearly getting done. Requirements exist. Designs exist. Tests pass.

The answer is easier to see if you stop thinking about the V as a sequence of stages and start thinking about it as a division of labour.

Five roles, one V

Here's how the work actually splits on a complex systems program, whether or not anyone holds these job titles.

Two things fall out of this table that aren't obvious from the V diagram alone.

First: compliance isn't a stage. It has no level of its own. The homologation engineer's job is to assemble evidence from every level at once and attest that it hangs together. That's why the trigger that finally forces SE onto the roadmap usually comes from this role, or from a customer asking this role's question. Compliance is the first job that needs the whole chain simultaneously, so it's the first to notice the chain has holes.

Second, and more useful: look at who owns both arms at each level.

At the bottom of the V, one person owns both. The component owner designs the part and writes its unit tests. If the design changes, the same person changes the tests. The link between design and test doesn't need to be written down anywhere, because it lives in one head, and that head is accountable for both sides.

At the top of the V, the arms split. The Product Manager defines what "good" means, and validation gets checked against that definition later, often by someone else. The systems engineer defines requirements and architecture, and a test engineer verifies against them months later.

The levels where the left and right arms have different owners are exactly the systems engineer's levels. That's the structural reason traceability is hard there and easy at the bottom. It isn't a document problem. It's a handoff problem between people who are not the same person, and not always in the same meetings.

Systems engineering is the discipline of making those handoffs survivable.

What Systems Engineering actually produces

Put concretely, early SE produces three things no other role produces.

A requirement set that can be allocated. Not a wishlist, and not a PRD. A set where each requirement is atomic enough to assign to exactly one component owner, verifiable enough that a test engineer can write a test against it, and identified well enough that a change to it can be tracked. The Product Manger supplies intent. Turning intent into something allocatable is a separate skill, and it belongs to SE.

An architecture whose interfaces are named. Most integration failures are interface failures. An architecture that names its interfaces turns the gap between two component owners into an object someone owns, rather than an assumption each of them makes privately and possibly differently.

Links captured while the work is happening. Not a traceability matrix assembled before an audit. The links recorded at the moment the decision is made, by the person owning the decision.

That third one carries most of the weight, and it's the one teams defer most readily. It's worth being precise about why deferring it costs more than it looks.

The part that can't be rebuilt has a name

In 1994, Orlena Gotel and Anthony Finkelstein published an analysis of the requirements traceability problem, based on empirical work with more than a hundred practitioners. They drew a distinction that has held up for thirty years: traceability before the requirements specification exists, and traceability after it [1].

Post-specification traceability is the part everyone pictures. A requirement links forward to a design element, a component, a test. These are links between documents that exist, and they can, with effort, be reconstructed later.

Pre-specification traceability is the other direction: where a requirement came from. Who raised it, what concern it answers, what discussion produced it, what was considered and dropped along the way. Their finding was that the majority of problems attributed to poor traceability come from inadequate traceability of this first kind [1].

That's the academic name for what Part 1 called unrecoverable. The distinction isn't between important links and unimportant ones. It's between links to things that still exist and links to things that only ever existed in a conversation.

It also explains something that puzzles teams midway through a retrofit. They buy a requirements tool, spend a quarter populating it, produce a complete traceability matrix, and still can't answer the question an assessor actually asks, which is why a requirement says what it says. The matrix is complete in the post-specification direction and empty in the other one.

Design rationale is a coproduct, not an extract

There's a second body of work worth knowing, because it settles a question teams keep relitigating: can rationale be recovered afterward from the artifacts?

The question is an old one; Werner Kunz and Horst Rittel proposed Issue-Based Information Systems (IBIS), in a 1970 working paper, as a way of recording the issues, positions and arguments that structure a decision [2]. Twenty years later, a group at Rank Xerox EuroPARC developed QOC, or Questions, Options and Criteria: a semiformal notation for the design space around an artifact, capturing the questions that framed a choice, the options that answered them, and the criteria used to compare them [3].

Their framing of it is the part that matters here. A design space analysis, they wrote, is not a record of the design process. It's a coproduct of design, and it has to be constructed alongside the artifact itself [3].

Which is to say: it isn't extractable. There's no post-hoc procedure that recovers it from the drawings, because the options that lost never made it into any drawing. If nobody captured the comparison while it was live, the comparison is gone. That conclusion has been sitting in the literature since 1991, and it's the single most important thing to know before deciding to defer this work.

What SE's absence actually looks like

None of this means a team without a systems engineer skips the work. The work happens, it just happens implicitly and it lands in two predictable places.

The PRD becomes a de facto requirements spec. A document written to align a company on intent gets used as the contract a component is designed against. It's the wrong instrument: it's prose, it's rarely atomic, it has one owner rather than one owner per line, and it changes without anyone tracking what the change touched. Component owners read it and make their own inferences, which are reasonable and mutually inconsistent.

Each component owner formalizes their own slice, differently. Good engineers don't work from vague inputs; they tighten them. So the battery lead writes precise thermal requirements in their own sheet, the motor lead writes precise requirements in theirs, and each uses their own ID scheme, their own definition of what counts as verified, and their own assumptions about the interface between them. Each slice is rigorous, but no one is putting it all together.

This is why "we'll add SE later" feels so reasonable at the time. From the inside, the team isn't being sloppy, everyone is doing careful work. What's missing is the layer that makes careful local work add up to a coherent system, and its absence stays invisible until something crosses a subsystem boundary.

What this buys you, stated plainly

Early SE buys three capabilities, and they are:

• Change impact analysis. When a requirement changes, you can enumerate what it touches instead of convening a meeting to guess.
• Verification that means something. Tests trace to requirements that trace to stakeholder needs, so passing the test is evidence about the product rather than evidence about the test.
• Answers to "why." For the engineer six months from now, and for the assessor, who asks the same question with more consequences attached.

One pass is the easy case

Everything above describes a single trip down the V and back up. On one pass, a team that deferred SE can usually work its way through. The people who made the decisions are mostly still there. The context is a few months old, not a few years, and someone remembers the "why".

Complex systems programs don't stop at one pass. There's a B-sample, then a C-sample. A regulation changes. A variant gets scoped. A field issue arrives. Each of those is another trip around, and each one asks for reasoning the last trip didn't record.

That's where the cost stops being a fixed debt and starts compounding. Part 3 looks at four kinds of laps and what each one costs when the reasoning is missing.

---

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. Gotel, O. C. Z. & Finkelstein, A. C. W. (1994). "An Analysis of the Requirements Traceability Problem." Proceedings of the First IEEE International Conference on Requirements Engineering, Colorado Springs, CO, pp. 94–101. DOI: 10.1109/ICRE.1994.292398. Author's PDF
2. Kunz, W. & Rittel, H. W. J. (1970). Issues as Elements of Information Systems. Working Paper No. 131, Institute of Urban and Regional Development, University of California, Berkeley. eScholarship
3. MacLean, A., Young, R. M., Bellotti, V. M. E. & Moran, T. P. (1991). "Questions, Options, and Criteria: Elements of Design Space Analysis." Human–Computer Interaction, 6(3–4), pp. 201–250. DOI: 10.1080/07370024.1991.9667168