Here is a question that comes up in design reviews, program kick-offs, and onboarding conversations more often than most senior engineers want to admit: Does the system requirements document drive the architecture, or does the architecture drive the requirements? A second version of the same confusion: If I already have a concept architecture, why do I need a separate requirements document?
These are not naive questions. The confusion is structurally reasonable — both artifacts describe the same system, both are produced early in a program, and in practice they are often edited by the same people in the same weeks. Getting the distinction wrong, or letting it blur, is one of the more common root causes behind requirements volatility, failed design reviews, and late-program scope surprises. It is worth being precise.
What a System Requirements Document Actually Is
A System Requirements Document (SRD) — sometimes called a System Requirements Specification (SRS) — defines what the system must do and what constraints it must satisfy. It is written from the perspective of the system’s external behavior and performance. It says nothing, at least in principle, about the internal structure the system will use to achieve those behaviors.
Good requirements are verifiable. “The system shall process sensor data with a latency not exceeding 50 milliseconds under peak load” is a requirement. It specifies a measurable outcome. It can be tested against a completed design. It does not say whether you achieve that latency with a dedicated coprocessor, a tuned software pipeline, or a hardware accelerator — those are architecture choices.
Requirements also carry obligation. They represent commitments made to customers, regulators, or internal stakeholders. They define the contract the engineering team is building to. That contract role is why requirements need to be stable enough to be meaningful but managed carefully enough to accommodate legitimate change.
In formal systems engineering practice, requirements are organized by level. System-level requirements define the top-level contract. Subsystem or allocated requirements break that contract down so individual design teams know what their piece must deliver. Derived requirements — more on these shortly — emerge from design decisions and must be traced back up to system-level intent.
What a System Architecture Actually Is
A system architecture is a structural description of the system — how it is decomposed into components, how those components interact, and how responsibilities are allocated across them. Architecture addresses questions like: What are the major functional blocks? What are the interfaces between them? What physical or computational resources are assigned to which functions? What design patterns govern the structure?
Architecture is inherently a set of decisions made under constraint. The architect is not describing a unique logical necessity — in almost every real program, multiple architectures could satisfy the same requirements. The architecture document (or model) records which structural choices were made and, in good practice, why.
Architecture decisions have consequences downstream. Choosing to distribute processing across three independent compute nodes has implications for latency, fault tolerance, inter-node communication bandwidth, and power budget. Choosing a centralized architecture has different implications. Neither is correct in the abstract. Both generate obligations that must be tracked.
Which Comes First?
The honest answer is: neither, not in the absolute sense the question implies.
In a clean textbook model, requirements come first. You define what the system must do, then you design a structure to do it. That sequence is pedagogically useful and roughly correct for simple systems or for the first pass through a new domain.
In practice, requirements and architecture co-evolve. Here is why.
Early requirements are written at a level of abstraction that still requires interpretation. To determine whether a requirement is feasible — or even meaningful — you need at least a conceptual architecture. You need to know enough about the structure to ask: Can we actually achieve 50ms latency given the sensor interface we plan to use? If the answer is no, the requirement needs to change or the concept needs to change. You cannot answer that question from requirements alone.
At the same time, a sound architecture cannot be evaluated without requirements. Architecture decisions are justified by their consequences for system behavior. If you do not know what behavior you need, you cannot make principled structural choices. Architecture without requirements is speculative engineering.
What healthy programs do is iterate deliberately. A first-pass requirements set drives a first-pass conceptual architecture. That architecture reveals feasibility constraints and trade-offs that feed back into requirements refinement. The refined requirements support more detailed architecture. This is not failure to follow the process — it is the process.
The Critical Mechanism: Derived Requirements
This is the part that gets dropped most often, and it is where programs get into serious trouble.
When an architecture decision is made, it generates new requirements on the subsystems and interfaces that implement it. These are called derived requirements. They do not come from the customer. They are not in the top-level SRD. They emerge from the architecture itself.
Example: The system architecture allocates fault detection to a watchdog processor. That allocation immediately creates derived requirements on the watchdog processor — response time, failure mode coverage, interface bandwidth, power budget. Those derived requirements need to be documented, formally. They need to be traced both upward (to the system-level requirement that made fault detection necessary) and downward (to the watchdog processor design that must satisfy them).
If derived requirements are not captured formally, they live in the architect’s head, in a presentation deck, or in a meeting note. When the architect rotates off the program, when a subsystem team changes, or when a design review challenges the allocation, those undocumented requirements become a source of silent gaps. The subsystem team builds to what they were told. The system does not behave as intended. Nobody can trace why.
The architecture-requirements boundary is not just a conceptual distinction. It is a data management problem.
How the Two Artifacts Should Relate
Think of it as a bidirectional contract. The SRD holds the system accountable to external stakeholders — customers, regulators, program management. The architecture holds the design accountable to the SRD. Every requirement should be traceable to at least one architectural element that satisfies it. Every significant architectural choice should trace back to at least one requirement that motivates it.
This traceability is what makes change management tractable. When a requirement changes — and requirements always change — you need to know which architectural elements are affected. When an architectural decision changes, you need to know which requirements are implicated and whether any derived requirements need to be revisited.
Without this linkage maintained as live data, traceability degrades into a periodic audit exercise. Teams produce a requirements traceability matrix (RTM) for a design review, the review passes, and then the RTM sits in a document folder while the design continues to evolve. Six months later, the RTM no longer reflects the architecture, the architecture no longer cleanly satisfies the requirements, and nobody can tell you exactly when the drift happened.
How Modern Tooling Handles This — and Where Most Falls Short
The traditional toolset for systems engineering separates these concerns in ways that inadvertently enable drift. Requirements live in a dedicated tool — IBM DOORS, DOORS Next, or Jama Connect. Architecture lives somewhere else — a modeling tool, a set of SysML diagrams, a PowerPoint. The link between them is manual: someone maintains a traceability matrix that maps requirement IDs to architecture elements.
This works under strict process discipline. The problem is that strict process discipline is hard to sustain across a multi-year program with changing teams. When the link is a spreadsheet or a manually maintained matrix, it gets out of sync. Nobody is lying — the team is just moving fast, and updating the traceability matrix is not the thing that gets done today.
Tools like IBM DOORS Next, Jama Connect, and Polarion have improved their internal traceability capabilities substantially. All three can maintain requirement-to-requirement and requirement-to-test links. The limitation is that architecture lives outside these tools in most real programs, so the architecture-requirements link remains a boundary problem.
Flow Engineering approaches this differently. The platform is built around a graph-based model where requirements, architecture elements, and their relationships are all first-class objects in the same data structure. A system requirement, the architectural element that satisfies it, and the derived requirements that element generates can all exist as nodes in the same graph, with typed edges connecting them. That means the link is not a separate artifact to be maintained — it is the structure itself.
When an architecture decision changes in Flow Engineering, the affected requirements are queryable immediately. When a requirement changes, the architectural elements that carry the obligation are surfaced without a manual audit. Derived requirements can be created in context — attached to the architectural allocation that generated them — rather than entered separately and linked after the fact.
This matters operationally because the failure mode it prevents is not dramatic. Architecture and requirements do not diverge all at once. They drift in small increments, each one defensible, until the accumulated drift produces a gap that costs real schedule and budget to close.
Flow Engineering’s deliberate focus is on this connected structure. It is a focused tool, not a general project management platform — teams that need broad program management features will need to integrate it with other systems. But for the core problem of keeping architecture and requirements in sync throughout a program, the graph-based approach addresses the structural cause of drift rather than adding process overhead to manage it.
Practical Starting Points
If you are setting up a program or trying to clean up an existing one, three practices make the architecture-requirements relationship tractable:
Define the boundary explicitly. Decide, in writing, what belongs in the SRD and what belongs in the architecture. A common split: the SRD holds externally verifiable behaviors, constraints, and interface requirements. The architecture document holds structural decisions, allocation rationale, and derived requirements generated by those allocations.
Treat derived requirements as first-class artifacts. Every time a significant architecture decision is made, ask: what new requirements does this place on the system, subsystems, or interfaces? Document them formally. Trace them both ways.
Link the artifacts in a queryable form. Whether you use a formal modeling tool, a structured database, or a platform like Flow Engineering, the requirement-to-architecture link should be something you can query, not something you reconstruct for each review.
The Short Answer
A system requirements document defines what the system must do. A system architecture defines how the system will be structured to do it. Neither comes first in absolute terms — they co-evolve through deliberate iteration. Architecture decisions generate derived requirements that must be formally captured. The failure mode that damages programs is not confusing these two artifact types — it is letting them drift apart quietly while the work continues.
Keeping them connected is not a documentation problem. It is a data structure problem. Programs that treat it as one will solve it once. Programs that treat it as the other will solve it repeatedly.