Should Requirements Be Written Before or After Architecture?

Every systems engineering curriculum gives the same answer: requirements first, then architecture. Define what the system must do before you decide how it will do it. Keep the solution space open as long as possible. Let requirements drive design.

It is a principled answer. It is also, for most real programs, only partially achievable — and the teams that treat it as fully achievable often get into more trouble than the ones who acknowledge the tension and manage it deliberately.

This is one of the genuine chicken-and-egg problems in systems engineering. Understanding it clearly — not just knowing the textbook position, but understanding why the textbook position is incomplete — is what separates requirements processes that help programs from requirements processes that the program eventually routes around.

The Textbook Answer, and Why It Exists

The classical model, codified in standards from MIL-STD-499B through ISO/IEC/IEEE 15288, places requirements elicitation and analysis upstream of architectural design. The logic is sound:

Requirements constrain the solution space. If you write requirements after you have chosen an architecture, you are at risk of writing requirements that describe the architecture you already have rather than the system your stakeholders actually need. The requirements become a post-hoc justification rather than a genuine constraint.

Architecture decisions are expensive to reverse. A requirement that changes in week four costs far less than an architectural decision that changes in week forty. Stabilizing requirements before committing to architecture reduces the cost of late-breaking changes.

Separation of concerns produces better verification. When requirements are written independently of architecture, you can verify the architecture against requirements without circular reasoning. If the same team wrote both, and wrote them together, “does the architecture satisfy the requirements?” becomes a trivially true question by construction.

These are real reasons, not academic formalism. Programs that collapse requirements and architecture into a single undifferentiated activity — particularly early-stage programs where the team is excited about the solution — frequently discover years later that they have no independent requirements baseline to verify against. The architecture is the requirements, effectively, and any proposed change to either threatens both simultaneously.

The Practical Reality: Co-Evolution Is Inevitable

The textbook model assumes that requirements can be fully specified in isolation from architecture. For many system types, this assumption breaks down immediately.

Consider a satellite communications payload. The requirements include data throughput, latency, link availability, and coverage area. These parameters cannot be made concrete without understanding, at minimum, the orbital regime, the antenna aperture constraints driven by launch vehicle fairing, the power budget driven by solar array area, and the thermal environment driven by orbital beta angle. None of those are architecture-neutral. Every specific number in the requirements is implicitly conditioned on architectural assumptions.

A requirements author who refuses to engage with architecture until requirements are “complete” is not being rigorous — they are deferring decisions into implicit assumptions, which is worse. At least an explicit architectural assumption can be tracked and challenged.

The same dynamic appears in avionics, automotive systems, medical devices, and industrial control systems. Physics, platform constraints, and supply chain realities impose boundaries on the requirement space before the requirements team has a chance to define it. Pretending otherwise does not keep the solution space open; it just obscures which parts of the solution space are actually available.

The empirical record supports this. Studies of concurrent engineering programs consistently find that requirements and architecture are refined in parallel, with each pass through the architecture informing the next pass through the requirements. This is not a sign of an undisciplined program. It is how complex technical systems actually get designed.

The Risks of Each Extreme

Acknowledging co-evolution is necessary. Losing control of it is catastrophic. Both extremes carry specific failure modes.

Requirements Written in Ignorance of Constraints

When a requirements team works in isolation — particularly when it is staffed primarily with stakeholder representatives and program managers rather than systems engineers — requirements tend to accumulate wishes rather than constraints. Performance numbers are set at “as good as possible” rather than at verified system-level needs. Interface definitions assume capabilities that no existing or planned technology can deliver. Reliability requirements are set at numbers that would require zero-maintenance hardware over multi-decade lifespans.

The architecture team then has two choices: design to the requirements and produce something that cannot be built, or quietly re-interpret the requirements in ways that the requirements team never intended and does not know about. Both outcomes represent a failure of the requirements process.

The deeper problem is that requirements written without physics awareness tend to be written at the wrong level of specificity. Parameters that actually depend on architecture (mass, power draw, thermal dissipation) get specified as absolute requirements rather than as allocations derived from system-level constraints. This collapses the architectural trade space before the architecture team has had a chance to explore it.

Architectures That Freeze Before Requirements Are Stable

The opposite failure is equally damaging. Architecture teams under schedule pressure often push toward a point design faster than the requirements process can generate stable, verified inputs. Once a specific architecture is chosen — a particular processor family, a bus topology, a redundancy scheme — the sunk cost and downstream commitments make it very difficult to revisit even when requirements subsequently change in ways that challenge the architectural choice.

The result is requirements that are unconsciously reverse-engineered from the architecture. Engineers writing requirement text know what the architecture looks like, and they write requirements that the architecture can satisfy, rather than requirements that reflect what stakeholders need. Verification becomes circular. Any audit that looks carefully at the traceability chain can see the problem — the requirements and architecture are suspiciously well-matched because they were designed together without being managed as separate engineering artifacts.

How Mature Programs Handle This

Programs that do this well share a set of practices that manage co-evolution without losing the benefits of the requirements-first model.

