TL;DR
- Your spec was accurate when signed off. It cannot update itself as the codebase changes — and six months of features, hotfixes, and shortcuts add up fast.
- Architecture drift is a structural problem: small, reasonable decisions accumulate silently until the gap between spec and code is audit-sized.
- The fix is not better documentation. It is continuously verifying that every build still matches what was specified. Automatically and from day one — using the appropriate tool.
6 Months from Now: Will Your Codebase Still Match What Was Specified?
Your Software Design Document and Your Codebase are Not the Same Thing. Here is How to Keep Them in Sync.
The codebase moved on. But the documents stayed where they were.
It happens on most projects.
After months of work, the software requirements specification is complete and the software design document is signed off. Stakeholders have reviewed it, architects have shaped it, and the development team has what they need to start building.
Six months later, the picture looks different: Features have been added, hotfixes landed overnight, a new team member made a shortcut that seemed reasonable at the time, and a contributed component that worked fine on its own turned out to quietly break a layering rule that nobody had thought to check.
By the time someone looks closely, the gap between what was specified and what was actually built is large enough to cause real (and very expensive) problems at an audit.
This often tends to get framed as a process problem or a question of team discipline. But it is neither.
What is the problem then?
It is structural. Because your software design documents and codebase are not the same thing.
A software requirements specification (SRS) tells you what the system should do. It does not tell you whether the code six months from now still reflects those decisions.
Keeping specification and implementation in sync requires something more than a well-written document and good intentions.
What Goes into an SRS and a Software Design Document?
A software requirements specification (SRS) is the document that defines what a system needs to do.
Following IEEE 830 conventions, it covers functional requirements i.e. the behaviors the system must exhibit, as well as non-functional requirements like performance, safety, security, and reliability constraints, along with the boundaries of what is being built.
It gives the development team and everyone depending on the outcome a shared, documented understanding of what they are building toward.
A software design document, sometimes called a software design specification (SDS), addresses the next question: not what the system should do, but how it will be built.
It describes:
-
How the system is broken into components
-
What each module is responsible for
-
How interfaces are defined
-
Which dependencies are permitted
-
Which architectural constraints must hold throughout development
A good software design document makes the intended structure concrete. It shows:
-
Which layers exist
-
What each layer can access
-
Which modules are allowed to communicate with each other
-
What is off limits
Read together, these two documents form the architecture description, the record of how the system was designed to work. ISO/IEC/IEEE 42010 formalizes what a complete architecture description should contain.
The limitation these documents share is that they capture the system at a point in time. They are accurate when written and approved. What they cannot do is update themselves as the codebase changes.
How Architecture Drift Happens, and Why it is so Hard to Catch
Architecture erosion happens when the implemented system quietly drifts away from its architecture description over time.
It builds up through small decisions, each one reasonable in context, until the gap between the software design specification and the running code is wide enough to cause real damage.
Take a safety-critical embedded system developed under ISO 26262. The software architecture description defines a strict layered structure: the application layer has no direct access to hardware abstraction routines, and all hardware access goes through a dedicated hardware abstraction layer.
That rule is there for good reasons.
It keeps platform-specific behavior contained, makes the system easier to port, and underpins the functional safety argument the team will need to make to their certifier.
Eighteen months into development, a developer under deadline pressure adds a direct call from an application module to a hardware routine. It fixes the immediate problem, it clears code review because the reviewer is focused on whether the code works rather than whether it respects the architecture, and it ships.
Six months later a second violation appears, then a third, in a different subsystem, from a developer who had no idea about the first two.
By the time the architecture team is preparing for their functional safety audit, the software architecture description and the codebase are telling different stories.
Getting them back into alignment means working through a large codebase at a point in the project when making changes is expensive, difficult, and in some cases, impossible.
Research backs up how common this situation is.
The same dynamic plays out in medical device software under IEC 62304, industrial control systems under IEC 62443, and aerospace software developed to DO-178C.
In regulated domains, an architecture description that no longer matches the implementation is both a quality issue and a compliance failure.
The technical term for this gap is architecture divergence.
It is a dependency the code has introduced that the architecture does not allow. They are the specific distinctions an architect needs to assess whether the implementation still reflects the specification. The difficulty is that most teams have no automated way to make that assessment.
Your SRS Documents the Rules. Architecture Verification Checks the Code is Following Them.
Architecture verification means continuously checking whether the implemented system still conforms to the architecture description. It is the part of the process that documentation alone cannot cover.
Axivion Architecture Verification works by taking the rules from your software design document, the permitted dependencies, the forbidden cross-layer calls, the module boundaries, and encoding them into an architecture model.
That model represents how the system is supposed to be structured. Axivion then analyses the actual codebase and computes the differences between the two automatically.
Because it integrates into your CI/CD pipeline, it is not a one-time check. Axivion runs against every build.
When a developer introduces a dependency that violates the architecture description, it is caught at the point of introduction rather than months later when someone is preparing for an audit.
Whether it is a forbidden import, a cross-layer call, a module boundary violation, or a missing dependency – it will be caught immediately when introduced.
For teams working under compliance frameworks, that kind of traceability is not a nice-to-have.
A requirement that specifies an architectural constraint, such as "the application layer shall not directly access hardware registers," needs to be verifiable in the actual artifact, not just stated in a document. Axivion provides that verification and keeps the audit trail to back it up.
Guides on writing an SRS are useful for getting requirements documentation right. What they cannot answer is whether the codebase, six months from now, will still satisfy what was written.
That is where architecture verification picks up.
Putting your Software Design Document to Work
Setting up an architecture model in Axivion starts with what you already have:
-
Software design specification
-
Software architecture description
-
Dependency and layering rules they contain
An architect works through the structural rules in the software design document, the permitted module dependencies, the layer hierarchy, the forbidden relationships, and expresses them as constraints in Axivion's architecture definition.
Axivion then maps the concrete implementation entities, files, packages, classes, functions, onto the conceptual entities in the model, and the reflexion analysis determines whether the codebase conforms.
The architecture model does not replace the software design specification. It is what makes the specification active. The rules that matter enough to document become rules that are continuously enforced.
Discover how Fresenius Medical Care keeps the multiFiltratePRO's software architecture intact across a decades-long development lifecycle — and what that means for a device where software quality is a matter of patient safety. Read Success Story >
Which Teams Benefit Most from Architecture Verification?
Architecture verification is relevant to any team producing an SRS for regulated software, but the stakes are highest in industries where a gap between the specified and implemented architecture has direct safety or compliance consequences.
In automotive development under ISO 26262, functional safety arguments rest on the software architecture description accurately reflecting what was built. A layer violation or an unexpected dependency can undermine safety analyses that took months to produce, at a point in the project where reworking them is expensive.
Continuous architecture conformance checking gives teams confidence that the implementation stays consistent with the architectural foundation of their safety case as development progresses.
Medical device software under IEC 62304 addresses traceability from requirements through architecture to implementation.
Architecture verification provides automated evidence that the implemented structure matches the software design specification, and that evidence holds up through the iterative development cycles that real projects involve and not just at the point when everything is theoretically finished.
For industrial and IoT systems developed under IEC 62443, cybersecurity requirements include explicit architectural constraints.
These are the kinds of constraints architecture verification is well suited to enforce. When the implementation diverges from what was specified, that is not just a quality observation. It may mean a security boundary has been crossed.
Aerospace software qualified under DO-178C requires evidence of architectural integrity across the full development lifecycle. Architecture verification provides that evidence continuously rather than as a late-stage activity.
What teams in all of these domains have in common is that they invest significant effort in requirement specifications and software design documents, and then have no reliable automated way to know whether the codebase still reflects them as development continues. Architecture verification fills that gap.
In a Nutshell: An SRS Without Architecture Verification is a Promise you Cannot Verify
A software requirements specification tells you what the system should do and how it should be structured. What it cannot tell you is whether the code being shipped still reflects those decisions. Without something actively checking that, the specification is a statement of intent rather than a guarantee.
There is a significant difference between catching an architectural violation at the point of introduction and finding it in an audit.
One is a one-line fix in a pull request while the other is an expensive forensic exercise across a large codebase at the worst possible point in the project timeline. And that is before the rework, analysis, and compliance evidence that must be rebuilt from scratch.
The hardest thing is having to answer the question “how long has it been this way?” only to realize you are drawing a blank.
The gap between specification and implementation is an engineering problem that has an engineering answer: check continuously that the architecture and code still match what was specified.
That is what Axivion Architecture Verification does, automatically on every build, across the full development lifecycle, with the traceability that regulated industries need.
Contact us regarding your project. We´re happy to help.
