There is a shift occurring, albeit quietly, across engineering organizations and it’s more significant than it seems. Engineers have relied upon document-based methods for documenting increasingly complex systems, thousands of pages of specification documents, layered Word docs, iterative spreadsheets, succinctly for years. But it’s not to say engineers have grown lazy in their documentation efforts, it’s that systems have become so interconnected and fast-moving that static approaches can no longer keep up. Something has got to give.
For years, the document-based approach was “good enough.” An engineer would outline and write requirements which would get passed to the next engineer who interpreted them for something else, only for a different set of requirements to be documented later down the line. But where things go wrong is in interpretation.
Two engineers can read the same requirement document and have two entirely different interpretations of what’s meant by something, and what needs to be built. And by the time this disconnection is uncovered, the work is often already well in progress with expensive consequences of fixing it, and that’s just one instance.
Table of Contents
A Different Way of Thinking About System Information
This is where system engineers shift their thinking about documentation and model based systems engineering (MBSE) comes into play. Instead of relying on a series of disparate documents to capture pertinent information about a system, MBSE locates everything inside of a developed model which serves as the source of truth.
Requirements, behaviors, interfaces, even the architecture, all exists in one comprehensive place in a connected field. If something changes, it changes in the model. There’s no frantically updating three different documents and hoping someone remembers to update a chart elsewhere.
This semblance of uniformity seems deceptively easy; however, for engineering teams, it’s a monumental cultural shift. One no longer reads about a system; they engage with a tangible instance of it. It changes the approach to decisions and the speed in which problems are identified.
Why Documentation Has Always Been A Weak Point
Here’s the kicker: no one likes to document anything, let alone engineers, and no documents age well. A requirements spec prepared after a month on the job looks nothing like one prepared at kick-off. Systems adapt as do stakeholders, technical constraints emerge from the dusty depths, and paper trails can hardly keep up.
Once a clean and professional document starts to receive notes about questions and comments about subsections emerge, track changes outline an alternative story to what’s originally been put down. By that time a newcomer is on the team who thinks he or she’s arrived on the project with a clean slate and can make sense of everything, they’re sorely mistaken.
Yet it’s not due to lack of effort; teams work diligently on their documents. It’s just a structural problem. Documents are static. They represent a snapshot in time at one point of thinking but subsequently don’t adjust for what’s next. When working with dozens of interconnected subsystems, making sure they have every relevant document up-to-date at all times is a full-time job.
What Changes When the Model Becomes the Source of Truth
The first thing that changes when teams go from documentation-based efforts to model based systems engineering is traceability. Following an evolving requirement from its origin through development and into verification feels like investigative work when sifting through disparate files to find where information was cross-referenced, if it was cross-referenced at all. A well-formed model provides naturally occurring connections; there’s no detective work needed to see exactly where something came from, what it relates to, if it was even touched.
This is especially important on large programs where different teams may be working on subsystem implementation at the same time; one team doesn’t need to blindly guess what another team might be doing; they’ve got a reliable document through which to understand common points of interest before integration shows them all what’s wrong.
The other side of this notion comes from change; in a documentation world, a change request opens the floodgates for additional work as files need to be adjusted in multiple places but risk one or two falling through the cracks. In a model world, change requests become streamlined adjustments that need more discussion of what it’ll address rather than extra work on finding out what’s been changed outside of requests.
The Broader Shift in Engineering Culture
Ultimately, moving away from documentation as a source of information is as much a tools conversation as it is a cultural one. MBSE requires people to think differently about their communication styles, knowledge capture methods, and how to work across disciplines. It’s not easy; people have their comfortable workflows and need organizational support to advance new implementations over time.
Yet those who have made the leap often find it worth the investment, not because MBSE is perfect or alleviates all project issues from hereon in, but because it at least situates teams and keeps them honest about their project status, from the same model. The less everyone makes assumptions along the way based on quiet decisions operating toward the wrong goal, the better.
It’s inevitable, systems engineering projects have outgrown many methods that were once acceptable in prior generations which at the time, were either all they knew or weren’t at liberty to expand upon. Systems are more interconnected today than ever before with more complex constraints than ever before and stricter time constraints than ever before for engineering teams at this size, and capturing and distributing information isn’t optional; it’s just a matter of how soon?
Thus, for those teams still considering transitioning to this arena, it’s probably not a matter of if an organization will modernize its documentation approach, but how it will go about doing so effectively such that it sticks?