Explicit iteration cycles with defined freeze points. Rather than treating requirements as a single deliverable that precedes architecture, mature programs define a series of gates — system requirements review, preliminary design review, critical design review — at which a defined subset of requirements must be stable. Architecture development proceeds within the constraints of currently frozen requirements, and architectural learning feeds back into the next iteration of requirements refinement. Co-evolution is permitted but time-bounded.

Architecture trade studies as requirements validation tools. A trade study is not just a mechanism for selecting an architecture. It is also a mechanism for validating whether requirements are achievable and what the cost of achieving them is. When a trade study reveals that a requirement is achievable only at ten times the budgeted cost, that is information the requirements team needs. Treating trade studies as downstream activities that cannot inform upstream requirements eliminates this feedback loop.

Allocation as a two-way conversation. Allocation — the process of distributing system-level requirements to subsystems and components — is typically depicted as a top-down activity. In practice, it must be bidirectional. Subsystem teams have knowledge of what their components can achieve that the system requirements team does not. When a subsystem team identifies that a specific allocation cannot be met with available technology, that information must flow back up to the system level, where it may require requirements relaxation, architectural restructuring, or a deliberate program decision to accept risk. Allocation that flows only downward, without a return channel, produces requirements documents that do not correspond to anything the architecture can actually deliver.

Explicit capture of architectural assumptions in requirements. When a requirement is written against an implicit architectural assumption — this antenna aperture, this processor speed, this redundancy configuration — that assumption should be documented as a derived requirement or a design constraint, not buried in the requirement text. This makes the assumption visible, traceable, and revisable if the architecture changes.

How Modern Tools Support Co-Evolution Without Losing Traceability

The tooling dimension of this problem is non-trivial. Traditional requirements management tools are designed around the document model: requirements are created, baselined, changed through formal change control, and traced to downstream artifacts. This model works reasonably well when requirements are written first and architecture is derived from them. It does not work well when both are being refined in parallel.

The specific failure mode is traceability debt. When requirements and architecture are co-evolving rapidly, engineers stop maintaining traceability links because the overhead of updating them is higher than the perceived benefit at any given moment. By the time the program reaches a formal review, the traceability matrix reflects the state of the program several months ago and has to be reconstructed manually — an expensive, error-prone process that everyone involved knows is not producing accurate results.

This is where graph-based, AI-native tools make a meaningful difference. Flow Engineering, which was built specifically for hardware and systems engineering teams, models requirements and architectural elements as nodes in a connected graph rather than as rows in a document. When an architectural decision is made, the affected requirements are visible immediately through their graph relationships — not because someone manually updated a spreadsheet, but because the connection was captured when the requirement was written.

The iterative requirements model Flow Engineering supports lets teams refine requirements as architectural decisions propagate through the model. When a trade study selects a specific bus architecture, the downstream requirements that were written against architectural options are flagged for review. The traceability doesn’t break during iteration — it surfaces the places where iteration is needed.

This matters because the alternative is not rigorous sequential requirements development; the alternative is co-evolution that happens anyway but is invisible to the requirements management process. A tool that can track co-evolution as it happens is not enabling undisciplined requirements practice. It is making visible a process that was already occurring, so it can be managed rather than hidden.

Flow Engineering’s approach also supports explicit capture of the allocation hierarchy — system to subsystem to component — as a live graph rather than a static spreadsheet. When subsystem-level information changes the feasibility of a system-level requirement, that change propagates visibly through the model, which is the two-way allocation conversation that mature programs need.

Practical Starting Points

If you are on a program working through this tension, the following practices help regardless of what tooling you use:

Define your iteration cadence explicitly. Do not let requirements and architecture co-evolve on an ad hoc schedule. Define when requirements must be stable enough to support architecture work, and when architecture learning must feed back into requirements. Make this a formal program event, not an informal conversation.

Identify your physics constraints before writing performance requirements. For any requirement that depends on platform constraints — power, mass, thermal, link budget — trace the derivation before baselineing the number. If the derivation depends on an architectural assumption, document that assumption explicitly.

Treat every trade study as a requirements review. Before a trade study closes on an architectural selection, ask: what does this selection imply for system-level requirements that are currently written as architecture-neutral? Update the requirements to reflect what you learned, or explicitly document why you are not updating them.

Build return channels into your allocation process. If subsystem teams cannot formally raise requirements feasibility concerns back to the system requirements team, those concerns will not disappear — they will go underground and surface as integration problems.

Honest Summary

The question “should requirements be written before or after architecture?” has a correct answer and a complete answer, and they are not the same thing.

The correct answer: requirements should logically precede architecture. You should know what your system must do before you decide how it will do it. This principle protects the solution space, enables meaningful verification, and prevents architecture from becoming a self-fulfilling requirement.

The complete answer: for any complex system, requirements and architecture will co-evolve. The engineering challenge is not to prevent co-evolution but to manage it — to maintain traceability through iteration, to make architectural assumptions explicit rather than buried, and to build formal feedback channels between the architecture team and the requirements team so that learning flows in both directions.

Programs that pretend co-evolution is not happening do not produce better requirements. They produce requirements that have drifted from their traceability chains, architecture teams that have quietly re-interpreted requirements no one was maintaining, and verification activities that are confirming nothing real. Acknowledging the co-evolution and managing it deliberately is the more disciplined position, not the less disciplined one.