How to Write Requirements for Systems That Will Be Modified After Fielding
Most requirements engineering practice is implicitly aimed at a single event: system acceptance. Pass the verification tests, close the requirements, deliver the system. That framing is adequate for a product that ships and stays static. It is not adequate for a defense platform, an industrial control system, a satellite bus, or a medical device—systems where the operational life spans decades and modification is not an exception but a routine condition of service.
When a system is modified after fielding, every change triggers a chain of questions: Which requirements does this change affect? Which verification evidence remains valid? Which derived requirements were written against an assumption that no longer holds? If the requirements baseline was written as a snapshot of the initial configuration and nothing more, answering those questions requires archaeology. Engineers reconstruct intent from meeting notes, margin comments, and tribal knowledge. That is expensive, error-prone, and in regulated industries, legally problematic.
This article explains how to think about requirements differently from the start—so that your requirements baseline supports the system’s entire operational lifecycle, not just its first day in service.
Why Initial-Configuration Requirements Fail at Modification Time
Requirements written for delivery tend to describe what the system shall do at acceptance. That is a necessary condition, but not sufficient. The problems surface when a modification is proposed:
Ambiguous scope. A requirement that reads “The system shall track 20 simultaneous targets” doesn’t tell you whether the tracking algorithm, the sensor interface, or both are within scope for a proposed upgrade. A requirements baseline with no architectural partitioning embedded in it gives no guidance.
Lost rationale. Requirements are often traceable to parent requirements, but the reason a specific threshold was chosen is rarely captured formally. When a modification proposes relaxing a threshold—say, accepting 18 targets instead of 20 during a software transition window—there is no way to evaluate whether that relaxation is acceptable without recovering the original rationale. If the threshold was derived from a threat model, relaxing it has different implications than if it was derived from processor capacity that has since doubled.
Version collapse. The system in the field after Modification 3 is not the system that was delivered. If the requirements baseline reflects only the delivery configuration, there is no authoritative statement of what the current fielded system is required to do. Modification 4 is then written against an inaccurate baseline.
Verification gap. Verification evidence accumulated for the initial configuration may not be valid for the modified configuration. Without a clear mapping from requirements to configurations, teams either re-verify everything (expensive) or verify nothing (dangerous).
These are not process failures that better discipline can solve. They are architectural failures in how the requirements were written and maintained.
What Modifiability Requirements Actually Look Like
Modifiability is an ility—a quality attribute, like reliability or maintainability. Most quality attribute requirements are vague in practice: “The system shall be maintainable.” That is not a requirement; it is a wish. A modifiability requirement is testable.
Here is what testable modifiability requirements look like across several categories:
Interface Stability Requirements
“The [subsystem X] external interface shall be defined by a versioned interface control document. Any modification that alters the ICD shall require a formal interface change notice and re-verification of all functions exercising that interface.”
This makes interface change a first-class event, not an assumption buried in design documentation.
Partitioning Requirements
“The mission processing function shall be partitioned from the platform management function such that a software upgrade to the mission processor introduces no change to platform management software.”
This is a requirement on the architecture, not the function. It exists specifically to enable future modification with bounded re-verification scope.
Upgrade Insertion Latency
“The system shall support replacement of the signal processing module within [N] hours of system downtime, using the standard maintenance kit defined in [reference document], without requiring recalibration of the sensor subsystem.”
This is a direct statement of the system’s capacity to accept a known class of modification. It is verifiable at delivery and re-verifiable at each modification point.
Graceful Degradation During Transition
“During any modification in which the primary processing chain is unavailable, the system shall maintain [X% of nominal capability] using the backup processing path. The transition window shall not exceed [Y hours].”
Operational systems can’t always go dark for modifications. This requirement protects operational availability during the modification process itself.
Configuration Identification Requirements
“Each delivered configuration shall be uniquely identified by a configuration identifier that maps to a baseline requirements set, a bill of materials, and a verification evidence package.”
This sounds administrative. It is actually what makes re-certification tractable: without it, there is no authoritative answer to “what configuration is this unit?”
Writing Requirements That Carry Their Own Rationale
A requirement without rationale is a fact without context. The numeric threshold, the interface constraint, the partitioning boundary—all of these encode decisions that were made for reasons. When the system is modified, those reasons determine whether the requirement remains binding, can be relaxed, or needs to be re-derived.
The standard practice is to capture rationale in a “rationale” field in the requirements tool or in linked documentation. That is necessary but not sufficient. The rationale needs to be actionable, which means it should answer three questions:
-
What assumption does this requirement protect against being violated? (“This threshold is set to provide margin against the threat envelope defined in [document]. If the threat envelope expands, the threshold must be re-derived.”)
-
What is the parent requirement this was derived from? Not just the ID, but a statement of the derivation logic.
-
What verification approach was used, and why is it valid for the current architecture? (“This was verified by hardware-in-the-loop test. If the processing architecture changes, the test configuration must be updated to remain valid.”)
This level of documentation is more work at requirements authoring time. It pays for itself at first modification. On long-lifecycle defense programs, it pays for itself many times over.
Configuration Management of Requirements Across the Fielded Life
Requirements configuration management is often treated as a subset of document control: baseline the requirements at PDR, CDR, and delivery, then store the files. That is not configuration management; it is archiving. Configuration management means you can answer, at any point in the system’s operational life, a specific question: What is this unit required to do right now?
That requires several things to be true:
Requirements are versioned against configurations, not just against program phases. Each modification that changes any requirement—whether by adding, deleting, modifying, or re-verifying—produces a new requirements baseline tagged to the resulting system configuration. The previous baseline is retained, not overwritten.
Change rationale is captured at the requirement level, not just the modification proposal level. Modification proposals explain why the modification was undertaken. Requirement-level change rationale explains why a specific requirement was added, changed, or deleted as part of that modification. These are different questions. The first is program-level. The second is what enables re-certification engineers to evaluate the impact of a proposed further change years later.
Traceability is maintained through modifications. If Requirement A was replaced by Requirement A’ in Modification 2, the replacement relationship is explicit. If Requirement B was deleted because it addressed a function that was removed from scope, that deletion is documented. Gaps in the traceability chain are indications of risk, not housekeeping details.
Verification evidence is linked to the configuration it validates. Test report X validates Requirement A in Configuration 1. After Modification 2, if Requirement A’ replaced Requirement A, the test report no longer validates the current requirement without explicit re-validation or a documented rationale for why the previous evidence remains sufficient.
This is demanding to implement with conventional document-based tools. When requirements live in Word documents or disconnected spreadsheets, maintaining this structure across a decades-long fielded lifecycle requires heroic process discipline. In practice, that discipline degrades. Modification 6 engineers inherit a partial picture of what Modifications 1 through 5 actually changed.
How Modern Platforms Support Fielded Requirements Management
Graph-based requirements platforms change what is tractable. When requirements, their attributes, their traceability relationships, and their change history are nodes and edges in a live model rather than static documents, the queries that matter for modification management become answerable.
Flow Engineering is built around this model. The platform maintains the full history of each requirement—every change, the rationale recorded at the time of the change, and the configuration context in which the change was made. This means a team preparing Modification 4 can reconstruct the exact state of the requirements baseline as it existed when Modification 2 was certified. Not from archived PDFs, but from a live query against the model.
The practical consequence for fielded systems is significant. Re-certification engineers can identify which requirements were in scope for a proposed change, what the rationale was when those requirements were written, and which verification evidence is still valid for the current configuration—without relying on institutional memory or document archaeology. Flow Engineering’s AI-assisted analysis can also surface derived requirements that are implicitly affected by a proposed change but not explicitly linked to it, which is one of the most common sources of scope underestimation in modification programs.
The intentional focus of Flow Engineering is on the requirements engineering and traceability layer. Teams with existing program management, V&V automation, or ERP infrastructure will integrate Flow Engineering as the requirements layer rather than replacing those systems. That is an appropriate scope for what is genuinely a hard problem.
Practical Starting Points
If you are writing requirements for a system that will be modified, here is where to start:
1. Define your system’s modification classes at program start. A technology upgrade, a mission scope change, a form-factor replacement, and a software patch are different modification types with different impact profiles. Writing one or two representative modifiability requirements for each class forces you to think about what the system needs to support.
2. Require architectural partitioning as a system requirement, not a design recommendation. If clean partitioning between subsystems is necessary to enable modification with bounded re-verification scope, say so explicitly as a requirement. Design teams tend to optimize for other things unless the partitioning constraint is binding.
3. Make rationale a required field, not an optional one. This is a process decision, but it needs to be enforced at requirement authoring time. Rationale captured retroactively is incomplete. The person who made the decision is often not available when the modification team needs to understand it.
4. Baseline requirements against configurations, not calendar dates. “The requirements baseline as of CDR” is less useful than “the requirements baseline for Configuration 1.0.” When the system has been through four modifications, configuration-tagged baselines let you answer operational questions that date-tagged ones cannot.
5. Plan for requirements debt the way you plan for technical debt. Every modification that is executed without updating the requirements baseline accumulates debt. That debt compounds. Programs that address it continuously spend less than programs that defer it to a re-baseline exercise that arrives, inevitably, at the worst possible time.
Honest Assessment
Requirements for modifiability are not standard practice on most programs. They require more work at requirements authoring time, more discipline in configuration management, and tooling that supports versioned, traceable, historically queryable requirement sets. The return on that investment is measured in modification cycles, re-certification efforts, and the avoidance of expensive scope rediscovery.
Systems that spend 30 years in service will be modified more times than they were designed for. The question is whether each modification team will have a clear picture of what the system is required to do—and why—or whether they will be working from an incomplete record and making assumptions that accumulate into risk.
Requirements written for initial delivery are not wrong. They are just insufficient for the system’s actual life.