Track the Source of Requirements
As a system’s design evolves, design decisions about subsystems often begin to be viewed as requirements for that subsystem.
Design decisions are not requirements though. That’s why it is important to have traceability with respect to every design decision.
With complex systems, what often happens is that a team working on a subsystem perceives an interconnecting subsystem’s interface specification as a requirement, but it is really just a design decision. It is sometimes the case that changing the interface is the best solution to a problem. But that requires talking to the people who designed the interface—otherwise, there is a risk of changing it in a way that violates a key design assumption or degrades the component’s cohesion.
For every design decision, it is important to be able to identify the reason for the decision, or who made the decision, so that they can be engaged in a discussion about whether the decision can be changed.
At SpaceX, they have a rule that every requirement must have attached to it the name of the person who specified the requirement. That way, if the requirement is problematic, that person can be contacted to verify if the requirement is still needed.
An alternative approach is to have lightweight documentation that always specifies the reason for each design decision. As we explained, design decisions end up being treated as requirements. If the reason for the decision is preserved, it can be challenged more easily.