From Text to Model: Why/How Models Should Replace Requirements as the Medium of Alignment

It’s easy to forget the original purpose of a task until the task itself becomes the purpose.

In traditional document-based systems engineering, textual requirements became the default artifact. We wrote "shall" statements, followed structured templates, and sometimes used tools like Gherkin to enforce consistency. But we often lost sight of the real purpose: achieving alignment between stakeholders.

When systems engineers send a requirements document for approval, the real message is:

“This is what we’re building. Do you agree?”

When that document goes to a subcontractor, it’s more like:

“Here’s what we need. Please build it, and we’ll verify it.”

This form of communication has been reliable. But in today’s complex and interconnected systems environments, the question becomes: Is it still efficient?

Why Textual Requirements Still Dominate

Even as MBSE adoption increases, textual requirements remain the foundation in many projects. Why?

• Contracts are written in natural language, often backed by legal requirements.

• Regulatory bodies demand traceable, human-readable requirement sets.

• Auditors require historical, versioned artifacts that demonstrate compliance.

• Requirement management tools are mature, robust, and well-understood.

• Models are still not a shared language across all disciplines or stakeholders.

Text, while imperfect, is still the lowest common denominator for cross-functional communication.

The Efficiency Gap

Model-Based Systems Engineering (MBSE) was born out of a need to address this inefficiency. Instead of producing fragmented documents and manually maintained specs, MBSE encourages the creation of integrated, interconnected models, ones that represent structure, behavior, interfaces, and constraints in a coherent whole.

We’re already comfortable with this idea outside of engineering. When buying a house, we don’t sign off on a document that says, “The bedroom shall be 3 meters wide.” We sign floor plans. We agree on models.

So why don’t we use models to align in systems engineering?

Barriers to Adopting Models for Alignment

Despite the promise of MBSE, full replacement of textual requirements still faces real barriers:

1. Cultural Inertia

Old habits die hard. Expressing ideas in natural language feels easier than learning a modeling language like SysML.

2. Versioning Challenges

Traditional requirement tools have decades of maturity in versioning, baselining, object-level change tracking, and collaborative protection. Most modeling tools still lag in areas like diffing, branching, and merging.

3. Modeling Lags Behind Project Execution

Projects run on tight schedules. Modeling is front-loaded and time consuming. Under pressure, teams drop modeling first, even though skipping it often leads to greater rework later.

What We Can Do About It

1. Start Small and Don’t Overcomplicate

Change doesn’t happen overnight. Focus on quick wins. Use models to generate requirement views, interface control documents, and test artifacts. Let models coexist with documents during transition phases even use behavior to text generation engines to utilize the power of the modeling tool.

2. Leverage Proven Versioning Approaches

Don’t wait for modeling tools to catch up. Use proven practices from software engineering, like Git-based control, to manage model versions and collaboration. With SysML v2, textual notation and API access offer a practical path forward.

3. Prioritize Value, Not Perfection

Perfection is the enemy of progress. A model that’s 80% complete and delivered on time is more valuable than a perfect model delivered too late. Prioritize modeling efforts where clarity, traceability, or simulation provide the most impact especially in safety-critical areas.

Final Thought

We are not simply replacing documents with diagrams. We are evolving our medium of engineering alignment. The shift from static, textual requirements to connected models is already happening. It requires deliberate planning, discipline, standards alignment, and cross-functional buy-in.

The challenge is not only technical, it’s cultural.

What has your experience been in transitioning from document-based to model-based alignment? Have you encountered resistance or found strategies that worked? Let’s compare notes and move the practice forward.